© 2007 carnegie mellon university managing the engineering of systems software engineering...

Managing the Engineering of Systems

Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213

Brian P. Gallagher, DirectorAcquisition Support29 October, 2007

2SEI Presentation (Basic)Author, Date

Contents

Engineering Management

Software Engineering is Systems Engineering

Software Engineering is Different

Back to Basics: Principles of Effective Engineering Management

Three Important Things

Conclusion

Engineering Management

Managing complex engineering projects requires:

• Ability to manage customers

• Ability to understand technical complexities

• Ability to understand team complexities

• Ability to inspire and lead

• Ability to negotiate

• Ability to deliver

• Ability to plan, re-plan, re-start, and close-out

• Situational awareness

• Luck

Knowledge Evolves: Acquirer’s View

StakeholdersStakeholders

Evaluate Incremental

Progress

StakeholdersStakeholdersStakeholdersStakeholders

Execute Acquisition

Strategy

Evaluate Incremental

Progress

Execute Refined

Acquisition Strategy

Improve Process

RefineAcquisition Strategy

RefineAcquisition StrategyDevelop

Acquisition Strategy

Acq. Strategy

v2.0Tech Devel Strat

AoA Plan

Evolutionary Approaches

Simultaneous Definition

and Tradeoffs

Marketplace,Re-use

System Context

Architecture & Design

Traditional Approach(Waterfall Development)

System Context

Architecture & Design

Implementation

Knowledge Evolves: Developer’s View

Known Rqmnts Buy, Re-use, Build, Integrate, Refresh

• COTS products• NDI

• Strongly influenced by products and standards

• requirements• cost• schedule• business processes• operational

procedures, etc.

Complex Operational Environments

Require Complex System SolutionsManned Ground Vehicles (MGV)

Non-Line of

Sight Cannon

(NLOS-C)

XM1203

Non-Line of

Sight Mortar

(NLOS-M)

XM1204

Medical Vehicle

Treatment (MV-T)XM1208FCS Recovery and

Maintenance

Vehicle (FRMV)

XM1205

Unmanned Aerial Systems (UAS)Class I UAV

(XM156)Class IV UAV

(MQ-8B)

Unattended Ground Systems (UGS)

Tactical and Urban Unattended

Ground Sensors

Unmanned Ground Vehicles (UGV)

Small UGV (SUGV)

Armed Robotic Vehicle – Assault (Light) (ARV-A-L)

MULE-C MULE-T

Mounted Combat System (MCS)

XM1202

Infantry Carrier

Vehicle (ICV)

XM1206

U-UGS(AN/GSR-10 (T))

Medical Vehicle

Evacuation (MV-E)

XM1207

Non-Line of Sight Launch System

(NLOS-LS) XM501

Multifunction Utility/ Logistics

and Equipment Countermine and

Transport

Reconnaissance

And Surveillance

Vehicle (RSV)XM1201

Command and Control Vehicle

(C2V) XM1209

Common

Chassis

17 Jul 07

Common

Chassis

Centralized

Controller

U-UGS(AN/GSR-9 (U))

Voyages of Discovery, not Well-Defined Programs

Software Engineering is Systems Engineering

What is a System?

… a collection of different things which together produce results unachievable by the elements alone

• The Art of System Architecting, 2nd edition, Maier and Rechtin

… an integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective

• Systems Engineering Fundamentals, Defense Acquisition University Press

… a set of complementary, interacting parts with properties, capabilities and behaviors emerging both from the parts and from their interactions

• Hitchins, Derek, http://www.hitchins.co.uk/WCES.html

Systems Engineering is …

…an interdisciplinary, collaborative approach that derives, evolves, and verifies a life-cycle balanced system solution which satisfies customer expectations and meets public acceptability

• (Reference: IEEE P1220)

Software Engineering is …

…the design, development, and documentation of software by applying technologies and practices from computer science, project management, engineering, application domains, interface design, digital asset management and other fields

• (Reference: Wikipedia)

Systems Engineering: “I want” to “I got”

Systems Engineering

Operational Need

Software Engineering: “I want” to “I got”

Software Engineering

Operational Need

Effective Engineering Managers Employ Software-Aware Systems Engineering: “I want” to “I got”

Software-Aware Systems

Engineering

Operational Need

Software as a “Product”; Software Engineering as a “Discipline”

Software Products Software Engineering

Software-AwareSystems Engineering

Software is Different

Realities of Software

Loop < 20 times

The flowchart might correspond to a 100 LOC module with a single loop that may be executed no more than 20 times.

There are approximately 1014 possible paths that may be executed!

For any but the smallest programs, complete path coverage for defect detection is impractical.

Adapted from Pressman, R.S., Software Engineering: A Practitioner’s Approach, Third Edition, McGraw Hil, 1992

Challenges of Software

Typical Industry Software Quality at Delivery

• A 1,000 line-of-code (1 KLOC) program listing has about 20 pages of executable code

• For industrial software, typical shipped quality levels are 5 to 10 defects per KLOC or 1 defect in 2 – 4 pages

• A 1 million line-of-code (1 MLOC) printed listing stands roughly 5’7” and contains between 5,000 to 10,000 defects when shipped

For DoD acquisition programs, these realities are often ignored resulting in unrealistic schedules and unplanned test/fix cycles inserted to grow the reliability of low quality software.

What Does 17M ESLOC Look Like?

How do we Grow the Reliability?

Do we expect between 85,000 and 170,000 defects to still be present after FQT?

Do we plan to discover, fix, re-test or do we plan to “prove functionality” (Green Light Integration and Test)?

