USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009
ICM-Sw and Large Systems
A. Winsor Brown
[email protected]
© 2009-2009 A W Brown BES/MSEE & USC CSE
81914659 – 1 of 48
v 0.2 04/02/00
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Goals of Presentation
You should get a working overview ICM-Sw beyond CS577
 What it is & how it works
 Principles behind it
You should learn about
 Applying ICM-Sw to a large [monolithic] software system
 Applying ICM-Sw to a [network centric?] System of Systems
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 2 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
ICM-Sw Invariants
1. Defining and sustaining a
stakeholder win-win
relationship through the
system's life-cycle.
2. Using the P3S Model
Integration Framework.
3. Using the P3S Process
Integration Framework.
4. Using the ECR(?), VCR, FCR,
DCR & TRR Anchor Point
milestones.
5. Ensuring that the content of
ICM-Sw artifacts and activities
is risk-driven.
[6. Uses concepts from 8 step
Sw Development Spiral Model]
© 2007-2017 A W Brown BES/MSEE & USC CSE
ICM-Sw Variants
1. Use of particular success, process,
product, or property models.
2. Choice of process or product
representation.
3. Degree of detail of process,
product, property, or success
modeling.
4. Number of spiral cycles or builds
between anchor points.
5. Mapping of activities onto
Exploration, Valuation, Foundations,
Construction & Transition phases.
6. Mapping of staff levels onto
activities.
81914659 – 3 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
P3S -- Model Framework
Business case
IKIWISI
Stakeholder win-win
Success models
Life cycle anchor
points
Risk management
Key practices
Process
entry/exit
criteria
Product
evaluation
criteria
Planning and control
Process models
Product models
Milestone content
Domain model
Requirements
Architecture
Code
Documentation
Evaluation and
analysis
Property models
Cost
Schedule
Performance
Reliability
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 4 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
P3S Model Integration Process
Stakeholders
Serve and Satisfy
Describe
enterprise
context in
Identify and
prioritize
Enable
satisficing
Success
M odels
Dom ain M odels
Set
context for
Contsrain
Provide
m easures
for
Provide
param eters for
Product
Models
Guide
developm ent
of
Property
M odels
Provide
param eters for
Process
Models
Constrain
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 5 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
ICM-Sw/RUP Activity/Process Model
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 6 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Anchor Points, Stages, Phases & Documentation
Risk-driven content of artifacts and activities.
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 7 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Stakeholder win-win relationship through the system's life-cycle; and Spiral Model
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 8 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
CS577 Software Systems
Characteristics
 Size
 ESLOC (equivalent [Logical] Source Lines of Code)
= 2 to 5K?
 2-3 person years of effort
 Domains
 eServices
 Tools
Examples
 Hunter-Gatherer Information Database
 Easily changed (by "owner") websites
 COINCOMO 2.0
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 9 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
CS577 Software Systems (cont.)
Prescribed IICM-Sw Variants (done before course started)
1. Particular models
 success: varies – grades; IKIWISI; knowledge; usable
software; business case; Stakeholder-WinWin
 process: [Lean] IICM-Sw/RUP; Results Chain; Quality
Mgt. (including IIV&V)
 product: use UML; prototypes; requirements [5 kinds]
 property models: COCOMO II (E&S); Gant & Pert;
parts of FED: ROI, EV, …
2. Choice of process or product representation.
3. Degree of detail of process, product, property, or success
modeling.
4. Number of spiral cycles or builds between anchor points.
5. Mapping of activities onto Exploration, Valuation, Foundations,
Construction and Transition phases.
6. Mapping of staff levels onto activities.
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 10 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
CS577 Software Systems (cont.)
Prescribed IICM-Sw Variants (cont.)
2. Choice of process or product representation.
 Process representation:
 Quality Assessment: ETVX; Presentation; …
 Development process(es): Microsoft Project; …
 Product representation:
 Options for OCD "Entity" Diagram
 RSM (UML) for A&D;
 Languages vary based on Win Conditions
 Build/Install mechanisms vary based on Win Conditions
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 11 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
CS577 Software Systems (cont.)
Prescribed IICM-Sw Variants (cont.)
3. Degree of detail of process, product, property, or
success modeling.
 Options specified in [Lean] IICM-Sw guidelines [EPG]
 Stakeholder must agreed to them
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 12 of 48
v1.0 - 07/29/17
USC
S E
C
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
CS577 Software Systems (cont.)
Prescribed IICM-Sw Variants (cont.)
4. Number of spiral cycles or builds between anchor points
for two
semester projects.
WinWin Spiral [cost not to scale]
ActivitiesinMapped
to Original
with
2 spirals
Exploration
andSpiral
Valuation
 2 or 3 spirals in Foundations
 2 spirals in Construction
 1/2 spiral in Transition
