bannerb

This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C

SWE-045 - Project Participation in Audits

1. Requirements

3.13.2 The project manager  shall participate in any joint NASA/supplier audits of the software development process and software configuration management process.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

Classes F and G are labeled as "X (not OTS)" which means that the project is required to meet this requirement for all software that is not considered off-the-shelf.

Class

     A      

     B      

     C      

   CSC   

     D      

   DSC   

     E      

     F      

     G      

     H      

Applicable?

   

   

   

   

   

   

   

   

   

   

Key:    - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.

2. Rationale

Per IEEE STD 1028-2008, Software Reviews and Audits, "The purpose of a software audit is to provide an independent evaluation of conformance of software products and processes to applicable regulations, standards, guidelines, plans, specifications, and procedures." 219  Audits are part of the supplier/provider monitoring activities performed by the acquirer 224, but may also be external audits, internal audits, or some other type of audit.  

In order to avoid surprises resulting from audits, project personnel need to know ahead of time that an audit will be occurring.

Audits are conducted by audit teams and require the participation and cooperation of the personnel involved with the software being audited, both acquirer and provider personnel, including contractors, as appropriate for the particular audit being performed.

3. Guidance

This requirement is not intended to force joint audits, but when audits occur, the project needs to be made aware of and participate at some level in those audits, whether they are internal audits, contractor audits, external audits by an independent organization, or any other type of internal or external audit. Project participation can benefit the audit by providing domain knowledge, planning assistance, and technical expertise to the audit team.

This requirement was written to require projects to participate in audits that include any or all of the software portion of a project. The project's participation can take many forms, including, but not limited to, simply keeping abreast of the audit's progress as well as participating as an observer in the actual audit.

If these audits involve a software supplier, requirements to allow acquirer project personnel to participate, as described above, need to be incorporated into the contract because the contract is the binding document for contractor performance and deliverables. "The supplier shall conduct or support ... informal meetings, acceptance review, acceptance testing, joint reviews, and audits with the acquirer as specified in the contract and project plans." 224 Therefore, this NPR 7150.2 requirement needs to be considered during the earliest phases of a project when the Request for Proposals (RFP), the Statement of Work (SOW), and the contract are being developed.

It is the responsibility of the project to make available appropriately prepared and qualified project personnel to participate or support audits as needed to fulfill the project's chosen level of involvement, including software assurance personnel described in the project's software assurance plan (see NASA-STD-8739.8, Software Assurance Standard 278,  for software assurance involvement in audits).

Consult Center Process Asset Libraries (PALs) for Center-specific guidance related to joint audits, particularly Project Monitoring and Control (PMC) documentation.

See the Topic 7.3 - Acquisition Guidance in this Handbook for additional guidance. Additionally, guidance related to joint audits may be found in the following related requirements in this Handbook:

SWE-022

Software Assurance

SWE-037

Software Milestones

SWE-038

Acquisition Planning

SWE-084

Configuration Audits

Topic 7.18 

Software Assurance Plan

4. Small Projects

For projects with limited personnel, consider limiting the audit participation to monitoring progress and reviewing the results as this would causes less interference and requires fewer personnel.

5. Resources

5.1 Tools

Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.

No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.

6. Lessons Learned

The NASA Lesson Learned database contains the following lesson learned related to joint audits:

Acquisition and Oversight of Contracted Software Development. Lesson Number 0921: "The loss of Mars Climate Orbiter (MCO) was attributed to, among other causes, the lack of a controlled and effective process for acquisition of contractor-developed, mission critical software.  NASA Centers should ... assure ... verification of the adequacy of the software design approach and overall contractor implementation throughout the software life cycle."  Audits are one way to assess the adequacy of contractor implementation throughout the software life cycle." 528

  • No labels