Why ALM 2.0

 

OVERVIEW

IT organizations spend billions of dollars a year on development life-cycle tools that don't play well together. The result in most cases - the application life-cycle management (ALM) is still largely a manual process. Most of today's ALM suites don't offer much support for ALM beyond what can be accomplished through brittle tool-to-tool integrations. ALM 2.0 talks about solutions that will be easier to implement, maintain, and employ. And at the end of the day, they'll enable development organizations to build better software.

 

WHAT IS ALM

An ALM solution is an integrated solution of life-cycle tools, not merely a collection thereof. It is a discipline, as well as a product category. There are 3 main pillars combining an ALM solution: traceability, process automation, and reporting and analytics. ALM doesn't support specific life-cycle activities; rather, it keeps them all in sync. Development effort can still fail miserably even if analysts document business requirements perfectly, architects build flawless models, developers write defect-free code, and testers execute thousands of tests. ALM ensures the coordination of these activities, which keeps practitioners' efforts directed at delivering applications that meet business needs.

 

Traceability of relationships between artifacts.

Correlating life-cycle artifacts like market requirements, product requirements, models, tasks, source code, test cases and defects, all in scope of a product/project release, helps demonstrate that the software has delivered functions as the business wanted it to.

Internal and external compliance requirements, as well as the increasing need to coordinate all development participants across roles, locations, and organizations, make traceability more critical to organization success. For most organizations, traceability is a manual process. The problem isn't just the size of projects; it's also the number, the varying size and scope, and the artifact interdependencies. Managing dependencies between high-priority change requests and ongoing application development efforts, makes this process extremely complicated.

 

Automation of high-level processes.

Development organizations commonly employ paper-based approval processes, if any,  to control handoffs between functions like product management, development and QA teams. ALM improves efficiency by automating these handoffs and storing all associated documentation.

 

Providing visibility into the progress of development efforts.

Most managers have limited visibility into the progress of development projects; what visibility they have is typically gleaned from subjective testimonials rather than from objective data. Most of the reporting procedures are manual, based on status meetings, progress reports and demonstrations.

 

ALM 1.0 GENERATION

The majority of today's ALM solutions have grown through accretion rather than through purposeful design. As a result, the dominant structure of today's ALM solutions is tool-to-tool integration, and this integration is never as deep or resilient as advertised - especially when it's integration of different vendors' tools. ALM 1.0 is characterized by the followings:

 

A single tool for each role

The problem with role-based tools is that roles are anything but uniform, varying by company, by business unit, by development team, and even by individual. When a customer's roles don't match up with the roles for which vendors have built tools, the IT organization has to choose between changing its roles, licensing multiple tools for a single role, or purchasing more features than a given role is likely to need. To provide an audience of diverse practitioners with all the features they need, vendors end up stuffing tools with so many features that they are practically unusable. The result is complex and expensive tools that have more functionality than any one individual is likely to need.

 

Redundant and inconsistent ALM features locked in practitioner tools.

Today's life-cycle tools feature an impressive amount of redundant and usually inconsistent functionality in areas like workflow, collaboration, reporting and analytics, and security. What's worse, functionality that would be valuable to the entire development team is often available only from within a single practitioner tool.

 

Integration through brittle repository synchronization mechanisms

Repository synchronization is the primary means for integrating life-cycle tools today - even when the tools concerned are all from the same vendor. But it is often difficult to establish, costly to maintain, or flat-out unworkable.

For many IT organizations, however, moving onto a single repository is a practical impossibility - either because they've invested so much in these repositories or because their development spans so many different platforms.

 

The hidden costs of ALM 1.0

• - A single tool for each role causes low productivity due to tool complexity
• - Role misalignment leads to overspending on licensing
• - Redundant and inconsistent ALM features locked in practitioner tools causes Lack of cross-life-cycle transparency
• - Effort spent building and maintaining synchronizations leads to No single source of truth
• - Integration through brittle repository synchronization mechanisms leads to Process assets are opaque and difficult to manage

 

ALM 2.0 - NEXT GENERATION

ALM 2.0 is a platform for the coordination and management of development activities, not a collection of life-cycle tools with locked-in and limited ALM features.

Using one integrated tool that manages the development lifecycle can save lots of time and efforts in the development process.

 

The architectural ingredients of ALM 2.0 are:

 

One stop-shop

Use one stop-shop for all Application lifecycle activities.

 

Product packaging

Packaging provides customers with simpler, cheaper tools. Today, customers must choose between defect management that's too tightly coupled with test management and requirements management or defect management in a standalone tool.

 

 

Use of open integration standards

Two means of integration - use of Web services APIs and use of industry standards for integration - will ease and deepen integration between a single vendor's tools, as well as between its tools and third-party tools.

 

Source: The Changing Face Of Application Life-Cycle Management Forester, Aug 2006

 

Using ALM 2.0 SYSTEM

As ALM 2.0 is all about collaboration between all participants in the development process, Key process automation, integration and data transparency between all development departments, ALM 2.0 tools are a holistic solution that covers all or most application lifecycle management artifacts, such as internal and external requirements, R&D activities such as design documents and tasks, test cases and test run results, defects, change management and customer facing, to name few.

The ability to trace customer request through its all development lifecycle, such as product requirements that covers it, related design docs and their status, QA coverage such as tests cases coverage and test run results and defects, gives a full traceability and overall picture on project progress ad status, in terms of definition, design and QA.

Using one tool eliminates the need to integrate between modules, allows organizations to manage one repository for all ALM artifacts and easily generate real time analytics and reports.