4.1.6 The project shall ensure that software configuration audits are performed to determine the correct version of the configuration items and verify that they conform to the documents and requirements that define them.
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
1.2 Applicability Across Classes
Classes C through E and Safety Critical are labeled, "SO." This means that this requirement applies to the safety-critical aspects of the software.
Class G is labeled with "P (Center)." This means that an approved Center-defined process which meets a non-empty subset of the full requirement can be used to achieve this requirement.
For software configuration, audits help ensure that configuration items (CIs) have been developed and completed in accordance with the documents and requirements that define them. Audits also help ensure that CIs achieve their performance and functional characteristics goals and that all associated operational and support documents are complete and meet their requirements. Audits also determine if all CIs that are supposed to be part of the baseline or release are actually in the baseline or release and are the correct version and revision.
Configuration audits provide checks to ensure that the planned product is the developed product.
There are two types of configuration audits: the Functional Configuration Audit (FCA) and the Physical Configuration Audit (PCA). Configuration audits are performed for all releases; however, audits of interim, internal releases may be less formal and rigorous, as defined by the project.
Audit plans, including goals, schedules, participants, contractor participation, and procedures are documented in the configuration management (CM) plan (see SWE-103).
When planning audits, it is important to remember that audits are samplings, not a look at every record. It is also important to remember that auditors should not have any direct responsibility for the software products they audit.
The basic steps in an audit are:
Additional audit topics to consider include:
- As coded, software products reflect their design.
- User documentation complies with standards as specified.
- Activities have been conducted according to applicable requirements, plans, and contract.
Consider the following options when deciding when to conduct audits:
- At the time a product is released.
- Prior to delivery to assure that all delivered products are complete, contain the proper versions and revisions, and that all discrepancies, open work, and deviations and waivers are properly documented and approved; can be FCA or PCA.
- At the end of a life cycle phase per Capability Maturity Model Integration (CMMI).
- Prior to the release of a new or revised baseline.
- As the project progresses to prevent finding major issues at the end when it's more costly to fix them and to identify systemic issues. such as meeting coding standards that could affect large segments of the project.
- Incrementally for very large, complex systems focusing on specific functional areas with a summary audit held to address status of all identified action items (FCA).
When reporting the results of an audit, it is important to remain unbiased and include positive observations as well as issues found. Findings are grouped as major or minor depending on the range and effect of the non-conformance.
Non-conformances result in corrective actions that address and correct the root cause of the non-conformances. Follow-up needs to be conducted to ensure the corrective actions were completed and are effective.
Consult Center Process Asset Libraries (PALs) for Center-specific guidance and resources related to configuration audits.
Additional guidance related to configuration audits may be found in the following related requirements in this Handbook:
Develop CM Plan
Software Configuration Management Plan
4. Small Projects
For projects with limited personnel, consider sharing lead auditors or audit team members among projects. Another suggestion is for members of small projects to conduct configuration audits of other small projects.
6. Lessons Learned
A documented lesson from the NASA Lessons Learned database notes the following: