19 th International Forum on COCOMO and Software

19 th 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. All Rights Reserved. Slide 1

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 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 • “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 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 [Boehm 96]: • 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) [Boehm 96] • US Army FCS (Future Combat Systems) [Boehm 04] – Project/Increment Context • RUP® (IBM/Rational Unified Process) [Royce 98] • MBASE - Model-Based (System) Architecting and Software Engineering [CSE 03] 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 LC O LC A IOC DE R EO M Phase 1 Phase 2 Phase 3 Phase 4 Phase 5 Phase 6 Increme nt • 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 k+1 APY P n Process in Question Phase j+1 j APx P n-1 Trailing Process Phase i+1 i • 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 [IEEE 00] 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 6 th phase, but the 6 th 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 Subassembly EO M LC A LC O PC B ASIC LC O LC A IOC DE R EO M • 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 Subassembly EO M LC A LC O PC B ASIC LC O LC A IOC EO M DE R • 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 LC O Produc t 1 LC O LC A Platfor m • Development of Product 1 IOC Produc t 2 IOC LC A DE R IOC LC A LC O DE R … DE R EO M – Platform (HW, SW, or Software-Intensive System) is concurrently developed with Product 1 – Platform architecture has to be finalized and provided when product planning starts – Platform DER is synchronized with Product 1 LCA • Platform has to be available to accomplish Product 1 IOC • Or, in a more aggressive plan, Platform IOC would be synchronized with Product 1 LCA • Development of Product 2 – Platform architecture information is provided when product planning starts – A second Platform DER is synchronized with Product 2 LCO or LCA • Actual platform is provided to the design team as soon as possible, to complete Product 2 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 • 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 [Gold 97] 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 COCOMO 2004 – Peter Hantos Slide 22

References COCOMO 2004 – Peter Hantos Slide 23

Backup COCOMO 2004 – Peter Hantos Slide 24

Anchoring Basic Software Development Patterns Waterfall Development COCOMO 2004 – Peter Hantos Iterative Development Translation-based Development Slide 25