1. Requirements

3.8.2 The project manager shall require the software developers and suppliers to provide NASA with electronic access to the models, simulations, and associated data used as inputs for auto-generation of software. 

1.1 Notes

The term electronic access includes access to the data from NASA facilities

1.2 HIstory

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

2. Rationale

NASA requires electronic access to models and simulation data used as input auto-generation of software developed by either suppliers or software developers to facilitate cases where inputs or models may require changes to produce the desired code results.  This access also accommodates the longer-term needs for performing maintenance, assessing operation or system errors, and addressing hardware and software workarounds.

3. Guidance

Auto-generated software is the result of translating a model of the system behavior into different software languages through the use of a code generator. It is important to capture the approach used for the automatic generation of software because issues can exist with auto-generated software and projects need to be prepared to address them.  “Users not only need to be sure that the code implements the model, but also that the code generator is correctly used and configured, that the target adaptations are correct, that the generated code meets high-level safety requirements, that it is integrated with legacy code, and so on."  ¹⁹³

The approach to auto-generated software is typically captured in project documentation such as the Software Development Plan.  Information can also be captured in project documentation relevant to the topic such as configuration management or verification and validation.

Suppliers and software developers provide electronic access to models and simulation data used as inputs to auto-generation software.

For recommended practices, considerations, and additional guidance related to auto-generated software, see Topic 8.11 – Model-Based Development and Auto-generated Code.

Additional guidance related to software tool accreditation may be found in the following related requirements in this Handbook:

4. Small Projects

No additional guidance is available for small projects.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.

7. Software Assurance

7.1 Tasking for Software Assurance

1. Confirm that NASA, engineering, project, software assurance, and IV&V have electronic access to the models, simulations, and associated data used as inputs for auto-generation of software. 

7.2 Software Assurance Products

• None identified at this time.

  Objective Evidence

  • Evidence of confirmation that NASA, engineering, project, software assurance, and IV&V have access to the models, simulations, and associated data used as inputs for the auto-generated software.
   Definition of objective evidence

  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

• None identified at this time.

7.4 Guidance

This requirement intends to provide the NASA software development team with direct access to the models, simulations, and associated data used as inputs for auto-generation of software. 

All software products acquired for NASA projects are to be made available in electronic format so they can be delivered accurately and used efficiently as part of the project. The electronic availability of the software work products, and associated process information, facilitates post-delivery testing that is necessary for assessing as-built work product quality, and for the porting of products to the appropriate hosts. Electronic access to software projects reduces NASA's project costs.

This access also accommodates the longer-term needs for performing maintenance, including defect repairs and software component augmentations, assessing operation or system errors, addressing hardware and software workarounds, and allowing for the potential reuse of the software on future NASA projects.

Software assurance personnel can determine whether the acquired software products are available in electronic format by checking with the software development managers to see if they are having any difficulties accessing any of the information they need. Some of the items that should be accessible are below. If there are any difficulties with access, these issues should be brought up with the project manager so they can be discussed with the contracting officer.

What Needs To Be Accessible?

• Auto-generation of software flight and ground software source code
• Models and simulations used to generate auto-generation of software source code
• Auto-generation of software prototype software, including prototype architectures/designs source code
• Auto-generation of software data definitions and data sets
• Auto-generation of software ground products source code
• Auto-generation of software build data
• Auto-generation of software test scripts