- 1. The Requirement
- 2. Rationale
- 3. Guidance
- 4. Small Projects
- 5. Resources
- 6. Lessons Learned
- 7. Software Assurance
4.4.3 The project manager shall select, define, and adhere to software coding methods, standards, and criteria.
NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.
SWE-061 - Last used in rev NPR 7150.2D
3.3.2 The project shall ensure that software coding methods, standards, and/or criteria are adhered to and verified.
|Difference between A and B|
Added requirement to select coding methods, standards, and/or criteria.
4.4.3 The project manager shall select, adhere to, and verify software coding methods, standards, and/or criteria.
|Difference between B and C|
Removed the requirement to verify.
4.4.3 The project manager shall select and adhere to software coding methods, standards, and criteria.
|Difference between C and D||Added the word 'define'|
4.4.3 The project manager shall select, define, and adhere to software coding methods, standards, and criteria.
1.3 Applicability Across Classes
Key: - Applicable | - Not Applicable
A & B = Always Safety-Critical; C & D = Sometimes Safety-Critical; E - F = Never Safety-Critical.
To ensure safety, security, reliability, quality, maintainability, readability, and testability of the NASA code products.
NASA programs and projects have multi-year life cycle times. Often the software personnel who develop the original software work products move on to other projects. These developers are then backfilled on the team by other developers for the remainder of the development, operations, maintenance, and disposal phases of the life cycle. This personnel turnover process may occur several times during the project's life cycle. 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.
There are five key benefits of using coding standards:
1. Understanding, maintainability, and readability of the code.
2. Consistent code quality — no matter who writes the code.
3. Software security from the start.
4. Reduced development costs.
5. Testability of the code.
Coding standards help prevent or reduce unsafe coding practices such as defect-prone coding styles, security issues from specific coding sequences, and numerous coding errors, mistakes, and misunderstandings.
3.1 General Coding Standard Guidance
Planning for the adoption and use of coding standards at the beginning of a software development activity sets the right tone and approach for the development team.
Software coding standards are classified by language, usage, and severity levels.
To assist you in fulfilling this requirement, interpret the text in section 1 as "software coding methods," "software coding standards," and "software coding criteria." Also, interpret the terms "methods" and "criteria" as indicative of the software developer's style.
Correlations between bugs and coding practices resulted in rules that helped prevent coding errors from occurring. These activities resulted in recommendations to develop and use coding standards.
In a team environment or group collaboration, the use of coding standards ensures uniform coding practices and reduces oversight errors and the time spent in code reviews. When NASA software development work is outsourced to a supplier (see Topic 7.3 - Acquisition Guidance), having a set of coding standards in place helps ensure that the code meets quality requirements mandated by NASA in the NASA Software Assurance Standard, NASA STD 8739.8.
A coding standard document may be written as a general document that is independent of any project. Project-specific needs are then added as amendments to the document. Note that there is an important difference between a coding style and a coding standard. A coding style specifies how you indent lines or employ tabs and spaces to make the code easier to read by the software development team. A coding standard, which often includes a coding style, goes beyond just how to name a variable. It tells you how that variable is to be treated and when it is to be used (and not used).
3.2 How Coding Standards are Classified
Software coding standards are classified by language, usage, and severity levels. Industry experts determine Language-specific rules and best coding practices in that particular language.
Coding standards should address (for all the languages used):
- Code structure (includes overall project layout (files, and so on), classes, resources, and other source file types).
- Error handling (describes how objects handle errors, reporting, and logging).
- Module size (should be limited).
- Library routines, especially the following:
- Operating system routines.
- Commercial library routines (e.g., numerical analysis).
- Project-specific utility routines.
- Constants and data types (rules for defining).
- Global data use.
- Compiler-specific features are not in the language standard.
The following items may be an integral part of the coding standard to the extent their implementation affects the execution of the software. Otherwise, they are part of the coding style.
- Formatting: Includes the use of white space, indentation, and length of statement lines in code. Some standards might include, for example, common editor setup and handling for tabs versus spaces for indentation.
- Naming conventions: Specifies how developers name their methods, classes, variables, events, and parameters.
- Comments: An English description in the code that explains the logic of the code. (Quality code is usually self-documenting by default.) The use of quality commenting gives quality code better maintainability and easier understandability.
3.3 Adherence and Verification
Assuring the developed software's adherence to the coding standards provides the greatest benefit when followed from software development inception to completion. Coding standards are selected at the start of the software development effort. Verification activities of the software work products include reviews, such as peer reviews and inspections (see SWE-087), and assessments of how the coding standards are used to develop the software work products.
Automated tools for assessing adherence to standards at appropriate reviews, or even on a batch mode run overnight, will assist the project team in adherence and verification.
Training should be provided for the software development team to use the logic model checkers for the analysis and verification of flight software.
3.4 MISRA and CERT-C Coding Standards
Two example coding standards to improve safety, reliability, and security in software systems are MISRA, and CERT C. MISRA C has become the de facto standard for embedded C programming in safety-related industries and is also used to improve software quality even where safety is not the main consideration.
3.5 How to Interpret the "and/or" Phrase in the Requirements Statement
The "and/or" in the text of the requirement statement is meant for flexibility in tailoring the requirement to the project's needs. Inappropriate (e.g., less "critical") settings, a subset of ”methods, standards, criteria” would be sufficient and compliant. For human-rated applications, the project would want to cover methods, standards, and criteria (e.g., the use of the Klocwork® Insight tool as part of the method,
MISRA C (a software development standard for the C programming language developed by MISRA (Motor Industry Software Reliability Association)
as part of the standards, avoidance of the project's restricted language constructs as criteria, etc.).
NASA-specific coding standards information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.
SPAN - Software Processes Across NASA
SPAN contains links to all of the Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. 197
Additional guidance related to the planning and control of software coding standards and where they may be used may be found in the following related requirements in this Handbook:
4. Small Projects
Smaller projects may consider using previously developed/tailored coding methods, standards, and guidelines rather than developing their own. These standard applications may be available in the software Process Asset Library (PAL) of other Centers, if not available at the performing Center.
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
6.1 NASA Lessons Learned
The NASA Lessons Learned database contains the following lessons learned related to coding standards:
- Software Design for Maintainability. Lesson Number 0838 526: NASA has long recognized that software maintenance is a large cost driver in its software systems. Early planning for maintenance, which includes appropriate and consistent coding standards, coding styles, and software configuration management systems, helps hold down software maintenance costs over the software life cycle. The lessons learned citation given below provides additional information on this topic of coding standards.
- Mars Pathfinder Flight Software Development Process (1997). Lesson Number 0590 510: The software developer should also recognize that there is a benefit to using coding standards dedicated to the project at hand. As this set of lessons learned from the Mars Pathfinder project shows, even though the coding standards and styles were tailored for the project, maintaining the set of derived coding standards for future upgrades and improvements will assure cost control.
The reader of these lessons learned can also indicate that the use of tailored coding standards for a new project raises the potential for error if extensive reuse of software work products is anticipated.
- Static Software Analysis of the NASA Autonomous Flight Termination Software Lesson Number 24503 563:
- Software development teams should specify specific coding standards to be applied to the software development for both ground utilities and flight software.
- Software development teams should configure the static analysis tool to best match the specified coding standard. Matching the coding standard and the static analysis tool capability leverages the tool as a verification asset.
- Software development teams should define how the reported issues are to be reviewed, and what defines an issue that should be corrected.
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
7.2 Software Assurance Products
- Static analysis of the source code to a coding standard
The SA independent analysis of the software code to the software coding standard, including any risk or issues.
- Coding standard (Secure coding standard)
- Results of static code analysis showing compliance with the project's coding standard
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 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.
- # coding standard violations identified (Open, Closed, type of violation, Severity)
- # of software process Non-Conformances by life cycle phase over time
Task 1: Review the project software development/management plan to learn what kind of software coding standards, methods, rules, and principles are used for the project. The coding standards could include any project-defined standards that dictate the safe use of code, secure coding standards, reliability coding standards, etc. They may also include a set of “principles” or best practices that have been collected for particular software applications, such as principles for developing flight software. These coding standards and principles are reviewed by software assurance during the development and selection of the project processes, as per SWE-013 - Software Plans. After becoming familiar with these standards, practices, and principles, analyze the software code using the static analyzers' results to help determine whether these standards, methods, and principles are being used consistently. Any risks or issues should be brought up with project management.
Task 2: Software assurance will perform independent static code analysis on the coding standard practices, methods rules, and principles. They should review the results of the static code analysis runs to determine whether the project's coding standards, etc., are being followed. Results should be reported to the project management at the end of the analysis. Information on code standard usage, static code analysis tools, their effectiveness, and the developers’ responses to the results should also be shared with the project management.