2
1b. Stakeholders Identify
System Objectives,
Constrains, & Priorities
(OC & P’s) Alternatives
Solutions Elements
Progress Through Steps
2a. Evaluate Alternatives
w ith respect to OC & P’s
First Semester
3
1
2b.
Assess,
Address
Risks
1a. Identify
Success-Critical
Stakeholders
Stakeholders’
8 Com m itm ent
7 Stakeholders’
I OC
CC D
L CA
4
L CO
Review
Early
Sect.
OCD
Mini
Spiral
Incep.
Elab.
Second Semester
?
Elab.
2
Full Spirals^: Three ARB's
Const.
to CCD
Summer
Const.
T* 1
to IOC
Transition with
lots of rework
Two Spirals^^: One TRR
* Transition 1: Only two weeks; at best, transition to a real client/sponsor
team.
^ Full spirals include all 8 steps, including stakeholder concurrence.
6
post LCA ARB
3. Elaborate
Product and
Process
Definition
CCD ARB
LCA ARB
^^ Risk driven selection of content of build up to CCD;
risk driven selection of second spiral.
Development management decisions with informal stakeholder concurrence about
what is in the "builds".
Stakeholder concurrence at the end of second spiral at the TRR;
4. Verify and Validate
Product and Process
Definitions
LCO ARB
5
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 13 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
IICM-Sw 577ab Lifecycle
First Semester
Early
Sect.
OCD
Mini
Spiral
Incep.
Elab.
Second Semester
?
Elab.
2
Full Spirals^: Three ARB's
Const.
to CCD
Const.
T* 1
to IOC
Summer
Transition with
lots of rework
Two Spirals^^: One TRR
* Transition 1: Only two weeks; at best, transition to a real client/sponsor
team.
^ Full spirals include all 8 steps, including stakeholder concurrence.
^^ Risk driven selection of content of build up to CCD;
risk driven selection of second spiral.
Development management decisions with informal stakeholder concurrence about
what is in the "builds".
Stakeholder concurrence at the end of second spiral at the TRR;
NOTEs: Four, Five or Six Anchor Points? Not all spirals
go to anchor points: What if it is NOT an anchor point?
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 14 of 48
v1.0 - 07/29/17
USC
C
University of Southern California
S E
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Spiral Model with ARBs for CS577
2
1b. Stakeholders Identify
System Objectives,
Constrains, & Priorities
(OC & P’s) Alternatives
Solutions Elements
Progress Through Steps
2a. Evaluate Alternatives
w ith respect to OC & P’s
3
1
2b.
Assess,
Address
Risks
1a. Identify
Success-Critical
Stakeholders
Stakeholders’
8 Com m itm ent
7 Stakeholders’
I OC
CC D
L CA
4
L CO
Review
6
post LCA ARB
3. Elaborate
Product and
Process
Definition
CCD ARB
LCA ARB
4. Verify and Validate
Product and Process
Definitions
LCO ARB
© 2007-2017 A W Brown BES/MSEE & USC CSE
5
81914659 – 15 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
IICM-Sw 577ab Lifecycle & Spiral Model
Is CCD an Anchor Point? Does it have an "ARB"?
How many spirals after DCR/LCA before TRR?
What is the "post DCR/LCA ARB"?
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 16 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
CS577 Software Systems (cont.)
Prescribed IICM-Sw Variants (cont.)
5. Mapping of activities onto Exploration, Valuation,
Foundations, Development [nee Inception, Elaboration,
Construction and Transition] phases:
 [Lean] IICM-Sw (RUP-like)
