Website Development – Configuration Items

Website Development – Configuration Items

Configuration Items

· Configuration Items: A project has a number of software items. Software items could be documents or code. Typically, in projects this includes the design document, test plans, code, SRS, user manual, etc. Among these software items, the project would like to define some or all of them as configuration items. The difference between a software item and a configurable item is that changes to configurable items are tracked. For software items that are not defined to be configuration items, changes are not necessarily tracked. The configurable items for a project are identified and defined in the project’s CMP. Care should be exercised on selecting the configuration items for a project.

· Guidelines for Selecting CIs:

1. All customer supplied items

2. All customer deliverables in a project should be defined as configurable items.

3. The target environment for software deployment (versions of software, hardware, tools, etc) should be defined in the Release Note before delivery.

4. The PP and test plans, whether deliverable items or not, should be defined as a CI.

5. In addition to this, you could optionally define any other software item of importance as a configurable item.

· Events: An event pertains to the completion of a task or activity. A software item (like design document, code, SRS, etc), becomes a configurable item once this event occurs. The event that brings a software item into Change Control is project dependent. Typically, events that make a software item configurable are ‘acceptance by customer’, ‘approval by project manager’, ‘release of code to the customer for acceptance testing’, etc. Hence, such events should be clearly stated in the PP for the project. Before the occurrence of this event, the software item does not come under Change Control. In simple terms, this would mean that the item does not get entered into the Configuration Item Index, Baseline and the Release Log. Also, changes to the item are not tracked.

· Guidelines for Defining Events: Events should be defined in such a manner that it is beneficial to the project. Events should not be defined to make the configuration management process a burden on the project. The overruling factor would be this question – when do I start tracking changes to the software item? In projects having external customers (as opposed to internal customers), changes to the software item should ordinarily be tracked after the software item gets accepted by the customer. Tracking changes to the software item before the occurrence of this event is of no use to the company. Changes to a software item tracked after the customer accepts the software item would mean added costs and the customer would need to pay for these changes. Hence tracking changes would be beneficial and mandatory on occurrence of this event. For internal customers (internal projects), typically the event would be ‘On acceptance by the project manager’.

· Use of Baselines: The main purpose of maintaining a baseline is to identify the versions of the configuration items that are in sync with each other. For example, it would be important to know which version of the SRS document is in sync with which version of the HLD document. This is especially true if multiple versions of these documents exist in the project. To track this ‘configuration of versions’ of the configuration items within the project, baselines are defined.

· Events for creating baselines: Just like in the case of configuration items, Baselines are created on occurrence of events. The event that leads to the creation of a baseline is when the project reaches a milestone. For the initial baseline, it is the start of the project. For the release baseline, it is the end of the project. For intermediate baselines, it is a “major change in the scope of the project leading to a change to more that 50% of the CIs”.

Create Baseline Records

Back to the LinksMultiple eBay Auction | eBay Shopping home page