Slide 1 COCOMO 2004 – Peter Hantos Dr. Peter Hantos The Aerospace Corporation Anchoring Concurrent...
-
date post
19-Dec-2015 -
Category
Documents
-
view
218 -
download
1
Transcript of Slide 1 COCOMO 2004 – Peter Hantos Dr. Peter Hantos The Aerospace Corporation Anchoring Concurrent...
Slide 1COCOMO 2004 – Peter Hantos
Dr. Peter Hantos
The Aerospace Corporation
Anchoring Concurrent Engineering Processes
19th International Forum on COCOMO and Software Cost Modeling, October 26-29, 2004, Los Angeles, California
2004. The Aerospace Corporation. All Rights Reserved.
Slide 2COCOMO 2004 – Peter Hantos
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
Slide 3COCOMO 2004 – Peter Hantos
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
Slide 4COCOMO 2004 – Peter Hantos
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
Slide 5COCOMO 2004 – Peter Hantos
The Traditional* Perspective on Life Cycles
HW/SW Integration and TestingSystem Qualification Testing
Operations and MaintenanceRe-validation/Re-verification
System Requirements DefinitionSystem Design
Software Requirements Def.
High-level Design (Architecture)
Detailed Design
Implementation (Coding)Unit Testing
Software IntegrationSoftware Qual. Testing
Hardware Requirements Def.
Preliminary Design
Detailed Design
FabricationTest
Hardware IntegrationHardware Qual. Testing
“Big Bang”
_____________________________*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
Slide 6COCOMO 2004 – Peter Hantos
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
HW/SW Integration and TestingSystem Qualification Testing
Operations and MaintenanceRe-validation/Re-verification
System Requirements DefinitionSystem Design
Software Requirements Def.
High-level Design(Architecture)
Detailed Design
Implementation (Coding)Unit Testing
Software IntegrationSoftware Qual. Testing
Hardware Requirements Def.
Preliminary Design
Detailed Design
FabricationTest
Hardware IntegrationHardware Qual. Testing
“Big Bang”
Slide 7COCOMO 2004 – Peter Hantos
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]
Slide 8COCOMO 2004 – Peter Hantos
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.
Slide 9COCOMO 2004 – Peter Hantos
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
Slide 10COCOMO 2004 – Peter Hantos
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
Slide 11COCOMO 2004 – Peter Hantos
Stakeholder Commitment Modeling
Phase i
APx
Phase i+1P n-1 Trailing Process
Phase j
APY
Phase j+1P n Process in Question
Phase k
APZ
Phase k+1P 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
Slide 12COCOMO 2004 – Peter Hantos
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]
Slide 13COCOMO 2004 – Peter Hantos
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
Slide 14COCOMO 2004 – Peter Hantos
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
Slide 15COCOMO 2004 – Peter Hantos
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
Slide 16COCOMO 2004 – Peter Hantos
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
Slide 17COCOMO 2004 – Peter Hantos
• 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-1
Sub-assembly
PCB
ASIC
LCO LCA
IOC DER
EOM
LCO
LCO LCA
LCA IOC EOM
EOM
Slide 18COCOMO 2004 – Peter Hantos
ASIC-PCB Anchoring Examples - 2
Sub-assembly
PCB
LCO LCA
LCO
ASIC
IOC DERLCO LCA
LCA IOC
EOM
EOM
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
Slide 19COCOMO 2004 – Peter Hantos
• 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 a Platform-Based Product-Line
PlatformIOCLCO LCA EOM
DER
Product1
LCO LCA IOC EOM
DER
DER
Product2
LCO LCA IOC EOM
DER DER…
Slide 20COCOMO 2004 – Peter Hantos
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.
Slide 21COCOMO 2004 – Peter Hantos
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.
Slide 22COCOMO 2004 – Peter Hantos
AcronymsAP Anchor Point ASIC Application Specific Integrated Circuit CCPM Critical Chain Project Management DARPA Defense Advanced Research Project Agency DER Delivery Readiness EOM End Of Maintenance FCS Future Combat Systems HW Hardware IC Integrated Circuit IOC Initial Operational Capability LCA Life Cycle Architecture LCO Life Cycle Objectives MBASE Model-Based (System) Architecting and Software Engineering PAB Post Anchor Point Buffer PCB Printed Circuit Board RUP IBM/Rational Unified Process SEI Software Engineering Institute SIS Software-Intensive System STARS Software Technology for Adaptable, Reliable Systems SW Software USC University of Southern California
Slide 23COCOMO 2004 – Peter Hantos
References[Boehm04] Boehm, B., et al., Spiral Acquisition of Software-Intensive Systems of Systems, Crosstalk,
May 2004 [Boehm96] Boehm, B., Anchoring the Software Process, IEEE Software, July 1996
[CSE03] Guidelines for Model-Based (System) Architecting and Software Engineering (MBASE),
v.2.4.0, USC Center for Software Engineering, February 11, 2003 [EETA04] Goering, R., Is verification really 70 percent?, Electronic Engineering Times – Asia,
August 2, 2004 [Gold97] Goldratt, E.H., Critical Chain, North River Press, Great Barrington, MA, 1997
[Hant00] Hantos, P., From Spiral to Anchored Processes: A Wild Ride in Lifecycle Architecting,
Proceedings, USC-SEI Spiral Experience Workshop, Los Angeles, CA, February 2000 [IEEE00] IEEE STD 1471-2000, IEEE Recommended Practice for Architectural
Description of Software-Intensive Systems, 2000 [IEEE97] IEEE/EIA 12207.0-1997, Standard for Information Technology Software Life Cycle
Processes – Implementation Considerations [JSTD95] J-STD-016-1995, (Interim) Standard for Information Technology Software Life Cycle
Processes Software Development Acquirer-Supplier Agreement, September 1995 [Royce98] Royce, W., Software Project Management – A Unified Framework, Addison-Wesley, 1998
[Smith97] Smith, M.J.S., Application-Specific Integrated Circuits, Addison-Wesley, 1997