6. Mapping of staff levels onto activities.
 Per project; reviewed at ARB
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 17 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Outline
ICM-Sw Beyond CS577a
Applying ICM-Sw to a Large System
Applying ICM-Sw to a System of Systems
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 18 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Large Software Systems
Characteristics
 Size
 100s to 1000s KESLOC
(100Ks to Ms of Equivalent [Logical] Source Lines of Code)
 50s to 100s of person years of effort
 Types
 COTS
 Shrink-wrap products
 Custom development: Middle-ware; IT systems;
Embedded Real-time; Search Engines/Services; …
 Open Source
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 19 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Large Sw System ICM-Sw Selections
Product Model Representation UOSC1:
Use organization's "standard"
Programming Language UOSC:
Use organization's "standard"
Properties Models: driven by success criteria
Process Meta-Model: ICM-Sw [nee WinWin Spiral]
 "Defining and sustaining a stakeholder win-win
relationship through the system's life-cycle"
 "Using the ECR, VCR, FCR, DCR Anchor Point milestones"
Process Lifecycle Model:
Depends on project characteristics
1 Unless Other Success Criteria
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 20 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Large System Example
A Common Operating Environment
[AKA Middleware]
A Virtual Machine: A "super" operating system
A Framework on which application(s) "ride"
Provides common functionality (so not repeated in each app.);
"Service" Oriented
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 21 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
FCS [SOS]COE
For more and detailed information, see
http://www.boeing.com/ids/soscoe/index.html and
http://www.boeing.com/ids/soscoe/SOSCOE_171713_001.pdf
FCS Software and SOSCOE
SOSCOE uses Distributed Development
SoSCOE Reference Model Relationship
SOSCOE Implementation Layers
SOSCOE Implementation Reference Model 1.5
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 22 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
FCS Software and SOSCOE
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 23 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
SOSCOE uses Distributed Development
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 24 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
SoSCOE Reference Model Relationship
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 25 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
SOSCOE Implementation Layers
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 26 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
SOSCOE Implementation Reference Model 1.5
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 27 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
SOSCOE ICM-Sw(?) Selections
Product Model Representation: UML (Rose);
J-016 compliant documents; 1491 for Software Arch.;
Content not always "risk driven"
Programming Language: C++ (programmer availability)
Properties Models: driven by success criteria
Cost, Schedule, Earned value, Risk burn-down, ....
Process Meta-Model: WinWin Spiral
 "Defining and sustaining a stakeholder win-win relationship
through the system's life-cycle"
 "Using the LCO, LCA, and IOC Anchor Point milestones"
(sort of)
Process Lifecycle Model: using Waterfall Milestones
even though operating more like WW Spiral model
(builds 1.5, 1.8, …; functionality group LCA-like reviews)
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 28 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Outline
ICM-Sw Beyond CS577a
Applying ICM-Sw to a Large System
Applying ICM-Sw to a System of Systems
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 29 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Background and Definitions
FCS Overview Booklet (Flipbook) 2004 R1
"FCS is a highly integrated structure of manned and unmanned, air
and ground assets, bound by a distributed network to act as a
unified combat force."
 Systems of FCS
 FCS System of Systems
Networked System-of-Systems
 distributed network, situationally aware and adaptive
SOLDIERS and leaders,
 agility and “reach back” enhanced by advanced
technology
Software Intensive System of Systems
2008 Smart Book available at
http://www.boeing.com/defense-space/ic/fcs/bia/080520_2007flipbook.html
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 30 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Future Combat "Systems"
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 31 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
FCS System of Systems
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 32 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Background and Definitions (cont.)
Basic Sw Devel. Parametric Model – COCOMO II
Life Cycle Development [Process] Models
 Waterfall (activity focus per stage) Vs. RUP/ICM-Sw (Concurrent:
All activities All the time)
 Incremental Vs. Evolutionary
