Dr. Peter Hantos The Aerospace Corporation

1. 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 • 2004. 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 • 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. Software Requirements Def. Hardware Requirements Def. High-level Design (Architecture) Preliminary Design Detailed Design Detailed Design Fabrication Implementation (Coding) Test Unit Testing Hardware Integration Software Integration Hardware Qual. Testing Software Qual. Testing “Big Bang” The Traditional* Perspective on Life Cycles System Requirements Definition System Design HW/SW Integration and Testing System Qualification Testing Operations and Maintenance _____________________________ *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 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 developmentconcept; 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. LCO LCA IOC DER EOM Phase1 Phase2 Phase3 Phase4 Phase5 Phase6 Increment Generalized Life Cycle Model • 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. APZ P n+1 Leading Process Phase k+1 APY P n Process in Question Phase j+1 APx P n-1 Trailing Process Phase i+1 Phase i Phase j Phase k Stakeholder Commitment Modeling • 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 • 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]

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 • 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

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 • 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

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. Sub-assembly PCB ASIC LCA LCA LCA LCO LCO LCO IOC IOC DER EOM EOM EOM ASIC-PCB Anchoring Examples-1 • 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. Sub-assembly PCB ASIC LCA LCA LCA LCO LCO LCO IOC IOC DER EOM EOM EOM ASIC-PCB Anchoring Examples - 2 • 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. Product2 Product1 … Platform LCA LCA LCA LCO LCO LCO IOC IOC IOC DER DER DER DER DER EOM EOM EOM Modeling a Platform-Based Product-Line • 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. Iterative Development Waterfall Development Translation-based Development Anchoring Basic Software Development Patterns