Download the Full Version of textbook for Fast Typing at textbookfull.

com

Systems Engineering: Fifty Lessons Learned 1st

Edition Howard Eisner

https://textbookfull.com/product/systems-engineering-fifty-
lessons-learned-1st-edition-howard-eisner/

OR CLICK BUTTON

DOWNLOAD NOW

Download More textbook Instantly Today - Get Yours Now at textbookfull.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

Systems Architecting Methods and Examples 1st Edition

Howard Eisner (Author)

https://textbookfull.com/product/systems-architecting-methods-and-
examples-1st-edition-howard-eisner-author/

textboxfull.com

Software Engineering at Google: Lessons Learned from

Programming Over Time 1st Edition Titus Winters

https://textbookfull.com/product/software-engineering-at-google-
lessons-learned-from-programming-over-time-1st-edition-titus-winters/

textboxfull.com

Software Development Pearls Lessons from Fifty Years of

Software Experience 1st Edition Wiegers

https://textbookfull.com/product/software-development-pearls-lessons-
from-fifty-years-of-software-experience-1st-edition-wiegers/

textboxfull.com

Service Learning Essentials Questions Answers and Lessons

Learned 1st Edition Barbara Jacoby

https://textbookfull.com/product/service-learning-essentials-
questions-answers-and-lessons-learned-1st-edition-barbara-jacoby/

textboxfull.com
INFORMATICS EDUCATION IN HEALTHCARE lessons learned 2nd
Edition Eta S. Berner

https://textbookfull.com/product/informatics-education-in-healthcare-
lessons-learned-2nd-edition-eta-s-berner/

textboxfull.com

Project Management Lessons Learned A Continuous Process

Improvement Framework 1st Edition Mel Bost

https://textbookfull.com/product/project-management-lessons-learned-a-
continuous-process-improvement-framework-1st-edition-mel-bost/

textboxfull.com

Successful Public Health Advocacy: Lessons Learned from

Massachusetts Legislators Chris Chanyasulkit

https://textbookfull.com/product/successful-public-health-advocacy-
lessons-learned-from-massachusetts-legislators-chris-chanyasulkit/

textboxfull.com

Coulson and Richardson’s Chemical Engineering, Fourth

Edition: Volume 3A: Chemical and Biochemical Reactors and
Reaction Engineering R. Ravi
https://textbookfull.com/product/coulson-and-richardsons-chemical-
engineering-fourth-edition-volume-3a-chemical-and-biochemical-
reactors-and-reaction-engineering-r-ravi/
textboxfull.com

Applied Data Science: Lessons Learned for the Data-Driven

Business Martin Braschler

https://textbookfull.com/product/applied-data-science-lessons-learned-
for-the-data-driven-business-martin-braschler/

textboxfull.com
Systems Engineering
Systems Engineering
Fifty Lessons Learned

Howard Eisner
First edition published 2020
by CRC Press
6000 Broken Sound Parkway NW, Suite 300, Boca Raton, FL 33487-2742

and by CRC Press

2 Park Square, Milton Park, Abingdon, Oxon, OX14 4RN

© 2021 Taylor & Francis Group, LLC

CRC Press is an imprint of Taylor & Francis Group, LLC

Reasonable efforts have been made to publish reliable data and information, but the author and pub-
lisher cannot assume responsibility for the validity of all materials or the consequences of their use.
The authors and publishers have attempted to trace the copyright holders of all material reproduced in
this publication and apologize to copyright holders if permission to publish in this form has not been
obtained. If any copyright material has not been acknowledged please write and let us know so we may
rectify in any future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced,
transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or here-
after invented, including photocopying, microflming, and recording, or in any information storage or
retrieval system, without written permission from the publishers.

​
For permission to photocopy or use material electronically from this work, access www.copyright. ​

com or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA
​
01923, 978-750-8400. For works that are not available on CCC please contact mpkbookspermissions@
​ ​
tandf.co.uk

Trademark notice: Product or corporate names may be trademarks or registered trademarks, and are
used only for identifcation and explanation without intent to infringe.

Library of Congress Cataloging-in-Publication Data

Names: Eisner, Howard, 1935- author.

Title: Systems engineering : ffty lessons learned / Howard Eisner.
Description: First edition. | Boca Raton, FL : CRC Press, 2020. | Includes
bibliographical references and index.
Identifers: LCCN 2020013254 (print) | LCCN 2020013255 (ebook) | ISBN
9780367422424 (hardback) | ISBN 9781003002505 (ebook)
Subjects: LCSH: Systems engineering--Management.
Classifcation: LCC TA168 .E3874 2020 (print) | LCC TA168 (ebook) | DDC
620.0068--dc23
LC record available at https://lccn.loc.gov/2020013254
LC ebook record available at https://lccn.loc.gov/2020013255

ISBN: 978-0-367-42242-4 (hbk)

