1. Introduction

This section includes a brief introduction of what coding is.

In the "Related Activities" in the list, comments explain how this activity is affected by each of the other activities. 

Software coding activities occur at the throughout the project. They may include prototyping and development of some throw-away code to experiment with approaches. The final code must be carefully produced and traced to prevent unforeseen problems from occurring after release.   

A project may be for the creation of a new product, or the enhancement of an existing product. It may even involve the merging of capabilities from multiple products into a new, more capable product.

Coding includes the creation of code, unit testing, and integration testing to form a complete usable product. 

The activities on this page include links to pages in the SWEHB that cover requirements from NPR 7150.2 as well as related Topics on techniques and Process Assets that may be used to help you in your project. 


1.1 Related Activities

  • SE-Initiation and Planning - Coding activities are planned. They are dependent on a whole host of other project activities.  
  • SE-Estimation - Estimates are made and tracked for coding activities. Coding must be measured and controlled. 
  • SE-Schedules - Coding Activities are scheduled and tracked to completion. Code is a deliverable what must fit into the timeline of other products and missions.  
  • SE-Training - Coders are trained in coding methods, the use of coding tools, and related subjects. 
  • SE-Scope Management - Requirements, defect management, change management, Non-conformance and Defect Management. Coding must be closely tied to requirements to avoid wasting time building something that is not wanted.
  • SE-Architecture and Design - Code lives and operates within the architecture. It interfaces with humans and other equipment. 
  • SE-Testing - including V&V
  • SE-Operations, Maintenance and Retirement
  • SE-Configuration Mgmt - including code repository, builds, and releases 
  • Peer Reviews - including code reviews
  • Measurements - related to coding


2. Make / Buy / Reuse

This is one of the early decisions that must be made early in a project. Once the product requirements are settled, at least at a high level, the project team must decide how the code will be obtained. 

  • Making code is always attractive among talented coders who are excited to create code from scratch. The advantage of this is that the code is highly customized and may be fixed using the project team's talent. This presumes that these talented individuals will always be available to do additional development and fix problems. 
  • Buying code is attractive for smaller project teams where the coding talent is not readily available. Third party coders may solve problems with talent availability but this code my be carefully monitored to ensure it performs as required. 
  • Reusing code may provide an attractive starting point for many project teams. It can be used to jumpstart a development effort when large portions of the reused code is adapted to the new needs. If the reused code is not up to current standards, it can be a challenge to cleanup to the projects needs and standards. 

When making any decision, it is important to assess the options available to obtain the greatest value and benefit.  Software development is no different.  Choices need to be assessed to identify the best use of available resources (budget, time, personnel, etc.) to address a defined and scoped need while providing the greatest benefit with the least risk to the project.

All software used on a project must meet the project requirements and be tested, verified, and validated, including the incorporated Commercial Off the Shelf (COTS), Government Off the Shelf (GOTS), Modified Off the Shelf (MOTS), Open Source Software (OSS) or reused software components. The project must know that each COTS, GOTS, MOTS, OSS, or reused software component meets NASA requirements; that all of the legal requirements for proprietary rights, usage rights, ownership, warranty, licensing rights, and transfer rights are understood and met by the project’s planned use. That software's future support for the software is planned.  To reduce the risk of failure, the project performs periodic assessments of vendor-reported defects to ensure the defects do not impact the selected software components.

2.1 Related NPR 7150.2 SWEs

2.2 Related Topics and Process Assets



3. Automatic Code Generation

Defining the approach to be used for the automatic generation of software source code allows projects to review and verify their plans for the use and management of auto-generated software before implementation to ensure the development approach and the resulting software will meet the expectations and goals of the project without introducing unacceptable levels of risk. 

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.

Model-based software development uses a model as the centerpiece of the development process. Software engineers create a model of the system behavior that can then be translated into different languages such as C or Ada by the appropriate code generator. The model is continually refined throughout the development process and can even be executable. For maximum benefit, the generated code should not be modified by software engineers; when changes are desired, the model is revised, and code is generated from the revised model.

3.1 Related NPR 7150.2 SWEs

3.8 Automatic Generation of Software Source Code

SWE-146 - Auto-generated Source Code 
SWE-206 - Auto-Generation Software Inputs

3.2 Related Topics and Process Assets

8.11 - Auto-Generated Code - 

4. Software Reuse

Software systems are often designed using existing components from other systems. It is recognized that reusing existing software components can help achieve the resulting system more quickly and at a lower cost. However, for software components to be truly reusable, reusability needs to be part of the planned initial development of those components.

