Article Keywords: Software Development Life Cycle | Understand Definition of Configuration Management | system development life cycle | SDLC

Those who have purchased the book, (Management Control and Quality! - Software/Firmware Configuration Management - available in e-book and soft cover), have responded with not only that the book has been of value but understanding that Configuration Management is more than just software version control and does include “Requirements Management”. Configuration management’s sole purpose is to document the system from requirements and include design and code and then managing any configuration changes to the product/system and its related documentation. Software version control is a part of Configuration Identification and Control and NOT the primary concern. Why, because before you have a product or component or module, created or in a library, you had to 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)). And it does not matter if they are done 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 are the processes or activities that are required before any of the other processes are conducted. How many failures have we seen when requirements are reduced to being non-essential? What do I mean by that? Well, when many have discussed the entire life cycle, (or SDLC), to develop applications, often times Configuration Management is not discussed or implemented to understand the entire process. SDLC is an acronym that is defined as the system development life cycle, although the software development life cycle can be defined within or outside of the System Development Life Cycle. That is sometimes why SDLC is defined also as software development life cycle.

• Requirements
• Design (Architecture and Detail Design)
• Code
• Testing
• Implementation
• *Support
• *Maintenance

(*Note: some projects or programs have ended before Support and Maintenance processes/activities have been completed but all should have been properly “Closed Out”.) *Click here to download a diagram of the software development life cycle (.pdf). Many businesses and organizations use CM Documentation and others as just version control of software during the SDLC. The CM process with the following identified activities is a discipline that has prevented a many failed project. Each development process having CM implemented correctly will increase the probability of project success. Using CM activities to some degree in the beginning and throughout the products life cycle when you have requirements will provide a project/program with the possibility of success. CM is not just documentation, (for documentation or data management sake); its concern, again, is for the products and its full life cycle.

• Configuration Identification (This always gets confused with simply identifying and controlling a version of software with some kind of reference or structure identification or number. But it is not just that, and those that understand and know configuration management (read Management Control & Quality - Software/Firmware Configuration Management and the related configuration management articles), don’t struggle with implementing the discipline as many do.)
• Configuration Control
• Status Accounting
• Functional and Physical (or Design) audit and review

Based on the number of failed projects you would think that these processes or other activities/processes are not, or have not been, a part of the CM discipline/process. The serious mistakes of the past, have begun, a trend that allows many to misunderstand CM, misuse its processes, leave out processes when implemented, and out right misrepresent Configuration Management. 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 Configuration Management. It has been emphasized and taught outside the CM discipline. Which leaves one to think that it is not apart of the engineering discipline (i.e., CM). I will end with this. Remember that Configuration Management complements the development process by providing documentation of the system, product, (description/mirror) and its maturing development until it becomes a product (application, system, etc.), to be supported and maintained throughout it’s life cycle.