1. Anchoring Concurrent Engineering Processes
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
The Aerospace Corporation. All Rights Reserved.

2. 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

3. 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

4. Introduction The Usual HW/SW Dialog Challenges, Challenges …
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

5. The Traditional* Perspective on Life Cycles
System Requirements Definition
System Design
Software Requirements Def.
High-level Design
(Architecture)
Detailed Design
Implementation (Coding)
Unit Testing
Software Integration
Software Qual. Testing
Hardware Requirements Def.
Preliminary Design
Detailed Design
Fabrication
Test
Hardware Integration
Hardware Qual. Testing
“Big Bang”
Note that the hardware life cycle is also waterfall (and it is always waterfall…)
HW/SW Integration and Testing
System Qualification Testing
Operations and Maintenance
Notes:
The model also assumes that all concurrently developed software and hardware items, even though they are developed in independent process streams, are completed at the same time, ready for a “Big Bang” integration. It is obvious though that this structure does not allow for successful, earlier validation of requirements, and the resolution of problems at this late stage of the project is usually very costly.
Despite of the shortcomings of the Waterfall Model, why was Winston Royce’s original publication so important? The Waterfall is the “mother of all life cycle models”. That was the first time when the otherwise seemingly natural sequence of software development was codified and published. It was an attempt to document an existing practice, unlike later life cycle models that were constructed with the goal of trying to address various shortcomings of the Waterfall Model.
_____________________________
*Chart is based on various software life cycle standards, e.g.:
J-STD , Annex B, Figure 4,5, and 6
IEEE/EIA , Annex I, Figure I.3
Re-validation/Re-verification

6. What is Wrong With This Picture?
Waterfall development of hardware and software
“Big-bang” Integration and System Test
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

7. 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 Agency-Software 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]

8. 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.

9. 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

10. Generalized Life Cycle Model
Phase1
LCO
Phase2
LCA
Phase3
IOC
Phase4
DER
Phase5
EOM
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

11. Stakeholder Commitment Modeling
Phase i
APx
Phase i+1
P n-1 Trailing Process
Phase j
APY
Phase j+1
P n Process in Question
Phase k
APZ
Phase k+1
P n+1 Leading Process
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

12. Generalizing the Architecture Concept
“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 , IEEE Recommended Practice for Architectural
Description of Software-Intensive Systems [IEEE00]

13. 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
Refinement of operational concept, scope, and top-level requirements
Resolution of LCO option-explorations, commitment to a feasible architecture and technology solutions
Life Cycle Plan refined
Global plans for the rest of the life cycle, plus
Detailed plan for achieving IOC

14. 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
The work product created in this phase is ready for
Delivery to the end-user/customer, or
Higher-level integration and test
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

15. 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

16. 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
These steps trigger another, concurrent process stream. Nevertheless, the support of the design continues until the end of life of the ASIC
EOM
Decision is part of the total system viability evaluation

17. ASIC-PCB Anchoring Examples-1
Sub-assembly
PCB
ASIC
LCO
LCA
IOC
DER
EOM
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

18. ASIC-PCB Anchoring Examples - 2
Sub-assembly
PCB
LCO
LCA
ASIC
IOC
DER
EOM
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 sub-assembly
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

19. Modeling a Platform-Based Product-Line
IOC
LCO
LCA
EOM
DER
Product1
Product2 …
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)

20. Modeling Iteration on the Phase Level
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.

21. 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.

22. Acronyms

23. References

24. Backup

25. Anchoring Basic Software Development Patterns
Waterfall Development
Iterative Development
Translation-based Development