Software Configuration Management (SCM) Audits Part 3: Physical Configuration Audit (PCA)

In the first part of this article, we introduced the three different types of Software Configuration Management Audit:

• Functional Configuration Audit (FCA)
• Physical Configuration Audit (PCA)
• In-Process SCM Audits

We also talked about when these audits occur in the software development life cycle. The second part of this article focused on Functional Configuration Management Audits.

This third part of the article talks about Physical Configuration Audits (PCA) and their purpose. It will also provide examples of checklists that could be used during PCA evaluations and suggests evidence-gathering techniques for each item in those checklists.

Purpose of a Physical Configuration Audit (PCA)

According to the ISO/IEC/IEEE Systems and Software Engineering— Vocabulary (ISO/IEC/ IEEE 2010), a physical configuration audit (PCA) is “an audit conducted to verify that each configuration item, as built, conforms to the technical documentation that defines it.” A PCA verifies that:

• All items identified as being part of the configuration are present in the product baseline
• The correct version and revision of each item is included in the product baseline
• Each item corresponds to the contained in the baseline’s configuration status report

A PCA is performed to provide an independent evaluation that the software, as implemented, has been described adequately in the documentation that will be delivered with it and that the software and its documentation have been captured in the software configuration status accounting records and are ready for delivery. Finally, the PCA may also be used to evaluate adherence to legal obligations, including licensing, royalties, and export compliance requirements.

Like the Functional Configuration Audit (FCA), a PCA is conducted at least once during the life cycle, typically just before the final ready-to-beta-test or ready-to-ship review, and provides input information into those reviews. However, PCAs can also be conducted throughout the life cycle at checkpoints to verify the proper transition of the requirements into the subsequent successor work products. The PCA is typically held either in conjunction with the FCA or soon after the FCA (once any issues identified during the FCA are resolved). A PCA is essentially a review of the software configuration status accounting data to make certain that the software products and their deliverable documentation are appropriately baselined and properly built prior to release to beta testing or operations, depending on where in the life cycle the PCA is conducted.

Checklist Item Suggestions for Evidence-Gathering Techniques

Table 1 illustrates an example of a checklist and lists possible objective evidence-gathering techniques for each checklist item that would be used for a PCA conducted at any baseline or major milestone.

Table 2 illustrates an example of a checklist and lists possible objective evidence-gathering techniques for each checklist item that would be used for a PCA conducted at the product/release baseline.These checklist items would be used in addition to the checklist items in table a.

While several suggested evidence-gathering techniques are listed for each checklist item, the level of rigor chosen for the audit will dictate which of these techniques (or other techniques) will actually be used.

Table 1 – Example Checklist and Evidence-Gathering Techniques Used During Any PCA

Table 2 – Example of Additional Checklist Item and Evidence-Gathering Techniques Used for PCA at Product/Release Baseline