Configuration Management - Indus Net Technologies

We've been helping companies grow for over a decade! Check our success stories

x
buzz
 
back

Configuration Management

April 11, 2007 by Mainak Biswas under CMMi502 views
Share with your friends










Submit

Some of most frequently encountered problems in software development are faced due to poor configuration management practices such as:

  1. Previously fixed bugs miraculously reappear after latest update
  2. Development teams are working on separate versions of the code
  3. Changes implement earlier have miraculously disappeared
  4. A fully tested application stops working
  5. There is no way to trace the software requirements to the documents and deliverables.
  6. Software teams are using different versions of tools and resulting code is incompatible

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:

  1. How many changes have been received?
  2. How many changes approved / disapproved?
  3. How many have been implemented / pending implementation?
  4. What differences exist within successive baselines?

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

Share with your friends










Submit