University of Southern California Center for Systems and Software Engineering Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems.

Slides:



Advertisements
Similar presentations
Prescriptive Process models
Advertisements

The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CSE 470 : Software Engineering The Software Process.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Human-System Integration in the System Development Process Frank E. Ritter with help from Barry Boehm 21 jan 08.
University of Southern California Center for Systems and Software Engineering A Look at Software Engineering Risks in a Team Project Course Sue Koolmanojwong.
University of Southern California Center for Systems and Software Engineering SoS Engineering and the ICM Workshop Overview Jo Ann Lane USC CSSE
University of Southern California Center for Systems and Software Engineering Integrating Systems & Software Architecting Workshop Participants Problem.
University of Southern California Center for Systems and Software Engineering Evidence-Based Software Processes Supannika Koolmanojwong CS510 1.
The Role of Software Engineering Brief overview of relationship of SE to managing DSD risks 1.
Proposed Way Forward for SERC EM Task Barry Boehm, USC-CSSE 30 January 2009.
University of Southern California Center for Software Engineering CSE USC System Dynamics Modeling of a Spiral Hybrid Process Ray Madachy, Barry Boehm,
University of Southern California Center for Software Engineering C S E USC Hardware/Software Human Systems Integration Context and Processes USC-CSE Executive.
University of Southern California Center for Software Engineering C S E USC Barry Boehm, USC USC-CSE Executive Workshop March 15, 2006 Processes for Human.
University of Southern California Center for Systems and Software Engineering USC CSSE Research Overview Barry Boehm Sue Koolmanojwong Jo Ann Lane Nupul.
University of Southern California Center for Systems and Software Engineering Issues and Recommendations Emanating from the Management Issues Group of.
COSOSIMO* Workshop 13 March 2006 Jo Ann Lane University of Southern California Center for Software Engineering CSE Annual.
University of Southern California Center for Systems and Software Engineering Integrating Systems and Software Engineering (IS&SE) with the Incremental.
University of Southern California Center for Systems and Software Engineering Next Generation Estimation Methods and Management Metrics: Working Group.
Administrivia Lifecycle Architecture (LCA) group assignment will go out later today. Informal feedback meetings with LCO groups EasyShare: Mon, 2:45pm-3:15pm,
1 Jul 2005CSE403, Summer'05, Section 02 Section 02: Life Cycle Architecture Review Valentin Razmov.
University of Southern California Center for Software Engineering C S E USC Barry Boehm, USC CS 510 Lecture Fall 2011 Value-Based Software Engineering.
Software Architecture in Practice
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
University of Southern California Center for Systems and Software Engineering Integrating Systems and Software Engineering: Complex Systems Workshop 29.
University of Southern California Center for Systems and Software Engineering Feasibility Evidence Description (FED) Barry Boehm, USC CS 577a Lecture Fall.
University of Toronto Department of Computer Science CSC444 Lec04- 1 Lecture 4: Software Lifecycles The Software Process Waterfall model Rapid Prototyping.
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
University of Southern California Center for Systems and Software Engineering Incremental Commitment Spiral Model (ICSM) for CS 577 Barry Boehm, Supannika.
Systems Engineering In Aerospace Theodora Saunders February AUTOMATION IN MANUFACTURING Leading-Edge Technologies and Application Fairfield University.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
University of Southern California Center for Systems and Software Engineering Model-Based Software Engineering Supannika Koolmanojwong Spring 2013.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
University of Southern California Center for Systems and Software Engineering Barry Boehm, USC CS 510 Software Planning Guidelines.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
University of Southern California Center for Software Engineering CSE USC A Case for Anchor Point Milestones and Feasibility Rationales April 2005 Barry.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
University of Southern California Center for Systems and Software Engineering 3/3/2010© USC-CSSE CSCI577B 2010 Light Weight Sw Engg for Off-the-Books.
CSC480 Software Engineering Lecture 10 September 25, 2002.
DoD Systems Engineering and Management Implications for Evolutionary Acquisition of Major Defense Systems A DoD SERC Quick-Look Study and CSER 2010 Invited.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
Systems/Software ICM Workshop Acquisition and Process Issues Working Group Rick Selby and Rich Turner Systems/Software ICM Workshop July 14-17, 2008 Washington.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
University of Southern California Center for Systems and Software Engineering Aug. 26, 2010 © USC-CSE Page 1 A Winsor Brown CS 577a Lecture Fall.
University of Southern California Center for Systems and Software Engineering Enablers and Inhibitors for Expediting Systems and Software Engineering &
1 Session 2: SET Workshop Human-Systems Integration Azad M. Madni & Colin J. Neill SET Team January 28, 2010.
University of Southern California Center for Systems and Software Engineering RDCR ARB CS 577b Software Engineering II Supannika Koolmanojwong.
University of Southern California Center for Software Engineering C S E USC ICSM Principles for Successful Software and Systems Engineering Barry Boehm,
Advanced Software Engineering Dr. Cheng
CS 577b: Software Engineering II
Project Cost Management
Client Introductions to CS577a
The Systems Engineering Context
Systems of Systems Challenges and Strategies
Using the Incremental Commitment Model (ICM) Process Decision Table
SDLC Model A framework that describes the activities performed at each stage of a software development project.
Using the Incremental Commitment Model (ICM) Process Decision Table
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML
Comparison between each special case
Stumpf and Teague Object-Oriented Systems Analysis and Design with UML
Ramin Moazeni Winsor Brown Barry Boehm
Incremental Commitment Model (ICM)* for Software
Logical Architecture & UML Package Diagrams
Presentation transcript:

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

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

University of Southern California Center for Systems and Software Engineering ©USC-CSSE 3 3/10/ F-4 A-7 F-111 F-15 F-16 B-2 F 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

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

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

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

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 ……

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

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

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

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

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

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

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

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

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