6.3  Managing Software Risk  Analyzing hazards that are introduced by software, or where software is one of several  contributing factors, is different from analyzing hazards that can be caused by hardware that  fails or wears out. Some of the unique characteristics of software include:  • Software Development Lifecycle (SDLC) – Software follows a defined lifecycle resulting in robust outcomes. Successive steps of architecture, design, coding, development (changes), Quality Assurance / testing (including logic, flow, load, stress, automation, regression, and union), demonstration (user acceptance), release (with configuration freeze), and “hot fixes” 3  eventually reach an acceptable failure ratio. It is with after-the-fact enhancements and backtracking that field failures often arise. • Software does not wear out. When software fails, it may be due to a design or implementation defect that has always existed (i.e., a latent defect), a recent enhancement not subject to the full SDLC, or a change in the operating environment that the software was not designed to accommodate. • Software usually fails without warning. Robust software includes error detection and correction functions to find and fix typical problems using “restores,” “restarts,” and optimization tools. Abnormal error conditions, unexpected process terminations, and long-duration problems not encountered during testing may still arise. Latent defects, specification errors, and issues with enhancements may have existed before the release of the product and may only be triggered or recognized once many software modules are in broad use under a stressing variety of field operating conditions. • Software can be more complex than hardware. It is common for device software to be hundreds of thousands or millions of lines of code long. Reuse of existing code modules helps reduce errors. Device software may also be integrated with Commercial Off-the-Shelf (COTS) system software, such as operating systems that can easily reach similar sizes. • It is difficult to test all of the software in a device and nearly impossible to test all combinations of inputs and branching. Modular design helps isolate code into independent blocks. • A line of software code can be easily changed. However, determining the consequences of that change is more difficult. • Seemingly insignificant changes in one area of software functionality can lead to defects in unrelated areas of functionality. • Requirements validation is most effective when analysis is performed early in the development of the requirements. • The AMS requires that the software design be commensurate with the severity of any identified hazard and identifies RTCA 4  DO-278A,  Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems , as the preferred means to implement that rigor. This requirement spans the AMS lifecycle and includes In-Service Management. Any changes to fielded 3. A “hot fix” is a single, cumulative package that includes information (often in the form of one or more files) that is used to address a problem in a software product (i.e., a software bug). Typically, hot fixes are made to address a specific customer situation. 4. RTCA, Inc., is a private, not-for-profit association founded in 1935 as the Radio Technical Commission for Aeronautics; it is now referred to simply as “RTCA.” 6_SRMGSA_202003  Originally published March 2020  Uncontrolled copy when downloaded  38