Why CM? What is the SDLC? System/Software Development Life Cycle Process Explained

“I was still having problems with understanding Configuration Management but after reading your book, I do know why I was having difficulties with the entire development life cycle focusing only on software version control and software library development.”

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” and supports the SDLC.

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)). 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 (such as Agile), they are still significant processes/activities for the full life cycle development process.

For the SDLC, an appropriate development methodology is determined to be used for the project or program. That methodology may be traditional or Agile, or a combination of both. There are no “silver bullets, and each methodology will have gaps based on the particular project or program. Each must have a process and feedback mechanism for improvement. We have moved on from just traditional methodologies with modular, iterative and incremental development processes but remember as the book states, “For iterative and incremental development there must be points of control. If not, the customer/user would not know what is being developed or be in agreement with what is being developed or produced. Which is usually costly for both! However, it doesn’t prevent an activity (or phase) from overlapping or being performed in parallel, as long as documented and agreed to requirements exist.”

Remember, requirements definition/analysis 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(and software) 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 a software development life cycle. Typical System/Software/Product Life Cycle processes or activities:

• Requirements
• Design

1. Architecture (High Level Design)
2. Detail Design (Note: if you are developing a “true” system you would have the System Requirements and Design Processes/Activities which would allocate processes/activities that develops the software and hardware components/subsystem. The currently used SDLC for software or application development in the commercial IT environments (and now other industries) is a perspective of the system development process (see system/software diagram below).

• Development/Implementation/Construction

1. Software – Programming/Coding/Unit Test/Integration/Software (system) Functional Test
2. Hardware -fabrication/Unit/Component Test/Integration/Hardware Qualification/Functional Test
3. System Integration/System Functional Test (note:  currently in many commercial IT system/software testing environments QA in conducting/performing Integration and Functional testing)

• Delivery/Deployment/Production
• *Support
• *Maintenance
• Retirement

(*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 system/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) and its maturing development until it becomes a product (application, system, etc.), to be supported and maintained throughout its life cycle.