01.01. Planning the Work

Planning the work is always done at the beginning of the project and followed up with a series of regular updates. These updates can be driven by a number of factors:

• Agile or similar life cycles will have planning updated as a part of each sprint or release cycle
• Changes in requirements 
• Changes in architecture or design, including advances in technology 
• Changes in coding, including advances in coding environments or tools
• Changes in testing, including advances in testing environments or tools
• Changes in release or maintenance 
• Issues discovered during Monitoring and Control 

Frequency Of This Activity

Planning the project encompasses a balance of several related sub-activities: 

• Cost estimation of all of the elements of the work
• Scheduling and assignments of tasks for all elements of the work
• Staffing the project with capable and properly trained workers
• Classifying the software and satisfying the requirements of NPR 7150.2D based on the software classification
• Monitoring of schedule events and Control of deviations 

01.01.1 Related SWEs

• SWE-013 - Software Plans - 3.1.3 The project manager shall develop, maintain, and execute software plans, including security plans, that cover the entire software life cycle and, as a minimum, address the requirements of this directive with approved tailoring.
• SWE-036 - Software Process Determination - 3.1.6 The project manager shall establish and maintain the software processes, software documentation plans, list of developed electronic products, deliverables, and list of tasks for the software development that are required for the project’s software developers, as well as the action required (e.g., approval, review) of the Government upon receipt of each of the deliverables.
• SWE-037 - Software Milestones - 3.1.7 The project manager shall define and document the milestones at which the software developer(s) progress will be reviewed and audited. 
• SWE-121 - Document Tailored Requirements - 3.1.12 Where approved, the project manager shall document and reflect the tailored requirement in the plans or procedures controlling the development, acquisition, and deployment of the affected software.
• SWE-125 - Requirements Compliance Matrix - 3.1.13 Each project manager with software components shall maintain a requirements mapping matrix or multiple requirements mapping matrices against requirements in this NPR, including those delegated to other parties or accomplished by contract vehicles or Space Act Agreements. 

01.01.2 Related Work Products

• 5.08 - SDP-SMP - Software Development - Management Plan - Minimum recommended content for the Software Development - Management Plan. 
• 7.08 - 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.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• 7.19 - Software Risk Management Checklists - tab 2 Planning Phase checklist
• A.10 Software Peer Reviews and Inspections - Plans are good candidates for a Peer Review

01.01.2.1 Related Process Asset Templates

01.01.3 Related Topics

• 7.05 - Work Breakdown Structures That Include Software - Provide guidance on the development of a work breakdown structure (WBS) for software on projects. 
• 7.06 - 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.

01.01.4 Related SPAN Links

01.02. Cost Estimation

Cost estimation helps Project Managers manage the work within the budget. If work estimates drive the cost estimates over budget, Project Managers have an early opportunity to request more budget or make adjustments in work to prevent budget overruns. 

Frequency Of This Activity

Re-estimation of costs are driven by:

• Changes in requirements
• Changes in architecture or design, including advances in technology 
• Changes in coding, including advances in coding environments or tools
• Changes in testing, including advances in testing environments or tools
• Changes in release or maintenance 
• Issues discovered during Monitoring and Control 

01.02.1 Related SWEs

• SWE-015 - Cost Estimation - 3.2.1 To better estimate the cost of development, the project manager shall establish, document, and maintain:
  1. 1. Two cost estimate models and associated cost parameters for all Class A and B software projects that have an estimated project cost of $2 million or more.
     2. One software cost estimate model and associated cost parameter(s) for all Class A and Class B software projects that have an estimated project cost of less than $2 million.
     3. One software cost estimate model and associated cost parameter(s) for all Class C and Class D software projects.
     4. One software cost estimate model and associated cost parameter(s) for all Class F software projects.
• SWE-151 - Cost Estimate Conditions - 3.2.2 The project manager’s software cost estimate(s) shall satisfy the following conditions: 

  a. Covers the entire software life cycle.
  b. Is based on selected project attributes (e.g., programmatic assumptions/constraints, assessment of the size, functionality, complexity, criticality, reuse code, modified code, and risk of the software processes and products).
  c. Is based on the cost implications of the technology to be used and the required maturation of that technology.
  d. Incorporates risk and uncertainty, including end state risk and threat assessments for cybersecurity.
  e. Includes the cost of the required software assurance support.
  f. Includes other direct costs.