ISBN: 978-1-003-00250-5 (ebk)

Typeset in Times
by Deanta Global Publishing Services, Chennai, India
This book is dedicated to my wife, June Linowitz, a professional artist
who is devoted to creating art for the world and the enjoyment of her
friends, colleagues, and family. It is also dedicated to my children and
their spouses, who are Susan Rachel Eisner Lee, Oren David Eisner,
Joseph Lee, and Tara Burke. Further dedications are to Oren’s sons
Zachary and Ben, deceased (Seth) son Jacob, and Susan and Joseph’s
children Gabriel and Lee.
Contents

Preface xiii
About the Author xv
Other Books by the Author xvii

1 Technical 1
1. When and Where Possible, Go Back to Fundamentals (*) 1
Case One 1
Case Two 2
Case Three 2
2. Seriously Explore Alternatives, Even If Time Is Short 3
References and Recommended Reading 5
3. Embrace Prototyping as Well as Modeling and
Simulation (M & S) 5
References and Recommended Reading 7
4. Cost-Effectiveness Is Still the Preferred Approach 7
Typical MOEs for Communication Systems 8
Selected MOEs for Transportation Systems 8
Limited MOEs for Air Defense Systems 9
Weighting Factors 9
References and Recommended Reading 9
5. Do Not Attempt to Integrate All Stovepipes 10
Reference and Recommended Reading 11
6. A Bit at a Time or All at Once 12
References and Recommended Reading 13
7. Growth by Acquisition 13
8. The Contract 16
9. Less Paper Please 17
References and Recommended Reading 19

2 Management 21
10. Defnitely Measure, but Do Not Over-Measure 21
Software Measurement 21
Overall Project Measurement 22

vii
viii Contents

Signifcant Parameters 22
COCOMO I and COCOMO II 23
References and Recommended Reading 23
11. Under Promise and Over Deliver 24
Reference and Recommended Reading 25
12. Try to Improve Overall Systems Engineering
Practices 25
References and Recommended Reading 27
13. Negotiate 27
References and Recommended Reading 28
14. Understanding the Enterprise 29
Monthly Measurements 29
The Balanced Scorecard 30
References and Recommended Reading 30
15. The Systems Approach 30
Systems Thinking 31
References and Recommended Reading 32
16. Industry/Government Interaction 33
Universities 33
INCOSE Certifcation 34
17. Tradeoffs 34
Risk 35
Detection and False Alarm Probabilities 35
18. Resilience 37
References and Recommended Reading 38

3 Idea Based 39
19. They Were Right: KISS, Simplify, and Reduce
Complexity 39
References and Recommended Reading 41
20. Seek a Balanced System Solution; Do Not Try to
Optimize or Achieve Perfection (*) 41
Other References to Balance 42
Stakeholders 44
References and Recommended Reading 44
21. Understand the Power, Importance, and Challenge of
Functional Decomposition 45
References and Recommended Reading 47
22. Break the Problem into Pieces Using the Reductionist
Approach Whenever Possible, and Then Apply Lateral
Thinking 47
References and Recommended Reading 49
 Contents ix

23. Develop and Try a New Way of Architecting 50

The DoD Procedure for Developing Architecture 50
Products for Views 51
An Alternative Approach 51
References and Recommended Reading 52
24. Plato and Proust 52
Reference and Recommended Reading 54
25. Try to Master New Tools and Use Them as
Needed 54
References and Recommended Reading 56
26. Real EAM 56
References and Recommended Reading 58
27. Ways of Thinking 59
Visualization 59
Lateral Thinking 59
Hybrid Thinking 60
Six Thinking Hats 60
Special Point-of-View Thinking 61
References and Recommended Reading 62
28. New Ideas to Be Explored 63
General Systems Theory 63
Rapid Computer-Aided Systems of Systems 63
New Method of Systems Architecting 64
National Aviation System (NAS) Model 64
Systems Engineering and Software Engineering 64
Emergent Properties of Systems 64
Affordability 64
Design to Cost 64
References and Recommended Reading 65

4 People Oriented 67
29. Building a Highly Productive Systems
Engineering Team 67
The Team Leader 67
Project Management and Leadership 68
References and Recommended Reading 68
30. Listen to Your Elders 69
References and Recommended Reading 71
31. Leadership 71
Practical Visionary 72
Inclusive Communicator 72
Positive Doer 72
x Contents