a) Once-through. The "once-through" strategy consists of performing the development
process a single time. Simplistically: determine user needs, define requirements, design
the system, implement the system, test, fix, and deliver.
b) Incremental. The "incremental" strategy determines user needs and defines the
system requirements, then performs the rest of the development in a sequence of builds.
The first build incorporates part of the planned capabilities, the next build adds more
capabilities, and so on, until the system is complete.
c) Evolutionary. The "evolutionary" strategy also develops a system in builds, but differs
from the incremental strategy in acknowledging that the user need is not fully understood
and all requirements cannot be defined up front. In this strategy, user needs and system
requirements are partially defined up front, then are refined in each succeeding build.
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 33 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
FCS Development Constraints
Average-Case Software Development Time versus Size
Size (KESLOC)
300
1,000
3,000
10,000
Time (Months)
33
50
72
108
Aggressive Schedule for software!
 SAIV! Six "builds" across 26 Partner/Suppliers
 An architecture to premit parrallel development
 Plan builds based on do-ability
 small enough increments so schedule is realistic
 some requirements trades based on experience
 Other influences: longer than normal first build
Foundations (must get SoS Sw Architecture right! )
 use other methods to estimate schedule; check for max
within build
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 34 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
FCS Development Life Cycles
18-24 Month Increments
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 35 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
FCS Approach: IncrEvolutionary RUPish builds
Allows concurrent [inception] elaboration and
construction after first build's construction started
Allows practice (makes perfect) integration: multiple SoS
Item Qualification [FQT], field test
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 36 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
FCS Approach: IncrEvolutionary RUPish builds
Overlapping Development Spirals By Prime & Subs
Ideal Overlapping
Development
Evolve
After Architecture
CompleteSpirals By Prime & Subs
Evolve After Architecture Complete
18 mon. Arch. Devel.
Build 1
Inception Elaboration with Evol. Req. Construction Transition
Inception
Inception
Elaboration with Evol. Req.
Elaboration with Evol. Req.
1st Integ. in SoSIL
Build 2
already done I & E
Inc. Elaboration Construction Trans.^
^ with FQT
Dry Run
SoS
LCA
Build 3
already done I & E
from 2nd build I&E
I. Elab. Construction Transition*
* with FQT
LUT: limited user test
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 37 of 48
LUT
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Multi-Build (IncrEvolve) COCOMO II
COINCOMO With Sum-across Build
Build x
New
Build x
Build x+1
Carried
Build x+2
Modify
Build x
Carried
New,
Reused and
COTS
New
Build x+1
New,
Reused and
COTS
Box size notional for effort.
© 2007-2017 A W Brown BES/MSEE & USC CSE
Modify
Build x+1
Carried
etc.
New
Build x+2
New,
Reused and
COTS
81914659 – 38 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Multi-Build COCOMO II
Guidance about how to "carry" forward
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 39 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Multi-Build COCOMO II
Guidance about how to "carry" forward (cont.)
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 40 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
COPSEMO: Phased Schedule and Effort Dist.
COPSEMO model is build into COINCOMO
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 41 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
COCOTS: COTS with Assessment, Tailoring and Glue Code
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 42 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
Large Softare Systems and Beyond
Software Cost and Schedule Models
 COINCOMO
 Guidance about how to "carry" forward
 COCOMO II + COPSEMO With Roll-across Build Summation
 COPSEMO: Phased Schedule and Effort Dist.
 COCOTS: COTS with Assessment, Tailoring and Glue Code
 Combining Models: COINCOMO 2.0
COCOCMO, COPSEMO and COCOTS
Systems Engineering Models
 COSYSMO: Systems Engineering Effort
 COSOSIMO: System of System Software Integration Effort
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 43 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
COSOSIMO Conceptual Model Context
The classic systems engineering "V" model with
emerging cost & schedule estimation models in context
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 44 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
COSOSIMO in Context of a
ICM-Sw/RUP-model Software System
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 45 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
COSOSIMO Model Context in FCS
Multiple, RUPish or Watrfall Builds
Faster Down on left so Sw can start
Longer “UP” on right as multiple Builds are repeatedly
integrated.
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 46 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
FCS Development Life Cycles
18-24 Month Increments
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 47 of 48
v1.0 - 07/29/17
USC
C
S E
University of Southern California
Center for Software Engineering
CS577a Fall 2009 – ICM-Sw and Large Systems
COSOSIMO Context in FCS
© 2007-2017 A W Brown BES/MSEE & USC CSE
81914659 – 48 of 48
v1.0 - 07/29/17