9.01 Software Design Principles Code that is believed to be unreachable poses a residual risk to the system in the event that it is executed inadvertently. One approach to implementing this design principle is to perform an analysis of unnecessary and/or unreachable code early in the life cycle. Although it is possible to identify unused code through manual code reviews, many commercial static analysis tools can be configured to identify unreachable code in an automated fashion. Run-time coverage analysis tools can also be used to identify unused sections of the code, although this technique may only be available later in the life cycle once an executable is available.Regardless of the means of identifying unused or unreachable code, an engineering analysis would be performed to describe the functionality associated with the code, and the relative cost/benefit of leaving it in place versus removing it. If the recommendation is to leave the code in place, the analysis would provide the rationale for doing so, and the justification (e.g., mitigating action) that explains why the included code does not provide a risk to the mission. The focus is on technical risk to the long term mission, not cost. There are significant benefits to re-using software from past missions but each mission has different requirements and re-using heritage software often carries forward software not required by the current mission. Unnecessary and unreachable software can also occur within a mission’s life cycle as system and software requirements change during the software development process. Unnecessary and unreachable software is typically not verified or validated as part of the current mission test programs, as a mission is only required to verify its mission requirements. This creates the potential for negative side-effects, costs and risks during the current mission’s on-orbit life. Table 1 provides sample types of unnecessary or unreachable code. Table 1 Sample Types of Unnecessary and Unreachable Software Sample Types Definition Parameter Checking A section of software that can never be executed because pre-conditions should never be met. For example, a properly developed function will validate all parameters to ensure the function doesn’t perform any illegal actions based upon the input parameters. However, it is possible to write the software system such that it never calls the function with invalid input parameters. In such a case, the error condition checks within the function should never execute. Unused Design Capability Application Program Interfaces (API) are developed to promote software reuse. For example, an Operating System (OS) API will have interface calls for dealing with semaphores (e.g., create, give, take, etc). If a new mission does not require the use of semaphores; then these OS API functions will never be executed. Unused Reuse Capabilities A reused software component/library or set of reused software components/libraries will typically contain capabilities and features not required by a mission. Debug/Test Features Debug and test features, which are not a required part of the operational system, are often required to test the software system. For example, debug software is often used in conjunction with testing Error Detecting And Correcting (EDAC) memory. It is extremely difficult to inject correctable and uncorrectable errors into EDAC memory, whereas a test command can easily inject these erroneous conditions to verify that the application software handles and reports the EDAC errors correctly. While it is desirable to completely eliminate dead code (or unreachable code), it is sometimes not practical or cost effective. However, the existence of dead code must be known and analyzed. The following table describes one way to identify and manage dead and unreachable code during the development life cycle. Table 2. Example Life Cycle-Based Implementation of Dead Code Exclusion Phase A B C D Activities: 1. Document that a flight software (FSW) Reuse Plan and risk assessment of unnecessary and/or unreachable code will be developed. 1. Document the FSW Reuse Approach and the plan for managing unnecessary and/or unreachable code in the FSW Mgmt./ Development Plan(s). 1. Analyze the potential risk of leaving the code in the flight product rather than removing it. 1. Update and analyze the documentation of unnecessary and unreachable code from heritage and newly developed flight products. Verification: Verify at Mission Definition Review (MDR). 1. Verify at FSW Software Requirements Review (SRR) & FSW Preliminary Design Review (PDR) 1. Verify at Critical Design Review (CDR) 1. Verify at FSW Acceptance Test Review None None None None No lessons learned 439 have currently been identified for this principle.
View this section on the website
See edit history of this section
Post feedback on this section
1. Principle
1.1 Rationale
2. Examples and Discussion
2. Identify and document code capabilities/ requirements that are not required for the current mission but are intended to be included in the FSW product(s).
3. Provide initial risk Identification, assessment & anticipated mitigation technique for each known type of unnecessary/ unreachable code.
4. Present analysis at FSW Reviews
2. Remove unnecessary and unreachable software that creates risk.
3. Update software verification plans if justified to reduce risk.
4. Present analysis and risk mitigations at FSW Reviews
5. Update the documentation of unnecessary and unreachable code associated with the intended flight products
2. Remove unnecessary and unreachable software that creates risk.
3. Update software verification plans if justified to reduce risk.
4. Present analysis at FSW reviews.
2. Verify at SDR & PDR
2. Verify at FSW CDR
2. Verify at Pre-Ship Review (PSR) and Flight Readiness Review (FRR).3. Inputs
3.1 ARC
3.2 GSFC
3.3 JPL
3.4 MSFC
4. Resources
4.1 References
5. Lessons Learned
9.06 Dead Code Exclusion
Web Resources
Unknown macro: {page-info}
