bannerc


(info) This section contains special features and topics which contain material that is broader than any one Software Engineering requirement. Many take the form of how-to's and tutorials for those wishing to learn about the state of software engineering within NASA.


For Frequently Asked Questions see the page: FAQ - Engineering, Assurance, and Safety

D. Topics

  

7.1 - History and Overview of the Software Process Improvement (SPI) EffortAddresses the history of the NASA software improvement efforts to provide a background for the development of this electronic handbook

7.2 - Software Classification Definitions and Software Safety-Criticality Determination - Aids to help those responsible for determining the software classification and the software safety criticality

7.3 - Acquisition Guidance - Guidance for projects implementing those requirements in NASA Procedural Requirement (NPR) 7150.2, NASA Software Engineering Requirements that address software acquisition. 

7.4 - Flowdown of NPR Requirements on Contracts and to Other Centers in Multi-Center Projects - Provides suggestions to the software lead for levying the Agency-level requirements contained in NPR 7150.2 to contracts and multi-center projects

7.5 - Work Breakdown Structures That Include Software - Provide guidance on the development of a work breakdown structure (WBS) for software on projects. 

7.6 - Software Test Estimation and Testing Levels - Provide guiding principles and best practices pertaining to software test estimation and a description of the typical "levels" of testing performed for a software project.

7.7 - Software Architecture Description Recommend content for software architecture descriptions for NASA projects. 

7.8 - Maturity of Life Cycle Products at Milestone Reviews - This chart summarizes current guidance approved by the NASA Office of the Chief Engineer (OCE) for software engineering life-cycle products and their maturity level at the various software project life cycle reviews.

7.9 - Entrance and Exit Criteria This guidance provides the maximum set of life cycle review entrance and exit criteria for software projects and should be tailored for the project class.

7.10 - Peer Review and Inspections Including Checklists - Describes the role of Peer Reviews and Inspections in detecting and evaluating product defects, and tracking solutions integration into the product.

7.11 - SWE History - The SWE History Summary includes all SWE numbers and their history of use in all versions of the Software Engineering Handbook.

7.12 - Topic retired

7.13 - Transitioning to a Higher Class Provide guidance for projects that desire to transition software from a lower to a higher classification.

7.14 - Implementing Measurement Requirements and Analysis for Projects Provides guidance for projects implementing the NPR 7150.2 requirements addressing or including software measurement. 

7.15 - Relationship Between NPR 7150.2 and NASA-STD-7009 - Discusses the relationship of NPR7150.2 to NASA-STD-7009 (Models and Simulation)

7.16 - Appendix C. Requirements Mapping and Compliance Matrix -  Guidance for using the 7150.2 Appendix C Requirements Mapping and Compliance Matrix.

7.17 - 7150.2C Appendices (Definitions, References, etc.) - This content is taken verbatim from NPR 7150.2C, NASA Software Engineering Requirements, Appendix A. 

7.18 - Documentation Guidance - Provide a set of minimum content guidance for software project plans, reports, and procedures. 

7.19 - Software Risk Management Checklists - Software Risk Management is a process whereby the project identifies and tracks threats to the success of the project. 

7.20 - Assessing - Meets the Intent - Guidance for projects that need to assess whether an industry partner or subcontractor’s standards meet the intent of NASA requirements. 

7.21 - Multi-condition Software Requirements - Specific recommendations for verifying software requirements with multiple conditional statements. 

-

8.1 - Off Nominal Testing - Guidance focusing on out of bounds parameters, failure scenarios, unexpected conditions, and capabilities that are typically considered as "must not work" functions.

8.2 - Software Reliability - The goal of SW reliability and maintainability is to assure that SW performs consistently as desired, when operating within specified conditions. This topic covers additional basic information on software reliability.

8.3 - Organizational Goals of Software Assurance Metrics - Derivation of SA Metrics from the Goal Statements using the Goal, Question, Metric method. 

8.4 - Additional Requirements Considerations for Use with Safety-Critical Software - requirements to be considered when you have safety-critical software on a program/project/facility.

8.5 - SW Failure Modes and Effects AnalysisA "bottoms up" structured analysis method to help determine potential failures or hazards in the software design with guidance and forms.

8.6 -  IV&V Requirements and SurveillanceThis guidance will establish the rationale behind the creation of an IV&V Requirements and Surveillance activities. 

8.7 - Software Fault Tree AnalysisA top-down analysis method to help identify the causes of presupposed hazards.

8.8 - COTS Software Safety ConsiderationsA discussion on the use of COTS in safety critical systems.

8.9 - Software Safety AnalysisSoftware Safety Analysis (SSA) is a term that is used to describe a wide range of analyses.  This article provides guidance on performing an SSA to satisfy the NASA-STD-8739.8 requirement associated with NPR 7150.2 SWE-205.  

8.10 - Facility Software Safety Considerations - Facility software system safety exists to ensure the safe and continuous operation of software associated with ground-based facilities.

8.11 - Auto-Generated Code - Model based coding techniques used with code generating tools.

8.12 - Basics of Software Auditingsoftware audits provide an independent evaluation of the conformance of software products and processes to applicable requirements, standards, guidelines, plans, and procedures.