Renewing Facilitator 72
Principled Integrator 72
Reference and Recommended Reading 73
32. New Boss 73
Reference and Recommended Reading 74
33. Team Busters 74
34. Meetings 76
A Systems Engineering Meeting 78
References and Recommended Reading 78
35. Myers–Briggs 79
Reference and Recommended Reading 80
36. Becoming a Hi-Tech Manager 81
Skills Required 81
Specifc Steps 82
Reference and Recommended Reading 82
37. Dealing with Your Customer 83
Going to Lunch with Your Customer 83
Issuance of a New Task Order 83
Quick Response Capability 84
A Truthful Interchange 84
The Re-Competition 84
38. Integration 85
Reference and Recommended Reading 86
39. Hall, Goode, and Machol 86
A. D. Hall 86
Goode and Machol 87
Machol’ s View 87
References and Recommended Reading 88
40. Man vs. Machine 88

5 Miscellany 91
41. Redundancy is Important and May Be Critical in
Certain Systems 91
Reference and Recommended Reading 93
42. Rechtin’s Heuristics Are Brilliant and Need to
Be Studied and Followed 93
References and Recommended Reading 94
43. Mistakes 95
A Footnote to the IBM – Microsoft Story 96
References and Recommended Reading 96
44. Cost Estimating 97
References and Recommended Reading 98
 Contents xi

45. Generalize 98
46. Risk Analysis and Mitigation 99
Take Your Pick of Serial and Parallel Confgurations 100
References and Recommended Reading 101
47. Change, Options Open, and Iteration 101
Rechtin’s Options Open 102
Confguration Control and Management 102
Iteration 103
TBDs 103
References and Recommended Reading 104
48. DOTSS 104
References and Recommended Reading 105
49. Obversity 105
50. Vaillant, Turned into Lessons Considered 106
Grit 107
Intelligence 107
Listening 107
Focus 107
Integrity 107
Community Involvement 108
Problem Solver 108
Respect 108
Curiosity 108
Sense of Humor 108
Resilient 108
Growth-Oriented 109
References and Recommended Reading 109

6 Top Ten Lessons 111

1. Stovepipes 111
2. Modeling and Simulation 111
3. Architecting 112
4. Amid a Wash of Paper … 113
5. Industry Initiatives and Government Support 113
6. The Elders in Systems Engineering 114
7. Functional Decomposition 114
8. Team Building 115
9. Risk Analysis and Mitigation 115
10. The Systems Approach and Systems Thinking 116
References and Recommended Reading 116

Index 117
Preface

On page 9 (Table 4.1) of the fourth edition of the Systems Engineering

Handbook (produced by INCOSE), it is noticed that an important date in the
origins of systems engineering (SE) as a discipline was cited as 1937. That was
two years after my birth year, which makes me older than the entire feld of SE.
The handbook also takes note of other signifcant dates such as:

1954 – the RAND Corporation recommending and using the terms

(systems engineering)
1962 – Hall’s classic book on systems engineering
1990 – the formation of NCOSE (National Council on Systems
Engineering)
2008 – ISO, IEC, IEEE, INCOSE, and PSM harmonize SE concepts in
standard 15288:2008

This all prompted me to pause for a moment or two and think about systems
engineering, a feld in which I have worked for some 50 years, starting from the
age of 25–75 (I am now past 80). This involvement intersects with my 30 years
in the industry as a working engineer, manager, executive, and president of two
high-tech companies. It also intersects with my 24 years as a professor at the
George Washington University, where I was a strong advocate for the study
and use of systems engineering. “Time to sum up”, I thought. And that is what
this book is all about. I sat down and decided to document the “50 lessons
learned” over this time period. What were some messages I could leave for the
next couple of generations to contemplate with the feld they chose to work in?
So here they are – 50 of them – in six categories and chapters:

• Technical: Chapter 1
• Management: Chapter 2
• Idea-Based: Chapter 3
• People-Oriented: Chapter 4
• Miscellany: Chapter 5
• Top Ten Lessons: Chapter 6

xiii
xiv Preface

I hope that readers will indeed fnd them interesting and useful in their lives as
systems engineers. Some lessons are more powerful and long lasting than oth-
ers, and these are in my “top ten” list, which is Chapter 6. Readers may wish to
pause to think about this set of ten lessons to see if there is any resonance with
their experiences. In any case, it’s all about thinking and re-thinking, review-
ing and re-evaluating, which is what systems engineers like to do.
This book is a retrospective from a systems engineering perspective. As
such, it looks back at 50 years of working in the feld of systems engineering
and cites some 50 “lessons learned” during this rather long period of time.
These lessons are organized into six categories and chapters, as mentioned
above.
This author, from approximately age 25 to 75, has worked on many prob-
lem areas associated with quite a few clients. These have included investiga-
tions in the domains of:

• Satellites and related ground systems

• Aircraft and aviation
• Air traffc control systems
• Cost-effectiveness evaluations
• Systems architecting
• Information systems
• Torpedoes
• Air defense systems
• Radars and sonars
• Battlefeld communications

