CTC Decision Making in Systems Engineering and Management Discussion

All questions and answers are in the textbook . Do exercises 9.1, 9.2, 9.3, 9.5, 9.6, 9.7a, 9.8

all answers are in chapter 9 of the text book uploaded

DECISION MAKING
IN SYSTEMS ENGINEERING
AND MANAGEMENT
DECISION MAKING
IN SYSTEMS ENGINEERING
AND MANAGEMENT
Second Edition
Edited by
GREGORY S. PARNELL
PATRICK J. DRISCOLL
DALE L. HENDERSON
A JOHN WILEY & SONS, INC., PUBLICATION
Copyright  2011 by John Wiley & Sons, Inc. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey
Published simultaneously in Canada
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as
permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior
written permission of the Publisher, or authorization through payment of the appropriate per-copy fee
to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400, fax
978-750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should
be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ
07030, 201-748-6011, fax 201-748-6008, or online at http://www.wiley.com/go/permission.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts
in preparing this book, they make no representations or warranties with respect to the accuracy or
completeness of the contents of this book and speciﬁcally disclaim any implied warranties of
merchantability or ﬁtness for a particular purpose. No warranty may be created or extended by sales
representatives or written sales materials. The advice and strategies contained herein may not be
suitable for your situation. You should consult with a professional where appropriate. Neither the
publisher nor author shall be liable for any loss of proﬁt or any other commerical damages, including
but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our
Customer Care Department within the United States at 877-762-2974, outside the United States at
317-572-3993 or fax 317-572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print
may not be available in electronic formats. For more information about Wiley products, visit our web
site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data:
Decision making in systems engineering and management / [edited by] Gregory S. Parnell, Patrick J.
Driscoll, Dale L. Henderson.— 2nd ed.
p. cm.—(Wiley series in systems engineering and management ; 79)
ISBN 978-0-470-90042-0 (hardback)
1. Systems engineering– Management. 2. Systems engineering– Decision making. I. Parnell,
Gregory S. II. Driscoll, Patrick J. III. Henderson, Dale L.
TA168.D43 2010
620.001 171–dc22
2010025497
Printed in the United States of America
oBook ISBN: 978-0-470-92695-6
ePDF ISBN: 978-0-470-92695-6
ePub ISBN: 978-0-470-93471-5
10
9
8
7
6
5
4
3
2
1
Systems engineers apply their knowledge, creativity, and
energy to making things better. Rarely do we assume
grave personal risk to do so.
We dedicate this book to our colleagues from the Department of Systems Engineering at The United States Military
Academy who have sacriﬁced their lives to make the
world a place where systems engineers are free to make
things better.
Contents
Foreword to the Second Edition
xvii
Foreword to the First Edition
xix
Preface to the Second Edition
xxi
Acknowledgments
xxv
Thoughts for Instructors
xxvii
Contributors
xxxiii
Acronyms
1
xli
Introduction
Gregory S. Parnell and Patrick J. Driscoll
1
1.1 Purpose
1.2 System
1.3 Stakeholders
1.4 System Life Cycle
1.5 Systems Thinking
1.6 Systems Engineering Thought Process
1.7 Systems Engineering
1.8 Engineering Management
1.9 Systems Decision Process
1.10 Overview
1.11 Exercises
References
1
3
3
7
10
12
13
15
16
21
21
23
vii
viii
CONTENTS
PART I
2
3
4
SYSTEMS THINKING
25
Systems Thinking
Patrick J. Driscoll
27
2.1 Introduction
2.2 Structure
2.3 Classiﬁcation
2.4 Boundaries
2.5 Visibility
2.6 IDEF0 Models
2.7 Mathematical Structure
2.8 Spatial Arrangement
2.9 Evolution
2.10 Summary
2.11 Exercises
References
27
32
33
35
39
40
50
54
58
58
59
63
System Life Cycle
Patrick J. Driscoll and Paul Kucik
65
3.1
3.2
Introduction
System Life Cycle Model
3.2.1 Establish System Need
3.2.2 Develop System Concept
3.2.3 Design and Develop System
3.2.4 Produce System
3.2.5 Deploy System
3.2.6 Operate System
3.2.7 Retire System
3.3 Other Major System Life Cycle Models
3.4 Risk Management in the System Life Cycle
3.4.1 Risk Identiﬁcation
3.4.2 Risk Assessment
3.4.3 Risk Mitigation
3.5 Summary
3.6 Exercises
References
65
68
70
70
70
71
72
72
73
74
77
78
83
88
89
90
92
Systems Modeling and Analysis
Paul D. West, John E. Kobza, and Simon R. Goerger
95
4.1
4.2
4.3
95
96
98
99
Introduction
Developing System Measures
Modeling the System Design
4.3.1 What Models Are
CONTENTS
4.3.2 Why We Use Models
4.3.3 Role of Models in Solution Design
4.3.4 Qualities of Useful Models
4.4 The Modeling Process: How We Build Models
4.4.1 Create a Conceptual Model
4.4.2 Construct the Model
4.4.3 Exercise the Model
4.4.4 Revise the Model
4.5 The Model Toolbox: Types of Models, Their Characteristics,
and Their Uses
4.5.1 Characteristics of Models
4.5.2 The Model Toolbox
4.6 Simulation Modeling
4.6.1 Analytical Solutions Versus Simulation; When It Is
Appropriate to Use Simulation
4.6.2 Simulation Tools
4.7 Determining Required Sample Size
4.8 Summary
4.9 Exercises
References
5
ix
99
101
102
104
105
106
107
108
109
112
114
121
122
123
129
131
132
134
Life Cycle Costing
Edward Pohl and Heather Nachtmann
137
5.1
5.2
137
139
143
145
145
Introduction to Life Cycle Costing
Introduction to Cost Estimating Techniques
5.2.1 Types of Costs
5.3 Cost Estimation Techniques
5.3.1 Estimating by Analogy Using Expert Judgment
5.3.2 Parametric Estimation Using Cost Estimating
Relationships
5.3.3 Learning Curves
5.4 System Cost for Systems Decision Making
5.4.1 Time Value of Money
5.4.2 Inﬂation
5.4.3 Net Present Value
5.4.4 Breakeven Analysis and Replacement Analysis
5.5 Risk and Uncertainty in Cost Estimation
5.5.1 Monte Carlo Simulation Analysis
5.5.2 Sensitivity Analysis
5.6 Summary
5.7 Exercises
References
146
160
167
168
168
171
172
172
173
177
178
178
181
x
CONTENTS
PART II SYSTEMS ENGINEERING
183
6
Introduction to Systems Engineering
Gregory S. Parnell
185
6.1
6.2
6.3
6.4
6.5
6.6
185
185
186
186
189
Introduction
Deﬁnition of System and Systems Thinking
Brief History of Systems Engineering
Systems Trends that Challenge Systems Engineers
Three Fundamental Tasks of Systems Engineers
Relationship of Systems Engineers to Other Engineering
Disciplines
6.7 Education, Training, and Knowledge of Systems Engineers
6.7.1 Next Two Chapters
6.8 Exercises
Acknowledgment
References
7
192
192
193
193
194
194
Systems Engineering in Professional Practice
Roger C. Burk
197
7.1
197
199
199
199
200
201
202
202
202
203
203
203
203
203
203
205
205
206
206
206
207
207
207
208
7.2
7.3
The Systems Engineer in the Engineering Organization
The Systems Engineering Job
Three Systems Engineering Perspectives
Organizational Placement of Systems Engineers
Systems Engineering Activities
Establish System Need
Develop System Concept
Design and Develop the System
Produce System
Deploy System
Operate System
Retire System
Working with the Systems Development Team
The SE and the Program Manager
The SE and the Client, the User, and the Consumer
The SE and the CTO or CIO
The SE and the Operations Researcher or System Analyst
The SE and the Conﬁguration Manager
The SE and the Life Cycle Cost Estimator
The SE and the Engineering Manager
The SE and the Discipline Engineer
The SE and the Test Engineer
The SE and the Specialty Engineer
The SE and the Industrial Engineer
CONTENTS
The SE and Quality Assurance
Building an Interdisciplinary Team
Team Fundamentals
Team Attitude
Team Selection
Team Life Cycle
Cross-Cultural Teams
7.5 Systems Engineering Responsibilities
Systems Engineering Management Plan (SEMP)
Technical Interface with Users and Consumers
Analysis and Management of Systems Requirements
System Architecting
Systems Engineering Tools and Formal Models
Interface Control Documents (ICDs)
Test and Evaluation Master Plan (TEMP)
Conﬁguration Management (CM)
Specialty Engineering
Major Program Technical Reviews
System Integration and Test
7.6 Roles of the Systems Engineer
7.7 Characteristics of the Ideal Systems Engineer
7.8 Summary
7.9 Exercises
Acknowledgment
References
208
208
208
209
210
210
211
212
212
213
213
216
217
218
218
218
218
220
221
221
222
223
224
225
225
System Reliability
Edward Pohl
227
8.1
8.2
8.3
227
228
229
233
242
244
245
245
247
247
249
249
250
250
253
253
7.4
8
xi
8.4
8.5
8.6
8.7
Introduction to System Effectiveness
Reliability Modeling
Mathematical Models in Reliability
8.3.1 Common Continuous Reliability Distributions
8.3.2 Common Discrete Distributions
Basic System Models
8.4.1 Series System
8.4.2 Parallel System
8.4.3 K -out-of-N Systems
8.4.4 Complex Systems
Component Reliability Importance Measures
8.5.1 Importance Measure for Series System
8.5.2 Importance Measure for Parallel System
Reliability Allocation and Improvement
Markov Models of Repairable Systems
8.7.1 Kolmogorov Differential Equations
xii
CONTENTS
8.7.2 Transient Analysis
8.7.3 Steady-State Analysis
8.7.4 CTMC Models of Repairable Systems
8.7.5 Modeling Multiple Machine Problems
8.7.6 Conclusions
8.8 Exercises
References
254
256
256
258
263
263
271
PART III SYSTEMS DECISION MAKING
273
9
Systems Decision Process Overview
Gregory S. Parnell and Paul D. West
275
9.1
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
275
276
278
280
282
283
284
285
286
289
289
289
289
290
Introduction
Value-Focused Versus Alternative-Focused Thinking
Decision Quality
Systems Decision Process
Role of Stakeholders
Role of Decision Makers
Environment
Comparison with Other Processes
When to Use the Systems Decision Process
9.9.1 Need
9.9.2 Resources
9.9.3 Decision Maker and Stakeholder Support
9.10 Tailoring the Systems Decision Process
9.11 Example Use of the Systems Decision Process
9.12 Illustrative Example: Systems Engineering Curriculum
Management System (CMS)—Summary and Introduction
9.13 Exercises
Acknowledgment
References
10 Problem Deﬁnition
Timothy Trainor and Gregory S. Parnell
10.1 Introduction
10.1.1 The Problem Deﬁnition Phase
10.1.2 Comparison with Other Systems Engineering Processes
10.1.3 Purpose of the Problem Deﬁnition Phase
10.1.4 Chapter Example
10.2 Research and Stakeholder Analysis
10.2.1 Techniques for Stakeholder Analysis
10.2.2 Stakeholder Analysis for the Rocket System Decision
Problem
10.2.3 At Completion
290
293
294
294
297
297
298
299
300
300
300
302
313
314
xiii
CONTENTS
10.3 Functional and Requirements Analyses
10.3.1 Terminology
10.3.2 Importance of Functional Analysis
10.3.3 Functional Analysis Techniques
10.3.4 Requirements Analysis
10.3.5 At Completion
10.4 Value Modeling
10.4.1 Deﬁnitions Used In Value Modeling
10.4.2 Qualitative Value Modeling
10.4.3 Quantitative Value Model
10.4.4 At Completion of Value Modeling
10.5 Output of the Problem Deﬁnition Phase
10.5.1 Discussion
10.5.2 Conclusion
10.6 Illustrative Example: Systems Engineering Curriculum
Management System (CMS)—Problem Deﬁnition
10.7 Exercises
References
11 Solution Design
Paul D. West
11.1
11.2
11.3
11.4
11.5
11.6
Introduction to Solution Design
Survey of Idea Generation Techniques
11.2.1 Brainstorming
11.2.2 Brainwriting
11.2.3 Afﬁnity Diagramming
11.2.4 Delphi
11.2.5 Groupware
11.2.6 Lateral and Parallel Thinking and Six Thinking Hats
11.2.7 Morphology
11.2.8 Ends–Means Chains
11.2.9 Existing or New Options
11.2.10 Other Ideation Techniques
Turning Ideas into Alternatives
11.3.1 Alternative Generation Approaches
11.3.2 Feasibility Screening
Analyzing Candidate Solution Costs
Improving Candidate Solutions
11.5.1 Modeling Alternatives
11.5.2 Simulating Alternatives
11.5.3 Design of Experiments
11.5.4 Fractional Factorial Design
11.5.5 Pareto Analysis
Summary
314
315
315
316
324
325
326
326
327
331
340
340
340
341
341
350
350
353
353
355
355
358
358
358
361
361
361
363
363
363
365
365
366
368
369
369
369
370
376
386
388
xiv
CONTENTS
11.7
Illustrative Example: Systems Engineering Curriculum
Management System (CMS)—Solution Design
11.8 Exercises
References
12 Decision Making
Michael J. Kwinn, Jr., Gregory S. Parnell, and Robert A. Dees
12.1
12.2
Introduction
Preparing to Score Candidate Solutions
12.2.1 Revised Problem Statement
12.2.2 Value Model
12.2.3 Candidate Solutions
12.2.4 Life Cycle Cost Model
12.2.5 Modeling and Simulation Results
12.2.6 Conﬁrm Value Measure Ranges and Weights
12.3 Five Scoring Methods
12.3.1 Operations
12.3.2 Testing
12.3.3 Modeling
12.3.4 Simulation
12.3.5 Expert Opinion
12.3.6 Revisit Value Measures and Weights
12.4 Score Candidate Solutions or Candidate Components
12.4.1 Software for Decision Analysis
12.4.2 Candidate Solution Scoring and Value Calculation
12.4.3 Candidate Components Scoring and System
Optimization
12.5 Conduct Sensitivity Analysis
12.5.1 Analyzing Sensitivity on Weights
12.5.2 Sensitivity Analysis on Weights Using Excel
12.6 Analyses of Uncertainty and Risk
12.6.1 Risk Analysis—Conduct Monte Carlo Simulation on
Measure Scores
12.7 Use Value-Focused Thinking to Improve Solutions
12.7.1 Decision Analysis of Dependent Risks
12.8 Conduct Cost Analysis
12.9 Conduct Cost/Beneﬁt Analysis
12.10 Decision-Focused Transformation (DFT)
12.10.1 Transformation Equations
12.10.2 Visual Demonstration of Decision-Focused
Transformation
12.10.3 Cost/Beneﬁt Analysis and Removal of Candidate
Solutions
12.11 Prepare Recommendation Report and Presentation
388
390
391
395
395
396
396
397
397
397
397
397
398
398
398
399
399
399
400
400
401
402
404
409
410
411
412
413
417
419
423
423
424
425
427
427
432
xv
CONTENTS
12.11.1 Develop Report
12.11.2 Develop Presentation
12.12 Prepare for Solution Implementation
12.13 Illustrative Example: Systems Engineering Curriculum
Management System (CMS)—Decision Making
12.13 Exercises
References
13 Solution Implementation
Kenneth W. McDonald and Daniel J. McCarthy
13.1
13.2
13.3
13.4
13.5
13.6
13.7
13.8
Introduction
Solution Implementation Phase
The Initiating Process
Planning
Executing
Monitoring and Controlling
Closing
Implementation During Life Cycle Stages
13.8.1 Implementation in “Produce the System”
13.8.2 Implementation in “Deploy the System”
13.8.3 Implementation in “Operate the System”
13.9 Exercises
References
14 Summary
Gregory S. Parnell
14.1
14.2
Systems Thinking—Key to Systems Decision Making
14.1.1 Systems Thinking Reveals Dynamic Behavior
14.1.2 The System Life Cycle Must Be Considered
14.1.3 Modeling and Simulation—Important Tools
14.1.4 The System Life Cycle Is a Key Risk Management
Tool
14.1.5 Life Cycle Costing Is an Important Tool for Systems
Engineering
Systems Engineers Play a Critical Role in the System Life
Cycle
14.2.1 Systems Engineers Lead Interdisciplinary Teams to
Obtain System Solutions that Create Value for
Decision Makers and Stakeholders
14.2.2 Systems Engineers Convert Stakeholder Needs to
System Functions and Requirements
14.2.3 Systems Engineers Deﬁne Value and Manage System
Effectiveness
433
434
439
439
443
446
447
447
449
452
453
457
458
461
462
462
464
466
474
475
477
478
478
478
479
479
479
480
480
480
480
xvi
CONTENTS
14.2.4
14.3
14.4
Systems Engineers Have Key Roles Throughout the
System Life Cycle
A Systems Decision Process Is Required for Complex Systems
Decisions
14.3.1 Problem Deﬁnition Is the Key to Systems Decisions
14.3.2 If We Want Better Decisions, We Need Better System
Solution Designs
14.3.3 We Need to Identify the Best Value for the Resources
14.3.4 Solution Implementation Requires Planning,
Executing, and Monitoring and Controlling
Systems Engineering Will Become More Challenging
Appendix A
Index
SDP Trade Space Concepts
481
481
481
482
482
482
483
485
491
Foreword to the Second Edition
The ﬁrst edition of this book was developed by the faculty of the Department of
Systems Engineering at the United States Military Academy and two colleagues at
the University of Arkansas. We used the book in draft and ﬁnal form for four years
as a text for undergraduate courses and professional continuing education courses
for systems engineers and engineering managers, and the book has been used as
a text for undergraduate and graduate courses at other universities. In addition,
we used the foundational material on systems thinking, systems engineering, and
systems decision making on very diverse and important research and consulting
projects by our students and faculty. The development and use of this text resulted
in restructuring part of our curriculum and has signiﬁcantly improved our academic
programs and the research of our faculty and our students.
However, we have continued to develop new material and reﬁne the techniques
that we use to present the material. The second edition keeps the problem-solving
focus on systems thinking, systems engineering, and systems decision making but
incorporates our learning based on teaching students and helping senior leaders
solve signiﬁcant challenges in many important problem domains.
The major changes include an increased focus on risk analysis as a key tool
for systems thinking and decision making; explicit inclusion of cost analysis in our
solution design phase; additional techniques for the analysis of uncertainty and risk
in the decision making phase; and a revised solution implementation chapter more
aligned with project management literature.
With the new material, this second edition can be used as an undergraduate or
a graduate text in systems engineering, industrial engineering, engineering management, and systems management programs. In addition, the book is an excellent
resource for engineers and managers whose professional education is not in systems
engineering or engineering management.
xvii
xviii
FOREWORD TO THE SECOND EDITION
We hope that the material in this book will improve your problem solving skills
by expanding your system thinking ability, increasing your understanding of the
roles of systems engineers, and improving the systems decision making processes
required to solve the complex challenges in your organization.
Brigadier General Tim Trainor, Ph.D.
Dean of the Academic Board
United States Military Academy
West Point, New York
September 2010
Foreword to the First Edition
The Department of Systems Engineering is the youngest academic department at the
United States Military Academy. Established in 1989, the department has developed
into an entrepreneurial, forward-looking organization characterized by its unique
blend of talented military and civilian faculty. This book is our effort to leverage
that talent and experience to produce a useful undergraduate textbook focusing
on the practical application of systems engineering techniques to solving complex
problems. Collectively, the authors bring nearly two centuries of experience in both
teaching and practicing systems engineering and engineering management. Their
work on behalf of clients at the highest levels of government, military service,
and industry spans two generations and a remarkably broad range of important,
challenging, and complex problems. They have led thousands of systems engineering, engineering management, information engineering, and systems management
students through a demanding curriculum focused on problem solving.
Teaching systems engineering at the undergraduate level presents a unique set
of challenges to both faculty and students. During the seven years I served as the
department head, we searched for a comprehensive source on systems engineering
for undergraduates to no avail. What we found was either too narrowly focused on
speciﬁc areas of the systems engineering process or more intended for practitioners
or students in masters or doctoral programs.
While conceived to ﬁll the need for an undergraduate textbook supporting the
faculty and cadets of the United States Military Academy, it is designed to be
used by faculty in any discipline at the undergraduate level and as a supplement to
graduate level studies for students who do not have a formal education or practical
experience in systems engineering.
xix
xx
FOREWORD TO THE FIRST EDITION
The book is organized around the principles we teach and apply in our research
efforts. It goes beyond exposing a problem-solving procedure, offering students
the opportunity to grow into true systems thinkers who can apply their knowledge
across the full spectrum of challenges facing our nation.
Brigadier General (Ret.) Michael McGinnis, Ph.D.
Formerly
Professor and Head ,
Department of Systems Engineering, 1999–2006
United States Military Academy
Executive Director
Peter Kiewit Institute
University of Nebraska
Preface to the Second Edition
WHAT IS THE PURPOSE OF THE BOOK?
The purpose of this book is to contribute to the education of systems engineers
by providing them with the concepts and tools to successfully deal with systems
engineering challenges of the twenty-ﬁrst century. The book seeks to communicate to the reader a philosophical foundation through a systems thinking world
view, a knowledge of the role of systems engineers, and a systems decision process (SDP) using techniques that have proven successful over the past 20 years
in helping to solve tough problems presenting signiﬁcant challenges to decision
makers. This SDP applies to major systems decisions at any stage of their system
life cycle. The second edition makes several important reﬁnements to the SDP
based on our teaching and practice since the ﬁrst edition was published in 2008.
A sound understanding of this approach provides a foundation for future courses
in systems engineering, engineering management, industrial engineering, systems
management, and operations research.
WHAT IS THIS BOOK?
This book provides a multidisciplinary framework for problem solving that uses
accepted principles and practices of systems engineering and decision analysis.
It has been constructed in a way that aligns with a structure moving from the
broad to the speciﬁc, using illustrative examples that integrate the framework and
demonstrate the principles and processes for systems engineering. The book is
xxi
xxii
PREFACE TO THE SECOND EDITION
not a detailed engineering design book nor a guide to system architecting. It is a
complement to engineering design and system architecting. It introduces tools and
techniques sufﬁcient for a complete treatment of systems decision making with
references for future learning. The text blends the mathematics of multiple objective
decision analysis with select elements of stakeholder theory, multi-attribute value
theory, risk analysis, and life cycle cost analysis as a foundation for trade studies
and the analysis of design solutions.
WHO IS THIS BOOK FOR?
The ﬁrst edition of this book was intended primarily to be a textbook for an undergraduate course that provides an introduction to systems engineering or systems
management. Based on the recommendations and requests from a host of academic
and professional practitioners, this second edition extends much of the existing
material and adds new material to enable the book to be comfortably adopted as
a graduate text or a text in support of professional continuing education while
remaining a valuable resource for systems engineering professionals. The book
retains all of the features that readers identiﬁed as useful for any individual who
is leading or participating in a large, complex systems engineering or engineering
management process. Not surprisingly, readers of the ﬁrst edition have highlighted
the usefulness of the approach we present to other disciplines as well, such as
human factors engineering, law, history, behavioral sciences, and management, in
which the object of focus can be conceptualized as a system.
WHY DID WE WRITE THIS BOOK?
We authored the ﬁrst edition of this book to ﬁll a critical gap in available resources
that we (and others) needed to support systems engineering projects that our faculty,
and hence our students as future systems engineers, were being asked to engage
with concerning high-visibility, high-impact systems in both government and corporate settings. Moreover, it was nearly always the case in these projects that key
stakeholders vested in the potential solutions demanded-large amounts of decision support throughout the engagement horizon. Thus, systems engineering with
a systems decision-making emphasis had evolved to be our primary professional
practice with clients and yet the ﬁeld was lacking a single source that students and
practitioners could turn to for guidance.
Speciﬁcally, there were three immediate needs driving us to the task. First,
we needed a textbook for our lead-in systems engineering courses offered by the
Department of Systems Engineering at the United States Military Academy at West
Point. Second, we needed to more fully describe the problem solving process that
we developed and successfully applied since the Systems Engineering Department
was formed in 1989. The process introduced in this book, called the systems decision process (SDP), is the reﬁned version of this process we currently use. Lastly,
PREFACE TO THE SECOND EDITION
xxiii
we wanted to document the problem solving lessons we have learned by hard
knocks, happenstance, and good fortune as leaders, military ofﬁcers, engineering
managers, systems engineers, teachers, and researchers.
We teach two foundational systems engineering undergraduate courses at West
Point that serve a broad clientele. SE301, Foundations of Engineering Design and
System Management, is the ﬁrst course we offer to our approximately 100 academic
majors each year. These majors include systems engineering, engineering management, and systems management. The ﬁrst two of these are programs accredited by
ABET Inc.
This is the course where our faculty make “ﬁrst contact” with each new class of
talented students. Based on a host of discussions with students, faculty, and external
stakeholders to our curriculum, we concluded that this needed to be the ﬂagship
course of the department, taught by our most experienced faculty; to communicate a
fundamentally different thought process than that emphasized by other engineering
ﬁelds; and to change the way our students thought about problem solving and their
role in the process. Moreover, the course needed to set the professional standards
required to put our students in front of real-world clients with real-world systems
decision problems at the start of their senior year, to support the requirement of
their year-long senior capstone experience.
The other course, SE300, Introduction to Systems Engineering, is the ﬁrst course
in a three-course Systems Engineering sequence taken by 300–400 nonengineering
majors each year. Rather than simply providing an introduction to a ﬁeld that was
not their academic major, we structure this course to deliver value to the students
both in their chosen majors and as future decision makers in their role as military
ofﬁcers. These design considerations became part of our plan for the ﬁrst edition
of the textbook, and we retained these for the second edition as well.
HOW DID WE WRITE THE BOOK?
We wrote the book in the manner that we advocate good systems engineering be
applied in practice. The editors led a team effort that leveraged the expertise of
each of the authors, several of whom were personally responsible for the structure
of the downstream courses for each of our academic majors. In this manner, each
author could craft critical material in direct support of later courses so that the
book retained value as a reference beyond the initial program course.
A host of regularly scheduled collaboration and communication sessions were
used to develop and reﬁne the terminology, content, and voice used throughout the
book. The concept maps in each chapter serve two purposes. First, they deﬁne the
key concepts of the chapter. Second, they help us identify a common lexicon for the
book. Since the book includes a systems decision process, we tried to incorporate
several illustrative examples as an integrating tool that would carry the reader
through the various systems decision process chapters. Our faculty and students
read and evaluated each of the chapters for clarity, consistency, and ease of use.
As with most iterative processes, we learned a great deal about our own programs
in the process. The writing of this book became a wonderful means of cross-leveling
xxiv
PREFACE TO THE SECOND EDITION
knowledge and understanding among the faculty as to the emphasis and content
that was being taught across our curriculum. This book and the approach contained within have signiﬁcantly contributed to our curriculum assessment process,
enabling us to more clearly articulate program and course outcomes and objectives
in a manner that communicates value return while aligning with accepted professional standards. Valuable feedback from faculty and students using the initial three
preliminary printings and the ﬁrst edition has been incorporated into this edition.
HOW IS THIS BOOK ORGANIZED?
The book is organized in three parts. Part I provides an introduction to systems
thinking, system life cycles, risk management, systems modeling and analysis, and
life cycle costing. Part II provides an introduction to systems engineering, the
practice of systems engineering, and systems effectiveness. Part III introduces the
systems decision process (SDP) and describes the four phases of our systems decision process: problem deﬁnition, solution design, decision making, and solution
implementation, in addition to the primary environmental factors that house important stakeholders and their vested interests. The systems decision process can be
used in all stages of a system life cycle. The ﬁnal chapter provides a summary of
the book.
Gregory S. Parnell and Patrick J. Driscoll
West Point, New York
July 2010
Acknowledgments
We would like to acknowledge several individuals for their contributions and
support for this second edition. Our design editor, Dale Henderson, again did a
superb job on many design details that add quality to this work. The department
leadership under COL Robert Kewley continues to provide great support and
encouragement for the project. Thanks also go to many of the U.S. Military
Academy Department of Systems Engineering faculty contributed to what was to
become the Systems Decision Process (SDP).
The editors would like to thank the chapter authors for their hard work and
ﬂexibility as we deﬁned and reﬁned many of the concepts included in the book.
Crafting a text such as this is a challenging undertaking. Having a tight production
schedule adds to this challenge in a signiﬁcant way. Their continuing level of
patience, professionalism, and commitment to the project is acknowledged with
our heartfelt gratitude.
A great example of this ﬂexibility was how the Rocket Problem, developed for
the ﬁrst edition by Dr. Paul West, was quickly accepted and used as the example
to present the concepts in Chapters 10–13. It continues to prove its usefulness for
many of the extended concepts and new material of this second edition. We would
also like to acknowledge COL Kewley’s development of the Curriculum Management System example, along with the real system that has been implemented at
our institution as a result. We also thank COL Donna Korycinski for a very careful
read of the initial manuscript and many helpful suggestions for clariﬁcation.
xxv
xxvi
ACKNOWLEDGMENTS
We continue to extend thanks to the many, many cadets who have taken courses
in the Department of Systems Engineering. We honor their commitment to service
with our best efforts to inspire and lead them. Their enthusiasm and high standards
make us all better teachers and better leaders. Finally, the entire project team would
like to thank their families for their selﬂess support and encouragement during this
demanding book project.
G. S. P.
P. J. D.
Thoughts for Instructors
COURSE DESIGN USING THE BOOK
This book has been designed as a systems engineering and management textbook
and as a reference book for systems engineers and managers. There are lots of ways
to use this material for undergraduate and graduate courses. Chapter 1 is always a
good place to start! Part I (Chapters 2 through 5) present systems thinking. Most
courses would probably want to start with at least Chapters 2 and 3 to set a good
foundation in systems thinking and the system life cycle. Chapters 4 and 5 can be
introduced next or during presentation of the systems decision process in Part III.
Part III is designed to be presented sequentially but is based on knowledge provided
in Chapter 1 through Chapter 5. Chapters 6 and 7 introduce systems engineering and
describe systems engineering practice. They can be presented before or after Part
III. The most advanced mathematics of the book is in Chapter 8, and Chapter 11,
Section 11.4. These can be omitted in an introductory course since they may be
covered in other courses in your student’s academic program. Instructors will want
to supplement the course with additional material.
AN EXAMPLE UNDERGRADUATE COURSE DESIGN
We use the text for our undergraduate systems engineering and management
fundamentals course, our introduction to systems engineering course for
nonengineering majors, and our year long capstone design course for academic
majors. The fundamentals course is taken by our systems engineering, engineering
management, and systems management majors, whereas the introductory course is
the ﬁrst of a three course systems engineering sequence taken annually by about
xxvii
xxviii
THOUGHTS FOR INSTRUCTORS
350–400 students. The capstone design course is the ﬁnal, integrative experience
for our students. We have found it useful to have the students learn the systems
decision process from three perspectives: a personal systems decision with known
or relatively easy to determine alternatives (e.g., buying a car); a complex systems
integration problem involving multiple decision makers and stakeholders (e.g.,
adding new components to perform new missions with an existing unmanned
aircraft system); and a complex systems design involving multiple stakeholders
with challenging implementation issues (e.g., the IT illustrative example presented
at the end of each chapter in Part III of the text).
Figure 0.1 provides the ﬂow of the course material using this approach. We
begin with Chapters 1 through 3 to provide an introduction to the course material
Figure 0.1 Course design with two projects and one illustrative example.
THOUGHTS FOR INSTRUCTORS
xxix
and a good understanding of systems thinking and the system life cycle. Next, we
introduce Project 1, a system decision problem that the students may encounter
in which, as the assumed primary decision maker, they can easily determine their
values, solution alternatives, measure scores, and basic life cycle costs. Example
problems might be buying a car or selecting a graduate program of study. The
students read Chapter 9 and the introductory parts of the four chapters describing
the four phases in the systems decision process (Chapters 10–13). They then apply
these concepts to their system decision problem. The effort culminates with a presentation and a paper that demonstrate the degree to which each student understands
the multiple objective decision analysis (MODA) mathematics used to evaluate the
value of the alternatives. Following this, we present the fundamentals and the practice of systems engineering using Chapters 6 and 7. This is also a good time to
give the ﬁrst exam.
Next, we introduce Project 2. For this project, we look to a systems integration
and/or systems design project that has one or more decision makers and multiple
stakeholders inﬂuencing the system requirements and subsequent trade space. We
require the students to perform more extensive research, stakeholder interviews
and surveys to develop the data and modeling components required by the MODA
approach. Proceeding to Chapters 10 to 13, we introduce additional material to
help the students address design and analysis issues associated with more complex systems decision problems. Modeling and simulation techniques introduced in
Chapter 4 are used for solution design and evaluation. Time permitting, we include
material from Chapter 5 addressing life cycle cost estimating.
While the students are completing their analysis of Project 2, we discuss the
design of a system from system need to implementation. The IT illustrative example
presented at the end of Chapters 9–13 was included in the book to provide an
example of a complete application of the systems decision process. We conclude
the Project 2 effort with student presentations and a summary of the course.
EXAMPLE GRADUATE PROGRAM SUPPORT
As mentioned previously, we received a signiﬁcant number of suggestions for
enhancements to the book from academicians and practitioners since the publication
of the ﬁrst edition. A number of these expressed a desire to use the book in support
of their graduate programs or for workshops they were offering as continuing
professional education. Figure 0.2 shows one perspective that might be helpful in
this regard. It describes how that each chapter might support program and course
objectives for a select number of graduate programs listed. It is intended purely as
illustrative course topic coverage based on the editors’ experience teaching courses
in these types of programs. Any speciﬁc curriculum design would and should
obviously be driven by the academic program speciﬁcs and course objectives.
In addition, several of the chapters include material and associated mathematical
content that may be appropriate for advanced undergraduate or graduate courses.
These are predominantly:
xxx
THOUGHTS FOR INSTRUCTORS
Program
Industrial & Systems
Engineering
Chapter
Acquisition Management/
Engineering Management Traditional Engineering Professional Continuing
Education
1.
Introduction
Introduces key systems
concepts and role of
stakeholders
Introduces key systems
concepts and role of
stakeholders
Introduces key systems
concepts and role of
stakeholders
Introduces key systems
concepts and role of
stakeholders
2.
Systems
Thinking
Foundational systems
thinking principles and
techniques
Foundational systems
thinking principles and
techniques
Foundational systems
thinking principles and
techniques
Foundational systems
thinking principles and
techniques
Importance of life cycle
and risk management for
system management
Importance of life cycle and
risk management for system
engineered solutions
Optional
3.
Importance of life cycle and
Systems Life
risk management for system
Cycle
solutions
Introduces roles and
techniques of M&S in
systems analysis
Introduces roles and
techniques of M&S in
systems analysis
4.
Systems
Modeling &
Analysis
5.
Life Cycle
Costing
Supplements engineering Supplements engineering Foundational cost analysis Foundational cost analysis
economy course
economy course
principles and techniques principles and techniques
6.
Introduction
to SE
Provides setting and context
Provides setting and
Provides setting and
Provides setting and
for SE and system
context for SE and system context for SE and system context for SE and system
complexity
complexity
complexity
complexity
7.
SE in
Professional
Practice
8.
Systems
Reliability
Overview of systems
effectiveness principles and
techniques
9.
Systems
Decision
Process
Overview
Useful to introduce and
compare SDP with other
DM processes
10. Problem
Definition
11. Solution
Design
12. Decision
Making
13. Solution
Implementation
14. Summary
Help system engineers
understand the roles and
activities of SEs
Introduces roles of M&S in Introduces roles of M&S in
systems analysis
systems analysis
Helps engineering
Help traditional engineers Helps acquisition manager
manager understand the
understand the role of SE understand the role of SE
roles of SE
Optional
Overview of systems
effectiveness principles
and techniques
Useful to introduce and Useful to introduce and
compare SDP with other compare SDP with other
DM processes
DM processes
Optional
Useful to introduce and
compare SDP with other
DM processes
Emphasizes importance of Emphasizes importance of Emphasizes importance of Emphasizes importance of
problem definition and
problem definition and
problem definition and
problem definition and
demonstrates key
demonstrates key
demonstrates key
demonstrates key
qualitative techniques
qualitative techniques
qualitative techniques
qualitative techniques
Teaches fundamental
system design principles
and techniques
Teaches fundamental
Teaches fundamental
Shows relationship of
system design principles traditional engineering system design principles
and techniques
and techniques
design in systems design
Demonstrates sound
Demonstrates sound
Demonstrates sound
Demonstrates sound
mathematical techniques
mathematical techniques
mathematical techniques
mathematical techniques
for trade studies and
for trade studies and
for trade studies and
for trade studies and
analysis of alternatives and analysis of alternatives and analysis of alternatives and analysis of alternatives and
presentations to DMs
presentations to DMs
presentations to DMs
presentations to DMs
Introduces key project
management techniques
Reinforces project
Introduces key project
Reinforces project
management techniques management techniques management techniques
Summarizes key messages Summarizes key messages
of the book
of the book
Optional
Optional
Figure 0.2 Example graduate program topical support.
•
•
•
•
Chapter 5: Life Cycle Costing, CER
Chapter 8: System Reliability
Chapter 11: Solution Design (section on experimental design and response
surface methodology)
Chapter 12: Decision Making (the sections on Decision-Focused Transformation, Monte Carlo simulation, and decision trees)
xxxi
THOUGHTS FOR INSTRUCTORS
Presentation and
decision quality
Bottom line up
front
1. Appropriate
frame
2. Creative
doable
alternatives
3. Meaningful,
reliable
information
Criteria and grade
Worst
Adequate
Very good
0
7
9
10
Not used
One bullet chart that
summarizes the major
results.
Bullet and graphs or
pictures that illustrate
the major results.
Briefing could be
presented in one
chart.
0
14
18
20
No problem
definition
Problem definition based
on stakeholder analysis
performed using
interviews and surveys.
Findings, conclusions,
and recommendations.
Insightful problem
definition clearly
supported by
stakeholder analysis.
New insights
provided to the
client.
0
14
18
20
No alternatives
Alternative generation
table used to generate
feasible alternatives.
Alternatives identified
that have potential to
provide high value.
Create alternatives
client has not
considered.
0
14
18
20
Appropriate sources.
Very credible
sources.
36
40
No
Adequate documentation
documentation
for values and scores.
on presentation. Assumptions identified.
28
0
4. Clear values
and tradeoffs
No value modal
Ideal
Value model (measures
aligned with system
functions), value
Clear, meaningful
Insightful objectives
functions, and swing
objectives and credible
and direct
weight model
measures.
measures.
implemented without
errors.
14
18
20
Value versus cost plot
presented and
interpretated correctly.
Logic for
recommendation
explained in three
sentences.
Logic for
recommendation
explained in one
sentences.
0
14
18
20
6. Commitment to
action
No discussion
of
implementation
Implementation plan
presented using WBS
and performance
measures. Key risks
identified.
Clean plan to reduce
implementation risk.
Identified
stakeholders who
may not support
and develop plan to
obtain their support.
Total
0
105
135
150
0
5. Logically
No rotational for
correct reasoning recommendations
Figure 0.3
A systems-based, project evaluation rubric.
DECISION ANALYSIS SOFTWARE
The text is designed to be independent of software. All of multiple objective decision analysis in Chapter 12 can be performed in a spreadsheet environment. For
the case of Microsoft Excel, macros that perform a linear interpolation useful for
converting measure scores to units of value via value functions exist (Kirkwood,
xxxii
THOUGHTS FOR INSTRUCTORS
1997).1 In several of the illustrative examples, we call upon the Excel Solver to
support component optimization. Any similar utility within other spreadsheet software would serve this purpose just as well. Certainly, one alternative to using a
spreadsheet would be to employ decision analysis software, a number of which we
highlight in this text where appropriate. Any Excel templates we use are available
upon request from the editors.
STUDENT EVALUATION
Systems engineers face a continuing challenge of balancing robust processes with
quality content. Creative ideas without a solid systems decision process will seldom
be defended and successfully implemented. However, a wonderful, logical process
is of little value without creativity and innovation. We believe we must impart to
our students the importance of both process and creativity without sacriﬁcing the
beneﬁts of either. Consequently, we used the concepts introduced in this book—the
systems decision process, quality decisions, and presentation guidance—to develop
a project grading mechanism that rewards both process and content. Figure 0.3
shows our Project 2 grading sheet. The decision quality terms in the ﬁrst column
are explained in Chapter 9. Insofar as grades are concerned, a student able able
to perform the process correctly will earn a “C.” Performing the process and having very good context will earn a “B.” Demonstrating a mastery of the process,
appropriate creativity, and producing outstanding insights will typically result in a
grade of “A.” We have found this grading approach helpful for recognizing student
performance and for conveying course expectations.
FINAL THOUGHT
While we have attempted to incorporate all the suggestions and great ideas we have
received from readers of the ﬁrst edition, we wholeheartedly recognize the value
of continuous improvement. Thus, while we are certainly limited in the degree to
which the outstanding publication staff at Wiley allow us to alter content between
printings without engaging in a third edition, we welcome feedback and suggestions
whenever they occur.
Gregory S. Parnell and Patrick J. Driscoll
West Point, New York
July 2010
1
Kirkwood, CW. Strategic Decision Making: Multiple Objective Decision Analysis with Spreadsheets.
Paciﬁc Grove, CA: Duxbury Press, 1997.
Contributors
Roger C. Burk, Ph.D. Dr. Burk is an Associate Professor in the Department of
Systems Engineering at the United States Military Academy (USMA) at West
Point. He retired from the (U.S.) Air Force after a career in space operations,
space systems analysis, and graduate-level instruction; afterwards he worked in
industry as a systems engineer supporting national space programs before joining
the USMA faculty. He teaches courses in statistics, decision analysis, mathematical modeling, systems engineering, and systems acquisition and advises senior
research projects. He also consults in the areas of decision analysis and mathematical modeling in the space and national defense domains. Dr. Burk has a
bachlor in Liberal Arts from St. John’s College, Annapolis; an M.S. in Space
Operations from the Air Force Institute of Technology; and a Ph.D. in Operations Research from the University of North Carolina at Chapel Hill. He is a
member of the Institute for Operations Research and the Management Sciences,
the Military Operations Research Society, the American Society for Engineering
Education, and Alpha Pi Mu.
Robert A. Dees, M.S. Major Robert Dees is an instructor and senior analyst with
the Department of Systems Engineering at United States Military Academy.
MAJ Dees has degrees in Engineering Management (United States Military
Academy) and Industrial and Systems Engineering (M.S. Texas A&M University). MAJ Dees conducts applications research in the ﬁelds of decision analysis,
systems engineering, and simulation for the U.S. Department of Defense and is
an integral part of the teaching faculty at USMA. He is a member of the Military
Applications Society of the Institute for Operations Research and the Management Sciences, the Decision Analysis Society of the Institute for Operations
xxxiii
xxxiv
CONTRIBUTORS
Research and the Management Sciences, and the Military Operations Research
Society.
Patrick J. Driscoll, Ph.D. Dr. Pat Driscoll is a Professor of Operations Research
at the United States Military Academy at West Point. He has systems experience
modeling and improving a wide range of systems including university academic
timetabling, information quality in supply chains, vulnerability and risk propagation in maritime transportation, infrastructure modeling and analysis, and
value structuring in personnel systems. He also serves on the boards of several
nonproﬁt organizations. Dr. Driscoll has degrees in Engineering (U.S. Military
Academy, West Point), Operations Research (Stanford University), EngineeringEconomic Systems (Stanford University), and Industrial and Systems Engineering (OR) (Ph.D, Virginia Tech). He is a member of the Institute for Operations
Research and the Management Sciences, the Institute of Industrial Engineers,
the IEEE, the Military Operations Research Society, the Operational Research
Society, and is President of the Military Applications Society of INFORMS.
Bobbie L. Foote, Ph.D. Dr. Bobbie Leon Foote served as a senior member of
the faculty in Systems Engineering at the United States Military Academy.
He has created systems redesign plans for Compaq, American Pine Products,
the United States Navy, and Tinker Air Force Base. He was a ﬁnalist for the
Edelman prize for his work with Tinker Air Force Base. He is the author of
four sections on systems, forecasting, scheduling and plant layout for the 2006
Industrial and Systems Engineering Handbook and the 2007 Handbook of
Operations Research. He jointly holds a patent on a new statistical test process
granted in 2006 for work done on the Air Warrior project. He is a fellow of
the Institute of Industrial Engineers.
Simon R. Goerger, Ph.D. Colonel Simon R. Goerger is the Director of the DRRS
Implementation Ofﬁce and Senior Readiness Analyst for the U.S. Ofﬁce of
the Secretary of Defense. Col. Goerger is a former Assistant Professor in the
Department of Systems Engineering at the United States Military Academy.
He has taught both systems simulations and senior capstone courses at the
undergraduate level. He holds a Bachelor of Science from the United States
Military Academy and a Masters in Computer Science and a Doctorate in
Modeling and Simulations from the Naval Postgraduate School. His research
interests include combat models, agent-based modeling, human factors, training
in virtual environments, and veriﬁcation, validation, and accreditation of human
behavior representations. LTC Goerger has served as an infantry and cavalry
ofﬁcer for the U.S. Army as well as a software engineer for COMBAT XXI,
the U.S. Army’s future brigade and below analytical model for the twenty-ﬁrst
century. He is a member of the Institute for Operations Research and the
Management Sciences, the Military Operations Research Society, and the
Simulation Interoperability Standards Organization.
CONTRIBUTORS
xxxv
Dale L. Henderson, Ph.D., Design Editor LTC Dale Henderson is a senior military analyst for the TRADOC Analysis Center (Ft. Lee) and a former Assistant
Professor of Systems Engineering at the United States Military Academy at
West Point. He has systems engineering and modeling experience in support of
large-scale human resources systems and aviation systems. He graduated from
West Point with a B.S. in Engineering Physics and holds an M.S. in Operations Research from the Naval Postgraduate School and a Ph.D. in Systems and
Industrial Engineering from the University of Arizona. He is a member of the
Institute for Operations Research and the Management Sciences, the Military
Operations Research Society, and Omega Rho.
Robert Kewley, Ph.D. COL Robert Kewley is the Professor and Head of the
Department of Systems Engineering at the United States Military Academy
Department of Systems Engineering. He has systems analysis experience in the
areas of battle command, combat identiﬁcation, logistics, and sensor systems.
He has also conducted research in the areas of data mining and agent-based
modeling. He has taught courses in decision support systems, system simulation,
linear optimization, and computer-aided systems engineering. COL Kewley has
a bachelor’s degree in mathematics from the United States Military Academy
and has both a master’s degree in Industrial and Managerial Engineering and a
Ph.D. in Decision Science and Engineering Systems from Rensselaer Polytechnic
Institute. He is a member of the Military Operations Research Society.
John E. Kobza, Ph.D. Dr. John E. Kobza is a Professor of Industrial Engineering
and Senior Associate Dean of Engineering at Texas Tech University in Lubbock,
Texas. He has experience modeling communication, manufacturing, and security
systems. He has taught courses in statistics, applied probability, optimization,
simulation, and quality. Dr. Kobza has a B.S. in Electrical Engineering from
Washington State University, a Master’s in Electrical Engineering from Clemson
University, and a Ph.D. in Industrial and Systems Engineering from Virginia
Tech. He is a member of Omega Rho, Sigma Xi, Alpha Pi Mu, the Institute for
Operations Research and the Management Sciences, the Institute of Industrial
Engineers, and the Institute of Electrical and Electronics Engineers and is a
registered professional engineer in the state of Texas.
Paul D. Kucik III, Ph.D. LTC Paul Kucik is an Academy Professor and Director of
the Operations Research Center at the United States Military Academy at West
Point. He has extensive systems experience in the operations and maintenance
of military aviation assets. He has taught a variety of economics, engineering
management, and systems engineering courses. LTC Kucik conducts research
in decision analysis, systems engineering, optimization, cost analysis, and management and incentive systems. LTC Kucik has degrees in Economics (United
States Military Academy), Business Administration (MBA, Sloan School of
Management, Massachusetts Institute of Technology), and Management Science
and Engineering (Ph.D., Stanford University). He is a member of the Military
xxxvi
CONTRIBUTORS
Applications Society of the Institute for Operations Research and the Management Sciences, the Military Operations Research Society, the American Society
for Engineering Management, and the Society for Risk Analysis.
Michael J. Kwinn, Jr., Ph.D. Dr. Michael J. Kwinn, Jr. is the Deputy Director for
the System-of-Systems Engineering organization for the Assistant Secretary of
the U.S. Army for Acquisition, Logistics and Technology and is a former Professor of Systems Engineering at the United States Military Academy at West Point.
He has worked on systems engineering projects for over 15 years. Some of his
recent work is in the areas of acquisition simulation analysis, military recruiting process management, and condition-based maintenance implementation. He
has also applied systems engineering techniques while deployed in support of
Operation Iraqi Freedom (OIF) and Operation Enduring Freedom (OEF). He
teaches systems engineering and operations research courses and has served
as an advisory member for the Army Science Board. Dr. Kwinn has degrees
in General Engineering (U.S. Military Academy), Systems Engineering (MSe,
University of Arizona), National Security and Strategic Studies (MA, US Naval
War College), Management Science (Ph.D., University of Texas at Austin). He
is the past-President of the Military Operations Research Society and is a member of the International Council on Systems Engineering, the American Society
for Engineering Education, and the Institute for Operations Research and the
Management Sciences.
LTC Daniel J. McCarthy is an Academy Professor and the Director of the Systems
Engineering and Operations Research Programs in the Department of Systems
Engineering at the United States Military Academy. He has systems analysis
experience in the areas of personnel management, logistics, battle command,
and unmanned systems. He has also conducted research and has experience
in the areas of system dynamics, project management, product development,
strategic partnership and strategic assessment. He has taught courses in systems
engineering design, system dynamics, production operations management, mathematical modeling, decision analysis, and engineering statistics. LTC McCarthy
has degrees in Organizational Leadership (U.S. Military Academy), Systems
Engineering (University of Virginia), and Management Science (Ph.D., Massachusetts Institute of Technology). He is a member of the Military Operations
Research Society (MORS), the International Council of Systems Engineering
(INCOSE), the System Dynamics Society, the American Society of Engineering
Education (ASEE), and the Institute of Industrial Engineers (IIE).
Kenneth W. McDonald, Ph.D. LTC Kenneth W. McDonald is an Associate Professor and Engineering Management Program Director in the Department of
Systems Engineering at the United States Military Academy at West Point.
He has extensive engineering management experience throughout a 25-year
career of service in the U.S. Army Corps of Engineers and teaching. He teaches
engineering management and systems engineering courses while overseeing the
CONTRIBUTORS
xxxvii
Engineering Management program. LTC McDonald has degrees in Civil Engineering, Environmental Engineering, Geography, City and Regional Planning,
Business and Information Systems. He is also a registered Professional Engineer
(PE), a Project Management Professional (PMP), and a certiﬁed professional
planner (AICP). He is a member of the Institute of Industrial Engineering, the
American Society of Engineering Management, the American Institute of Certiﬁed Planners and the Society of American Military Engineers. He is also an
ABET evaluator for Engineering Management programs.
Heather Nachtmann, Ph.D. Dr. Heather Nachtmann is an Associate Professor of
Industrial Engineering and Director of the Mack-Blackwell Rural Transportation
Center at the University of Arkansas. Her research interests include modeling
of transportation, logistics, and economic systems. She teaches in the areas of
operations research, engineering economy, cost and ﬁnancial engineering, and
decision analysis. Dr. Nachtmann received her Ph.D. in Industrial Engineering
from the University of Pittsburgh. She is a member of Alpha Pi Mu, the American Society for Engineering Education, the American Society for Engineering
Management, the Institute for Operations Research and the Management Sciences, the Institute of Industrial Engineers, and the Society of Women Engineers.
Gregory S. Parnell, Ph.D. Dr. Gregory S. Parnell is a Professor of Systems Engineering at the United States Military Academy at West Point. He has systems
experience operating space systems, managing aircraft and missile R&D programs, and leading a missile systems engineering ofﬁce during his 25 years in
the U.S. Air Force. He teaches decision analysis, operations research, systems
engineering, and engineering management courses. He also serves as a senior
principal with Innovative Decisions Inc., a leading decision analysis consulting
company. He serves on the Technology Panel of the National Security Agency
Advisory Board. Dr. Parnell has degrees in Aerospace Engineering (State University of New York at Buffalo), Industrial and Systems Engineering (University of Florida), Systems Management (University of Southern California) and
Engineering-Economic Systems (Ph.D., Stanford University). Dr. Parnell is a
member of the American Society for Engineering Education, the International
Council on Systems Engineering, the Institute for Operations Research and the
Management Sciences, and the Military Operations Research Society.
Edward Pohl, Ph.D. Dr. Edward A. Pohl is an Associate Professor and John L.
Imhoff Chair of Industrial Engineering at the University of Arkansas. Prior to
joining the faculty at Arkansas, Dr. Pohl served as an Associate Professor of
Systems Engineering at the United States Military Academy, and as an Assistant Professor of Systems Engineering at the Air Force Institute of Technology.
During his 21 years of service in the United States Air Force, Dr. Pohl held
a variety of systems engineering and analysis positions. He worked as a systems engineer on the B-2 Weapon Systems Trainer and worked as a reliability,
maintainability, and availability engineer on a variety of strategic and tactical
xxxviii
CONTRIBUTORS
missile systems. Finally, he worked as a systems analyst on the staff of the Secretary of Defense, Programs Analysis and Evaluation on a variety of space and
missile defense systems. Dr. Pohl has degrees in Electrical Engineering (Boston
University), Engineering Management (University of Dayton), Systems Engineering (Air Force Institute of Technology), Reliability Engineering (University
of Arizona), and Systems and Industrial Engineering (Ph.D., University of Arizona). He is a member of the International Council on Systems Engineering, the
Institute for Operations Research and the Management Sciences, the Institute of
Industrial Engineers, the Institute of Electrical and Electronics Engineers, and
the Military Operations Research Society.
Robert Powell, Ph.D. COL Robert A. Powell was a former Academy Professor
and Director of the Systems Management program at the United States Military Academy at West Point. Prior to his death in 2008, he had a vast and
varied background of academic, research, and government experience in the
engineering profession that spanned more than 21 years. He conducted research
in decision analysis, systems engineering, battleﬁeld imagery, optimization, and
project management, as well as on the value of integrating practice into engineering curriculums. While on the faculty at USMA, COL. Powell taught courses in
production operations management, engineering economics, and project management. COL Powell held a Ph.D. in Systems Engineering from Stevens Institute
of Technology, a Master of Military Art and Science from the U.S. Army Command and General Staff College, an M.S. in Operations Research/Management
Science from George Mason University, and a B.S. in Industrial Engineering
from Texas A&M University. COL. Powell was also a member of the American
Society for Engineering Education, the International Council on Systems Engineering, the Military Operations Research Society, and the National Society of
Black Engineers.
Timothy Trainor, Ph.D. Brigadier General Timothy E. Trainor is the Dean of
Academics and former Professor and Head of the Department of Systems Engineering at the United States Military Academy at West Point. He has systems experience in the operations of military engineering organizations. He
teaches engineering management, systems engineering, and decision analysis
courses. BG Trainor has degrees in Engineering Mechanics (United States Military Academy), Business Administration (MBA, Fuqua School of Business,
Duke University), and Industrial Engineering (Ph.D., North Carolina State University). He is a member of the Military Applications Society of the Institute
for Operations Research and the Management Sciences, the Military Operations
Research Society, the American Society for Engineering Education, and the
American Society of Engineering Management. Colonel Trainor is a member of
the Board of Fellows for the David Crawford School of Engineering at Norwich
University.
CONTRIBUTORS
xxxix
Paul D. West, Ph.D. Dr. Paul D. West is an Assistant Professor in the Department
of Systems Engineering at the United States Military Academy at West Point.
His systems engineering experience ranges from weapon system to state and
local emergency management system design. He has taught courses in combat modeling and simulation, system design, and engineering economics. He
designed and implemented an immersive 3D virtual test bed for West Point and
chaired the Academy’s Emerging Computing Committee. Other research interests include the design and operation of network-centric systems and human
behavior modeling. He holds a bachelor’s degree in Liberal Studies from the
State University of New York at Albany, an M.B.A. degree from Long Island
University, a Master of Technology Management degree from Stevens Institute
of Technology, and a Ph.D. in Systems Engineering and Technology Management, also from Stevens. He is a member of the Military Operations Research
Society, the American Society of Engineering Management, and the Institute
for Operations Research and the Management Sciences.
Acronyms
ABET
AFT
AoA
ASEM
ASI
BRAC
CAS
CCB
CER
CFR
CIO
CM
CPS
CTO
DDDC
DDDD
DDPC
DDPD
DFR
DoD
DOE
Formerly Accreditation Board for Engineering and Technology, now
ABET, Inc.
Alternative-Focused Thinking
Analysis of Alternatives
American Society for Engineering Management
American Shield Initiative
Base Realignment and Closure Commission
Complex Adaptive System
Conﬁguration Control Board
Cost Estimating Relationship
Constant Failure Rate
Chief Information Ofﬁcer
Conﬁguration Manager (or Management)
Creative Problem Solving
Chief Technology Ofﬁcer
Dynamic, Deterministic, Descriptive, Continuous
Dynamic, Deterministic, Descriptive, Discrete
Dynamic, Deterministic, Prescriptive, Continuous
Dynamic, Deterministic, Prescriptive, Discrete
Decreasing Failure Rate
Department of Defense
Design of Experiments
xli
xlii
DPDC
DPDD
DPPC
DPPD
EM
ESS
FIPS
FRP
GIG
ICD
ICOM
IDEF
IE
IED
IFR
IIE
ILS
INCOSE
INFORMS
IV& V
LCC
LRIP
M& S
MA
MAS
MTF
MODA
MOE
MOP
MORS
NCW
NPV
NSTS
OR/MS
ORS
PM
QA
R/C
RFP
RMA
RPS
RSM
SADT
SCEA
ACRONYMS
Dynamic, Probabilistic, Descriptive, Continuous
Dynamic, Probabilistic, Descriptive, Discrete
Dynamic, Probabilistic, Prescriptive, Continuous
Dynamic, Probabilistic, Prescriptive, Discrete
Engineering Manager (or Management)
Environmental Stress Screening
Federal Information Processing Standards
Full Rate Production
Global Information Grid
Interface Control Document
Inputs, Controls, Outputs, and Mechanisms
Integrated Deﬁnition for Function Modeling
Industrial Engineer (or Engineering)
Improvised Explosive Device
Increasing Failure Rate
Institute of Industrial Engineers
Integrated Logistic Support
International Council on Systems Engineering
Institute for Operations Research and the Management Sciences
Independent Veriﬁcation and Validation
Life Cycle Costing
Low Rate Initial Production
Modeling and Simulation
Morphological Analysis
Multi-Agent System
Mean Time to Failure
Multiple Objective Decision Analysis
Measure of Effectiveness
Measures of Performance
Military Operations Research Society
Network Centric Warfare
Net Present Value
National Space Transportation System
Operations Research & Management Science
Operational Research Society
Program Manager (or Management)
Quality Assurance
Radio Controlled
Request for Proposal
Reliability, Maintainability, and Availability
Revised Problem Statement
Response Surface Method
Structured Analysis and Design Technique
Society of Cost Estimating and Analysis
xliii
ACRONYMS
SDDC
SDDD
SDP
SDPC
SDPD
SE
SEC
SEMP
SME
SPDC
SPDD
SPPC
SPPD
TEMP
U.S.
VFT
WBS
Static, Deterministic, Descriptive, Continuous
Static, Deterministic, Descriptive, Discrete
Systems Decision Process
Static, Deterministic, Probabilistic, Continuous
Static, Deterministic, Prescriptive, Discrete
System(s) Engineer (or Engineering)
Securities and Exchange Commission
Systems Engineering Master Plan
Subject Matter Expert
Static, Probabilistic, Descriptive, Continuous
Static, Probabilistic, Descriptive, Discrete
Static, Probabilistic, Prescriptive, Continuous
Static, Probabilistic, Prescriptive, Discrete
Test and Evaluation Master Plan
United States
Value-Focused Thinking
Work Breakdown Structure
Chapter 1
Introduction
GREGORY S. PARNELL, Ph.D.
PATRICK J. DRISCOLL, Ph.D.
To be consistent, you have to have systems. You want systems, and not rules. Rules
create robots. Systems are predetermined ways to achieve a result. The emphasis is
on achieving the results, not the system for the system’s sake . . . Systems give you
a ﬂoor, not a ceiling.
—Ken Blanchard and Sheldon Bowles
1.1
PURPOSE
This is the ﬁrst chapter in a foundational book on a technical ﬁeld. It serves two
purposes. First, it introduces the key terms and concepts of the discipline and
describes their relationships with one another. Second, it provides an overview
of the major topics of the book. All technical ﬁelds have precisely deﬁned terms
that provide a foundation for clear thinking about the discipline. Throughout this
book we will use the terms and deﬁnitions recognized by the primary professional
societies informing the practice of contemporary systems engineering:
The International Council on Systems Engineering (INCOSE) [1] is a not-forproﬁt membership organization founded in 1990. INCOSE was founded to
develop and disseminate the interdisciplinary principles and practices that
enable the realization of successful systems. INCOSE organizes several meetings each year, including the annual INCOSE international symposium.
Decision Making in Systems Engineering and Management, Second Edition
Edited by Gregory S. Parnell, Patrick J. Driscoll, Dale L. Henderson
Copyright  2011 John Wiley & Sons, Inc.
1
2
INTRODUCTION
The American Society for Engineering Management (ASEM) [2] was founded in
1979 to assist its members in developing and improving their skills as practicing managers of engineering and technology and to promote the profession
of engineering management. ASEM has an annual conference.
The Institute for Operations Research and the Management Sciences (INFORMS)
[3] is the largest professional society in the world for professionals in the
ﬁelds of operations research and the management sciences. The INFORMS
annual conference is one of the major forums where systems engineers present
their work.
The Operational Research Society (ORS) [4] is the oldest professional society of
operations research professionals in the world with members in 53 countries.
The ORS provides training, conferences, publications, and information to
those working in operations research. Members of the ORS were among the
ﬁrst systems engineers to embrace systems thinking as a way of addressing
complicated modeling and analysis challenges.
Figure 1.1 shows the concept map for this chapter. This concept map relates the
major sections of the chapter, and of the book, to one another. The concepts shown
in round-edge boxes are assigned as major sections of this chapter. The underlined
items are introduced within appropriate sections. They represent ideas and objects
that link major concepts. The verbs on the arcs are activities that we describe
brieﬂy in this chapter. We use a concept map diagram in each of the chapters to
help identify the key chapter concepts and make explicit the relationships between
Figure 1.1 Concept map for Chapter 1.
STAKEHOLDERS
3
key concepts we explore. This book addresses the concepts of systems, system life
cycles, system engineering thought process, systems decisions, systems thinking,
systems engineering, and engineering management.
1.2
SYSTEM
There are many ways to deﬁne the word system. The Webster Online Dictionary deﬁnes a system as “a regularly interacting or interdependent group of items
[elements] forming a uniﬁed whole” [5]. We will use the INCOSE deﬁnition:
A system is “an integrated set of elements that accomplishes a deﬁned
objective. These elements include products (hardware, software, ﬁrmware),
processes (policies, laws, procedures), people (managers, analysts, skilled
workers), information (data, reports, media), techniques (algorithms, inspections, maintenance), facilities (hospitals, manufacturing plants, mail distribution centers), services (evacuation, telecommunications, quality assurance),
and other support elements.”[1]
As we see in Figure 1.1 a system has several important attributes:
•
•
•
•
•
•
•
Systems have interconnected and interacting elements that perform systems
functions to meet the needs of consumers for products and services.
Systems have objectives that are achieved by system functions.
Systems interact with their environment, thereby creating effects on stakeholders.
Systems require systems thinking that uses a systems engineering thought
process.
Systems use technology that is developed by engineers from all engineering
disciplines.
Systems have a system life cycle containing elements of risk that are
(a) identiﬁed and assessed by systems engineers and (b) managed throughout
this life cycle by engineering managers.
Systems require systems decisions, analysis by systems engineers, and decisions made by engineering managers.
Part I of this book discusses systems and systems thinking in detail.
1.3
STAKEHOLDERS
The primary focus of any systems engineering effort is on the stakeholders of the
system, the deﬁnitions of which have a long chronology in the management sciences
literature [6]. A stakeholder, in the context of systems engineering, is a person or
4
INTRODUCTION
organization that has a vested interest in a system or its outputs. When such a
system is an organization, this deﬁnition aligns with Freeman’s: “any group of
individuals who can affect or is affected by the achievement of the organization’s
objectives” [7]. It is this vested interest that establishes stakeholder importance
within any systems decision process. Sooner or later, for any systems decision
problem, stakeholders will care about the decision reached because it will in one
way or another affect them, their systems, or their success. Consequently, it is
prudent and wise to identify and prioritize stakeholders in some organized fashion
and to integrate their needs, wants, and desires in any possible candidate solution.
In the systems decision process (SDP) that we introduce in Chapter 9, we do this
by constructing value models based on stakeholder input. Their input as a group
impacts system functions and establishes screening criteria which are minimum
requirements that any potential solution must meet. Alternatives failing to meet
such requirements are eliminated from further consideration.
It is important to recognize that all stakeholder input is conditionally valid based
upon their individual perspectives and vested interests. In other words, from their
experience with and relationship to the problem or opportunity being addressed,
and within the environment of openness they have chosen to engage the systems
engineering team, the information they provide is accurate. The same can be said of
the client’s information. What acts to ﬁll any gaps in this information is independent
research on the part of the team. Research never stops once it has begun, and it
begins prior to the ﬁrst meeting with any client. This triumvirate of input, so critical
to accurately deﬁning a problem, is illustrated in Figure 1.2.
Managing stakeholder expectations has become so intrinsic to project success
that a number of other formalizations have been developed to understand the interrelationship between key individuals and organizations and the challenges that
could arise as a project unfolds. Mitchell et al. [6] posit that stakeholders can be
identiﬁed by their possessing or being attributed to possess one, two, or all three
of the following attributes, which we generalize here to systems.
1. The stakeholder’s power to inﬂuence the system.
2. The legitimacy of the stakeholder’s relationship to the system.
3. The urgency of the stakeholder’s claim on the system.
Client Input
Problem
Definition
Stakeholder
Interviews
Research
Figure 1.2 Three required ingredients for proper problem deﬁnition.
5
STAKEHOLDERS
These attributes interact in a manner that deﬁnes stakeholder salience, the degree
to which managers give priority to competing stakeholder claims. Salience then
results in a classiﬁcation of stakeholders by eight types shown in Figure 1.3.
Throughout the systems decision process (SDP), there is a strong emphasis on
identifying, engaging with, cultivating a trust relationship with, and crafting high
value system solutions for a stakeholder called the decision authority. Mitchell’s
characterization clearly illustrates why this is so. The decision maker is a salience
type 7 in Figure 1.3. The decision maker possesses an urgency to ﬁnd a solution to
the dilemma facing the system, the power to select and implement a value-based
solution, and a recognized legitimacy by all stakeholders to make this selection.
Beyond understanding how stakeholders relate to one another and the system,
these attributes are relevant to systems decision problems because Matty [8] has
connected them to elements of value, a characteristic that comprises one-half of the
tradeoff space advocated by the approach presented in this book (see Chapter 9).
Stakeholder legitimacy strongly inﬂuences value identiﬁcation; power strongly
inﬂuences value positioning; and urgency strongly inﬂuences value execution.
Two other recent approaches have garnered broad interest in professional practice: the Stakeholder Circle and the Organizational Zoo [9].
The Stakeholder Circle is a commercially available software tool (www.stake
holder-management.com) which originated in a doctoral thesis [10, 23] motivated
by several decades of project management experience in which “poor stakeholder
engagement due to not seeing where some stakeholders were coming from led to
project delivery failure.” The software provides a visualization tool that measures
and illustrates various stakeholders’ power, inﬂuence, and positioning. It leverages
a useful metaphor of stakeholders in a concentric circle surrounding the project
itself. A ﬁve-step methodology is used to manage the stakeholder pool over the
complete life cycle of a project: Identify the stakeholders and their needs, prioritize
the stakeholders, visualize their relationship to the project, develop an engagement
strategy, and monitor changes over time.
Types
0 – Non-stakeholder
Power
1
1 – Dormant
2 – Discretionary
3 – Demanding
4
6
7
Legitimacy
Urgency
3
5
2
4 – Dominant
5 – Dependent
6 – Dangerous
7 – Definitive
Figure 1.3 Stakeholder salience types [8].
6
INTRODUCTION
The “Organizational Zoo” concept uses the metaphor of an animal kingdom
and its familiar inhabitants to persuade stakeholders to see “how various situations and environments can facilitate or inhibit a knowledge-sharing culture.” By
associating key individuals with stereotypical behaviors expressed by lions, eagles,
ants, mice, rattlesnakes, hyenas, unicorns, and other creatures, stakeholders gain an
understanding of how and why they are likely to react to project-related situations.
This approach is more stakeholder-centric in its application than the Stakeholder
Circle, though both methods possess similarities to the use of rich pictures in
soft system methodology [11].
Notice that this notion of a stakeholder makes no distinction based on the motivation of stakeholder vested interest. We should allow the possibility that for any
system of reasonable presence in its surrounding environment, there exists a subset
of adversarial stakeholders who are not interested in the success and well-being
of the system under study. On the contrary, they might have a vested interest
in its demise, or at the very least the stagnation or reduction in the growth of
the system, its outputs, and linkages. Market competitors, advocates of opposing
political ideologies, members of hostile biological systems, and so on, are obvious examples of adversarial groups that might typify this malevolent category
of stakeholders. Cleland [12] and Winch [13] introduce and elaborate upon several useful techniques for mitigating the risk to project success posed by hostile
stakeholders.
More complex and challenging to identify are the less obvious stakeholders,
namely, those persons and organizations that are once, twice, and further removed
from direct interaction with the system under study but nonetheless have a vested
interest that needs to be considered in a systems decision problem. A once removed
stakeholder could be described as one whose direct vested interest lies in the output
of a system that is dependent on output of the system under study. A similar
relationship exists for further removed stakeholders. The environmental factors
shown in the SDP of Figure 1.7 are very helpful in this regard. They are frequently
used as memory cues during stakeholder identiﬁcation.
For our purposes, the simplest complete taxonomy of stakeholders contains six
types. In some systems decisions it may be useful to include additional types
of stakeholders. For example, it may be helpful to divide the User group into
two subgroups—operators and maintainers—to more clearly identify their role in
interacting with the system and to better classify their individual perspectives.
Decision Authority. The stakeholder(s) with ultimate decision gate authority to
approve and implement a system solution.
Client. The person or organization that solicited systems decision support for
a project; the source of project compensation; and/or the stakeholder that
principally deﬁnes system requirements.
Owner. The person or organization responsible for proper and purposeful system
operation.
User. The person or organization accountable for proper and purposeful system
operation.
SYSTEM LIFE CYCLE
7
Consumer. The person(s) or organization(s) that realize direct or indirect beneﬁts from the products or services of the system.
Interconnected. The persons or organizations that will be virtually or physically
connected to the system and have potential beneﬁts, costs, and/or risks caused
by the connection.
For any given systems decision problem, it is perhaps easiest to identify the
Client ﬁrst, then the Decision authority, followed by the others in any convenient
order. For example, on a recent rental car system re-design, the Client solicited
assistance in identifying creative alternatives for marketing nonrecreational vehicle
rental in his region. When asked, the Client stated that while he would be making
the intermediate gate decisions to move the project forward, any solutions would
have to be approved by his regional manager prior to implementation. His regional
manager is therefore the Decision authority.
An example will help to distinguish between a User and an Owner. A technology
company purchases computer systems for its engineers to use for computer-aided
design. The company owns the computers and is held responsible for maintaining
proper accountability against loss. The engineers use the computers and typically
sign a document acknowledging that they have taken possession of the computers.
If, on a particularly bad Friday, one of the engineers (User) tosses her computer
out the window and destroys it, she will be held accountable and have to pay
for the damages or replacement. The managing supervisor of the engineer, as the
company’s representative (Owner), is held responsible that all proper steps were
taken to protect and safeguard the system against its loss or damage.
This taxonomy can then be further divided into an active set and a passive set of
stakeholders. The active set contains those stakeholders who currently place a high
enough priority on the systems decision problem to return your call or participate
in an interview, focus group, or survey in order to provide the design team with
relevant information. The passive set contains those who do not. Membership in
these two sets will most likely change throughout the duration of a systems decision
project as awareness of the project and relevance of the impact of the decisions
made increases in the pool of passive stakeholders.
1.4
SYSTEM LIFE CYCLE
Systems are dynamic in the sense that the passage of time affects their elements, functions, interactions, and value delivered to stakeholders. These observable effects are commonly referred to as system maturation effects. A system life
cycle is a conceptual model that is used by system engineers and engineering managers to describe how a system matures over time. It includes each of the stages
in the conceptualization, design, development, production, deployment, operation,
and retirement of the system. For most systems decision challenges and all system
design problems, when coupled with the uncertainties associated with cost, performance, and schedule, life cycle models become important tools to help these same
8
INTRODUCTION
engineers and managers understand, predict, and plan for how a system will evolve
into the future.
A system’s performance level, its supportability, and all associated costs are
important considerations in any systems decision process. The process we introduce
in Section 1.9 is fundamentally life cycle centered. In each stage of a system’s
useful life, systems owners make decisions that inﬂuence the well-being of their
system and determine whether the system will continue to the next stage of its life
cycle. The decision of whether or not to advance the system to the next stage is
called a decision gate.
The performance of a system will degrade if it is not maintained properly.
Maintaining a system consumes valuable resources. At some point, system owners
are faced with critical decisions as to whether to continue to maintain the current
system, modify the system to create new functionality with new objectives in
mind, or retire the current system and replace it with a new system design. These
decisions should be made taking into consideration the entire system life cycle
and its associated costs, such as development, production, support, and “end of
life” disposal costs, because it is in this context that some surprising costs, such as
energy and environmental costs, become clearly visible.
Consider, for example, the life cycle costs associated with a washing machine
[14] in terms of percentage of its overall contributions to energy and water consumption, air and water pollution, and solid waste. One might suspect that the
largest solid waste costs to the environment would be in the two life cycle stages
at the beginning of its life cycle (packaging material is removed and discarded)
and at the end (the machine is disposed of). However, as can be seen in Figure 1.4,
the operational stage dominates these two stages as a result of the many packets of
washing detergent and other consumables that are discarded during the machine’s
life. It is just the opposite case with the environmental costs associated with nuclear
power facilities. The disposal (long-term storage) costs of spent nuclear fuel have
grown over time to equal the development and production costs of the facility [15].
Figure 1.4 Life cycle assessment of environmental costs of a washing machine [14].
SYSTEM LIFE CYCLE
9
Figure 1.5 Systems decision process used throughout a system life cycle.
We use the system life cycle shown in Figure 1.5 throughout the book. Chapter 3
develops the life cycle in detail so that it can be used to assess any system in
support of systems decisions. The stages of this life cycle are aligned with how a
system matures during its lifetime. We assume in our approach that there also exist
decision gates through which the system can only pass by satisfying some explicit
requirements. These requirements are usually set by system owners. For example,
a system typically will not be allowed to proceed from the design and development
stage to the production stage without clearly demonstrating that the system design
has a high likelihood of efﬁciently delivering the value to stakeholders that the
design promises. Decision gates are used by engineering managers to assess system
risk, both in terms of what it promises to deliver in future stages and threats to
system survivability once deployed.
Throughout all of these considerations, uncertainties are present to varying
degrees. While some cost components can be ﬁxed through contractual agreements,
others are dependent upon environmental factors well beyond the control and well
outside of the knowledge base of systems engineering teams. Illness, labor strikes,
late detected code errors, raw material shortages, weather-related losses, legal challenges, and so on, are all phenomena of the type that impose cost increases despite
the best intentions and planning of the team. Important modeling parameters such as
10
INTRODUCTION
Figure 1.6 Simpliﬁed risk management cycle for systems decisions.
cost coefﬁcients used in cost estimating relationships and component performance
estimates are based on past data which, as all investment professionals will proclaim, are no guarantee of future performance. Performing the proper due diligence
to identify, assess, and manage the potential downside impact of events driven by
uncertainty such as these is the role of risk management.
As will be discussed in Chapter 3 in more detail, risk management involves a
constant cycle of activities whose purpose is to leverage the most accurate information concerning uncertain events that could threaten system success to construct
effective plans that eliminate, mitigate, relocate, or accept (and adapt to) the occurrence of these events [22]. Figure 1.6 shows a simpliﬁed risk management cycle
whose elements are in common to all risk planning efforts.
Risk is a fundamental concept in systems decision making. Various forms of
risk present themselves throughout the life cycle of a system: business risk (does
it make sense for the project team to undertake the effort?), market risk (is there a
viable and proﬁtable market for the products and/or services the system is designed
to deliver?), system program risk (can technical, schedule, and program risks be
identiﬁed, mitigated, or resolved in a manner that satisﬁes system owners?), decision risk (is there a sufﬁcient amount of accurate information to make critical
decisions?), and implementation risk (can the system be put into action to deliver
value?). Risk management, including risk forecasting and mitigation planning, starts
early and continues throughout a system’s life cycle.
1.5
SYSTEMS THINKING
Systems have become increasingly more complex, dynamic, interconnected, and
automated. Both the number and diversity of stakeholders have increased, as
global systems have become more prevalent. For example, software companies
take advantage of time zone differences to apply continuous effort to new software
SYSTEMS THINKING
11
systems by positioning development teams in the United States, Europe, India,
and Japan. Financial systems previously operating as independent ventures now
involve banks, businesses, customers, markets, ﬁnancial institutions, exchange services, and national and international auditing agencies. Changes occurring in one
system impact in a very short time those they are connected to. A change in the
Tokyo market, for example, propagates quickly to the U.S. market because of strong
relationships existing not only between these markets but also among the monetary
exchange rates, trade balance levels, manufacturing production levels and inventory
levels as well. In order to respond quickly to these market changes, buy and sell
rules are automated so as to keep disrupting events from escalating out of control
over time.
Military systems have dramatically increased in complexity as well. Currently,
complex, interconnected systems use real-time satellite data to geo-locate themselves and ﬁnd, identify, and classify potential targets using a worldwide network
of sensor systems. These, in turn, are connected to a host of weapons platforms
having the capacity to place precision guided munitions on targets. With systems
such as these, a host of systems decisions arise. Is there a lower limit to human
participation in a targeting process such as these? Are these limits deﬁned by technological, cultural, moral, legal, or ﬁnancial factors? Likewise, should there be
an upper limit on the percentage of automated decision making? What measures
of effectiveness (MOE) are appropriate for the integrated system behavior present
only when all systems are operational?
In general then, for complex systems, how many systems interactions do we
need to consider when we are faced with analyzing a single system? Answers to
this question shape both the system boundaries and scope of our analysis effort.
How can we ensure that critical interactions and relationships are represented in any
model we build and that those that play only a minor role are discounted but not
forgotten? For these and other important considerations to not be overlooked, we
need a robust and consistent systems decision process driven by systems thinking
that we can repeatedly apply in any life cycle stage of any system we are examining.
As is addressed in detail in Chapter 2, systems thinking is a holistic philosophy
capable of uncovering critical system structure such as boundaries, inputs, outputs,
spatial orientation, process structure, and complex interactions of systems with
their environment [16]. This way of thinking considers the system as a whole,
examining the behavior arising from the total system without assuming that it
is necessary to decompose the system into its elements in order to improve or
modify its performance. Understanding system structure enables system engineers
to design, produce, deploy, and operate systems focused on delivering high value
capabilities to customers. The focus on delivering value is what underscores every
activity of modern systems engineering [17].
Systems thinking is a holistic philosophy capable of uncovering critical system structure such as boundaries, inputs, outputs, spatial orientation, process
structure, and complex interactions of systems with their environment [16].
12
INTRODUCTION
Systems thinking combined with engineering principles focused on creating
value for stakeholders is a modern world view embedded in systems engineering
capable of addressing many of the challenges posed by the growing complexity of
systems. Systems engineers necessarily must consider both hard and soft systems
analysis techniques [11].
In applying the SDP that we introduce in Section 1.9 and use throughout this
book, a signiﬁcant amount of time is consumed in the early steps of the process,
carefully identifying the core issues from stakeholders’ perspectives, determining
critical functions that the system must perform as a whole in order to be considered
successful, and clearly identifying and quantifying how these functions will deliver
value to stakeholders. Many of the techniques used to accomplish these tasks are
considered “soft” in the sense that they are largely subjective and qualitative, as
opposed to “hard” techniques that are objective and quantitative. Techniques used
in later steps of the SDP involving system modeling and analysis, which are introduced in Chapter 4, lean more toward the quantitative type. Together, they form an
effective combination of approaches that makes systems engineering indispensable.
1.6
SYSTEMS ENGINEERING THOUGHT PROCESS
The philosophy of systems thinking is essentially what differentiates modern systems engineering from other engineering disciplines such as civil, mechanical,
electrical, aerospace, and environmental. Table 1.1 presents some of the more
signiﬁcant differences [18]. While not exhaustive in its listings, the comparison
clearly illustrates that there is something different about systems engineering that
is fundamental to the discipline.
The engineering thought process underpinning these other engineering ﬁelds
assumes that decomposing a structure into its smallest constituent parts, understanding these parts, and reassembling these parts will enable one to understand
the structure. Not so with a systems engineering thought process. Many of these
engineering ﬁelds are facing problems that are increasingly more interconnected
and globally oriented. Consequently, interdisciplinary teams are being formed using
professionals from a host of disciplines so that the team represents as many perspectives as possible.
The systems engineering thought process is a holistic, logically structured
sequence of cognitive activities that support systems design, systems analysis,
and systems decision making to maximize the value delivered by a system
to its stakeholders for the resources.
Systems decision problems occur in the context of their environment. Thus,
while it is critical to identify the boundaries that set the system under study apart
from its environment, the system is immediately placed back into its environment
for all subsequent considerations. The diversity of environmental factors shown in
the SDP of Figure 1.7 clearly illustrates the need for systems engineering teams to
13
SYSTEMS ENGINEERING
TABLE 1.1 Comparison of Engineering Disciplines
Comparison
Criteria
Systems
Engineering
Problem
characteristics
Complex, multidisciplinary,
incrementally deﬁned
Emphasis
Leadership in formulating and
framing the right problem to
solve; focus on methodology and
process; ﬁnding parsimonious
solutions; associative thinking
Basis
Aesthetics, envisioning, systems
science, systems theory
Architecting unprecedented
systems; legacy migration;
new/legacy system evolution;
achieving multilevel
interoperability between new
and legacy software-intensive
systems
Key challenges
Complicating
factors
Key metric
examples
SE has a cognitive component and
oftentimes incorporates
components arising from
environmental factors (see SDP)
Cost and ease of legacy migration;
system complexity; system
parsimony; ability to
accommodate evolving
requirements; ability to meet
stakeholder expectations of value
Traditional Engineering
Discipline
Primarily requiring expertise
in no more than a couple
of disciplines; problem
relatively well-deﬁned at
the onset
Finding the right technique
to solve; focus on
outcome or result; ﬁnding
parsimonious
explanations; vertical
thinking
Physical sciences and
attendant laws
Finding the most elegant or
optimal solution;
formulating hypothesis
and using deductive
reasoning methods to
conﬁrm or refute them;
ﬁnding effective
approximations to simplify
problem solution or
computational load
Nonlinear phenomena in
various physical sciences
Solution accuracy, product
quality, and reliability;
solution robustness
be multidisciplinary. Each of these factors represent pote…

Hire a Writer

Client Reviews

4.9

Sitejabber

4.6

Trustpilot

4.8

Our Guarantees

100% Confidentiality

Information about customers is confidential and never disclosed to third parties.

Original Writing

We complete all papers from scratch. You can get a plagiarism report.

Timely Delivery

No missed deadlines – 97% of assignments are completed in time.

Money Back

If you're confident that a writer didn't follow your order details, ask for a refund.

New to Artemis 2000? Sign up & Save

Calculate the price of your order

Type of paper needed:

Pages:

You will get a personal manager and a discount.

Academic level:

We'll send you the first draft for approval by at

Total price:

$0.00

Power up Your Academic Success with the
Team of Professionals. We’ve Got Your Back.

Power up Your Study Success with Experts We’ve Got Your Back.

Order Now Order Now