National Aeronautics and Space Administration REPORT NO: AC1L1-52 DATE: October 1, 2005 Constellation Program Systems Engineering Exploration Systems Mission Directorate National Aeronautics and Space Administration, Headquarters Washington DC 20546-0001 Software Strategy for Reuse Study Final Report CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Software Strategy for Reuse Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page i Document History Log Status (Baseline/ Revision/ Canceled) Document Revision Effective Date Description Baseline per Directive # CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Software Strategy for Reuse Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page ii Software Strategy for Reuse Study—Final Report Constellation Program Systems Engineering Prepared by: ______________________________________ Dr. David J. Atkinson Study Lead Jet Propulsion Laboratory _____________________ Date Approved by: ______________________________________ Dr. David Atkinson Chair Computers, Software and Automation Integrated Discipline Team Constellation Program Systems Engineering _____________________ Date Accepted by: ______________________________________ Geoffrey Yoder Chief Engineer (Acting) Constellation Program Systems Engineering _____________________ Date CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page iii Table of Contents EXECUTIVE SUMMARY............................................................................................................8 INTRODUCTION .......................................................................................................................10 Purpose...............................................................................................................................10 Study Objectives ................................................................................................................10 Relationship to Exploration Objectives .................................................................10 Relationship to Constellation Modeling and Simulation.......................................11 Relationship of This Study to Other IDT Studies ..................................................11 CCC IDT AC1L1-85 Command and Control Interoperability Study ..................12 AFM IDT Study AC1L1-18 Automated Rendezvous and Docking .....................12 AFM IDT Study AC1L1-19 Mated Flight Control Operations ............................13 CSA IDT Study AC1L1-56 Integrated Systems Health Management Study .......14 CSA IDT Study AC1L1-55 Autonomy and Automation Roadmap for SRR........14 Ground Rules and Assumptions ........................................................................................15 Study Task Description ......................................................................................................15 Key Issues for Constellation Reuse Strategy ....................................................................16 SOFTWARE REUSE...................................................................................................................18 Section Purpose and Scope ................................................................................................18 Background........................................................................................................................18 Various Definitions of Software Reuse..............................................................................19 Constellation and Reuse.....................................................................................................21 Reuse Strategy ...................................................................................................................22 Architecture .......................................................................................................................23 Product Lines .....................................................................................................................24 Software Reuse Success ....................................................................................................26 CASE STUDIES ..........................................................................................................................28 Introduction........................................................................................................................28 NASA Case Studies ...........................................................................................................28 AMMOS Multi-Mission System Reuse Case Study .............................................28 Mission Operations Services Provided.................................................................28 AMMOS as a Software Product Line ..................................................................30 Return on Investment ...........................................................................................30 Lifecycle Considerations ......................................................................................32 Other Challenges of a Product Line Approach .....................................................35 Future Vision ........................................................................................................35 AMMOS Conclusions ..........................................................................................36 ROSE—Flight Analysis and Design Reengineering Case Study ..........................36 Project Description ...............................................................................................36 Project Timeframe ................................................................................................37 CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page iv Process 37 Organization .........................................................................................................38 Training 38 Technical ..............................................................................................................38 Lessons Learned ...................................................................................................38 Checkout and Launch Control System (CLCS) Case Study .................................39 Impact of Cultural Differences on Software Product Specification .....................39 Subsystem Status via Service Provider Model .....................................................40 Framework Encourages Reuse .............................................................................41 Configuration Complexities of Software Reuse ...................................................41 Summary of SEEDS Formulation Team Final Recommendation Report .............42 Introduction ..........................................................................................................42 Definitions ............................................................................................................42 Summary of Findings and Recommendation of the Study ..................................43 GSFC Ground System Reuse Case Study .............................................................45 Non-NASA Case Studies ...................................................................................................45 Introduction 45 Bold Stroke Avionics Software Family, Boeing ....................................................46 A-7E Operational Flight Program, U.S. Naval Research Laboratory ...................47 ShipSystem 2000, CelsiusTech Systems AB .........................................................47 United States National Reconnaissance Office (NRO) Control Channel Toolkit (CCT) 47 NRO CCT and Similarity to Constellation ..........................................................48 Managing Several Teams with SPL .....................................................................48 Need for an Early Architecture .............................................................................49 Technical and Cultural Challenges Using SPL for Constellation.........................49 Constellation Scope and Complexity ...................................................................49 Leadership in Management within SPL Environment .........................................50 Lessons Learned on NRO CCT Project ...............................................................50 Discussion and Analysis ....................................................................................................50 Overview of NASA Case Lessons .........................................................................50 Overview of Non-NASA Case Lessons.................................................................51 Summary of Case Study Challenges and Solutions...............................................52 POTENTIAL BENEFITS OF REUSE.......................................................................................55 Discussion..........................................................................................................................55 Increased Reliability and Overall Quality .............................................................55 Reduced Development Time..................................................................................56 Increased Productivity ...........................................................................................56 Reduced Cost 56 Reduced Development Process Risk .....................................................................59 CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page v Increased Maintainability ......................................................................................59 Continuous Improvement and Increased Evolvability ..........................................59 More Effective and Efficient Use of Specialists....................................................60 Easier Compliance with Standards ........................................................................60 Increased Flexibility ..............................................................................................60 Findings .............................................................................................................................60 RISKS, OBSTACLES, AND MITIGATIONS ..........................................................................62 Introduction........................................................................................................................62 Technical Risks ..................................................................................................................62 Software Inheritance ..............................................................................................62 System Failure ......................................................................................................62 Cost Growth .........................................................................................................63 Legacy Software ....................................................................................................63 Reuse Process Risks ..............................................................................................64 Non-Technical Risks..........................................................................................................64 Organization-Level Reuse .....................................................................................64 Business and Economic Factors ............................................................................64 Legal Factors 65 Psychological Factors and Incentives ....................................................................66 Inadequate Training................................................................................................67 Additional Risk Findings .......................................................................................68 Mitigation Strategies..........................................................................................................68 Mitigation for Inherited Software Risks ................................................................69 Mitigation for Legacy Software Risks...................................................................69 Mitigation for Business and Economic Factors.....................................................70 Mitigation for Psychological Factors: Incentives .................................................71 Additional Mitigation Findings .............................................................................71 SUMMARY OF FINDINGS .......................................................................................................73 Opportunity to Realize Major Benefits from Reuse ..........................................................73 Confidence from a Rich History and Broad Current Work on Software Reuse ................73 Requirement for Success: a Systemic Engineering Technical Approach ..........................73 Importance of and Necessity of Both Technical and Non-Technical Factors....................74 RECOMMENDATIONS ............................................................................................................76 Non-Technical Recommendations .....................................................................................76 Technical Recommendations .............................................................................................79 NEXT STEPS—IMPACT ON REQUIREMENTS ..................................................................85 Traceability to Requirements .............................................................................................85 CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page vi Impact on SEI Constellation Responsible Assignment Matrix (CRAM) products ...........88 Software Management Plan (SMP)—DSM&A ....................................................88 Other Constellation Program Systems Engineering Products ...............................88 Follow-On Studies .............................................................................................................90 ACKNOWLEDGEMENTS ........................................................................................................93 Appendix A: Glossary, Acronyms, and Abbreviations ............................................................94 A.1 Glossary .................................................................................................................94 A.2 Acronyms and Abbreviations.................................................................................96 Appendix B: Bibliography .......................................................................................................100 Appendix C: Study Team Participants ...................................................................................107 C.1 Participants ..........................................................................................................107 C.2 Study Team Bios ..................................................................................................108 Appendix D: D.1 D.2 D.3 D.4 D.5 D.6 Study Team Approach .......................................................................................125 Study Team and Logistics ....................................................................................125 Initial Team Meeting............................................................................................125 Regular Meetings.................................................................................................125 Data Development ...............................................................................................125 Analysis ...............................................................................................................125 Synthesis ..............................................................................................................125 Appendix E: Reuse Metrics Deserve a Warning Label: The Pitfalls of Measuring Software Reuse ...................................................................................................................127 Appendix F: Software Reuse Study Report—A Report for the NASA IV&V Facility ......132 Appendix G: Quantitative Benefits Achieved through Software Reuse ..............................135 Appendix H: Recommended Online Reading ........................................................................137 CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page vii List of Figures Figure 3-1. Market for Reusable Software Artifacts ...............................................................18 Figure 4-1. Mission System Elements .......................................................................................27 Figure 4-2. Dual Lifecycle Approach ........................................................................................35 Figure 5-1. Relative Development Cost vs. Reuse Fraction by Reuse Type (from Jensen, 2004)..............................................................................................54 List of Tables Table 4-1. Impact of Software Reuse on Deep Space Mission Ground Systems ...................29 Table 4-2. Mature System Reuse Advantages ..........................................................................31 Table 4-3. Challenges in System Level Reuse ...........................................................................32 Table 4-4. Product Line Successes .............................................................................................36 Table 4-5. Product Line Challenges ..........................................................................................36 Table 4-6. Case Studies—Lessons Learned* ............................................................................50 Table 5-1. Reported Benefits From Reuse ................................................................................53 Table 5-2. Return on Investment by Reusable Artifact ...........................................................54 Table 6-1. Local Reuse Costs vs. Benefits (Fichman and Kemerer, 2001) .............................63 Table 6-2. Targets for Early Investment to Enable Reuse ......................................................66 Table 9-1. Reuse Impact on Program Systems Engineering Products...................................82 CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Software Strategy for Reuse Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 8 1.0EXECUTIVE SUMMARY This study investigated and develops a strategy for software reuse for the Constellation Program. The study team consisted of a group of multidisciplinary experts from across the NASA Centers, with collective expertise spanning the lifecycle of software engineering from research through operations and software obsolescence. The team investigated what software reuse would mean in the context of the Constellation Program, the benefits that might be earned, and the risks to be mitigated. The team found that “software reuse” is usually defined as either the application of software to a problem other than the original problem the software was implemented to solve; or the designing of the software (and other artifacts) from the beginning for reuse within multiple products, projects, or domains with similar requirements. The first definition of reuse was found to be very limited in potential benefit and otherwise not suitable for a project with the large scale of Constellation, and was not further addressed with the exception of reuse of “legacy” software. The study team focused on the second type of reuse since it rapidly became obvious that these concepts have been applied beneficially to a large number of large-scale commercial, defense, and aerospace projects over the last decade or so. Many case studies have shown that the systematic development and reuse of core assets substantially reduces implementation time and increases product quality. Core assets include requirements, architecture, documentation, code, test plans, experience, management processes, and other products of the software engineering product lifecycle. The Software Engineering Institute has captured and refined the best practices of large-scale reuse for the Department of Defense. The practice is called Software Product Lines. The case studies show that it is critical that the foundations for software product lines are laid early in the project lifecycle, and that the practice receives support from senior project management. The foundations must be laid early, as otherwise, decisions will be made and actions taken that will make it difficult or practically impossible to implement reuse later in the lifecycle. For example, the system architecture must be developed early and with support for reuse as a key objective. If it is not developed with reuse as an objective, is allowed to evolve in an ad-hoc manner, or is partitioned amongst multiple contractors with no contractual incentive to discover and exploit commonality, then it will not support large-scale, project-wide reuse. If the management support for reuse is not established early and supported from the top, then investment, governance, and incentive strategies will evolve that do not support, or even suppress, project-wide reuse. In either case, the benefits of product lines will be lost. The team thus recommends the establishment of a software systems engineering and management office at the Constellation program level that is broadly chartered to execute software product lines within the project. Effective utilization of large-scale systematic reuse within Constellation will require the NASA engineering and management culture to take an evolutionary step forward. The team thus focused much of its time on the risks and obstacles to effective reuse and identified possible mitigations. Several case studies of the development of successful software product lines within CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 9 NASA were developed and studied, yielding important lessons learned. These cases included both flight and ground software systems from four mission Centers. The report concludes with the unanimous recommendation that the Constellation program adopt the software product line engineering methodology as the basis of all software development within the project. The team developed multiple recommendations and identified the next steps to be taken towards this objective. The time to start is now. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 10 2.0INTRODUCTION 2.01 Purpose The purpose of this study was to develop a set of guidelines and policies governing the appropriate strategy for reuse of software to ensure the most cost effective, schedule-efficient, and productive use of development efforts across all elements/projects of the Constellation Program. This was undertaken in support of the level 0 requirements for an “affordable” and “sustainable” exploration program. 2.02 Study Objectives The initial study objectives, which were to investigate and create a “software systems strategy” addressing the Constellation goals of reuse, interoperability, compatibility, and improvement, became too broad for this study. Recognizing that solutions to these goals are strongly interrelated, and that the concept of “reuse” is central to an overall solution, the study team elected to focus the available time and resources on the objective of developing the programmatic and technical precursors to the development of a “Strategy for Software Reuse,” because doing so would enable the timely and efficient development of an actionable strategic reuse plan. It was anticipated that follow-on work would be conducted to develop the actionable strategic reuse plan for Constellation. Therefore the principal objective of this study has been to identify the key benefits, costs, and risks of a reuse-based software engineering strategy for the Constellation Program Systems Engineering Office (with flow-down of requirements and recommendations to Constellation programs) that will help enable interoperability, compatibility, and improvement through effective software engineering for reuse, and will help the Program realize significant benefits from reuse of software engineering artifacts across the multi-mission lifecycles of the various Constellation systems. This report is comprised of an initial set of best practices, risks, recommendations, and linkages to key program systems engineering products with special focus on deliverables for the System Requirements Review (SRR) and consequent requirements for further studies. 2.02.1 Relationship to Exploration Objectives The results of this study will support Constellation policy decisions and architecture development for a software strategy that will be instrumental in “implementing a sustainable and affordable human and robotic program.” In order to “extend human presence across the solar system and beyond,” Constellation systems will require multiple diverse vehicles and systems. Each of the exploration vehicles will require significant software to perform needed tasks from low-level command and control to autonomous operations, and will need to support extensive interoperability and coordination. Software lifecycle costs will only be affordable and sustainable if a strategic architecture for reuse is developed and adopted at the onset so that the development costs of core assets can be amortized across multiple uses of those assets within the vehicles and systems of Constellation. Software reuse, interoperability, and compatibility can only be CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 11 achieved if the program can “develop supporting innovative technologies, knowledge, and infrastructures.” A fully defined strategy for software reuse, interoperability and compatibility will enhance “international participation in exploration” by allowing software from diverse sources to integrate in a predictable manner and with predictable and high-resultant system dependability. Finally, the requirements generation process will be impacted by this study since the software strategy for reuse, interoperability, and compatibility will be a factor in the set of requirements approved at SRR. 2.02.2 Relationship to Constellation Modeling and Simulation Constellation Modeling and Simulation (formerly known as Simulation-Based Acquisition [SBA]) is intended to support program decisions with accurate and timely data. The modeling and simulation activity ensures that the infrastructure of tools, policies, and organizational working groups required for modeling and simulation are built, maintained, and improved as necessary. As an analysis effort generated by Constellation Integrated Discipline Team (IDT) efforts, this study has been mindful of and compliant with policies regarding analysis tool development and use. There are two complementary aspects to the relationship between modeling and simulation and the area of reuse. One is that, as Constellation evolves, the tools developed for modeling and simulation must evolve as well, and reuse and compatibility of those tools will be an issue. The other is that the tools will be used to test systems that include reused software. Adoption of an architecture and framework for reuse will provide a vehicle for effective evolution of supporting tools and provide a basis for testing of reused software and newly developed software that is intended for future reuse. 2.02.3 Relationship of This Study to Other IDT Studies There are several other IDT studies that are also concerned with the major aspects of software reuse. These studies include but are not limited to: • Command Control and Communications (CCC) IDT AC1L1-85 Command and Control Interoperability Study (C2I) • Aerosciences and Flight Mechanics (AFM) IDT AC1L1-18 Automated Rendezvous and Docking (AR&D) • AFM IDT AC1L1-19 Mated Flight Operations (MFC) • Computers, Software and Automation (CSA) IDT AC1L-55 Autonomy and Automation Roadmap for SRR Each of these has important software reuse aspects related to the focus of their study. In particular, each study is developing elements of the overall architecture that must in the end be made compatible with the objective of facilitating reuse. These IDT studies are described in the following subsections. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report 2.02.3.1 Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 12 CCC IDT AC1L1-85 Command and Control Interoperability Study The C2I and the Autonomy and Automation Roadmap for SRR studies (see subsection 2.2.3.5) are both analyzing the sets of software product lines for systems and subsystems. Exploration missions pose new challenges for command and control, because they combine operation of unmanned automated robotic spacecraft with relatively autonomous manned spacecraft. The C2I study collected historical data from a set of manned and unmanned spacecraft. For the X-15, Mercury, Gemini, and Apollo programs, control was either hardwired into the spacecraft or performed by the crew. Although these were built as custom systems, there has been a pattern of reusing computer systems and software programs in migrating from Apollo to Shuttle and Station. The number of lines of code and number of available commands increases for newer spacecraft in the manned space programs. Unmanned spacecraft tend to use more complex commands. Manned spacecraft have at least an order-of-magnitude more telemetry parameters than unmanned spacecraft from the same time era. The study also looked into locus-of-control issues, i.e., the designation of what entity (ground, element automation, or crew) is authorized to issue commands to a spacecraft. When two vehicles rendezvous (such as Shuttle docking at the ISS or Shuttle retrieving a payload), one spacecraft is designated as the controlling entity while the other spacecraft is the passive target. To support Exploration missions, inter-element command and control autonomy and automation will be needed that requires shifting the locus of control among the Constellation elements, depending upon the mission phase and configuration of vehicles. This drives a substantial need for a software reuse strategy that allows software to be shared between Constellation elements that are designed and built by different contractors during different time frames. The study recommends further historic research (particularly for data involving the complexity of commands used for different spacecraft) in order to (a) form a clearer idea of the trends in locus of control, and (b) identify the need to distribute and shift the locus of control to support the needed inter-element command and control for autonomous and automated Exploration missions. 2.02.3.2 AFM IDT Study AC1L1-18 Automated Rendezvous and Docking Successful execution of the Constellation Program will require extensive utilization of automated and autonomous rendezvous and docking capability and operations infrastructure for both crewed and un-crewed missions. This requires a significant element of interoperable command and control. This study provides the trade results and quantitative data required for programmatic decisions, and the requirements development effort to produce a Constellation rendezvous and docking Interface Requirements Document (IRD) as specified in the Exploration level 1 requirements release. It also establishes the basic interface requirements that envelope the performance and operations for rendezvous and docking between various Constellation elements. This study is a critical component of the overall NASA strategy of implementing a sustainable and affordable CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 13 human and robotic program. And again, this drives a substantial need for a software reuse strategy that allows software to be shared between Constellation elements that are designed and built by different contractors during different time frames. 2.02.3.3 AFM IDT Study AC1L1-19 Mated Flight Control Operations The Exploration missions require the capability for two or several vehicles to be operated together as a single flight unit. This requires command and control intercommunication between mated elements, which again drives a substantial need for a software reuse strategy that allows software to be shared between Constellation elements that are designed and built by different contractors during different time frames. The software reuse requirements include command and control authority distribution options, information flow across mated elements, changes in vehicle static and dynamic characteristics, verification and validation (V&V) of mated vehicle dynamics; and guidance, navigation and control (GN&C) configuration changes, interface mechanism variability, articulation of vehicle components, mass redistribution, and adaptation to multiple flight configurations and operating modes. Each element will have its own GN&C subsystem, capable of executing GN&C functions and with some degree of built-in redundancy for that element, but not necessarily adequate for the mated vehicles. Exploration mated-element command and control software will require shifting the locus of control among mated elements, depending upon the mission configuration and phase. Mated flight command and control software requirements for Crew Exploration Vehicles (CEV) may require over-design to accommodate controlling various configurations of mated flight control challenges. Command and control interoperability for mated flight control (MFC) requires a methodical approach to managing GN&C subsystems redundancies for multiple mated configurations, defining essential components (hardware/software) for each GN&C subsystem, defining MFC GN&C performance requirements for the mated vehicles, identifying all possible GN&C subsystems (feasible set) that can satisfy MFC GN&C performance requirements, and selecting an optimal GN&C configuration from the feasible set. Each element will have independent actuator sets capable of controlling that element, but not necessarily adequate for the mated vehicles. The CEV’s C&DH subsystem must be capable of communicating information across the mated interfaces for MFC operations. A candidate information set across mated interfaces includes mass, center of mass, moments of inertia in three degrees of freedom (3DOF), position, attitude, attitude rates, velocity, acceleration, and deltas, consumables inventory and rate of use; particularly propellant; and shared electrical power, including generation, usage, and battery charging rates and state-of-charge. The dynamic model of all mated configurations involving CEV must be sufficiently accurate to reliably predict MFC responses to within a “to-bedetermined” specification under both nominal and off-nominal conditions. The GN&C subsystem performance must be sufficiently robust during all MFC operations including both nominal and off-nominal conditions, driving requirements for software reuse across a complex of Constellation elements. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report 2.02.3.4 Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 14 CSA IDT Study AC1L1-56 Integrated Systems Health Management Study Integrated Systems Health Management (ISHM) is a key component for software reuse and interoperability across Constellation elements. ISHM is a system engineering discipline that addresses the design, development, operation, and lifecycle management of components, subsystems, vehicles, and other operational systems with the purpose of maintaining nominal system behavior and function and assuring mission effectiveness under off-nominal conditions. For the Constellation Program, ISHM will enable (1) autonomous and automated launch-abort and crew-escape capability; (2) efficient testing and checkout of ground and flight systems during various mission stages; (3) monitoring, verification, and trending of ground and flight system operations and performance; (4) enhanced situation awareness and control options for ground personnel and crew; (5) vehicle autonomy (self-sufficiency) in responding to off-nominal conditions during long-duration and distant exploration missions; (6) in-space maintenance and repair; and (7) efficient ground processing of reusable systems. Many of these scenarios require rapid response to prevent or mitigate mission- or life-threatening conditions. Effective health management requires integration of command and control information from multiple systems and subsystems developed by a multitude of contractors over a period of decades, thus driving requirements for software reusability. It is necessary to approach ISHM as an integrated systems engineering discipline. Traditional health management functional needs are allocated to individual subsystems and components with no requirements for commonality, interoperability, or even data interchange among implementations. This haphazard approach to health management results in inefficiencies in system design and operation, inconsistent coverage of mission- and life-critical failure modes, and inability to recover from failures in a predictable manner. Human involvement is often required to interpret and integrate pieces of information obtained from disparate subsystems in order to make mission-critical health and safety decisions at the systems level. Experience with aircraft and spacecraft shows that an integrated approach to development, deployment, and management of ISHM requirements, architectures, and systems is critical to mission success. Such integration can be achieved only by defining and enforcing software reuse standards and best practices for ISHM design, certification, operations, interoperability, supportability, and knowledge management across Constellation programs. 2.02.3.5 CSA IDT Study AC1L1-55 Autonomy and Automation Roadmap for SRR This study includes investigation of both autonomous and automated software capabilities as they apply to the Constellation Program. Crewed as well as robotic missions are covered in the study. Today’s mission management roles and responsibilities between onboard crew and mission control need to evolve to accommodate missions beyond the Earth-moon system. With increased travel times for communication and telemetry, a great deal of authority for decisionmaking will be transferred to the onboard crew. As such, onboard expert systems, automation, and insight into spacecraft systems will be required to provide the tools for the crew to make CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 15 educated and informed decisions. There must be appropriate balance between human versus computer functions (automation) and ground versus onboard functions (autonomy). The strategy for autonomy and automation will have major impact on the design of these systems as the capability for manual control evolves into automatic control. Schedule and cost constraints will dictate the continued software reuse of legacy capabilities, leading to interface issues, model and data compatibilities, continuous maintenance of redundant (but different) information sets, and reverse engineering of legacy systems for reuse. Designing automation and autonomy software systems for reuse and evolution requires hardware independence, language and development infrastructure independence, and placing appropriate performance requirements on supporting hardware and software infrastructure. 2.03 Ground Rules and Assumptions There are no simple answers for the core themes of Constellation Program Systems Engineering: reuse, interoperability, compatibility, and improvement. Experience has shown that effective software engineering strategies for reuse must be planned and in place very early in the Program lifecycle. For example, Clements and Northrop (2001) show that early commitment to software product lines (the most comprehensive form of reuse) is a key success factor. A study that examines the requirements of the Constellation Program missions and product lifecycles versus the best practices in software engineering for reuse, is essential. The Constellation Program will develop a series of vehicles with space and ground systems that will be refined repeatedly through incremental development. The spacecraft will have extensive computing capabilities and require large and complex on-board software systems with millions of lines of code. Constellation system software will need to be continuously written, rewritten, modified, repaired, tested, verified, validated, deployed, and obsolesced during sustained operations. It will not be possible to sustain such a system over time without applying software engineering principles to effectively modularize the system such that system elements can be added, removed, and evolved independently for both flight and ground. There is a clear requirement for software systems to be sustainable and interoperable for the lifetime of Constellation elements, possibly up to 20–30 years for certain reusable in-space systems. In the arena of software, with its accelerating progress, concepts of software reuse will be enabling for this requirement. This study will help drive technology requirements for the Earth-local and lunar missions. In fiscal 2005, this topic is the responsibility of the Computers, Software and Automation IDT, with support from several other related IDTs. In future years, the Program Systems Engineering activities will further address this topic. 2.04 Study Task Description The study team sought to answer the questions: • What is software reuse and what does it mean in the context of Constellation? CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 16 • What are the potential benefits? • What are the risks and obstacles? • What can be done to mitigate risks and avoid or overcome obstacles? Deliverable content in this Final Report of the study includes: • Data and analysis regarding these questions • Recommendations in multiple technical and non-technical areas • Figures of Merit, metrics and measurements relevant to software reuse processes and products across the software system and mission lifecycle(s) • Identification of Constellation program systems engineering work products that are impacted by the study, with a focus on the major products required for SRR • Recommended next steps • Recommended follow-on studies After the first draft of this study was released, a subset of the original team broadened the scope of the study from the original scope of “software reuse” to the larger range of “reuse,” “interoperability,” “compatibility,” and “improvement.” This was done in response to a review that noted that Software Product Lines, a mature reuse discipline developed for use on largescale projects, was a superset of the study recommendations and a comprehensive solution. Section 3.7 of this report outlines the Software Product Line practice areas. 2.05 Key Issues for Constellation Reuse Strategy Early in the conduct of this study, it became apparent that the study team had a broad set of concerns, issues, ideas, and forward-looking approaches to the basic challenge of effective software reuse. Four unifying themes that emphasize the importance of reuse strategy are highlighted below: • The greatest return from software reuse occurs when software artifacts are planned from the beginning as reusable assets. Hence, this report focuses on planned reuse; ad hoc or opportunistic reuse is assumed to be part of the normal development process and is not emphasized as a key element of Constellation reuse strategy. • Perhaps the most important part of creating a planned reuse strategy is the focus on upfront programmatic planning and investment in reusable assets (software artifacts, tools, infrastructure). Once the software architecture and product line plans are in place, programmatic plans can be made for developing key assets. This requires more up-front investment in software than is typical for a NASA mission. It is this upfront investment that will provide the greatest return in terms of cost, reliability, and schedule savings (see discussion in Sections 3.0 and 4.0 and recommendations in Sections 8.0 and 9.0). CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 17 • The product line approach appears to have significant advantages for the Constellation Program. This approach is discussed in multiple places in this report and is an important part of the recommendations in Section 8; however, the productline concept as an integrating theme for the Constellation Reuse Strategy has not been fully developed. Hence, this topic is proposed as a follow-on study (Section 9.0). • In order to make software reuse a part of the Constellation Program from its inception, it is critical to include the CEV project and to ensure that project’s compliance with the adopted recommendations of this report. The next window of opportunity to impact CEV is the upcoming Call-for-Improvement (CFI) to be released by early FY06. In this CFI, specific sections devoted to software reuse policy need to be included. For instance, it is recommended that the CEV Project’s Software Management Plan and the applicable Constellation SEI standards and other products passed as requirements to the CEV project, should include provisions based on an explicit Software Reuse Plan (see Section 8.1.3). CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 18 3.0SOFTWARE REUSE 3.01 Section Purpose and Scope This section introduces the fundamental concepts of software reuse and how software reuse should be incorporated into the Constellation Program lifecycle. After a brief discussion on the history of software reuse, a working definition of software reuse is provided, along with the scope of the concept. Subsequent subsections describe key aspects of software reuse within the context of the Constellation Program lifecycle. First, some background is presented. The notion of a reuse strategy is then presented, and shown to be a key element to effective and high-payoff utilization of software reuse. Next, the concept of software architecture is described, and again shown to be a key element to reuse within the program. The concept of a software product line is described and shown to enable a comprehensive and systematic reuse program over the total lifecycle of the Constellation Program. Subsequent sections describe additional practices that have been found to be beneficial and others that have been nonproductive. 3.02 Background The reuse of software code in order to improve software productivity was first proposed by M. D. McIlroy (1968) in an invited address that he presented at the groundbreaking NATO Conference on Software Engineering. More recently, IEEE Transactions on Software Engineering dedicated a special section to the same topic (TSE, 2005). The general claims and advantages for software reuse have remained remarkably stable over the decades: cost, schedule, and reliability may be improved—but are not necessarily improved—by reusing various software development assets (code, requirements, specifications, tests, knowledge, etc.) rather than recreating them over and over again. There are three core issues that are central to the practice of software reuse: 1. Establishing and refining the reuse strategy. The software reuse strategy lays out the plan for investing in reusable assets (software artifacts, tools, infrastructure) in order to achieve long-term benefits. It includes the specification of a software architecture, product line plans, policies and incentives for reuse, as well as a business plan that shows the future return to be achieved from reuse investments. The business case motivates investment now for benefits accrued later (Nazareth, 2003). 2. Improving the technical elements of the reuse strategy. The technical challenge of software reuse is, in essence, how to make finding and incorporating reusable core assets more efficient than recreating those assets from scratch. This includes questions of how to create reusable core assets in the first place (investment), as well as how to find and utilize them later (accrued benefit), how to maximize the technical opportunities for reuse (typically via software product lines [Lutz, 2002]), and how to quantify and manage the risks of reuse (Yao, 2004). CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 19 3. Improving the non-technical elements of the reuse strategy. Research and practical experience have shown that software reuse may not occur, even when a rational business case seems to indicate that it would be profitable to do so. Various reasons for this have been proposed, including cultural inertia, inappropriate reward system, unquantified or unquantifiable risk (“not invented here” syndrome), and the like (Menzies, 2003). This area of reuse strategy focuses on managing the non-technical incentives and disincentives for reuse. The remainder of this section explores the opportunities and implications of software reuse within the context of the Constellation Program. Figure 3-1. Market for Reusable Software Artifacts 1 3.03 Various Definitions of Software Reuse The definition of software reuse varies among organizations and across development communities. Some communities practice software reuse by utilizing commercial software libraries as a matter of routine, and thus, do not define that practice as “software reuse” and do not explicitly represent the use of the library code in their cost models. This means the accrued advantage is apparently tacitly distributed across the costing of the other elements of the work. This view on software reuse is ubiquitous in the commercial software sector. In other communities of practice, for example safety-critical software development, this practice is more limited. 1 Courtesy NASA GSFC [http://softwarereuse.gsfc.nasa.gov/] CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 20 Some communities distinguish between “accidental” and planned reuse. Accidental or “ad hoc” reuse occurs when an individual informally reuses artifacts that were not designed for reuse and without the use of reuse-oriented processes. Planned reuse means that software artifacts are designed from the beginning for the purpose of being used in different domains or projects. The focus of this report is on planned reuse. Software reuse is not just limited to reusing the code assets but it includes everything that is required to provide a technically complete system:2 1. Software libraries 9. Analysis 2. Software components 10. Test 3. Application libraries 11. API specifications 4. Design patterns 12. Protocols 5. Parametric programming 13. Architecture frameworks 6. Aspect-oriented programming 14. Training 7. Requirements 15. Knowledge 8. Design The most comprehensive definition of reuse is that of software product lines: A software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. (P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, [Boston: Addison-Wesley, 2002], p. 5) A comprehensive program must involve program-level activities in order to enable reuse on a scope that will improve costs and efficiency at the program level. In general, the program-level activities include (Kemerer, 1987): 2 • Facilitate construction of artifacts that are more effectively reused. • Develop a program system-of-systems architecture that maximizes opportunities for reuse. • Promote formal and informal incentives that encourage sharing and reuse. • Develop and maintain a software reuse cost model to guide investments. • Implement a metrics program that allows reuse costs and benefits to be quantified and fed back into calibration of the cost model. This is an extension of the list found in the Software Engineering (Sommerville), http://www.comp.lancs.ac.uk/ computing/resources/IanS/SE6/ CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report 3.04 Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 21 Constellation and Reuse Constellation is a very large many-tiered program with many stakeholders that have mature competitive-advantage software development capabilities, and has a very long lifecycle. This dictates certain properties of any viable software reuse program: 4. The software reuse strategy for Constellation must be developed, refined, and maintained so that it can be used to guide program investments in software reuse. 5. The reuse program must have a phased implementation. 6. The program must accommodate legacy, commercial, and designed-for-reuse elements so that the reuse program does not require unnecessary reconstruction of assets. 7. The program must have a flexible investment (cost) profile so that inevitable fluctuations over the life of the program can be accommodated. 8. The program must include development of a set of domain-specific software architectures (DSSA) to maximize potential commonality amongst reusable elements, and to increase return on investment (ROI) by engineering-in flexibility in the face of obsolescence. 9. The program must facilitate institutional self-improvement in the domain of reuse, since a large reuse program like this is certain to extend the state-of-the-art and the state-of-the-practice of software reuse. 10. The interfaces and practices that must be common amongst stakeholders should be negotiated in a neutral manner, e.g., within a standards body, perhaps the Object Management Group (OMG) and/or IEEE. 11. The incentive mechanisms must be engineered, based on the business case, to cause rational self-interest on the part of all involved parties to motivate actions that coincide with the objectives of the Constellation reuse program. These measures are necessary because of the tremendous scope of the Constellation Program. There will be a vast amount of new and legacy software; there will be many political, regulatory, and corporate stakeholders; much of the software will be safety-critical; there is a lot of money involved; and the program will exist for several decades. If the nation’s taxpayers are to gain maximum benefit from software reuse within Constellation, then the reuse program must be national in scope. Most of the research done on software reuse is performed within the context of industrial software, and consequently, the primary focus is on profit. In particular, improvements in software quality and reliability are generally noted as side effects of reuse, rather than primary objectives. There is also little discussion on the topic of reuse for safety-critical software, and not much practical experience, though the topic has come up (Lougee, 2004, 2005). Constellation will CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 22 require large amounts of extremely reliable software built and tested to formal standards for safety-critical software (DO-178B/ED-12B, 1992). It is likely that software reuse can be used to manage and improve software reliability in its own right, but further original research will probably be necessary if maximum benefit is to be accrued. 3.05 Reuse Strategy The Constellation Reuse Strategy lays out the programmatic plans for the implementation of reusable software across the Constellation Program. The entire document is focused on articulating the key concepts to be addressed by any software reuse strategy for Constellation; this subsection provides an introduction to the elements that make up that strategy. All of these elements are discussed in more detail elsewhere in this report. Major elements include: • Policies, processes, and practices • Software architecture • Programmatic plan for investing in reusable assets • Policies and incentives for reuse • Business case Because of the importance of developing the software architecture and product line plans, these elements are discussed in separate subsections (3.6 and 3.7 below). Once these plans are in place, programmatic plans can be made for developing key assets. Perhaps the most important part of creating a reuse strategy is the focus on up-front programmatic planning (development of policies, processes, and practices) and investment in reusable assets (software artifacts, tools, infrastructure). As discussed in several sections of this report, the greatest return from software reuse occurs when software artifacts are planned from the beginning as reusable assets. Many of these assets should be developed prior to their first use by a project and delivered to the project user (see discussion in Subsection 4.2, the AMMOS case). This requires more up-front investment in software than is typical for a NASA mission. Although the return on this investment will not be immediate, it is this up-front investment that will provide the greatest long-term return in terms of cost, reliability, and schedule savings (see recommendations in Sections 8.0 and 9.0). Policies and incentives for reuse are discussed throughout this entire report. The previous two subsections (3.3 and 3.4) review policies that are derived from the nature of the Constellation Program. Incentives must be provided to the individual projects to encourage reuse (see Figure 3-1) and funding must be provided for infrastructure and tools that support the reuse effort (see Subsection 3.3). Contracts must be written to incentivize reuse. Specific attention must be paid to organizational or cultural disincentives for reuse (see Sections 4.0 and 6.0). Section 8.0 provides a summary of the policies that are recommended by the study team. By establishing these policies early in the program, individual project plans can be developed consistent with program plans and contracts can be written that support the reuse program. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 23 The business case shows the value of the reuse strategy. It documents the savings to be achieved by individual projects and shows the costs of programmatic investment in reuse. It will highlight improvements in reliability and reductions in schedule to be achieved through reuse. The business case establishes the relationships across time and between costs, benefits, schedule, functionality, and risks. In the case of a multi-tier program like Constellation, it would take political and organizational boundaries into account as well. The business case is used to direct investments to where they will yield the best return. These elements, along with Architecture and Product Lines discussed in the next two subsections, comprise the reuse strategy. The rest of this report provides additional detail and further insight into these elements of reuse strategy. 3.06 Architecture The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. By “externally visible” properties, we are referring to those assumptions other components can make of a component, such as it provided services, performance characteristics, fault handling, shared resource usage, and so on. (P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, [Boston: Addison-Wesley, 2002], p. 57) Constellation must have a comprehensive and well-defined software architecture if it is to have a far-reaching software reuse program (there are many other reasons as well, and if the architecture is not developed, then costly consequences are likely to ensue). The software architecture provides the “context” for the elements of the software systems: how the elements must interact (and must not interact) to accomplish the objectives of the system, how resources are managed, what functionality goes where, etc. If the architecture does not define how the elements interact, then they will inevitably interact in different ways. Each different pattern of interaction will become part of the operational specification of the relevant software, and will hinder its reuse in other contexts. If interaction patterns are standardized, and unnecessary interaction is minimized, then opportunities for reuse will increase and the cost of developing reusable elements will decrease. Thus, the upper bound on the ROI is increased by the existence of a strong architecture. Architecture is key to the success of any software project, not just a software product line. Architecture is the first design artifact that begins to place requirements into a solution space. Quality attributes of a system (such as performance, modifiability, [dependability] and availability) are in large part permitted or precluded by its architecture—If the architecture is not suitable from the beginning for these qualities, don’t expect to achieve them by some miracle later… The right architecture is absolutely essential for smooth sailing. The wrong one is a recipe for disaster. (P. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 24 Clements and L. Northrop, Software Product Lines: Practices and Patterns, [Boston: Addison-Wesley, 2002], p. 57) The large scale of the Constellation software systems suggests that it may be best organized as a number of layers of architecture: a system-of-systems for the overall program, an architecture for the various flight/ground elements, and so on. Development of this architecture is a key element of the Software Research Strategy (see recommendations in Sections 8.0 and 9.0). As the above quote indicates, this work must also begin early in the project lifecycle. The development of the architecture is also a Software Product Line key practice. 3.07 Product Lines The purpose of a software product line is to exploit economies of scope, by taking advantage of commonalities between the many elements of a project. The economies of scope are engineered into the product line—they don’t just happen. In a sense, software product lines represent the end game of software reuse: under the software product line paradigm, the system itself is designed from the beginning to offer maximum opportunities for reuse, and the software engineering, and non-technical management is structured to take maximum advantage of those opportunities. This goes far beyond simple reuse of code. Software Product Lines are the distillation of best practices by the Software Engineering Institute at Carnegie Mellon University for the Department of Defense. The SEI examined billions of dollars of reuse-oriented software development in the defense, commercial, and aerospace sectors to develop the practices. The study team found that the “Software Product Lines” practices are the most comprehensive and most broadly used framework for a large-scale reuse program in existence today. The Constellation Program mitigates risk by using a spiral development model, each spiral undertaking a more ambitious goal, while building upon the work done in previous cycles. Each cycle provides an opportunity to learn from the previous cycle, and modify the approach as necessary. That is an ideal environment for software product lines, as the project itself is in fact a product line. What is a Software Product Line? A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. Why are Software Product Lines Important? Software product lines are rapidly emerging as a viable and important software development paradigm allowing companies to realize order-of-magnitude improvements in time to market, cost, productivity, quality, and other business drivers. Software product line engineering can also enable rapid market entry and CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 25 flexible response, and provide a capability for mass customization. (Carnegie Mellon University, “Software product lines,” online document) Product lines save time and money: systems that use the same components and offer the same features require less time for planning and rework, have lower production costs, and require fewer staff members. Because the shared components of a product line are reused from system to system (rather than built from scratch every time), the systems in software product lines are also highly reliable. (Carnegie Mellon University, “Product line systems program,” online document) The software product line captures both the architecture and the managed evolution of the system. Product lines facilitate software reuse across elements of the program, and reuse across the life of the program. There are a number of software product line practice areas. It is out of scope of this report to go into detail about them all. However, it is useful to present an outline of the areas in order to convey the scope of the practice of product lines (Clements and Northrop, 2001). 12. Software Engineering Practice Areas • Architecture Definition • Architecture Evaluation • Component Development • COTS Utilization • Mining Existing Assets • Requirements Engineering • Software System Integration • Testing • Understanding Relevant Domains 13. Technical Management Practice Areas • Configuration Management • Data Collection, Metrics, and Tracking • Make/Buy/Mine/Commission Analysis • Process Definition • Scoping • Technical Planning • Technical Risk Management • Tool Support CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 26 14. Organizational Management Areas • Building a Business Case • Customer Interface Management • Developing an Acquisition Strategy • Funding • Launching and Institutionalizing • Market Analysis • Operations • Organizational Planning • Organizational Risk Management • Structuring the Organization • Technical Forecasting • Training 3.08 Software Reuse Success The case studies in this report show that many organizations have searched for and found ways to reduce the cost of software development efforts through the use of software reuse. To achieve this, much attention has been given to a combination of technical, non-technical, and management approaches. Technical approaches have included the use of automatic code generation and more esoteric approaches such as algorithm synthesis. Non-technical approaches have included both organizational-wide and ad-hoc software repositories, and use of shared libraries of vendor-supplied code. From a management level, one sees everything from a casual position on software reuse to edicts that “Thou shall reuse whenever possible.” Some people are resistant to any form of reuse because of the “not invented here” syndrome. That is why a successful program must involve non-technical management at the highest level that will nurture and maintain the program. Software reuse is most successful when it is designed-in from the beginning of the project as part of a software product line process. Such a process includes, but is not limited to, the development of system architectures, software architectures, common standards, protocols, and interfaces. The many case studies in the literature clearly demonstrate that trying to retroactively add in (or slam in) a policy of reuse later in the lifecycle ends up costing more than rebuilding from scratch. In addition to setting out on the right path for software reuse at the onset of the project, to succeed in the large, reuse efforts must address a spectrum of both technical (tools and techniques) and non-technical (corporate, management, policies) issues. A strong software architecture, well thought out product line plan, and an effective reuse strategy are essential to achieving successful software reuse. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 27 CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 28 4.0CASE STUDIES 4.01 Introduction The purpose of analyzing case studies is to focus on lessons learned from prior reuse efforts that are directly applicable to the Constellation Program effort. This section consists of two types of case studies: NASA and Non-NASA case studies. There are a total of nine separate studies followed by a Discussion and Analysis subsection that emphasizes the lessons of importance to Constellation Systems and a set of product line solutions for the challenges derived from the cases. 4.02 NASA Case Studies Four NASA case studies and one summary report were documented or reviewed specifically for this Software Strategy for Reuse Study Final Report: 15. AMMOS Multi-mission System Reuse Case Study 16. ROSE—Flight Analysis and Design Reengineering Case Study 17. Checkout and Launch Control System (CLCS) Case Study 18. Summary of SEEDS Formulation Team Final Recommendation Report 19. GSFC Ground System Reuse Case Study The AMMOS case study illustrates the value of the product line approach and the importance of programmatic planning and guidance to the success of a system-level reuse effort. The ROSE case study describes a product line approach to reengineering and shows the need for detailed technical planning and training in executing such an approach. The CLCS case study shows the impact of cultural and organizational complexities on reusable product design and demonstrates the value of frameworks in software reuse efforts. The SEEDS report provides an overview of the reuse recommendations for the Earth Science Enterprise Data System. The GSFC Ground System case study describes some important product line concepts in the context of developing ground system software. 4.02.1 AMMOS Multi-Mission System Reuse Case Study The Advanced Multi-Mission Operations System (AMMOS) has been in use at JPL since 1989. Since that time it has been used by approximately 30 missions as the primary source of ground data system (GDS) software, hardware, procedures, and personnel. Although AMMOS is a true multi-mission system, it is comprised of individual elements (shown in Figure 4-1) that must be adapted, integrated, tested, and deployed for each individual mission. Lessons learned over the last 16 years of adaptation and core system development make an excellent case study of systemlevel reuse. 4.02.1.1 Mission Operations Services Provided A significant advantage of AMMOS is that broad Mission Operations Systems functionality is available for new missions. AMMOS provides a well-defined set of mission services: CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 29 • Navigation • Planning and Sequencing • Spacecraft Analysis (includes spacecraft modeling and simulation tools) • Mission Control • Data Management and Archiving • Telemetry and Command • Computing and Communications • Instrument Operations The system elements comprising these services and their interrelationships are shown in Figure 4-1.3 Ready availability of these elements is a significant aid to mission planning in addition to their substantial reuse value. Figure 4-1. Mission System Elements 3 Unpublished presentation, “AMMOS Roadmap,” 2005. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report 4.02.1.2 Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 30 AMMOS as a Software Product Line AMMOS was planned from the beginning as a reusable multi-mission system that required relatively small adaptations to create a mission-specific GDS. An important part of this strategy is that core GDS capability grows over time with later missions gaining from the experiences (and code) of earlier missions. Reuse impacts outside the area of code development are substantial: planning, operations, and risk reduction benefits are discussed below. AMMOS is a software-intensive system. Although there are significant hardware elements in any specific project implementation, it is the software portion that is inheritable. It is useful to view AMMOS as an early example of a Software Product Line (SPL). A mapping to current SPL terminology would be: Products → Individual Project GDS’s Product Line → Set of Project GDS’s Core Assets → AMMOS Subsystems (see Figure 4-1) AMMOS Architecture → Documents, Testing Plans, etc. Production Plan → Parameterization and Adaptation by Projects With this mapping it is easy to make comparisons to the typical SPL structure discussed in Clements and Northrop (2001). The lessons learned from AMMOS provide key insights into the benefits and challenges of the product line approach. 4.02.1.3 Return on Investment Calculating a meaningful return on investment (ROI) figure for AMMOS requires a detailed estimate of what mission-specific development would have cost for the 30 missions that have used AMMOS. Because of the difficulty of obtaining accurate, independent estimates of these 30 non-existent custom systems, few measures of ROI exist. Two approaches that demonstrate the significant value of multi-mission system reuse for current and future users of AMMOS are described in this section. Bottoms-up estimation. A 2004 presentation4 by Charles Klose of the AMMOS program office shows substantial savings provided by the multi-mission approach especially during the later years of his 17-year study. Klose uses a detailed bottoms-up approach to estimate the annual cost of each phase of a mission during the mission lifetime. This study indicates dramatic savings ($180–$250M per year) for the years 2005–2011. He also shows the significant reduction in flight operations costs that is possible if a multi-mission operations team is employed along with the AMMOS multi-mission GDS. These savings compare with an AMMOS program cost of approximately $40M per year. 4 Unpublished presentation, “AMMOS 2004 Update, ROI Benefit Model,” Feb. 2004. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 31 Lines-of-code estimation. An alternative parametric approach to estimating value for current missions is based on lines-of-code estimation: comparing lines-of-code needed for custom development with the alternative of significant inheritance from AMMOS. This approach is summarized in Table 4-1. Custom ground data systems for deep space missions are complex software-intensive systems comprising 5–10 million source lines of code (SLOC). Software inherited by current major users of AMMOS is given in Table 4-1.5 For any specific mission, one can compare the estimated cost (using any of the usual cost models) of generating a custom GDS with cost of a multi-mission system based on the inheritance from AMMOS. The cost of the AMMOS-based GDS is either known historical data or estimated for ongoing missions—see footnote (**) in Table 4-1. This estimation method has the added value of easy testing of its basic assumptions: SLOC for the custom system and the cost of development (per line-of-code). Sensitivity analysis of a wide range of reasonable values of these basic assumptions shows consistent savings generated by the multi-mission system. Table 4-1. Impact of Software Reuse on Deep Space Mission Ground Systems Project Genesis Size (MSLOC) 12.2 GDS with ith AMMOS % From Cost AMMOS $M (FY05) 93 7.5 Custom GDS GD Size* GDS Cost (MSLOC) $M (FY05) 3.5 87.5 Percent Savings 91.4 Mars Exploration Rover Deep Impact 15.1 75 26.2 5.5 137.5 80.9 14.4 78 9.4 4.5 112.5 91.6 Mars Reconnaisance Orbiter Spitzer Space Telescope Dawn 11.5 98 11.5 2.5 62.5 81.6 14.9 76 18.8 5.0 125.0 85.0 12.0 93 9.0 3.0 75.0 88.0 Custom GDS S Productivity: Productivity:*** ($/SLOC) 25.0 Average Savings 86.4 GDS Cost (with ith AMMOS) is s based on historical h orical values from rom the ESD Cost ost Reposit Repository, ry, the Proje Project and Financial Workforce rkforce Data Database, se, and the JPL Software Metrics Reposi Repository. ry. Where d data ta was not a available, estimated cost st is based o on a mixture of historical storical actu actuals, s, current bu budgets, ets, and est estimated mated data. **Custom GDS S size has b been en adjusted to reflect the fa fact ct that navigation naviga n software w would ould be inhe inherited with little modification. cation. **The cost perr SLOC assu assumes mes a doublin doubling in productivi productivityy due to COT COTS/GOTS S/GOTS or other ot er inheritance. inheritance This is in addition to o the naviga navigation n software iinheritance. eritance. A caveat to this LOC approach: substantial use of “government-off-the-shelf” (GOTS) or “commercial-off-the-shelf” (COTS) software might reduce costs of building a custom system to a level comparable to an AMMOS-based GDS. No one has yet demonstrated the practicality of doing this. However, navigation software would almost certainly be reused. The SLOC requirements for custom systems in Table 4-1 have been adjusted to reflect this fact, and the 5 Unpublished presentation, “AMMOS Roadmap,” 2005. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 32 productivity factor assumes that significant inheritance would occur even in custom system development. Even with these fairly conservative assumptions about custom GDS cost, this method provides savings estimates that are reasonably consistent with the Klose study. Both bottoms-up and LOC approaches to estimating ROI indicate significant value to the multimission approach for the long term. As the number of missions using AMMOS increases, this return becomes even more dramatic. Return in the early years is less clear—see Early User Considerations in Subsection 4.2.1.4. 4.02.1.4 Lifecycle Considerations Core software assets have a lifecycle; they will evolve and erode over time. This subsection explores the value stemming from 16 years of AMMOS use and then looks at problems (i.e., erosion) associated with this maturity. The discussion concludes with problems faced by early users. Advantages of a Mature Product Line Much of the value provided by AMMOS is derived from its evolution over 16 years of use by multiple missions. Advantages already discussed include providing substantial functionality at the beginning of new projects and significant cost advantages. Other advantages include the ability to plan new missions much more quickly and accurately due to a well-defined set of mission services and much greater predictability of GDS development and testing costs. This planning capability is enhanced by a valuable set of standard products and templates for required mission documents. Some of the many available are: • Software Management Plan • Requirements documents • Test documents • GDS Architecture • Security plans • Training documents • KSC support plans • Standard interfaces Mature product lines tend to provide high reliability (AMMOS has been operationally tested by 20+ missions) and shorter GDS development times. Lessons learned from past missions are automatically incorporated in future missions. Because AMMOS is a multi-mission system, it allows significant savings through shared operations and development teams. Examples in JPL projects include shared flight control teams, sequence integration teams, GDS system engineering and test engineering teams. All of these advantages provide greatly reduced GDS risk (schedule and cost) and allow project personnel to focus on mission objectives rather than GDS development. These advantages are summarized in Table 4-2. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 33 These powerful advantages are derived from long-term use but are offset to some degree by challenges that come with maturity, by disadvantages facing early users, and by other system reuse challenges. Table 4-3 summarizes these challenges. Mature Product Line Concerns One of the challenges facing AMMOS is the erosion in quality of code over time. Mature systems (such as AMMOS) require maintenance and new investment if they are to continue as an efficient source of inherited software. For example, much of the AMMOS code was written fifteen years ago in the “C” programming language. Current designers might prefer C++ or other object-oriented language. Although there have been significant efforts aimed at continuous improvement in functionality and structure, tight program budgets have restricted the amount that could be spent to upgrade existing code. An approach of “if it’s working, don’t fix it” will guarantee obsolescence of the product line. Table 4-2. Mature System Reuse Advantages Substantial functionality available for new missions Well-defined set of mission services Prior investment in capability development provides significant value High leverage for current missions Reduced planning uncertainty Better predictability of GDS costs (both development and operations) Shorter development cycle High reliability (reduced risk) Years of testing by multiple (20+) missions Testing (including MOS V&V) costs are lower and more predictable Valuable set of standard products and templates Lessons learned from past missions automatically incorporated in future missions True multi-mission operation dramatically reduces flight team costs Innovation cost is spread across multiple missions Well-documented, well-understood values and benefits Allows focus on mission objectives rather than GDS development A related problem with mature product lines is that users who arrive late in the lifecycle sometimes assume the software product is “free.” Budget and schedule are still required for adaptation, maintenance, testing, and operations. Programs employing a product line approach must still budget for these items. AMMOS is developing future plans to alleviate these concerns and enhance the mature product line benefits described above (see Subsection 4.2.1.6). CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 34 Early User Considerations Many of the benefits described above for mature product lines were available to a lesser extent or simply not available to early users of AMMOS. To avoid early users paying a disproportionate share of the cost, AMMOS was planned with substantial programmatic investment (i.e., early development) up-front. AMMOS, in effect, delivered to the early users. In addition, adaptation expenses were paid for the first five missions. This allowed AMMOS to keep the focus on a multi-mission product line rather than being dominated by the needs of the first users. In spite of these efforts, functionality available to early users (especially the first user) was limited and precise capabilities were unknown or even unplanned at the time project planning was taking place. This parallel planning was a tax on both projects and AMMOS developers. Cost risk was not well understood. Some users did not need all of the capabilities of the multimission system; these extra features may have actually increased project risk. For all of the above reasons, some early project users of AMMOS felt they could have developed a custom GDS that better met their needs. Table 4-3. Challenges in System Level Reuse Mature System Concerns The core software has a lifecycle; it will evolve and erode over time. Core assets require maintenance and new investment to avoid obsolescence. SW is not “free” to a user; it requires adaptation, maintenance, and testing. Early User Considerations Solid programmatic planning and significant up-front investment is required. Reusable software should be delivered to not developed by the first user. No one wants to be the first user. Early users may pay a disproportionate share of the cost. Functionality available to early users may be limited. Parallel planning (projects and product line developers) may be difficult. •Unknown capability requirements Multi-mission features not needed by the project may increase project risk. Standardization Projects are adapting a standard GDS—it is not optimized for specific mission. Standardized spacecraft make project adaptation easier. Missions with special requirements might do better with a custom system. Configuration Management CM is difficult when operating multiple missions in parallel with product upgrades. •Multiple versions of software are under tight project CM. •Encouraging upgrades to a project-CM controlled system can be difficult. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report •Each Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 35 mission becomes a separate upgrade, handled independently. Organizational Challenges Organizational incentives and disincentives for product use must be managed. •Program plans must be specifically designed to support the product line. A well thought-out program with solid programmatic planning and significant up-front investment alleviated many early-user concerns. However, even with an excellent program plan some issues remained. The big payoff in product lines is long term. 4.02.1.5 Other Challenges of a Product Line Approach Other issues have created challenges for AMMOS users and developers. These issues will be important to other systems where adaptation to individual projects is required. Standardization. Projects adapting AMMOS must use a standard GDS (albeit tailored or adapted). Hence, it is not optimized for a specific mission. Missions with special or lesser requirements might do better with a custom-designed system. For example, Earth orbital missions with limited Command requirements (e.g., TOPEX, Jason-1 and -2) have found it desirable to design a custom GDS to meet their needs. In general, more standardized spacecraft make adaptation of AMMOS easier. Configuration Management (CM). Mission adaptation can cause a CM nightmare as upgrades are developed in parallel with multiple ongoing missions. Voyager, Ulysses, Galileo, and Magellan each had different versions of AMMOS under tight project CM while the AMMOS developers were trying to upgrade to the next version of the multi-mission system. Encouraging projects to upgrade under these circumstances can be difficult. As a result, developers had to maintain four different CM paths rather than concentrating on multi-mission development. In recent years, projects have tended to see the value of upgrading to the latest version of the multi-mission system—the exception being projects nearing end-of-mission or facing severe budgetary constraints. 4.02.1.6 Future Vision In order to take full advantage of the benefits described above, alleviate some of the disadvantages, and achieve the operations cost reductions implied by even optimistic budget scenarios, new adaptation paradigms are being developed. The vision for the AMMOS of the future6 includes the following elements: Plug and play – Projects will be able to select the AMMOS elements that meet their needs and plug them into a basic GDS with relatively little adaptation. Project choice – Projects will be free to choose other suppliers or commercial products for some or all of the system elements. 6 Unpublished presentation, “AMMOS Roadmap,” 2005. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 36 Fair market paradigm – Project choice will provide a fair estimate of market value. Full cost recovery – Projects will pay for use of system elements. Innovation – Major investments will be paid by the AMMOS program with particular attention to ROI. Thus, innovation cost will be spread across multiple missions. These new paradigms should significantly enhance the value for AMMOS users. Project choice combined with a market paradigm not only provides discipline for developers, it encourages projects to control their appetites for new capability. Plug and play not only allows projects to efficiently build the system they want, it enhances reusable design and allows modules to be continuously improved for the benefit of future users. These enhancements will, of course, require continuing investment in the AMMOS core assets. 4.02.1.7 AMMOS Conclusions Although early project users of AMMOS may not have achieved the full cost and risk reduction benefits of the product line approach, long-term results have been dramatic. AMMOS has provided significant advantages for many years: lower development and operations cost, shorter development cycle, robust GDS, and reduced risk (Table 4-2). It has also demonstrated some significant factors that should be carefully considered in setting up the Constellation Systems Program (Table 4-3). Solid programmatic planning and significant up-front investment is needed to alleviate the concerns for early users. Organizational incentives and disincentives for product line use must be managed and program plans must be specifically designed to support the product line approach. 4.02.2 ROSE—Flight Analysis and Design Reengineering Case Study 4.02.2.1 Project Description The ROSE (Reusable Object Software Engineering) Project was aimed at reengineering a large legacy system—the Flight Analysis and Design System (FADS) for the Space Shuttle program. ROSE was planned as an economical and effective approach to reengineering and maintaining Shuttle Flight Design and Dynamics (FDD) systems. The FDD software was developed over many years, and has been continuously evolving. Because the software was developed under a variety of methodologies and languages, it was difficult to use and expensive to maintain. The Flight Analysis and Design System (FADS) development was originally targeted to address the software in addition to upgrading the hardware platform. FADS is composed of 2.5 MLSOC of mostly FORTRAN that has undergone several “minimum impact” changes in a variety of methodologies and languages and several programs with overlapping or redundant functionality. For a variety of reasons most of the software was rehosted to the new platform with minimal change. Therefore, the problems associated with operations and maintenance of the software persisted. The ROSE Project intended to bring the FDD software into a consistent architecture and design framework. To accomplish this, the existing functionality was to be reengineered into a modern architecture based on Object Oriented Software Engineering (OOSE) techniques, CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 37 implemented in a language that supports those techniques, and accomplished through a repeatable, defined process. 4.02.2.2 Project Timeframe • 1/1/93 — Pilot start • 8/31/93 — Pilot review, “go” given for secondary pilot • 4/5/94 — Pilot review, “go” for project • 9/9/94 — NASA merges ROSE with MOC rehost effort, team size doubles • 3/6/95 — Delivery Increment-1 (Navigation) delivered • 6/95 • 7/31/95 — Project retargeted at TOTM–DI-2 (DOPS/LANDOPTS application) still on track • 3/12/96 — ROSE-TOTM cancelled 4.02.2.3 — Massive re-planning of Trajectory-Off-the-MOC (TOTM) Process A product line approach employing a dual lifecycle was selected. The dual lifecycle approach separates the activities involved in software development and management into two distinct groups within the organization: those concerned with the domain as a whole (product line), and those concerned with particular applications (products) within the domain. The domain and application engineering activities are distinct, yet related endeavors, which proceed in parallel (see Figure 4-2). Figure 4-2. Dual Lifecycle Approach The choice of a product line approach was driven strongly by a large amount of redundancy both within FADS itself and with other closely related systems within NASA/JSC. The additional CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 38 effort expended in generating a generic solution (domain engineering) rather than a point solution for FADS, was perceived as beneficial, and was key in the decision to expand the project scope to include the Mission Operations Center Trajectory System. The process was based on an iterative approach, where iterations were planned and executed in about 6 weeks. 4.02.2.4 Organization ROSE began as a six-month, 20-person initial pilot to demonstrate proof-of-concept for the approach. The sixth-month review resulted in the expansion of the team to 40 people and extension of the pilot to a full year. This year-long activity generated enough information to assess probable success of the full project, and in the year-end review, the team was given the entire flight analysis and design system as its scope, with a set of phased delivery increments to successively replace major FADS subsystems. The team was then expanded to 60 people. Once the Trajectory part of the Mission Operations Center was included in the project, the team was increased again to a total of 80 developers. The team was split into multiple groups, each responsible for a different area. Areas of focus included: reverse engineering techniques, tool customization, process definition, domain engineering, application engineering, etc. 4.02.2.5 Training Extensive training was provided to all the team members. Since the team had to go through multiple learning curves in parallel (OO, reuse, reengineering, toolset, etc.) the training covered all these aspects. Formal training classes were augmented with mentoring sessions. 4.02.2.6 Technical The ROSE team members were all familiar with the Flight Design domain. They were all software developers involved in the use and maintenance of the legacy software. The team decided to use C++ for the project. The project used the OMT method (Rumbaugh et al., 1991) as the Object-Oriented Analysis and Design method. The tool chosen to support the modeling was Paradigm Plus. 4.02.2.7 Lessons Learned The ROSE case provides several keys to successful use of the product line approach (Table 4-4) and also reveals several challenges that can derail that success (Table 4-5): Table 4-4. Product Line Successes The product line approach was viewed as very beneficial by the ROSE team. Training was key—both formal training classes and informal mentoring program. The pilot project was important to debug the process and start to build the core team. A strong architecture team is key to the success of Domain Engineering. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 39 Table 4-5. Product Line Challenges The product line approach must be supported by the entire organization. • ROSE faced too many conflicting objectives. The customer did not understand the importance of developing the core assets (domain engineering) and wanted the focus to be on application production. There were too many learning curves at the same time (process, reverse engineering, OO paradigm, iterative/incremental lifecycle, C++ language, toolset, etc.). When a real-time system was inserted in the ROSE project, the design constraints were significantly different from the ones relevant to Flight Design. The ROSE Project was terminated due to schedule pressure generated by a rapidly expanding scope (inadequate product line scope control). 4.02.3 Checkout and Launch Control System (CLCS) Case Study Software reuse can be attempted at multiple levels and through multiple phases of the software lifecycle. This case study looks at several approaches attempted during the CLCS project. The CLCS project ran from 1998 through August 2002 when it was cancelled. The project deployed a new control room at the Hypergolic Maintenance Facility (HMF) and was approximately one year away from deploying for Space Shuttle Orbiter checkout in the Orbiter Processing Facility (OPF). 4.02.3.1 Impact of Cultural Differences on Software Product Specification Application software development was organized around vehicle subsystems as this was the organization of the legacy system and represented how the operations community was organized. One area of reuse was in the software that represents valves. The fluid systems on the orbiter and their associated Ground Support Equipment (GSE) utilize many types of electrically actuated pneumatic valves. These valves range from simple valves with one command and no position indicators to complex valves with multiple commands and multiple position indicators. Since the same physical valve is used within multiple systems, this appeared to be an obvious area of reuse potential. Both the Main Propulsion System (MPS) and the Orbital Maneuvering System (OMS) use the same valve for GSE, which is Normally Closed (NC), and has a single OPEN command and a single OPEN position indicator, a micro switch that closes when the valve physically reaches the OPEN position. During the domain analysis and requirements phase, it was discovered that the two engineering groups supporting the MPS and OMS subsystems held diametrically opposed philosophies concerning how to handle off-nominal cases in determining the state of the valve. Both parties were in agreement that if the command were OPEN and the valve indicated OPEN, then the state was OPEN. Likewise if the command were CLOSED and the valve indicated CLOSED, then the state was CLOSED. However, if the command were OPEN and the valve indicated CLOSED, disagreement ensued. The MPS engineers would call this state CLOSED-ERROR, because the valve indicated CLOSED so the problem most likely was that the command was not reaching the valve. The OMS engineers would call this state OPEN-ERROR because indicators have failed in the past (they’re only micro switches) and since it is commanded OPEN it is most likely OPEN and the problem is in the indication. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 40 After much discussion, the groups were unable to reach an agreement on the determination of the state of the same physical valve. There were several other operational differences in how the valve was used by the system engineers including: timing constraints, required sample rates for position indicators, and the test and checkout philosophy that led to the realization that multiple software representations were required of the same physical piece of hardware. The lesson learned here is that differences in operational use and philosophy must be addressed prior to software product specification. 4.02.3.2 Subsystem Status via Service Provider Model The existing legacy system was a federated architecture where each of the subsystems, or predefined groups of subsystems, were allocated their own CPU and developed monolithic applications that minimized interactions with other subsystems. One observation early in the project was that 80% of the existing systems had duplicated code in their own applications to determine if power was available, if the avionics system was in the correct configuration, and other integrated configuration information (such as the location of the orbiter or which launch pad the orbiter was on). The determination was made for the project that configuration, health, and status information would be provided by the subsystem owner and published or made available via remote access to anyone who needs the information. In this way the code can be maintained in one place. However, this had an unforeseen consequence in the testing and validation of the individual subsystem’s software. Previously, subsystems (such as MPS) could test and validate their software independent of other subsystem software. With this new approach many dependencies were created between subsystems. While schedule issues could be worked around through manually setting published values or building test proxy software that emulated the data provider, there was the problem of trust. Engineers working on Ground Launch Sequencer (GLS) believed they test their software to the best of their ability, and do not believe that other subsystems test their software to the same level. This is not isolated to GLS as there are other trust issues that exist between various subsystems; some even believe their valves are OPEN even when their indicators tell them they are CLOSED. There was widespread concern that individual subsystem application software functionality and safety were being put at risk by relinquishing control of these functions to the owning organization. One of the fundamental operations philosophies is “test your software like you will use your software.” However, there are ramifications that involve dependencies on other software or subsystems. For example, which systems application software is running, and where that software is running for specific integrated testing purposes. Dependencies determine when those tests can be performed and increases the level of support needed when running those integrated tests. The lesson learned here is that reuse through a service provider model creates dependencies in testing and integration that, in some circumstances, may outweigh the intended cost savings. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report 4.02.3.3 Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 41 Framework Encourages Reuse Within the software engineering domain some level of software reuse was enforced through an application framework based on extending the ACE framework. Through use of the framework, common methods of application initialization, messaging, debug tracing, reading data points, and sending commands were standardized through a set of application programming interfaces (API). These framework APIs provided higher-level capabilities that met the needs of 80% of the various application subsystem domains. In addition to the standard APIs, the framework also provided a consistent concurrency model that simplified the complexities associated with concurrent programming into a simple threading model. Some of the capabilities provided by the framework involved utilizing C++ templates to take the various system-provided primitives for command issuance, derived from the legacy system (APPLY for analogs, SET for discretes, ISSUE for digital patterns), into a single SET interface that was used for all command types. Another higher-level capability was provided through an analysis of the domain space; most often, when a measurement was read it was compared to a limit and verified to be within limits. The framework provided a common VERIFY method that performed the data read and then compared the value to a set of limits. Standardized messaging was provided through the framework SEND_MSG API, with the option of outputting a standard message when a measurement was out-of-limits as part of the VERIFY API. In addition, the framework also provided the core capability to perform unit-level debug and testing. Providing a common mechanism enabled successfully promotion of unit-level testing prior to application-level integrated testing. The lesson learned here is that by utilizing standard capabilities through the framework API and framework-provided services and capabilities, we were able to achieve high levels of application software reuse. 4.02.3.4 Configuration Complexities of Software Reuse Configuration complexities are often overlooked in software reuse applications. For example, an important consideration should be: which version of the reusable software component is running and where it is being run. This complexity may be minimized in an operational environment where the specific configuration is known and documented. However, in development and validation, this can lead to increased debug and testing times and increase the risks that software, which already passed testing, could fail in the operational environment. The details of this are development environment-specific. In the CLCS case development was on UNIX (SUN Solaris to be specific) and deployment on Solaris as well as VxWorks operating systems. Many of the reusable software components were stored in reusable, shared library files. The specific applications have environment variables of which values pointed to the specific shared library to use. Management and configuration of the environment variables and the paths that are searched to find the specified library files can lead to extended debug time, as the shared library (that the program is using) may not be the library that one might expect. This is especially true if the libraries are shared objects where an CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 42 application that was previously running may have loaded a different version of the library than that one needed. Hence, a subsequent application uses the earlier library version since it is already in memory. The lesson here is that reuse can lead to increased configuration complexity and that configuration control and versioning is especially important as the dependencies increase. 4.02.4 Summary of SEEDS Formulation Team Final Recommendation Report 4.02.4.1 Introduction The purpose of SEEDS (Strategic Evolution of Earth Science Enterprise Data System) is to (1) establish a framework for distributed data management to maximize availability and utility of Earth Science Enterprise (ESE) products; (2) leverage community expertise, ideas, and capabilities; and (3) improve overall effectiveness of ESE-funded systems and services. The study was lead by Gail McConaughy, NASA GSFC, to determine if software reuse with a reference architecture can reduce the cost and improve the delivery of information services needed by future NASA Earth Science Enterprise missions. Team members carried out this study (SEEDS, 2003) by gathering, assembling, analyzing, and interacting with community experts. This summary focuses on the reuse aspects of the SEEDS final report. 4.02.4.2 Definitions SEEDS defined reuse as “the act of taking a functional capability used in or provided by one system or mission and employing in another system or mission.” Reference architecture was defined as “a generic architecture that provides coherent design principles for use in a particular domain. It can have various levels of specificity and granularity.” The SEEDS’ team identified the following key software reuse and reference architecture approaches: • Clone & Own: Copying code and associated artifacts of one system for use in another system, where they may be independently modified and maintained. • Improved Clone & Own: Extending Clone & Own practices to enable developers to identify existing assets, subsequently copy those assets, and modify and integrate them more easily as needed for use in new systems. • Open Source: Engaging developers across missions to collaboratively develop and update selected components or systems stored in a central repository. • Service Encapsulation: Wrapping a complete, operational capability of a system with a network-accessible interface so that the capability can be used by others in-place, rather than re-implemented. • Product Lines: Reusing a set of core software components intentionally designed for a family of systems; the components are modified and maintained only by the organization responsible for the core components. • Notional Reference Architecture: Architecture that defines the subsystems or subcomponents of a system and allocates requirements/functionality to each. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 43 • Specific Reference Architecture: Architecture that defines the services (including all parameters) and service invocation mechanisms of each component of a system in precise enough terms to build interfaces. • Coarse-Grained Reference Architecture: Architecture that defines external interfaces to major subsystems only. • Fine-Grained Reference Architecture: Architecture that defines internal interfaces within applications or functional components. SEEDS grouped their user community into two categories: 1. Those involved in mission critical activities driven by launch schedule and the need for highly reliable production, distribution, and user services. 2. Those involved in mission success activities driven by need for more innovation in research and science applications. 4.02.4.3 Summary of Findings and Recommendation of the Study • The mission-critical community is strongly in support of an Improved Clone & Own approach for mission-critical development efforts. • The mission success community favors the Open Source and Service Encapsulation approach for mission success development effort. • Establish a body such as reuse integration office wherein responsibilities include: – Prioritize & approve reuse initiatives. – Select & guide reuse projects. – Develop, institute, and administer reuse incentives. – Conduct some reuse outreach and education activities. – A small technical team to support all reuse-related activities and evaluate cost saving and impacts. – Make policy changes where there are impediments to reuse—particularly policies related to intellectual property rights. • Competitively select, evaluate, and fund community reuse implementation projects. • Develop reference architecture as part of the support to encourage reusability. • Significant opportunity exists in NASA to realize additional benefits from software reuse. Current impediments are lack of support mechanism for reuse, schedule, and quality concerns. • Guiding principles: – Encourage reusability to be built into original code. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 44 – Create an Open Source authoring environment. – Identify functional areas appropriate for reuse, and focus reuse efforts on those areas. – Training and knowledge accompanies a software asset. – Define a peer-review process for selecting components for Open Source. • Technology strategies for reuse: – Establish a reusable component library. – Establish a testbed to help identify and qualify reusable components. – Incorporate reuse in NASA development standards. – Develop a software experience library with links to experts, assets, and other resources. – Document architecture/design patterns to enable design reuse. – Focus on reusable tools. – Focus on general software that has broad opportunity for reuse by the community. – Use formal methods and application generators to assemble systems from existing assets. • Program strategies to encourage reuse: – Establish teams to mine assets. – Have authoring organizations provide reuse support. – Fund authoring organizations to package, document, and advertise the software assets. – Provide institutional support by soliciting software from the community, polling the community for validation of components, designing testbeds for testing components. – Provide additional funding to cover overhead costs associated with making code reusable. – Fund activities that support/enable software reuse. – Establish/revise policies related to reuse. – Fund actual software reuse efforts/activities primarily concerned with taking and employing reusable assets in an operational environment and documenting the results. Currently there is a group at GSFC supporting the development and promotion of reusable software applicable to the Earth Science Data System. Project SHAirED (Services for Helping the Air-quality community use ESE Data) CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 45 aims to extend Web infrastructure development for sharing distributed Earth science data and creating tools for data processing and analysis. The project will seek existing data processing components that can assist in attaining its technology development objectives. 4.02.5 GSFC Ground System Reuse Case Study The journal article by Selby (2005) analyzed productivity and quality of ground system products from a NASA software development environment at GSFC that actively reuses software (average reuse is 32% per project). The study looked at module design and implementation factors for 25 projects for ground support software for unmanned spacecraft control. The projects were developed from the 1970s to the 1990s, and were from 3KLOC to 112KLOC of FORTRAN code. In that environment, the approach to implement a new software development was to first select one of their reference architectures to meet the needs of the system requirements. They then populated the architecture by using their repositories to determine which existing modules could be reused or modified. For new capabilities, they created new modules and ensured that they were designed for reusability in future projects. Thus, the development environment benefits from the maturity of the domain and the multi-project planning horizon of project managers and architects. The study found that average module development effort decreased with more reuse. Modules used with major revision were the largest; those completely reused, the smallest. Modules used without revision had the fewest faults and low fault correction effort; newly developed modules or those with major revision had the most faults and the most fault isolation effort. Modules used without revision were small, well-documented modules with simple interfaces and little I/O. The article concludes, “integrating flexible combinations of architectures and components can yield sustainable, multi-project benefits in well-defined problem domains … in terms of productivity and quality.” 4.03 Non-NASA Case Studies 4.03.1 Introduction Much of the literature available today on SPL discusses how Software product lines are rapidly emerging as a viable and important software development paradigm in the private sector. Claims of companies realizing order-of-magnitude improvements in time to market, cost, productivity, quality, and other business drivers are not uncommon. This section examines the non-NASA, not necessarily non-Government, cases and examples of SPL. The main source of comprehensive case examples cited here are from Carnegie-Mellon University’s Software Engineering Institute (SEI) software product line case studies (ND). At SEI the Product Line Systems Program, through the work of the Product Line Practice Initiative, has been the leader in many ideas and pioneered many of the practices that characterize the software product line approach to software development. In the SEI SPL Program, they are working to make software product line practice a systematic, dependable, low-risk, high-benefit practice that combines the necessary business and technical approaches to achieve success. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 46 Therefore, the study team examined the SEI’s SPL Program case studies because they are well documented and aligned with the effort of promoting sound SPL development and engineering. The cases selected provide a good basis for Constellation to develop a solid SPL approach by examining how other non-NASA organizations implemented SPL. It is useful to examine the technical and management approach, the benefits gained from SPL and also the potential pitfalls and challenges that are presented. By doing this, Constellation can development a meaningful SPL approach with a solid plan for software development and re-use strategy that carefully balances benefit and risks while maximizing success. There are a total of four cases discussed here. The first three cases were chosen to show successful non-NASA implementations of SPL that have similarities to the Constellation Program and therefore can yield beneficial lessons learned that are directly applicable to the program. The last case on NRO’s CCT effort is also a non-NASA case NOT from the Hall Of Fame but has strong correlations to the type of SPL software development effort that can be expected on Constellation These cases selected from the Software Product Line Hall of Fame were chosen due to the selection criteria. The criteria are that members had to serve as models of what a software product line should be, exhibiting a majority of the following characteristics: • The family that constitutes the product line is clearly identified, i.e., there is a way to tell whether or not a software system is a member of the product line, either by applying a known rule or a known enumeration. • The family that constitutes the product line is explicitly defined and designed as a product line, i.e., the commonalities and variabilities that characterize the members of the product line are known and there is an underlying design for the product line that takes advantage of them. • The product line has had a strong influence on others who desire to build and evolve product lines, and has gained recognition as a model of what a product line should be and how it should be built. Others have borrowed, copied, and stolen from it in creating their product lines or in expounding ideas and practices for creating product lines. • The product line has been commercially successful. • Interestingly, the Hall of Fame cases must have sufficient documentation about the product line that one can understand its definition, design, and implementation without resorting solely to hearsay. 4.03.2 Bold Stroke Avionics Software Family, Boeing The Bold Stroke Software Product Line is comprised of a wide range of artifacts required to create Operational Flight Programs for a variety of Boeing military fighters. A well-defined software architecture and carefully designed approaches to handle commonality and variability were crucial to the success of this product line. The architecture is heavily based on and CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 47 expressed via object-oriented patterns. These patterns were leveraged to convey both the architecture and its rationale to a large community of software engineers previously experienced primarily with military standard assembly language systems. CORBA was selected as the communication middleware for Bold Stroke. The product line exploits commercial standards, technologies, and products as much as possible, using an open source CORBA real-time Object Request Broker—the ACE ORB-developed in partnership with Washington University in St. Louis and a commercial real-time operating system. The Bold Stroke Software Product Line is the foundation for an increasing number of production and research programs including several funded by the Air Force Research Laboratory and the Defense Advanced Research Projects Agency. 4.03.3 A-7E Operational Flight Program, U.S. Naval Research Laboratory The A-7E operational flight program (OFP) is the software that assists the pilot of the Navy’s A7E aircraft to operate the airplane. The OFP was redesigned by the Software Cost Reduction project at the Naval Research Laboratory to show how to apply family-based software development principles in the development of a hard real-time system. Commonalities and variability’s were explicitly identified starting in the requirements specification for the family, and were a strong driving factor in the modular design of the OFP. The OFP design, including a modular structure, a process structure, and a uses relation, was explicitly created and documented to be an engineering model that others could follow. It has had a strong influence on the field of both software engineering and of product line engineering. 4.03.4 ShipSystem 2000, CelsiusTech Systems AB ShipSystem 2000 is a family of naval shipboard comment and control systems produced by CelsiusTech Systems AB of Sweden since the late 1980s. Begun in 1985 as a business and technical response to two large contracts awarded simultaneously, ShipSystem 2000 is based upon a robust architecture that was designed to handle both of those initial systems as well as the more than fifty variants that followed. Family members include systems for ships from coastal corvettes to cruisers to submarines, for navies all over the world. These systems comprise 1–1.5 million SLOC of Ada code, are hard-real-time, embedded, and safety-critical. CelsiusTech has been able to slash production time, build more systems with fewer people, and increase quality. The story of ShipSystem 2000 was one of the first and most important case studies in successful software product line engineering. 4.03.5 United States National Reconnaissance Office (NRO) Control Channel Toolkit (CCT) The last non-NASA case presented here is the Control Channel Toolkit (CCT) developed by the United States National Reconnaissance Office (NRO). NRO recognized that much is the same comparing one ground-based spacecraft command and control system to another. The details surrounding the NRO CCT case can be found at the SEI website and so will not be discussed here. However, there are striking similarities between that case and the challenges we face at NASA and specifically on Constellation. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 48 To reiterate, a software product line is a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way (Clements and Northrop, 2001). As it turns out, NRO made some good decisions by recognizing that there is great commonality in their delivered systems and that they too could benefit from the advantages of applying SPL thereby taking advantage of the commonality to build a product line asset base for their ground-based spacecraft command and control software. The first delivered system in their product line showed overall reductions in cost of 50% with a greatly reduced workforce. In addition, software defects went down significantly. 4.03.5.1 NRO CCT and Similarity to Constellation NRO set out to develop CCT which is a software asset base, funded and developed by one organization and built under contract with Raytheon Company as an industry partner. This software supplier contractor arrangement and the interaction between the two organizations are also common in NASA. Many spaceflight missions are, for example, are managed by one NASA center, while the spacecraft is built by an industry partner such as Lockheed Martin, Ball Aerospace, etc. NRO did not develop the entire system from architecture through final products; rather, they provided overall core assets containing an architecture, requirements and development processes and then disseminated the product development to other teams. On Constellation, the complexity and challenges are even greater than this. Here we have many NASA centers and several contractors that need to work together in developing perhaps the largest and most complex software system since the Apollo program. 4.03.5.2 Managing Several Teams with SPL Therefore, much like NRO, it is conceivable that Constellation will not develop a complete software system or complete SPL. Rather, Constellation will develop an asset base which consists of generalized requirements, domain specifications, a software architecture, a set of reusable software components, test procedures, a development environment definition, and the very important documentation needed for reusing the architecture and components. The Constellation users will build products. The users described here are the individual teams and government contractors under direction of a NASA Center to build spacecraft flight and ground software assets. As NRO did, Constellation may decide to have product development and the core asset development divided among potentially different teams/contractor organizations, where users (team/contractors) share the management responsibilities. A core asset is a software artifact that is used in the production of more than one product in a software product line. A core asset may be a software component, a process model, a plan, a document, or any other useful result of building a system. One of the most important core assets is the software architecture for the product line. The scope of the core asset differs from traditional reuse in that the scope must span the needs of the entire set of products, and provide a context in which other assets, such as code and test artifacts are related. The core asset must also be developed with the right flexibility to satisfy the products in the product line. The scope of the core asset needs to clearly state what CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 49 products the core assets are intended to support. The scope defines the commonality between the various products and the ways in which they differ. For Constellation, the SPL will represent a significant departure from traditional attempts of software reuse schemes in which well intended architects have made assets as general as possible (domain light) without the context provided by an architecture and a scope definition. These approaches typically designate some repository of components or frameworks that are too general, lack domain depth, have insufficient descriptions, lack good documentation and require way too much adaptation to claim valuable reuse. 4.03.5.3 Need for an Early Architecture Product lines pay off because the investment in the core assets is allocated across the entire family of products, and as NRO has discovered, it’s good to have an architecture (a core asset) early in the lifecycle in order to provide a clear production capability that allows rapid construction of high-quality products. Lessons learned from NRO indicate that perhaps Constellation should create an Architecture Group early on. This group will advocate the creation of an Architecture Model for Constellation to clearly communicate Constellation architectural concepts and decisions to Constellation users who would build future products. Learning from NRO’s CCT case where it was important to communicate architectural features early on to the builders it will be even more paramount on Constellation with the myriad of teams and contractors. 4.03.5.4 Technical and Cultural Challenges Using SPL for Constellation A major challenge for the Constellation team is two-fold. There is the newer technical side of SPLs where a well thought out architecture and reuse strategy is needed, along with the numerous tools, methods and processes to ensure successful development and delivery. But also, there is the cultural paradigm change that will need to occur which includes leadership and solid management, careful planning, a clear view of the approach, training, collaborating and obtaining the necessary buy-in to bring together many software teams from various NASA centers. Skilled organizational management is needed to adopt software product line engineering, achieve the correct organizational structure, and establish an effective customer interface. These and other practice areas are described in the SEI SPL Framework for Software Product Line Practice. The challenge of NRO to develop new systems with shrinking budgets was probably the original trigger for turning to software product lines as a cost-saving system acquisition strategy. NASA, and Constellation as a project within NASA, must operate in a new era of greater technical and fiscal responsibility as well. Projects are constrained more and more today by cost caps in which projects must not exceed them without risk of major descoping or possibly cancellation. 4.03.5.5 Constellation Scope and Complexity However, unlike NRO, Constellation faces the issue of greater scope and a plethora of partners. This may be the single greatest reason for the SPL approach. Constellation will set out early to define “what” kind of products will be needed to reach programmatic needs. From here, solid CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 50 requirements and an architecture developed early by the Constellation Architecture Group will allow all teams to better understand the core assets needed to further the design of their systems to develop products. Learning from the NRO case, it is recommended that a team be formed early to explore architecture definition, process definition, operations and maintenance definition, cost analysis, schedule assessment, and risk assessment. 4.03.5.6 Leadership in Management within SPL Environment For NRO’s CCT effort, it has been noted that successful management of a product line effort requires sophisticated management skills and well-honed leadership qualities. While some of the leadership was attributed to strong personalities with great drive to succeed, it is recommended that a well-conceived training program be developed to ensure all Constellation teams receive excellent training in Software Product Lines (SPLs) and project leadership courses. CCT was completed on schedule and within budget and with no outstanding risks. There are only a few organizations developing software these days that can make such a claim and represents a significant change in the software success arena. NRO originally set out pursuing a product line approach to reduce development costs, increased quality, improve the evolution of software for future use, decrease time-to-field, and obtain savings in sustainment costs, all of which were achieved. 4.03.5.7 Lessons Learned on NRO CCT Project Constellation can greatly benefit from NRO’s CCT effort through the Software Object Technology Group, a joint government and industry group led by NASA and the NRO, which already has applied the CCT architectural concepts to the definition of an object/interface standard for space-related applications. 4.04 Discussion and Analysis This subsection summarizes the lessons learned from the case studies with special emphasis on the software product line approach and challenges in implementing this approach; it concludes with an overview of potential solutions for these challenges. 4.04.1 Overview of NASA Case Lessons The AMMOS study shows there can be substantial long-term benefits to system-level reuse. These benefits are far more than cost savings—better planning, shorter development cycle, and high reliability (see Table 4-2). To achieve these benefits, however, Constellation must overcome the challenges associated with managing a software product line: mature system issues, early user considerations, standardized products, early investment, and configuration management. Solid programmatic planning and significant up-front investment is needed to alleviate the concerns for early users. Organizational incentives and disincentives must be managed and program plans must be specifically designed to support the product line approach. The ROSE case describes a product-line approach to reengineering the Shuttle Flight Analysis and Design System (FADS). It illustrates the use of Object Oriented Software Engineering CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 51 techniques and employs a dual-lifecycle approach—an approach that allows a strong architectural team to focus on overall product line design while individual implementation teams focus on applications. This case emphasizes the importance of training when employing several new techniques (multiple learning curves) and when teams are operating in parallel. A pilot effort helped to eliminate process bugs. Process discipline is viewed as critical in implementing a product line effort. The ROSE Project emphasizes the importance of all stakeholders understanding and supporting the product line approach. The project was terminated when the scope was expanded too rapidly and in a way that was inconsistent with product line scope. The CLCS study focuses on how different team cultures and organizational interaction can affect reuse strategies. The study provides examples of how differences in terminology between organizational elements can result in software product specification problems. These issues need to be addressed before reuse efforts are undertaken. The CLCS study also provides examples of how using common service-provider software can complicate testing and communication across diverse groups. In addition, the study shows how frameworks can help achieve high levels of software reuse at the application level. The GSFC Ground Systems Study shows that reuse of architectures and components can achieve both productivity and quality improvements in relative proportion to the degree of reuse. It also indicates that these core assets have improved over time (with use) and because of the multiproject planning horizon—two important tenets of the product line approach. The SEEDS report provides well thought-out definitions of reuse and related topics such as reference architecture. The report recommends the establishment of a Reuse Integration Office to manage all reuse activities in the organization. It also encourages the use of reuse support groups —the SHAirED group at Goddard has been established to encourage reuse within the Earth Science Enterprise Data System. In addition to general guidelines for reuse, the SEEDS report provides recommendations for reuse technologies and program strategies. Many of these will be directly applicable to Constellation Systems. One finding is that different approaches to reuse (e.g., Clone and Own vs. Product Line) may be appropriate for different user groups. This conclusion needs to be carefully considered in establishing a software product line. Programmatic support and stakeholder buy-in are vital as evidenced in the ROSE case. 4.04.2 Overview of Non-NASA Case Lessons Each of the three cases selected from the Hall-Of-Fame expose an advantage to using SPL on large software-intensive projects that relate to Constellation. Key in the use of SPL during the planning and development on Constellation should be availability to lessons-learned from other government and non-government involvement with SPL as well access to the materials and experts in the SPL subject area at Carnegie-Mellon University. The Bold Stroke case focuses on the positive aspects of SPL implementation by having a welldefined architecture early on that is heavily based on well-expressed object-oriented patterns that could be communicated to a large development community. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 52 The A7E Operational Flight Program case illustrates the gains in SPL realized from having a well-defined process and engineering model for a large to team to follow. The ShipSystem 2000 case shows success in using SPL for the development of real-time safetycritical development effort on a very large scale. Finally, the NRO CCT case shows several parallels to Constellation and lessons-learned that feed directly to the Constellation Program. NRO is funded and developed by one organization and built under contract with Raytheon Company as an industry partner. This model can be expanded and applied to Constellation and to management and technical relationships with other NASA Centers and industry partners. NRO had a supplier-contractor arrangement where the interaction between the two organizations was essential to the final products. The same will be true for Constellation. NRO needed to leverage from the commonality of their ground-based spacecraft command and control software and therefore, built a product line asset base for final product development. Constellation faces the same kind of challenge in developing an integrated flight and ground software system. NRO also developed an early architecture as the preliminary core asset and disseminated it to the other teams that could then carry out the development of the final product. Constellation will need to convey early architectural assets to other teams for final product development, test, integration and delivery. Lessons learned from NRO indicate that perhaps Constellation should create an Architecture Group early on to communicate architectural ideas and obtain buy-in by various stakeholders. Constellation has a myriad of partners to share technical information with and can greatly benefit from such a working group. 4.04.3 Summary of Case Study Challenges and Solutions Lessons learned from the NASA and non-NASA case studies that are applicable to the Constellation Systems effort are summarized in Table 4-6. The benefits have been discussed above. Many of the solutions shown in the table are discussed more fully in Sections 6.0 through 8.0. They are highlighted here to emphasize their relationship to the cases and provide motivation for the recommendations that follow. If constellation chooses a product line approach, it is essential to get the buy-in of the entire organization. This requires strong programmatic leadership and a well-defined architecture. Achieving stakeholder buy-in will require appropriate education as well as significant management attention. Core assets are the lifeblood of the product line and Constellation must nurture these resources. A major aspect of this challenge is managing the evolution and erosion of software over time (see Subsection 4.2.1.4). This means continuous investment in core asset software improvement throughout the life of the code. Product lines must be planned with evolution in mind and implemented with appropriate technology (e.g., object-oriented paradigms, frameworks, etc.)— see discussion of technical factors and recommendations in Sections 7.0 and 8.0. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 53 One of the strongest arguments for a product line approach is the huge scale of Constellation and the need for interoperability and compatibility. The non-NASA cases have demonstrated considerable success in achieving commonality of systems and architectures and in achieving very large scale reuse (see Subsection 4.3). These organizations have also demonstrated the ability to manage complex contracting relationships (note especially the NRO case). A product line that is developed for multi-mission use is, by definition, not optimized for a specific mission or narrow domain. Reuse will be more efficient to the extent that missions and domains adopt the same standards that were used to design the product line. The product line should, of course, be planned to support future missions. The point here is that common standards make both project adaptation and product line design easier. Table 4-6. Case Studies—Lessons Learned* Benefits • • • • • • • • • • • High return from product line approach roach (long-t (long-term) Shorter development cycle for new w missions Reduced development cost for new w missions High reliability/reduced risk through h testing in multiple missions/domains Reduced testing time and cost New missions benefit from the availability vailability of su substantial functionality Lessons learned from prior missions ns are automa automatically incorporated Planning uncertainty is reduced byy predictabil predictability of product costs Allows focus on mission objectivess rather than software development Innovation costs spread across multiple missi missions Product line discipline is valued byy team memb members Challenges Solutions Entire organization support for product line approach Buy-in by stakeholders Support for core assets and domain engineering Strong programmatic leadership Well defined architecture Strong architecture team Education and training: the how of reuse Core software has a lifecycle; it will evolve and erode Continued programmatic investment over time. Product line approach: Core assets require maintenance and new investment Planning for evolution to avoid obsolescence. Dual lifecycle approach Modern reuse technology: Frameworks and design patterns Object-oriented techniques and languages Commonality of systems and architectures Product line approach Very large scale reuse Complex contracting relationships See NRO case for model solutions No one wants to be the first user of new products. Early users’ functionality may be limited. Early users may face increased risk. Standard products Domain differences/team cultures Product line configuration management is crucial. Programmatic planning and up-front investment Product software should be delivered to not developed by early users. Product line planning (incentives and standards) Reuse Integration Office Incentives Standardized requirements across domains Early attention to cultural differences Product line planning Clone and own (for some users) CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Rapidly expanding project scope Mismatch of product and application Too many new processes and learning curves Revision: 0 Page 54 Product line scope control Product line definition Clear definition of product line approach Education and training Pilot projects *It is important to note that most of these lessons are applicable pplicable at multiple reuse levels (system, program, module) and multiple development stages (requirements, design, n, code). Early product users need special attention. Product development should be funded separately from individual missions and planned for delivery to the first user. Use of incentives and standards are vital (for early and later users)—see Sections 7.0 and 8.0. Both the AMMOS and CLCS studies emphasize the importance of configuration management (CM) and illustrate how version control can become complex when core software is under continuous development while products are being used in multiple applications. Configuration control and versioning is especially important as the dependencies increase. To reduce complexity, product line evolution should be planned to release versions at times consistent with mission needs and plans—see product line planning recommendations in the following sections. The system architecture should be developed early and with great attention to detail so that major architectural changes are not required as the system evolves: the architecture should facilitate evolution, not hinder it. Finally, Constellation must pay special attention to product line definition. Several cases have shown the importance of maintaining a clear focus on the defined scope while allowing it to evolve over time to take advantage of new opportunities. Both NASA and non-NASA cases provide key insights and are sources of information for Constellation planners. This concluding section has focused on identifying product line challenges and solutions that were developed from the case studies. The remaining sections of this report are devoted to developing these and other solutions that form the basis of a reuse strategy for Constellation Systems. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 55 5.0POTENTIAL BENEFITS OF REUSE This section describes benefits that accrue from reuse of software development artifacts. Artifacts that can be reused include plans, cost estimates, schedules, requirements models, specifications, designs, human/machine interfaces, documentation, code, data, test cases, and application generators. 5.01 Discussion Systematic reuse is viewed as a possible means to reduce software development costs while improving software quality. The benefits of software reuse are substantial. For a particular project, the dollar savings can be readily calculated by estimating the cost for development without reuse and subtracting the cost for development with the reuse of existing software components. Because the quality of the software is normally known and is generally higher than that of a newly developed software component, a high level of confidence in the software is achieved through familiarity with it. A list of potential benefits for Constellation include: • Increased productivity • Shorter project schedule • Reduced net costs over time • Increased quality and reliability • Earlier requirements validation • Lower risk due to more accurate estimates • Higher ability to leverage expertise in individual domains The largest savings in reuse are anticipated through leveraged reuse and not opportunistic reuse. In 1992, the Advanced Research Projects Agency (ARPA) projected software costs and savings for the next 16 years. The savings anticipated in reuse-based software development equals the combined savings of process improvement and software development tools. Section 4.0 on NASA case studies documents these benefits in prior missions (see Table 4-2). Section 4.0 also supports the benefits described below. 5.01.1 Increased Reliability and Overall Quality Ideally, a software artifact that is developed for reuse would be verified to be correct, and would contain no defects. In reality, with reuse, defects are found and eliminated, and as a result, an artifact’s reliability is improved. Over time, the artifact can become virtually defect-free (or sometimes it merely reaches an equilibrium with respect to the number of defects as shown in Table 5-1 (Matsumoto, 1995).7 This is especially important for upstream artifacts such as 7 Personal communication, Barry Boehm to a study member regarding an OS/360 example. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 56 requirements and designs because these errors are more expensive to correct later in the lifecycle than are programming errors. Table 5-1. Reported Benefits From Reuse Organization Nippon Electric Productivity 6.7x Cost Development Time 75 Ada Projects 10x Toshiba 20%–30% fewer defects DEC 1.25x 0.33x–0.2x HP1 1.5x 0.57x HP2 1.4x Raytheon 1.5x 9 companies 0.16x 0.3x 1.2x 0.75x 1.15x–1.5x 0.9x–0.5x US Navy simulator 2x NASA 76% fewer defects 24% fewer defects 312 aerospace projects Japanese industry 20%–35% fewer customer complaints 0.25x AT&T SofTech Quality 2.8x, 5x–10x 0.5x 10x–20x 5.01.2 Reduced Development Time Development time is reduced because it is not necessary to spend the time to develop and unittest the reused artifacts. The reused artifacts incorporate lessons learned and avoid the time for reinvention or rediscovery. 5.01.3 Increased Productivity When reusable artifacts are applied throughout the software process, less time and effort is spent creating the artifacts that are required to create a deliverable system. Development is simplified. Therefore, the same level of functionality is delivered to the customer with less input effort, improving productivity. Rough estimates suggest that 30% to 50% reuse can yield productivity improvements in the 25% to 40% range. Others experienced from 7× to 20× improvement (see Table 5-1). Leverage is obtained by employing commercial and open-source components. The use of application generators can achieve order-of-magnitude productivity gains (Tracz, 1995), and may also have the benefit of enabling domain experts to specify the component, rather than requiring programmers as intermediaries. 5.01.4 Reduced Cost A reduction in cost results from less time and effort being spent developing the software product; also testing costs are lower. An increase in the quality of the software means less expense CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 57 detecting and correcting defects, especially the expensive ones discovered late in the development process. Table 5-2 contains information from military projects, and depicts the return on a $1.00 investment after four years and 24 uses for each of the artifacts noted above (Jones, 1994). Quantitative evidence indicates that the effort it takes to reuse a piece of software is 20% of the cost to develop it for one-time use (Poulin, 1997). Table 5-2. Return on Investment by Reusable Artifact Reusable Artifact Four-Year Return ($) Project plans 2.00 Cost estimates 3.00 Architecture 1.50 Requirements models / specs 3.00 Designs 5.00 Source code 6.00 User/technical documentation 1.50 Human interfaces 1.00 Data 3.50 Test cases 3.50 Reuse can occur at many levels of the software system development process, as discussed earlier. A simple list would include requirements, design, code, and validated code. Jensen (2004) performed an economic analysis of software reuse and demonstrated that results were independent of the particular software cost modeling tool used (e.g., COCOMO). His model provides a simple yet realistic prediction of software product costs in an environment containing reused software artifacts. Although his results assume that a mature reuse organization and a mature body of reusable assets that are readily available, the results provide a useful baseline model. Figure 5-1 shows the relative development cost versus reuse fraction by reuse type. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 58 Figure 5-1. Relative Development Cost vs. Reuse Fraction by Reuse Type (from Jensen, 2004) A realistic full-lifecycle cost model with no externalized costs is important. Most techniques for increasing reusability, such as modularity, high functional cohesion, low module coupling, and use of standards, are good software engineering techniques and should be used regardless of the reusability issue. The cost required to implement a cataloging scheme for retrieval of software from reuse libraries can be significant. Domain engineering is a new concept and requires training and manpower. Disagreements over ownership rights and liability issues of reused software components can result in costly legal services. Enthusiasm for software reuse can lead to overestimating cost savings and underestimating cost increases, thus biasing the cost-benefit analysis. A list of costs include: • Domain analysis and modeling • Domain architecture development • Certification and quality assurance of reusable components • Increased documentation to facilitate reuse • Maintenance and enhancements of reuse artifacts • Royalties or licensing fees for externally acquired components • Operation of a reuse repository • Resolution of ownership and liability • Additional time to negotiate interfaces suitable to multiple users of the interface • Negotiating component evolution with many users of that component CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report • Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 59 Training of personnel in design and coding for reuse 5.01.5 Reduced Development Process Risk Because known artifacts are being reused, there is less uncertainty in the product, leading to better schedule and cost predictability. The uncertainty in the cost of reusing an artifact is less than that of developing it, especially in the case of large subsystems (Sommerville, 2004). In addition, the capabilities of the system can be planned more accurately (see Table 4-2). Also, the risk of innovation is spread over more applications. 5.01.6 Increased Maintainability Maintenance cost reductions of up to 90% have been reported when reusable code, code templates, and application generators have been used to develop new systems. Maintenance consists of fixing errors and implementing new functionality. The benefits for reliability of reuse have been mentioned above. The ease with which new functionality can be implemented is dependent on how modular the system is relative to the needed changes. To the extent that modifications can be foreseen, the point of domain engineering is to understand the problem domain so that its reusable modular components are identified. At the extreme end of maintenance, product-line engineering enables cost-effective development of an envisioned suite of products. As an example, Constellation ground software will have to support a variety of mission architectures. Investing in domain engineering up front could allow the ground system to endure the evolution of the missions. 5.01.7 Continuous Improvement and Increased Evolvability Reuse of interfaces defined by an abstraction layer enhances continuous improvement and evolvability. Defining a reusable interface insulates applications from their implementation platform, allowing for substitution of the platform implementing the interface, and preventing obsolescence. Examples of major sources of obsolescence are operating systems, COTS products, hardware, and data formats. To ameliorate the problem with operating systems, a platform-independent layer can be specified which provides certain system services. It can be implemented by invoking calls to a particular operating system. If that operating system eventually is no longer viable (because the vendor went out of business, or it doesn’t meet timeliness requirements), another operating system can be substituted by re-implementing the layer using the new operating system.8 For hardware, defining a byte-code interface language (as with Java) allows portability among different hardware. For data formats, formats defined in XML allow for regeneration of the programs that process the data as the requirements of the information stream evolve. 8 This approach was taken for the TOPEX and Jason satellites: a layer was defined that provided services for memory allocation, buffer management, name services, file access control, concurrency control, and inter-process communication. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 60 Another example is middleware, which insulates applications from each other by interposing an intermediary system, thus allowing the two applications to evolve separately. CORBA is an example of a middleware standard with implementations available from multiple vendors. It has been used in a number of large and mission-critical systems. Evolvability is a critical issue for Constellation because of the program’s intended long life span. Defining appropriate reusable interfaces could ensure evolution within reasonable cost. 5.01.8 More Effective and Efficient Use of Specialists The specialized knowledge needed to construct an artifact is encapsulated in the artifact itself; that knowledge is reused when the artifact is reused, and thus it is not necessary to obtain the labor of the specialist again for the new application. In many cases, especially those cases where reliability or performance are critical, the user of reusable code typically seeks to acquire the developer of that reusable code, and if that specialist is available, productivity and quality will benefit. Class A code generally isn’t as “opaque” as is portrayed here. The real benefit comes incrementally as a decreasing reliance on the original creators (if available) of software when there is a desire to reuse it. 5.01.9 Easier Compliance with Standards To the extent that the artifacts embody standards, or were developed in accordance with standards, the new applications making use of those artifacts inherit those standards. This is applicable to software development process assets that may support a CMMI maturity-level rating, as well as code that satisfies coding standards. This is a very important point. In the case of Application Program Interfaces (API), such standards open the door to broader participation by the software development community in industry and other organizations and may very well help determine new standards. 5.01.10Increased Flexibility There is flexibility as to how a product is developed. In periods of high demand, developers would have a higher level of reuse in their designs (design with reuse), leading to higher productivity. A “design for reuse” philosophy can be applied when demand is low. 5.02 Findings Constellation has the opportunity to realize major benefits from software reuse in a number of areas as discussed in this section. The degree to which these benefits are realized will be a function of the effectiveness of the overall implementation of the technical and non-technical aspects of reuse policies and procedures. With respect to software systems engineering practice, most techniques for increasing reusability —such as modularity, high functional cohesion, low module coupling, and use of standards—are good software engineering techniques and should be used regardless of the reusability issue. Based on the study team’s analysis of NASA and external case histories, a few areas realizing benefit are noteworthy: CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 61 • Productivity: Reduced time to deliver the same functionality: 25% to 40%. • Quality: Reduced defects via reuse of iteratively refined and matured software. • Cost: Reduced development time and improved quality yield return on investment for a variety of reusable products ranging from 100% to 600%. • Flexibility: Software (all artifacts) designed for reuse enable more rapid response to demand and systematic adaptation to a variety of requirements. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 62 6.0RISKS, OBSTACLES, AND MITIGATIONS 6.01 Introduction There are problems in deciding what should be reusable and at what level of granularity reuse should be applied, but when properly done, then significant gains can be realized (see Appendix G). For reuse to be successful and cost effective, it needs to be applied from a higher level than that of identifying common subroutines. When the project is viewed as an evolving software product line composed of COTS, GOTS, and NDIs, then there are benefits. There are issues about at what level of abstraction the components should exist. When the same component is used more than once and its API changes, then there are ramifications to every instance where it is used. In order for a software reuse strategy to be effective, it means the components that are reused must be fairly static and not undergoing revisions. Management is sometimes reluctant to support a reuse approach because reusable software components usually cost more to develop. This is because rather than implementing the component for a single use, the big picture of how this asset fits in must be considered with possibly broader functionality. Additionally, a unified API needs to be developed and coordinated with all the users that intend to use the asset, requiring more complex testing and support. For software reuse to be truly successful, organizations must make an early commitment and investment in a reuse approach. Sometimes organizations are unenthusiastic because the returns are often not immediately realized or easy to quantify. 6.02 Technical Risks In reusing a component, what assumptions are necessary for the component to function correctly in a new context? Are the assumptions exhaustively known and specified? Can they be checked in the new context? 6.02.1 Software Inheritance Oftentimes projects will try to make explicit reuse of technologies, products, or processes that were developed for previous projects. The decision to do so is a function of determining whether the previous product was “good enough” or “close enough” to meet the new requirements. Unfortunately, more often than not, a real analysis is not done of the suitability of the reuse of existing software products. In the absence of such an analysis, the results are unpredictable and can result in multiple risks to the project, the most significant of which are system failure and cost growth. 6.02.1.1 System Failure A major reliability risk is undocumented or poorly understood dependencies embedded in the legacy software that are peculiar to the application system (e.g., CEV for ISS missions) that would not carry over to a new vehicle (e.g, CEV for lunar missions). Such dependencies may exist at any level in the software system and manifest themselves in multiple ways. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 63 An extreme example of this kind of risk is the Ariane 501 mishap—where a supposedly noncritical portion of the flight code from the Ariane 4 was reused without adequate analysis for the maiden flight of Ariane 5. A series of poorly documented assumptions dating back a decade led to the loss of Ariane 501 in the first minutes of the ascent phase. Specifically, in order to fit within a computational envelope, exception handlers were removed from parts of the Ariane 4 code. One of these removed exception handlers was for arithmetic overflows related to the conversion from floating point to integer of the “horizontal bias” variable—which measured the horizontal component of velocity up to the first minute after launch. There was a dependency between this exception handler and the thrust of the Ariane first stage. This dependency was forgotten over the course of a decade from the original development of the code for the Ariane 4 to its reuse on the Ariane 5. The more powerful thrust of the Ariane 5 literally caused a floating point to integer conversion overflow that led to loss of the maiden mission (Leveson, 2004). 6.02.1.2 Cost Growth Project cost growth can occur as a result of several technical and non-technical factors associated with the “inheritance” of code. This may occur at any level in the software system, with concomitant magnitude of impact at the software system level. Cost growth risks may be due to • inheritance of code that does not behave as advertised, • inheritance code that is poorly documented, or • inheritance code that required more modification than expected. The cost-growth risk can be mitigated by a number of methods, each of which contributes to a solution but may not be sufficient to completely mitigate the risk. Mitigations include (1) a thorough software inheritance review (see also criteria for such a review, discussed elsewhere in this report), (2) ensuring that engineers who are knowledgeable about the inherited software come with the software or are otherwise available, and (3) ensuring that software to be reused, or “inherited” is designed from the onset for this purpose and the appropriate infrastructure is created to maintain the code in a managed and certified condition. 6.02.2 Legacy Software Unlike software inheritance, where there is an explicit decision to capture and reuse existing software, “legacy software systems” are those that are considered out-of-date or are too specialized to be carried forward into a new design. They are often viewed as a hold-over until a complete system replacement occurs that may completely replace or eliminate the functions performed. However, the existence of legacy software is frequent enough that it should be considered as a special case for reuse. The risks involved are similar to inherited software, but typically plans are made to explicitly replace the legacy software. The risks become very significant when these plans for replacement go awry, and the legacy software now becomes “good enough.” CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 64 6.02.3 Reuse Process Risks Frakes and Fox (1996) identify seven reuse “failure modes,” each corresponding to a step in the process where reuse can fail. These include: (1) reuse was not attempted, (2) part does not exist, (3) part is not available, (4) part is not found, (5) part is not understood, (6) part is not valid; and (7) part is not integratable. The end result of any of these failure modes is a missed reuse opportunity. Failures that occur late in the process of attempting reuse are far more expensive than those occurring early in the process. These costs are analogous to those of any major software rework that occurs due to other failures, and are highly context-dependent. 6.03 Non-Technical Risks Non-technical risks refer to those factors that affect the planned reuse of software, but do not pertain to the technology of software engineering. These factors can be organizational, administrative, psychological, or legal and can sometimes overwhelm the technical challenges. If not addressed in policies and guidelines, they can often spell the difference between cost effectiveness and cost ineffectiveness. Kalagiakos (2003) writes: Current reuse support systems allow developers to gain some of the benefits of reusability but, in order for reusability to reach its full potentiality special attention has also to be given to the non-technical factors of software reuse. The greatest reuse technical solutions may fail if the human factor together with the contractual and legal issues are not addressed successfully. 6.03.1 Organization-Level Reuse Developing, deploying, and supporting systematically reusable software assets requires a deep understanding of application developer needs and business requirements. As the number of developers and projects employing reusable assets increases, it becomes difficult to structure an organization to provide effective feedback loops between these constituencies. Groups that develop reusable middleware platforms are often viewed with suspicion by application developers who resent the fact that they may no longer be empowered to make key architectural decisions. Likewise, internecine rivalries among business units may stifle reuse of assets developed by other internal product groups that may be perceived as a threat to job security or corporate influence. 6.03.2 Business and Economic Factors Supporting organization-wide reusable assets requires an economic investment, particularly if reuse groups operate as cost centers. Many organizations find it difficult to institute appropriate taxation or charge-back schemes to fund their reuse groups. Sound business practices must be applied when assessing the effectiveness of planned software reuse. If the Return on Investment (ROI) is poor, it may not justify the expense of reuse. Of course there are other factors that may be considered such as the need to maintain an effective skill base. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 65 More Resources and Time Required Reusable software requires more resources and a time factor that is often not taken into consideration during the planning process. For a typical project there is often little incentive for project managers to develop reusable software. One reason is, unlike hardware, there really is no easily accessible catalog of software components, therefore, developers continue to repeatedly “reinvent the wheel.” Contractual Incentives/Disincentives For most of the organizations within a corporate structure, the contract award process and individual rewards system are generally oriented against software reuse. Cost-plus contracts are disincentive to contractors to make use of reusable products. On a large project where numerous companies are involved, licensing issues and ownership of intellectual property rights make the reuse of software across the entire project extremely difficult. It is probably easier to develop reusable components of software within a corporation where these issues are not important. 6.03.3 Legal Factors Intellectual Property Rights Software is protected legally as intellectual property through laws that control its dissemination and use. These laws relate to the exclusive ownership of the idea, the form of expression of the idea, and the use of the idea and its expression. There are three basic methods to protect software: patents, copyrights, and trade secrets. Patents protect the rights to the idea itself, while copyrights protect the rights to the expression of the idea. Trade secret laws protect the rights to confidential business information. However, in many cases laws are not clear about the enforcement of intellectual property rights (Institute for Defense Analysis, 1991). ITAR International Traffic in Arms Regulations (ITAR) apply when development teams deal with foreign nationals and partners. Legislative experts must be consulted to ensure that appropriate international agreements can be drawn up to avoid the onerous restrictions of simplistic ITAR application. Today, many export items would be covered under an existing ITAR license for ISS. The cognizant NASA Center’s Export Control Office will determine if the export item(s) are covered by this license base on the technical information provided by the technical team or individual. If items are not covered by the existing licenses, the center’s Export Control Office will work with the NASA HQ Export Control Office and the U.S. State Department to apply for a new license. Depending on the export items, the process can take up to six months. If International Partners are part of the Constellation Program, it is recommended that the HQ Export Control Office apply for the “umbrella” license that would cover the data, technology, and knowledge exchange to ensure the cooperation necessary. Sharing data or technology does not mean that one must relinquish ownership of the intellectual property. The inventor or developer of the exchange items retains ownership of the items. The receiving party will have to comply with the copyright license. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 66 Liability In the context of software, liability refers to the legal responsibility for harm attributable to software components. Liability may affect not only the supplier of the component but also the user. For example, software suppliers could be liable for submitting defective software components that fail to meet performance standards or cause a software system malfunction. Liability is the responsibility of both the original and the “reused” developers. The original developers must document all the design architecture, capability, and sign effects (if any) of the object. The “reused” developers must make sure the object performs according to the document(s) and complies with the new system’s requirements. It is also important to thoroughly test the object as if it were developed in-house. It can be assumed as unnecessary to re-certify a module or object that has been certified for a certain critical level if it is reused for a new system with the same critical level. That may be true if the module alone is the new system. However, it would not be true if the module is only part of an integrated system. The integrated verification and validation process should be the same as if no reused part were included. The legal ramifications of software liability are fairly new. As a consequence, there is still some uncertainty (such as whether software is a product or service) about the nature of liability that may accompany software. For this reason, experts believe that organizations interested in reuse need to address liability issues, otherwise suppliers may be reluctant to submit components for reuse, repositories may limit the availability of components, and users may be unwilling to use the components in the repository. Responsibility Legal responsibilities often cause software reuse to not be considered viable for a project. One question arises as to who is responsible when a reused software asset fails. An even more complex question is, who is responsible when that asset is modified? Does this mean a purchaser of a reusable asset has the right to make changes when it is being used in a critical application? Using commercial aviation as an example, a common presumption is that some entity (typically the airframer) is responsible for ensuring the integrity of all modifications to a system. Thus reuse and interoperability arguments always hinge upon an overall organization maintaining a global safety argument. Unfortunately, this tends to limit opportunities for planned reuse in the aviation sector. 6.03.4 Psychological Factors and Incentives Although the benefits of planned software reuse may appear to net a positive return across a project or organization, the benefits may not always be perceived by the very people who are charged with developing the software. In “Why Software Reuse has Failed and How to Make It Work for You,” (Schmidt, ND) states, “Application developers may perceive ‘top down’ reuse efforts as an indication that management lacks confidence in their technical ability. The ‘not invented here’ syndrome is ubiquitous in many organizations, particularly, among highly talented programmers.” If the benefits are not perceived at the developer level, it will be very difficult for a given project (as well as for individual developers) to embrace reuse-compatible strategies. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 67 The uneven distribution of reuse costs and benefits across projects generates the bulk of incentive problems at the project team-level. Table 6-1 illustrates how reuse costs and benefits might be perceived locally by a software development team. Note that, in the absence of incentives—specifically at the producer-level—local costs clearly outweigh the local benefits. 6.03.5 Inadequate Training Schmidt goes on to say: As if these non-technical impediments aren’t daunting enough, reuse efforts also frequently fail because developers lack technical skills and organizations lack core competencies necessary to create and/or integrate reusable components systematically. For instance, developers often lack knowledge of, and experience with, fundamental design patterns in their domain, which makes it difficult for them to understand how to create and/or reuse frameworks and components effectively. Developers have often been observed putting too much faith in language features, such as inheritance, polymorphism, templates, and exception handling as the primary means to foster reuse. Unfortunately, languages alone don’t adequately capture the commonality and variability of abstractions and components required to build and systematically apply reusable software in complex application domains. Table 6-1. Local Reuse Costs vs. Benefits (Fichman and Kemerer, 2001) Reuse Costs Reuse Producer Costs: • Cost of performing cost-benefit analysis • Cost of performing domain analysis • Cost of designing reusable parts • Cost of modeling/design tools for reusable parts • Cost of implementing reusable parts • Cost of testing reusable parts • Cost of documenting reusable parts • Cost of obtaining reuse library tools • Cost of added equipment for reuse library • Cost of resources to maintain reuse library • Cost of management for development, test and library support groups • Cost of producing publications • Cost of maintaining reusable parts • Cost of marketing reusable parts • Cost of training in software reuse Reuse Benefits Reuse Producer Benefits: • Added revenue due to income from selling reusable information • Added revenue from fees or royalties resulting from redistribution of information CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Reuse Consumer Costs: • Cost of performing cost-benefit analysis • Cost of performing domain analysis • Cost of locating and assessing reusable parts • Cost of integrating reusable parts • Cost of modifying reusable parts • Cost of maintaining modified reusable parts • Cost of testing modified reusable parts • Fees for obtaining reusable parts • Fees or royalties for reusing parts • Cost of training on software reuse Revision: 0 Page 68 Reuse Consumer Benefits: • Reduced cost to design • Reduced cost to document (internal) • Reduced cost to implement • Reduced cost to unit test • Reduced cost to design tests • Reduced cost to document tests • Reduced cost to execute testing • Reduced cost to product publications • Added revenue due to delivering product sooner to market place • Reduced maintenance costs • Added revenue due to improved customer satisfaction with product quality • Reduced cost of tools • Reduced cost of equipment • Reduced cost to manage development and test 6.03.6 Additional Risk Findings The following findings point to additional risks that must be taken into consideration in a planned software reuse development program. 1. A cross-cutting reliability risk is the reuse of software on platforms for which it was not originally designed. 2. Without careful design in advance for portability and reuse, there are likely to be dependencies built into the software peculiar to the legacy platform (e.g., aerospace vehicle). 3. A major reliability risk is undocumented or poorly understood dependencies embedded in the legacy software that would not transfer to a new application. 4. The use of reuse components, COTS, GOTS, or any other non-developmental items (NDI) is a risk that can be addressed by thorough risk management processes. 6.04 Mitigation Strategies Mitigating the technical risks of planned software reuse is largely based on effectively addressing the previous hard-won lessons of software engineering and computer science such as the strategies of structured programming, information hiding, modularization, and planned software reuse.9 Structured programming is the “adherence to a strict discipline of a few wellunderstood control structures. The lesson could be summarized as: ‘Give careful thought 9 Mitigation Strategy, citations from Software Program Managers Network, 2005. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 69 to the structuring of your software.’ Its goal is software that is easier to construct, prove correct and maintain, by keeping the structure clean and simple.” Information hiding is the “separation of concerns. The lesson here is: ‘Don’t bother users of your code with what happens inside, since they shouldn’t need to know.’ The goal is to hide unnecessary details, making the total software package a group of black boxes, each performing its specified function. The process involved is data abstraction and specification.” Modularization is the “structuring of code, grouping related pieces into modules. The lesson is: ‘Group logically related parts, so as to group related problems and to make their being solved easier.’ The goal is to collect related problems, easing again both construction and maintenance. The process involved is functional abstraction.” Planned software reuse implies using previously existing software assets to build new software. The lesson is: To modularize your software so it can be reused in other applications. The goal is using those assets to reduce the development effort and improve the quality of the software rather than creating it from scratch. Although, these four strategies are very much related, the difference is in their emphasis (Laverman, 1995): Strategy Emphasis Structured programming Design & implementation Information hiding Data abstraction Modularization Functional abstraction Planned software reuse Effort & quality Mitigations that address some of the specific risks identified earlier are described in the following subsections. 6.04.1 Mitigation for Inherited Software Risks Without careful design in advance for portability and planned reuse, there are likely to be dependencies built into the software peculiar to the legacy platform (e.g., aerospace vehicle). Reuse then requires careful analysis, removal of the dependencies, testing, and recertification. This effort is facilitated if the software, design, and code are well-documented; but for humanrated software, the reliability standard is necessarily high: all dependencies need to be tracked down and analyzed. 6.04.2 Mitigation for Legacy Software Risks There are four main ways of successfully reusing legacy software components and systems: • Reuse legacy code on top of new hardware that emulates the functioning of a legacy computer. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 70 • Reuse the legacy source code using new compilers/assemblers targeting new hardware platforms. • Translate legacy source code to new source code on new hardware. • Mine selected artifacts related to the software for reuse—design, requirements, algorithms, etc. These options are actually technical solutions in nature, but because they entail development costs that are sometimes unforeseen or unplanned, the use of legacy software can become a significant factor in the business case decision for planned reuse. 6.04.3 Mitigation for Business and Economic Factors Previous reuse histories and case studies may yield important signs of whether a particular reuse path is worth pursuing. Potential risks and mitigations of those risks must be assessed prior to deciding on reuse. (This is one of the purposes of this study, itself.) Figures of merit (FOM) must be constructed that will enable management to judge the potential worthiness of reuse. Examples for FOMs may include: • Modularity of reusable elements • Proven reusability of candidate reusable elements (%) • Complexity of reusable elements • Revision history of reusable elements A number of early investments are needed to make reuse viable even if case histories, figures of merit, and other analytical tools are already in place. One early investment is a sharable archive and retrieval system for reusable components and systems that provide for associated documentation. Table 6-2 shows typical targets of early reusable software investments (Boehm, 1997). Table 6-2. Targets for Early Investment to Enable Reuse COST FACTORS • • • • • • • • • Domain engineering Architecture determination Reusable components development Legacy software reengineering Process redefinition Training, teambuilding Repository development and operations Component certification Component maintenance MAJOR COST DRIVERS • • • • • • • • • • Breadth, maturity of domain Architecture maturity; diversity of legacy, COTS software Breadth of reuse; other cost drivers Legacy SW structure, understandability Process maturity Novelty of PLM approach; number of trainees Number of components; users Number of components; degree of certification Stability of application, technology, environment, and infrastructure Type of product (package, service) CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 71 Early investments in these cost-factor areas will help mitigate some of the typical costs of planned reuse which arise from: • Locating and determining reusable software components • Modifying reusable software components • Integrating and testing assets as well as products that use reusable software components • Product/asset maintenance • Software asset acquisition and maintenance fees 6.04.4 Mitigation for Psychological Factors: Incentives The software development environment must be positive in order to encourage planned reuse of software. Developers and software project teams must be able to realize rewards for appropriately and correctly making the decision to reuse rather than to reinvent software. Even in the best cases, some original designing and coding will be necessary to make best use of reusable components. The measurement of productivity performance should include the effectiveness of the architecture and structure in which the reusable components are placed. Developers must be cautioned about “2nd systems affect”—the tendency to try to include every feature that was left out of the first incarnation. A “reuse compatible” incentive program has the goal to maximize the probability that, for any given project, the benefits to that project will outweigh the costs as perceived by the project team. Some heuristics for such incentives are: • Encourage reuse where it has the highest probability of a net positive local payoff. • Seek ways to shift the extra costs and risks of reuse production out of individual projects. • Recognize and encourage all forms of reuse that have net benefits at a project level, including less leverageable forms (e.g., within-project factoring to isolate common code, and reuse of components previously developed by the project team itself). • Focus incentives to reduce the incidence of reuse failures that are the most costly to the consumers of products built with reused components. 6.04.5 Additional Mitigation Findings The following recommendations address additional methods of mitigating risks inherent in a planned software reuse program. 20. Reuse is most successful when designed in from the beginning in a “product line” oriented process. 21. Definition of the software product line architecture, specifically the definition of common components versus adapted or domain-specific components, has both an CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 72 immediate impact on viability of early and continuing reuse over the product line lifecycle. 22. Additional methods of addressing the technical risks of reuse include: • Standardization of reusable software components • Providing tools and training to support a development approach based on reuse • Providing a library of reusable parts that can easily be accessed and used • Using a software development methodology that fosters reuse 23. Non-technical risk factors can begin to be addressed in two simple ways, both of which are necessary but not sufficient for success: • Enlisting management support and enforcement for planned reuse • Emulating the behavior and actions of organizations that have to some extent overcome the difficulties of planned reuse CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 73 7.0SUMMARY OF FINDINGS 7.01 Opportunity to Realize Major Benefits from Reuse 1. Productivity: Reduced time to deliver the same functionality: 25% to 40%. 2. Quality: Reduced defects via reuse of iteratively refined and matured software. 3. Cost: Reduced development time and improved quality yield return on investment for a variety of reusable products ranging from 100% to 600%. 4. Flexibility: Software (all artifacts) designed for reuse enable more rapid response to demand and systematic adaptation to a variety of requirements. 7.02 Confidence from a Rich History and Broad Current Work on Software Reuse 1. Maturity: Case studies, lessons learned, and life-cycle information readily yield common technical and non-technical factors that can spell success or failure. 2. Enabling technology and standards: Software engineering methodologies, tools, languages, architectures, development environments, and standards are available; appropriate selection and use is directly correlated with success and value returned. 7.03 Requirement for Success: a Systemic Engineering Technical Approach 1. Staff must be trained in the discipline of developing reusable core assets. 2. Reuse is most successful when “designed in” from the beginning as part of a “software product line”-oriented process. “Design for reuse” includes the development of software architectures, common standards and interfaces. Attempts at reuse later in the lifecycle, or reuse of legacy systems, are virtually guaranteed to fail. 3. Effective reuse in complex systems benefits greatly from the use of middleware, for example CORBA. Ease of development and deployment, and reduced project cost are just two of the important benefits. Middleware functionally bridges the gap between application programs and the lower-level hardware and software infrastructure. By providing this architectural mediating function, middleware coordinates how parts of applications are connected and how they interoperate. It also enables and simplifies the integration of components developed by multiple technology suppliers. Standards are embodied and enforced by middleware. 4. An iterative development cycle allows time to learn from the past then architecture and core assets are developed. 5. Standardization is another important aspect and all areas of the software lifecycle need to be gradually standardized, for example, standardizing the components themselves as well as the methodologies of identifying, classifying, modifying and incorporating these components into a wide range of systems. Establishing a classification scheme requires combining the knowledge inherent in the components with the knowledge about the application domain where the components are going to CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 74 be used. Common characteristics of the components are then grouped and organized into a structure that can be easily understood. 6. The repository of core assets is the enabling tool for software reuse in a “software product line” approach. The repository builds on the standards and product line structure defined through domain analysis. It must be widely available, easy, and efficient to use. As a consequence, the storage, definitions, searching, accessing, and representation of components are just some of the factors that need to be considered in creating an “easy-to-use” repository. Such a repository must be built slowly and carefully, with components that are high quality and well documented. This approach is more likely to lead to (1) greater trust by reuse asset producers and consumers, (2) increased usefulness to software project teams, and (3) reduced risk in reuse with a corresponding lower average costs of reuse failure. 7. System level reuse may pay big dividends for Constellation. This requires up-front programmatic investment and attention to the Constellation Reuse Strategy, especially the software architecture and the establishment of an effective system level product line. 7.04 Importance of and Necessity of Both Technical and Non-Technical Factors 1. “To succeed in-the-large, reuse efforts must address both technical and non-technical issues. Focusing on non-technical issues alone neglects important skills-building education that must occur to succeed with non-trivial reuse efforts. Likewise, focusing solely on technological issues neglects the deep impact that social and economic forces and processes have on the success or failure of technology adoption.” Project policies, plans, commitments and management support must be in place early and consistently applied across the project. Non-technical issues in legal, procurement, intellectual property and related areas must be addressed. Management must make investments and support, enforce, and incorporate systematic reuse in their organizations and processes. 2. Significant investment must be expended up-front to produce efficient, flexible, and well-documented reusable software assets before they can be leveraged in subsequent generations of a product line. Therefore, organizations must support an appropriate software development process that allows systematic reuse to flourish. 3. It is not a question of whether Constellation should or should not reuse “software.” Reuse includes “non-developmental items” such as: legacy software systems, COTS, GOTS, MOTS, and a multiplicity of software engineering artifacts, processes, and procedures. The question is how best to practice reuse for both non-developmental items and project-developed software artifacts. 4. The importance of software reuse issues in the acquisition process cannot be emphasized enough. Some of the issues include (1) how reuse should be considered in the request-for-proposal process, (2) what criteria to use for evaluating proposals, CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 75 (3) how costs of reuse will be evaluated and estimated, and (4) what incentives are needed in solicitation documents to promote reuse. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 76 8.0RECOMMENDATIONS This section provides a set of team recommendations that, if adopted and carefully implemented, will enable the Constellation Program to realize and maximize the benefits of software reuse. Fully aware that there are a great many details to be developed, a second major purpose is to lay out the groundwork for a set of next-steps and follow-on studies. The team’s recommendations are grouped into two primary areas that are reflected elsewhere in this report. Non-Technical Recommendations address those factors that affect the reuse of software, but do not have to do with the technology of software engineering itself. Technical Recommendations address those factors that affect the processes, methodologies, and technical products of software engineering. Non-technical factors can easily overwhelm technical factors. The technical approach to reuse can be 100% correct and reuse can still fail if the non-technical factors are not handled properly. The team believes that it is essential to address both areas, and to address them early in the project lifecycle. For Constellation, this means that the Program must immediately undertake multiple actions to create the required technical and non-technical systems engineering products for reuse that in turn will make software reuse effective, readily usable, and a preferred implementation mode by Constellation programs and primes. Successful reuse efforts general execute these recommendations out of an office specifically chartered and empowered by the project to oversee the execution of the product line reuse effort. 8.01 Non-Technical Recommendations 24. Immediately establish a team to develop a comprehensive actionable product line reuse strategy that addresses the recommendations herein. The team should be empowered to guide other study teams to begin organizing Constellation in a manner that facilitates a product line approach. 25. Adopt and enforce management and organizational policies, processes and procedures that require and promote effective reuse across all Constellation elements. It is essential to ensure continuous, top-to-bottom management support for reuse policies, plans, and activities. In so doing, it must be recognized that the benefits of effective reuse may not become realized in an organization or product line for several years. The benefits of software reuse can only be realized and maximized if software reuse is formalized at the program level, and adopted or mandated at project level. The team proposes the following approach to help achieve awareness: • Brief Constellation management and highlight the executive summary with technical recommendations. • Brief stakeholders and others who will be responsible for implementing the recommendations (as adopted) of this report, including project managers, software system engineers, and software engineers with the results of this report (NASA CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 77 internal first; primes and subcontractors as identified by NASA management and stakeholders). • Offer website with report results and available reference links. 26. Establish an initiative to disseminate information on software reuse and the related Constellation policies. The technical recommendations listed in this section and elsewhere in this report are key factors to consider when writing a plan or strategy for achieving success in software reuse, operability, and compatibility. Another important factor that would contribute to success is the acceptance of the strategy by NASA’s management and software community. The software reuse benefit discussed in this report needs to be appreciated across the agency. The benefit can only be realized and maximized if software reuse is formalized at program-level, and adopted or mandated at projectlevel. To help achieve awareness, the team proposes the same approach as for Recommendation #2. 27. Ensure software reuse-related requirements are addressed and incorporated into Constellation procurements, including the CEV “Call for Improvement.” Historical data indicates that past development programs have benefited greatly in terms of cost, schedule, and risk reduction through the use of planned software reuse methodologies. Such methodologies would include commitment of high-level management, development of reuse infrastructure such as automated program libraries, and full documentation of software elements that encourage adaptation and use of the software in and out of product lines. Because of the large volume of software expected in the Constellation Program and the necessity to share this software across multiple project element boundaries, it would be highly beneficial for the developers of the software to work within a consistent software reuse environment. This environment would ensure maximum interoperability between all the entities contributing to the development of Constellation systems. Providing a contractual incentive to encourage software reuse in a consistent environment will be a prudent business practice that will enhance reuse and provide long-term benefit to Constellation as a whole. In order to make software reuse a part of the Constellation Program from its inception, it is critical to include the CEV project and to ensure that project’s compliance with the adopted recommendations of this report. The next window of opportunity to impact CEV is the upcoming Call-for-Improvement (CFI) to be released by early FY06. In this CFI, specific sections devoted to software reuse policy need to be included. For instance, it is recommended that the CEV Project’s Software Management Plan and the applicable Constellation SEI standards and other products passed as requirements to the CEV project, should include provisions based on an explicit Software Reuse Plan. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 78 All additional Constellation proposal solicitation should require the responder to identify the software that will be considered for reuse on the project. Proposals should include a section on the applicable software, if any, that will be made available for reuse in the proposed “Software Reuse Catalog”. Thus all software acquisition and development activities must explicitly be required to consider the reuse on overall project and future payoff. 28. Construct an incentive program that will promote and reward effective reuse by Constellation products and prime contractors. Further study is recommended. 29. Ensure NASA and the Constellation Program have addressed the legal issues related to software reuse. Further study is recommended. 30. Establish a “Software Reuse Tiger Team” to identify high leverage reuse opportunities. The establishment of a software tiger team with responsibility for the identifying early high-leverage reuse opportunities for Constellation, with initial emphasis on CEV, Launch and Mission Systems (LMS) and Exploration Communications and Navigation Systems (ECANS) projects. 31. Require and create plans for software reuse, at each Constellation level, that address the key technical and non-technical factors for successful reuse while at the same time insisting on sound business practices in assessing opportunities and effectiveness of reuse at each level. Further study is recommended. 32. Monitor the effectiveness of Software Reuse Plans across the project lifecycle. Further study is recommended. 33. Undertake periodic, thorough cost estimation, monitoring and assessing reusable software engineering assets. This could be included in a “software product line” strategy. The application of sound business practices in assessing opportunities and the effectiveness of software reuse will be paramount in determining the actual benefits realized by NASA, also in the monitoring and adjustment (if needed) of contractual business incentives. 34. Develop and specify Constellation engineering and management processes that promote reuse, support the business case, and make software reuse the readily adoptable, preferred approach. This will require the creation of policies and plans that promote reuse, create compelling incentives, and reward effective reuse by projects and prime contractors. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 79 The introduction of a reuse infrastructure within an existing organization and the associated modification of employee behavior and processes is a complex interdisciplinary task. Additionally, the Constellation Program has its own specific characteristics that need to be understood in order for the technology infusion to be successful. A number of examples in the literature are showing that unless a real effort is put into the insertion activities, low adoption and minimal success can be expected. For instance, a reuse technology insertion approach requires motivation of all involved, namely the professionals who have to change their practices, and the management who control the resources. Constellation should undertake a study to identify the key success criteria for software reuse technology infusion during the early phases of the project and Constellation-specific actions to meet those success criteria. 35. Develop a “Reuse Maturity Model” for organization elements (NASA and nonNASA) and require continuous improvement. In order to assess the reuse maturity level of the Constellation Program, the team recommends adopting a Reuse Maturity Model. Reuse Maturity is defined as the extent to which a company’s reuse practices are defined, managed, measured, controlled, and are generally effective. There are various reuse maturity models proposed in the literature. These models consist of a set of key areas that capture different aspects of the introduction and improvement of a company’s reuse maturity. Constellation should develop a model to encourage and evaluate continuous improvement in organization, workgroup, and individual readiness and practices. Effective reuse will require change in organizational, workgroup, and individual behavior. • Use this model for assessment of Constellation organizations and their capability for capturing the benefits of reuse for Constellation. • Require continuous improvement in Reuse Maturity. 8.02 Technical Recommendations 1. Establish a policy and develop the technical requirements for “Design for Reuse.” A “Design for Reuse” policy provides a conceptual framework for the design of reusable components. Details should embody the best practices described in this study report and include those technical processes, procedures, standards, etc. that mitigate specific risks of reuse. A follow-on study should focus on producing the set of guidelines for “design-for-reuse” that will define the key principles to be followed by the Constellation Program. The next level of details would address specific concepts such as component structures, interfaces, parameterization, and composition. This follow-on study would also allow the project to analyze and select alternatives at the next level of detail. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 80 2. Constellation Software Management Plans should explicitly address the software reuse strategy. The Constellation Program Software Management Plan should include a complete and thorough strategy and requirements regarding software reuse, interoperability, and compatibility. The strategy will vary depending on the different level of software criticality, as defined in Appendix B of NPR 7150.2. Human Rated Flight Software is classified as the highest criticality level software class and General Purpose Desktop Software is classified as the lowest criticality level software class. The software reuse strategy must clearly place requirements on how each software class should be handled in terms of adaptation, application, documentation, and verification and validation. Class G S/W—General Purpose Computing Software and class H S/W— General Purpose Desktop Software probably do not engender any formal requirements for reuse strategy, except in specific cases where they are used to develop higher level-of-criticality software class. The software reuse strategy also needs to address requirements on how to treat other software types, such as contracted software, off-the-shelf software (COTS, GOTS), or glueware, in terms of adaptation, application, documentation, verification and validation, and legal implication. 3. Implement changes to the technical plan to reach readiness for the Systems Requirements Review. Several specific reused-related activities should be incorporated immediately into the near-term activities of Constellation SEI. • During Requirement Analysis Cycle 1 (RAC1) The Software Requirements Document (SRD) should be modified to include software reuse. The changes to the Constellation Responsible Assignment Matrix (CRAM) specified in Section 9.0, including those to the Software Management Plan, should be implemented. As part of the RAC1 integration review activities, the project should review the status of progress in the adoption of a reuse plan. • During Requirement Analysis Cycle 2 (RAC2) The project needs to refine and update the Systems Requirements Review (SRR), and review the status of progress in the adoption of a reuse plan as part of RAC2 integration review. – Establish a software tiger team with responsibility for identifying of early highleverage reuse opportunities for Constellation, with initial emphasis on CEV, Launch and Mission Systems (LMS) and Exploration Communications and Navigation Systems (ECANS) projects. – Develop a software cost model parameterized to Constellation that will be used to determine the most highly leveraged and minimally risky investments in software reuse. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 81 4. Develop and maintain a Software System Architecture at the Constellation Program Systems Engineering level based on “software product lines.” The objective is to identify specific [or] specify architecture and design patterns to be reused by the Constellation Program. A common architecture enables the creation of product platforms (product lines): sets of similar products that are developed rapidly from a common starting point. It defines rules for developing reusable components by defining interface, control, and data format standards, and it speeds development by defining design patterns and application frameworks. One very effective form of software reuse is the reuse of software architectures. A follow-on study focused on establishing an architectural style, assessing the most relevant domain-specific design patterns and application frameworks, defining the control and data format standards, and middleware specifications would allow the Constellation Program to start reaping the benefits of reuse early in the lifecycle. 5. Develop software engineering technical requirements for creation of reusable artifacts. Require a modular, model-based engineering and component-based development (CBD) approach, use of design patterns, and application frameworks. Additional details should be developed in a follow-on systems engineering activity. 6. Specify standards, requirements, and guidelines for middleware or platform independent constructs to isolate software components from hardware peculiarities. This recommendation provides strong technical support to realize the benefits of reuse and mitigate numerous risks. Independent of the topic of software reuse, it is also a recommendation based on software systems engineering state-of-the-practice. 7. Adopt engineering policies, processes, and procedures that promote effective reuse across Constellation elements. The processes for effective software engineering and software systems engineering share a great deal with those for systems engineering. These two “families” of systems engineering should be brought into closer alignment. • Criterion for software design, review, and evaluation must be modified to infuse the practices that lead to development of reusable software. • The system engineering process that identifies the software requirements also must be modified to take into account reusable artifacts. The software reuse process is an important step of the software systems engineering lifecycle and should be formalized and made a requirement. • Use architectural and design definitions based on approved higher-level requirements in the selection of reusable products. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 82 8. Develop metrics for software reusability. A Constellation Software Reuse Plan will need to prove its effectiveness through the use of specific metrics. A follow-on study should be performed to define the detail measurements to put in place from the inception of the reuse program. Based on the wealth of published research in this area, this study should identify those metrics that are relevant and well targeted for the Constellation Program. Constellation should develop measurements, metrics, and decision process with focus on rapid deployment in current Constellation activities. Examples of topic areas worthy of follow-on study for the development of software reuse metrics are: • Reuse by organization (people) not involved in development • Granularity of reuse—software vs. only software artifacts • Changes required to reusable software or application software • Portability to new platforms • Plan for technology insertion • Increase in productivity measured in terms of cost savings & schedule gain • Reduction in repair time, reduction in customer complaints • Lifecycle cost of acquiring reusable software • Technical, liaison, and maintenance support for reusable software • Ease of availability/visibility through catalogs • Usage by multiple users/organizations • Ease of incorporation into different architectural environments • Level of dependency on operating system • Use of good programming practices during development such as modularity, cohesion, etc. 9. Manage (re)use of non-developmental items. The use of reusable components, commercial off-the-shelf (COTS), government offthe-shelf (GOTS), modified off-the-shelf (MOTS), legacy software, or any other nondevelopmental items (NDI) should be treated as a risk and managed through risk management processes. The reuse of COTS, GOTS, and any other NDI requires the definition of precise acceptance criteria based on a number of parameters such as the target software criticality, the required certification process, the potential benefits of obtaining it. The follow-on study should allow the Constellation Program to categorize the NDI, to refine the acceptance criteria, elaborate risks, and identify potential mitigation strategies. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 83 Application of reuse components, COTS, GOTS, or any other NDI should be made only after successful completion of an NDI acceptance inspection. This inspection needs to consider a standard list of reuse criteria. These will include the process used to develop it, how it was documented, the number of users, user experience, and compliance with essential program technical and non-technical considerations. Before a decision is made to reuse a product or to acquire COTS, GOTS, or NDI, a complete cost trade-off should be made considering the full lifecycle costs, update requirements, maintenance costs, warranty and licensing costs, and any other considerations that impact use of the product throughout its lifecycle. All reuse products, COTS-, GOTS-, or NDI-decisions should ensure compliance with Constellation architectural and design definitions. The selection of all reuse items must be traceable back to an approved user requirement. All reuse components, COTS, and GOTS need to be tested individually, first against program requirements, and then in an integrated software and system configuration prior to release for testing according to the program test plan. Reuse COTS-, GOTS-, and NDI-decisions should be continuously revisited as program conditions change. 10. Establish a “software product line” component library. The major purpose of this recommendation is to make reusable artifacts readily available to Constellation development across institutional and organizational boundaries. Recommendations related to the establishment of a Software Product Line Component Library are as follows: • The reusable components in the Library must be under strict configuration management. • To speed adoption and remove some of the costs of reuse from the user, the metadata associated with each component should be complete and the component itself should be “certified” (guaranteed to meet a set of pre-determined criteria). • A software taxonomy should be developed that will allow better definition and classification of metadata for software for easy deposition and search from the Reusable Software library. • Operations of the library should include promotion of reuse across all organizations participating in software development activities, inspection and audit responsibilities, and maintenance of software reuse policies and plans at the Constellation SEI level. • The library should provide some level of support for COTS, GOTS, MOTS, legacy, and open-source. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 84 • The library should identify Constellation software artifacts, developed and available throughout the project lifecycle at a given level of maturity. • A valuable extension of the library functions could include verification and validation of standard libraries widely used in software engineering (e.g., MatLab, WindRiver products). 11. Provide tools and techniques to development groups that promote and enable reuse. For the reuse process to be successful, the availability of tools to enable the rapid identification, adaptation, and deployment of reusable software assets can be a critical factor. Constellation should identify specific tools that will enable the most effective use of Constellation software assets and the relationship of these tools to the proposed “Software Product Line Asset Repository.” “Tools” are broadly defined as instruments that facilitate the reuse of products or byproducts during the software lifecycle, including reuse libraries, application templates and generators, common testbed environments, etc. Tool categories include Analysis and Design, Asset Constructors, Asset Testers, Reuse Management. A reuse-based software development model (a.k.a. “Software Product Line”) follows the assembly-line analogy. It is built around a reuse infrastructure. A follow-on study of the infrastructure to put in place for the specific characteristics of Constellation would allow the program to identify early how to build an appropriate infrastructure. The objective would be to develop expanded Constellation-specific detail for the infrastructure recommendations identified in this report. Domain engineering has been noted earlier herein as a necessary component of an effective software product-line approach. This type of systems engineering has its impact on software systems engineering via a well-defined process and vocabulary. This can be embodied in a “domain specific language” (DSL). The basic idea of a DSL is a computable language that is targeted to a particular kind of problem, rather than a general purpose language that is aimed at any kind of software problem. This relatively new field of research could be of high interest to Constellation in the systematic representation and software systems implementation of domain engineering requirements. Some DSL tools are starting to appear and could be leveraged for the Constellation Program. A follow-on study on this topic could make a recommendation to Constellation on the best method for using DSL to address the domain engineering process requirements. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 85 9.0NEXT STEPS—IMPACT ON REQUIREMENTS Software has played a major role in most parts of space flight programs at NASA. The adoption of the “Software Strategy for Reuse,” as recommend in this study, will change a large part of the Constellation Program’s software requirements and development. These changes will impact across the software system lifecycle—from planning, requirements, development, and testing, to sustaining. The degree of impact will vary depending on whether or not the software is destined for reuse or the software itself is being reused. The degree of impact also depends on the criticality level of the software (see NASA Procedural Requirements NPR 7150.2). This section will identify ESMD requirements and Constellation Responsible Assignment Matrix (CRAM) products that will be impacted by the strategy for software reuse. An approach to extend communication of the software reuse strategy to the NASA software community is needed. This section will also discuss how the result of this study will affect the Call-ForImprovement for CEV. The road to SRR will be addressed. In addition to those new studies identified earlier in Section 8.0 Recommendations, this section will suggest follow-on studies specifically related to steps identified here. 9.01 Traceability to Requirements The design and development of the EDMS flight software requirements, as listed below, will be affected by the software reuse strategy. These requirements include monitoring, command and control, automations, and system health management. Whether or not these requirements will be included in further revisions of the requirement documents, they will be superseded by future revisions that incorporate any change required as a result of the ESAS (60 days) study. Design solutions for the requirements identified in this section, are governed by high level requirements, guidelines, and standards, as defined in NPR 7150.2—NASA Procedural requirements, NASA NPR 8750.2—Human Rating Requirements and Guidelines for Space Flight Systems, NPR 8715.3—NASA Safety Manual, and NASA-std 8719.13—Software Safety Standard, for all safety-critical software. The “Reuse Strategy” recommended in this report must also be in compliance with these NASA requirements. The following requirements are from the NASA Exploration Crew Transportation System Requirements Document (ESMD-RQ-001, Rev E, 30 Mar 2005). The document’s section headings are shown in gray to indicate the context; when no headings are shown, the prior heading applies. 3 System Requirements 3.3 Performance Requirements CTS0050H The CTS shall provide the capability to monitor, command, and control, its system segments and elements. CTS0075H The CTS shall provide automated control linked to the mission phase and function, with an objective of automated operations throughout the mission. CTS0300H The CTS shall provide autonomous operations linked to the mission phase and function with an objective of autonomous operations throughout the mission. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 86 CTS0320H The CTS shall provide manual intervention of automated functions critical to mission success and crew safety. 3.3.5 Software CTS0270H The CTS shall comply with NPR 7150, NASA Software Engineering Requirements. 3.4 Safety 3.4.3 Vehicle Health CTS0190H The CTS shall automatically detect and annunciate conditions which could result in loss of human life, loss of vehicle, loss of mission, or significantly impact mission capability. CTS0200H The CTS shall provide autonomous fault detection, isolation and recovery, with an objective of automated isolation and recovery, from conditions which could result in loss of human life or loss of vehicle. CTS0230H The CTS shall provide isolation and recovery from conditions which could result in loss of mission or significantly impact mission capability. CTS0045H The CTS shall capture, archive, and make retrievable, mission and safety critical performance data. 3.7 Subordinate Elements 3.7.2 Crew Exploration Vehicle (CEV) 3.7.2.3 Performance Characteristics 3.7.2.3.5 Software CEV0170H The CEV shall comply with NPR 7150, NASA Software Engineering Requirements. 3.7.2.4 Safety 3.7.2.4.1 General CEV0180H The CEV shall comply with NASA NPR 8750.2, Human Rating Requirements and Guidelines for Space Flight Systems CEV0190H The CEV shall comply with NPR 8715.3 NASA Safety Manual. CEV0200H The CEV shall comply with NASA-std 8719.13, Software Safety Standard, for all Safety-Critical Software. 3.7.2.4.3 Vehicle Health CEV0240H The CEV shall provide autonomous isolation and recovery, with an objective of automated fault isolation and recovery, from conditions which could result in loss of human life or loss of vehicle. CEV0290H The CEV shall provide isolation and recovery from conditions which could result in loss of mission or significantly impact mission capability. CEV0047H The CEV shall capture, archive, and make available for retrieval, mission and safety critical performance data. The following requirements are from the NASA Exploration System of Systems Programmatic Requirements and Guidelines Document (ESMD-RQ-0021, Rev E, 24 Mar 2005). The CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 87 document’s section headings are shown in gray to indicate the context; when no headings are shown, the prior heading applies. 3 System Requirements 3.1 Exploration Programmatic Requirements EPR0670 The program will establish "Design for Minimum Risk" criteria for components/ systems which do not meet the applicable failure tolerance requirements through the use of the following process: (process not quoted here) EPR0560 The responsible program will develop interface standards at the Exploration System of Systems level. EPR0500 The responsible program will develop a Human Rating Plan to address compliance with NASA 8705.2 Human Rating Requirements and Guidelines for Space Flight Systems. This is parent of CEV0180H. 3.2 Exploration Programmatic Guideline EPG0810 The responsible program should simplify and minimize the number of interfaces between systems, segments, and elements, and between organizations where such simplification will increase reliability, reduce risk, and minimize lifecycle costs. Software reuse should provide opportunities to simplify and minimize interfaces. EPG0820 The responsible program should use common subsystems, interfaces, and software across the Exploration System of Systems where such commonality will reduce risk and minimize cost. One of the major principles driving software reuse is the reduction of risk and cost. EPG0840 The responsible program should, to the maximum extent practical, design the Exploration System of Systems to allow for the use of commercially provided items and services. Third party software and commercially available computing systems fall under this requirement. The following requirements are from the NASA Exploration System of Systems Technical Requirements Document (ESMD-RQ-0010, Rev E, 30 Mar 2005). The document’s section headings are shown in gray to indicate the context; when no headings are shown, the prior heading applies. 3 System Requirements 3.5 NASA Procedural Requirements ESS0350 Manual. The Exploration System of Systems shall comply with NPR 8715.3, NASA Safety This is the parent of CEV0190H. ESS0370 The Exploration System of Systems shall comply with NPR 7150, NASA Software Engineering Requirements. This is the parent of CTS0270H and CEV0170H. ESS0360 The Exploration System of Systems shall comply with NASA-STD-8719.13, Software Safety Standard for all Safety-Critical Software. This is the parent of CEV0200H. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report 9.02 Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 88 Impact on SEI Constellation Responsible Assignment Matrix (CRAM) products 9.02.1 Software Management Plan (SMP)—DSM&A The Software Management Plan should include a complete and thorough discussion of strategy and requirements regarding software reuse, interoperability, and compatibility. The strategy will vary depending on the different level of software criticality, as defined in Appendix B of NPR 7150.2. Human Rated Flight Software is classified as the highest criticality level software class and General Purpose Desktop Software is classified as the lowest criticality level software class. The software reuse strategy must clearly place requirements on how each software class should be handled in term of adaptation, application, documentation, and verification and validation. Class G S/W—General Purpose Computing Software and Class H S/W—General Purpose Desktop Software probably do not engender any formal requirements for reuse strategy; except in specific cases where they are used to develop higher level of criticality software class. The software reuse strategy also needs to have requirements on how to treat other S/W types, such as Contracted Software, Off-The-Shelf (COTS, GOTS), or Glueware, in term of adaptation, application, documentation, verification & validation, and legal implication. 9.02.2 Other Constellation Program Systems Engineering Products Table 9-1 identifies the Constellation Program systems engineering products, in addition to the Software Management Plan, that will also be impacted by a software reuse strategy. Products are identified by their number as designated in the Constellation Responsibility Allocation Matrix (CRAM). Table 9-1. Reuse Impact on Program Systems Engineering Products IPT T&V T&V Product Number Product Title Product Description Milestone C0254P Master Validation, The purpose of the CR Integration, and Constellation MVI&V Plan Verification Plan is to document the approach, philosophy, requirements, guidelines, processes, and best practices associated with the validation, integration, verification and certification of the elements that comprise the System. CxxxxP Test & Verification This document will detail Strategy top-level strategies and philosophies for testing and verification. Strategy will be developed utilizing data, products, and other input provided by virtually all other IPTs. Impact Should include plan to T&V reused components. Should include strategy to T&V reused software component. (continued) CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 89 Table 9-1. Reuse R Impact act on Progr Program Systems ms Engineering Engineerin ng Products—Continued Products— IPT T&V Product Number Product Title CxxxxP Constellation Systems Verification Plans and Matrix DSM&A C0042A DSM&A C0162A DSM&A CxxxxA RD&FA C0155P Product Description Milestone Impact Outline of verification Should include activities from an verification activity for integrated system level. reused software Document will detail component, and a individual tests to be detail test plan to performed, test objectives, perform on reused test configurations, ICDs, software component requirements, and specifications needed, HW and SW products involved. Command, See DR SDR Design and Control, Development will be Communications, impacted by software Computers, and reuse, interoperability, Intelligence and compatibility Support Plan strategy. Software Requirements (where SRR Software reuse policy Development applicable) for software and processes will be Guidelines/ development processes, key factors of the Standards. coding standards, data software development dictionaries, delivery guidelines. media, support role. ISHM Integrated Systems Health Design and Management development will be impacted by software reuse, interoperability, and compatibility strategy System Requirements must Requirements reflect software reuse, Documents interoperability, and compatibility. Test & Verification (T&V) products will have significant impact. The T&V strategy will need to include a process to test and verify software systems with reuse components. The process of testing and verification of software that is built to be reused will also need to be part of the T&V strategy. The process of T&V of a software system is assumed to be shortened or simplified if the software system employs a software component from an equal or higher software class. In the opposite case, when a higher software class reuses a component from a lower software class, the T&V process needs to be as stringent as if the component is built from scratch. Integration testing will always be performed regardless of whether reusable software components have been employed. The Design Synthesis Manufacturing & Assembly (DSM&A) products related to software (e.g., Software Development Guideline/Standard or Command, Control, Communications, Computers, and Intelligence Support Plan) will also have an impact. Software development guidelines must include steps to guide software system development in order to leverage on software reuse, as well as to generate reusable components to share across other Constellation programs. To comply CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 90 with the software development guideline, standard, or SMP, software systems like Integrated System Health Management (ISHM) or Command and Control software must consider the software reuse strategy in the design and implementation phases. As discussed in Section 9.1—Traceability to Requirements, the System Requirements Document in the Requirement Definition & Functional Allocation (RD&FA) IPT will also be affected by software reuse strategy. The software requirements should reflect the result of this study. The software lifecycle needs to address software reuse, especially in the planning phase. 9.03 Follow-On Studies A number of follow-on studies should be considered for the short term in order to improve the chance of this study to positively impact the Constellation Program from the beginning. Brief descriptions of the proposed studies are provided below: 36. Develop a Software Product Line Strategy The product line concept as an integrating theme for the Constellation Reuse Strategy has not been fully developed in this report. A study aimed at understanding and developing the software product line as the backbone for the Constellation Reuse Strategy is needed. This study should include a review of the software architecture to identify potential product lines and select candidates for initial programmatic investment. 37. Domain Specific Language Domain engineering has been noted earlier in this report as a necessary component of an effective software product line approach. This type of systems engineering has its impact on software systems engineering via a well-defined process and vocabulary. This can be embodied in a “Domain Specific Language” (DSL). The basic idea of a DSL is a computable language that is targeted to a particular kind of problem, rather than a general purpose language that's aimed at any kind of software problem. This relatively new field of research could be of high interest to Constellation in the systematic representation and software systems implementation of domain engineering requirements. Some Domain Specific Language tools are starting to appear and could be leveraged for the Constellation program. Objective: A follow on study on this topic could make a recommendation to the Constellation on the best method for using DSL to address the domain engineering process requirements. 38. Tools for Constellation Software Asset Reuse For the reuse process to be successful, the availability of tools to enable the rapid identification, adaptation and deployment of reusable software assets can be a critical factor. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 91 Objective: Identify specific tools that will enable the most effective use of Constellation software assets and the relationship of these tools to the proposed “Software Product Line Asset Repository.” 39. Design for Reuse Technical Requirements A follow on study focused on producing the potential set of guidelines for “designfor-reuse” will define the key principles to be followed by the Constellation Program. The next level of details would address specific concepts such as component structures, interfaces, parameterization and composition. This will also allow the project to analyze and select alternatives at next level of detail. Objective: Provide a conceptual framework for the design of reusable components. 40. Software Systems Architecture One very effective form of software reuse is the reuse of software architectures. A follow on study focused on establishing an architectural style, assessing the most relevant domain specific design patterns and application frameworks, defining the control and data format standards and middle-ware specification would allow the Constellation Program to start reaping the benefits of reuse early on in the lifecycle. Objective: Identify specific architecture and design patterns to be reused by the Constellation Program. 41. Reuse of Non-Developmental Items The reuse of COTS, GOTS and any other non-developmental items (NDI) requires the definition of precise acceptance criteria based on a number of parameters such as the target software criticality, the required certification process, the potential benefits to obtain. The follow on study should allow the Constellation program to categorize the NDI, to refine the acceptance criteria, to elaborate risks and identify potential mitigation strategies. Objective: Initiate the decision process related to the reuse of NDI. 42. Software Product Lifecycle Reuse Metrics Constellation Program reuse plan will need to prove its effectiveness through the use of specific metrics. A follow on study should be performed to define the detail measurements to put in place from the inception of the reuse program. Based on the wealth of published research results in this area, this study should identify those metrics that are relevant and well targeted for the Constellation program. Objective: Develop measurements, metrics, and decision process with focus on rapid deployment in current Constellation activities. 43. Reuse Maturity Model CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 92 In order to assess the reuse maturity level of the Constellation Program, we assess and adopt a Reuse Maturity Model. Reuse Maturity is defined as “the extent to which a company’s reuse practices are defined, managed, measured, controlled and generally effective.” There are various reuse maturity models proposed in the literature. These models consist of a set of key areas that capture different aspects of the introduction and improvement of a company’s reuse maturity. This study will select the appropriate model for the Constellation program. Objective: Develop a model to encourage and evaluate continuous improvement in organization, workgroup and individual readiness and practices. 44. System Level Reuse Because of the nature of the Constellation Program, system level reuse appears to have high potential benefits. The follow on study should be aimed at reviewing the software architecture to identify potential system reuse candidates and their need for early programmatic investment and attention. This is the first step in establishing a system level product line. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 93 10.0ACKNOWLEDGEMENTS This effort and the study described in this report was lead and performed in part by the Jet Propulsion Laboratory, California Institute of Technology under contract with the National Aeronautics and Space Administration. Contributing NASA Centers: Ames Research Center Goddard Space Flight Center Jet Propulsion Laboratory Johnson Space Center Kennedy Flight Center Marshall Space Flight Center Document preparation and editorial support was provided by members of the JPL Documentation Services Group. A complete list of study participants and contact information can be found in Appendix C. Note from the Study Lead (David Atkinson): I especially wish to acknowledge the editorial as well as technical contributions of Mark James, Kirk Reinholtz, Charlie Beswick and Harry Woo. Mark James’ leadership was especially important in managing the final editing and publication of this document. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 94 Appendix A: Glossary, Acronyms, and Abbreviations A.1 Glossary Application product lines: An application type generalized around a common architecture so that it can be adapted in different ways for different customers. Architecture: The software architecture of a program or computing system. The structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. An architecture largely permits or precludes a system’s quality attributes such as performance or reliability. Architecture represents a capitalized investment, an abstract reusable model that can be transferred from one system to the next. Aspect-oriented software development: Shared components woven into an application at different places when the program is compiled. Component-based development systems: Developed by integrating components (collections of objects) that conform to component-model standards. Configurable vertical application: A generic system designed so it can be configured to the needs of specific system customers. COTS software: Operating systems, libraries, applications, and other software purchased from a commercial vendor. Not customized for a particular project. Access to source code and documentation are often limited. COTS integration: Systems developed by integrating existing application systems. Design patterns: Generic abstractions that occur across applications, represented as design patterns that show abstract and concrete objects and interactions. Derivative reuse: Domain Specific Software Architecture: An architecture designed to solve a set of problems within a specific domain (area of related problems). A DSSA is an example of a generic architecture. A DSSA is a software architecture based on the actual and projected commonalities and differences of applications in a domain. It is a reusable design component providing the basis for other reusable design and code components. Legacy system wrapping: Legacy systems that can be “wrapped” by defining a set of interfaces and providing access to these legacy systems through these interfaces. Leveraged reuse: Reuse with modifications. Locked reuse: Reusable content that cannot be changed except by the original author. Locked reuse is used when to ensure that content is not changed. Middleware: Software that resides between applications and the underlying operating systems, network protocol stacks, and hardware. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 95 Opportunistic reuse: Refers to when the author makes a conscious decision to find an element, retrieve it, and reuse it. Opportunistic reuse requires that the author be aware of the opportunities for reuse and be motivated to search for and retrieve reusable content. Opportunistic reuse is the most common form of reuse. Opportunistic reuse does not rely on specific technology; it can be done without a content management system, although a CMS is advisable. Program generators: A generator system that embeds knowledge of a particular types of application and can generate systems or system fragments in that domain. Program libraries class and function libraries: Implementing commonly used abstractions are available for reuse. Reusable software: Software that is implemented in such a way as to facilitate reuse, as opposed to software that could be reapplied but which was not implemented with reuse in mind. Reusable software is actually an extension of the concept of maintainability, where maintainability implies that the software will be able to evolve with the problem, and reusability implies that the software will also be applicable to other related problems. Reuse methods: There are two methods for reuse: opportunistic reuse (an author makes a conscious decision to reuse content) and systematic reuse (planned reuse where content is automatically inserted). Within each method of reuse are three options: locked reuse (reused content cannot be changed), derivative reuse (reused content can be changed), and nested reuse (multiple versions of the content are contained within the same element). SBA Support Office: Office that is chartered with ensuring that the infrastructure of tools, policies, and organizational working groups required to realize simulation-based acquisition (SBA) are built, maintained, and improved as necessary. Service-oriented systems: Systems developed by linking shared services that may be externally provided. Simulation-based acquisition: Refers to supporting program decisions with accurate and timely data. Software Product Line: “A SPL is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.” [Reference: http://www.sei.cmu.edu/] Software reuse: A software product developed for one use but having other uses or one developed specifically to be usable on multiple projects or in multiple roles on one project. Examples include, but are not limited to, COTS products, acquirer-furnished software products, software products in reuse libraries, and pre-existing developer software products. Each use may include all or part of the software product and may involve its modification. This term can be applied to any software product (such as requirements and architectures), not just to software code itself. Often this applies to software previously written by an in-house development team and CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 96 used on a different project. GOTS software would come under this category if it is supplied from one government project to another government project. [Reference: NASA-GB-8719.13, NASA Software Safety Guidebook] Software reuse: The application of software to a problem other than the specific original problem the software was implemented to solve. Systematic reuse: Planned reuse. Specific content is identified as reusable in a specific location. Then the content management system automatically inserts (auto-populates) the reusable content in the appropriate locations in the document. The author does not have to determine whether the reusable content exists or search for and retrieve it. Systematic reuse ensures that content is reused and reduces the burden on the author of knowing that reusable content exists, of finding the reusable content, and of inserting it appropriately. Verbatim reuse: Reuse without modifications. A.2 Acronyms and Abbreviations 3DOF ACE AFM AMMOS ANSI API AR&D AT & T C&DH C2I CASE tools CCC CEV CFI CLCS CM CMMI COCOMO COREM COTS CPU Three degrees of freedom An expert in a specialized area. Aerosciences and Flight Mechanics The Advanced Multi-Mission Operations System American National Standards Institute Application programming interfaces Automated Rendezvous and Docking American Telephone and Telegraph Company Command and data handling Command and Control Interoperability Study Computer-Aided Systems Engineering tools Command Control and Communications Crew Exploration Vehicle Call-for-Improvement Checkout and Launch Control System Configuration management Capability Maturity Model Integration Constructive Cost Model Capsule oriented reverse engineering for software reuse Commercial-Off-The-Shelf Central processing unit CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report CRAM CRIS CSA DEROS DoD DOPS/LANDOPTS DSM&A DSSA ECANS EDSAC ESD ESE FADS FDD FOM GDS GLS GN&C GOTS GSE GSFC HMF HQ IDT ISHM ISS IT ITAR JASON JSC KBEmacs KLOC LMS LOC MFC Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 97 Constellation Responsible Assignment Matrix Customer resource information systems Computers, Software and Automation Design Environment for Reusable Object-oriented Software US Department of Defense Desirable Objectives and Practices/ Design Synthesis Manufacturing & Assembly Domain-specific software architecture Exploration Communications and Navigation Systems Electronic Delay Storage Automatic Computer Electronic Services Delivery Earth Science Enterprise Flight Analysis and Design System [Shuttle] Flight Design and Dynamics Figures of merit Ground data system Ground Launch Sequencer Guidance, navigation and control Government Off-The-Shelf Ground Support Equipment Goddard Space Flight Center Hypergolic Maintenance Facility Headquarters Integrated Discipline Team Integrated Systems Health Management Study International Space Station Information Technology International Traffic in Arms Regulations Successor to TOPEX Johnson Space Center Knowledge-Based Editor in Emacs Thousand lines of code Launch and Mission Systems Lines of code Mated Flight Control Operations CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report MLSOC MOC MPS NASA NATO NC NDI OMS OMT OO OOSE OPF OS PAC ROI ROSE RSL RSL S/W SBA SDA SDLC SEEDS SEI SLOC SMP SPL SRR SRR STAR STL T&V TCM TOPEX TOTM Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 98 Million lines of source code Mission Operation Computer Main Propulsion System National Aeronautics and Space Administration North Atlantic Treaty Organisation Normally Closed Non-developmental items Orbital Maneuvering System Object Modeling Technique Object oriented Object Oriented Software Engineering Orbiter Processing Facility Operating system Presentation, Abstraction and Control Return on investment Reusable Object Software Engineering Reusable Software Libraries Traditional reusable software libraries Software Simulation-Based Acquisition Software Development Assets Software Development Life Cycle Strategic Evolution of Earth Science Enterprise Data System Software Engineering Institute Source lines of code Software Management Plan Software product line System Requirements Review. System Requirements Review Software Technology Standard Template Library Test & Verification Topography Experiment Trajectory-Off-the-MOC CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report V&V XML Document No.: AC1L1-52 Effective Date: October 1, 2005 Verification and validation Extensible Markup Language Revision: 0 Page 99 CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 100 Appendix B: Bibliography “16 critical software management practices,” Software Managers Network, [Online document], 2005, [2005 Sep. 9], Available http://www.spmn.com/16CSP.html A. Abran and J. Desharnais, “Measurement of functional reuse in maintenance,” Journal of Software Maintenance: Research and Practice, vol. 7, no. 4, July–Aug., pp. 263–277, 1995. “Aerospace Industries Association Position Statement on Ada,” [Online document] July 12, 1996, [2005 Aug. 26], Available http://sw-eng.falls-church.va.us/aia_position_on_ada.html W. Agresti and W. Evanco, “Projecting software defects from analyzing Ada designs,” IEEE Trans. Software Engineering, vol. 18, no. 11, Nov., pp. 988–997, 1992. A. Albrecht, “Measuring application development productivity,” in Proc. IBM Applications Development Symposium, Oct. 1979, pp. 83–92. “Ariane 5 flight 501 failure [Online document] ND [2005 Aug. 30], Available http:// www.ima.umn.edu/~arnold/disasters/ariane5rep.html G. Asrar, “Data and knowledge system for mission to planet Earth,” Remote Sensing Reviews, vol. 13, pp. 1–25, 1995. J. Baldo, J. Moor, and D. Rine, “Software reuse standards,” Standard Views: ACM Perspectives on Standardization, vol. 5, no. 2, Jun., pp. 50–57, 1997. R. Banker, R. Kauffman, C. Wright, and D. Zweig, “Automating output size and reuse metrics in a repository-based computer aided software engineering CASE environment,” IEEE Trans. on Software Engineering, vol. 20, Mar., pp. 169–187, 1994. V. Basili and J. Musa, “The future engineering of software: a management perspective,” IEEE Computer, vol. 24, no. 9, Sep., pp. 90–96, 1991. T. Berners-Lee, R. Cailliau, J. Groff, and B. Pollermann, “World-Wide Web: the information universe,” Electronic Networking: Research, Applications and Policy, vol. 1, no. 2, Spring, pp. 74–82, 1992. T. Berners-Lee, R. Cailliau, A. Luotonen, H. Frystyk Nielen, and A. Secret, “The World-Wide Web,” Communications of the ACM, vol. 37, no. 8, Aug., pp. 76–82, 1994. B. Boehm, Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981. B. Boehm and P. Papaccio, “Understanding and controlling software costs,” IEEE Trans. Software Engineering, vol. 14, no.10, Oct., pp. 1462–1477, 1987. T. Bollinger and S. Pfleeger, “Economics of reuse: issues and alternatives,” Information and Software Technology, Dec., vol. 32, no. 10, pp. 643–652, 1990. G. Booch, Object Solutions, Managing the Object-Oriented Project, Menlo Park, CA: AddisonWesley, 1996. J. Carbonell, “Derivational Analogy: A Theory of Reconstructive Problem Solving and Expertise Acquisition,” in Machine Learning—An Artificial Intelligence Approach, Vol. II, R. Michalski, J. Carbonell, and T. Mitchell, Eds., San Francisco: Morgan Kaufmann Publishing, 1986, pp. 371–392. J. Carbonell and M. Harris, “Open systems architecture for legacy aircraft,” Open Systems Project Engineering Conference, [Online document], 1988, [2005 Aug. 30], Available http:// www.acq.osd.mil/osjtf/pdf/osala.pdf CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 101 D. Card, and E. Comer, “Why do so many reuse programs fail?” IEEE Software, vol. 11, no. 9, Sep., pp. 114–115, 1994. S. Christensen, “Software reuse initiatives at Lockheed,” Lockheed Horizons, [Online document], Dec. 1994, [29 Aug. 2005]. Available http://www.stsc.hill.af.mil/crosstalk/1995/05/ Lockheed.asp A. Clark, The Biology of Business, San Francisco, CA,: Jossey-Bass, 1999. P. Clements and L. Northrop, Software Product Lines: Practices and Patterns, Boston, MA: Addison-Wesley, 2001. R. Cruickshank and J. Gaffney, “An Economics Model of Software Reuse,” in T. Gulledge and W. Hutzler (ed.), Analytical Methods in Software Engineering Economics, Springer-Verlag, 1993. Cusumano, M., Japan’s Software Factories: A Challenge to U.S. Management, New York: Oxford University Press, 1991. DO-178B/ED-12B, “Software considerations in airborne systems and equipment certification,” RTCA, Inc., Washington, DC, Dec. 1992. C. Donaldson, “InQuisiX: An electronic catalog for software reuse,” SIGIR Forum, vol. 28, no. 1, Spring, pp. 8–12, 1994. D. Eichmann, T. McGregor, and D. Danley, “Integrating structured databases into the Web: The MORE System,” in Selected Papers of the First Conference on World-Wide Web, Amsterdam, The Netherlands: Elsevier Science Publishers, pp. 281–288, 1994. D. Fafchamps, “Organization factors and reuse,” IEEE Software, Sep., pp. 31–41, 1994. M. Fayad, W. Tsai, and M. Fulghum, “Transition to object-oriented software development,” Communications of the ACM, vol. 39, no. 2, Feb., pp. 109–121, 1996. N. Fenton and S. Pfleeger, Software Metrics: A Rigorous Approach, New York: Chapman and Hall, 1991. A. Ferrentino, SNAP: The Use of Reusable Templates to Improve Software Productivity and Quality, Herndon, VA: Template Software, Inc., 1994. R. Fichman and C. Kemerer, “Object-oriented and conventional analysis and design methodologies, comparison and critique, IEEE Computer, vol. 25, no. 10, Oct., pp. 22–39, 1992. P. Fonash, “Metrics for reusable software code components,” diss, Fairfax, VA: George Mason University, 1993. W. Frakes, “Software reuse empirical studies,” in Software Reusability, W. Schafer, R. Prieto-Diaz, and M. Matsumoto, Eds. New York: Ellis Horwood, 1994. W. B. Frakes and C. Fox, “Sixteen questions about software reuse,” Communications of the ACM, vol. 38, no. 6, Jun., pp. 75–87, 1995. W. Frakes and S. Isoda, “Success factors of systematic reuse,” IEEE Software, Sep., pp. 15–19, 1994. W. Frakes and C. Terry, “Software reuse: metrics and models,” ACM Computing Surveys, vol. 28, no. 2, June, pp. 415–435, 1996, Available http://delivery.acm.org/10.1145/240000/ 234531/ p415-frakes.pdf?key1=234531&key2=6118136211&coll=GUIDE&dl=GUIDE& CFID=52602224&CFTOKEN=73012708 W. Gibbs, “Software’s chronic crisis, Scientific American, Sep., pp. 86–95, 1994. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 102 J. Gold, “Reusabilty promise hinges on libraries,” IEEE Software, vol. 13, no. 1, Jan., pp. 86–92, 1993. M. Griss and M. Wosser, “Making Software Reuse Work at HP,” Hewlett Packard Laboratories, [Online document], 1995, [2005 Sep. 9], Available http://www.hpl.hp.com/techreports/95/ HPL-95-04.html M. Griss, “Software reuse: from library to factory,” IBM Systems Journal, vol. 32, no. 4, Oct., pp. 548–566, 1993. IEEE std 1517-1999 IEEE standard for information technology—software life cycle processes— reuse processes—description [Online document], 1999, [2005 Aug. 31], Available http:// standards.ieee.org/reading/ieee/std_public/description/se/1517-1999_desc.html R. Fichman and C. Kemerer, “Incentive compatibility and systematic software reuse,” Journal of Systems and Software, vol. 57, no. 1, Apr., pp. 45–60, 2001. Function Point Counting Practice Manual Release 4.0, Westerville, Ohio: International Function Point User Group, 1994. J. Gaffney and R. Cruickshank, “A general economics model of software reuse,” in Proc. 14th International Conference on Software Engineering, pp. 327–337, New York: ACM Press, 1992. Institute for Defense Analysis, 1991. Islam, Choudhury, “A perspective on software reuse,” [Online document], ND, [2005 Sep. 9], Available http://www.scism.sbu.ac.uk/cios/islam/Reuse_p1.htm I. Jacobson, M. Griss, and P. Jonsson, “Making the reuse business work,” IEEE Computer, vol. 30, no. 10, Oct., pp. 36–42, 1997. R. Jensen Software Technology Support Center, “An economic analysis of software reuse,” CROSSTALK: The Journal of Defense Software Engineering [Online document], Dec. 2004, [2005 Aug. 29], Available http://www.stsc.hill.af.mil/crosstalk/2004/12/0412Jensen.html C. Jones, “The economics of object-oriented software,” American Programmer, vol. 7, no. 10, Oct., pp. 28–35, 1994. R. Joos, “Software reuse at Motorola,” IEEE Software, Sep., pp. 42–47, 1994. P. Kalagiakos, “The non-technical factors of reusability,” in Proc. 29th Euromicro Conference, p. 124, 2003. C. Kemerer, “An empirical validation of software cost estimation models,” Communications of the ACM, vol. 30, no. 5, pp. 416–429, 1987. D. Kiely, “Are components the future of software?” IEEE Computer, vol. 31, no. 2, Feb., pp. 1011, 1998. D. Lamb, Software Engineering: Planning for Change, Upper Saddle River, NJ: Prentice-Hall, 1988. B. Lampson, “How software components grew up and conquered the world,” [Online document], May 21, 1999, [cited 2005 Aug 30], Available http://research.microsoft.com/Lampson/ Slides/ ReusableComponentsAbstract.htm R. Leach, Software Reuse: Methods, Models and Costs, New York: McGraw-Hill, 1997. M. Lenz, H. Schmid, and P. Wolf, “Software reuse through building blocks,” IEEE Software, vol. 4, no. 4, Jul., pp. 34–42, 1987. N. Leveson, “The role of software in spacecraft accidents,” AIAA Journal of Spacecraft and Rockets, vol. 41, no. 4, July 2004. http://sunnyday.mit.edu/papers/jsr.pdf CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 103 N. Leveson and K. Weiss, “Making embedded software reuse practical and safe,” ACM SigSoft 2004/FSE-12, [Online document], 2004, [2005 Aug. 30], Available http://sunnyday.mit.edu/ papers/fse04.pdf W. Lim, “Effects of reuse on quality, productivity, and economics, IEEE Software, vol. 11, no. 5, Sep., pp. 23–30, 1994. W. Lim, Managing Software Reuse, Upper Saddle River, NJ: Prentice Hall, 1998. Y. Maarek, D. Berry, and G. Kaiser, “An information retrieval approach for automatically constructing software libraries,” IEEE Trans. Software Engineering, vol. 17, no. 8, Aug., pp. 800–813, 1991. M. Matsumoto, “Research to shed light on software shadows,” IEEE Software, vol. 12, no. 5, pp. 16, 1995. C. McClure, The Three Rs of Software Engineering: Reengineering - Repository - and Reusability, Englewood Cliffs, NJ: Prentice-Hall, 1992. M. D. McIlroy, “Mass-produced software components,” Proc. NATO Software Engineering Conference, pp. 138–155, 1968. A. Meyer, “Software reuse: why you need a well managed repository,” Flashline Technology, [Online document] Feb. 2002 [2005 Aug. 30], Available http://www.flashline.com/Content/ Meyer/impact_analysis.jsp?&sid=1125442154273-2303618884-101 M. Morisio, M. Ezran, and C. Tully, “Success and failure factors in reuse,” IEEE Trans. Software Engineering, vol. 28, no. 4, pp. 340–357, 2002, Available http://csdl2.computer.org/ persagen/ DLAbsToc.jsp?resourcePath=/dl/trans/ts/&toc=comp/trans/ts/2002/04/ e4toc.xml&DOI=10.1109/TSE.2002.995420 E. Morris, L. Levine, C. Meyers, P. Place, and D. Plakosh, “System of Systems Interoperability (SOSI): final report,” Pittsburgh, PA: Carnegie Mellon University, CMU/SEI-2004-TR-004, April 2004. N. Nada, “Software reuse-oriented functional framework,” diss, Fairfax, VA: George Mason University, 1997. K. Obraczka, P. Danzig, and S.-H. Li, “Internet Discovery Services,” IEEE Computer, vol. 25, no. 5, Sep., pp. 8–22, 1993. J. O’Connor, C. Mansour, J. Turner-Harris, and G. Campbell, Jr., “Reuse in command-and-control systems,” IEEE Software, vol. 11, no. 5, Sep., pp. 70–79, 1994. D. Parnas, “On the design and development of program families,” IEEE Trans. Software Engineering, vol. 2, no. 1, Mar., pp. 1–9, 1976. F. Patterson, “Reengineerability: metrics for software reengineering for reuse,” diss, Fairfax, VA: George Mason University, 1995. S. Pfleeger, Software Engineering, The Production of Quality Software, Indianapolis, IN, Macmillan Publishing, 1987. S. Pfleeger, “Design and analysis in software engineering, part 3: types of experimental design,” Software Engineering Notes, vol. 20, no. 2, Oct. pp. 14–16, 1994. S. Pfleeger, “Design and analysis in software engineering, part 5: analyzing the data,” Software Engineering Notes, vol. 20, no. 5, pp. 14–16, 1994. S. Pfleeger, “An investigation of cost and productivity for object-oriented development,” diss, Fairfax, VA: George Mason University, 1995. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 104 T. Pole, “It’s all in the timing,” Flashline Technology, [Online document], ND, [2005 Aug. 30], Available http://www.flashline.com/Content/tpole/decisionModel.jsp? sid=1122760619257-1084354677–102 J. Poulin, “Populating software repositories: incentives and domain-specific software,” Journal of Systems and Software, vol. 30, no. 3, Sep., pp. 187–199, 1995. J. Poulin, “The economics of product line development,” International Journal of Applied Software Technology, vol. 3, no. 1, Mar., pp. 20–34, 1997a. J. Poulin, Measuring Software Reuse: Principles, Practices, and Economic Models, Reading, MA, Addison-Wesley Longman, 1997b. J. Poulin and K. Werkman, “Software Reuse Libraries with Mosaic,” Oswego, New York: Loral Federal Systems, [Online document], ND, [2005 Aug. 30], Available http:// archive.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/werkman/www94.html J. Poulin and K. Yglesias, “Experiences with a faceted classification scheme in a large reusable software library (RSL),” Proc. Seventeenth Annual International Computer Software and Applications Conference, pp. 90–99, 1993. J. Poulin, D. Hancock, and J. Caruso, “The business case for software reuse,” IBM Systems Journal, vol. 32, no. 4, pp. 567–594, 1993. R. Pressman, Making Software Engineering Happen: A Guide for Instituting the Technology, Englewood Cliffs, NJ, Prentice Hall, 1988. Pressman, R., Software Engineering: A Practitioner’s Approach, Boston, MA: McGraw-Hill, 1992. “Product line systems program,” Software Engineering Institute, Carnegie Mellon University, [Online document], ND, [2005 Sep. 9], Available http://www.sei.cmu.edu/progams/pls/ pl_program.html R. Prieto–Diaz and P. Freeman, “Classifying software for reusability,” IEEE Software, vol. 4, no. 1, Jan., pp. 6–16, 1987. L. Putnam and W. Myers, Five Core Metrics: The Intelligence Behind Successful Software Management, New York: Dorset House Publishing, 2003. D. J. Reifer, Practical Software Reuse: Strategies for Introducing Reuse Concepts in Your Organization, IEEE Standard 1517, New York: John Wiley and Sons, 1997. “Report on independent research study of software reuse (using frame technology),” Pittsfield, MA: Quality Software Management, Inc., [Online document], Sep. 1994, [2005 Aug. 30], Available http://www.qsm.com/independent.pdf “Reusable software components,” Federal Aviation Administration Advisory Circular AC 20-148, [Online document], Dec. 7, 2004, [2005 Aug. 31], Available http://www.airweb.faa.gov/ Regulatory_and_Guidance_Library/rgAdvisoryCircular.nsf/ Reuse Adoption Guidebook, version 02.00.05, Herndon, VA: Software Productivity Consortium, SPC-92051-CMC, Nov. 1993. W. Riddle, “Instituting and maturing a practical reuse program: an interview with Dr. William Frakes,” International Perspectives in Software Engineering, vol. 1, Summer, pp. 18–26, 1993. D. Rine, “Supporting reuse with object technology,” special issue on software reuse processes and products,” IEEE Computer, vol. 30, no. 10, Oct., pp. 43–45, 1997. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 105 D. Rine and R. Sonnemann, “Investments in reusable software: a study of software reuse investment success factors,” Journal of Systems and Software, vol. 41, no. 1, Apr., pp. 17–32 1998. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen, Object-Oriented Modeling and Design, Englewood Cliffs, NJ: Prentice-Hall, 1991. J. Rushby, “Modular certification,” Washington, DC, National Aeronautics and Space Administration, NASA/CR-2002-212130, [Online document], Dec. 2002, [2005 Aug. 30], Available http://techreports.larc.nasa.gov/ltrs/PDF/2002/cr/NASA-2002-cr212130.pdf D. Schmidt, “Why software reuse has failed and how to make it work for you,” [Online document], ND, [2005 Aug. 31], Available http://www.cs.wustl.edu/~schmidt/reuse-lessons.html R. Selby, “Enabling reuse-based software development of large-scale systems,” IEEE Trans. Software Engineering, vol. 31, no. 6, June, pp. 495–510, 2005. “Services for Helping the Air-quality community use ESE data,” [Online document], ND, [2005 Sep. 9], Available http://capita.wustl.edu/ShAirED/ “Software approval guidelines,” Federal Aviation Administration Order 8110.49, [Online document], June 3, 2003, [31 Aug. 2005], Available http://www.airweb.faa.gov/ Regulatory_and_Guidance_Library/rgOrders.nsf/ “Software architecture for software-intensive systems,” Software Engineering Institute, Carnegie Mellon University, [Online document], ND, [2005 Sep. 9], Available http://www.sei.cmu.edu/ architecture/index.html “Software product line case studies,” Software Engineering Institute, Carnegie Mellon University, [Online document], ND, [2005 Sep. 21], Available http://www.sei.cmu.edu/productlines/ spl.case_studies.html “Software product lines,” Software Engineering Institute, Carnegie Mellon University, [Online document], ND, [2005 Sep. 9], Available http://www.sei.cmu.edu/productlines/index.html Software Reuse Major Issues Need to Be Resolved Before Benefits Can Be Achieved: Report to the Chairman, Subcommittee on Defense, Committee on Appropriations, House of Representatives (SuDoc GA 1.13:IMTEC-93-16), Washington, DC: Government Accounting Office, 1993. “Software Reuse Study Report: A Report for the NASA IV&V Facility, Fairmont, West Virginia,” [Fairmont, WV, 2005]. I. Sommerville, Software Engineering, 5th ed., New York: Addison-Wesley, 1996. I. Sommerville, “Software Reuse,” in Software Engineering, 7th ed., Addison-Wesley, 2004. R. Sonnemann, “Exploratory study of software reuse success factors,” diss, Fairfax, VA: George Mason University, 1995. W. Staringer, “Constructing applications from reusable components, IEEE Software, vol. 11, no. 5, Sep., pp. 61–68, 1994. “Strategic evolution of Earth Science Enterprise Data System (SEEDS) Formulation Team final recommendation report, Vol. I,” [Online document], Jul. 2003, [2005 Aug. 31], Available http:// seeds.gsfc.nasa.gov/SFormHome.html “Supporting Reuse with Object Technology,” special issue, IEEE Computer, vol. 30, no. 10, Oct. 1997. J. Tirso and H. Gregorious, “Management of Reuse at IBM,” IBM Systems Journal, vol. 32, no.4, pp. 612–615, 1993. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 106 W. Tracz, “Domain-specific software architecture frequently asked questions, Software Engineering Notes, vol. 19, no. 2, April, pp. 52–56, 1994. W. Tracz, Confessions of a Used Program Salesman: Institutionalizing Software Reuse, Addison Wesley Longman, 1995. W. Ulrich, “Collaborative business & IT infrastructures: creating a culture of reuse,” Flashline Technology, [Online document], ND, [2005 Aug. 31], Available http://www.flashline.com/ Content/Ulrich/reuse_culture.jsp?sid=1122760619257-1084354677-102 M. Wasmund, “Implementing critical success factors in software reuse,” IBM Systems Journal, vol. 32, no. 4, pp. 595–611, 1993. J. Withey, “Implementing model based software engineering in your organization: an approach to domain engineering,” Pittsburgh, PA: Carnegie Mellon University Software Engineering Institute,. Tech. Rep.CMU/SEI-93-TR, November 1993. K. Yglesias, “Limitations of certification standards in achieving successful parts retrieval,” Proc. 5th International Workshop on Software Reuse, 1992. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 107 Appendix C: Study Team Participants C.1 Participants David Atkinson (JPL, Study Lead) Anil Agrawal (JPL) Charles Beswick (JPL) Lisa Blue (MSFC) Tom Cochrane (ARC) Keith Cornett (MSFC) Len Day (JPL) S. Ellenberger (JSC) M. Hinchey (GSFC) Michael Izygon (JSC) Mark L. James (JPL) Patricia Langwost (KSC) Michael Lowry (ARC) Jeff Lubelczyk (GSFC) Huyen-Anh “Bebe” Ly (JSC) L. Markosian (ARC) P. Miner (LaRC) Eugene Miya (ARC) Thomas Pressburger (ARC) Steven Purinton (MSFC) Kirk Reinholtz (JPL) Luis Trevino (MSFC) Robert Waterman (KSC) Harry Woo (JPL) CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report C.2 Document No.: AC1L1-52 Effective Date: October 1, 2005 Study Team Bios D. Atkinson JPL, Study Lead Revision: 0 Page 108 CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 109 Dr. David J. Atkinson is Program Manager nager of the Cons Constellation Systems Engineering Support Office in JPL’s Exploration Systems and nd Technology Office O where he works with NASA’s Project Constellation. As Program Manager, nager, he is responsible re for all of JPL’s systems engineering support to the Constellation on Program Systems S Engineering. Additionally, David serves as the Chair of the “Computers,, Software and Automation Integrated Discipline Team.” As the Chair of this group, he leads a multidisciplina ultidisciplinary group of experts from across NASA to develop the foundational systems engineering neering in this thi discipline area for Project Constellation. Previously, Dr. Atkinson was Deputy Division ivision Mana Manager of the Information Technologies and Software Systems Division at NASA’s Jet Propulsion L Laboratory, California Institute of Technology. As deputy manager of JPL’s ’s lead organization organi for computing, software engineering and information technologies, he was responsible for oversight ove of the development, delivery and operations of major information systemss and software softwa for JPL’s flight projects and Deep Space Network as well as advanced computing ng and information inform systems for other government agencies. Recent major deliveries by the he Division have ha included software architecture and engineering for the on-board flight software oftware systems system on the Mars Exploration Rover (MER) project, the mission control centers for MER Entry, Descent D and Landing, Engineering, and Science Operations, and major software re system upgrades upgra to the uplink, monitor and control and ground data systems of the Deep Spacee Network. Earlier at JPL, Dr. Atkinson headed the Section responsible respons for development of key software subsystems of the AMMOS multi-mission ion operations system. As a Section Manager, he also oversaw the development of both mission-specific ion-specific and a multi-mission science data systems, such as the Topex SDS and the Planetary Data ata System. Throughout T his career at JPL, Dr. Atkinson has had additional duties as a Program Manager. In collaboration c with NASA HQ and Centers, he supervised NASA technology R&D at JPL and numerous num other institutions in such areas as autonomous systems, operations automation, ation, artificial artific intelligence, and robotics. He has also participated in mission studies, including ng the Mars Rover Rove Sample Return, Europa and Titan missions. Dr. Atkinson is an expert in systems autonomy utonomy and automation, a a notable early contribution being the invention of the SHARP (now SHINE) system sys which provided real-time monitoring and diagnosis operations support for Voyager oyager and Magellan M telecommunications as well as the Galileo power subsystems. Dr. Atkinson on has received receive the NASA Exceptional Service Medal as well as numerous NASA Group Achievement vement Awards Awards, Space Act Awards, and multiple recognitions by the NASA Inventions Board. Dr. Atkinson At is a member of the IEEE, AAAI, and ACM, and has over 45 publications. Hee serves as a Member M of the Industrial Relations Board for California State University at San Luis uis Obispo (CalPoly) (Ca Computer Engineering Program. Dr. Atkinson holds a Ph.D in Computerr Systems Engineering Engi from Chalmers University of Technology, Göteborg, Sweden (where he also served serve as a Visiting Scientist) the M.S. and M. Phil degrees in Computer Science from Yale University Univers and the B.A in Psychology from the University of Michigan. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 110 A. Agrawal JPL Dr. Anil Agrawal is Member of Technical cal Staff in the Ground Data System section at Jet Propulsion Laboratory. He has overr 25 years experience experi in the area of software development, system engineering and development of satellite ground data da systems. Dr. Agrawal was responsible for developing oping the major ma segments of the ground data system for TOPEX and JASON project. Currently y he is providing providi technical support for the NASA’s Project Constellation Computers Software and nd Automation Integrated Int Discipline Team (CSAIDT) in the area of risk management, software reusability usability and automation. a He received his Ph.D. in Electrical Engineering ngineering from Southern Methodist University. C. Beswick JPL Dr. Charles Beswick has managed large ge IT organizations organiza at the Jet Propulsion Laboratory for 20 years. Most recently, he managed a 400 person section sect that builds, maintains, and operates the Lab’s computing infrastructure: networks, orks, workstations, workstat desktop applications, and supercomputing. He also served as manager nager of the IT Partnering Office (managing $400Million worth of IT support contracts). Dr. Beswick was Deputy Division Manager nager of the Information Inform Systems Division (750 people, $120M budget) for 10 years. In this capacity, pacity, he directed dire the implementation and operation of large ground data systems, telecommunication unication systems, syste and administrative computing systems. He led the first re-evaluation of the Deep ep Space Network Net information systems architecture in more than twenty years and co-led the development of the JPL IT Strategic Plan. Prior positions at JPL include serving ng as technical section s manager of two different sections, one focused on artificial intelligence, science nce data systems, syste and software engineering (JPL software development standards) and the otherr on building large la military simulation and decision support systems for DOD. Dr. Beswick managed ged the developm development of the Corps Battle Simulation (CBS), which was featured on the cover over of TIME and made m major contributions to Desert Storm and Iraqi Freedom. Prior to joining JPL, Dr. Beswick held d a faculty position pos at the University of South Carolina (Assistant Professor of Management Science) cience) and worked w for Olin Corporation as a systems engineer (information systems). Dr. Beswick received the NASA Exceptional ptional Service Servic Medal in 1986 for “exceptional achievements in large scale simulation, on, computer graphics, gra and artificial intelligence.” L. Blue MSFC CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 111 Ms. Lisa Blue has 22 years of experience nce in Flight Computers Com and Data Systems. Her experience includes being the responsible ble Avionics Lead L Engineer for the International Space Station Nodes 2 & 3 Project as well as the ISS Command Com and Data Handling (C&DH) system expert at MSFC. She was responsible for the Flight Test Telemetry System for the Proto-type Clipper-Graham vehicle, where she also o dealt with human hum rated requirements for evolving the Clipper-Graham into a space vehicle. T. Cochrane ARC CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 112 Mr. Tom Cochrane is co-lead and systems ms architect for SimStation, S a virtual vehicle that is a knowledge-management system for the he International Internationa Space Station. SimStation is a 3D CADbased visualization model integrated with ith functional, functiona behavioral and procedure models, with access to multiple data resources and streaming treaming telemetry tele and with interactive crew avatars. It is intended to assist vehicle system engineers, neers, flight operations ope and crew, as they research and evaluate design and operational tradeoffs. offs. The technology technol is being expanded to future NASA exploration vehicles. Mr. Cochrane’s work has included participation rticipation in developing de the structure for NASA’s high performance computing and communications cations projects, projec next generation space transportation systems, and on a project team to design gn a spatial modeling m system for the National Airspace Management System. He played a leading ding role in a Space S Computing Working Group chartered by NASA headquarters to evaluate NASA’s SA’s future needs ne for computing in space. He also participated in a JSC committee to evaluate luate on-orbit on-orbi failures of Command and Control computers on the International Space Station. tation. Mr. Cochrane is a pathfinder in knowledge-integrat edge-integrating systems for aerospace computing and geographic information systems and nd has made numerous num presentations on Capital Hill, the Pentagon, NASA, DOE, EPA, DoD, and nd DOI. He ha has been responsible for developing systems ranging across many application areas,, including: energy e and aerospace, federal, state and local environmental and natural resources management, anagement, educational e computer games, automotive manufacturing, and motion pictures production. Mr. Cochrane worked for several years for DOI as Interior Int Basins RS/GIS Coordinator; designing and managing remote sensing, ng, GIS and database da systems for natural resource planning. Responsibilities include conducting onducting remote remot sensing analysis of habitat, biological, hydrologic and other resources. His work ork included constructing c and maintaining RS/GIS layers and databases throughout the interior or basins region of the t western United States. Mr. Cochrane served as systems integration gration manager manage for the congressionally mandated SERDP Program (Strategic Environmental Resources ources Development Devel Program), a joint DoD/DOE/EPA life-cycle-analysis program for agile, clean, lean, manufacturing manufa technology. In this capacity he acted for DOE headquarters as the technical liaison between betwe software development teams from several national laboratories. Mr. Cochrane served as technical reviewer wer for DOE headquarters of the Integrated Computer Control System (ICCS), for the National onal Ignition Facility Fa (NIF) at Lawrence Livermore Laboratories (LLNL), for generating ng fusion events in i the laboratory. He contributed system architecture design concepts, and served d as technical technica liaison for the LLNL NIF ICCS team. Mr. Cochrane has supported U.S. EPA and U.S. DO DOJ with modeling and data quality management for contaminated Superfund rfund sites. He produced produc large 3D scientific visualizations for a number of complex SUPERFUND D sites, and worked w as a technical reviewer for scoring national priority list sites. He also performed rformed an extensive ext evaluation for U.S. EPA on the data management systems and GIS software re tools used within w the SUPERFUND program. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 113 K. Cornett MSFC Mr. Keith Cornett began here at MSFC C in 1980. Initially, Ini his work involved Spacelab Mission Operations and he was a member of two o flight ops teams t that conducted the on-orbit payload operations. After these two missions,, he transitioned over ove to development of mission operations ground systems. He worked specifically ly with the verification ve of the integrated ground systems development activities (hardware and nd software) for the t Spacelab Payload Operations Control Center and the Shuttles Engineering Support upport Center in i the HOSC. The tasks eventually transitioned into actual software and nd hardware development deve of these systems. Mr. Cornett became Branch Chief in n 1990 and the branch bra had the responsibility to build the Chandra Operations Control Center (OCC) CC) and the International Int Space Station Payload Operations Integration Center (POIC) IC) and the United Unite States Operations Center (USOC). The group was responsible for the system engineering ngineering and a the hardware/software development of these systems. In 1993, he became Division Chief responsible ponsible for the t activities above coupled with the facility development activities necessary to accommodate commodate these t systems. In late 2000, he became Deputy Project Manager of the Interim Control Module Modul project and within 6 months became the Project Manager. In 2002, Mr. Cornett was part of the SLII program office of and developed program requirements for software and for mission operations. ons. After the SLI S Program transitioned to the Orbital Space Plane (OSP) Program, he became a member mber of the OSP O Acquisition Management Office and developed various components of the OSP SP RFP, including inc software and mission operations requirements. L. Day JPL CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 114 Mr. Len Day is presently a senior software are engineer at a the Jet Propulsion Lab. Recent accomplishments include the leadership p of the team that delivered boot and filesystem code to the Deep Impact project and boot code to the Mars Reconnaissance Re Orbiter project. He also acted as a system engineer and led the low-level software soft team for the JPL Multi-Mission System Architecture Platform. He is currently urrently the System S Engineer/Chief Engineer for an Integrated Vehicle Health Management nt technology demonstration de task that is being done in cooperation by JPL, Ames Research h Center and Dryden Dryde Flight Research Center. Mr. Day’s first involvement with a space ce flight project proj was as a member of the operations team for the Viking Mars project. Since then n he has participated partic in a number of other flight projects including Seasat, MILSTAR, Galileo and nd Cassini. He H has also participated in problem resolution teams for a number of other flight projects ects including MISR, M QuickSCAT, Genesis and MER and has three times received the Space Act Award for significant si contribution to the space program. Mr. Day’s career has not been limited d to Aerospace and a he has worked for a number of companies through his career including ng Printrak, Inc. Inc (fingerprint matching systems), Hughes (factory automation), Networking Dynamics ynamics (FAX applications) a and he did the computer system for the first Cyber Café in Los Angeles County. Count He brings a broad experience base at all levels of software engineering from GUI UI user interfaces interfa through systems-level and device drivers. He has performed in all phasess of software development de including systems engineering, architecture development, software development, velopment, test/validation te and technical management. Mr. Day has a particularly strong background kground in embedded embedde systems and space applications. S. Ellenberger JSC M. Hinchey GSFC Dr. Michael G. Hinchey is currently Director irector of the NASA Software Engineering Laboratory, located at Goddard Space Flight Center. r. Prior to joining joi the US Government, he held academic positions at the level of Full Professor or in the USA, UK, U Ireland, Sweden and Australia. He is the author of move than 120 technical papers, pers, and 15 books. books His current research interests are in the areas of formal methods, system correctness, ctness, and agent-based age technologies. Dr. Hinchey is a Senior Member of the IEEE, a Fellow Fell of the IEE and the British Computer Society. He is a Chartered Engineer,, Chartered Professional Profe Engineer, Chartered Information Technology Professional and Chartered d Mathematician. Mathematic Dr. Hinchey is currently Chair of the IEEE Technical Committee on Complexity xity in Computing, Comput and is the IEEE Computer Society’s voting representative to IFIP TC1, C1, for which he has been elected Chair for 2006 to 2008. He is also Vice Chair of the IEEE Computerr Society Technical Techni Activities Board and of the newly established IEEE Task Force on Autonomous onomous and Autonomic A Systems. Dr. Hinchey received the Ph.D. in Computer puter Science Scienc from University of Cambridge, UK, the M.Sc. degree in Computation from University niversity of Oxford, O UK, and the B.Sc. degree in Computer Science from University of Limerick, k, Ireland. M. Izygon JSC CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 115 Dr. Michel Izygon came to the Johnson on Space Center Cent as a post-doctoral research scientist under the National Research Council program in 1990. Since Sinc then he has continued to work at JSC toward the insertion of advanced software are technologies technologi into operational programs. Today he is the CTO and co-founder of Tietronix Software, oftware, a small sm business participating in multiple projects at NASA/JSC. As a research scientist, Dr. Izygon researched arched ways to use artificial intelligence technologies to solve NASA-JSC problems. His responsibilities ponsibilities inc included the development of an intelligent user interface for complex scientific programs, ms, the use of Artificial Intelligence in Software Engineering, and development of a Visual ual Programming Program tool for a Reuse-based Domain Engineering Environment. Dr. Izygon served as a software technology hnology consultant consulta in the ROSE project which aim was to reengineer millions of lines of code supporting upporting the Trajectory Tra simulation of the JSC Mission Control Center. His support to the ROSE E project included inc overall software architecture development, training of more than n one hundred engineer engi on Object-Oriented Methods, use of the Object Modeling Technique (OMT), ), development developme of Software Development Processes based on the OO concept, customization on of the CASE CAS Tool, evaluation of tools and Class Libraries, and development of a Pen-based n-based application applicat for group activity support. He acted as project lead on the development of an n Intelligent Computer Com Aided Training system for the OMT method, as well as for the development nt of a simulation simulat tool aimed at verifying and validating OMT models. Dr. Izygon was in charge of the insertion on of advanced advance software technology at the NASA-JSC. His responsibilities included the use of Object-Oriented Object-Orie Methods to reengineer Mission Control Center software, training of two Rockwell ell groups on the t Object Modeling Technique (OMT) method, assessment of Object-Oriented d Analysis and Design D Methods for software development, development of a tool to o support Total Tota Quality Management method at JSC, software reengineering methods and tools ools evaluation. Dr. Izygon served as technical lead in n the Web-based Web-base electronic workflow system, which aimed at deploying a number of workflow automating utomating different diffe mission critical processes of the NASA —Johnson Space Center. These include ude the Space Station S Procedures Change Request System, the Space Shuttle Flight Rule Change Request System, Syste and the Internal Proposal Technical Assessment Process of the NASA—JSC C Mission O Operation Division. Dr. Izygon acted as the main software architect of the Roboticss Situational Awareness Display, an on-board software that helps the astronauts manipulates the he robotics arm on the Space Shuttle. M. James JPL CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 116 Mr. Mark L. James is a member of the Advanced Computing Com Algorithms and IVHS Group in the Flight Software and Data Systems Section tion within NASA’s N Jet Propulsion Laboratory, Pasadena, CA. At JPL Mr. James is Principal Investigator and Task Manager in real-time inference and knowledge-based systems. His primary ry research focus foc is on high-speed inference systems and their application to planetary and exploration oration and military m systems, and, automatic software debugging of large software systems. Mr. James has received a number of JPL L and NASA awards which include: Space Act Award for 2005, Space Act Award for 2003, Major or Scientific Achievement A Award for 2002, NOVA award for Leadership in 2000, Team Excellence nce Award for 1990, JET J Productivity Award for 1990, Major NASA Monetary Award rd for 1990, NASA Ce Certificate of Recognition for 1990, NASA Group Achievement Award for 1990, NASA ASA Exceptional Except Service Medal for 1989, NASA Exceptional Service Plaque for 1989, NASA ASA Manned Manne Flight Awareness award for 1989 and NASA Manned Flight Awareness award rd for 1988. He is author of 1 patent, 8 provisional patents, 41 scientific sc and technical papers, and 17 technical manuals. Mr. James has over thirty years experience ence in design, implementation, i and integration of large software systems with core competencies ies in applied computer c science and core artificial intelligence technology. His special areas as of expertise experti include: artificial intelligence technology, high-speed real-time expert systems, image age processing process and scene analysis, pattern recognition, planning and simulation, real-time control ontrol systems, programming progra languages and compilers, symbolic mathematics, operating systems, ms, programming program environments, robotics, virtual reality systems, with additional expertise in medicine, edicine, biology, biol and analog and digital electronics. Prior to coming to JPL Mr. James was the former Chief Chi Scientist and Board Member of System Cognition Corporation (now Inference Corporation). He H contributed to the development of the MIT LISP Machine when it was commercialized ercialized as the LMI LISP Machine. He contributed to the development of Symbolic Manipulation ation Program (SMP), later to become Mathematica. He also held a consulting position at Hughes ughes Research Lab, L Systems programmer at the University of Southern California, Researcher at the he Information Sciences S Institute (ISI) and consultant to XEROX PARC. Mr. James worked with Dr. David Atkinson kinson in the invention inve of the SHARP (now SHINE) system which provided real-time monitoring toring and diagnosis di operations support for Voyager and Magellan telecommunications as well as the Galileo power pow subsystems. He is co-author of STAR*TOOL, a sophisticated knowledge dge representation represent system. He is co-author of SHINE which has been licensed to numerous companies ompanies involving invol applications that include business forecasts, biotech, robotics, smell detection, ction, etc. He is author of the Programmers’ Assistant, an automatic debugging tool that locates anomalies in software. s P. Langwost KSC CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 117 Ms. Patricia Langwost received a BS in n Electrical Engineering E with a minor in Space Studies from the University of North Dakota and nd a MS in Industrial Indus Engineering from the University of Florida. Ms. Langwost has worked in the ISS Payload ayload Proce Processing Directorate developing video and audio requirements, test procedures,, problem reports, report trouble-shooting plans, and interface drawing between GSE and flight hardware are for Multi-Element Mult Integration Test 3 (MEIT 3 included Node 2, Japanese Experiment nt Module (JEM), (JE and the Flight Emulator), Node 2 Standalone test, and Node 2 Traveled Work ork Systems System Test (TWST). She was the KSC Experiment Engineer for Space Dynamically ically Responding Respondi Ultrasonic Matrix System (SpaceDRUMS) and Expedite the Processing essing of Experiments Expe to the Space Station (EXPRESS) Engineer for ULF1.1 Mission. She wass also the Electrical Ele Power Distribution and Control (EPD&C) lead for the Orbital Space Plane lane (OSP) Launch L Site Integration Office. M. Lowry ARC CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 118 Dr. Michael Lowry is the area lead d for Automated Software S Engineering within the Computational Sciences Division and nd is also the project proj manager for Automated Software Engineering Technologies within the ITSR program. program He serves as the NASA lead for the HighDependability Computing Program, and nd is the NASA NAS program manager for the joint NSF/ NASA HDCSSR program. Dr. Lowry’s main technical interest is in applying automated a reasoning to Software Engineering. After joining NASA Ames in 1992, he was the principle princ investigator on the Amphion project. Amphion automates the construction on of programs from domain-oriented user specifications by composing subroutines from a reuse library. brary. Amphion Amphi is a generic architecture which is specialized to a new domain by developing oping a declarative declara domain theory. Domain theories for several NASA applications have been n successfully built, bui including Computational Fluid Dynamics, Space Observation Geometries, ries, and Space Spa Shuttle Navigation. Meta-Amphion was developed in 1995 as a means of generating rating additional additiona Amphion applications, receiving the best paper award at the Knowledge-Based d Software Engineering Engi conference. Dr. Lowry has since lead his group in n developing innovative innova applications of automated reasoning for software engineering based ed on experience experie with NASA domains. This includes software model checking (2003 TGIR IR award), the before/after be experiments with Deep-Space one, and new thrusts such as certifiablee program synthesis synt and automated testing. Under his leadership, the automated software engineering ngineering group has ha grown from three people to fifteen people, and has developed collaborations ons with a number num of NASA application projects including Space Shuttle SAFM, JPL Planetary Data ata Systems, JPL J MER and MSL projects, and NASA Ames aviation capacity projects. He recently cently organized organi a NASA-wide workshop in April 2004 on reliable software, involving both NASA ASA centers and a the chief engineers office. Dr. Lowry is a member of the editorial board for the Journal of Automated Software Engineering (published by Kluwer), and nd was the program progra chair of the Automated Software Engineering conference held in fall 1997 (formerly KBSE'97). K He is co-editor of the book Automating Software Design (1991) available vailable from MIT Press, and was the principle author of a tutorial on knowledge-based software re engineering that t was part of the Handbook of Artificial Intelligence. Lowry has reviewed d proposals for NASA, NA Darpa and NSF, and is currently the technical advisor for NASA Ames on many any university univers grants on software engineering technologies. He has served on numerous rous conference conferenc program committees. Dr. Lowry received his MS/BS from MIT IT and his PhD P in 1989 from Stanford University in computer science. His PhD dissertation, on, “Algorithm Synthesis through Problem Reformulation,” focused on formalizing ng and automating automa algorithm design and problem reformulation/abstraction. From 1989 to 1992 he was w a computer scientist at the Kestrel Institute, and was principle investigator or on several projects proj related to AI and Software Engineering. During his graduate studies udies he also did research re in image understanding and speech understanding, and digital signal gnal processing. J. Lubelczyk GSFC CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 119 Mr. Jeff Lubelczyk has more than n 16 years of NASA experience working with software, systems engineering, and project management on a variety of programs progra ranging from technology assessment and insertion into operational onal systems (such (s as spacecraft operations and the space network) to science systems development. ent. He currently curre supports multiple Earth science related missions including NPOESS/NPP and nd LDCM, and ha has begun supporting NASA’s exploration initiative. Mr. Lubelczyk holds an M.S. in electrical cal engineering engineeri from the Johns Hopkins University. H. “Bebe” Ly JSC Ms. Huyen-Anh “Bebe” Ly has worked d at NASA Johnson Johns Space Center since January 1986. Ms. Ly has worked on many software projects which whic range from artificial intelligent projects to flight support software systems development. opment. She developed de the X-window Graphical User Interface for the Expert System Shell,, C Language Integrated Int Production System (CLIPS, the knowledge capture tool named Task Analysis/ nalysis/ Rule Generation Tool (TARGET), and CLIPS expert system Verification and validation on tool, Cross Cros Reference & Verification System (CRVS). Ms. Ly was the project lead of the Onboard nboard Short Term T Plan (OSTP) and Onboard Data File (ODF) Crew Interface (OOCI) project,, which provided provi the software package for the Internal Space Station Crew and the flight controller roller team to view vi the manual procedures and the onboard short term plan. Ms. Ly also managed anaged the High H Volume Data Management Project which developed an advanced set of tools ools to support distributed handling of documents and the integration of electronic tools for authoring, horing, revising, reviewing, re controlling, and releasing operations books controlled by the system. tem. This development deve includes automation of the process definition engine used to build d process flows. flow L. Markosian ARC Mr. Lawrence Markosian is a Computerr Scientist employed em by QSS Group, Inc. at NASA ARC, where he led a team developing practical al model checking che tools based on Java PathFinder. Over the past three years he has been active in the NASA Software Engineering Initiative’s Research Infusion activity, where he is the contractor ractor lead on a process for tech transfer of software engineering research into NASA development opment organizations. organi More recently he has contributed to the Constellation ISHM study, focusing ing on V&V of ISHM. Prior to joining NASA, Mr. Markosiann held various positions at Reasoning, Inc. where, as VP of Applications Development, he managed d technology transfer t of advanced software engineering tools for software synthesis, transformation, ation, and defect defe detection. He has authored many presentations and publications on code synthesis, reengineering, re and software defect detection. Mr. Markosian has an undergraduate degree in mathematics mathe from Brown University and has done graduate work at Stanford University rsity in logic and a applications of artificial intelligence. P. Miner LaRC CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 120 Dr. Paul Miner is a Senior Research Engineer ngineer in the Safety-Critical Avionics Systems Branch at NASA Langley Research Center. His primary research resea interests are fault-tolerant systems, design and digital systems, and design gn assurance using us formal methods. He is the principal architect of the Scalable Processor-Independent -Independent Design Des for Extended Reliability (SPIDER). Dr. Miner’s recent responsibilities have ve focused on formal form analysis and certification considerations for fault-tolerant integrated grated modular avionics. a He is an active participant on RTCA Special Committee 200, developing oping the document docum “Integrated Modular Avionics (IMA) Development Guidance and Certification on Considerations.” Considera Dr. Miner has been a NASA employee since 1989 and a holds a PhD in Computer Science from Indiana University. E. Miya ARC Most recently Mr. Eugene Miya worked d as one of NASA’s N liaisons/technical reviewers to the NASA Computers, Information, and nd Communications Technologies (CICT) Program Office on the Interagency Digital Libraries Initiative tive which begat be the Google search engine and other Internet. Mr. Miya is known as “the” Unix evangelist ngelist inside NASA. N This advocacy placed Unix on the Cray-2 supercomputer thus keeping ng Cray Research, Inc. Inc a viable firm (and contributing to the demise of competitor ETA Systems) as well as the early e adoption of networked workstations as other Ames people advocated for TCP/IP. /IP. This work consisted c of supercomputer and support processor acquisition, mass storage system ystem evaluation, evaluati and other systems metrics. Mr. Miya is known for starting the FAQ Q concept on the t Internet in the early 1980s. He maintains the world’s bibliographic database on parallel pa computing. He is Associate Editor for Publications and Software Review for the journal Scientific Programming, and moderator of the comp.parallel omp.parallel news ne group. Mr. Miya has served as staff on various ous ACM and IEEE IE Conferences as well as an ACM SIG chapter President. Mr. Miya’s work at JPL consisted of systems ystems work for S Seasat and VOIR as well as software conversion cost estimation for Voyagerr using software softw metrics. He is an ANSI Standards Committee member, Consultant with the he DOE and DTRA D and other agencies, and is a member of the US Antarctic Program (holderr of Antarctic Service Se Medal). Mr. Miya got online starting in n 1973, host #3 on the ARPAnet. T. Pressburger ARC CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 121 Mr. Thomas Pressburger is in the Robust Software Engineering E group led by Dr. Michael Lowry at NASA Ames. He serves on the Amess Engineering Process P Group and is the alternate Ames representative to the Software Working ng Group. He led l the subgroup of the Software Working Group whose task it is to get mature software oftware engineering engine research used on NASA projects; 9 infusion projects either finished or are in progress, and a 4-5 more will be started in 2006. The subgroup received a “Best New Research” rch” award at OSMA’s Software Assurance Symposium in 2004. Mr. Pressburger’s expertise is in the area rea of software engineering; in particular, automatic code generation. He was a principle programmer mer of the Amphion A system developed under Dr. Lowry at Ames which automatically constructed ted programs from specifications that solved solar system geometry problems, making use of a reusable usable software softw library called SPICE from JPL’s NAIF group. He started as a contractor at Ames es in 1992 and became be a civil servant in 2000. Previously, he worked at the Kestrel Institute and Reasoning, Re Inc. on program synthesis and transformation, and software reengineering. ring. He holds a B.S. in Mathematics from CalTech and an M.S. in Computer Science from Stanford. nford. S. Purinton MSFC Mr. Steven Purinton is the Team Lead, d, Software System Sys Engineering (2+ Years): In this capacity Mr. Purinton performs requirements allocation, location, analysis, ana preliminary schedule development, metric determination, and trade studies in addition to t insight for embedded software programs at MSFC. Project Engineer (2+ Years): Mr. Purinton nton served as a subsystem manager for Command & Data Handling, Guidance Control and Navigation, gation, and Software Soft Integration in the International Space Station Propulsion Module Project, ect, an element eleme of the International Space Station Program and Software Systems in the Chandra Program. Progra Chief Engineer (11 Years): Mr. Purinton on served in Chief Chi Engineer Office for the Chandra Observatory, Chandra Science Centerr and the Aero assist a Flight Experiment with oversight responsibilities for end-to-end system engineering of all a flight software, flight software support systems, ground support equipment software, oftware, and electrical e ground support equipment. Developer (22 Years): Mr. Purinton developed veloped simulator simul environments for Space Telescope, Solar Magnetograph, X-ray Telescope,, SRB thermal therma protection system and the Spacelab Payload Crew Training Complex. He converted onverted and developed de real-time operating systems including multiprocessors. He developed oped a robot control cont program and models for rocket engines and rocket engine controllers. He verified fied a Fortran compiler c and library for use in testing of the Space Shuttle Main Engine Controllerr software. K. Reinholtz JPL CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 122 Mr. Kirk Reinholtz is the Project Software are Systems Engineer for the Mars Science Laboratory (MSL) mission. He is also the software re manager and Chief Chi Programmer for the Mission Data System (MDS), a large software and systems ystems engineering engine effort instituted at JPL to prepare the laboratory to meet the challenges of tomorrows omorrows advanced adva missions. He is the P.I. for several research efforts, including “Multi-view modeling and Analysis of Mission Data System Applications” and “Verifiable C++.” The he objective of the t research in Verifiable C++ is to reduce the cost of safety-critical software by allowing llowing productive produc programming languages to be applied in the safety-critical domain, or equivalently lently to allow larger systems to be developed for the same cost. The approach is based d upon the development developm of coding techniques that work in conjunction with analysis tools to allow deeper analysis anal for faults of much larger programs than would otherwise be possible. Mr. Reinholtz’s research interests include ude large-scale large-scal software engineering and verification techniques, and the prudent and nd productive application applicat of powerful programming languages and tools to large mission-critical and safety-critical y-critical software soft systems. Mr. Reinholtz has a Masters degree in Computer Science from the University niversity of Southern S California. L. Trevino MSFC CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 123 Dr. Luis Trevino, Marshall Space Flight ght Center, is currently c an AI researcher in the Advanced Sensors and Health Management Systems ms Branch within w the Spacecraft and Vehicle Systems Department investigating new advanced d computing technologies t for Health Management Systems. Specifically he’s investigating ng advanced software s architectures and requirements for spacecraft systems. Other areas of research arch interest are a in prognostics, diagnostics, fault detection, mitigation strategies, and nd brain theory related rel to the development of intelligent machines. For the prior year he served d as lead for the Avionics Department’s Advanced Computing Office investigating applications ations of advanced adva computing techniques in MSFC projects. For the past three years Dr. Trevino hass served on NASA’s N Software Working subgroup for Software Technology Infusion involving ng members from Ames Research Center, JPL, Langley Research Center, and Goddard Space Flight light Center. This group independently researches technologies and uses available resources ources for furthering furthe the infusion of potential technologies into NASA software projects for improving proving the production produc of software. From mid-1999 to early-2004, he served as Software Design ign Team Leader Lea for the Flight Software Group within the Avionics Department. He served on a software oftware review revie board overseeing all embedded flight software projects and addressing issues. s. He helped the t Flight Software Group reach CMM Level III certification by representing ng the Design and Implementation Im Capability during the audit. For the prior 11 years, Dr. Trevino worked orked in the Propulsion Propul Laboratory at MSFC as a controls engineer for Technology Test Bed SSME E Testing and SSME S and X-33 Aero-Spike engine health management. Dr. Trevino holds a BSEE from Texas A&M and a MSEE M and a PhD EE from University of Alabama, Huntsville. He has applied d for a patent on “Implementing “ Bayesian Analysis Through Recursion” (for real time engine analysis ysis software) for rocket roc engine start-up. R. Waterman KSC CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 124 Mr. Robert Waterman is responsible for Command and a Control, Avionics, Integrated Systems Health Management, and Software for the NASA KSC K Constellation Systems Office. Previously he was the technology area champion for supportability s of non-terrestrial system at the Kennedy Space Center. He was the Command and a Data Handling (C&DH) as well as the Flight Software lead for the Orbital Space pace Plane (OSP) (O Launch Site Integration Office and was an active member of the agency wide team eam for Integrated Integra Health Management (IHM). He was the Spaceport Technology Development nt Manager for command, c control and monitoring technologies where he led the KSC strategic rategic planning and a new business development activities in addition to addressing the high priority ority needs of the t center within the command, control and monitor thrust area. Previously, Mr. Waterman was the technical hnical lead for real-time re control software being developed for the ground Checkout and Launch h Control System (CLCS) where he was responsible for the technical direction of the application software oftware development devel and conflict resolution between the development organization and the operations rations organization. organi Mr. Waterman has fifteen years experience ence as the system sys specialist for the Space Shuttle Main Engine (SSME) avionics system where he was responsible respons for developing the certificate of flight readiness for the SSME avionics system and leading l the anomaly resolution activities during launch countdown. He was the NASA point of contact c for SSME Controller (SSMEC) software problem analysis and resolution, on, coordinating coordinat troubleshooting results with various NASA centers and vendors. Before joining ning NASA, Mr. M Waterman was with Lockheed Space Operations Company, where he was a launch certified certifi console engineer on the SSME avionics system. He was responsible for the day-to-day y-to-day maintenance maint and diagnostic testing of the SSME and related Space Shuttle Orbiter hardware. rdware. H. Woo JPL Mr. Harry Woo has nearly 30 years experience xperience in mission m operations and the design and implementation of ground data systemss for planetary spacecraft. s He has worked in various systems engineering and management capacities on Voyager, Ulysses, Galileo, Magellan, Stardust, and Cassini. He established the he Operations Engineering Laboratory at JPL enabling improved mission operations performance nce through development de and application of software tools. Mr. Woo has served in a numberr of line and program progra management positions at JPL and participates on the mission operations review boards of several current flight projects. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 125 Appendix D: Study Team Approach D.1 Study Team and Logistics The Software Reuse, Interoperability, and Compatibility Trade Study team has representatives from across NASA and across the Constellation IDTs. The members of the team were chosen to provide a variety of skills backgrounds. A complete list of study participants appears in Appendix C. D.2 Initial Team Meeting An initial team meeting was conducted to lay out the study approach, identify key study milestones, assignments, and communicate the study schedule. The effort was phased so that not all participants would provide support for the full duration of the study. A specific meeting agenda was developed for initiating the study. D.3 Regular Meetings The team conducted weekly telecon and WebEx meetings to issue assignments, and to report on progress, identify issues, and develop solutions. An agenda was developed for the recurring meetings to facilitate and streamline communications and to set expectations for the study team. D.4 Data Development Team members individually identified key topics or concerns in their special areas of expertise and interest. Literature surveys: The team reviewed over a hundred published documents, NASA memos and data, conference proceedings and presentations, and other written reports. Interviews and consultations: The team added non-IDT personnel who had first hand experience with reuse and/or major technical expertise in the area. Targeted interviews with internal-NASA and external experts were performed. Case studies: The team identified four diverse cases of previous NASA activities directed at or including software reuse, and studied these in depth. D.5 Analysis Team members were assigned specific study topic areas for individual analysis. Data from areas of investigation were shared and discussed in multiple venues, and all work products made available to the team via shared Windchill folders and email. Weekly study team telecons focused the team on emerging “tall-pole” issues and relevant data, and served as a forum for technical discussion as well as study guidance by the Study Lead. D.6 Synthesis Small teams were assigned to create findings by consolidating analysis data in key topic areas, abstracting common elements, and identifying key factors and lessons-learned. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 126 These teams and all study members were invited to make preliminary recommendations. Periodic “consensus” polls were taken on key topic areas as well as study recommendations, and the results targeted for further elaboration. The Study Lead analyzed overall progress and results and prepared consolidated findings and recommendations for discussion by the team. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 127 Appendix E: Reuse Metrics Deserve a Warning Label: The Pitfalls of Measuring Software Reuse 10 Jeffrey S. Poulin Lockheed Martin Federal Systems Almost everyone agrees that reuse involves using something that someone originally developed for “someplace else.” However, when it actually comes time to calculate reuse levels and reuse benefits, people often define reuse with a remarkable amount of flexibility. This article describes some of the difficulties in measuring software reuse. In a thorough and well-executed reuse survey of industry and government organizations by the Defense Information Systems Agency (DISA), software development leaders consistently reported impressive results. Managers gave reuse returns on investment a ratio as high as 4-to-1 after two years, cycle time improvements of more than 30 percent, and “a significantly increased competitive edge” [1]. But when the survey team sought to understand how the survey participants measured success, they found that the participants had provided testimonials and anecdotal results rather than objective evidence derived from quantitative measures. How can we have faith in anecdotes? This article explains how reuse metrics, like all software metrics, can leave a lot of open questions [2]. Leaving Room for Interpretation The values derived from any software metric depend on the data gathered to put into the metric. Unfortunately, developers usually exercise considerable discretion and creativity when deciding how to count different classes of code. To understand the true value of software development practices such as reuse, the data must be evaluated objectively and consistently. To complicate efforts, most people want to use traditional metrics to show increased productivity, e.g., lines of code (LOC) per labor-month, and improved quality, e.g., errors per thousand LOC. This creates an intuitive tendency to “look better by writing more,” which conflicts with the reason for reuse: to avoid software development costs by “writing less.” Unless acknowledged, this conflict will arise in subtle ways as people attempt to show excellence in reuse by using the same type of data used for traditional, productivity-sensitive metrics. Common Counting Strategies Management has considerable influence over how reuse is calculated. If management emphasizes reuse, a variety of common practices will suddenly appear under the reuse banner to artificially raise reuse levels. In my experience, developers often use the following methods to distort their reuse metrics and corresponding reuse benefits. 10 Verbatim text: http://www.stsc.hill.af.mil/crosstalk/1997/07/reuse.asp Note: “Acknowledgments” and “About the Author” have not been included in this appendix. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 128 The Code Generator Method Generating code can greatly help us during software development. However, developers will also use code generators to artificially achieve extremely high levels of “reuse.” For example, graphical user interface (GUI)-intensive applications commonly use code generators. After designing the GUI with a graphical layout editor, the developers merely push a button to create thousands of LOC that implement the GUI. Likewise, the developers might also count the generated code to inflate their productivity metrics. (Some show productivity rates as high as 15,000 LOC per labor-month—a superhuman feat by any standard.) Finally, the developers might include the generated code (usually close to defect-free) to distort their quality metrics with uncommonly good defect rates. Code generators yield a significant advantage when we can use them. However, from a metrics point of view, the code they generate requires special consideration when calculating metrics for productivity, quality, and reuse. We do this by reporting the generated code separately from all other code. The Baseline Code Method Groups performing maintenance can also significantly impact software metric values depending on how they count the code that they maintain. When making a new version of an application via changes to a large software baseline, the group might claim all of the software from that baseline as “reuse” or “produced” in the subsequent version of the application. In short, making minor modifications to a 1 million LOC product does not mean the team “reused” or “wrote” 1 million LOC. As with the generated code example, to include baseline code will severely inflate reuse, productivity, and quality metrics. The Porting Method In an “open systems environment,” the same application often runs on various hardware, operating systems, and flavors of the same operating system. Porting software to similar platforms usually requires little more than recompiling the source code for the new targets. However, some developers will report reuse levels of 99.9 percent for each “port,” and claim a corresponding financial benefit from “reuse.” Because overly high reuse levels may attract unwanted attention and scrutiny, reuse metrics may be collected and combined in many interesting and creative ways. For example, if a low reuse level on the initial development is averaged with a couple of 99 percent values from porting, one can arrive at a plausible and impressive value of 65 percent to 85 percent. This, of course, involves the mathematically unsound practice of averaging percents. The Programming Language Differences Method Language features provided by [insert your favorite programming language here] can make it easier to use code that someone originally wrote for use someplace else. But while procedures, functions, generics, templates, etc., provide highly effective mechanisms for reuse [3], these features do not guarantee reuse, nor does their use automatically mean reuse has taken place. The following set of examples shows how the use of programming language features can help programmers claim reuse even when no true reuse has occurred: CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 129 Traditional example: Programmer J. Average sits down to design and implement a couple of thousand LOC for a new personnel roster and duty assignment system. Average decides to use the C language. Since many of the functions performed by officers, non-commissioned officers (NCOs), and enlisted members do the same thing, Average codes these functions as C functions. The program calls these C functions to process data records for officers, NCOs, and enlisted members. It takes Average three months to complete the program. When asked about reuse, Average responds, “I didn't do any; I wrote the whole program myself.” Object-oriented example: Programmer J. Average sits down to design and implement a couple of thousand LOC for a new personnel roster and duty assignment system. He decides to use the C++ language. Since many of the functions performed by officers, NCOs, and enlisted members do the same thing, Average codes these functions as C++ methods. Classes in the program inherit these methods to process data objects for officers, NCOs, and enlisted members, and it takes Average three months to complete the program. When asked about reuse, Average responds, “At least 60 percent, because I reused the same code over and over.” If both efforts took three months, what happened to the benefits of reuse in the second example? In fact, no reuse took place in either example, because both programmers did all the work themselves. The programmers merely placed different labels on what they did, while correctly using the features provided by their chosen programming language. The Problem of Units Reuse metrics do not necessarily require large influences to cause their values to vary. The previous examples illustrate factors that can have a major impact on metric values. However, metric values can vary significantly due to inconspicuous and seemingly innocuous factors, such as the units used in the metrics. Most organizations use LOC (which have many welldocumented advantages and disadvantages) or units such as function points or objects. How should we account for the wide variation in the size of objects? Should we make an allowance, since the use or reuse of a small object counts the same as the use or reuse of a large object? I have seen reuse levels vary by as much as a factor of 8, depending on whether a group calculated reuse by LOC or by object. The choice of units can affect code metric values, but the need to remove ambiguity in “what to count“ extends beyond code. We must also determine and quantify how to reuse lifecycle products such as requirements, documentation, and designs. What units should we use for these lifecycle phases? How should we count words, scripts, or graphics? Does a picture equal a thousand words? With the exception of the design phase—where some design environments clearly identify measurable “design objects”—standard, agreed-upon units of measure do not exist in the software industry. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 130 Reengineering Pitfalls Just as we expect developers to create routines when they have to do the same thing many times, we also expected them to copy and modify software when possible. This widespread practice, called “reengineering,” routinely saves developers significant implementation effort. But how should we track the amount of modified software in each routine? In addition to the difficulties of measuring reengineered software, how does it compare to the disciplined use of unmodified software that we have designed and implemented for reuse? Note that a plethora of evidence shows that reengineering can actually cost more than new development. This penalty can occur if developers modify as little as 20 percent of the code, and almost certainly occurs if they change more than half [4]. To include modified software in reuse metrics without adjusting for these penalties will inflate the apparent benefits from “reuse.” Altogether, these facts make a cogent argument for the design and reuse of unmodified software. Possible Solutions Management needs to give specific directions when requesting metric data; otherwise, developers will almost certainly use some latitude to interpret the request to their advantage. Developers do not necessarily manipulate the data, but they will present what they have done in the best possible light. For example, many practitioners do not often recognize the difference between “use” and “reuse.” When programmers need to do the same thing many times, they naturally code it into a procedure, function, method, subroutine, remote call, or similar language feature. When asked for reuse data, groups commonly exaggerate their reuse level by reporting every invocation of these routines as “reuse.” Management should specifically state that multiple “uses” do not count as “reuse.” More often than not, reuse metrics should include a warning. Knowing to watch for the “reuse warning label” will help everyone better understand the true benefits of reuse and ultimately help them make the best possible business decisions involving their reuse investments. Reuse metrics make an effective technology insertion tool, even if people will always try to find ways to make the numbers sing their praises. The following suggestions may help you with your reuse program and reuse metrics: • Have a management structure that supports reuse. Dedicate a team of programmers to the task of building and supporting code that all your teams can use. All developers can use this team as a resource during application design and implementation. • Develop and enforce a software architecture for all your teams. Provide the resources early in your project for domain analysis and to develop a common software architecture. • Define what you will measure as reuse and how you will measure it. Make sure everyone understands what you will count and why. • Regularly track your reuse metrics. Use metrics as a technology insertion tool to improve all of your processes and methods. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 131 Conclusions We have all seen experience reports that claim glowing results from reuse; however, reuse does not automatically provide the panacea that some reports seem to indicate [5]. Experience reports that do not mention where and how they obtained the data probably rely on testimonials and anecdotes rather than on objective evidence. Armed with a little knowledge about how metric values can vary based on who does the counting, we can better understand how to measure reuse activities and thereby maximize the benefits of reuse in our organizations. References 1. DISA/SRI, “Software Reuse Benchmarking Study: Learning from Industry and Government Leaders,” Defense Information Systems Agency Center for Software, Software Reuse Initiative, Document DCA100-93-D-0066, Delivery Order 0037, Nov. 10, 1995. 2. Poulin, Jeffrey S., Measuring Software Reuse: Principles, Practices, and Economic Models, Addison-Wesley, Reading, Mass., 1997. 3. Biddle, Robert L. and Ewan D. Tempero, “Understanding the Impact of Language Features on Reusability,” Fourth International Conference on Software Reuse, Orlando, Fla., April 23-26, 1996, pp. 52-61. 4. Stutzke, Richard D., “Software Estimating Technology: A Survey,” Crosstalk, STSC, Hill Air Force Base, Utah, May 1996, pp. 17-22. 5. Pfleeger, Shari Lawrence, “Measuring Reuse: A Cautionary Tale,” IEEE Software, July 1996, pp. 118-127. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 132 Appendix F: Software Reuse Study Report—A Report for the NASA IV&V Facility After the team completed this study, the team became aware of a software reuse study that was developed for the NASA Independent Verification and Validation (IV&V) Facility. That study and report were done by a company called TMC Technologies. The PI gave a presentation about the report at the IV&V Facility in Fairmont, West Virginia, in August 2005. That presentation and report provided important results that needed to be discussed herein. The NASA POC for the report, Gerald Gilley, graciously provided soft copies of that report to this study team. This appendix provides a summary of that report and its impact on this software reuse study (TMC, 2005). TMC undertook their reuse project for the NASA IV&V Facility to determine the impact of using legacy software on NASA spacecraft, and to help mitigate the risks of using legacy spacecraft software. The project was in four phases. The purpose of the Phase 1 study was to document the “as-is” state of NASA legacy spacecraft flight-software reuse. They reviewed literature on software reuse, and interviewed NASA IV&V personnel. TMC’s literature review led to definitions of different kinds of reuse: ad hoc, which is unplanned reuse of artifacts, also known as accidental reuse; opposed to that is systematic reuse, which is planned from reusable software components; black-box reuse is where components are reused unmodified, as opposed to white-box reuse, where the components are modified in the new use. (Frakes, Williams, and Terry, 1996; Poulin, 1997; Reifer, 1997). TMC’s literature review included mention of the regulations as described in Chapter 12 of FAA Order 8110.49, Software Approval Guidelines, June 2003, for reusable software components. Reusable components may be approved for integration in a larger system if “there is no adverse effect on original system safety margins, and 2) there is no adverse effect on original operational capability UNLESS accompanied by a justifiable increase in safety.” There is also an FAA Advisory Circular AC 20-148, Reusable Software Components, December 2004, supplementing FAA Order 8110.49. This advisory suggests a process that developers and integrators could follow to receive FAA acceptance of reusable software components. It also addresses reverification, and changes to reusable components; that is, how white-box reuse affects certification of the component. TMC’s literature review concluded with the following factors that seem to contribute to successful reuse projects (Joos, 1994; Morisio, Ezran, and Tully, 2002; Griss and Wosser, 1995): • Top management involvement and support • Changing the organization’s culture to reuse • Reuse-driven incentives • Training on reuse • Use of standards CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 • Reuse within a well-defined domain • A library or centralized component repository • Reuse related tools • Well-defined software engineering methods Revision: 0 Page 133 The TMC report noted that loss of Mars Climate Orbiter was in part due to reusing its “Small Forces File,” which was in English units, while introducing a new vendor-supplied thruster equation, which returned data in metric units. This led them to consider the following questions: • Could the NASA IV&V facility have found the problems that resulted in the catastrophic loss, had the mission gone through their IV&V process? • Could proper reuse practices have prevented the loss? • Were contextual changes properly accounted for in the reuse scenario? The approach to answering these questions was to study the state-of-the-practice of software reuse in order to mitigate risk and increase benefits. TMC investigated 23 missions looked at by the IVV Facility: 19 IV&V efforts and 4 Independent Assessment efforts, and interviewed 12 IV&V project managers. They did not have access to the software developers. One result of the project manager interviews was that there were no standard definitions of software reuse among the project managers. For example, some defined reuse as black-box reuse, while another allowed up to 25% modifications from a previous mission. There were also no standard metrics for measuring the extent of software reuse on a NASA mission: some measured lines-of-code reused, while others counted the number of unmodified modules. The managers themselves did not measure software reuse; they accepted the claims of the software developers. Similarly, there was no standard approach among developers to implement reuse. Reuse claims were often overestimated and unjustified. For example, it appears that the amount of reuse is usually less than what is estimated at the beginning of the project. Also, the amount of rework needed for that reused code is usually more than what is estimated at the onset of the project: 6 out of 7 projects investigated required more changes to reused software than was originally anticipated. A focus of the report was on how reuse affected the use of IV&V. It was found that the reused portions of the software undergo the same IV&V activities, usually in less depth, but not always: one manager experienced the same or increased level-of-effort on the IV&V of reused software. The amount of IV&V is based on the criticality of the component, not on reuse. They found inconsistency or contradiction in the IV&V opinion on the impact of reuse on cost, schedule, and risk. This finding is important: Risk of failure is another factor that can be linked to NASA software reuse claims. Project Managers think that risk impact depends on various factors like component modification, quality of the interface analysis, changes in context, and whether the parent mission underwent IV&V at the IV&V facility or not. In most cases, they CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 134 believe software reuse elevated the mission's risk because it was white-box, the documentation supporting the reuse was not provided, and the legacy software was usually not IV&V’ed and sometimes software claimed heritage was not even flown (TMC, 2005). TMC’s report recommended standards for both the developer and the IV&V practitioner, imposing limits on what should and should not be considered as valid reuse, which would allow a more consistent sharing of experiences and lessons learned from manager to manager. The report developed 10 genealogies of missions interrelated by reuse of artifacts. GN&C and C&DH were the two most commonly reused subsystems. Source code and requirements were the most commonly reused software artifacts. Only one genealogy involved systematic reuse. One of them involved parallel evolution of missions, where the missions’ software was exchanged while both missions’ software was being developed. It was thought this would confuse the development teams’ reuse strategy and its impact on risk. The level-of-risk of reuse was believed to be impacted by whether the missions involved had the same context, that is, involved similar space science goals such as exploring planets, or deep space, or the Sun. The TMC team recommends further study to identify patterns that could help mitigate the risks of software reuse in NASA spacecraft systems. In particular, the team recommends a more extensive study of projects where reuse was systematic to determine if these have fewer reuserelated problems. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 135 Appendix G: Quantitative Benefits Achieved through Software Reuse This is a verbatim excerpt, with format changes, from “Software acquisition gold practice ™ assess reuse risks and costs,” Available http://www.goldpractices.com/practices/arrc/index.php [Poulin, 1997], [Putnam, 2003], [Leach, 1997] and [Lim, 1998] have reported some of the quantitative benefits achieved through software reuse: • Nippon Electric Company: Achieved 6.7 times higher productivity and 2.8 times better quality through 17% reuse. They improved software quality 5-10 times over a 7-year period through the use of unmodified reuse components in the domain of basic system software development and in the domain of communication switching systems. • GTE Corporation: Saved $14 million in costs of software development with reuse levels of 14%. GTE Data Services benefited from $1.5M in cost savings in 1988 for 20–50% reuse. • Multiple Ada Projects: A study of 75 Ada projects in 15 firms totaling 30M LOC found reuse resulted in 10 times higher quality with reuse levels of 10-18%. • Toshiba saw a 20–30% reduction in defects per line of code with reuse levels of 60%. • DEC reported cycle times that were reduced by a factor of 3–5 through reuse levels of 50–80% and an increase of 25% in productivity through software reuse. • Hewlett-Packard (HP) cited quality improvement on two projects of 76% and 24% defect reduction, 50% and 40% increases in productivity, and a 43% reduction in time to market with reuse levels up to 70%. ROI ranged from 215% for one development to 410% for the other. • Raytheon achieved a 50% productivity increase in the MIS domain from 60% reuse using COBOL. • A study of nine companies showed reuse led to 84% lower project costs, cycle time reduction of 70%, and reduced defects. • 312 projects in aerospace industry: [“Showed an”] average 20% increase in productivity; 20% reduction in customer complaints; 25% reduction in time to repair; 25% reduction in time to produce the system. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 136 • Japanese industry study: 15–50% increase in productivity; 20–35% reduction in customer complaints; 20% reduction in training costs; 10–50% reduction in time to produce the system. • Simulator system developed for the US Navy: Increase of approximately 200% in number of SLOC produced per hour. • NASA Report: Reduction of 75% in overall development effort and cost. • AT&T reported a 50% decrease in time-to-market for 40–90% reuse. • Raytheon Missile Systems experienced a 1.5 times increase in productivity from 40– 60% reuse. • SofTech had a 10-to-20 times increase in productivity for reuse greater than 75%. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 137 Appendix H: Recommended Online Reading This is a verbatim excerpt with format changes from resources cited in http:// www.goldpractices.com/practices/arrc/index.php. Defense Information Infrastructure (DII) Common Operating Environment (COE) Upon successful login, you can view information on COE Releases, download COE Reference Materials, request COE Security Products, and interact with COE developers through the COE Forums. URL: https://coe.mont.disa.mil/login/login.asp Reuse Home Page The Reuse Group is comprised of experienced professionals with extensive expertise in establishing successful software reuse programs in major corporations. Its mission is to enable organizations to reduce time-to-market while improving system quality and organizational productivity through the systematic institutionalization of reuse practices. They emphasize a pragmatic approach to implementing and improving a reuse program. URL: http://www.reuse.com/ Software Dioxide: Reuse A portal into numerous software reuse resources, including papers and tech reports; books and publications; experts; conferences and seminars; tools; best practices; news and FAQs. URL: http://www.softwaredioxide.com/Channels/Reuse.asp?CDParent=Reuse Reusable Software Research Group (RSRG) The work of the group deals with the disciplined engineering of component-based software systems and the software components (a.k.a. reusable software components) from which they can be built. RSRG’s “home base” is The Ohio State University, and the information accessible through the links on this site deals primarily with OSU RSRG work. URL: http://www.cse.ohio-state.edu/rsrg/index.html Software Reuse: Acquisition Community Connection at Defense Acquisition Univ. (DAU) A group of questions and responses compiled on the topic of Software Reuse. CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 138 URL: http://acc.dau.mil/simplify/ ev.php? URL_ID=1491&URL_DO=DO_TOPIC&URL_SECTION=201&reload Software Program Manager’s Network (SPMN)—Assess Reuse Risks and Costs The SPMN mission is to identify proven industry and government software best practices and convey them to managers of large-scale software-intensive acquisition programs. URL: http://www.spmn.com/16CSP.html#reuse Software Productivity Consortium (SPC) The purpose of the Software Productivity Consortium is to o serve its members, affiliates, and the national interest by providing highly leveraged system and software technology and services to increase productivity, profitability, and competitiveness. Through membership, it offers several reports, tools, etc., in the area of software reuse. URL: http://www.software.org/ Lombard Hill Group The Lombard Hill Group mission is to enable organizations to reduce time-to-market while improving system quality and organizational productivity through the systematic institutionalization of reuse practices. URL: http://www.lombardhill.com Data and Analysis Center for Software (DACS) Risk Management Topic Area This site contains hyperlinks that deal with DoD Risk Management resources; case studies; education, training and conferences; experts; literature; related sites; service providers; and tools and methods. URL: http://www.dacs.dtic.mil/databases/url/key.hts?keycode=270 Data and Analysis Center for Software (DACS) Reuse of Software Assets Topic Area This site contains hyperlinks that are dedicated to the DoD Software Vision and Strategy, as well as citations and abstracts of literature related to the reuse of software architectures and product lines. URL: http://www.thedacs.com/databases/url/key.hts?keycode=15 CONSTELLATION PROGRAM SYSTEMS ENGINEERING CONSTELLA NEERING Title: Strategy for Software Reuse Study Final Report Document No.: AC1L1-52 Effective Date: October 1, 2005 Revision: 0 Page 139 The DACS “Formal Risk Management” Gold Practice™ This is one of a number of practices that form part of the DACS Gold Practice initiative, which strives to promote the understanding and effective use of software acquisition and development methodologies and processes. URL: http://www.goldpractices.com/practices/frm/index.php View publication stats