A sample of customers includes NASA (National Aeronautics and Space

Administration), the DOT (Department of Transportation), and the DoD
(Department of Defense). The readers will note that these three are substantial
agencies and all are part of the federal government. Despite this potential limi-
tation, it is believed that the lessons learned, in the main, apply to more or less
any customer set. So it is hoped that the readers will consider how to use these
lessons in their work in systems engineering and related felds. To the extent
that this is the case, feedback to the author is welcomed, at [email protected].
It is also hoped that some of the readers, when they are inclined to do so, will
document their own sets of lessons learned.

Howard Eisner
Bethesda, Maryland
About the Author

Howard Eisner spent 30 years in industry and 24 years in academia. In the

former, he was a working engineer, manager, executive (at ORI, Inc. and the
Atlantic Research Corporation), and president of two high-tech companies
(Intercon Systems and the Atlantic Research Services Company). In academia,
he was a professor of engineering management and a distinguished research
professor in the Engineering School at the George Washington University
(GWU). At GWU he taught courses in systems engineering, technical enter-
prises, project management, modulation, and noise and information theory.
He has written nine books that relate to engineering, systems, and man-
agement. He has also given lectures, tutorials, and colloquia to professional
societies (such as INCOSE – International Council on Systems Engineering),
government agencies (such as the DoD, NASA, and the DOT), and other
groups (such as the Osher Lifelong Learning Institute (OLLI)).
In 1994, he was given the outstanding achievement award from the GWU
Engineering Alumni.
Dr. Eisner is a Life Fellow of the IEEE (Institute of Electrical and
Electronics Engineers) and a fellow of INCOSE and the New York Academy
of Sciences. He is a member of Tau Beta Pi, Eta Kappa Nu, Sigma Xi, Omega
Rho, and various research/honor societies. He received a Bachelor’s degree
(BEE) from the City College of New York (1957), a Master of Science degree
in Electrical Engineering from Columbia University (1958), and a Doctor of
Science degree from the George Washington University (1966).
Since 2013, he has served as professor emeritus of engineering man-
agement and distinguished research professor at the George Washington
University. As such, he has continued to explore advanced topics in engineer-
ing, systems, and management.

xv
Other Books by
the Author

Computer-Aided Systems Engineering

Reengineering Yourself and Your Company
Managing Complex Systems – Thinking Outside the Box
Essentials of Project and Systems Engineering Management
Systems Engineering – Building Successful Systems
Topics in Systems
Thinking – A Guide to Systems Engineering Problem-Solving
Systems Architecting – Methods and Examples

xvii
Technical
1
1. WHEN AND WHERE POSSIBLE,
GO BACK TO FUNDAMENTALS (*)
So what, indeed, are the fundamentals? In a nutshell, they’re basic physics and
engineering. I would like to illustrate this with a few stories.

Case One
I was having dinner with my son and his two twin sons, my grandchildren.
We were exploring entrepreneurship, and what it might take to become one.
To make a point, I suggested that there might be a huge market for a device
that un-cooks a steak (or the like) when it is well-done rather than rare, as the
customer requested. After all, with such a device, restaurants could save huge
amounts of money.
“That’s a great idea, grandpa”, they both agreed. “Let’s build such a
device”.
I encouraged this whole adventure, and they went off with a happy assign-
ment – to fgure out how to build a steak un-cooker. Their enthusiasm was
almost boundless. If successful, they would become super entrepreneurs – at
age 20.
A few days later I got a phone call from one of these grandchildren.
“Grandpa, I have bad news”, he said
I replied, “Don’t keep me in suspense. What is it?”
“I’m afraid that we can’t build a steak un-cooker. It violates the Second
Law of Thermodynamics! We discovered that by going back to our High
School physics class notes and our textbook”.

1
2 Systems Engineering

“Terrifc”, I said. “You did what needed to be done. You both went back
to some fundamentals”.
And so the tale ended.

Case Two
Another story goes like this. It was suggested by a friend of mine that I visit
with an ex-Israeli who lived in Queens, New York. So when I was spending
some time with my brother in the Big City, I went with my sister-in-law to see
this ex-Israeli. He showed me an “invention” of his, a prism that took in light
and produced the colors of the spectrum as an output.
“There’s more energy coming out than the energy going in”, he said, spin-
ning the prism around in his hand. “How about we develop this together, and
make a fortune”, he suggested. With that, he thrust a paper in front of me and
urged me to sign it. It was a partnership agreement that, presumably, would get
us up and running.
“More energy out than the input energy”, I thought. “That simply cannot be.
That’s more than 100 percent effciency, and violates a basic Law of Physics”.
My sister-in-law, also an ex-Israeli, spoke to him in Hebrew and then to
me in English.
“This is a scam”, she said, under her breath. “Don’t fall for it. He just
wants an open pipeline to your money”.
I had come to the same conclusion, more-or-less at the same time.
“Sorry”, I said, “but I’m going to have to decline your offer, and we have to
leave now”. And with that, we left his premises and drove back to my brother
and sister-in-law’s apartment.
There are times, I thought, when one just needs to go back to fundamen-
tals, which also might help in avoiding a poorly disguised scam.

