Some of most frequently encountered problems in software development are faced due to poor configuration management practices such as:
Configuration management falls under the category of Support process group of CMMI and falls at Level 2 in staged representation. In essence it is a discipline of establishing the integrity of the work products through proper identification, accounting, auditing and control. Here are the key things involved in this discipline:Â
Identifying Configuration Items
Configuration items are identified at the very onset of the project. These typically include work products that are delivered to the customer, internal work products, acquired products, tools and intermediate work product that support the development effort. The following items are generally configurable items: Requirements specification, Architectural specification, Design specification, Code modules, Test data and plans, Project plan, Quality plan etcÂ
Setting up a Baseline
Establishing a baseline is most important part of configuration management discipline. A baseline represents an approved snapshot of the system at appropriate points in a system life cycle. A baseline serves a platform for further development. This is because before a baseline is established, change can be made informally but after establishing a baseline, change can only be made using a formal procedure.
There are two important terms in respect to a baseline i.e. Build and Release. A baseline that is used for internal development is called a Build whereas a baseline that is delivered to the customer is called a release.
Change Control
As stated earlier, once a baseline is established the only way to make amendments to the “baselined†work product is through formal change requests. Each change request is recorded formally, their impact is evaluated, and they are formally reviewed and then tracked to closure. Changes are generally approved by a change control board (PM can also be a member of the group) and this ensure that adhoc changes are not made to the system.
The change history of each work product should match its current baseline version. This helps the management to answer questions such as – what features has been added to the work product between release 1 and release 2? Often regression testing is also done on the configuration items to ensure that there are no unintended consequences on other configuration items.
Configuration Status Accounting
Configuration status accounting is quite similar to the financial status accounting in a sense it tells about the inflows and outflows that has resulted in the current state of the project.
With a status accounting, the management should be able to answer questions like:
Auditing the Configuration
Finally, the system is audited, mostly prior to customer delivery to ensure that all change requests have been resolved and that the system contains only the work products that are required and nothing more. This is done by comparing the documentation (SRS, Manuals etc) to the product to ensure that it is ready for delivery.
Word of Advice!
Configuration Management is discipline in itself that requires infrastructure, effort and cost. Thus, these activities should be included in the original project plan itself otherwise it might seem like an overhead to do them later and the organization will make a costly mistake of ignoring this discipline
