Kovair is now part of SurgeONE.ai Same experts, even more power.

Month: April 2014

Overview of the Kovair Agile Solution

Introduction

Kovair Agile Solution is an implementation of Agile based on SCRUM methodology using Kovair Platform. Kovair has extended SCRUM methodology to implement various tools necessary to implement Agile in a distributed development scenario. One major differentiator of Kovair Agile Solution from some other Agile products from other vendors is its configurability – using the Kovair platform the Agile Solution can be extended and further configured to incorporate any organizational need which go beyond the definition of SCRUM and Agile methodology. Moreover, since Kovair uses the same platform for implementing ALM for more traditional iterative methodology and ITSM for ITIL V3 implementation, all three solutions can be mixed in a tightly integrated manner within a single tool interface.

List of Entities

Kovair Agile Solution supports the following Artifacts/ Entities/ Objects:

  • Projects – contains multiple Releases
  • Releases – contains multiple Sprints
  • Sprints – With multiple durations from 1 week to 6 weeks
  • Product Backlogs – Categorized as Epic, Features, User stories
  • Daily Scrum Meeting – In a distributed development daily SCRUM meeting happens remotely even sometime asynchronously. Kovair implementation of virtual daily SCRUM meeting captures all the major meeting aspects.
  • Test Cases – Implementing more traditional Test Management approaches integrated with Agile to enforce testing of selected Product Backlog by Traceability Relations.
  • Issues/ Changes – a complete Issues management solution integrated with Agile including custom visual issues process design and implementations.

Gathering backlogs from varied sources

The User Stories can be created from various sources – selective import from previous projects, import from Microsoft Word and Excel, manual input through custom forms of Kovair Agile Solution, submission from integrated web pages from corporate websites or portals.

Managing Entities

Releases

Kovair Agile Solution supports multi-Sprint Releases. The Backlog items belong to multiple Releases and multiple Sprints. At each Sprint and Release level the total estimated efforts are summed-up. A Roadmap report shows Backlog items in a Hierarchy of Release and Sprints.

Backlogs

The Backlog Items are assigned to different users independent of their locations. Kovair Agile Solution being 100% browser based, any user can access it from anywhere anytime. Reports show Backlog items grouped by Release, Sprint and Assigned Users. Kovair offers a number of tools to manage a large number of Backlogs. Backlogs can be categorized into Epics which are very high level requirements, Features that an Epic is broken into and further User Stories that are linked to a Feature. These include custom Views, Filters, Text Search, ID Search. The Views allow dynamic multiple nested grouping of Backlog with custom display fields and ordering.

Sprints

A Release consists of multiple Sprints. Each Sprint consists of multiple Backlog items. Each Backlog Item has an assigned user and estimated effort. Kovair Agile Solution calculates the Sprint start and finish dates based on the included Backlogs. The Backlog items may be moved from one Sprint to another to manage the Sprint schedule.

Issues and Change

Kovair Agile Solution has a built-in Issues/ Change management which allows users and project members to enter various Backlogs as Issues/ defects/ change and enhancement requests. Kovair’s industry leading process engine allows routing of these items through appropriate workflows based on the Backlog types. In addition the various Backlogs can be imported from MS Word, Excel documents, parsed from Email and submitted from different websites integrated with Kovair.

Risks

Kovair Agile Solution includes a separate Risk Management feature. The Risks can be entered, Tracked and related to Backlog Items.

Versioning Backlog Item

Kovair has built-in versioning and also implicit and explicit locking mechanism. Built-in versioning allows tracking of all previous versions, comparison between two versions, a version diagram to show the progression, cloning of artifacts, branching and merging of versions. An artifact is implicitly locked when a user opens it for editing. A user can also explicitly lock it for a longer time period. All other users can see who has locked an item but still can access it in read-only mode.

Estimating effort for a Backlog item

Kovair Agile Solution supports Story Point as well as Feature Points as an extension of Function Point Analysis. A planning Poker implementation allows estimation of Story and Feature Points collaboratively and what is more important, by a distributed team.

Traceability Relationships

Using Kovair’s industry leading Traceability Relation, feature linking can be done between User Stories, between User Stories and other Backlog items, Sprints and Risks.

  • Using Kovair’s Traceability relations the User Stories can be linked to Test cases
  • Using Kovair’s Traceability relations the User Stories can be linked to Defects.
  • Using Kovair’s Traceability relations the User Stories can be linked to Codes or Change Items.

The following screenshot displays Kovair Traceability View by which users can get a complete visibility to all the artifacts that are linked to one another which eventually would facilitate in either tracing forward or backward starting from any particular artifact.

Kovair agile solutions

Collaboration

Ranking of a Backlog Item

Kovair Agile Solution has a collaborative ranking tool which allows multiple users to rate each backlog item in a 1 to 10 scale against various business values. These business values may include ‘Additional Revenue Potential’, ‘Competitive Advantage’ etc. Each value can have a weightage factor. Based on various ratings from multiple users Kovair automatically calculates a normalized score for each Backlog which can be used for prioritizing Backlog.

Collaborating concurrently with Kovair Tasks

Kovair Agile Solution has built-in task management. Tasks can be created manually or automatically by Kovair’s Process and Policy engines. The basic Metadata for a Task are Activity, Owner(s) and Status (Open, Completed, Work Started). Additional standard metadata includes % complete and various planning fields like estimated and actual work, start, finish dates. Users can add custom fields to Tasks as well. In Kovair Tasks are linked to various Artifacts e.g. Backlog, Issues, and Defects. There can be multiple Tasks related to an Artifact item. The Artifacts can be entered into the system in a number of ways as indicated earlier – selective import from previous projects, import from Microsoft Word and Excel, manual input through custom forms of Kovair Agile Solution, submission from integrated web pages from corporate website or portals or through integration with several IDEs or other tools – Visual Studio, Eclipse, RequisitePro, ClearCase, Quality Center… A Task linked with an Artifact allows users to access the information of the Artifacts directly from the Task. Each Task may be assigned to multiple owners. Kovair supports three multi-owner Task Assignment Policies – ‘Queued’, ‘One Task for All’ and ‘Independent Tasks’. Queued tasks mean any one user can become the owner and the Tasks from the other user’s home page will be removed by the system. One Task for All means multiple owner work together on a single item. Independent means when each user works on the same artifact independent to each other but in parallel. Tasks are linked to the development artifacts. For example a backlog of type defect can flow through a Kovair process and generate Tasks linked to that defect. The Tasks may include ‘Review of defect’, ‘Fix defect’, ‘Test fix’ – all related to the same defect and at each Task the team members work on it. Kovair includes a built-in Timesheet module. Users can enter actual time spent for each task using this Timesheet.

Multi-threaded Discussions among the Stakeholders

A primary activity of any team is to make a series of decisions based on comments and opinions of its members. These are sometimes done in synchronous meetings (either in-person or using technologies like teleconference or online-meeting). Whereas such meetings have their place, multi-threaded discussions (in the context of each collaboration item) provide a forum to share such comments in a more structured way, reducing the need to have costly meetings. These discussion-threads allow one to capture a complete history (and hence the intellectual property) of the decision making process.

Kovair agile solutions

Kovair supports multi-threaded discussions in terms of Contextual Comments. Kovair has a built-in Comments section that can be exposed to the users via system pre-defined or custom defined forms. The purpose of this section is to enable users to carry out multi-threaded discussions in the context of each Backlog. The discussions are entered either as a New Comment or Reply to an existing comment. Comments can be in the form of rich text with all sorts of formatting and even embedded images. Kovair allows users to include multiple attachments to their comments. The attachments can be – simple Notes, any type of Files (Word document, spreadsheet, image etc.) and URL. These multi-threaded discussions are saved in the context of the version of a Backlog.

Automation

Process Automation

Kovair has the industry’s leading Process Engine – Omniprocess. Using a drag-and-drop graphical designer an Agile process can be designed, implemented, enforced and automated. The process will automatically create Tasks for one or more users based on Roles they play. When the tasks are completed the process creates a new set of tasks for a new set of users. The following is a screenshot of User Story process.

Automation through Policy

In Kovair advanced notification Policies can be set with custom email content with embedded macro variables for the Artifact metadata. The notifications are generated in the context of Artifacts and Tasks.

Reporting

Kovair Agile Solution includes multiple reporting engines – HTML, Crystal, Microsoft Word and Microsoft Excel. Both textual and graphical metrics reports can be displayed on custom Dashboards. Each user can have several custom Dashboards based on his/ her role. Various reports include:

  • A dashboard with all relevant reports of Agile like Velocity, Burn Down, and Burn Up chart are given below.
  • Kovair provides various textual reports to show the status useful for Scrum meetings.
  • Kovair supports various graphical distribution reports
Scalable Software Delivery through Integrated Agile ALM

Introduction

The unprecedented level of success of Agile methods is causing a wide range of organizations to apply Agile techniques on large project teams with hundreds of people, often geographically distributed, in various environments and various complex situations that involve regulatory compliance, external partners, etc. Agile is getting pushed beyond the small, co-located team environments that it has been typically associated with. Clearly, Agile needs to scale far larger than the techniques were pioneered for.

While there is an unmistakable shift towards Agile as a software development methodology of choice, not all of those who start meet with success. Not surprisingly, this has led to an industry-wide quest for a better understanding of the success factors in the adoption of Agile.

Visibly improved quality and productivity are the two key reasons behind the acceptance of Agile. The Agile principles have led to the adoption of practices that require software delivery organizations to fundamentally change the way they work to improve team synergy and engage with customers during the development process to deliver working software frequently. Improvement of quality is a natural outcome of the need to deliver working software to the customer frequently while improvement of productivity is a natural outcome of group synergy.

This improvement of quality and productivity was first noticed in primarily software construction projects by small, co-located teams. During that period, tools other than development tools (IDE, Test Automation Tools, and SCM Tools) were not considered important or necessary for successful delivery of software. The first Agile principle of Individuals and interactions over processes and tools’ was quoted by many in arguing that use of tools was against the principles of Agile because tools reduce agility. The industry-wide interest in Agile changed this perception about tools.

What followed was an industry-wide agreement that ideas of Agile had to be extended from partial methods to a full-fledged, disciplined delivery processes, and had to scale using next-generation ALM tools to work effectively for geographically distributed large teams involving hundreds of people engaged in a full delivery process – from project initiation to deployment and maintenance. Thus, the idea of “Agile ALM” was born.

However, Agile principles of team interaction, collaboration, frequent delivery and responsiveness to change all through the project required the Agile Project Management tools, the Lifecycle Management tools (ALM tools), and the Development tools to seamlessly integrate allowing in-context collaboration among all members of the team. The need for frequent delivery of working software to customer further required elements of DevOps to be integrated into the lifecycle. Hence, the idea of Agile ALM had to be extended further to ‘Integrated Agile ALM’.

This whitepaper discusses some key considerations for the successful implementation of a scalable IT delivery process using an Integrated Agile ALM framework. It also discusses the widely used approaches taken by different vendors over time towards achieving Integrated Agile ALM, and the relative merits of these approaches.

Defining an Integrated Agile ALM Framework

Using Scrum as the base, this section proposes a model for a scalable end-to-end Agile delivery framework that can be used to manage delivery of large scale software development projects from inception to delivery into production and maintenance. It shows how Scrum can be extended to scale; how DevOps is a natural extension of the Agile principle of frequent delivery of working software to the customer; and why and how ALM tools need to be used to establish an end-to-end integrated tool chain covering all lifecycle phases in a continuum.

Scaling Agile

The Agile manifesto, as well as the mainstream Agile methods, has an implicit development focus. The principles of customer collaboration, frequent delivery of working software, responsiveness to change, etc. ensure that what‘s built is what the customer needs. This is great for the customer, but for the delivery organization, how it is built is also important. The delivery organization is faced with the dual challenges of building it right and building it the right way using the right tools.

A delivery process that is not efficient, streamlined, or cost effective impacts the bottom line of the delivery organization. Allowing the team to choose the tools they want to use is great as long as it does not involve significant investment in new software tools that the project budget does not cover. For any project, there is always a pressure to leverage existing tools and infrastructure. So, adopting radically different tools, infrastructure, or processes may not always be feasible.

Responsiveness to change is not only based on sound logic, but it also impacts cost and schedule. Contractual obligations, requirement for upfront planning and budgeting, constraints on cost and schedule are some of the several scaling challenges that delivery organizations adopting Agile face. The other Agile scaling factors are large, geographically distributed teams, mandated documentation and compliance standards, organizational complexity.

The delivery organizations of today are looking at all options of leveraging the benefits of Agile within a delivery framework that allows large, geographically distributed teams to deliver consistently better quality, faster and cheaper software while still operating under the contractual constraints of schedule, cost, externally mandated requirements, dependencies on external partners, and organizational constraints of various kinds including but not limited to organization culture, IT infrastructure, enterprise IT disciplines, etc. All these factors clearly indicate the need of scaling agile for delivery organization.

Scaling Approach

