Website Development – Configuration Identification

Configuration Identification & Accounting

Objective

The objective of this procedure is to identify the Configuration Items (CIs), establish libraries and Baselines based on what has been defined in the Configuration Management Plan and to track status of CIs after they have been released and brought under Change Control.

Scope of the Procedure

This procedure applies to all the configuration items identified by , which includes offshore as well as on-site. Deviation wherever necessary must be authorised in writing by the Project Head.

Users of the Procedure

This procedure is intended for personnel involved in the management, facilitation, and support of software projects. Such persons may be Project Head, Head Quality, Project Managers, and Project Leaders.

Entry Criteria

· Configuration Items are to be identified

· Baselines are to be identified

· Dynamic and Control libraries are to be identified

· Mapping of Configuration Items to Baselines needs to be done

For status accounting, any of the following criteria should be satisfied

· The event as defined in CMP that brings the Configurable Item under Change Control should have occurred.

· The event as defined in CMP that brings a Baseline into existence should have occurred.

· A Change Request has been raised.

Process Description

Identify Configuration Items (CIs)

All CIs have to be identified in the Configuration Management Plan (CMP). The Configuration Items should have the names as defined in the Configuration Management Plan (CMP). Along with the identification of the CI, the event that would bring the CI under Change Control should be defined in the CMP. Refer Appendix - A1: Check-list for Configuration Items (CIs)

Identify Baselines

A project should have a minimum of two baselines. These baselines are called “Initial” and “Release” baselines. In addition to these baselines, a project could have one or more intermediate baselines.

Initial Baseline: This is the baseline that is created at the start of the project. This baseline defines the configuration items that form the basis for the project. Typically, this baseline will list the documents supplied by the client at the start of the project. Such documents include RFPs, proposals with detailed specifications, specification documents, design document, hardware and software configuration, etc. Once created, the baseline should never be modified.

Release Baseline: This is the baseline that is created at the end of the project. This lists all the configuration items that are in sync at the end of the project - it includes the items under the initial baseline and the configuration items that get created during the course of the project. Thus this baseline includes the client supplied documents and project documents like SRS, HLD, LLD, Test Plans, code, user manual, etc.

Intermediate Baselines: The main guiding factor for having an intermediate baseline is a major change in the scope of the system or application, resulting in changes to more than 50% of the Configuration Items. In such an event, typically the development work stops and all CIs, created until that point, are examined to determine the effect of the change in scope. A complete backup of the current versions of the configuration items is taken. Work on updating the CIs is taken up after this. All CIs are brought up to date and tested / reviewed for synchronization among the CIs. Then a new intermediate baseline is opened. All the CIs along with their latest versions are entered into the intermediate baselines. Creating intermediate baselines is entirely the project manager’s call. Configuration items that get created after the intermediate baseline should not be entered into this baseline. In other words, once created, the intermediate baseline should never be modified.

Configuration Items

Back to the LinksMultiple eBay Auction | eBay Shopping home page