Typical Lifecycle Resources and Relationships

To help see how all of the pieces might fit together in a collaborative Application Lifecycle Management (ALM) solution, we thought it might be useful to briefly describe lifecycle domains of interest, some of the resource types associated with each domain, and some of the relationships among resources. This is not intended as a grand, unified meta model of ALM – it's merely an example of how one might think about the ALM space, and a description of some of the interesting resources and relationships in these domains. Our intent is to collaborate with the community in each of these domains to elaborate the vision.

Starting in the lower left corner of this diagram, the Requirements domain concerns itself with defining the characteristics of a system under design, including functional attributes, operational characteristics, qualities of service, and so on. Requirements can be expressed in any number of vocabularies – sketches and storyboards, use cases, textual documents, process models, etc.

Closely related to requirements are test cases. Test cases contain the satisfaction criteria for requirements. Since applications are typically delivered and tested through a number of iterations, the delivery lifecycle is often divided into test phases, each with its associated test plans, indicating which requirements are to be tested in which phase.

Work items are used for two reasons. First, they help to identify, plan, and manage the work that people need to do, making them key elements in any project management system. Second, they are used to associate work products (such as changes made to source code) to expressions of the work that needs to be done (the tasks). In this way, work items help us understand why changes were made to artifacts.

In the SCM domain, changes to resources are grouped into change sets which flow into a stream; these are used to provide stable configurations of resources for various purposes, such as giving developers code on which they can work, or feeding an automated build system. The build system takes a stable configuration of code and assembles it into a working application. This has many uses, of course, one of which is to provide the QM system with an execution environment against which it can run a set of test cases.

For all of this to work, or at least work well, a collection of tools must agree on some common concepts that provide context for the other activities. Key among these are users (with associated access rights, for example), projects (to provide context for managing changes to resources), plans (to organize work), and processes (rules of engagement for teams and projects).

By agreeing on common vocabularies, individual tools can more easily collaborate for effective software delivery, each providing its own unique value and sharing resources in a way that benefits the broader lifecycle process.