Software Configuration Management (SCM) Audits Part 2: Functional Configuration Audit (FCA)

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

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

Purpose of a Functional Configuration Audit (FCA)

According to the IEEE, an FCA is an audit conducted to verify that: [IEEE-610]

• The development of a configuration item has been completed satisfactorily
• The item has achieved the performance and functional characteristics specified
• Its operational and support documents are complete and satisfactory

An FCA is performed to provide an independent evaluation that the as-built, as-tested system/software and its deliverable documentation meet the specified functional, performance, and other quality attribute requirements.

An FCA is essentially a review of the system/software’s verification and validation (V&V) data to ensure that the deliverables are sufficiently mature for transition into either beta testing or production at the end of the development cycle. If FCAs are conducted at intermediate milestones, they review V&V data to ensure that the deliverables of each milestone are mature enough to transition to the next development phase depending on where in the life cycle the FCA 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 an FCA conducted at any baseline or major milestone.

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. For example, when evaluating whether the code implements all and only the documented requirements, a less rigorous approach would be to evaluate the traceability matrix, while a more rigorous audit might examine actual code samples and review the code against the allocated requirements.

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

Table 2 illustrates an example of a checklist and lists possible objective evidence-gathering techniques for each checklist item that would be used for an FCA conducted at the product/release baseline.

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