why it s important to integrate hardware software human factors and systems engineering l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering PowerPoint Presentation
Download Presentation
Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering

Loading in 2 Seconds...

play fullscreen
1 / 16

Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering - PowerPoint PPT Presentation


  • 147 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Why It’s Important to Integrate Hardware, Software, Human Factors, and Systems Engineering' - giuseppe


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
why it s important to integrate hardware software human factors and systems 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

why it s important to integrate hardware software human factors and systems engineering2
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
systems engineering is evolving from its hardware origins
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

implications for integrating hwe swe and hfe current syse guidelines emphasize hardware concerns
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

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

System/Software Architecture Mismatches- Maier, 2006

©USC-CSSE

examples of architecture mismatches
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

software development schedule trends years 0 4 cube root ksloc
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

why it s important to integrate hardware software human factors and systems engineering9
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
problems with software first or human factors first
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)
why it s important to integrate hardware software human factors and systems engineering11
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
the incremental commitment life cycle process overview
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

anchor point feasibility evidence description
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

us science technology engineering and math initiative
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)
references
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