University of Southern California
Center for Systems and Software Engineering
Incremental Commitment Spiral Model:
Phases and Stages
Common Cases
Jo Ann Lane
CSSE Annual Research Review, April 29, 2014
jolane@usc.edu,
http://csse.usc.edu
University of Southern California
Center for Systems and Software Engineering
Part II Outline
• ICSM Stages and Phases
• ICSM Common Cases
• Medical First Responder System (MedFRS)
example
April 2014
Copyright © USC-CSSE
2
University of Southern California
Center for Systems and Software Engineering
The Incremental Commitment Spiral Process: Phased View
Anchor Point
Milestones
Synchronize, stabilize concurrency via FEDs
Risk patterns
determine life
cycle process
April 2014
Copyright © USC-CSSE
3
University of Southern California
Center for Systems and Software Engineering
ICSM Stages and Phases
• Stage I: System definition
– Exploration Phase: Concurrently identifies and clarifies
system capability needs, constraints, and candidate solution
options
– Valuation Phase: Analyzes alternative solutions and
identifies preferred alternative
– Foundations Phase: Develops management and technical
foundations for the selected alternative
• Stage II: Incremental development
– Development Phase: Procurement, iterative detailed design
and development, integration, and test of currentincrement components
– Production and Operations Phase: System “units”
produced, integrated, and put into operations
April 2014
Copyright © USC-CSSE
4
University of Southern California
Center for Systems and Software Engineering
ICSM Phase Detailed
Descriptions
April 2014
Copyright © USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
What the ICSM Book Has to Say
About Each Phase
•
•
•
•
•
•
•
What it is
Questions to guide phase activities
Potential pitfalls during phase
Major risks to watch for
How phase scales from small to large/complex
Role of principles in phase
MedFRS example activities and decisions
April 2014
Copyright © USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
Questions To Guide Phase Activities
•
•
•
•
•
•
Engineering technical activities
“ility” trades
Aspects of potential pitfalls and risks
Feasibility evidence
Potential cost/schedule issues
Stakeholders
April 2014
Copyright © USC-CSSE
7
University of Southern California
Center for Systems and Software Engineering
Example Questions To Guide Phase Activities
• Exploration
– What is the real need? Who wants it and why?
– Who is/are the key proponent(s)? Opponent(s)?
– How strong is the business case? What is the expected
market share?
• Valuation
– Will less extreme performance/capability suffice?
– If so, what are the various levels of acceptability?
– If innovation or new technologies required, what is current
status?
• Foundations
– What is the status of desired innovations or new
technologies?
– Have they been sufficiently matured, or should alternatives
be considered?
April 2014
Copyright © USC-CSSE
8
University of Southern California
Center for Systems and Software Engineering
Example Questions To Guide Phase Activities
(continued)
• Development:
– Hardware: What are the size, weight, power, etc.
constraints for hardware components? Who is responsible
for embedded FPGA code?
– Software: What are contingency plans for reusable
software that is found not to be as reusable as initially
planned?
– Integration: If recent COTS software upgrades have not
yet been incorporated, should they be incorporated or is
there risk of destabilizing the system?
• Production and operations:
–
–
–
–
What manufacturing is required for the new release?
When will spares be produced?
What user training is required?
What Help Desk training is required?
April 2014
Copyright © USC-CSSE
9
University of Southern California
Center for Systems and Software Engineering
ICSM as Risk-Driven Process Generator
• Stage I of the ICSM has 3 decision nodes with 4
options/node
– Culminating with incremental development in Stage II
– Some options involve go-backs
– Results in many possible process paths
• Can use ICSM risk patterns to generate frequentlyused processes
– With confidence that they fit the situation
• Can generally determine this in the Exploration
phase
– Develop as proposed plan with risk-based evidence at VCR
milestone
– Adjustable in later phases
April 2014
Copyright © USC-CSSE
10
University of Southern California
Center for Systems and Software Engineering
Different Risk Patterns Yield Different Processes
April 2014
Copyright © USC-CSSE
11
11
University of Southern California
Center for Systems and Software Engineering
ICSM Patterns: How Phases Can Be Combined
April 2014
Copyright © USC-CSSE
12
University of Southern California
Center for Systems and Software Engineering
Iterative and Incremental Development
Unforeseeable Change (Adapt)
Future Increment Baselines
Agile
Rebaselining for
Future Increments
Rapid
Change
Foreseeable
Change
(Plan)
Short
Development
Increments
Increment N Baseline
Stable Development
Increments
High
Assurance
Current V&V
Resources
Continuous V&V
April 2014
Deferrals
Short, Stabilized
Short, Stabilized
Development
Short, Stabilized
Development
of Increment
N
Developments
of Increment N
for Increment N
Artifacts
Operations and Maintenance
Concerns
Verification and
Validation (V&V)
of Increment N
Copyright © USC-CSSE
Increment N Transition/
Future V&V
Resources
13
University of Southern California
Center for Systems and Software Engineering
Unforeseeable Change (Adapt)
Foreseeable
Change
(Plan)
Short
Development
Increments
Increment N Baseline
Stable Development
Increments
High
Assurance
Current V&V
Resources
Continuous V&V
Deferrals
Short, Stabilized
Short,
Stabilized
Development
Short,
Stabilized
Development
of Increment
N
Developments
of Increment N
for Increment N
Artifacts
Increment N Transition/
Operations and Maintenance
Concerns
Verification and
Validation (V&V)
of Increment N
Future V&V
Resources
Unforeseeable Change (Adapt)
Foreseeable
Change
(Plan)
Short
Development
Increments
Current V&V
Resources
Continuous V&V
Short, Stabilized
Short,
Stabilized
Development
Short,
Stabilized
Development
of Increment
N
Developments
of Increment N
for Increment N
Artifacts
Increment N Transition/
Operations and Maintenance
Increment N Baseline
Stable Development
Increments
High
Assurance
Future V&V
Foreseeable
Change
(Plan)
Continuous V&V
Increment N Baseline
Stable Development
Increments
High
Assurance
April 2014
Current V&V
Resources
Continuous V&V
Deferrals
Short, Stabilized
Short,
Stabilized
Development
Short,
Stabilized
Development
of Increment
N
Developments
of Increment N
for Increment N
Artifacts
Deferrals
Short, Stabilized
Short,
Stabilized
Development
Short,
Stabilized
Development
of Increment
N
Developments
of Increment N
for Increment N
Artifacts
Increment N Transition/
Operations and Maintenance
Concerns
Verification and
Validation (V&V)
of Increment N
Future V&V
Resources
Unforeseeable Change (Adapt)
Future Increment Baselines
Agile
Rebaselining for
Future Increments
Short
Development
Increments
Current V&V
Resources
Resources
Unforeseeable Change (Adapt)
Rapid
Change
Short
Development
Increments
Foreseeable
Change
(Plan)
Concerns
Verification and
Validation (V&V)
of Increment N
Future Increment Baselines
Agile
Rebaselining for
Future Increments
Rapid
Change
Deferrals
Increment N Baseline
Stable Development
Increments
High
Assurance
Unforeseeable Change (Adapt)
Future Increment Baselines
Agile
Rebaselining for
Future Increments
Rapid
Change
Reality for
Large/Complex
Development
Future Increment Baselines
Agile
Rebaselining for
Future Increments
Rapid
Change
Increment N Transition/
Operations and Maintenance
Concerns
Verification and
Validation (V&V)
of Increment N
Future V&V
Resources
Foreseeable
Change
(Plan)
Short
Development
Increments
Increment N Baseline
Stable Development
Increments
High
Assurance
Unforeseeable Change (Adapt)
Future Increment Baselines
Agile
Rebaselining for
Future Increments
Rapid
Change
Current V&V
Resources
Deferrals
Short, Stabilized
Short,
Stabilized
Development
Short,
Stabilized
Development
of Increment
N
Developments
of Increment N
for Increment N
Artifacts
Increment N Transition/
Operations and Maintenance
Concerns
Verification and
Validation (V&V)
of Increment N
Future V&V
Resources
Copyright © USC-CSSE
Continuous V&V
Future Increment Baselines
Agile
Rebaselining for
Future Increments
Rapid
Change
Foreseeable
Change
(Plan)
Short
Development
Increments
Increment N Baseline
Stable Development
Increments
High
Assurance
Current V&V
Resources
Continuous V&V
Deferrals
Short, Stabilized
Short,
Stabilized
Development
Short,
Stabilized
Development
of Increment
N
Developments
of Increment N
for Increment N
Artifacts
Increment N Transition/
Operations and Maintenance
Concerns
Verification and
Validation (V&V)
of Increment N
Future V&V
Resources
14
University of Southern California
Center for Systems and Software Engineering
ICSM COMMON CASES
April 2014
Copyright © USC-CSSE
15
University of Southern California
Center for Systems and Software Engineering
ICSM Common Cases
•
•
•
•
•
Software application or system
Software-intensive device
Hardware platform
Family of systems or product line
System of systems (SoS) or enterprisewide system
• Brownfield modernization
April 2014
Copyright © USC-CSSE
16
University of Southern California
Center for Systems and Software Engineering
Common Case Examples
System (or Subsystem) Is…
Use…
Examples
Software application/system
that executes on one or more
commercial hardware
platforms. It can be a standalone software system or a
constituent within one or more
systems of systems (SoS).
An object, machine, or piece of
equipment that is developed for
a special purpose and has
significant features provided by
software.
Vehicle (land, sea, air, or
space).
Software
application
or system
Cellphone app, business application or
system, military command-and-control
software system, pharmacy systems,
inventory management systems, computer
operating system software, database
management system
Softwareintensive
device
Computer.
Hardware
platform
Computer peripherals, weapons,
entertainment devices, health care devices
(including small robotics used in surgeries or
to assist injured people), GPS navigation
device, manufacturing tools
Small unmanned ground or air vehicle,
automobile, military jeep, tank, ship, airplane,
space shuttle, space station, Mars rover
Supercomputer, mainframe, server, laptop,
tablet, cellphone
April 2014
Hardware
platform
Copyright © USC-CSSE
17
University of Southern California
Center for Systems and Software Engineering
Common Case Examples (continued)
System (or Subsystem) Is…
Use…
Part of a set of systems that
Family of
are either similar to each other systems or
or interoperate with each other. product line
A new capability that will be
performed by more than one
interoperating system
System of
system or
enterprisewide systems
Refactoring or reimplementation of an older
legacy system or set of
systems
Brownfield
modernization
April 2014
Examples
Car models that share many core
components; interoperating back-office
systems such as billing, accounting,
customer care, pricing, and sales force
automation systems that share a
common underlying repository with
standard data definitions/formats for the
business domain and are provided by a
single vendor
Multiple interoperating systems that are
owned and managed by different
organizations—for example, navigation
systems that include airborne and land
systems that also interoperate with GPS
Incremental replacement of old, fragile
business systems with COTS products or
technology refresh/upgrading of existing
systems
Copyright © USC-CSSE
18
University of Southern California
Center for Systems and Software Engineering
Software Strategies
Name
Description
Architected
agile
Initial agile iteration focuses on software foundations and
architecture issues, then transitions to a purely agile process for
development of software capabilities
Software developed using purely agile methods with shortduration iterations, used after initial architected agile iteration or in
cases where the environment for the new software application is
well-definedfor example, a cellphone app with well defined
interfaces
Traditional software development process guided by detailed
plans and schedules, typically employing incremental or
evolutionary methods
Critical software system or subsystem, often containing securityor safety-relevant software or critical/high-precision algorithms
that must be rigorously developed, tested, and often certified
Software functionality provided through the integration of one or
more commercial off-the-shelf software components or software
services
Agile
Plan-driven
Formal
methods
COTS/services
April 2014
Copyright © USC-CSSE
19
University of Southern California
Center for Systems and Software Engineering
Software Strategy Selection
April 2014
Copyright © USC-CSSE
20
University of Southern California
Center for Systems and Software Engineering
ICSM Software Strategy Examples
Accounting Application
Simple Customer Business App
Size/Complexity: Small/low
Typical Change Rate/Month: Low
Criticality: High
NDI Support: NDI-driven architecture
Organizational Personnel Capability: NDIexperienced, medium to high
Size/Complexity: Small/low
Typical Change Rate/Month: Medium to high
Criticality: Medium
NDI Support: No COTS, development and target
environment well-defined
Organizational Personnel Capability: Agileready, domain experience high
Software Strategy: COTS
Software Strategy: Architected agile
Cellphone Feature
Security Kernel
Size/Complexity: Medium/medium
Typical Change Rate/Month: Medium to high
Criticality: Low
NDI Support: No COTS, development and
target environment well-defined
Organizational Personnel Capability: Agileready, domain experience high
Size/Complexity: Small/low
Typical Change Rate/Month: Low
Criticality: Extra high
NDI Support: No COTS, development and target
environment well-defined
Organizational Personnel Capability: Strong
formal methods experience
Software Strategy: Agile
Software Strategy: Formal methods
April 2014
Copyright © USC-CSSE
21
University of Southern California
Center for Systems and Software Engineering
ICSM and Brownfield Development
• Many process models are Greenfield-oriented
– Requirements→Design→Develop→Test→Operate
• Failed Greenfield project example
– Corporate central financial system
– To replace spaghetti-code collection of COBOL
programs
• Alternative ICSM Brownfield approach
– Concurrent new-system definition and legacy
system re-engineering
April 2014
Copyright © USC-CSSE
22
University of Southern California
Center for Systems and Software Engineering
Example: Failed Greenfield
Corporate Financial System
• Used waterfall approach
– Gathered requirements
– Chose best-fit ERP system
– Provided remaining enhancements
• Needed to ensure continuity of service
– Planned incremental phase-in of new services
• Failed due to inability to selectively phase
out legacy services
– Dropped after 2 failed tries at cost of $40M
April 2014
Copyright © USC-CSSE
23
University of Southern California
Center for Systems and Software Engineering
Legacy Systems Patched, Highly Coupled
Financial and Non-Financial Services
Legacy Business Services
Project Services
Contract Services
Deliverables
Management Billing
Staffing
Budgeting
Work Breakdown Structure
Earned Value Management
Subcontracting
Scheduling
Progress Tracking
Change Tracking
Reqs, Configuration Management
April 2014
Copyright © USC-CSSE
24
University of Southern California
Center for Systems and Software Engineering
Result of Legacy Re-engineering
Legacy Business Services
Contract Services
Contract
Financial
Services
•Billing
•Subcontract
payments
•...
April 2014
Contract NonFinancial
Services
•Deliverables
mgmt.
•Terms
compliance
•...
Project Services
General
Financial
Services
•Accounting
•Budgeting
•Earned
value
•Payroll
•...
General NonFinancial
Services
•Progress
tracking
•Change
tracking
•...
Copyright © USC-CSSE
Project
Financial
Services
•WBS
•Expenditure
categories
•...
Project NonFinancial
Services
•Scheduling
•Staffing
•Reqs CM
•...
25
University of Southern California
Center for Systems and Software Engineering
ICSM Approach to Brownfield Engineering
• Understanding needs
– Analysis of legacy system difficulties
• Envisioning opportunities
– Concurrently decouple legacy financial and non-financial services,
explore new system phase-in and architecture options
• System scoping and architecting
– Extract legacy financial, non-financial services
– Prioritize, plan for incremental financial services phase-in/out
• Feasibility evidence development
– Successful examples of representative service extractions
– Evidence of cost, schedule, performance feasibility
• Works well when re-engineering/refactoring can be easily
achieved and parts can be incrementally replaced
– If not relatively easy, better to focus on capturing/restructuring
system data and migrating to replacement system
April 2014
Copyright © USC-CSSE
26
University of Southern California
Center for Systems and Software Engineering
Medical First Responder
System Example
University of Southern California
Center for Systems and Software Engineering
MedFRS Scenario
• Ensayo (small urban, semi-rural area) needs
– Improve trauma patient outcomes
– Simplify/consolidate multitude of first responder systems on
ambulances
– Provide flexibility to provide first responder systems on other
platforms
• Initial vision
– Upgrade communications between ambulances and trauma
centers
– Incorporate telemedicine capabilities on ambulances
– Migrate to a common electronic health record (EHR) system
across platforms and sites
– Provide high level of patient privacy and safety
– Integrate new technologies once approved for general use
April 2014
Copyright © USC-CSSE
28
University of Southern California
Center for Systems and Software Engineering
MedFRS Stage/Phase Discussions
• ICSM principles as applied to the phase
• Activities, including feasibility analysis
• Summary of phase
–
–
–
–
–
–
–
–
April 2014
Objectives and business case
Constraints
Alternatives
Risks
Risk mitigation
Risk resolution results
Plan for next phase
Commitment
Copyright © USC-CSSE
29
University of Southern California
Center for Systems and Software Engineering
MedFRS Exploration
Initial Vision
1st Increment at End of Exploration
•
•
•
•
•
•
•
•
Upgrade/expansion of comms
systems capabilities
Upgrade and integration of
medical devices on ambulances
Standard electronic health
records across all ambulances,
trauma centers, and hospitals
Telemedicine capability
Improved patient safety and
privacy
Learning capability for improved
patient care
Incorporation of new devices
(e.g., smart stents) once
approved
April 2014
•
•
•
Integrated first responder medical systems,
connecting a variety of medical devices and
telemetry systems, to initially include cardiac
monitors, blood pressure monitors,
defibrillators, pulse oximeters, and
intravenous (IV) infusion pump monitors
using standard interfaces
Transmit patient information to the trauma
center using current communications
systems and transition to standard EHR as
soon as possible
Improved patient privacy and safety
Future:
• Telemedicine capability
• Upgraded comms
• New devices such as smart stents
• Retina authentication to systems
• Learning capability
Copyright © USC-CSSE
30
University of Southern California
Center for Systems and Software Engineering
MedFRS Valuation
1st Increment at End of Exploration
1st Increment at End of Valuation
•
•
•
•
•
Integrated first responder medical
systems, connecting a variety of medical
devices and telemetry systems, to initially
include cardiac monitors, blood pressure
monitors, defibrillators, pulse oximeters,
and intravenous (IV) infusion pump
monitors using standard interfaces
Transmit patient information to the trauma
center using current comms system and
transition to standard EHR as soon as
possible
Improved patient privacy and safety
Future:
• Telemedicine capability
• Upgraded comms
• New devices such as smart stents
• Retina authentication to systems
• Learning capability
April 2014
•
•
•
•
Integrated first responder medical systems
to be provided by single cardiac monitor,
blood pressure monitor, defibrillator, pulse
oximeter system and an IV infusion pump
system
Camera to provide patient images to
trauma center
Transmit patient information and images to
the trauma center using upgraded comms
system
Improved patient privacy and safety
Future:
• Telemedicine capability to replace
camera
• Standard EHR
• New devices such as smart stents
• Retina authentication to systems
• Learning capability
Copyright © USC-CSSE
31
University of Southern California
Center for Systems and Software Engineering
MedFRS Foundation
1st Increment at End of Valuation
1st Increment at End of Foundations
•
•
•
•
•
•
Integrated first responder medical
systems to be provided by single
cardiac monitor, blood pressure
monitor, defibrillator, pulse oximeter
system and an IV infusion pump
system
Camera to provide patient images to
trauma center
Transmit patient information and
images to the trauma center using
upgraded comms system
Improved patient privacy and safety
Future:
• Telemedicine capability to replace
camera
• Standard EHR
• New devices such as smart stents
• Retina authentication to systems
• Learning capability
April 2014
•
•
•
•
Vendors selected for compatible
ruggedized laptop, single cardiac monitor,
blood pressure monitor, defibrillator, pulse
oximeter system, IV infusion pump system,
and camera
Comms updated in single ambulance and
systems checked out on board to determine
desired ambulance configuration, tuning,
user training, and impacts to patient
outcomes
configuration, tuning, and user training
Software design developed to fully integrate
systems
Future:
• Telemedicine capability to replace
camera
• Standard EHR
• New devices such as smart stents
• Retina authentication to systems
• Learning capability
Copyright © USC-CSSE
32
University of Southern California
Center for Systems and Software Engineering
MedFRS Development
1st Increment at End of Foundations
1st Increment at End of Development
•
•
•
•
•
Vendors selected for compatible
ruggedized laptop, single cardiac monitor,
blood pressure monitor, defibrillator, pulse
oximeter system, IV infusion pump
system, and camera
Comms updated in single ambulance and
systems checked out on board to
determine desired ambulance
configuration, tuning, user training, and
impacts to patient outcomes
Software design developed to fully
integrate systems and patient information
Future:
• Telemedicine capability to replace
camera
• Standard EHR
• New devices such as smart stents
• Retina authentication to systems
• Learning capability
April 2014
•
•
•
•
•
•
Hardware configuration/installation plans
complete
Integration and user interface software
developed and tested
Improved patient privacy and safety
confirmed through prototype on first
ambulance
Transition plans/schedules to upgrade
ambulances and train users (ambulances
and trauma centers)
User help desk plans established
Plans for 2nd increment
Future:
• Telemedicine capability to replace
camera
• Standard EHR
• New devices such as smart stents
• Retina authentication to systems
• Learning capability
Copyright © USC-CSSE
33
University of Southern California
Center for Systems and Software Engineering
MedFRS Production and Operations
1st Increment at End of Development
1st Increment at End of Productions
and Operations
•
•
•
•
•
•
•
•
•
Hardware configuration/installation plans
complete
Integration and user interface software
developed and tested
Improved patient privacy and safety
confirmed through prototype on first
ambulance
Transition plans/schedules to upgrade
ambulances and train users (ambulances
and trauma centers)
User help desk plans established
Plans for 2nd increment
Future:
• Telemedicine capability to replace
camera
• Standard EHR
• New devices such as smart stents
• Retina authentication to systems
• Learning capability
April 2014
•
•
•
•
Hardware procured including spares
All ambulances and trauma centers
upgraded with new systems (hardware
and software)
Users trained “just in time” using “spares”
as each platform upgraded
Help desk established
Plans for 2nd increment implemented
Still to come:
• Telemedicine capability to replace
camera
• Standard EHR
• New devices such as smart stents
• Retina authentication to systems
• Learning capability
Copyright © USC-CSSE
34
University of Southern California
Center for Systems and Software Engineering
April 2014
Copyright © USC-CSSE
35
University of Southern California
Center for Systems and Software Engineering
Backup Slides
April 2014
Copyright © USC-CSSE
36
University of Southern California
Center for Systems and Software Engineering
Exploration
Activities
•
•
Proposal/white paper
explaining need and
context for need
Inputs
•
•
•
•
Clarify and assess
need/potential benefits
Conduct gap analysis
against existing
capabilities
Develop initial concept
description
Identify potentially
feasible alternatives for
further analysis
Capture risks and
develop mitigation
plans
Entry Criteria
•
•
•
April 2014
Identified need
Proponent(s) for need
Budget for exploration
activities
•
•
•
•
•
Initial concept
description
Business case for need
List of feasible
alternatives for further
analysis
Key risks and mitigation
plans
Guidelines/needed
budget for further
analysis
Outputs
Exit Criteria
•
Decision to provide resources to
conduct further evaluation of
potential alternatives or decision
to discontinue
Copyright © USC-CSSE
37
University of Southern California
Center for Systems and Software Engineering
Valuation
Activities
•
•
•
•
•
Guidelines identified in
Exploration phase
Initial concept
description
Business case for need
List of potentially
feasible alternatives for
further analysis
Risk list and mitigation
plans
Inputs
•
•
•
•
•
•
Refine and implement
valuation plan developed in
Exploration phase
Monitor changes in
needs/opportunities/ risks
Adapt plans to address
identified changes
Evaluate results of valuation
activities
Develop foundations strategy
and plans
Update risks and risk
mitigation plans
•
April 2014
•
•
•
Analysis of any
prototypes
Updated risks and
mitigation plans
Approved Foundations
strategy plan
Key stakeholder
commitments/ MOAs
Outputs
Exit Criteria
Entry Criteria
•
•
Decision to conduct further
evaluation of potential
alternatives
Budget for Valuation
activities
•
Decision to provide resources to
proceed to Foundations Phase
or decision to discontinue
Copyright © USC-CSSE
38
University of Southern California
Center for Systems and Software Engineering
Activities
Foundations
•
•
•
•
•
Analysis/results of any
Valuation prototypes
Key risks and mitigation
plans
Approved Foundations
strategy plan
Key stakeholder
commitments/ MOAs
Inputs
•
•
•
•
•
•
Ensure technology readiness
for needed capabilities
Monitor changes in
needs/opportunities/ risks
Prototype and evaluate
various alternatives
Select acquisition/
development strategies
Prioritize features/
requirements for development
Develop plan for development
based upon prioritization
Update risks and risk
mitigation plans
•
April 2014
•
•
•
•
•
List of approved
features/requirements
allocated to components or
configuration items
Approved Development plan
Feature allocation to
increments
Updated risks and mitigation
plans
Updated stakeholder
commitments/ MOAs
Requests for proposals for
outsourced development
Outputs
Exit Criteria
Entry Criteria
•
•
•
Decision to develop
necessary foundations
Budget for Foundations
activities
Copyright © USC-CSSE
Decision to provide resources to
proceed to Development Phase
or decision to discontinue
39
University of Southern California
Center for Systems and Software Engineering
Activities
Development
•
•
•
•
•
•
•
•
List of approved
features/requirements
Problems reported against
currently deployed system
Approved changes
Approved Development plan
Feature allocation to
increments
Updated risks and mitigation
plans
Updated stakeholder
commitments/ MOAs
Proposals for outsourced
development
Inputs
Initial increment:
• Set up development environments
• Develop detailed design
• Select hardware, COTS products,
and outsource vendors
• Update Foundations as needed
based on selections
All increments (in accordance with
plan)
• Update detailed design
• Procure/develop/integrate hardware
components
• Develop/procure/integrate software
features/requirements according to
development plan
• Monitor changes in
needs/opportunities/ risks
• Update Foundations as needed
• Conduct continuous V&V
• Update approved features, risks,
and mitigations at end of each
increment
April 2014
System ready for
production/deploym
ent
Outputs
Exit Criteria
Entry Criteria
•
•
•
•
Decision to develop increment
Budget for increment
Development activities
Copyright © USC-CSSE
Decision to either proceed with
production/operations or discontinue
40
University of Southern California
Center for Systems and Software Engineering
Activities
Production
•
•
Approved production
plans
Inputs
•
•
•
•
Acquire/establish
production or
manufacturing facilities
and resources
Produce system units in
accordance with approved
production plans/orders
Develop maintenance
strategies and plans for
system
Produce user information /
training materials
Produce help desk support
materials
Entry Criteria
•
April 2014
Production budget
•
•
•
•
System units ready for
operations
User information/training
materials
Help desk materials and
training
Maintenance and
logistics plans
Outputs
Exit Criteria
•
Copyright © USC-CSSE
Production for current system
version complete
41
University of Southern California
Center for Systems and Software Engineering
Operations
and Support
•
•
•
Approved operations
and support plans
System updates
Help desk updates
Inputs
Activities
•
•
•
•
Distribute and support
system units and
components in accordance
with approved plans
Distribute and support
approved system changes
in accordance with
approved plans
Operate system help desk
and provide user assistance
as requested
Triage user problem reports
and change requests and
forward to Development as
needed
Entry Criteria
•
April 2014
Operations and support
budget
•
•
Support:
• Problem reports to
be resolved
• Change requests for
implementation
consideration
End of life:
• Authorization to
replace, retire or
dispose of system
Outputs
Exit Criteria
•
Copyright © USC-CSSE
End of life: decision to replace,
retire, dispose of system, or no
longer support system (or
system version)
42
University of Southern California
Center for Systems and Software Engineering
List of Acronyms
B/L
C4ISR
CD
CDR
COTS
DCR
DI
DoD
ECR
EVMS
FCR
FED
FMEA
FRP
GAO
GUI
April 2014
Baselined
Command, Control, Computing, Communications, Intelligence, Surveillance,
Reconnaissance
Concept Development
Critical Design Review
Commercial Off-the-Shelf
Development Commitment Review
Development Increment
Department of Defense
Exploration Commitment Review
Earned Value Management System
Foundations Commitment Review
Feasibility Evidence Description
Failure Modes and Effects Analysis
Full-Rate Production
Government Accountability Office
Graphical User Interface
Copyright © USC-CSSE
43
University of Southern California
Center for Systems and Software Engineering
List of Acronyms
HMI
HSI
HW
ICSM
IOC
IRR
IS&SE
LCO
LRIP
MBASE
NDI
NRC
OC
OCR
OO&D
OODA
O&M
April 2014
(continued)
Human-Machine Interface
Human-System Interface
Hardware
Incremental Commitment Model
Initial Operational Capability
Inception Readiness Review
Integrating Systems and Software Engineering
Life Cycle Objectives
Low-Rate Initial Production
Model-Based Architecting and Software Engineering
Non-Developmental Item
National Research Council
Operational Capability
Operations Commitment Review
Observe, Orient and Decide
Observe, Orient, Decide, Act
Operations and Maintenance
Copyright © USC-CSSE
44
University of Southern California
Center for Systems and Software Engineering
List of Acronyms
PDR
PM
PR
PRR
RUP
SoS
SoSE
SSE
SW
SwE
SysE
Sys Engr
S&SE
USD (AT&L)
VCR
V&V
WBS
WMI
April 2014
(continued)
Preliminary Design Review
Program Manager
Public Relations
Product Release Review
Rational Unified Process
System of Systems
System of Systems Engineering
Systems and Software Engineering
Software
Software Engineering
Systems Engineering
Systems Engineer
Systems and Software Engineering
Under Secretary of Defense for Acquisition, Technology, and Logistics
Validation Commitment Review
Verification and Validation
Work Breakdown Structure
Warfighter-Machine Interface
Copyright © USC-CSSE
45