4_Boehm ISSEwithICM-July08LLd

advertisement
University of Southern California
Center for Systems and Software Engineering
Integrating Systems and Software
Engineering (IS&SE) with the
Incremental Commitment Model (ICM):
ICM Lessons Learned
Barry Boehm and Jo Ann Lane, USC-CSSE
IS&SE with ICM Workshop II
July 17, 2008
University of Southern California
Center for Systems and Software Engineering
ICM Assumptions and Critical Success Factors
• The project can establish milestones at which it can
synchronize and stabilize its elements
– May exclude some classes of systems of systems
• Ad-hoc, collaborative, some acknowledged
– But ICM principles can be applied to tailor variants
• The project can invest enough up front to generate
and evaluate feasibility evidence and address risks
• The project can acknowledge and manage its risks
– Risk-taking essential for many classes of projects
• Unprecedentedness, emergence, rapid change, immature
technology
• DARPA: 100% success rate is not doing your job
• Commercial: 40% failure rate acceptable for new ventures
15 July 2008
©USC-CSSE
2
University of Southern California
Center for Systems and Software Engineering
Example: SoSE Synchronization Points
FCR1
SoS-Level Exploration
Valuation
Candidate Supplier/
Strategic Partner n
DCR1
Architecting
OCR1
Develop
OCR2
Operation

LCO-type
Proposal &
Feasibility
Info
●
Source
Selection
Rebaseline/
Adjustment FCR1
●
●
Candidate Supplier/
Strategic Partner 1
OCRx2
OCRx1
System x   
Develop
OCRx3
Operation
Operation
OCRx5
OCRx4
Operation
Operation
DCRC
OCRC1

●
●
●
System C   
FCRC
Exploration
Valuation
Architecting
FCRB
System B   
Exploration
Valuation
3
Exploration
Valuation
DCRB
Architecting
FCRA
System A   
Develop
Operation
OCRB1
Develop
July 2008

OCRB2
Operation

OCRA1
DCRA
Architecting
OCRC2
Develop
Operation
©USC-CSSE

University of Southern California
Center for Systems and Software Engineering
Recognizing Authority/Responsibility Mismatch
Collaborative
Acknowledged
SoS
Ad-hoc SoS
SoS
Directed SoS
Responsibility
Infeasible
Traditional Methods
Authority
4
18 June 2007
©USC-CSSE
University of Southern California
Center for Systems and Software Engineering
How Much Architecting is Enough?
Percent of Time Added to Overall Schedule
- Larger projects need more
100
90
10000
KSLOC
80
Percent of Project Schedule Devoted to
Initial Architecture and Risk Resolution
70
Added Schedule Devoted to Rework
(COCOMO II RESL factor)
Total % Added Schedule
60
Sweet Spot
50
40
100 KSLOC
30
Sweet Spot Drivers:
20
Rapid Change: leftward
10 KSLOC
10
High Assurance: rightward
0
0
10
20
30
40
50
60
Percent of Time Added for Architecture and
Risk Resolution
03/19/2008
©USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
ICM Assumptions and Critical Success Factors - II
• The program office has enough expertise to evaluate
feasibility evidence and assess risks
– If not in-house, need to contract for it
• Feasibility evidence is a first-class deliverable
– Needs plans, EVMS monitoring of progress vs. plans
• Appropriate contracting mechanisms and incentive
structures are available for executing ICM approach
– Concurrent stabilized development, change rebaselining, V&V
– Collaborative systems of systems
– Competitive prototyping
• Representative examples are needed to clarify concepts
– Ideally, success stories with excursions to show pitfalls
15 July 2008
©USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
ICM Stage II: Increment View
A radical idea?
Unforseeable Change
(Adapt)
Rapid
Change
Short
Development
Increments
Agile
Future Increment Baselines
Rebaselining for
Future Increments
Deferrals
Foreseeable
Change (Plan)
Increment N Baseline
Stable Development
Increments
Current V&V
High
Assurance
Resources
Short, Stabilized
Development
of Increment N
Artifacts
Increment N Transition/O&M
Concerns
V&V
of Increment N
Future V&V
Resources
Continuous V&V
No; a commercial best practice and part of DoDI 5000.2
15 July 2008
©USC-CSSE
7
University of Southern California
Center for Systems and Software Engineering
Bottom Line
• Tremendously valuable workshop
– Complementary perspectives, but remarkable compatibility
– Value of insights much broader than ICM
• Better understanding of underlying assumptions
– Not every program fits the basic ICM/DoD milestone framework
– But ICM principles can be applied to tailor variants
– Need to clarify expectations, especially for SoSs
• Rework chapter on application to SoSs
• Rework overview to define assumptions and implications
• Increase effort on representative examples
– Will inform content of guidelines
– Looking for good examples to use, further feedback on content
• Will post results on Workshop web site
– And establish ICM work-in-progress web site for review
– Look forward to your participation
in Oct 29-30 USC workshop
15 July 2008
©USC-CSSE
8
Download