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

of the product manager, project managers, and configuration manager. Dashboards should present appropriate summary information into which the user can drill down to get additional information.

Fourth Generation CM/ALM Requirements
The future of CM/ALM tools is in the fourth generation (4G). Although peak usage for these tools may not be attained until well into the 2020s, there will be at least one 4G tool available before the end of the decade. If you are looking at tools, an understanding of 4G requirements will help you to measure existing tools and their potential to evolve. As well, many tools already meet some 4G requirements.

4G Fourth Generation CM Tools (peak usage forecast 2020s-2030s)

1 Small Footprint: Despite growing hardware capabilities, a small footprint for a CM/ALM tool is a strong indicator of vendor longevity. It is also a strong indicator of tool simplicity, which is ever more important and functionality continues to increase through the generations.

2 Zero Administration Operation: For the most part, an administrator is not required for a 4G tool. A part-time administrator may be required to deal with specific issues (e.g. applying an upgrade), but these should be intuitive and require minimal manual intervention other than high level directives (e.g. verify synchronization of all sites).

3 Scalability to thousands of users per server/platform: A 4G system must support thousands of users across an enterprise, as organizations begin to consolidate multiple projects/products into a single respository to leverage re-use, process engineering and data mining.

4 Fully Synchronous Multi-site: Multiple sites must be able to synchronize themselves without manual intervention. Near-zero maintenance should apply even to distributed development support. Automatic recovery from network outages must be supported. Data segregation (e.g. ITAR) must be fully supported within the framework of having multiple sites.

5 Full Interoperability between 32- and 64-bit platforms. As a mixture of platforms will persist for quite a while, especially across geographic sites, the 4G tool must support full interoperability between 32 and 64 bit platforms. There must not be any significant effort required to switch a server or a client between platforms, and each must be able to concurrently interoperate with the other.

6 Unified Configuration of all Native and Web interfaces: In cases where the web interface technology is different from the native platform interface, it must be possible to use a single configuration specification for those parts of user interface common to both web and native platforms.

7 Server-only Installation (only trivial Client Upgrades Required): Visible client installation (other than establishing a short cut or other reference to the 4G tool) must be absent. Client side upgrades must follow directly from the central server(s) upgrade, without any client-side intervention.

8 Trivial Bulkloading and Multiple Revision/Baseline Bulk-loading: It must be possible to load in software trees by a simple drag-and-drop, copy/paste or other such trivial mechanism, although additional supporting details may be queried as part of the operation. It should be possible to bulk load multiple baselines of a source tree such that the history between the baselines, and between the individual items within the baseline, are maintained.

9 Fully Automated Configuration Management: Configuration management tasks should be reduced to high level requests. Tedious tasks such as labelling, creating baseline definitions, establishing context views, creating promotion views, etc. must be fully automated, subject only to the parameters required by the high level requests. Users, including the CM managers, should focus only on Change management.

10 Bulk Build/ANT/Make File Generation: Automatic generation of Makefiles, Build scripts, ANT files should replace the need to have to create and maintain such files. Generation of the files should proceed