1. University of Southern California Center for Systems and Software Engineering 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. University of Southern California Center for Systems and Software Engineering Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering 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/10/2010©USC-CSSE2

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

4. University of Southern California Center for Systems and Software Engineering ©USC-CSSE 4 3/10/2010 Underlying HwE, SwE, HfE Differences Difference AreaHardwareSoftwareHuman Factors Major Life-cycle Cost Concern Development, manufacturing Life-cycle evolutionTraining and operations labor Ease of ChangesGenerally difficultGood within architectural framework Very good, but people- dependent Nature of ChangesManual, slow, labor- intensive, expensive Electronic, rapid, inexpensive Need personnel retraining, can be expensive User-tailorabilityGenerally difficult, limited options Technically easy; mission-driven IndivisibilityInflexible lower limitFlexible lower limitSmaller increments easier to introduce Underlying SciencePhysics, chemistry, continuous mathematics Discrete mathematics, linguistics Behavioral sciences TestingBy test organization; much analytic continuity By test organization; little analytic continuity By users

5. University of Southern California Center for Systems and Software Engineering 3/10/2010©USC-CSSE5 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

6. University of Southern California Center for Systems and Software Engineering ©USC-CSSE 6 3/10/2010 System/Software Architecture Mismatches - Maier, 2006 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

7. University of Southern California Center for Systems and Software Engineering 3/10/2010©USC-CSSE7 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 Examples of Architecture Mismatches … Sensor 1 SDMS1 Sensor 2 SDMS2 Sensor 3 SDMS3 Sensor n SDMSn ……

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

9. University of Southern California Center for Systems and Software Engineering Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering 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/10/2010©USC-CSSE9

10. University of Southern California Center for Systems and Software Engineering Problems with Software-First or Human-Factors-First 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) 3/10/2010©USC-CSSE10

11. University of Southern California Center for Systems and Software Engineering Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering 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/10/2010©USC-CSSE11

12. University of Southern California Center for Systems and Software Engineering 3/10/2010©USC-CSSE12 ICM HSI Levels of Activity for Complex Systems

13. University of Southern California Center for Systems and Software Engineering 3/10/2010©USC-CSSE13 The Incremental Commitment Life Cycle Process: Overview Stage I: DefinitionStage II: Development and Operations Anchor Point Milestones Synchronize, stabilize concurrency via FEDs Risk patterns determine life cycle process

14. University of Southern California Center for Systems and Software Engineering 3/10/2010©USC-CSSE14 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

15. University of Southern California Center for Systems and Software Engineering US Science, Technology, Engineering, and Math Initiative 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) 3/10/2010©USC-CSSE15

16. University of Southern California Center for Systems and Software Engineering 15 July 2008©USC-CSSE16 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 (2 nd 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.