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.
are a useful piece of the puzzle. Some of the more advanced tools will drag the industry along as competitive differences are addressed by the vendors. But we're a long way from what I might want to label a real CM standard.
Another approach that I've been looking at for the past year or so has been the possible adoption of existing standards from the hardware side of things. In looking around, the CM II standard from the Institute of Configuration Management (ICM) is interesting. It clearly addresses a need on the hardware side: the production of hardware must flow from the documentation. This basically means that parts are not version controlled, but rather only the documents are.
Looking more carefully at this standard, I could not accept that software modules would not be version controlled, but had no problem saying that builds, or more precisely the deliverables that come out of the build process, are not version controlled. Software really tends to be dual-natured, both documentation and, in some cases at least (e.g,. Perl scripts), deliverable.
Looking at CM II more carefully, there are also a number of other key elements. A user interface element called the "baseline view" allows specific frame by frame advance of what the differences are as each engineering/enterprise change notice (ECN) is applied. CM II does not dictate the full functionality of this view, but does identify some key properties it must have. Similarly, for processes and roles, it identifies key elements that must be present: change specialists, users, etc.; change control boards (CCBs); and change implementation boards (CIBs). It also identifies some key data elements that must be tracked: ECRs, ECNs, problem reports, work orders, waivers, etc., identifying some of the key properties of each, and even the workflow of them, without limiting the definitions.
It's not a simple task, but the CM II process can be mapped onto the software world. No vendor has done this to date (at least not publicly), even though there are a number of CM II tools for hardware. I expect one or two software vendors to take on this task in the next year or two. If so, we might have the makings of a software CM standard, or perhaps the framework on which one could be built.
Perhaps the most important quality process that applies to software CM has been the CMM/CMMI from SEI (at Carnegie Melon University, also known as CMU). The industry is fairly well-versed in the capability maturity model (CMM). If nothing else, this model has allowed us to broaden the definition of CM so that the model may be more fully supported from the enterprise CM backbone. Some CM tools can be customized to provide CMM-specific