Configuration Management

Software Configuration Management is a set of activities designed to control change by identifying the work products that are likely to change establishing the relationship among them, defining mechanisms for managing different versions of these work products, controlling changes imposed, and auditing and reporting on the changes made (Roger Pressman).

It consists of the following 4 activities:

1. Configuration Identification
2. Configuration Control
3. Configuration Status Accounting
4. Configuration Audits

Configuration Identification: Project teams (and also the SEPG, OT, OID, QAG teams) are required to identify the work products (in their respective teams) that need to be put under configuration control. Data required / used in a project can be placed under two categories: configurable and non-configurable items. Configurable items are those work products, which are likely to undergo changes and will have multiple versions at any given time during the project execution. Project plans, CM Plans, code, etc. are configurable items. On the contrary, data like emails, client chat scripts, audit reports, etc. do not change. They need not be version controlled. Such items are put under Data Management Plan.

Configuration Control: is the systematic evaluation, coordination, approval / disapproval and dissemination of proposed changes and implementation of all approved changes in the configuration of any item after formal establishment of its configuration baseline.

Change requests to process / products have to be routed through configuration control board (CCB) for approval before they can be used. Product change requests are analyzed for impact by the CCB. The mandated changes are implemented in the respective artifacts and then baselined. The CM issues a communication to the team on the baselined artifacts.

As the project advances, multiple versions of the baselined configurable items will exist. Configuration control is essential to keep the latest approved set (by CCB) of the work products floating. For code, it ensures that all developers work on the same baselined version.

Configuration Status Accounting: the recording and reporting of the configuration information is called configuration status accounting. This activity includes:

1. List of identified configurable items. (nos, and names)
2. Changes / Deviations / Waivers to configuration.
3. Implement status of approved changes. (configuration control status)
4. Version, baseline status

Configuration Audit: are necessary to verify that the integrity of work products is being maintained. Checks would be done on: baselining, configuration item identification, configuration control status, etc.

Run Charts and Control Charts

Run Charts

Run chart gives the trend of processes - its performance over a period of time; against previous performance. Run charts help in spotting aberrations in process performance and its progression over time. We can add an average line (parallel to the X axis) to the Y values to see the data deflection from average.

We can also have multiple run charts where the trends of process compliance of several projects can be compared.

Since run charts depict process trends, significant trends or patterns can be identified and investigated for the root causes. Similarly, special variations (significant deviant data points) can be spotted and their causes identified & addressed.

The above chart does not tell anything about the tolerance limits of PCI (that the organization would put up with). It merely tells us about the PCI trend for the months stated. So, without a guiding process performance limits, it is not of much use.

CMMI and ISO

ISO is a standard. Companies have to comply with standards. ISO has eight principle clauses.

CMMI is a process meta model. The process model is a guideline for organizations to improve their processes. CMMI is a collection of best practices in the s/w industry. CMMI tells you what to do, the HOW is left to the choice of the ogranization implementing it.

CMMI has 25 process areas (including IPPD, SS) as per v1.1

Common metrics for maintenance projects...

1. Client satisfaction index
2. Effort metrics
-Overall effort variance
-COQ
-COPQ
-Rework effort index
3. Schedule metrics
-Overall schedule variance
-On-time delivery index
4. Quality metrics
-Overall defect density
-Residual defect density
5. Performance metrics
-PCI of last audit
6. Support metrics
-FTR

Bi-directional Traceability

Traceabilities are of two kinds:

1. Vertical Traceability
2. Horizontal Traceability

Bidirectional traceability is tracing requirements both forward and backwards (in Horizontal) AND Top to Bottom, & Bottom to Top (in Vertical) through all the phases of software development lifecycle.

Vertical traceability is tracing customer requirements from requirements phase thru System Test / UAT phase and from System Test / UAT phase back to customer requirements phase. These traceabilities can be established if the requirements are well managed. Vertical traceability helps determine that all the source requirements have been completely addressed and that all lower level requirements and selected work products can be traced to a valid source.

Forward traceability ensures all requirements have been captured, while backward traceability ensures no additional functionality (gold plating) has not been introduced into the system.

If a requirement is added or withdrawn, the development team must be aware of the design elements / development modules / test cases, etc. where the impact would be felt and changes need to be carried out.

How does bidirectional traceability help?

1. To measure the impact of requirement changes. One requirement may spawn multiple design elements. In this case, each such design element should be traceable backwards to the same requirement.
2. To know that all requirements have been implemented in the system. (Forward traceability ensures this).
3. To ensure that no unwanted functionality has been incorporated into the system. (Backward traceability ensures this).

Vertical Traceability: Within a work product (BRS, SRS, HDL, LDL, Test Plan, etc.), the inter-relationships between various requirements is called vertical traceability. Each requirement is related to other requirement/s by virtue of functionality. Vertical Traceability ensures that all requirements have been captured, gaps in functionality have been identified, and that there is no duplication of requirements.