• SWE-174 - Software Planning Parameters - 3.2.3 The project manager shall submit software planning parameters, including size and effort estimates, milestones, and characteristics, to the Center measurement repository at the conclusion of major milestones.
• SWE-142 - Software Cost Repositories - 2.1.5.10 For Class A, B, and C software projects, each Center Director, or designee, shall establish and maintain software cost repository(ies) that contains at least the following measures: 

  a. Planned and actual effort and cost.
  b. Planned and actual schedule dates for major milestones.
  c. Both planned and actual values for key cost parameters that typically include software size, requirements count, defects counts for maintenance or sustaining engineering projects, and cost model inputs.
  d. Project descriptors or metadata that typically includes software class, software domain/type, and requirements volatility.

01.02.2 Related Work Products

• Cost Models and Estimation Worksheets
• 7.08 - 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.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• A.10 Software Peer Reviews and Inspections - Cost Estimates are good candidates for a Peer Review

01.02.2.1 Related Process Asset Templates

01.02.3 Related Topics

• 7.06 - 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.

01.02.4 Related SPAN Links

01.03. Scheduling the Work

Scheduling helps Project Managers manage the work within the time constraints. If work estimates drive the schedule over the time budget, Project Managers have an early opportunity to request more time or make adjustments in work to prevent late deliveries. 

Frequency Of This Activity

Re-scheduling is driven by:

• Changes in requirements
• Changes in architecture or design, including advances in technology 
• Changes in coding, including advances in coding environments or tools
• Changes in testing, including advances in testing environments or tools
• Changes in release or maintenance 
• Issues discovered during Monitoring and Control 

01.03.1 Related SWEs

• SWE-016 - Software Schedule - 3.3.1 The project manager shall document and maintain a software schedule that satisfies the following conditions:
  1. 1. Coordinates with the overall project schedule.
     2. Documents the interactions of milestones and deliverables between software, hardware, operations, and the rest of the system.
     3. Reflects the critical dependencies for software development activities.
     4. Identifies and accounts for dependencies with other projects and cross-program dependencies.
• SWE-018 - Software Activities Review - 3.3.2 The project manager shall regularly hold reviews of software schedule activities, status, performance metrics, and assessment/analysis results with the project stakeholders and track issues to resolution.
• SWE-046 - Supplier Software Schedule - 3.3.3 The project manager shall require the software developer(s) to provide a software schedule for the project’s review, and schedule updates as requested.

01.03.2 Related Work Products

• Schedule of work tasks
• Assignments of tasks to individuals
• 7.08 - 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.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• A.10 Software Peer Reviews and Inspections - Schedules are good candidates for a Peer Review

01.03.2.1 Related Process Asset Templates

01.03.3 Related Topics

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

01.03.4 Related SPAN Links

01.04. Training

The workers on a project must have the necessary skills to perform and complete the work and meet quality objectives. Project Managers have the obligation to select these workers for the project and see that training opportunities are available to improve the skills needed. Training for workers must be planned for both in the budget (cost estimation) and the schedule. 

Training can come from a number of sources: 

• Organizations that provide tools or materials used on the project may have training programs for these tools and materials
• OCE provides training on Software Development subjects
• OSMA provides training on Software Assurance subjects

Frequency Of This Activity

Re-training is driven by:

• Changes in requirements
• Changes in architecture or design, including advances in technology 
• Changes in coding, including advances in coding environments or tools
• Changes in testing, including advances in testing environments or tools
• Issues discovered during Monitoring and Control 

01.04.1 Related SWEs

• SWE-017 - Project and Software Training - 3.4.1 The project manager shall plan, track, and ensure project specific software training for project personnel.

Institutional SWEs (A.13 NASA Institutional Requirements)

• SWE-100 - Software Training Funding - 2.1.1.5 The NASA OCE and Center training organizations shall provide training to advance software engineering practices.  
• SWE-222 - Software Assurance Training - 2.1.2.6 The NASA Chief, SMA shall provide for software assurance training. 

01.04.2 Related Work Products

• 5.15 - Train - Software Training Plan - Minimum recommended content for the Software Training Plan. 
• 7.08 - 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.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.

01.04.2.1 Related Process Asset Templates

01.04.3 Related Topics

01.04.4 Related SPAN Links

01.05. Monitor and Control

