CM: THE NEXT GENERATION - Beyond CM to ALM

In software, it's much the same.  You can have an engineering team with great version control and even CM tools produce a great application.  But if the verification team, the documentation team, the marketing team and the project management team aren't on board, the great application may never see the light of day.   The whole team has to be involved.  The application has a life cycle, from conception to retirement, the application life-cycle, and it has to be managed - ALM.

Perhaps when there was less market pressure, or fewer applications and products, with far fewer computers, it was fine to focus on the software design and implementation. In those days of old, managing the new flexibility and capabilities afforded by software was the big challenge.  But we've come a long way since then.

The First Generation
In the early days of software, the late '60s and early '70s, a new capability known as Version Control (VC), or Source Code Control (SCC) evolved on a number of different fronts including IBM (for their mainframe code), AT&T (for their Unix code and telecomm product code), and DEC (for their own PDP and VMS software).  

I believe the IBM product was called Update (or some variant thereof - anyone remember the name?).  It captured updates to be applied to a file, and so maintained a capability for retrieving files with any number of updates applied.  Digital's product was known as CMS, for Code Management System.  And AT&T's Unix tool was SCCS (Source Code Control System).  Perhaps some of you have been exposed to all of these.  They were the forerunners of the current CM tools.  SCCS in particular was very widespread in the Unix world and made its way over to VMS as well.

A number of other VC tools evolved over time: RCS, PVCS, CMVC, etc.  They dealt primarily with 4 basic functions:

• Save/retrieve revisions (i.e versions) of source code
• Creation of baselines
• Checkout/checkin functions
• Branching of source code files

In addition, the Make utility, and other similar capabilities evolved so that the code baseline, once retrieved from the version control database, could be built in a repeatable fashion.  Other tools, such as diff and merge/diff3, evolved to support workspace management, including peer reviews of changes in your workspace, and merging parallel changes into your workspace.

This was the first generation of what soon came to be called (software) configuration management tools.  The goal was modest and easily accomplished.  Version control continued to evolve for many years with schemes to improve retrival time when there were numerous revisions, capabilities to track checkouts, and the ability to add comments to each revision.

Remember, there were command line interfaces, but no GUI interfaces at the time.    You had to be a techie.  You were interested in your edits - preserving them and getting the right revisions checked in.  The big goal was to allow builds to be done from the version control system, without using any files from user's disks/directories.

From VC to CM, the 2nd Generation
Late in the '80s after a couple of decades of using the VC tools with various scripts, second generation tools started to take shape.  Not very quickly though.  A few private systems, notably PLS at Bell-Northern Research, and SMS at Mitel Corporation, gave some of the direction for future systems, especially in terms of change packaging and change management.  These were the forerunners of today's CM+ product (Neuma).

But one of the best liked systems of the time was called DSEE, the forerunner of ClearCase (IBM), made for a specific workstation named Apollo.  The entire