In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
The introduction of SCM into a project involves:
- Identifying a CM/ALM process to be followed
- Acquisition of tools to support CM/ALM
- Customization of the tools to support the process
- Training of personnel on the CM/ALM tools and process
- Training CM managers and administrators to support the process
- Sufficient quality management to ensure the process is being followed and is beneficial
Are these steps different today than they used to be? Not really. The steps are the same, but the cost and effort should be dramatically lower. If not, as a small or medium sized business, you need to look around more.
Identifying a CM/ALM Process
I remember back in the 1970s and 1980s spending a substantial amount of time
trying to derive the best CM processes. Back then, SCCS was the predominant model and that was nothing more than a version control tool with some branching capabilities. Combine that with Make files and we had a CM system, or so some thought. Fortunately I worked for larger telecom companies back then and had time to figure out that change packages were a necessity, that release stream-based development was the natural way for a telecom project to progress, and that version control (i.e., delta compression to a single file) was only a minor part, at best, of CM. One of the most successful proprietary CM tools of it's day, Mitel's Software Management System, was up and running for years before delta compression was even considered. When it was introduced, there was no change to the user interface, and no additional training, only disk space savings, significant though that was at the time.
We spent a lot of time understanding what was necessary and what was not. We introduced problem tracking, project/activity management, document management and tied them all together in with the rest of the CM system. After carefully considering how change packaging had to work and how baseline management could be automated from changes, we gradually built up our CM tools. They were completed to the level of true 2nd generation tools at a cost of well under a $1 million. And since they were in-house tools, we had the flexibility to change them to work the way we wanted.
Unfortunately, we were not primarily in the CM business. Though the benefits easily justified the costs, the tools eventually reached a level where the business case for continued changes was less and less clear. After all, the tool did what we wanted for the most part. So how could we justify a team for second and third level feature requests?
The good thing was that we were able to build a tool that matched the process elements that we had decided were crucial. From automating baselines, doing change-based configuration management, and ensuring proper traceability between changes and features/problems, to ensuring we had adequate reports showing us project progress, product quality (in terms of both problems found and test case results), we had a process that helped us to continually improve and tools that could be modified to support such improvements.
We didn't have starting points such as Sigma 6, CMM/CMMI, ISO 9001, or later frameworks. Instead, we had experience from previous projects and from earlier iterations on our current projects. We knew our processes and tools would have to survive decades of use and would have to scale up.