Monitoring plans as they are carried out is critical for maintaining awareness of progress. It also allows the Project Team to know when there are deviations from the plan. When those deviations are significant, control actions may be made to get the project back on track. If the project cannot be gotten back on track, some amount of re-planning may be called for. The earlier correction actions are taken, the less severe they will be.  

Frequency Of This Activity

Some monitoring is done frequently. In some life cycles, like Agile, include daily "stand-up meetings" where team members report on progress and their "plan for the day". This keeps all team members aware of what the team is doing at the moment.

Additional opportunities for monitoring is more formal. These include regular reporting of progress to management and stakeholders. These include reviews of various work products and formal reviews at certain project and program milestones. 

01.05.1 Related SWEs

• SWE-018 - Software Activities Review - 3.3.2 The project manager shall regularly hold reviews of software schedule activities, status, performance metrics, and assessment/analysis results with the project stakeholders and track issues to resolution.
• SWE-024 - Plan Tracking - 3.1.4 The project manager shall track the actual results and performance of software activities against the software plans.
  1. 1. Corrective actions are taken, recorded, and managed to closure.
     2. Changes to commitments (e.g., software plans) that have been agreed to by the affected groups and individuals are taken, recorded, and managed.
• SWE-037 - Software Milestones - 3.1.7 The project manager shall define and document the milestones at which the software developer(s) progress will be reviewed and audited. 
• SWE-039 - Software Supplier Insight - 3.1.8 The project manager shall require the software developer(s) to periodically report status and provide insight into software development and test activities; at a minimum, the software developer(s) will be required to allow the project manager and software assurance personnel to:
  1. 1. Monitor product integration.
     2. Review the verification activities to ensure adequacy.
     3. Review trade studies and source data.
     4. Audit the software development processes and practices.
     5. Participate in software reviews and technical interchange meetings.
• SWE-040 - Access to Software Products - 3.1.9 The project manager shall require the software developer(s) to provide NASA with software products, traceability, software change tracking information, and non-conformances in electronic format, including software development and management metrics.
• SWE-042 - Source Code Electronic Access - 3.1.10 The project manager shall require the software developer(s) to provide NASA with electronic access to the source code developed for the project in a modifiable format.
• SWE-046 - Supplier Software Schedule - 3.3.3 The project manager shall require the software developer(s) to provide a software schedule for the project’s review, and schedule updates as requested.

01.05.2 Related Work Products

• 5.08 - SDP-SMP - Software Development - Management Plan - Minimum recommended content for the Software Development - Management Plan. 
• Project Schedule - including schedules from software suppliers
• 7.08 - 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.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.

01.05.2.1 Related Process Asset Templates

01.05.3 Related Topics

• 7.05 - Work Breakdown Structures That Include Software - Provide guidance on the development of a work breakdown structure (WBS) for software on projects. 
• 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.

01.05.4 Related SPAN Links

01.06. Acquisition and Reuse of Software

Software that is not actually developed by the team for the project, is acquired. It may be: 

• Acquired through a contract with an outside software developer - custom software specifically produced for the project
• Off the Shelf software - Government Off the Shelf (GOTS), Commercial Off the Shelf (COTS), or Modified Off the Shelf (MOTS), all with appropriate modifications
• Reused software - code from another NASA project that may be used as a whole or in part, with appropriate modifications

Regardless of the origins of the code, it must be properly licensed so that it can be legally used on the project.  

Frequency Of This Activity

This activity is performed whenever there is a change in the reused software. 

01.06.1 Related SWEs

• SWE-027 - Use of Commercial, Government, and Legacy Software - 3.1.14 The project manager shall satisfy the following conditions when a COTS, GOTS, MOTS, OSS, or reused software component is acquired or used: 

  a. The requirements to be met by the software component are identified.

  b. The software component includes documentation to fulfill its intended purpose (e.g., usage instructions).

  c. Proprietary rights, usage rights, ownership, warranty, licensing rights, transfer rights, and conditions of use (e.g., required copyright, author, and applicable license notices within the software code, or a requirement to redistribute the licensed software only under the same license (e.g., GNU GPL, ver. 3, license)) have been addressed and coordinated with Center Intellectual Property Counsel. 

  d. Future support for the software product is planned and adequate for project needs.

  e. The software component is verified and validated to the same level required to accept a similar developed software component for its intended use.

  f. The project has a plan to perform periodic assessments of vendor reported defects to ensure the defects do not impact the selected software components.

