Software Configuration Management Audits Part 3 – Physical Configuration Audits (PCA)
In the first part of this article, we introduced the three different types of Software Configuration Management Audit:
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:
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.
Invest in yourself and your career: Become a Software Excellence Academy's All-Access Member
Get access to:
领英推荐
______________________________________________________________
Upcoming Live, Online Classes from the Software Excellence Academy
Presented by Robin Goldsmith:
_______________________________________________________________
Upcoming webinars from the Software Excellence Academy:
June 2023 - Topic of the month is Teams
For more information about our webinars or to register for one or more of these webinars click here.
_____________________________________________________
The following webinar recordings are currently available for free on our website:
To watch these webinars click here and scroll down to the recordings.
_____________________________________________________
? 2023 Westfall Team. All Rights Reserved
If you have any other suggestions for checklist items that need to be added to either of my Physical Configuration Audit (PCA) checklists, please add them in the comments.