8.13 - Test Witnessing - Guidance for software assurance personnel performing test witnessing.

8.14 - SA Tasking for NPR 7150.2B – Provides users of NPR7150.2B with the updated software assurance and software safety tasking in NASA-STD-8739.8A corresponding to the requirements in NPR 7150.2B. 

8.15 - SA Tasking Checklist Tool - Checklist tool that gives SA analysts the ability to tailor the software assurance and software safety tasks in NASA-STD-8739.8 and generate a tailored checklist for the tasks required on a project's software classification and safety criticality.

8.16 - SA Products -   Provides information for the major software assurance and safety work products resulting from the performance of the Software Assurance and Software Safety (SASS) tasks required in NASA-STD-8739.8.  Each product’s section may include sub-products, potential analysis methods/technologies, and suggested content for capturing and reporting on the product activities.

8.17 - SA List of Confirmations - Tool for tracking Software Assurance Confirmations.

8.18 - SA Suggested Metrics - This topic contains the complete list of software assurance/safety metrics that are suggested for use with the SA tasks in NASA-STD-8739.8.

8.19 - Dead / Dormant Code and Safety Critical Software - This topic discusses the issues of having dead or dormant code in software that is safety critical. 

8.20 - Safety Specific Activities in Each Phase - This topic provides a summary of the safety-specific activities that should be performed for any safety-critical software. The activities are grouped into the approximate life cycle phases where they will be performed.

8.21 - Software Hazard Causes - This topic provides a list of possible software causes that should be considered when developing the hazard analyses.


  

1. Software Design Principles - This topic contains the Guiding Principles that have been built over the years at NASA. These Principles are designed to help projects be successful by reducing the likelihood of defects.

2. Software Safety and Design Principles - This page contains the cross-references between elements of SWE-134 and the Software Design Principles.

3. Coding Standards - Implement a "secure" coding standard on all mission-critical software.

4. Command Receipt Acknowledgement - Design software to send a positive acknowledgement of command receipt.

5. Data Interface Integrity - Design software to verify the integrity of all inputs and outputs in the control system

6. Dead Code Exclusion - Establish a policy for eliminating unreachable code or mitigating the risk of any unreachable code.

7. Fault Detection and Response - In the software design, provide mechanisms to detect credible system faults and to react to these faults according to a pre-described plan.

8. Flight Software Modification - Include in the software design the capability for commanding modification of the software, and for preventing unwanted modifications.

9. Incorrect Memory Use or Access - Design software to protect against incorrect use of memory.

10. Initialization - Safe Mode - Design flight software to initialize software and hardware to a known, safe, and deliberate state

11. Invalid Data Handling - Design software to handle invalid data appropriately.

12. Resource Margins - Establish and maintain quantitative margins for all critical resources, allowing for maturation of usage estimates through the life cycle.

13. Resource Oversubscription - Include a robust and well thought out response to resource oversubscription situations in the software design.

14. Resource Usage Measurement - Incorporate timely visibility into the use of computing resources into the software design.

15. Safe Transitions - Assert required preconditions and post-conditions at software transitions.

16. Thread Safety - Design interaction between threads to prevent inappropriate interference.

17. Toggle Commands - Design both internal and external commanding to place the system into an explicitly specified state.


This tab contains checklists that can be used by both software engineering personnel as well as software assurance and safety personnel. The collection of checklists contains checklists to:

  1. aid in designing safety critical modules,
  2. aid in the development of requirements for safety critical systems
  3. aid in selecting operating systems and Commercial-Off-The-Shelf (COTS) software and
  4. focus on programming practices for specific languages as well as general programming practices.

These checklists can be used by developers as guidance for coding or for peer review checklists as well as by assurance and safety personnel to check that best practices have been followed. Although many of these checklists are designed for use with safety critical software, a majority of the practices are applicable for all software.

  

6.1 - Design Practices for Safety  - Lists some key practices for software design, particularly when designing safety-critical software.

6.2 - Checklist for General Software Safety Requirements Provides a list of many of the requirements that should be included in a safety critical software system.

6.3 - Checklist for Choosing a Real Time Operating System (RTOS)  - Considerations for choosing the best RTOS for your application.

6.4 - Checklist for Choosing Off-The Shelf Software (OTS)Checklist for Choosing Off-The Shelf Software (OTS) – Provides many questions to answer before choosing a COTS product that will be used across the project life cycle.

6.5 - Checklist for C Programming Practices Good practices to follow when coding in C for safety-critical software.

6.6 - Checklist for C++ Programming Practices – Good practices to follow when coding in C++ for safety-critical software.

6.7 - Checklist for Ada Programming PracticesCommon errors to look for when coding in Ada.

6.8 - Checklist for Fortran Programming PracticesPoints out a number of common problems to avoid when coding in Fortran.

6.9 - Checklist for Generic (Non-Language-Specific) Programming Practices - Practices that should be considered when coding safety critical software in any language. 

6.10 - Checklist for General Good Programming PracticesContains a number of practices and activities that can improve the quality of the software.

6.11 - Examples of Programming Practices for Exception HandlingShows some good and bad examples of exception handling when coding safety- critical software. 

6.12 - Reserved for next checklist 

  • No labels