• SWE-032 - CMMI Levels for Class A and B Software - 3.9.2 The project manager shall acquire, develop, and maintain software from an organization with a non-expired CMMI-DEV rating as measured by a CMMI Institute Certified Lead Appraiser as follows:
  1. 1. For Class A software: CMMI-DEV Maturity Level 3 Rating or higher for software.
     2. For Class B software (except Class B software on NASA Class D payloads, as defined in NPR 8705.4): CMMI-DEV Maturity Level 2 Rating or higher for software.
• SWE-033 - Acquisition vs. Development Assessment - 3.1.2 The project manager shall assess options for software acquisition versus development.
• SWE-147 - Specify Reusability Requirements - 3.10.1 The project manager shall specify reusability requirements that apply to its software development activities to enable future reuse of the software, including the models, simulations, and associated data used as inputs for auto-generation of software, for U.S. Government purposes.
• SWE-148 - Contribute to Agency Software Catalog - 3.10.2 The project manager shall evaluate software for potential reuse by other projects across NASA and contribute reuse candidates to the appropriate NASA internal sharing and reuse software system. However, if the project manager is not a civil servant, then a civil servant will pre-approve all such software contributions; all software contributions should include, at a minimum, the following information:

  a. Software Title.
  b. Software Description.
  c. The Civil Servant Software Technical POC for the software product.
  d. The language or languages used to develop the software.
  e. Any third-party code contained therein, and the record of the requisite license or permission received from the third party permitting the Government’s use and any required markings (e.g., required copyright, author, applicable license notices within the software code, and the source of each third-party software component (e.g., software URL & license URL)), if applicable.
  f. Release notes.

• SWE-214 - Internal Software Sharing and Reuse - 2.1.5.16 The Center Director or designee (e.g., the Civil Servant Technical POC for the software product) shall perform the following actions for each type of internal NASA software transfer or reuse:

  a. A NASA civil servant to a NASA civil servant:

  (1) Verify the requesting NASA civil servant has requested and completed an Acknowledgment (as set forth in the note following paragraph 3.10.2e).
  (2) Provide the software to the requesting NASA civil servant.

  b. A NASA civil servant to a NASA contractor:

  (1) Verify a NASA civil servant (e.g., a Contracting Officer (CO) or Contracting Officer Representative (COR)) has confirmed the NASA contractor requires such software for the performance of Government work under their NASA contract and that such performance of work will be a Government purpose. Center Intellectual Property Counsel should be consulted for any questions regarding what is or is not a Government purpose.
  (2) Verify a NASA civil servant (e.g., a CO or COR) has confirmed an appropriate Government Furnished Software clause (e.g., 1852.227-88, “Government-furnished computer software and related technical data”) is in the subject contract (or, if not, that such clause is first added); or the contractor may also obtain access to the software in accordance with the external release requirements of NPR 2210.1, Release of NASA Software.
  (3) Verify NASA contractor is not a foreign person (as defined by 22 CFR §120.16).
  (4) Verify there is a requesting NASA Civil servant (e.g., a CO or COR), and the requesting NASA civil servant has executed an Acknowledgment (as set forth in the note following paragraph 3.10.2e).
  (5) After items (1), (2), (3), and (4) are complete, provide the software to the requesting NASA civil servant. The requesting NASA civil servant is responsible for furnishing the software to the contractor pursuant to the subject contract’s terms.

  c. A NASA civil servant to any NASA grantees, Cooperative Agreement Recipients or any other agreement partners or to any other entity under U.S. Government Agency Release, Open source Release, Public Release, U.S. Release, Foreign Release:

  (1) If the release is to any NASA grantees, Cooperative Agreement Recipients, or any other agreement (e.g., Space Act Agreement) partners or to any other entity under U.S. Government Agency Release, an Open source Release, a Public Release, a U.S. Release, or a Foreign Release, the software release is completed in accordance with the external release requirements of NPR 2210.1, Release of NASA Software – Revalidated w/change 1.

