19th International Forum on COCOMO and Software Cost Modeling,
October 26-29, 2004, Los Angeles, California
Anchoring Concurrent
Engineering Processes
Dr. Peter Hantos
The Aerospace Corporation
COCOMO 2004 – Peter Hantos
2004. The Aerospace Corporation. AllSlide
Rights
1 Reserved.
Acknowledgements
• This work would not have been possible without assistance
from the following:
– Reviewers
• Richard J. Adams, Software Acquisition and Process Office
• Lance A. Diernback, Software Architecture and Engineering
• Suellen Eslinger, Software Acquisition and Process Office
– Sponsor
• Michael Zambrana, USAF Space and Missile Systems Center,
Directorate of Systems Engineering
– Funding source
• Mission-Oriented Investigation and Experimentation (MOIE)
Research Program (Software Acquisition Task)
– Inspiration
• Dr. Barry Boehm, University of Southern California
COCOMO 2004 – Peter Hantos
Slide 2
Agenda
• Introduction
• The Traditional Perspective on Life Cycles
• Anchor Points
• Generalization of Anchor Points
• Generalized Life Cycle Model
• Anchoring ASIC and PCB Processes
• Modeling a Platform-based Product Line Development Process
• Modeling Iteration on the Phase Level
• Conclusions
COCOMO 2004 – Peter Hantos
Slide 3
Introduction
• The Usual HW/SW Dialog
– Traditional SW Position:
• Give me the working hardware, and leave me alone
– Traditional HW Position:
• Here are the specs, see you at final integration. Now leave me alone!
– What Really Takes Place:
• HW is changing frequently during design. SW people are frustrated and
inefficient. SW always ends up being the bottleneck
• Challenges, Challenges …
– The Project Manager’s Challenge:
• Managing (estimating, planning, monitoring, and controlling)
concurrent engineering processes
– The Process Architect’s Challenge:
• Dealing with life cycle modeling complexity
- concurrent engineering of hardware and software
- iterative/incremental processes
• We need to determine the optimal number of interactions and their
optimal place in the life cycle
COCOMO 2004 – Peter Hantos
Slide 4
The Traditional* Perspective on Life Cycles
System Requirements Definition
System Design
Software Requirements Def.
High-level Design
(Architecture)
Hardware Requirements Def.
Preliminary Design
Detailed Design
Detailed Design
Implementation (Coding)
Unit Testing
Software Integration
Software Qual. Testing
Fabrication
Test
Hardware Integration
Hardware Qual. Testing
HW/SW Integration and Testing
System Qualification Testing
Operations and Maintenance
Re-validation/Re-verification
_____________________________
*Chart is based on various software life cycle standards, e.g.:
J-STD-016-1995, Annex B, Figure 4,5, and 6
IEEE/EIA 12207.0-1997, Annex I, Figure I.3
COCOMO 2004 – Peter Hantos
Slide 5
“Big Bang”
What is Wrong With This Picture?
• Waterfall development of hardware and software
System Requirements Definition
System Design
Software Requirements Def.
High-level Design
(Architecture)
• “Big-bang” Integration and System Test
Hardware Requirements Def.
Preliminary Design
Detailed Design
Detailed Design
Implementation (Coding)
Unit Testing
Software Integration
Software Qual. Testing
Fabrication
Test
Hardware Integration
Hardware Qual. Testing
HW/SW Integration and Testing
System Qualification Testing
Operations and Maintenance
Re-validation/Re-verification
“Big Bang”
• Hardware-software units are developed in
isolation
• Design trade-offs are expected on system level
only
• Mitigation of hardware and software risks is
separated; no opportunity for joint risk
mitigation
• All software units are expected to be developed
simultaneously
• Simplified, static view of architecture
• Static view of software assuming unchanging
software entities across the life cycle
COCOMO 2004 – Peter Hantos
Slide 6
Anchor Points
• Anchor Points
– Anchor points are a set of project planning milestones with specific
objectives
– Boehm’s original anchor points [Boehm96]:
• LCO (Life Cycle Objectives)
• LCA (Life Cycle Architecture)
• IOC (Initial Operational Capability)
– The need for these anchor points was determined on the basis of studying
successful projects
• Representative Applications of Anchor Points
– System/System of Systems Context
• DARPA-STARS (Defense Advanced Research Project AgencySoftware Technology for Adaptable, Reliable Systems) [Boehm96]
• US Army FCS (Future Combat Systems) [Boehm04]
– Project/Increment Context
• RUP® (IBM/Rational Unified Process) [Royce98]
• MBASE - Model-Based (System) Architecting and Software
Engineering [CSE03]
COCOMO 2004 – Peter Hantos
Slide 7
Generalizing Anchor Points for Concurrent
Engineering
• Generalization Objectives
– Improve estimation accuracy and control confidence
– Extend the anchor point concept to inter-increment contexts to model
the concurrent development of increments
– Extend the anchor point concept beyond software development
• Specific Goals
– Extend the concept to cover the complete (“cradle to grave”) life cycle of
development increments
– Apply the concepts to electronic hardware design, specifically to
• ASICs – Application Specific Integrated Circuits, and
• PCBs – Printed Circuit Boards.
COCOMO 2004 – Peter Hantos
Slide 8
Generalization Approach
• Key Elements of the Original Anchor Points
– Stakeholder concurrence on the system’s life cycle objectives
– Determination and validation of the system’s life cycle architecture
• Generalization Assumptions
– The original definitions above are extendable and scalable
– The generalized “increment” is a delivery, and not a development concept;
hence the new model will not explicitly reflect the development details
– Properly defined and positioned anchor points represent stability in key
dimensions of the development process
• Anchor point objectives might be achieved iteratively, but planned iteration loops
do not cross life cycle phase boundaries
• Generalization Approach
– Interpret “stakeholder”, “system”, “architecture” in the extended contexts
– Determine new anchor points and their objectives that are consistent with
the generalized interpretations
– Use anchor points to connect and synchronize concurrent process streams
COCOMO 2004 – Peter Hantos
Slide 9
Generalized Life Cycle Model
LCO
Phase1
LCA
Phase2
IOC
Phase3
DER
Phase4
EOM
Phase5
Phase6
Increment
• Phases are intentionally not named only numbered
– Phase content stays flexible; phase activities are not pre-determined
– Focus is on achieving anchor point objectives
– Want to avoid confusion with RUP or MBASE
• New Anchor Points to be introduced
– DER - Delivery Readiness
– EOM - End Of Maintenance
COCOMO 2004 – Peter Hantos
Slide 10
Stakeholder Commitment Modeling
APZ
P n+1 Leading Process
Phase k
Phase k+1
APY
P n Process in Question
Phase j
Phase j+1
APx
P n-1 Trailing Process
Phase i
Phase i+1
• A generalization of the original “Stakeholders concur on the
system’s life cycle objectives” key element to concurrent processes
• Stakeholder concurrence expressed as commitments:
– Upstream: Pn knows Pn+1’s objectives at APz and supports it with its delivery
– Downstream: Pn relies on Pn-1’s delivery to satisfy APY objectives
COCOMO 2004 – Peter Hantos
Slide 11
Generalizing the Architecture Concept
• Architecture*
– “Fundamental organization of a system embodied in its components,
their relationship to each other, and to the environment, and the
principles guiding its design and evolution.”
• For Generalization, replace
– “System” with “Increment”
– “Environment” with “Concurrently Developed Increments”
• Understand that the scope of “design” and “evolution” refers
to all concurrent development streams and not only one
– Concurrently Developed Increments can be software or hardware
_________________
* Definition from IEEE STD 1471-2000, IEEE Recommended Practice for Architectural
Description of Software-Intensive Systems [IEEE00]
COCOMO 2004 – Peter Hantos
Slide 12
Front-End Anchor Points – Focused
Objectives
• LCO – Life Cycle Objectives
– Product-related
• Definition of operational concept, scope, and top-level requirements
• Architectural and design options
– Process-related
• Life Cycle Plan defined
- Global plans for the whole life cycle, plus
- Detailed plan for achieving LCA
• LCA – Life Cycle Architecture
– Product-related
• Refinement of operational concept, scope, and top-level requirements
• Resolution of LCO option-explorations, commitment to a feasible
architecture and technology solutions
– Process-related
• Life Cycle Plan refined
- Global plans for the rest of the life cycle, plus
- Detailed plan for achieving IOC
COCOMO 2004 – Peter Hantos
Slide 13
Back-End Anchor Points – Focused
Objectives
• IOC – Initial Operational Capacity
– Product-related
• Operation and quality is demonstrated in development environment
– Process-related
• Readiness for moving to target environment for final implementation,
testing and/or integration is demonstrated
• DER – Delivery Readiness
– Product-related
• The work product created in this phase is ready for
- Delivery to the end-user/customer, or
- Higher-level integration and test
– Process-related
• The processes are ready to accomplish the delivery or integration tasks
outlined above
• EOM – End of Maintenance
– Decision is made for terminating support
– End of maintenance strategy developed
• End of maintenance strategy is executed in the 6th phase, but the 6th
phase is not terminated by an anchor point
COCOMO 2004 – Peter Hantos
Slide 14
Anchoring the PCB Process
• Input
– Board-level specification (Including ASIC specifications)
• LCO
– Logic design
– Functional verification
• LCA
– IC (Integrated Circuit) placement and routing (With ASICs)
• IOC
– IC physical verification and analysis
– Analog/mixed-signal design
• DER
– Fabrication and test
– External sourcing or manufacturing start-up
• These steps trigger another, concurrent process stream. Nevertheless, the support of
the design continues until the end of life of the board
• EOM
– Decision is part of the total system viability evaluation
COCOMO 2004 – Peter Hantos
Slide 15
Anchoring the ASIC Process
• Input
– ASIC specification
• LCO
– Virtual prototyping
– ASIC system simulation
– Behavioral modeling
• LCA
– HDL (High Definition Language) design capture and simulation
• IOC
– Rapid prototyping or hardware emulation
– System verification
• DER
– Fabrication and test
– External sourcing or manufacturing start-up
• EOM
• These steps trigger another, concurrent process stream. Nevertheless, the support of
the design continues until the end of life of the ASIC
– Decision is part of the total system viability evaluation
COCOMO 2004 – Peter Hantos
Slide 16
ASIC-PCB Anchoring Examples-1
LCA
LCO
EOM
Sub-assembly
LCO
LCA
IOC
EOM
PCB
LCO LCA
IOC
DER
EOM
ASIC
• Scenario A
– ASIC and PCB specifications are the results of the sub-assembly design process
– ASIC DER is synchronized with PCB LCO
• Actual ASIC is needed to carry out IC placement and routing (PCB LCA objective)
– EOM decision might trigger EOM for PCB and ASIC, but
• ASIC must be supported until PCB’s end of life
• PCB must be supported until Sub-assembly’s end of life
– Note that PCB design is highly constrained by the ASIC design process
• Bulk of the work cannot proceed until ASIC is available
• Plan poses increased schedule pressure on ASIC designers as well
COCOMO 2004 – Peter Hantos
Slide 17
ASIC-PCB Anchoring Examples - 2
LCA
LCO
EOM
Sub-assembly
LCO
LCA
IOC
EOM
PCB
LCO
LCA
IOC
EOM
DER
ASIC
• Scenario B
– ASIC specification is technology-driven and known in advance
• ASIC design can start even before sub-assembly design start
– ASIC DER is synchronized with the beginning of PCB design
• ASIC specifications and actual ASIC can be provided to PCB designers even before
LCO even though it is only needed at LCO to accomplish LCA objectives
– ASIC EOM decision will trigger an EOM for PCB, but not necessarily for the subassembly
• For example, ASIC is redesigned for improved performance; as a result, PCB needs to
be redesigned as well, but its external electrical, electronic, and physical characteristics
don’t change.
– Note that neither process is overly constrained by the other
COCOMO 2004 – Peter Hantos
Slide 18
Modeling a Platform-Based Product-Line
LCA
LCO
IOC
DER
EOM
Product2
LCO
LCA
IOC
DER
EOM
Product1
LCO
LCA
IOC
DER DER
…
DER
EOM
Platform
• Development of Product1
– Platform (HW, SW, or Software-Intensive System) is concurrently developed with Product1
– Platform architecture has to be finalized and provided when product planning starts
– Platform DER is synchronized with Product1 LCA
• Platform has to be available to accomplish Product1 IOC
• Or, in a more aggressive plan, Platform IOC would be synchronized with Product1 LCA
• Development of Product2
– Platform architecture information is provided when product planning starts
– A second Platform DER is synchronized with Product2 LCO or LCA
• Actual platform is provided to the design team as soon as possible, to complete Product2 IOC
– The last product’s EOM triggers EOM for the platform as well
• Caveat: Platform technology obsolesce can also trigger EOM for the product(s)
COCOMO 2004 – Peter Hantos
Slide 19
Modeling Iteration on the Phase Level
APn+1
APn
CCPM PAP
Buffer Buffer
• What is Iteration?
–
–
–
–
–
Iteration is the repeated execution of steps inside of the phase
Iteration is a risk-mitigation strategy to deal with complexity challenges
Planned iteration cycles (vs. “doodling” or “code-and-fix”) are driven by engineering objectives
Final number of iterations and their duration are not deterministic entities
The use of CCPM*-type buffers is suggested to model iteration planning uncertainties
• PAP (Post-Anchor Point) Buffer
–
–
The use of this additional buffer is suggested to model follow-up, post-anchor point activities
Note that PAP activities are concurrent with the activities of the next phase and they are not on
the critical path; hence the distinction from CCPM buffers.
_________________
* CCPM - Critical Chain Project Management [Gold97] is a buffering system originally
introduced for the planning and control of the critical path in project networks.
COCOMO 2004 – Peter Hantos
Slide 20
Conclusions
• A generalized life cycle modeling approach has been presented
– The approach facilitates reasoning about concurrent engineering
process streams during planning and estimation.
• The models are
– discipline-independent, but facilitate trade-offs across technical
disciplines,
– Intuitive, and easily translatable to Gantt charts for operational planning
and control purposes.
COCOMO 2004 – Peter Hantos
Slide 21
Acronyms
AP
ASIC
CCPM
DARPA
DER
EOM
FCS
HW
IC
IOC
LCA
LCO
MBASE
PAB
PCB
RUP
SEI
SIS
STARS
SW
USC
COCOMO 2004 – Peter Hantos
Anchor Point
Application Specific Integrated Circuit
Critical Chain Project Management
Defense Advanced Research Project Agency
Delivery Readiness
End Of Maintenance
Future Combat Systems
Hardware
Integrated Circuit
Initial Operational Capability
Life Cycle Architecture
Life Cycle Objectives
Model-Based (System) Architecting and Software Engineering
Post Anchor Point Buffer
Printed Circuit Board
IBM/Rational Unified Process
Software Engineering Institute
Software-Intensive System
Software Technology for Adaptable, Reliable Systems
Software
University of Southern California
Slide 22
References
[Boehm04] Boehm, B., et al., Spiral Acquisition of Software-Intensive Systems of Systems, Crosstalk,
May 2004
[Boehm96] Boehm, B., Anchoring the Software Process, IEEE Software, July 1996
[CSE03] Guidelines for Model-Based (System) Architecting and Software Engineering (MBASE),
v.2.4.0, USC Center for Software Engineering, February 11, 2003
[EETA04] Goering, R., Is verification really 70 percent?, Electronic Engineering Times – Asia,
August 2, 2004
[Gold97] Goldratt, E.H., Critical Chain, North River Press, Great Barrington, MA, 1997
[Hant00] Hantos, P., From Spiral to Anchored Processes: A Wild Ride in Lifecycle Architecting,
Proceedings, USC-SEI Spiral Experience Workshop, Los Angeles, CA, February 2000
[IEEE00] IEEE STD 1471-2000, IEEE Recommended Practice for Architectural
Description of Software-Intensive Systems, 2000
[IEEE97] IEEE/EIA 12207.0-1997, Standard for Information Technology Software Life Cycle
Processes – Implementation Considerations
[JSTD95] J-STD-016-1995, (Interim) Standard for Information Technology Software Life Cycle
Processes Software Development Acquirer-Supplier Agreement, September 1995
[Royce98] Royce, W., Software Project Management – A Unified Framework, Addison-Wesley, 1998
[Smith97] Smith, M.J.S., Application-Specific Integrated Circuits, Addison-Wesley, 1997
COCOMO 2004 – Peter Hantos
Slide 23
Backup
COCOMO 2004 – Peter Hantos
Slide 24
Anchoring Basic Software Development Patterns
LCO
Phase1
LCA
Phase2
IOC
LCO
Phase3
Phase1
Requirements
HighLevel
Design
LowLevel
Design
LCA
Phase2
IOC
Phase3
• Modeling
• Modeling
• Modeling
• Requirements
• Requirements
• Requirements
• Analysis and Design
• Analysis and Design
• Analysis and Design
• Implementation
• Implementation
• Implementation
• Test
• Test
• Test
Code
Integration
Test
Iterative Development
Waterfall Development
LCO
Phase1
• Analysis
LCA
Phase2
IOC
Phase3
• Analysis
• Simulation
• Automated Code
Generation
MODEL
CODE
Translation-based Development
COCOMO 2004 – Peter Hantos
Slide 25