SOFTWARE CONSIDERATIONS IN AIRBORNE SYSTEMS AND EQUIPMENT CERTIFICATION

R euse has been defined variously: Definitions range from " the systematic practice of developing software from a stock of building blocks, so that similarities in requirements and/or architecture between applications can be exploited to achieve substantial benefits in productivity , quality, and business performance " [1] to " the process of creating software systems from predefined software components " [2]. The first definition is seemingly more complete, but the second definition is less restrictive and more useful. Too often in literature, a purist attitude is taken toward reuse. For example, often the term reuse is applied to only those elements that can be used without change or to only those elements that have been designed and configured for reuse. For this article, therefore , reuse is defined simply as using previously existing software artifacts. Artifacts include all products of a certification development process and include plan-Reuse Factors Functional Alignment Two aspects of functional alignment can affect the reuse strategy adopted. The first aspect, applicability, is a determination of how well the existing require-ments/functionality align with the requirements of the target application. Do the artifacts serve the intended pur-pose? How much must the artifacts be modified to accommodate any new func-tionality? The second aspect also concerns the alignment of new functionality to existing functionality, although in the opposite respect. Does the existing configuration contain more functionality than is needed for the targeted application? What must be done to accommodate this additional functionality? The issues surrounding extra func-tionality are prevalent with design-for-reuse component libraries. These libraries are designed to include all possible future functionality needs and, by their very nature, include additional func-tionality. These existing configurations typically contain more functionality than is needed for the targeted application. How, then, must this additional functionality be accommodated in a certifiable software system? A variety of strategies are available to handle extra functionality. Seemingly, the most simple is to strip the unnecessary functionality from the configuration (from requirements through verification arti-facts). Conceptually, this is the simplest approach, but this may not be the most cost-effective approach. Additional unused functionality may be retained in the code as long as the mechanism by which such code could be inadvertently executed is prevented, isolated , or eliminated [3] is verified. In other words, although the code is present, its non-availability within a specific application must be demonstrated. Typically, this means that the unused functional interface must be …