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

by E.R. Williams

"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.


10 Proven Strategies Guaranteed to Improve your IT Project Success! What You HAVEN'T Been Told!

{ 1 trackback }

BloggersBase Business & Finance
February 16, 2011 at 5:10 pm

{ 1 comment… read it below or add one }

E.R. Williams January 13, 2011 at 8:40 pm

Thank you Bob,

I get many comments during my coaching sessions, at conferences and within networking groups, about understanding Configuration Management and the System/Software Development Life Cycle (SDLC). Once these individuals read: A Practical Guide to Understand and Apply “Software/Firmware Configuration Management” – Within the System Development Process, they began to understand how valuable it is to understand Configuration Management and the System/Software Development Life Cycle. Many also stated that additional information in this newsletter, was significant and reinforced the value of Configuration Management within the SDLC.

I appreciate you providing the link to the SOP.
After reading the SOP identified for Configuration Management and paying particular attention to the definition, it is not describing the Configuration Management that has been known for years in industries such as Aerospace and DOD. Configuration management is now being used (or attempting to be used) in the commercial IT industry.

Your SOP relates to a platform/infrastructure for environments (e.g., development, test, etc.). It is good information for that topic and releases supported by those environments but it is NOT “Configuration Management” as the industry knows it.

The book referenced above is an excellent source to understand Configuration Management, its definition and concept while also understanding the system/software development life cycle (SDLC).

Note: Understanding Configuration Management also provides you the process to identify product (system, software, etc) deliverables for the development life cycle.

First, here is the definition of Configuration;

“Configuration, the functional and physical characteristics of hardware, firmware, software, or a combination thereof as set forth in technical documentation and achieved in a product.”

Configuration Management begins with requirements.

In addition here are two related articles for further reading.

Understanding Configuration Management
Configuration Management Clarified

The former also identifies problems and issues and provides a solution to correct the problem of misunderstanding and the improper application of Configuration Management.

My comments are being provided because of my concern for individuals, organizations and companies not understanding CM, how to apply it and how it applies to the SDLC.

And Bob, CM and QA complement one another and without good CM and QA, planned and implemented for a program or project’s development process, the project and program will become troubled and/or fail.

Keep in touch because I provide coaching and mentoring. Click Here To Contact…

Previous post:

Next post: