1 / 12

Acquisition Strategies

SAM Executive Seminar. Acquisition Strategies. George Prosnik DAU CDSC E&T Center. SW-CMM. ISO 15504. CMMI. ISO 12207. Industry “ Best Practices ”. Software Lifecycle Processes. EIA J-STD-016 IEEE 12207. “ACQUISITION STRATEGY”.

martha-potter
Download Presentation

Acquisition Strategies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SAM Executive Seminar Acquisition Strategies George Prosnik DAU CDSC E&T Center

  2. SW-CMM ISO 15504 CMMI ISO 12207 Industry “Best Practices” Software Lifecycle Processes EIA J-STD-016 IEEE 12207 “ACQUISITION STRATEGY” 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 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” Rev 1.1

  3. DT and OT&E Testing System SubsystemIntegrationandTesting System System Qualification Requirements Testing Analysis Sub Sys HIandSIIntegrationandTesting System Design Software SoftwareItemQualification SI SI HIs SI Requirements Testing Analysis Software Software SWUnitIntegration Units Software Units andTesting Software Units Design Software Software UnitTesting UnitCoding Systems & Software Development

  4. P R O C System Analysis E and Control S (Balance) S I N P U T S PROCESS OUTPUTS Example Systems Engineering Process Requirements Analysis Requirements Loop Functional Analysis & Allocation Design Loop Verification Loop Synthesis

  5. WaterfallParadigms IncrementalParadigms SpiralModels Grand Design P3I Acquisition Approach Evolutionary Software Development Paradigms System Acquisition Strategy Rev 5.0

  6. Single Development Increment REQUIREMENTS DESIGN CODE, TEST, DELIVER Turn-Key Operations Refine User Needs Grand Design (“Once Through”) Acquisition S Y S T E M User “Grand Design” Acquisition Strategies may be appropriate for software-intensive systems that are Precedented or monolithic but nevertheless are now strongly discouraged, Rev 4.2

  7. Operational Concepts Doctrine Acquisition Community Developed Technology Delivered Products 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 Operational Requirements System Requirements Operational Community

  8. Integrated Architecture System Requirements Doctrine Operational Community Acquisition Community Delivered Technology 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

  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. 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 PROs CONs 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 Software-Intensive Systems and P3I Acquisition Issues Longer Range Planning Form, Fit & Function Specs Generalized Architectures “Transportable” Software Standards & Interface Capacity Modular Equipment/Open Systems Rev 4.3

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

  12. 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 Lo Hi Hi Lo Risk-O-Meter Hi Lo Hi Lo Risk-O-Meter Risk-O-Meter Increment Requirements Increment Requirements Increment Requirements Increment Requirements Increment Requirements Increment Requirements Increment Requirements 1. 2. 3. 4. ● ● ● n. 1. 2. 3. 4. ● ● ● n. 1. 2. 3. 4. ● ● ● n. 1. 2. 3. 4. ● ● ● n. 1. 2. 3. 4. ● ● ● n. 1. 2. 3. 4. ● ● ● n. 1. 2. 3. 4. ● ● ● n. ? ? ? ? Prelim Design Prelim Design Prelim Design Prelim Design Prelim Design Prelim Design Detailed Design Detailed Design Detailed Design Detailed Design Detailed Design Detailed Design Code & Unit Test Code & Unit Test Code & Unit Test Code & Unit Test Code & Unit Test Code & Unit Test Integration Test Integration Test Integration Test Integration Test Integration Test Integration Test Qual Test Qual Test Qual Test Qual Test Qual Test Qual Test Deliver Deliver Deliver Deliver Deliver Deliver Priority vs Risk Requirements Matrix Production Process High Priority Low Risk High Priority High Risk Prelim Design Detailed Design Code & Unit Test Integration Test Qual Test Deliver

More Related