Scott Ambler and many other contemporary thought leaders and analysts have prescribed a multi-dimensional approach to scaling Agile, involving:

  • Moving from simplistic and empirical processes to full-scale industrialized agile delivery processes
  • Customizing the delivery processes to take into account various scaling challenges, such as integrating DevOps into the lifecycle
  • Using the right tools where necessary

Taking note of the fact that many large-scale agile adoptions would not function without tools, there is a universal consensus on the use of tools where necessary. Collaboration strategies that worked for small & co-located teams must give way to sophisticated collaboration tools and techniques when teams are geographically distributed. The meaning of collaboration has to grow beyond email and instant messaging; the tools must make it possible to seamlessly collaborate in context in a real-time manner.

An Agile Delivery Process

The mainstream agile methods are focused on different aspects of the software development life cycle with an implicit development focus. Some focus on the practices (Extreme Programming, Pragmatic Programming, Agile Modeling), while others focus on managing the software projects (the Scrum approach). Yet, there are approaches providing full coverage over the development life cycle, such as Dynamic Systems Development Method (DSDM) and IBM Rational Unified Process (RUP). Thus, there is a clear difference between the various agile software development methods in this regard. Whereas DSDM and RUP do not need complementing approaches to support software development, the others do to a varying degree. (Wikipedia)

An Agile Delivery Process with Scrum

With its product-centric focus, Scrum provides an excellent foundation on which scalable delivery processes can be built. It is a framework within which various processes and techniques can be employed. While Scrum itself focuses on requirements management and incremental product delivery, it does not specify how the Development team works; how the final product is deployed in production; or how it is maintained. However, Scrum‘s proven incremental and adaptive development approach can form the nucleus of a project-centric end-to-end delivery process — from project inception that includes scoping project, creating an architectural framework and a technical strategy, making an estimate of cost and schedule to determine feasibility, etc., to development, which is based on Scrum‘s principles of managing Product Backlogs, Sprint Planning, Sprint Reviews, etc., and is powered by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management, to deployment in production that integrates elements of DevOps, to maintenance – with project tracking and monitoring across the entire lifecycle.

Scalable Software Delivery Through Integrated Agile ALM

Integrating DevOps into the Lifecycle

In a traditional organization structure with independent departments for development, QA, and IT operations, development team hands over the developed software product to the QA team for testing, and the QA team hands over the tested software product to IT Operations team for deployment in production.

Scalable Software Delivery Through Integrated Agile ALM

Quite often, the activities in the organization‘s development and operations processes that affect transitions involve dealing with different priorities, goals, processes, tools, and a variety of other issues. Improving the hand-off of work from development to operations is an age-old goal. DevOps is an umbrella concept that refers to anything that streamlines communication and collaboration between development and operations. The goal of DevOps is to break down these silos to achieve a better delivery lifecycle.

DevOps and Agile

In many ways, focus on DevOps is a natural consequence of the Agile movement.

Continuous Integration

The Agile principle of frequent delivery of working software to the customer requires the Agile team to build and test the software as frequently as possible. The Agile practice of Continuous Integration, abbreviated as CI, is popular because it addresses this critical aspect of the success of Agile very well. CI makes Integration a non-event! Single source-code repository, daily commit, automated unit testing, automated build, automated functional testing, regression testing are some of the key practices within the practice of CI.

Continuous Deployment

The point of continuous integration is to flush out the problems in the system in rapid cycles. In the end, the system will be judged by how it runs in production. Therefore, continuous integration cannot deliver working software unless the software is continuously deployed and tested in a production environment.

A significant part of how a system behaves in production is linked with the production environment. Technical issues related to hardware, system software versions, networking software, database systems, etc. can arise when software is moved to production system. Validation of non-functional requirements, such as security, performance, and availability must be performed in the target production environment only.

Traditionally, the focus of testing used to be on the functional side of the testing during development, and non-functional aspects of testing, which are also critical, were deferred until after the development phase. To mitigate this risk, the test environment must be as exact a replica of the production environment as possible.

Continuous Deployment is the essence of DevOps. DevOps makes deployment a non-event!

Realizing DevOps

Realizing continuous deployment, in terms of teams involved, would require the development team to hand-off the compiled and unit tested product to the operations team on a daily basis. Now, this is not practically possible as long as the software needs to be tossed over the wall of organizational barriers. Implementing continuous deployment would require:

Team Integration: Members of the operations teams should be part of the self-organizing and cross-functional Agile team.

