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-CSSE
2
University of Southern California
Center for Systems and Software Engineering
Systems Engineering Is Evolving from its Hardware Origins
90
F-22
F/A-22
80
70
B-2
B-2
60
50
F-16
F-16
40
F-15
F-15
30
F-111
F-111
20
10
F-4
A-7
1960
1964
Multi-year
delays
associated
with software
and system
stability
Software and
testing delays
push costs
above
Congressional
ceiling
0
3/10/2010
Ref: Defense
Systems Management College
1970
1975
©USC-CSSE
1982
1990
2000
3
University of Southern California
Center for Systems and Software Engineering
Underlying HwE, SwE, HfE Differences
Difference Area
Hardware
Software
Human Factors
Major Life-cycle
Cost Concern
Development,
manufacturing
Life-cycle evolution
Training and
operations labor
Ease of Changes
Generally difficult
Good within
architectural
framework
Very good, but peopledependent
Nature of Changes
Manual, slow, laborintensive, expensive
Electronic, rapid,
inexpensive
Need personnel
retraining, can be
expensive
User-tailorability
Generally difficult,
limited options
Technically easy;
mission-driven
Technically easy;
mission-driven
Indivisibility
Inflexible lower limit
Flexible lower limit
Smaller increments
easier to introduce
Underlying Science
Physics, chemistry,
continuous
mathematics
Discrete
mathematics,
linguistics
Behavioral sciences
Testing
By test organization;
much analytic
continuity
By test organization;
little analytic
continuity
By users
3/10/2010
©USC-CSSE
4
University of Southern California
Center for Systems and Software Engineering
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
3/10/2010
©USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
System/Software Architecture Mismatches
- Maier, 2006
• System Hierarchy
• Software Hierarchy
– Part-of relationships; no
shared parts
– Uses relationships; layered
multi-access
– Function-centric; single
data dictionary
– Data-centric; class-object
data relations
– Interface dataflows
– Interface protocols;
concurrency challenges
– Dynamic functionalphysical migration
– Static functional-physical
allocation
3/10/2010
©USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
Examples of Architecture
Mismatches
• Fractionated, incompatible sensor data management
…
…
Sensor 1
SDMS1
…
Sensor 2
Sensor 3
Sensor n
SDMS2
SDMS3
SDMSn
• “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
3/10/2010
©USC-CSSE
7
University of Southern California
Center for Systems and Software Engineering
Software Development Schedule Trends
#Years ~ 0.4 * cube root (KSLOC)
20
Years to
Develop
Software,
Hardware
10
SW
HW
0
10
100
1000 10000 100000
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
3/10/2010
©USC-CSSE
8
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-CSSE
9
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-CSSE
10
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-CSSE
11
University of Southern California
Center for Systems and Software Engineering
ICM HSI Levels of Activity for Complex Systems
3/10/2010
©USC-CSSE
12
University of Southern California
Center for Systems and Software Engineering
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
3/10/2010
©USC-CSSE
13
University of Southern California
Center for Systems and Software Engineering
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
3/10/2010
©USC-CSSE
14
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 engineeringoriented capstone courses for mono-discipline majors
• Need for T-shaped people (Ramo)
• Need ability to quickly learn other disciplines (Rechtin)
3/10/2010
©USC-CSSE
15
University of Southern California
Center for Systems and Software Engineering
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.
15 July 2008
©USC-CSSE
16