Pittsburgh, PA 15213-3890 Sustaining Software-Intensive Systems - A Conundrum Mary Ann Lapham Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University Version 1 NDIA System Engineering Conference - page 1 Report Documentation Page Form Approved OMB No. 0704-0188 Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number. 1. REPORT DATE 3. DATES COVERED JAN 2005 2. REPORT TYPE 00-00-2005 to 00-00-2005 4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER Sustaining Software-Intensive Systems - A Conundrum 5b. GRANT NUMBER 5c. PROGRAM ELEMENT NUMBER 6. AUTHOR(S) 5d. PROJECT NUMBER 5e. TASK NUMBER 5f. WORK UNIT NUMBER 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION Carnegie Mellon University,Software Engineering REPORT NUMBER Institute,Pittsburgh,PA,15213 9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S) 11. SPONSOR/MONITOR’S REPORT NUMBER(S) 12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited 13. SUPPLEMENTARY NOTES 14. ABSTRACT 15. SUBJECT TERMS 16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF ABSTRACT OF PAGES RESPONSIBLE PERSON a. REPORT b. ABSTRACT c. THIS PAGE Same as 15 unclassified unclassified unclassified Report (SAR) Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18 Agenda What is Sustainment Software Entrance Criteria for Sustainment Top 10 Sustainment Challenges Examples of Challenges Conclusions © 2005 by Carnegie Mellon University Version 1 NDIA System Engineering Conference - page 2 What is Sustainment? Joint Publication 4-0 (Doctrine for Logistic Support of Joint Operations): “The provision of personnel, logistic, and other support required to maintain and prolong operations or combat until successful accomplishment or revision of the mission or the national objective” DoDI 5000.2: “The first effort of the Operations and Support (O&S) phase established and defined by DoDI 5000.2. The purpose of the sustainment effort is to execute the support program to meet operational support performance requirements and sustain the system in the most cost effective manner of its life cycle. Sustainment includes supply, maintenance, transportation, sustaining engineering, data management, Configuration Management (CM), manpower, personnel, training, habitability, survivability, environment, safety (including explosives safety), occupational health, protection of critical program information, anti-tamper provisions, and information technology (IT), including National Security Systems (NSS), supportability and interoperability functions. Sustainment overlaps the Full Rate Production and Deployment (FRP&D) effort of the Production and Deployment (P&D) phase.” © 2005 by Carnegie Mellon University Version 1 NDIA System Engineering Conference - page 3 Software Sustainment - Definition Software maintenance and software sustainment are often used interchangeably. We will make a distinction. Software Maintenance: “The process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment.” No definitive definition of software sustainment has been found, so our working definition is: Software Sustainment: “The processes, procedures, people, materiel, and information required to support, maintain, and operate the software aspects of a system.” © 2005 by Carnegie Mellon University Version 1 NDIA System Engineering Conference - page 4 Software Sustainment - Distinction Software maintenance consists of: • correcting the faults • improving performance or other attributes • adapting to a changed environment Software sustainment addresses other issues not always included in maintenance, such as: • operations • documentation • deployment • security • CM • training • help desk • COTS management • technology refresh © 2005 by Carnegie Mellon University Version 1 NDIA System Engineering Conference - page 5 Software Entrance Criteria for Sustainment Signed Source of Repair Assignment Process (SORAP) Completed Operational Test & Evaluation Stable software production baseline Complete current software documentation Authority to Operate (ATO) Sustainment Plan Current & negotiated sustainment transition plan Sustainment staff training plan Key: Good Caution Warning Critical Note: Based on SEI experience with actual programs © 2005 by Carnegie Mellon University Version 1 NDIA System Engineering Conference - page 6 Challenges Top 10 Sustainment Challenges Lack of funding for transition planning Lack of signed SORAP Unclear Information Assurance requirements to finalize ATO Unaddressed support database transition logistics Unclear COTS license management Sustainer inexperience with COTS-based systems Loss of key contractor staff and expertise Over reliance on contractor development processes and proprietary tools No formal training for sustainers Lack of parallel Sustainment/Development Management Plan © 2005 by Carnegie Mellon University Version 1 NDIA System Engineering Conference - page 7 Challenges Selected Examples of Challenges COTS Programmatic System Transition Information Assurance (IA) • Indicates Major Concern © 2005 by Carnegie Mellon University Version 1 NDIA System Engineering Conference - page 8 COTS Obsolescence & Upgrade Planning New complexity to handle Fielded System COTSVendors Instances Incremental system releases System • Demand Context for Simultaneous features Definition and Tradeoffs Marketplace Architecture & Design • System development • Unsupported releases • Tech refresh, RIP system sustainment • No market demand © 2005 by Carnegie Mellon University Version 1 NDIA System Engineering Conference - page 9