Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering

1. Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering Barry Boehm, USC-CSSE Annual Research Review Executive Workshop March 10, 2010 Some charts include explanatory notes

2. Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering ©USC-CSSE • Most Current and Future Systems Need All Four • But most people’s learning focuses on just one • They have different mental models • That make different assumptions about solutions • Some of the assumptions are decreasingly valid • Hardware-first doesn’t work • Nor does software-first or human-factors first • Initiatives are forming to address integration • SERC SwE and SysE Bodies of Knowledge; SysE 2020 • Incremental Commitment Model • US Science, Technology, Engineering, and Math Initiative

3. Systems Engineering Is Evolving from its Hardware Origins 90 90 F-22 F/A-22 80 80 Multi-year delays associated with software and system stability 70 70 B-2 B-2 60 60 50 50 F-16 F-16 Software and testing delays push costs above Congressional ceiling Percent of Specification Requirements Involving Software Control 40 40 F-15 F-15 30 30 F-111 F-111 20 20 A-7 A-7 F-4 F-4 10 10 0 0 1960 1960 1964 1964 1970 1970 1975 1975 1982 1982 1990 1990 2000 2000 Ref: Defense Systems Management College ©USC-CSSE

4. Underlying HwE, SwE, HfE Differences ©USC-CSSE

5. Implications for Integrating HwE, SwE, and HfE: Current SysE Guidelines Emphasize Hardware Concerns • Focus on early hardware decisions may lead to • Selecting hardware components with incompatible software • Inadequate hardware support for software functionality • Inadequate human operator capability • Late start of software development • Difficulty of hardware changes may lead to • High rate of change traffic assigned to software without addressing critical–path risks • Indivisibility may lead to single-increment system acquisition • Different test phenomena may lead to inadequate budget and schedule for testing software and human factors ©USC-CSSE

6. System Hierarchy Part-of relationships; no shared parts Function-centric; single data dictionary Interface dataflows Static functional-physical allocation Software Hierarchy Uses relationships; layered multi-access Data-centric; class-object data relations Interface protocols; concurrency challenges Dynamic functional-physical migration System/Software Architecture Mismatches- Maier, 2006 ©USC-CSSE

7. Examples of Architecture Mismatches • Fractionated, incompatible sensor data management • “Touch Football” interface definition earned value • Full earned value taken for defining interface dataflow • No earned value left for defining interface dynamics • Joining/leaving network, publish-subscribe, interrupt handling, security protocols, exception handling, mode transitions • Result: all green EVMS turns red in integration … … … Sensor 1 Sensor 2 Sensor 3 Sensor n SDMS1 SDMS2 SDMS3 SDMSn ©USC-CSSE

8. Software Development Schedule Trends#Years ~ 0.4 * cube root (KSLOC) SW Years to Develop Software,Hardware HW Thousands of source lines of code (KSLOC) Delaying software start increasingly risky Need to find ways to compress software schedules - Timeboxing; architecting for decoupled parallel development ©USC-CSSE

9. Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering ©USC-CSSE • Most Current and Future Systems Need All Four • But most people’s learning focuses on just one • They have different mental models • That make different assumptions about solutions • Some of the assumptions are decreasingly valid • Hardware-first doesn’t work • Nor does software-first or human-factors first • Initiatives are forming to address integration • SERC SwE and SysE Bodies of Knowledge; SysE 2020 • Incremental Commitment Model • US Science, Technology, Engineering, and Math Initiative

10. Problems with Software-First or Human-Factors-First ©USC-CSSE • Unscalable SW COTS choices (New Jersey DMV) • Too many SW layers (IBM 360/67, Medlars II) • Insensitive to new technology (ASICs, multicore) • Changing user interface (UI) slows project (FAA AAS) • Immature natural language UI ability (library systems) • UI choices neglect new technology (WYSIWYG) • Computer-knows-best UIs (MS WYTINWYG) • What you type is not what you get (HSI becomes HIS)

11. Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering ©USC-CSSE • Most Current and Future Systems Need All Four • But most people’s learning focuses on just one • They have different mental models • That make different assumptions about solutions • Some of the assumptions are decreasingly valid • Hardware-first doesn’t work • Nor does software-first or human-factors first • Initiatives are forming to address integration • SERC SwE and SysE Bodies of Knowledge; SysE 2020 • Incremental Commitment Model • US Science, Technology, Engineering, and Math Initiative

12. ICM HSI Levels of Activity for Complex Systems ©USC-CSSE

13. The Incremental Commitment Life Cycle Process: Overview Stage I: Definition Stage II: Development and Operations Anchor Point Milestones Synchronize, stabilize concurrency via FEDs Risk patterns determine life cycle process ©USC-CSSE

14. Anchor Point Feasibility Evidence Description • Evidence provided by developer and validated by independent experts that: If the system is built to the specified architecture, it will • Satisfy the requirements: capability, interfaces, level of service, and evolution • Support the operational concept • Be buildable within the budgets and schedules in the plan • Generate a viable return on investment • Generate satisfactory outcomes for all of the success-critical stakeholders • All major risks resolved or covered by risk management plans • Serves as basis for stakeholders’ commitment to proceed Can be used to strengthen current schedule- or event-based reviews ©USC-CSSE

15. US Science, Technology, Engineering, and Math Initiative ©USC-CSSE • Major national program to strengthen K-12 Science, Technology, Engineering, and Math (STEM) education • DARPA program to use advanced GUI, agent, and game technology to make STEM learning more fun, interesting • USC-ISI DREAMS proposal • DDR&E-SERC program to create systems engineering-oriented capstone courses for mono-discipline majors • Need for T-shaped people (Ramo) • Need ability to quickly learn other disciplines (Rechtin)

16. References Boehm, B., Software Engineering Economics, Prentice Hall, 1981. Boehm, B., and Lane, J., “Using the ICM to Integrate System Acquisition, Systems Engineering, and Software Engineering,”CrossTalk, October 2007, pp. 4-9. Boehm, B., and Lane, J., "Guide for Using the Incremental Commitment Model (ICM) for Systems Engineering of DoD Projects,” version 0.5, USC-CSSE-2009-500, December 2008, http://csse.usc.edu/csse/TECHRPTS/ Checkland, P., Systems Thinking, Systems Practice, Wiley, 1980 (2nd ed., 1999). Galorath, D., and Evans, M., Software Sizing, Estimation, and Risk Management, Auerbach, 2006. Jensen, R. “An Improved Macrolevel Software Development Resource Estimation Model,” Proceedings, ISPA 5, April 1983, pp. 88-92. Lientz, B., and Swanson, E.B., Software Maintenance Management, Addison Wesley, 1980. Maier, M., “System and Software Architecture Reconciliation,”Systems Engineering 9 (2), 2006, pp. 146-159. Pew, R. W., and Mavor, A. S., Human-System Integration in the System Development Process: A New Look, National Academy Press, 2007. Putnam, L., “A General Empirical Solution to the Macro Software Sizing and Estimating Problem,”IEEE Trans SW Engr., July 1978, pp. 345-361. Rechtin, E. Systems Architecting, Prentice Hall, 1991. ©USC-CSSE