1 / 25

Dr. Peter Hantos The Aerospace Corporation

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

dieter
Download Presentation

Dr. Peter Hantos The Aerospace Corporation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related