Tuesday, March 20, 2012

Agile Configuration Management (2): Towards a Practical Definition of Software Configuration Management

Although definition should be simplifying the concept, in case of Software Configuration Management, the definition is complicating the concept! Take, for example, this definition:

"A discipline applying technical and administrative direction and surveillance to (1) identify and document the functional and physical characteristics of a configuration item, (2) control changes to those characteristics, (3) record and report change processing and implementation status, and (4) verify compliance with specified requirements" - SEI CMMI Glossary

To complement this definition, SEI added references to 7 other definitions: configuration audit, configuration control, configuration identification, configuration status accounting, configuration item, product, and audit. What this effectively does is adding to the complexity of the definition!

On the other hand, there are some other definitions which are simple and to the point, and in the same time give a clear explanation of what Configuration Management means. It may not receive a unanimity among theorists that it is correct. However, in itself, it proposes a clear definition of CM, and I personally believe that they are excellent definitions. These are two definitions:

"Software CM is a discipline for managing the evolution of computer program products, both during the initial stages of development and during all stages of maintenance" - ANSI/IEEE standard 1042-1987 (withdrawn standard)

"In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software" - Wikipedia 

These two later definitions captures in simple terms the essence of Software configuration management as per its original intent. Building on this definition, I have added a 'Capability-oriented' definition, which defines SCM in terms of capabilities it adds to the team:

"Software configuration management enables the team to trace releases, work-items, and work products to each other"


A strong SCM environment empowers the team to relate workitems (what has been done) to work products (artifacts of work done) to releases (packaged and delivered software products). This is what I describe as a 'Strong configuration management environment'.

Implications of this definition is huge. It means that the team may instantly know the history of a workitem (say  a bug), when it was released and which artifacts or code changed due to it. The team may also know every thing about a specific release to a customer, which bugs or user stories were included, and what code files or documents delivered as part of this release.

No comments: