Software Acquisition ManagementSAM-450 EXEC SAM (1)

Acquisition Strategies

SAM Executive Seminar

George ProsnikDAU CDSC E&T Center

Software Acquisition ManagementSAM-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”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 12207ISO 15504 CMMI

EIA J-STD-016 IEEE 12207

Software Acquisition ManagementSAM-450 EXEC SAM (3)

Systems & Software DevelopmentSystems & Software Development

System

Sub Sys

SI

SoftwareUnits

SI

SoftwareUnits

SI

SoftwareUnits

HIs

SystemDesign

SoftwareRequirements

Analysis

SystemRequirements Analysis

SoftwareDesign

Software Unit Coding

SW Unit Integrationand Testing

SoftwareUnit Testing

Software Item Qualification Testing

HI and SI Integration and Testing

Subsystem Integration and Testing

System QualificationTesting

DT and OT&E Testing

Software Acquisition ManagementSAM-450 EXEC SAM (4)

PROCESS OUTPUTS

DesignLoopVerification

Loop

RequirementsLoop

Example Systems Engineering ProcessExample Systems Engineering Process

Requirements Analysis

Functional Analysis & Allocation

Synthesis

PROCESS

INPUTS

System Analysisand Control(Balance)

Software Acquisition ManagementSAM-450 EXEC SAM (5)

Rev 5.0

Grand Design

P3I

Evolutionary

SoftwareSoftwareDevelopmentDevelopment

ParadigmsParadigms

Waterfall Paradigms

Incremental Paradigms

Spiral Models

AcquisitionApproach

SystemAcquisitionStrategy

Software Acquisition ManagementSAM-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

SYSTEM

Single Development Increment

Grand Design (“Once Through”) AcquisitionGrand Design (“Once Through”) Acquisition

Rev 4.2

Refine User Needs Turn-Key OperationsREQUIREMENTS CODE, TEST, DELIVERDESIGN

Software Acquisition ManagementSAM-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

OperationalOperationalCommunityCommunity

AcquisitionAcquisitionCommunityCommunity

Operational Requirements

DoctrineDoctrine

OperationalOperationalConceptsConcepts

SystemSystemRequirementsRequirements

DeliveredDeliveredProductsProducts

DevelopedDevelopedTechnologyTechnology

Software Acquisition ManagementSAM-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

OperationalOperationalCommunityCommunity

AcquisitionAcquisitionCommunityCommunity

IntegratedIntegratedArchitectureArchitecture

SystemSystemRequirementsRequirements

DeliveredDeliveredTechnologyTechnology

DoctrineDoctrine

Software Acquisition ManagementSAM-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.

Software Acquisition ManagementSAM-450 EXEC SAM (10)

Acquisition IssuesLonger Range PlanningForm, Fit & Function SpecsGeneralized Architectures“Transportable” SoftwareStandards & Interface CapacityModular Equipment/Open Systems

Acquisition IssuesLonger Range PlanningForm, Fit & Function SpecsGeneralized Architectures“Transportable” SoftwareStandards & Interface CapacityModular 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 Software-Intensive Systems and

P3IP3IPROs

• 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

Software Acquisition ManagementSAM-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

CB . . . .

Define--$FUND$--Develop--Operationally Test CORE

Define--FUND--Develop--Operationally Test Block A

. . . . continue “as required”

C

Block A

B . . . .

CORE

Refine & UpdateRequirements

“Managed” User

Feedback

Rev 6.2

The lack of specificity anddetail in identifying the final

system capability is what distinguishes Evolutionary

Acquisition from an acquisition strategy based on P3I

Flexible/incremental funding, testing, etc..

Software Acquisition ManagementSAM-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 PriorityHigh Risk

High PriorityLow Risk

Lo Hi

Risk-O-MeterLo Hi

????

Risk-O-MeterLo Hi

Risk-O-MeterLo Hi

Priority vs Risk Requirements Matrix