Case Three
I was a young engineer in my 20s and was watching and listening to a senior
engineer (actually a physicist) explain his thinking in solving a diffcult prob-
lem. He did so with grace and a complete command of physics. He set forth
a very convincing argument as to how he derived a certain formula and what
the “answer” was very likely to look like. I watched and listened in great awe.
“This is what research is all about”, I thought, considering his “heuristic”
as both correct and masterful.
So there we have it. Three cases that help to illustrate the premise. They’re
all different, but they demonstrate the point. Stay with the fundamentals, and
 1 • Technical 3

make sure to be careful as you do so. In particular, listen and don’t sign any
partnership papers.

2. SERIOUSLY EXPLORE ALTERNATIVES,

EVEN IF TIME IS SHORT
This admonition is one of the author’s favorites and receives a fully intentioned
asterisk [1]. A key issue for the system architect is to take the time to defne
and evaluate alternatives. The “analysis of alternatives” (AoA) was suggested
by the Department of Defense (DoD) as an important part of building new
systems. It’s not clear as to when and if the DoD will enforce this suggestion;
it would be surprising if they did not.
The Department of Homeland Security (DHS) has also explored the
notion of analysis of alternatives and has documented their approach [2]. Some
of the features of this approach are delineated below:

• First, the alternatives need to be defned

• Then one identifes operational scenarios and concepts of opera-
tions (CONOPS)
• This is followed by setting forth effectiveness measures for the
alternatives
• Which leads to estimates of cost
• One then plots the values of cost and effectiveness on a graph
• Then this graph is analyzed, in detail

So we see above a basic cost-effectiveness approach. The alternative that is

most cost-effective is usually selected unless there are other over-riding factors
and infuences in play.
Examples of problem areas that are subject to the defnition of alternatives
include:

1. Buying an automobile,
2. Buying a house, and
3. Buying a computer.

But frst we look at a short tale from the world of military communica-
tions. Some years ago, I had the pleasure of working on a system known as
Consolidated Space Operations Center (CSOC) on a sub-contract for the Air
Force. We had won the base contract and moved on to bid on the follow-on
4 Systems Engineering

effort. In our proposal, we were faced with the matter of what our approach
should be – frequency division multiplex (FDM) or time division multiplex
(TDM). During the base year contract, we took the position that FDM was
the preferred approach. This decision carried the day, and we therefore bid an
FDM approach for the second phase contract. As it turned out, a competitive
bid came in, taking a TDM approach. That competitor won the competition.
As best I can remember, going with TDM was in line with a trend toward
digital communications and its inherent compatibility with the computer and
various off-the-shelf hardware and software. So we learned a lesson that day:
in retrospect, it was conjectured that we should have submitted two bids – one
for FDM and the other for TDM. So the wrinkle in the analysis of alternatives
sometimes can be not “either-or”, but “and”. Sometimes it’s possible to bid
more than one alternative, rather than just one.
While we are on the topic of bidding on contracts, we recognize that in
such a scenario where time is usually short, there’s a lot of pressure to come
up with an answer. So participants argue that there’s not enough time to look
at more than one singular alternative. This, of course, is not an AoA case since
there is only one selection. This author believes that this is generally wrong-
headed and that just about all situations call for a legitimate AoA. If one does
not do this, then a price is usually paid down the road.
We turn our attention now to the DoD and what their approach might be
and how they look at the overall issue [3]. The stated objectives of an AoA, as
represented by the Air Force, are:

1. Refne alternatives
2. Refne criteria
3. Refne evaluation factors
4. Work to gain consensus
5. Reduce uncertainty
6. Choose an alternative

We note the following regarding these objectives. First, there is no mention of

cost or effectiveness, explicitly. This, in itself, is a bit surprising. The omission of
a cost analysis is a most serious matter. Second, the consensus item shows inter-
est in and emphasis on the matter of how decisions are formulated and made.
Third, there is the objective of reducing uncertainty. This can be a long and dif-
fcult item, with little guidance as to how to do that. The bottom line appears to
be that the DHS approach and that of the DoD, as defned here by the Air Force,
aren’t quite the same. Indeed, the differences are signifcant. In this comparison,
the Air Force approach would appear to be in need of a second draft.
We end this discussion by simply saying that the AoA is the most impor-
tant notion that should be followed, and refned, for all large-scale systems.
Leaping to an intuitive conclusion with only one alternative may well be a
 1 • Technical 5

mode of operation, but it is not recommended. Take the time to broaden your
consideration to at least two alternatives. In the case of architecting systems,
there is good and suffcient reason to extend your consideration to three alter-
natives. See the presentation on systems architecting in this book.

References and Recommended Reading

1. If given an asterisk, it is in the author’s “top ten”.
2. “Analysis of Alternatives (AoA) Methodologies: Considerations for DHS
Acquisition Analysis”, Version 3.0, 22 January 2014.
3. “An AoA Handbook – A Practical Guide to the AoA”, Offce of Aerospace
Studies, Kirtland AFB, NW 87117 – 5522, 6 July 2016.

3. EMBRACE PROTOTYPING AS WELL

AS MODELING AND SIMULATION
(M & S)
Over the years we have seen a stronger move toward prototyping which has
had a signifcant impact on systems engineering. Where this effect started up
is debatable, but we can see thrusts in the business world mainly in the form
of design. Prototypes can have quite positive effects on a project or system
development such as:

a. Reducing the time needed to produce results

b. Costing less, in the long run
c. Moving from “thinking” to “instantiating”
d. Showing the customer(s) something concrete to react to

The latter often leads to customer interjection such as:

“I like it!” or “I don’t like it but can you change to something like …?”

In the area of modeling and simulation (M & S), we see continual investment in
software. And the reason – to fnd out how the system should be architected and
carry out extensive tradeoff studies that exhibit system and subsystem behavior.
Generally speaking, there are two broad types of M & S systems – event-
driven and time sliced. For the latter, we are interested in what is happen-
ing at every time slice and standard computer time slices that are of course
6 Systems Engineering

synchronous help us in this regard. For the event-driven systems, we often wait
for “important events which are out of time-step”. An example is the appear-
ance of a satellite in and out of view of a ground station as it circles the earth.
This author has attempted to encourage the growth of the M & S feld, start-
ing with his book on Computer-Aided Systems Engineering [1], which delin-
eates a substantial list of useful software in several categories, which includes:

• GPSS
• SIMAN
• SIMSCRIPT
• SLAM
• DYNAMO
• GASP
• CSSL

Other categories of M & S-related software that come to mind are:

a. Design tools
b. Alternatives and preference evaluators
c. AI related

A fnal word on the matter of M & S. Some years ago, this country undertook
the challenge of the SDI, or the Strategic Defense Initiative. It was around the
year 1990, and I was charged with the responsibility (in my company) for fnding
out how to participate in this very important program within the Department of
Defense. I looked around within the company to see what had the best chance of
succeeding in this regard. I looked at the technology that we had built for NASA
and concluded that we had something that might apply to the SDI program. This
was a piece of software that calculated orbital mechanics and position location
on the face of the earth. This might apply to locating a missile that was launched
against us from foreign soil (the so-called boost phase of an enemy missile).
I contacted the person in our company who had built this position location
algorithm and asked for a demonstration of that software. He was more than
happy to oblige since he saw a possible new use for his software, which might
indeed be called M & S software, put to a second purpose.
Soon enough we were both driving down the road to Cherry Hill, New
Jersey, to demonstrate the software to a potential customer. The basic idea
was that the software was capable of simulating the SDI scenario such that
we could compute the kill probabilities of enemy missiles during its various
stages of fight. This customer was impressed and recommended a contract to
explore the SDI scenarios in detail. Soon we were under contract, which was
quite a positive experience for both our company as well as that customer. In a
relatively short period of time, we were showing the SDI program offce what
 1 • Technical 7

we were able to do to simulate the overall set of SDI scenarios. It was a real
breakthrough for the company as well as the customer.
Another experience of this author, in relation to M & S activities, is worth
noting. This was the Climatic Impact Assessment Program (CIAP), a two-year
study sponsored by the Department of Transportation (DOT). The author’s
company had a contract with the DOT to support the program, the essence of
which was to build a series of models that ft together and that also dealt with
the following pieces:

a. A feet of SST aircraft that emitted various effuents as they few,

b. The chemistry between these effuents and the atmosphere,
c. The consequent changes in the atmosphere, and
d. The possible increase in cancer, from the above.

The above four components were constructed as a serial model, and it took
some two years to do so and then be able to do end-to-end calculations.
Finally, we see several books on M & S systems that will keep any reader
up-to-date on this important subject, such as references [2], [3] and [4].

References and Recommended Reading

1. Eisner, H., “Computer-Aided Systems Engineering”, Prentice-Hall, 1988.
2. Sokoloski, J., “Principles of Modeling and Simulation”, Wiley, 2009.
3. Sokoloski, J., and C. Banks, “Modeling and Simulation Fundamentals”, Wiley,
2010.
4. Zeigler, B., “Theory of Modeling and Simulation”, Elsevier, 2000.

4. COST-EFFECTIVENESS IS STILL
THE PREFERRED APPROACH
The U.S. government, especially the DoD, is looking for:

a. Cost-effective solutions,
b. Cost-effective systems, and
c. Cost-effective architectures.

The intuitive meaning is clear – the more cost-effective, the better. And we can
compare two systems based upon their costs and measures of effectiveness.
8 Systems Engineering

