UNDER CONSTRUCTION

In this example, the Div bodies were distributed into child pages. Click on a link in one of the cells in the row below to open the content. 

1. Requirements2. Rationale3. Guidance4. Small Projects5. Resources6. Lessons Learned7. Software Assurance

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