• SWE-215 - Software License Rights - 2.1.5.13 The Center Director or designee shall ensure that the Government has clear rights in the software, a Government purpose license, or other appropriate license or permission from third party owners prior to providing the software for internal NASA software sharing or reuse.
• SWE-216 - Internal Software Sharing List - 2.1.5.14 The Center Director, or designee, shall ensure that all software listed on the internal software sharing or reuse catalog(s) conforms to NASA software engineering policy and requirements.
• SWE-217 - List of All Contributors and Disclaimer Notice - 2.1.5.15 The Center Director, or designee, (e.g., the Civil Servant Technical Point of Contact (POC) for the software product) shall perform the following actions:

  a. Keep a list of all contributors to the software product.

  b. Ensure that the software product contains appropriate disclaimer and indemnification provisions (e.g., in a “README” file) stating that the software may be subject to U.S. export control restrictions, and it is provided “as is” without any warranty, express or implied, and that the recipient waives any claims against, and indemnifies and holds harmless, NASA and its contractors and subcontractors.

• SWE-218 - Contracting Officers - 2.1.7.1 Contracting Officers, as defined in FAR 2.101, or Agreement Managers as defined in NAII 1050.3, NASA Partnership Guide, in conjunction with Program/Project Managers shall ensure that the appropriate FAR, NFS, and other provisions/clauses based on this requirements document and NASA-STD-8739.8 are included for all NASA contracts, Space Act Agreements, cooperative agreements, partnership agreements, grants, or other agreements pursuant to which software is being acquired, developed, modified, operated, or managed for NASA.

01.06.2 Related Work Products

• 5.12 - SUM - Software User Manual - Minimum recommended content for the Software User Manual. 
  • Manuals from suppliers of software
• Make vs Buy Decision Documents 
• 7.08 - 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.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• A.10 Software Peer Reviews and Inspections - Software Acquisition documents are good candidates for a Peer Review

01.06.2.1 Related Process Asset Templates

• PAT-025 - Checklist for Choosing a Real Time Operating System (RTOS) 

01.06.3 Related Topics

• 6.3 - Checklist for Choosing a Real Time Operating System (RTOS) - Considerations for choosing the best RTOS for your application.
• 7.03 - Acquisition Guidance - Guidance for projects implementing those requirements in NASA Procedural Requirement (NPR) 7150.2, NASA Software Engineering Requirements that address software acquisition. 
• 7.04 - Flow Down 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.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.25 - Artificial Intelligence And Software Engineering - AI is implemented in software and governed by software development processes.
• 8.08 - COTS Software Safety Considerations - A discussion on the use of COTS in safety-critical systems.

01.06.4 Related SPAN Links

01.07. Classification, Tailoring and Waivers

This sub-activity is complex and includes requirements from the Institutional Requirements as well as from Software Assurance Requirements.

NPR 7150.2, Appendix D contains guidance on the classifications used for software. Appendix C contains a matrix specifying the requirements that are applicable to a specific class. In the planning for a project, the Project Manager documents the requirements that will be satisfied in the project using the "Requirements Mapping and Compliance Matrix". 

If there are one or more requirements that cannot be satisfied by the project, the Project Manager determines what alternative to the requirement can be satisfied (called tailoring) and seeks relief from the original requirement from the appropriate level of Technical Authorities. 

Frequency Of This Activity

In the course of a project, it may be necessary to re-classify the software. This can be due to a change in the mission for which the software is planned to be used, or some other change. Classification can be either increased or decreased. Both SWE-021 - Transition to a Higher Class, and topic 7.13 - Transitioning to a Higher Class deal specifically with moving to a higher classification. 

01.07.1 Related SWEs