But we need to have solid approaches to measure both costs and effectiveness,
the latter being more complicated.
Let C1 = the cost of system 1, C2 = the cost of system 2, E1 = the effective-
ness of system 1, and E2 = the effectiveness of system 2. If C1<C2 and E1> E2,
we can assert that system 1 is more cost-effective than system 2. Other con-
structions, such as C1> C2 and E1> E2, leave us with some uncertainty. System
1 is more effective than system 2, but costs more. Are we willing to pay the
extra price (cost) in order to achieve higher effectiveness? We have to look at
additional details before we can decide on some answer.
This author supports the basic ideas of cost-effectiveness analysis in order
to choose approaches and systems from one another. As suggested above,
other groups and agencies appear likewise to support this approach. If we have
more than two alternatives, more combinations need to be taken into account,
but the basic ideas remain the same.
The notion of cost estimation, of course, is part and parcel of this cost-
effectiveness approach. As easy as this approach sounds in principle, signif-
cant steps have been taken to support this type of estimation [1, 2]. On the
effectiveness side, we conjure up a series of MOEs to generally establish effec-
tiveness measures. These MOEs, by way of example, can be estimated as fol-
lows for various types of systems.

Typical MOEs for Communication Systems

• Detection probability
• False alarm rate
• Signal-to-noise ratio
• Availability
• Grade of service
• Speed of service
• Bit error rate (BER)

Selected MOEs for Transportation Systems

• Trip time
• Passenger capacity
• Freight capacity
• Speed
• Connectivity
• Capacity to demand ratio
 1 • Technical 9

TABLE 4.1 Weighted (Modifed) MOEs Example

MOE MODIFIED
ORIGINAL MOES WEIGHTS (W) RATING (R) MOE (W R )
Trip time
Pax capacity
Freight capacity
Maintainability
Reliability

Limited MOEs for Air Defense Systems

• Probability of target detection
• False alarm probability
• Target kill probability
• Percent of targets detected
• Number of targets in track-while-scan mode

Weighting Factors
If the various MOEs have different levels of importance, we generally weigh
them to obtain modifed MOEs. These modifed values become the new MOEs
for comparative analysis. Such a situation is illustrated in Table 4.1.
There are other ways to approach measuring effectiveness. These are
suggested, for example, in Blanchard and Fabrycky’s classic text [3]. In that
treatise, the authors defne several orders of measure, including performance,
availability, dependability, producability, sustainability, and others. This is
still an open question, but the system analyst, in search of the best design,
needs to look at the overall matter of MOEs in some detail.

References and Recommended Reading

1. “NASA Cost Estimation Handbook”, NASA Cost Analysis Division, NASA
Headquarters, Washington, DC
2. ”Parametric Estimation Handbook”, International Society of Parametric
Analysts, Fourth Edition, April 2008
3. Blanchard, B., and W. Fabrycky, “Systems Engineering and Analysis”, Prentice-
Hall, 2011.
10 Systems Engineering

5. DO NOT ATTEMPT TO
INTEGRATE ALL STOVEPIPES
It is well known that there are many “stovepipes” out there, a stovepipe being a
system with more-or-less a single focus or function. There is also a great temp-
tation, on the part of management, to try to integrate all stovepipes under a
common umbrella system. I have seen more than one directive from an agency
head that basically mandates complete integration of the agency stovepipes. In
addition, I’ve been a frst-hand witness to an attempt to carry out this form of
complete integration.
With respect to the latter situation, I was on an advisory panel for the
Navy, and this particular group was trying to integrate six stovepipes to form
one overarching system. They had a serious budget, but were running out of
time and dollars. Finally, the program to integrate was terminated, and all the
contractors and sub-contractors went home, so to speak. I thought long and
hard about what had happened and realized that the stovepipes were by no
means easily integrated. It was mostly a matter of software, meaning that the
structure and languages for these stovepipes were widely disparate. How do
you integrate software written in six different languages, supported by several
different databases?
Upon further examination, I developed a means by which an “integration
index” could be set forth that would be a measure of how hard it might be to
integrate two or more stovepipes. The idea was to fnd a way to help manage-
ment cope with this not very well understood situation. The essence of that
construction is presented below.
The suggestion here is that we accept the viewpoint and ground rule that says:

• Integrate stovepipes only when it is provably cost-effective to do so.

