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 2004. The Aerospace Corporation. All Rights 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

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

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

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-016-1995, Annex B, Figure 4,5, and 6 IEEE/EIA 12207.0-1997, Annex I, Figure I.3 Re-validation/Re-verification

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

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]

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.

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

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

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

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 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems [IEEE00]

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

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

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

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

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

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

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)

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.

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.

Acronyms

References

Backup

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