With the focus on software reuse increasing, projects need to plan for future reuse of developed software by specifying requirements that facilitate software reuse in the future.  These requirements enhance the benefits of reuse and address the known pitfalls of reuse where that is possible.  These requirements, which should be captured as early in the life cycle as possible, address development processes as well as project technical requirements and are captured in project documentation such as the software development/management plan for processes, project coding standards, and the requirements document or repository for technical requirements.  The software reuse-related requirements are included as a part of the normal software requirements review process and verification & validation process.

Reusing software can have many benefits for the Agency, including, but not limited to, cost savings.  For this reason, software project managers consider future reuse of software components created for their projects and make those selected components available to future projects through an Agency repository. When evaluating software for potential reuse, remember to consider single components as well as entire software products.

4.1 Related NPR 7150.2 SWEs

3.10 Software Reuse

SWE-147 - Specify Reusability Requirements

SWE-148 - Contribute to Agency Software Catalog

SWE-214 - Internal Software Sharing and Reuse

4.2 Related Topics and Process Assets


5. Coding

The project has the primary responsibility for producing the software code. The NPR notes that the "software implementation consists of implementing the requirements and design into code, data, and documentation. Software implementation also consists of the following coding methods and standards. Unit testing is also a part of software implementation." Other guidance areas in this Handbook cover the requirements for data, documentation, methods, standards, and unit testing (see the table in the guidance section for this requirement).

Standards are used to ensure safety, security, reliability, quality, maintainability, readability, and testability of the NASA code products. 

The static analysis requirement for NASA software projects increases the quality and safety of code developed for NASA Missions. Using static analysis helps to ensure that code meets the coding standards/criteria established by the project team  and common coding errors are eliminated before system integration and test. Studies show that the cost of catching errors dramatically increases from one phase of development to the next by roughly a factor of 10. Eliminating errors during implementation results in cost and time savings during integration and testing, which is a particularly important cost-saving factor for projects using high-fidelity testbeds.

When coding is being obtained by Acquisition, the code is being generated by others. In these cases, project team members efforts are directed toward: 

  • Ensuring that the third party coders understand the requirements that the code must meet
  • Ensuring that the code provided meets the requirements. This includes coding standards, and performance objectives at a minimum. 

5.1 Related NPR 7150.2 SWEs

SWE-060 - Coding Software
SWE-061 - Coding Standards
SWE-135 - Static Analysis

4.2 Related Topics and Process Assets

Topic 7.3 - Acquisition Guidance

6. Unit Test

Unit testing is the process of testing the range of inputs to a unit to ensure that only the intended outputs are produced. By doing this at the lowest level, fewer issues will be discovered when the components are later integrated and tested as a whole. Therefore, during unit testing, it is important to check the maximum and minimum values, invalid values, empty and corrupt data, etc. for each input and output to ensure the unit properly handles the data (processes or rejects it).

Software testing is required to ensure that the software meets the agreed requirements and design. The application works as expected. The application doesn’t contain serious bugs, and the software meets its intended use as per user expectations.

Unit test procedures are to be repeatable so that future runs can confirm that any identified flaws have been corrected and for regression purposes to ensure that any new changes do not introduce new flaws in the software. As stated in SWE-062, unit testing can be described as the confirmation that the unit performs the capability assigned to it, correctly interfaces with other units and data, and represents a faithful implementation of the unit design.  

6.1 Related NPR 7150.2 SWEs

SWE-062 - Unit Test

SWE-066 - Perform Testing

SWE-186 - Unit Test Repeatability

6.2 Related Topics and Process Assets

STP - Software Test Plan

7.  Integration

Integration is the assembly of discrete code components into a deliverable product that can be installed and used as a finished product. Code is typically used to monitor and control some other machine or device.

The deliverable product of coding must be tested in an environment that replicates the environment in which it will operate in service. See SE-Testing. 

 A software version description document (VDD) is used to identify and record the exact version of software to be delivered to a user, support, or other sites. 

Software development tools contain software defects.  Commercial software development tools do have software errors.  Validation and accreditation of the critical software development and maintenance tools ensure that the tools being used during the software development life cycle do not generate or insert errors in the software executable components.  This requirement reduces the risk in the software development and maintenance areas of the software life cycle by assessing the tools against defined validation and accreditation criteria.  The likelihood that work products will function properly is enhanced and the risk of error is reduced if the tools used in the development and maintenance processes have been validated and accredited themselves. This is particularly important for flight software (Classes A and B) which must work correctly with its first use if critical mishaps are to be avoided.

7.1 Related NPR 7150.2 SWEs

SWE-063 - Release Version Description
SWE-136 - Software Tool Accreditation

7.2 Related Topics and Process Assets