Configuration Management Clarified

I wanted to address a real problem that we in the IT industry seem to think has gone away. Understanding What Configuration Management (CM) is. As stated in Software/Firmware Configuration Management and in articles. ……. There’s simply no problem with explaining what CM is by discussing and addressing each of its processes/activities (no different than explaining the development process), but it’s wrong to address each of these processes/activities as if they are not part of the CM discipline.

Purchasers of the of the book have responded with not only that the book has been of value but now they understand that Configuration Management is more than just software version control and does include “Requirements Management”. Configuration management’s purpose is to document the system as it is being developed from requirements, through design, produced code, and then managing any configuration changes to the product/system and its related technical documentation. Software version control is a part of Configuration Identification and Control and not the primary/only concern. Why? Because before you have a product or component or module, created or in a library, you first had/have requirements and design.

Just because we have progressed to reusable code does not eliminate the first two processes or activities (i.e., Requirements Definition/Analysis and Design (Architecture and Detail). It does not matter if they are performed at some point in parallel, (when requirements are stable and agreed to), or as an iterative development process, they are still significant processes/activities for the full life cycle development process. And remember, requirements definition and analysis are the processes or activities that are required before any of the other processes are conducted (or when requirements are thorough enough and stable). How many disasters have we seen when requirements are reduced to being non-essential.
What do I mean by the above? When many discuss the entire life cycle or System/Software Development Life Cycle (SDLC), “best practices processes: PM, Development, QA, and of course CM ” must be performed as required. SDLC is an acronym that is identified as the system or software development life cycle, although the software development life cycle can be defined within or outside of the System Development Life Cycle. CM documents/specifies the development the product(s) during the entire life cycle until it becomes a deliverable product. The technical documentation mirrors the product, which allows configuration control to be applied. The following outlines the SDLC basic or typical processes/activities.

• Requirements (definition/analysis)

• Design (Architecture and Detail Design)

• Development/Construction: Code/Unit Test (programming and unit test)

• Testing (Integration/System Testing)

• Implementation (Deployment/Delivery)

• Support

• Maintenance

(Note: Some projects or programs have ended before Support and Maintenance are completed but all projects and programs should have been properly “Closed Out”.)
The CM process with its identified activities is a discipline that has prevented projects from failing. Each development process having CM implemented correctly using these activities as required, in the beginning, and throughout the product’s development have experience much success. CM is not just documenting for documentation sake, its concern again is for the product(s) and its full life cycle or project. The following are the processes/activities of Configuration Management:

• Configuration Identification
  (Which always gets confused with just identifying and controling a version(s) of software and documentation with some kind of reference or structure identification or number? But it is not just that, it begins with identifying and specifying requirements and design.

• Configuration Control

• Status Accounting

• Functional and Physical (or Design) audit and review

When each activity/process is not, or has not been, a part of the CM discipline/process, it has started a trend that allows many to misunderstand CM, misuse it processes, leave out processes when implemented, and out right misrepresent what Configuration Management is. One example is Requirements Management (and even Design Management). In the current IT environment many … seem to believe that requirements management is separated (because it has been) from CM. Taught out side the CM discipline. Which leaves one to think that it is not apart of the engineering discipline (i.e., CM) …but it complements the development process by providing documentation of the system, product, (description/mirror it) and its maturing development until it becomes a product (application, system, etc.), to be supported and maintained throughout it’s life cycle.

Configuration Management
The same problems that existed in the past continue into the 21st Century. It is the 2010, we still have the same problems with Configuration Management and Quality Assurance. CM and QA when interpreted and transferred into the commercial environment without its true meaning and implementation, was/is a disservice to the industry!