Process Integration: The activities that affect transitions between teams must reflect the realities of the processes of all teams, such as Development, IT Operations, and QA. Examples include both the deployment of software into test, staging, or production and the resolution of problems caused by defects in the software, which must be fixed and a new version of the software must be redeployed.

Tool Integration: Tool integrations allow one tool to leverage the interface provided by the other to automate tasks that affect transitions between teams. For example, to enable the release of a solution into production, a deployment tool could access production configuration information maintained in a configuration management tool. To enable reporting of a problem with an application, a test management tool could register the defect reports into the defect management tool used by the development team.

Data Integration: Data integration allows multiple tools to work with one another‘s data. For instance, on the development side, a released product may include quality results, configuration information, and proof of regulatory compliance. In operations, usage statistics are tracked and configuration and installation details are maintained for the solution. Integration of this information enables consistency and accuracy between the development and operations teams through single truth across teams.

Application Lifecycle Management Tools

Application Lifecycle Management (ALM) refers to the capability to integrate, coordinate and manage the different phases of the software delivery process — from development to deployment. ALM is a set of pre-defined processes and tools that includes definition, design, development, testing, deployment and management. Throughout the ALM process, each of these phases are closely monitored and controlled.

Categories of ALM Tools

    The categories of ALM tools include, but are not limited to:
  • Requirements management
  • Modeling
  • Design
  • Integrated Development Environment (IDE)
  • Software configuration management
  • Change management
  • Build management
  • Automated unit testing
  • Test automation (Automated functional testing)
  • Test management
  • Software deployment
  • Issue/Defect management
  • Project management

ALM being one of the fastest growing areas in the IT space in recent times, more and more ALM tools are continuously appearing in each category. With Agile becoming mainstream, new approaches focused on mixing and matching the right methodologies will emerge, and will need to be supported by ALM tool vendors. Demand for Cloud deployment will drive the growth of SaaS-based ALM tools. With large-scale virtualization of server infrastructure becoming a reality, organizations will move more and more of their IT infrastructure to virtualized environments with increased focus on further reduction of spending on hardware. Thus, ALM has entered a new phase in its evolution as it has to deal with the impact of agile methodologies on software development on one hand, and the impact of DevOps on software deployment and support on the other.

DevOps in ALM

In many ways, DevOps is a natural extension of ALM. Large scale delivery of software projects needs processes and tools for managing full delivery lifecycle from project initiation to deployment into production and maintenance.

Traditionally ALM tools were focused on phases from inception till development cut-over. This included tools for Requirement Management, Modeling, Design, Development (IDE), SCM, Build Management, Automated Unit Testing, Automated Functional Testing, etc., and Project Management. Tools necessary for managing application lifecycle beyond development, i.e., QA, Deployment, and Support were largely part of IT Operations and Services Management tool set. ALM has since expanded to include, in a seamlessly integrated way, tools for Deployment Automation, IT Services Management, Quality Metrics, etc.

Integrated Agile ALM

ALM is universal and methodology agnostic. ALM applies to Agile as much as it does to any other methodology, e.g., Waterfall. So, what‘s needed for Agile ALM‘? In reality, it is about the tools, but with a difference. Agile ALM refers to the ability of using tools in a way that people want in an agile development project, and not the other way around.

Scaling agile needs a tool chain across the life cycle that supports agile way of planning, collaborating, managing task based development, continuous integration, frequent releases, ability to create and maintain traceable artifacts across the lifecycle, and so on. Tools can no longer enforce how team should work; tools that do not enhance productivity and agility, while allowing people to do their work the way they want, are no longer acceptable. Thus, Agile ALM is implicitly ‘Integrated Agile ALM’.

In Agile, the more seamless an integrated product development framework is, the more an agile team can focus on building customer value. The integration becomes an enabler for delivering customer value. At the same time, there is a need for flexibility and customization so that an ALM tool framework doesn‘t drive the team‘s interaction.

Summary

A working definition of an Integrated Agile ALM is thus proposed as: It is an end-to-end process framework that can be used to manage the delivery of large scale software development projects from inception to delivery, into production and maintenance, without compromising on the core Agile principles.

  • It is an extension of Scrum.
  • It has elements of DevOps in it.
  • It can be implemented using an integrated ALM tool chain across the life cycle that support agile way of:
    • Planning
    • Collaborating
    • Managing task based development
    • Continuous integration
    • Frequent releases
    • Ability to create and maintain traceable artifacts across the lifecycle
  • It is generic enough to be customized in a way that Agile team wants to use the tools.