• A.13 NASA Institutional Requirements
  
  • SWE-006 - Center Software Inventory - 2.1.5.6 Center Director, or designee, shall maintain a reliable list of their Center’s programs and projects containing Class A, B, C, and D software. The list should include: 

    a. Project/program name and Work Breakdown Structure (WBS) number.
    b. Software name(s) and WBS number(s).
    c. Software size estimate (report in Kilo/Thousand Source Lines of Code (KSLOCs)).
    d. The phase of development or operations.
    e. Software Class or list of the software classes being used on the project.
    f. Software safety-critical status.
    g. For each Computer Software Configuration Item (CSCI)/Major System containing Class A, B, or C software, provide:

    (1) The name of the software development organization.
    (2) Title or brief description of the CSCI/Major System.
    (3) The estimated total KSLOCs, the CSCI/Major System, represents.
    (4) The primary programming languages used.
    (5) The life cycle methodology on the software project.
    (6) Name of responsible software assurance organization(s).

  • SWE-121 - Document Tailored Requirements - 3.1.12 Where approved, the project manager shall document and reflect the tailored requirement in the plans or procedures controlling the development, acquisition, and deployment of the affected software.
  • SWE-125 - Requirements Compliance Matrix - 3.1.13 Each project manager with software components shall maintain a requirements mapping matrix or multiple requirements mapping matrices against requirements in this NPR, including those delegated to other parties or accomplished by contract vehicles or Space Act Agreements. 
  • SWE-126 - Tailoring Considerations - 2.1.8.2 The technical and institutional authorities for requirements in this directive shall: 

    a. Assess projects’ requirements mapping matrices and tailoring from requirements in this directive by:

    (1) Checking the accuracy of the project’s classification of software components against the definitions in Appendix D.
    (2) Evaluating the project’s Requirements Mapping Matrix for commitments to meet applicable requirements in this directive, consistent with software classification.
    (3) Confirming that requirements marked “Not-Applicable” in the project’s Requirements Mapping Matrix are not relevant or not capable of being applied.
    (4) Determining whether the project’s risks, mitigations, and related requests for relief from requirements designated with “X” in Appendix C are reasonable and acceptable.
    (5) Approving/disapproving requests for relief from requirements designated with “X” in Appendix C, which falls under this Authority’s scope of responsibility.
    (6) Facilitating the processing of projects’ requirements mapping matrices and tailoring decisions from requirements in this directive, which falls under the responsibilities of a different Authority (see column titled “Authority” in Appendix C).
    (7) Include the SAISO (or delegate) in all software reviews to ensure software cybersecurity is included throughout software development, testing, maintenance, retirement, operations, management, acquisition, and assurance activities.
    (8) Ensuring that approved requirements mapping matrices, including any tailoring rationale against this directive, are archived as part of retrievable project records.

    b. Indicate the Technical Authority or Technical Authorities approval by signature(s) in the Requirements Mapping Matrix itself, when the Requirements Mapping Matrix is used to tailor from the applicable “X” requirement(s).

  • SWE-139 - Shall Statements - 3.1.11 The project manager shall comply with the requirements in this NPR that are marked with an “X” in Appendix C consistent with their software classification.
  • SWE-140 - Comply with Requirements - 2.1.5.4 Center Director, or designee, shall comply with the requirements in this directive that are marked with an “X” in Appendix C.
  • SWE-150 - Review Changes To Tailored Requirements - 2.2.7 The engineering, CIO, and SMA authorities shall review and agree with any tailored NPR 7150.2 requirements per the requirements mapping matrix authority column. 
  • SWE-152 - Review Requirements Mapping Matrices - 2.1.1.3 The NASA OCE shall periodically review the project requirements mapping matrices.
  • SWE-212 - NASA-STD-8739 Mapping Matrices - 2.1.2.4 The NASA Chief, SMA shall periodically review the project’s requirements mapping matrices.
  • SWE-223 - Tailoring IV&V project selections - 2.1.2.7 The NASA Chief, SMA shall make the final decision on all proposed tailoring of SWE-141, the Independent Verification and Validation (IV&V) requirement. 
• A.01 Software Life Cycle Planning
  • SWE-020 - Software Classification - 3.5.1 The project manager shall classify each system and subsystem containing software in accordance with the highest applicable software classification definitions for Classes A, B, C, D, E, and F software in Appendix D. 
  • SWE-021 - Transition to a Higher Class - 2.2.8 If a system or subsystem development evolves to meet a higher or lower software classification as defined in Appendix D, then the project manager shall update their plan(s) and initiate modifications to any supplier contracts to fulfill the applicable requirements per the Requirements Mapping Matrix in Appendix C with approved tailoring.
  • SWE-176 - Software Records - 3.5.2 The project manager shall maintain records of each software classification determination, each software Requirements Mapping Matrix, and the results of each software independent classification assessments for the life of the project. 
• A.02 Software Assurance and Software Safety
  • SWE-205 - Determination of Safety-Critical Software - 3.7.1 The project manager, in conjunction with the SMA organization, shall determine if each software component is considered to be safety-critical per the criteria defined in NASA-STD-8739.8. 

01.07.2 Related Work Products

• 7.08 - 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.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• 7.16 - Appendix C. Requirements Mapping and Compliance Matrix - Guidance for using the 7150.2D Appendix C Requirements Mapping and Compliance Matrix.

01.07.2.1 Related Process Asset Templates

• PAT-028 - NPR 7150.2D Compliance Matrix

01.07.3 Related Topics

• 7.02 - Classification and Safety-Criticality - Aids to help those responsible for determining the software classification and the software safety criticality
• 7.13 - Transitioning to a Higher Class - Provide guidance for projects that desire to transition software from a lower to a higher classification.

01.07.4 Related SPAN Links

01.08. Cybersecurity

The purpose of security risk management is to identify potential software security problems before they occur so that software security risk handling activities can be planned and invoked as needed across the life of the space flight software product or project. 

Software defects have the potential to leave a system compromised and open to cyber-attacks. Identifying risks and planning appropriate mitigations early in the project life cycle help increase the overall security and enhance the survivability of the space flight software system. Provide the capability to monitor key software observables (e.g. number of failed login attempts, performance changes, internal communication changes) to detect adversarial actions that threaten mission success.

The project manager shall implement protections for software systems with communications capabilities against unauthorized access per the requirements contained in the NASA-STD-1006, Space System Protection Standard. 

Mitigations identified to address security risks need to be confirmed as appropriate and adequate.  Software verification and validation (V&V) processes are used to determine whether the software security risk mitigations, as planned and implemented, satisfy their intended use to address security risks in space flight software.  The results of V&V activities serve as a documented assurance that the correct mitigations were identified, implemented, and will reduce to an acceptable level or eliminate known software security risks.

Secure coding practices should be identified, recorded, and implemented to include all life cycle phases of the project.  Unsafe coding practices result in costly vulnerabilities in application software that leads to the theft of sensitive data.   Some secure practices include but not limited to the strict language adherence and use of automated tools to identify problems either at compile time or run time; language-specific guidance, domain-specific guidance, local standards for code organization and commenting, and standard file header format are often specified as well. The use of uniform software coding methods, standards, and/or criteria ensures uniform coding practices, reduces errors through safe language subsets, and improves code readability. Verification that these practices have been adhered to reduces the risk of software malfunction for the project during its operations and maintenance phases.

Frequency Of This Activity

This activity is repeated when there are changes in Requirements, Coding, or Testing where security vulnerabilities are detected or need to be investigated. 

01.08.1 Related SWEs

01.08.1.1 - SWEs in A.01 Software Life Cycle Planning

• SWE-154 - Identify Security Risks - 3.11.3 The project manager shall identify cybersecurity risks, along with their mitigations, in flight and ground software systems and plan the mitigations for these systems.
• SWE-156 - Evaluate Systems for Security Risks - 3.11.2 The project manager shall perform a software cybersecurity assessment on the software components per the Agency security policies and the project requirements, including risks posed by the use of COTS, GOTS, MOTS, OSS, or reused software components.
• SWE-157 - Protect Against Unauthorized Access - 3.11.4 The project manager shall implement protections for software systems with communications capabilities against unauthorized access per the requirements contained in the NASA-STD-1006, Space System Protection Standard.
• SWE-159 - Verify and Validate Risk Mitigations - 3.11.5 The project manager shall test the software and record test results for the required software cybersecurity mitigation implementations identified from the security vulnerabilities and security weaknesses analysis.

01.08.1.2 - SWEs in A.05 Implementation

• SWE-185 - Secure Coding Standards Verification - 3.11.7 The project manager shall verify that the software code meets the project’s secure coding standard by using the results from static analysis tool(s).
• SWE-207 - Secure Coding Practices - 3.11.6 The project manager shall identify, record, and implement secure coding practices.

01.08.1.3 - SWEs in A.06 Testing 

• SWE-210 - Detection of Adversarial Actions - 3.11.8 The project manager shall identify software requirements for the collection, reporting, and storage of data relating to the detection of adversarial actions.

01.08.2 Related Work Products

• 7.08 - 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.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.

01.08.2.1 Related Process Asset Templates

• PAT-012 - Detection of Adversarial Actions

01.08.3 Related Topics

• 7.22 - Space Security: Best Practices Guide - This topic guides mission security implementation in the form of principles coupled with applicable controls that cover both the space vehicle and the ground segment.
• 8.04 - Additional Requirements Considerations for Use with Safety-Critical Software - Requirements to be considered when you have safety-critical software on a program/project/facility.

01.08.4 Related SPAN Links

01.09. Work Products

