CM: THE NEXT GENERATION - Evaluating and Selecting a CM/ALM Tool

be critical to successful acquisition. This list is not complete. But it will likely contain numerous items you have not yet considered.

First Generation CM Requirements
First generation (1G) CM tools were available through the 1970s and 1980s, but their use continued well into the new millenium (e.g. Visual Source Safe. Such tools were file-based and focused on basic checkout/in and build capabilities. Some of the requirements included:

1 Item and Revision Identification: Uniquely identify all repository items and consistently identify item revisions.

2 Check-out and Check-in with comments: Check files in and out of the repository and add "reason" comments to the checked out/in files.

3 Exclusive Check-out: Checkout of a file by one person can preclude concurrent checkout of the same file by another person.

4 File Retrieval (aka. R/O checkout): Retrieve either latest or earlier revision of a file from repository to workspace directory.

5 Revision Comparison (aka. Diff / Delta): Comparison of line differences between workspace file and the latest repository file, or between any two revisions of the file.

6 Baseline Definition Capability and Reproducibility: Define (and name) a consistent set of file revisions as a baseline such that the same set of file revisions can be retrieved repeatedly.

7 Basic Build/Make Tool Support: Ability to transform the files in a workspace into a working build, using third party compilers/linkers/etc.

8 Basic File Merge Capability: Ability to merge differences between two files into a third file.

9 Basic Scripting (usually OS Scripting Language): Scripting capability which allows automation of build, retrieval of a set of files, basic information reporting.

10 Basic Branching Capability: Revision identification allows definition of branches within an otherwise sequential set of revisions of files. This allows parallel development/tracking of changes for a file.

11 Basic Branch/Revision Reports: Ability to report on existing branches and revisions of a file (file history), as well as the contents (i.e. file revisions) of a baseline.

12 Consistent Backup: Support for a consistent backup capability of the entire CM repository is supported.

Second Generation CM Requirements
Second Generation (2G) CM had peak usage in the 1990s-2000s, and moved CM solutions ahead significantly. As vendors struggle to reach 3G capabilities, 2G tools will continue to be used well into the 2010s. 2G CM tools begin to integrate more of the ALM suite into the solution. This includes Problem Tracking, Requirements Management and Change Management. In particular, change packaging is a significant move forward in the 2nd Generation, allowing changes to be viewed logically, rather than file by file. Today, the vast majority of CM solutions are based on 2G tools (though some still cling to 1G tools).

Key 2G CM Tool requiremetns include:

1 Unix and Windows Concurrent Platform Support: Support for clients must include, concurrently, both Unix/Linux and Windows platforms. Ideally, the same holds for servers, but this is not a hard requirement of 2G tools.

2 Scalability of Solution to hundreds of users: Hundreds of users are able to share a CM repository with reasonable performance characteristics, and ideally without having to partition the repository to have acceptable performance.

3 Change-packaging capabilities (aka. Updates, Changesets): Collecting files which implement a logical change into a permanently defined change package; the ability to check-in and do delta reports on a change package basis; the ability to promote changes, rather than files; the ability to define baselines based on change status rather than individual file status. Ideally, this capability is central to the CM tool and does not require a separate database/user interface to maintain change definitions.

4 Revisioning of Directory Structure: As product development evolves, the CM