1. University of Southern California Center for Software Engineering C S E USC Hardware/Software Human Systems Integration Context and Processes USC-CSE Executive Workshop Barry Boehm Center for Software Engineering (CSE) University of Southern California (USC) boehm@usc.edu http://sunset.usc.edu March 15, 2006

2. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 2 Outline The Future of Systems and Software –8 surprise-free trends; 2 wild-card trends –Individual and combined process implications General HW/SW/Human systems integration process challenges –Balancing agility and discipline –Scaling up Responding to the challenge –The scalable spiral process Conclusions, references

3. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 3 The Future of Systems and Software Eight surprise-free trends 1.Increasing integration of SysE and SwE 2.User/Value focus 3.Software Criticality and Dependability 4.Rapid, Accelerating Change 5.Distribution, Mobility, Interoperability, Globalization 6.Complex, Net-Centric Systems of Systems 7.COTS, Open Source, Reuse, Legacy Integration 8.Computational Plenty Two wild-card trends 9.Autonomy Software 10.Combinations of Biology and Computing Implications for SE/SW processes –Jointly and severally

4. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 4 What Does an SISOS Look Like: Network Centric Operations and Warfare

5. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 5 System of Systems Definition*  A system will be called a System of Systems (SoS) when: –The component systems achieve well-substantiated purposes in their own right even if detached from the overall system; –The components systems are managed in large part for their own purposes rather than the purposes of the whole; –It exhibits behavior, including emergent behavior, not achievable by the component systems acting independently –Component systems, functions, and behaviors may be added or removed during its use * Definition evolved from Sage, Maier, Levis

6. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 6 Systems Engineering Evolution: Alex Levis perspective We started with Hardware-centric Systems Engineering –Addressed the human through Man-Machine system work We then progressed to Software-centric systems –Addressed the human through Human-Computer interface work We are now evolving toward Human-centric Systems Engineering Hardware Humans Software Systems Engineering Integration Human-Computer Man-Machine

7. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 7 Systems Engineering Evolution: Alex Levis perspective II The systems have hardware, software and humans as components We focus too much on Hardware and Software integration leaving “the rest” for humans to cope with; we then invest in training In the systems-of-systems, many humans are inside the SoS But our methodology and procedures really consider the human as being outside: the “interface” problem Consequently, we do the Task Allocation too early along traditional lines The Task Allocation problem requires some new thought: –Not Hardware centric SE –Not Software centric SE –Not Human centric SE but considering all three in a balanced manner:  Focus on Integration

8. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 8 Essential Integration Process Features Concurrent: in defining product and process; needs and solutions; development and solution; human, hardware, and software elements Risk-driven: in determining which tasks to do next and how much of each task to do Anchor point milestones: in bounding complexity and in synchronizing and stabilizing development Stakeholder value-based: in determining and reconciling human stakeholder value propositions Balanced with respect to plan-driven and situation- driven process Mapped onto acquisition commitment milestones

9. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 9 Hardware-SW- Human-System Integration Levels of Activity - EIEIO model for relatively complex systems IRR: Inception Readiness Review; LCO: Life Cycle Objectives; LCA: Life Cycle Architecture; OC: Operational Capability. LCA N+1 is being rebaselined while OC N is being implemented and OC N-1 is being operated.

10. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 10 Spiral Anchor Points Enable Concurrent Engineering

11. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 11 Primary Focus of HSI Activity Categories - I – HSI activities often span multiple categories

12. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 12 Primary Focus of HSI Activity Categories - II – HSI activities often span multiple categories

13. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 13 Primary Focus of HSI Activity Categories - III – HSI activities often span multiple categories

14. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 14 Emerging Scalable Spiral Process - For 21 st century systems engineering and acquisition The C4ISR Metaphor for NCSOS Acquisition –vs. purchasing agent metaphor –Continuing OODA loops Observe, orient, decide, act Risk-Driven Scalable Spiral Model –Increment view –Life-cycle view –Role of anchor point milestones Acquisition management implications People management implications

15. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 15 Risk-Driven Scalable Spiral Model: Increment View

16. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 16 Risk-Driven Scalable Spiral Model: Increment View

17. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 17 Risk-Driven Scalable Spiral Model: Life Cycle View System Inception System Elaboration Agile DI 2 (OO&D) Rebaselining Plan-Driven DI 1 Construction (A) DI 1 V&V Plan-Driven DI 2 Construction (A) DI 2 V&V System LCASystem, DI 1 LCADI 2 B/L LCA DI 2 LCA Changes LCA: Life Cycle Architecture IOC: Initial Operational Capability OO&D: Observe, Orient and Decide V&V: Verification and Validation DI: Development Increment B/L: Baselined

18. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 18 Risk-Driven Scalable Spiral Model: Life Cycle View System Inception System Elaboration Agile DI 2 (OO&D) Rebaselining Plan-Driven DI 1 Construction (A) DI 1 V&V Agile DI 3 (OO&D) Rebaselining Plan-Driven DI 2 Construction (A) DI 2 V&V Agile DI 4 (OO&D) Rebaselining Plan-Driven DI 3 Construction (A) DI 3 V&V DI 1 Trans’n DI 1 Usage DI 2 Trans’n DI 2 Usage DI 3 Trans’n DI 3 Usage System LCA DI 3 LCA System, DI 1 LCADI 2 B/L LCADI 3 B/L LCADI 4 B/L LCA Update DI 2 LCA Changes DI 4 LCA... DI 1 IOC DI 3 IOC DI 2 IOC LCA: Life Cycle Architecture IOC: Initial Operational Capability OO&D: Observe, Orient and Decide V&V: Verification and Validation DI: Development Increment B/L: Baselined

19. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 19 LCO (MS A) and LCA (MS B) Anchor Points Pass/Fail Criteria A system built to the given architecture will –Support the operational concept –Satisfy the requirements –Be faithful to the prototype(s) –Be buildable within the budgets and schedules in the plan –Show a viable business case –Establish key stakeholders’ commitment to proceed LCO: True for at least one architecture LCA: True for the specific life cycle architecture; All major risks resolved or covered by a risk management plan

20. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 20 Spiral Feasibility Rationale Deliverable LCO, LCA reviews not just UML/PowerPoint charts Need to show evidence of product and process feasibility Evidence provided by prototypes, production code, benchmarks, models, simulations, analysis –Sizing and cost/schedule model results for process feasibility Evidence provided in advance to LCO/LCA review team –Key stakeholders, specialty experts Lack of evidence risks destabilizing the process –Needs coverage by viable risk mitigation plan Key new progress metric –Feasibility evidence progress vs. plans

21. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 21 Conclusions New Paradigms needed for future success –Adaptive process immaturity balanced with repeatable process maturity –Software/ systems/acquisition engineering Separate contract, award fee mechanisms for build-to-spec, V&V, agile rebaselining –IR&D: core capability research plus external technology experimentation –Enterprise integration: Mutual learning and sharing vs. stovepipes New skills and career paths needed –Specialists in build-to-spec, V&V, agile rebaselining –Managers and SW/ systems engineers with all three skills –Skills in software/ systems/ acquisition engineering, COTS assessment and integration, value-based software/ systems engineering, software/ hardware/ human factors integration, agile/ adaptive methods –Continuing education and learning how to learn

22. University of Southern California Center for Software Engineering C S E USC 02/06/2006 © USC-CSE 22 G. Anthes, “The Future of IT”, Computerworld, March 7, 2005, pp. 27-36 S. Biffl, A. Aurum, B. Boehm, H. Erdogmus, and P. Gruenbacher (eds.), Value-Based Software Engineering, Springer, 2005 (to appear) B. Boehm, “Some Future Trends and Implications for Systems and Software Engineering Processes,” System Engineering, 2006 (to appear). B. Boehm and J. Lane, “21 st Century Processes for Acquiring 21 st Century Software- Intensive Systems of Systems”, Cross Talk, May 2006 (to appear). B. Boehm and R. Turner, Balancing Agility and Discipline, Addison Wesley, 2004. T. Friedman, The World Is Flat, Farrar Straus, and Giroux, 2005 J. Highsmith, Adaptive Software Development, Dorset House, 2000. INCOSE: “Systems Engineering Technical Vision” (H. Crisp, ed.) v1.1, June 2005. L. Koskela and L. Howell, “The Underlying Theory of Project Management Is Obsolete”, Proc. PMI Rsch. Conference, 2002, AP. 293-302 D. Reifer, Making the Software Business Case, Addison Wesley, 2002. W. Royce, Software Project Management, Addison Wesley, 1998. USAF-SAB, Systems of Systems Engineering for Air Force Capability Development, SAB-TR-05-04, July 2005 References