Agile Development with Kovair Task BoardThe Task Board in Kovair Agile ALM solution is configured according to the needs of an Agile team member. The tasks are graphically represented in the Task Board according to the status of the task. The Task Board displays the users to whom the tasks are assigned. Another feature of the Task Board in Kovair Agile Studio is that one can drag and drop tasks from one Status category to another Status category, as and when the tasks get updated.

Kovair Traceability Matrix DocumentA Traceability Matrix is a table that helps you trace project related artifacts, both forward and backward. Project related artifacts include requirements, designs, test cases, test steps, defects, and so on. Using a Traceability Matrix, you can trace one of these artifacts to all other linked artifacts.

Kovair Omnibus IntegrationKovair Omnibus offers a unique capability to use both the synchronization model and the link based model of integration. This choice is available for the users of the new generation of IBM Jazz tools – Rational Requirements Composer (RRC), Rational Team Composer (RTC) and Rational Quality Manager (RQM). Along with synchronization of artifacts across tools, Kovair’s generic OSLC provider allows Customers to create OSLC links with artifacts from other tools which are connected to Kovair Omnibus.

Kovair Reports and Dashboards DocumentIt is an absolute necessity for any ALM tool, to be able to gather information from the different work areas of a particular project. However, gathering information is only half the job.
An ALM tool must also be able to effectively present the gathered information, in an efficient and simple manner. The different kinds of Reports and Dashboards in Kovair, allow you to do exactly that. Once you are aware of the subtle differences between a dashboard and a report you will know when do you use Reports and Dashboard?

Scalability and Performance in Kovair Omnibus Document Kovair Omnibus is often adopted in an organization in an incremental fashion. The deployment starts with a few projects and based on their success the solution is pushed for adoption to other project teams. As the number of tools integrated through Omnibus increase at a rate higher than expected, the initial planned hardware infrastructure proves to be inadequate to handle the increased load on the Omnibus servers. Kovair Omnibus can scale up to meet these requirements. Most of the Kovair components are stateless Web Services or WCF services which can be hosted on multiple parallel servers without causing any conflict.

Importing Requirements from MS Word DocumentIn the absence of a proper Requirements Management Tool, most of the organizations use MS Word to manage Requirements. Eventually, as they deploy a standard Requirements Management tool, importing all the records from MS Word to the new tool becomes a challenge. Kovair allows simple solutions to this problem; there are two ways to go about it.

1. Upload the document directly into the application
2. Install an Add-in and import



DefiningTraceability Relationship in Kovair DocumentChanges are inevitable in any sort of development effort regardless of industry. Poorly managed changes can create mammoth impacts on even the most talented development teams. When change is properly managed teams can assess the impact of the change, track the full history, and maintain synchronization among globally distributed teams and disparate tools thus improving the product quality substantially. Maintaining traceability manually can be burdensome and leads to inconsistent information, poor productivity, and diminished quality.

HP QC and IBM RTC Integration with Kovair Omnibus DocumentUndoubtedly, HP QC and IBM RTC are two widely used tools in software industry. HP QC provides a platform for Requirements, Test, and Defect Management in a single repository. It is used by Business Analyst, Developers, and Testers to log Requirements, manage Requirements, log Defects and Test cases and verify them. And IBM RTC can help software development teams to store and organize an enormous amount of information.

Types of Searches in Kovair DocumentWith the kind of competition that exists in the market, it is quite understandable that an ALM tool is rated according to the varying features it can provide. An ALM tool is expected to cover all corners in the lifecycle of a project and for doing that, the tool needs to host a vast range of features some being highly critical and some not so. One such functionality is the ‘Searching’ capability of an ALM tool. So let us discuss this functionality in a greater depth, as to why this feature is important in the context of ALM, and how Kovair deals with it.

Kovair Integration with Git GitHub Gerrit DocumentKovair Omnibus has a complete integration with the Git Suite. So, users using only Git as an Enterprise SCM tool can use the integration to track and get the complete traceability. When a user pushes a change to GitHub site via Git command line, desktop apps, or GitHub.com, the Kovair adapter tracks all the changes and pushes the data to the bus in order to publish it to the other tools. It can also initiate automatic build using the integration bus. This provides the manager a complete view of the changes happening without requiring him/her to log into the SCM system.