1. Software Acquisition Management SAM-450 EXEC SAM (1) Acquisition Strategies SAM Executive Seminar George Prosnik DAU CDSC E&T Center

2. Software Acquisition Management SAM-450 EXEC SAM (2) Rev 1.1 A ROADMAP DEVELOPED BY THE PROGRAM MANAGER THAT GUIDES PROGRAM EXECUTION “FROM PROGRAM INITIATION THROUGH POST-PRODUCTION SUPPORT ESSENTIAL ELEMENTS SOURCES RISK MANAGEMENT COST PROFILES CONTRACT APPROACH MANAGEMENT APPROACH ENVIRONMENTAL CONSIDERATIONS SOURCE OF SUPPORT ACQUISITION APPROACH “ACQUISITION STRATEGY” PRIMARY GOAL IN DEVELOPING AN ACQUISITION STRATEGY “MINIMIZE THE TIME IT TAKES TO SATISFY AN IDENTIFIED NEED CONSISTENT WITH COMMON SENSE AND SOUND BUSINESS PRACTICE” SW-CMM Industry “Best Practices” Software Lifecycle Processes ISO 12207 ISO 15504 CMMI EIA J-STD-016 IEEE 12207

3. Software Acquisition Management SAM-450 EXEC SAM (3) Systems & Software Development System Sub Sys SI Software Units SI Software Units SI Software Units HIs System Design Software Requirements Analysis System Requirements Analysis Software Design Software Unit Coding SW Unit Integration and Testing Software Unit Testing Software Item Qualification Testing HI and SI Integration and Testing Subsystem Integration and Testing System Qualification Testing DT and OT&E Testing

4. Software Acquisition Management SAM-450 EXEC SAM (4) PROCESS OUTPUTS Design Loop Verification Loop Requirements Loop Example Systems Engineering Process Requirements Analysis Functional Analysis & Allocation Synthesis P R O C E S S I N P U TSTS System Analysis and Control (Balance)

5. Software Acquisition Management SAM-450 EXEC SAM (5) Rev 5.0 Grand Design P3I Evolutionary SoftwareDevelopmentParadigms Waterfall Paradigms Incremental Paradigms Spiral Models Acquisition Approach System Acquisition Strategy

6. Software Acquisition Management SAM-450 EXEC SAM (6) “Grand Design” Acquisition Strategies may be appropriate for software-intensive systems that are Precedented or monolithic but nevertheless are now strongly discouraged, User SYSTEMSYSTEM Single Development Increment Grand Design (“Once Through”) Acquisition Rev 4.2 Refine User Needs Turn-Key Operations REQUIREMENTSCODE, TEST, DELIVERDESIGN

7. Software Acquisition Management SAM-450 EXEC SAM (7) Requirements Change and System Acquisition Issue: Traditional acquisition processes emphasized sequential determination and satisfaction of requirements This resulted in an acquisition process that resisted and was vulnerable to change OperationalCommunity AcquisitionCommunity Operational RequirementsDoctrine OperationalConceptsSystemRequirements DeliveredProducts DevelopedTechnology

8. Software Acquisition Management SAM-450 EXEC SAM (8) Requirements Change and System Acquisition We must recognize that requirements WILL change over time The Requirements and Acquisition Processes can no longer be isolated from each other OperationalCommunity AcquisitionCommunity IntegratedArchitecture SystemRequirements DeliveredTechnology Doctrine

9. Software Acquisition Management SAM-450 EXEC SAM (9) Spiral and Incremental Development Approaches The approaches to achieve evolutionary acquisition require collaboration between the user, tester, and developer. They include: –Spiral Development. In this process, a desired capability is identified, but the end-state requirements are not known at program initiation. Those requirements are refined through demonstration and risk management; there is continuous user feedback; and each increment provides the user the best possible capability. The requirements for future increments depend on feedback from users and technology maturation. –Incremental Development. In this process, a desired capability is identified, an end-state requirement is known, and that requirement is met over time by developing several increments, each dependent on available mature technology.

10. Software Acquisition Management SAM-450 EXEC SAM (10) Acquisition Issues Longer Range Planning Form, Fit & Function Specs Generalized Architectures “Transportable” Software Standards & Interface Capacity Modular Equipment/Open Systems Acquisition Issues Longer Range Planning Form, Fit & Function Specs Generalized Architectures “Transportable” Software Standards & Interface Capacity Modular Equipment/Open Systems The P3I software acquisition management challenge is to acquire software with interfaces and accessibility as an integral part of the software design so that the deferred element(s) can be incorporated in a cost-effective manner when they become available CONs Software-Intensive Systems and P3I PROs Responsive to threat changes Accommodates future technology IOC can be earlier Reduced development risk Possible subsystem competition Increased effective operational life Responsive to threat changes Accommodates future technology IOC can be earlier Reduced development risk Possible subsystem competition Increased effective operational life Increased initial development cost Increased technical requirements –Memory utilization –Source code efficiency –Software “reliability” More complex CM Goldplating vulnerability Sensitive to funding streams Parallel development management Increased initial development cost Increased technical requirements –Memory utilization –Source code efficiency –Software “reliability” More complex CM Goldplating vulnerability Sensitive to funding streams Parallel development management Rev 4.3

11. Software Acquisition Management SAM-450 EXEC SAM (11) Classic Evolutionary Acquisition User Requirements General for the System Specific for the Core Concept of Operations Preliminary System Architecture CORE Block A C B.. Define-- $FUND$ --Develop--Operationally Test CORE Define-- FUND --Develop--Operationally Test Block A.... continue “as required” C Block A B.. CORE Refine & Update Requirements “Managed” User Feedback Rev 6.2 The lack of specificity and detail in identifying the final system capability is what distinguishes Evolutionary Acquisition from an acquisition strategy based on P3I Flexible/incremental funding, testing, etc..

12. Software Acquisition Management SAM-450 EXEC SAM (12) Production Process Series of incremental builds –Only high priority low risk requirements Use efficient build processes –Predictable cost and schedule Incorporate test & evaluation into each build –Deliver a reliable product 1. 2. 3. 4. ● n. Increment Requirements Prelim Design Detailed Design Code & Unit Test Integration Test Qual Test Deliver Prelim Design Detailed Design Code & Unit Test Integration Test Qual Test Deliver Prelim Design Detailed Design Code & Unit Test Integration Test Qual Test Deliver Prelim Design Detailed Design Code & Unit Test Integration Test Qual Test Deliver Prelim Design Detailed Design Code & Unit Test Integration Test Qual Test Deliver Prelim Design Detailed Design Code & Unit Test Integration Test Qual Test Deliver Prelim Design Detailed Design Code & Unit Test Integration Test Qual Test Deliver 1. 2. 3. 4. ● n. Increment Requirements 1. 2. 3. 4. ● n. Increment Requirements 1. 2. 3. 4. ● n. Increment Requirements 1. 2. 3. 4. ● n. Increment Requirements 1. 2. 3. 4. ● n. Increment Requirements 1. 2. 3. 4. ● n. Increment Requirements High Priority High Risk High Priority Low Risk Lo Hi Risk-O-Meter Lo Hi ? ? ? ? Risk-O-Meter Lo Hi Risk-O-Meter Lo Hi Priority vs Risk Requirements Matrix