Invalid license: Your evaluation license of Refined expired.
bannerd

A. Introduction

B. Institutional Requirements

C. Project Software Requirements

D. Topics

E. Tools, References, and Terms

F. SPAN
(NASA Only)

UNDER CONSTRUCTION

In this example, the Div bodies were distributed into child pages. Click on a link in one of the cells in the row below to open the content. 

1. Requirements2. Rationale3. Guidance4. Small Projects5. Resources6. Lessons Learned7. Software Assurance
This page contains macros or features from a plugin which requires a valid license.

You will need to contact your administrator.

7. Software Assurance

SWE-961 Coding Standards - Requirements
4.4.3 The project manager shall select, define, and adhere to software coding methods, standards, and criteria.

7.1 Tasking for Software Assurance

From NASA-STD-8739.8B

1. Assure the project manager selected and/or defined software coding methods, standards, and criteria.

2. Analyze that the software code conforms to all required software coding methods, rules, and principles.

7.2 Software Assurance Products

  • Static analysis of the source code to a coding standard

The SA independent analysis of the software code to the software coding standard, including any risk or issues.


Objective Evidence

  • Coding standard (Secure coding standard)
  • Results of static code analysis showing compliance with the project's coding standard

Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

7.3 Metrics

  •  # of coding standard violations identified (Open, Closed, type of violation, Severity)
  •  # of software process Non-Conformances by life cycle phase over time

See also Topic 8.18 - SA Suggested Metrics

7.4 Guidance

Task 1: Review the project software development/management plan to learn what kind of software coding standards, methods, rules, and principles are used for the project. The coding standards could include any project-defined standards that dictate the safe use of code, secure coding standards, reliability coding standards, etc.  They may also include a set of “principles” or best practices that have been collected for particular software applications, such as principles for developing flight software. These coding standards and principles are reviewed by software assurance during the development and selection of the project processes, as per SWE-013 - Software Plans. After becoming familiar with these standards, practices, and principles, analyze the software code using the static analyzers' results to help determine whether these standards, methods, and principles are being used consistently. Any risks or issues should be brought up with project management.

Task 2: Software assurance will perform independent static code analysis on the coding standard practices, methods rules, and principles. They should review the results of the static code analysis runs to determine whether the project's coding standards, etc., are being followed. Results should be reported to the project management at the end of the analysis. Information on code standard usage, static code analysis tools, their effectiveness, and the developers’ responses to the results should also be shared with the project management.

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

Related Links

Unable to render {include} The included page could not be found.

Unable to render {include} The included page could not be found.



  • No labels
Page Editor: Tim Crumbley
NASA Official: Tim Crumbley
Accessibility
NASA Software Engineering Handbook - A service of the NASA Office of the Chief Engineer
NASA Privacy Statement
______________________________________________________________________________