Software development requires documentation and implementation. Software development activities require decisions and work results (e.g., requirements, design, the outcome of reviews, etc.) to be captured as building blocks throughout the software life cycle. Software developers and software acquisitions need to know what documentation expectations exist for a development project.  Having defined and approved content descriptions for project documentation allows these needs and more to be met.

Frequency Of This Activity

Work products may need to be updated as requirements and design changes. Other work products are updated almost continuously, such as code and testing. Many work products also benefit from Peer Reviews (see Activity A.10 Software Peer Reviews and Inspections.)

01.09.1 Related SWEs

• SWE-153 - ETA Define Document Content - 2.1.5.12 The designated ETA(s) shall define the content requirements for software documents or records.

01.09.2 Related Work Products

• 5.01 - CR-PR - Software Change Request - Problem Report - Minimum recommended content for the Software Change Request - Problem Report. 
• 5.02 - IDD - Interface Design Description - Minimum recommended content for the Interface Design Description. 
• 5.03 - Inspect - Software Inspection, Peer Reviews, Inspections - Minimum recommended content for the Software Inspection, Peer Reviews, Inspections. 
• 5.04 - Maint - Software Maintenance Plan - Minimum recommended content for the Software Maintenance Plan. 
• 5.05 - Metrics - Software Metrics Report - Minimum recommended content for the Software Metrics Report. 
• Measurement Analysis Results
• 5.06 - SCMP - Software Configuration Management Plan - Minimum recommended content for the Software Configuration Management Plan. 
• 5.07 - SDD - Software Data Dictionary - Minimum recommended content for the Software Data Dictionary. 
• 5.08 - SDP-SMP - Software Development - Management Plan - Minimum recommended content for the Software Development - Management Plan. 
• 5.09 - SRS - Software Requirements Specification - Minimum recommended content for the Software Requirements Specification. 
• Unit Test Procedures for the code
• 5.10 - STP - Software Test Plan - Minimum recommended content for the Software Test Plan at a high level,
• 5.11 - STR - Software Test Report - Minimum recommended content for the Software Test Report. 
• 5.12 - SUM - Software User Manual - Minimum recommended content for the Software User Manual. 
• 5.13 - SwDD - Software Design Description - Minimum recommended content for a Software Design Description. 
• 5.14 - Test - Software Test Procedures - Minimum recommended content for the Software Test Procedures Plan. 
• 5.15 - Train - Software Training Plan - Minimum recommended content for the Software Training Plan. 
• 5.16 - VDD - Version Description Document - Minimum recommended content for the Version Description Document. 
• 5.17 - Software Assurance Plan Minimum Content - Minimum Recommended Content for a Software Assurance Plan. 
• 5.18 - Safety Plan Minimum Content - Minimum Recommended Content for a Safety Plan. 
• 5.19 - Software Assurance Status Report Minimum Content - Minimum Recommended Content for Software Assurance Status Reports. 
• 5.20 - IV&V Project Execution Plan Minimum Content - Minimum Recommended Content for IV&V Project Execution Plan. 
• 5.21 - Software Requirements Analysis Report Minimum Content - Minimum Recommended Content for Software Requirements Analysis Report. 
• 5.22 - Software Design Analysis Report Minimum Content - Minimum Recommended Content for Software Design Analysis Report. 
• 5.23 - Testing Analysis Report Minimum Content - Minimum Recommended Content for Testing Analysis Report. 
• 5.24 - Hazard Report Minimum Content - Minimum Recommended Content for Hazard Report. 
• 5.25 - Audit Report Minimum Content - Minimum Recommended Content for Audit Report. 
• 5.26 - Source Code Quality Analysis Report Minimum Content - Minimum Recommended Content for Source Code Quality Analysis Report. 
• Cost Models and Estimation Worksheets
• Schedule of work tasks
• Assignments of tasks to individuals
• Project Schedule - including schedules from software suppliers
• Make vs Buy Decision Documents 
• Operational Concepts
• Modules of code
• Root Cause Analysis Results

01.09.2.1 Related Process Asset Templates

01.09.3 Related Topics

• 7.08 - 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.09 - Entrance and Exit Criteria - This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.
• 7.18 - Documentation Guidance - Provide a set of minimum content guidance for software project plans, reports, and procedures. 
• 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 the NASA Software Assurance and Software Safety Standard, 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.
• A.10 Software Peer Reviews and Inspections - Many of the above documents are good candidates for a Peer Review

01.09.4 Related SPAN Links