Do systems engineers without a foundation in software engineering understand this unique aspect of the complexities of software-intensive systems and latent defects that will be present?

What are the consequences?

V-22 Osprey

A V-22 Osprey crashed on December 11, 2000.

• Four marines were killed.

• The problem was traced to a software defect.

V-22 software had been exhaustively tested.

Software is Challenging

The complexities, the interactions, the flexibility, and our inability to grasp how difficult building software-intensive systems places us at a cross-roads

New techniques are needed but are years away

We refuse to accept this and grasp at “Silver Bullets”

Back to Basics:Principles of Effective Management

The Buzzword Quagmire and Quest for the “Silver Bullet”

Evolutionary AcquisitionCapability-Based Acquisition

Interoperability

Service-Based Acquisition

Systems Engineering Revitalization

Acquisition Reform

Net-Centric Warfare

Open Systems

Total System Performance Responsibility

Insight versus Oversight

Architecture-based Development

Agile Acquisition

Lean Acquisition

Lean Six Sigma

Service-Oriented Architecture

Time-Certain Development

Team Software Process

Incremental Commitment Model

Extreme Programming

Open Architecture

DoDAFFEAFATAM

Win-Win Spiral

Earned-Value

How to make sense? Principle-Based Decisions

“Principle” Defined:

The collectivity of moral or ethical standards or judgments: a decision based on principle rather than expediency.

Decisions to pursue a given management approach should be grounded on underlying principles designed to increase the effectiveness of acquiring, developing, and deploying systems to the end user

The following describes the Seven Principles of Effective Engineering Management

Seven Principles of Effective Engineering Management

The Core Principle: Open Communication

Encouraging free flowing information at and between all stakeholders.

Enabling formal, informal, and impromptu communication.

Using consensus-based processes that value the individual voice (bringing unique knowledge and insight to evolving mission capabilities).

The Three Sustaining Principles

Team Risk Management

Continuous Process Improvement

Continuous Product Improvement

Team Risk Management

Evolving the warfighter’s capabilities by continuously mitigating operational, development, and acquisition risks.

All stakeholders participating in managing the project by managing the risks.

Continuous Process Improvement

Maturing the acquisition, development, and operational processes to meet the warfighter’s objectives.

Employing a common process improvement framework and language to align and enhance process capability.

Continuous Product Improvement

Enhancing the warfighter’s mission through evolutionary delivery of enhanced capabilities.

Delivering an initial capability on the first promise date, with the demonstrated capability to deliver improved or updated capability on a regular, dependable schedule.

The Three Defining Principles

Forward-Looking View

Global Perspective

Shared Product Vision

Forward-Looking View

Seeing a common tomorrow against which all stakeholders can measure potential breakthroughs and risks.

Managing project resources and activities while anticipating uncertainties.

Global Perspective

Sharing a single mental model of project success that crosses all boundaries between acquirer, developer, and operator.

Viewing enhancements within the context of the operational mission.

Recognizing both the potential value of opportunity and the potential impact of adverse effects.

Shared Product Vision

Developing and sustaining a common conception of the product being built - one that can be stated simply and briefly, and is founded on common purpose, shared ownership, and collective commitment among the stakeholders.

Focusing on results.

Three Important Things: Scope, Focus, Deliver!

Three Important Things

Scope the problem – “What”

Focus the team – “How”

Deliver value – “When and Where”

Everything else is just noise!

RUP/ICM Anchor Points Enable Concurrent Engineering

Deliver

Conclusions

Management of engineering project has become more complex as demand grows and technology tries to keep up

Software and Systems Engineering employ defined processes to get from “I want” to “I got”

Managers need to ensure their early Systems Engineering efforts are informed by Software Engineering issues (Software-Aware Systems Engineering)

Software has some unique properties including logical complexities that lead to an inherently defect laden product

Software and Systems Engineering professionals need to be wary of “Buzzwords” and “Silver Bullets”

All effort should help Scope the problem, Focus the team, and Deliver value

Contact Information

Brian Gallagher

Director, Acquisition Support Program

Software Engineering Institute

4500 Fifth Ave.

Pittsburgh, PA 15213-3890

(412) 268-7157

bg@sei.cmu.edu

Air ForceJohn Foreman, jtf@sei.cmu.edu

ArmyCecilia Albert, cca@sei.cmu.edu

NavyRick Barbour, reb@sei.cmu.edu

Intelligence CommunityRita Creel, rc@sei.cmu.edu

Civil AgenciesSteve Palmquist, msp@sei.cmu.edu

http://www.sei.cmu.edu/programs/acquisition-support

© 2007 carnegie mellon university managing the engineering of systems software engineering...

Documents

carnegie mellon university student organization catering...

intruder trends tom longstaff cert coordination center...

cert ® training and education networked systems...

integrating intelligent assistants into human teams katia...

© 2007 carnegie mellon university cmmi software engineering...

carnegie mellon university, pittsburgh pa 15213, usa arxiv

selecting middleware technologies - sei digital library ·...

object shape and reflectance modeling ... - robotics...

pittsburgh, pa 15213 carnegie-mellon university

disciplined software engineering lecture #10 software...

october 5-6, 2018 the tepper quad carnegie mellon...

carnegie mellon university 2017 fall...carnegie mellon...

modelchecking’s...

disciplined software engineering lecture #6 software...

efﬁcient cryptographic techniques for ... - computer...

disciplined software engineering lecture #12 software...

1 disciplined software engineering watts s. humphrey...

disciplined software engineering lecture #15 software...

stereo visual-inertial-lidar simultaneous …...dr. eric...

© 2015 carnegie mellon university parametric symbolic...