This means that we simply do not try to integrate when it will cost too much
and/or it will take too much time, or the overall expenditure of resources will
be too high. It also means that we need to brush up on how to do a cost-effec-
tiveness analysis. More about that under another topic in this book.
This matter needs to be studied in detail, for many types of systems, to
be more precise about when and how to deal with the “stovepipe issue”. How
much money and time has been wasted going to the default perspective of issu-
ing a directive that calls for the integration of all stovepipes? My experience
and study say that this is a non-trivial problem that calls out for a systematic
and comprehensive investigation. Management folks in both industry and gov-
ernment certainly deserve such.
Discovering Diverse Content Through
Random Scribd Documents
law in creating the Project Gutenberg™ collection. Despite these
efforts, Project Gutenberg™ electronic works, and the medium
on which they may be stored, may contain “Defects,” such as,
but not limited to, incomplete, inaccurate or corrupt data,
transcription errors, a copyright or other intellectual property
infringement, a defective or damaged disk or other medium, a
computer virus, or computer codes that damage or cannot be
read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except

for the “Right of Replacement or Refund” described in
paragraph 1.F.3, the Project Gutenberg Literary Archive
Foundation, the owner of the Project Gutenberg™ trademark,
and any other party distributing a Project Gutenberg™ electronic
work under this agreement, disclaim all liability to you for
damages, costs and expenses, including legal fees. YOU AGREE
THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT
LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT
EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE
THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY
DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE
TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL,
PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE
NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of
receiving it, you can receive a refund of the money (if any) you
paid for it by sending a written explanation to the person you
received the work from. If you received the work on a physical
medium, you must return the medium with your written
explanation. The person or entity that provided you with the
defective work may elect to provide a replacement copy in lieu
of a refund. If you received the work electronically, the person
or entity providing it to you may choose to give you a second
opportunity to receive the work electronically in lieu of a refund.
If the second copy is also defective, you may demand a refund
in writing without further opportunities to fix the problem.

1.F.4. Except for the limited right of replacement or refund set

forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’,
WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of
damages. If any disclaimer or limitation set forth in this
agreement violates the law of the state applicable to this
agreement, the agreement shall be interpreted to make the
maximum disclaimer or limitation permitted by the applicable
state law. The invalidity or unenforceability of any provision of
this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the

Foundation, the trademark owner, any agent or employee of the
Foundation, anyone providing copies of Project Gutenberg™
electronic works in accordance with this agreement, and any
volunteers associated with the production, promotion and
distribution of Project Gutenberg™ electronic works, harmless
from all liability, costs and expenses, including legal fees, that
arise directly or indirectly from any of the following which you
do or cause to occur: (a) distribution of this or any Project
Gutenberg™ work, (b) alteration, modification, or additions or
deletions to any Project Gutenberg™ work, and (c) any Defect
you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new
computers. It exists because of the efforts of hundreds of
volunteers and donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project
Gutenberg™’s goals and ensuring that the Project Gutenberg™
collection will remain freely available for generations to come. In
2001, the Project Gutenberg Literary Archive Foundation was
created to provide a secure and permanent future for Project
Gutenberg™ and future generations. To learn more about the
Project Gutenberg Literary Archive Foundation and how your
efforts and donations can help, see Sections 3 and 4 and the
Foundation information page at www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-
profit 501(c)(3) educational corporation organized under the
laws of the state of Mississippi and granted tax exempt status
by the Internal Revenue Service. The Foundation’s EIN or
federal tax identification number is 64-6221541. Contributions
to the Project Gutenberg Literary Archive Foundation are tax
deductible to the full extent permitted by U.S. federal laws and
your state’s laws.

The Foundation’s business office is located at 809 North 1500

West, Salt Lake City, UT 84116, (801) 596-1887. Email contact
links and up to date contact information can be found at the
Foundation’s website and official page at
www.gutenberg.org/contact
 Section 4. Information about Donations to
the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission
of increasing the number of public domain and licensed works
that can be freely distributed in machine-readable form
accessible by the widest array of equipment including outdated
equipment. Many small donations ($1 to $5,000) are particularly
important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws

regulating charities and charitable donations in all 50 states of
the United States. Compliance requirements are not uniform
and it takes a considerable effort, much paperwork and many
fees to meet and keep up with these requirements. We do not
solicit donations in locations where we have not received written
confirmation of compliance. To SEND DONATIONS or determine
the status of compliance for any particular state visit
www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states

where we have not met the solicitation requirements, we know
of no prohibition against accepting unsolicited donations from
donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot

make any statements concerning tax treatment of donations
received from outside the United States. U.S. laws alone swamp
our small staff.

Please check the Project Gutenberg web pages for current

donation methods and addresses. Donations are accepted in a
number of other ways including checks, online payments and
credit card donations. To donate, please visit:
www.gutenberg.org/donate.

Section 5. General Information About

Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could
be freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose
network of volunteer support.

Project Gutenberg™ eBooks are often created from several

printed editions, all of which are confirmed as not protected by
copyright in the U.S. unless a copyright notice is included. Thus,
we do not necessarily keep eBooks in compliance with any
particular paper edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg
Literary Archive Foundation, how to help produce our new
eBooks, and how to subscribe to our email newsletter to hear
about new eBooks.
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

textbookfull.com