Concepts: Configuration Status Reporting
Topics
Definition 
Configuration Status Accounting (Measurement) – is used to describe the ‘state’ of the product based on the type, number, rate and severity of defects found, and fixed, during the course of product development. Metrics derived under this aspect of Configuration Management are useful in determining the overall completeness status of the project.
The four principle sources for software Configuration Status Reports are:
- Change Requests,
- Software Builds,
- Version Descriptions, and
- Audits.
Change Requests
A Change Request (CR) is a general term for a request to change an artifact or process. The general process associated with CRs is described in the process step ‘Establish Change Request Process’. However, the following outline of the CR process describes the states and statuses of CRs through their overall process.
- Submitted
- Logged
- Reviewed
- New
- Assigned
- Design
- Implement
- Verify/Test
- Integrate
- System_Test
- Completed
- Canceled
- Pending
The status ‘tags’ provide the basis for reporting CR (aging, distribution or trend) statistics as described under ‘Guidelines’ of this process step.
Change Request based defect reports fall under the following categories:
- Aging (Time Based Reports)
How long have Change Requests of the various kinds been open? What is the ‘lag time’’ of when in the lifecycle defects are found, versus when are they being fixed?
- Distribution (Count Based Reports)
How many Change Requests are there in the various categories by owner, priority or state of fix?
- Trend (Time and Count Related Reports)
What is the cumulative number of defects being found and fixed over time? What is the rate of defect discovery and fix? What is the ‘quality gap’ in terms of open versus closed defects? What is the average defect resolution time?
Build
Reports
Build Reports list all the files, their location, and incorporated changes that make up a build for a specific version of the software.
Build Reports can be maintained both at the system and subsystem level.
Version Descriptions
Similar to Release Notes, Version Descriptions describe the details of a software release. As a minimum the description needs to include the following:
- Inventory of material released (physical media and documents),
- Inventory of software contents (file listings),
- All unique-to-site ‘adaptation’ data,
- Installation instructions, and
- Possible problems and known errors.
Audits
There two kinds of audits that are covered in the context of Configuration Management:
- Functionality Audits, and
- Physical Audits.
The objective of the Functionality Audit is to verify that the actual performance of the software configuration item complies with its requirements. The following items describe what needs to be done from the CM perspective to support a Functionality Audit.
- Prepare a Verification Matrix that lists all functional requirements, and for each requirement references the test procedure, instance of test conduct (timestamp or other test instance identifier), corresponding test results and/or analysis and/or demonstration report which completely document the validation of the requirement.
- Verify that all change requests have been appropriately implemented.
- Verify that all changes to the software have been appropriately applied.
- Document discrepancies, establish corrective actions and completion dates.
The objective of the Physical Audit is to verify that artifacts baselined in the configuration management system are the ‘correct’ versions. The following items describe what needs to be done in support of a Physical Audit.
- Create a list of items that should be under Configuration Management (CM).
- Inspect items maintained under CM.
- Create a ‘discrepancy listing’ of what was maintained under CM versus what was supposed to be in CM.
