A Physical Configuration Audit (PCA) identifies the components of a product to be deployed from the Project Repository.  Steps are:

• Identify the baseline to be deployed (typically just a name and/or number, but may also be a full list of all files and their versions).
• Confirm that all required work products, as specified by the Development Process, are present in the baseline.  List missing work products in the Configuration Audit Findings.

Other Levels of Physical Configuration Audit

Some organizations use a Physical Configuration Audit to confirm consistency of design and/or user documentation with the code.  The Rational Unified Process recommends that this consistency checking be performed as part of the review activity throughout the delivery process.  At this late stage, audits should be restricted to auditing that required deliverables are present, and not reviewing content.

A Functional Configuration Audit (FCA) confirms that a baseline meets the requirements targeted for the baseline.  Steps for performing this audit are:

• Prepare a report which lists each requirement targeted for the baseline, its corresponding test procedure, and test result (pass/fail) for the baseline.  
• Confirm that each requirement has one or more tests, and that all tests of the requirement have passed.  List any requirements without test procedures, and requirements with incomplete or failed tests, in the Configuration Audit Findings. 
• Generate a list of CRs targeted for this baseline.  Confirm that each CR has been closed.  List any CRs which are not closed in the Configuration Audit Findings.

If there are any discrepancies, then these are captured in the Audit Findings as described above.  In addition, the following steps should be taken:

• Identify corrective actions.  This may require interviewing various members of the project team to identify the source of the discrepancy and appropriate corrections:
• • For missing work products, the appropriate action is typically to place the work product under configuration control, or to create a CR or task to create the missing work product.
  • For untested or failed requirements, the requirement may be targeted to a later baseline, or negotiated for removal from the set of requirements.
  • For un-closed CRs, the CR may simply need to be closed, or it may need further testing, or deferred to a later baseline.
    
• For each corrective action, assign responsibility and determine a completion date.