This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2D
See edit history of this section
Post feedback on this section
4.4.2 The project manager shall implement the software design into software code.
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
1.2 Applicability Across Classes
Classes F and G are labeled with "X (not OTS)." This means that this requirement does not apply to off-the-shelf software for these classes.
Class A B C CSC D DSC E F G H Applicable?
Key: - Applicable | - Not Applicable
A & B = Always Safety-Critical; C & D = Not Safety-Critical; CSC & DSC = Safety-Critical; E - H = Never Safety-Critical.
This requirement begins the implementation section of the NPR 7150.2. It acknowledges that 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 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).
Once the software development team has completed the software architecture and the software detailed design, the exacting task of turning the design into code begins. The use and adherence to the project's software coding standards will enhance the resulting code and help reduce the coding errors (see SWE-061). In a team environment or group collaboration, the use of coding standards ensures uniform coding practices, it reduces oversight errors and the time spent in code reviews. When NASA software development work is outsourced to a supplier (see SWE-038), the agreement on of a set of coding standards ensures that the code produced by the contractor meets all quality guidelines mandated by NASA-STD-8739.8, Software Assurance Standard. 278
The software development team uses accredited tools to develop the software code (see SWE-136). This may include accredited tools that have not been previously used or adapted to the new environment. The key is to evaluate and then accredit the development environment and its associated development tools against other environment/tool systems that are accredited. The more typical case regarding new software development is using accredited tools in an accredited development environment that have not been used together previously, and thus are not accredited as an integrated system. Many NASA missions and projects have used modeling tools like Simulink and Matlab. Auto-generated code (e.g., code from generators like MatrixX and Real Time Workshop) has been successfully used in the past and is an important approach for developing software on current and future NASA projects. The potential for bugs, sometimes difficult to find, and the certification of the generated code are two problems the software development team needs to be aware of and plan for as the software coding occurs.
Smaller software work products can be completed with a few stand alone tools. Larger software work products will benefit from the use of an integrated development environment (IDE) for producing the code. An IDE (also known as an integrated design environment) is a software application that provides comprehensive facilities to software coders and computer programmers for software development.
An IDE normally includes the following tools:
- Source code editor (a text editor for editing the source code).
- Compiler and/or an interpreter (a program (or set of programs) that transforms source code written in a programming language (the source language) into object code).
- Build automation tools (activities or work aids that script or automate the wide variety of tasks that software developers do in their day-to-day activities).
- Debugger (a program run on the software to surface coding errors or other software work product issues).
An IDE developed for a particular application may have more tools. The Process Asset Library (PAL) at the performing Center is the first place to search when looking for an existing IDE to use.
This Handbook, along with the Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook, provides an extensive listing of individual tools that have been developed for particular applications (see section 5.1 of this SWE). The tool list contains both NASA and commercially developed products. SPAN has several examples of design environments. PALs from other Centers, easily located by NASA users through the NASA Engineering Network (NEN), are also good places to search for individual tools and developed IDEs.
Code generated by the use of an IDE results in output language from the compiler, usually the native machine language of the system. The work accomplished in this phase of the software life cycle includes the coding of the algorithmic detail that was developed during the component level design activities. This results in the coding needed for manipulating data structures, effecting the communications between software components across their interfaces, and implementing the processing algorithms allocated to each component of the software work product.
The software team performs code unit testing and debugging regularly to help find errors early in the coding cycle to avoid expensive and costly fixes in the systems and integration test case phases of the software life cycle. The use of unit testing is intended to confirm that the software work product performs the capability assigned to it, correctly interfaces with other units and data, and represents a faithful implementation of the unit design. Static analysis tools are used to help uncover a variety of problems in the code (dead code, security vulnerabilities, memory leaks, etc.) Debugging can be done with various tools, but experienced and knowledgeable personnel often are needed when addressing the code that supports complex software architectures and designs. Code walk-through and inspections by peers can help identify and correct issues, and reveal opportunities for applying better coding practices.
Compiling may take one pass or it may take multiple passes. Compiling will generate optimized code. Often the execution of one pass through the compiler does not result in all the possible optimizations in the code. A good practice then would be to plan on multiple compiler passes to achieve the maximum amount of code improvements. However, optimization is but one of many desirable goals in software work product development, and is often at odds with other important goals such as stability, maintainability, and portability. At its most cursory level (e.g., efficient implementation, clean non-redundant interfaces) optimization is usually beneficial when applied. But at its most intrusive (e.g., inline assembly, pre-compiled/self-modified code, loop unrolling, bit-fielding, superscalar and vectorizing) it can be an expensive source of time-consuming recoding, recompiling, and bug hunting. Be cautious and wary of the cost of optimizing your code. 208
Additional guidance related to software coding may be found in the following related requirements in this handbook:
4. Small Projects
No additional guidance is available for small projects. The community of practice is encouraged to submit guidance candidates for this paragraph.
- (SWEREF-368) Software Version Description Template, GRC-SW-TPLT-SVD, 2011. This NASA-specific information and resource is available in Software Processes Across NASA (SPAN), accessible to NASA-users from the SPAN tab in this Handbook.
Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).
NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.
The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.
6. Lessons Learned
No Lessons Learned have currently been identified for this requirement.