Post #1 Name/ Abdulelah Altherwi Under the subsection Program Risks, five examples are listed of conditions that may result in a significant probability of program failure. For each example, explain briefly what consequences of the condition may lead to a program failure. Leading-edge unproven technology is to be applied A project may fail as sometimes the project team might use the unproven technology that might not meet the objective needed. Unproven technology is dangerous as it can lead to a waste of resources (Kossiakoff et al., 2011). Further, their use may lead to a result that is not appropriate for the completion of the project. As a result, the team managers will be forced to restart the project, which is a waste of time. A significant increase in performance is required In a situation when a significant improvement in performance is needed for the project, the team may not get enough time to do an efficient job. As a result, some of the stages might be skipped and not followed correctly which is dangerous in the project. Most of the projects fail because the team tries to increase the performance at the expense of following the stages of the project process. A significant decrease in cost is required for the same performance Most of the stages in the project require money to be completed. Reducing the cost can lead to using low-quality resources which will not make the program to be accomplished. Moreover, using them can make the whole team to redo the entire work as sometimes they might not give accurate results. Reducing cost limits the chances of deriving program cost from the systems life cycle cost. A significant more severe operating environment is postulated. Environmental condition is vital in the project completion (Kossiakoff et al., 2011). When the environment is not appropriate, it will affect the functioning of the team hence making them not to work correctly. As a consequence, the project might not be realized or sometimes might be achieved but at a late date as it does not support the project team members. An unduly short development schedule is imposed Unduly short development schedule is dangerous as the team members will not get enough time to coordinate the whole process. As a result, they will not do good work as sometimes they might not to follow the entire systems life cycle. In this way, the project will not be accomplished as per the requirement of the engineering department. Post #2 Name/ Melissa Sanders 8.4) Under the subsection Program Risks, five examples are listed of conditions that may result in a significant probability of program failure. For each example, explain briefly what consequences of the condition may lead to a program failure. a. A leading-edge unproven technology is to be applied In this example, the key word is unproven, which usually means there are few examples of success going into the program. Although past failures can help make changes to new programs, being able to refer back to a success story can help even more with a new program. Usually with leading-edge technology developments there are a lot of unknowns because the development is leading the way to the future. It basically boils down to; you don’t know what you don’t know. When working on a program where there is a lot of uncertainty it inherently brings risk. One of the biggest consequences, aside from the unknown obstacles, when developing leading-edge technology is experience. Having a balance of experienced engineers work with unproven technology is paramount. If only the best engineers work on the program then there’s no opportunity for growth and training for less experienced engineers. If only the least-experienced work on the program, then there isn’t enough prior knowledge to develop the new technology. Having a team with a blend promotes creativity, ingenuity, and usually yields better results in the end. a. A major increase in performance is required. As engineers it is almost second nature to have the desire to build something new. However, having aspirations that are too grand can lead to failure quickly. The best analogy when working with improved performance is the program has to crawl, then walk, then run. If you try to run first the program is going to fall flat on its face. This can usually be the most challenging condition to manage from a risk standpoint because the customer usually wants the latest and greatest or the most for what they are paying for. With any program where improvements are made the customer is usually prepared for the program to be over budget or delayed. However, they won’t accept something that is under performing. When introducing a major increase in performance to a program, this can lead to a case where the requirements aren’t met. a. A major decrease in cost is required for the same performance. Research and Development (R&D) programs usually have large budgets because to meet the performance requirements it costs money when working on any new development. Typically a program manager will have management reserve or other funds set aside to offset unexpected risks that occur throughout the program. On multi-year and multi-million dollar programs, funding levels from year to year are never guaranteed. As the program progresses, if there are budget cuts, usually the funds come out of the management reserve. When this happens, this induces risk because the funds that were being set aside as a mitigation technique are no longer available. When the management reserve reaches zero, then other program costs become affected. When you reduce the budget for a task, you usually de-scope some of the work. It becomes very risky trying to meet original performance requirements when work is de-scoped. Any re-work or fixes that need to happen during the testing phase, cost money to fix, change, or replace. If the funds aren’t available, then the fixes don’t get done. a. A significantly more severe operating environment is postulated. The risk associated with the operating environment is often the most overlooked risk on a program. During the planning and design phases of a program, requirements are established. The requirements associated with the operating environment are just as important as the requirements associated with the product itself. Inexperienced customers will often say things like if it works in the lab it will work outside. Another misconception is if it works in the desert it will work in the forest. As a systems engineer, you have to understand your environment to ensure the product works correctly. A typical progression on an R&D effort is to build something in the lab and then test it outside. However, you wouldn’t take a camera without a housing and go run it in the rain because water usually causes permanent damage to electronics and optics. This is an example of when additional development is needed to prepare the camera to be tested outside. Another example would be image processing for surveillance of a facility surrounded by an open field vs. one in an urban environment. In the first environment there is a wide open area with little “clutter” and it would be easy to spot something unusual in the imagery. However, in the urban environment there is a lot of “clutter”. Things like people walking on the sidewalk, cars driving by, buildings creating “blind spots” make it very challenging to analyze the image for something unusual. For every new challenge that the environment brings, leads to more risk. a. An unduly short development schedule is imposed. As an engineer, the most over used phrase is “you can have it on time, within budget, or working; pick 2.” What this means, is risk is a known factor of every project and usually it impacts schedule, cost, or performance. When managing a risk usually one factor will not be met out of the three. Delays to a program are all too common. However, imposing an unduly short schedule can almost guarantee failure in some manner. The failure doesn’t have to be a schedule delay, it could be that the program costs twice as much to complete. If the program were to be shortened, the most likely failure would be a program delay. The reason for this is the program and all the tasks associated with it take time to complete. Even with crashing the schedule, you eventually reach a point where you can’t shorten the schedule any more. Also, crashing a schedule can lead to team members burning out, making mistakes, or quitting. Throwing more people at the program doesn’t always work because it may take more time to train them (learning curve) than it would to have the original team complete the task. SYSTEMS ENGINEERING PRINCIPLES AND PRACTICE SECOND EDITION Alexander Kossiakoff William N. Sweet Samuel J. Seymour Steven M. Biemer A JOHN WILEY & SONS, INC. PUBLICATION ffirs02.indd iii 2/8/2011 11:05:45 AM ffirs04.indd vi 2/8/2011 11:05:47 AM SYSTEMS ENGINEERING PRINCIPLES AND PRACTICE ffirs.indd i 2/8/2011 11:05:44 AM WILEY SERIES IN SYSTEMS ENGINEERING AND MANAGEMENT Andrew P. Sage, Editor A complete list of the titles in this series appears at the end of this volume. ffirs01.indd ii 2/8/2011 11:05:44 AM SYSTEMS ENGINEERING PRINCIPLES AND PRACTICE SECOND EDITION Alexander Kossiakoff William N. Sweet Samuel J. Seymour Steven M. Biemer A JOHN WILEY & SONS, INC. PUBLICATION ffirs02.indd iii 2/8/2011 11:05:45 AM 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 specifically disclaim any implied warranties of merchantability or fitness 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 profit or any other commercial 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 (800) 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: Systems engineering : principles and practice/Alexander Kossiakoff ... [et al.].—2nd ed. p. cm.—(Wiley series in systems engineering and management; 67) Rev. ed. of: Systems engineering: principles and practices/Alexander Kossiakoff, William N. Sweet. 2003. ISBN 978-0-470-40548-2 (hardback) 1. Systems engineering. I. Kossiakoff, Alexander, 1945– II. Title. TA168.K68 2010 620.001′171–dc22 2010036856 Printed in the United States of America oBook ISBN: 9781118001028 ePDF ISBN: 9781118001011 ePub ISBN: 9781118009031 10 ffirs03.indd iv 9 8 7 6 5 4 3 2 1 2/8/2011 11:05:46 AM To Alexander Kossiakoff, who never took “no” for an answer and refused to believe that anything was impossible. He was an extraordinary problem solver, instructor, mentor, and friend. Samuel J. Seymour Steven M. Biemer ffirs04.indd v 2/8/2011 11:05:47 AM ffirs04.indd vi 2/8/2011 11:05:47 AM CONTENTS LIST OF ILLUSTRATIONS xiii LIST OF TABLES xvii PREFACE TO THE SECOND EDITION xix PREFACE TO THE FIRST EDITION PART I 1 2 xxiii FOUNDATIONS OF SYSTEMS ENGINEERING 1 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS 1.1 What Is Systems Engineering? 1.2 Origins of Systems Engineering 1.3 Examples of Systems Requiring Systems Engineering 1.4 Systems Engineering as a Profession 1.5 Systems Engineer Career Development Model 1.6 The Power of Systems Engineering 1.7 Summary Problems Further Reading 3 3 5 10 12 18 21 23 25 26 SYSTEMS ENGINEERING LANDSCAPE 2.1 Systems Engineering Viewpoint 2.2 Perspectives of Systems Engineering 2.3 Systems Domains 2.4 Systems Engineering Fields 2.5 Systems Engineerng Approaches 2.6 Systems Engineering Activities and Products 2.7 Summary Problems Further Reading 27 27 32 34 35 36 37 38 39 40 vii ftoc.indd vii 2/8/2011 11:05:50 AM viii CONTENTS 3 STRUCTURE OF COMPLEX SYSTEMS 3.1 System Building Blocks and Interfaces 3.2 Hierarchy of Complex Systems 3.3 System Building Blocks 3.4 The System Environment 3.5 Interfaces and Interactions 3.6 Complexity in Modern Systems 3.7 Summary Problems Further Reading 4 THE 4.1 4.2 4.3 4.4 4.5 4.6 5 SYSTEMS ENGINEERING MANAGEMENT 5.1 Managing System Development and Risks 5.2 WBS 5.3 SEMP 5.4 Risk Management 5.5 Organization of Systems Engineering 5.6 Summary Problems Further Reading PART II 6 ftoc.indd viii SYSTEM DEVELOPMENT PROCESS Systems Engineering through the System Life Cycle System Life Cycle Evolutionary Characteristics of the Development Process The Systems Engineering Method Testing throughout System Development Summary Problems Further Reading CONCEPT DEVELOPMENT STAGE NEEDS ANALYSIS 6.1 Originating a New System 6.2 Operations Analysis 6.3 Functional Analysis 6.4 Feasibility Definition 41 41 42 45 51 58 60 64 66 67 69 69 70 82 87 103 106 108 109 111 111 113 117 120 128 132 133 134 137 139 139 146 151 153 2/8/2011 11:05:50 AM ix CONTENTS 6.5 6.6 6.7 Needs Validation System Operational Requirements Summary Problems Further Reading 155 158 162 163 164 7 CONCEPT EXPLORATION 7.1 Developing the System Requirements 7.2 Operational Requirements Analysis 7.3 Performance Requirements Formulation 7.4 Implementation of Concept Exploration 7.5 Performance Requirements Validation 7.6 Summary Problems Further Reading 165 165 170 178 185 189 191 193 194 8 CONCEPT DEFINITION 8.1 Selecting the System Concept 8.2 Performance Requirements Analysis 8.3 Functional Analysis and Formulation 8.4 Functional Allocation 8.5 Concept Selection 8.6 Concept Validation 8.7 System Development Planning 8.8 Systems Architecting 8.9 System Modeling Languages: Unified Modeling Language (UML) and Systems Modeling Language (SysML) 8.10 Model-Based Systems Engineering (MBSE) 8.11 System Functional Specifications 8.12 Summary Problems Further Reading 197 197 201 206 212 214 217 219 222 DECISION ANALYSIS AND SUPPORT 9.1 Decision Making 9.2 Modeling throughout System Development 9.3 Modeling for Decisions 9.4 Simulation 255 256 262 263 272 9 ftoc.indd ix 228 243 246 247 250 252 2/8/2011 11:05:50 AM x CONTENTS 9.5 9.6 9.7 9.8 PART III ftoc.indd x Trade-Off Analysis Review of Probability Evaluation Methods Summary Problems Further Reading 282 295 299 308 311 312 ENGINEERING DEVELOPMENT STAGE 315 10 ADVANCED DEVELOPMENT 10.1 Reducing Program Risks 10.2 Requirements Analysis 10.3 Functional Analysis and Design 10.4 Prototype Development as a Risk Mitigation Technique 10.5 Development Testing 10.6 Risk Reduction 10.7 Summary Problems Further Reading 317 317 322 327 333 340 349 350 352 354 11 SOFTWARE SYSTEMS ENGINEERING 11.1 Coping with Complexity and Abstraction 11.2 Nature of Software Development 11.3 Software Development Life Cycle Models 11.4 Software Concept Development: Analysis and Design 11.5 Software Engineering Development: Coding and Unit Test 11.6 Software Integration and Test 11.7 Software Engineering Management 11.8 Summary Problems Further Reading 355 356 360 365 373 385 393 396 402 405 406 12 ENGINEERING DESIGN 12.1 Implementing the System Building Blocks 12.2 Requirements Analysis 12.3 Functional Analysis and Design 12.4 Component Design 12.5 Design Validation 409 409 414 416 419 432 2/8/2011 11:05:50 AM xi CONTENTS 13 12.6 CM 12.7 Summary Problems Further Reading 436 439 441 442 INTEGRATION AND EVALUATION 13.1 Integrating, Testing, and Evaluating the Total System 13.2 Test Planning and Preparation 13.3 System Integration 13.4 Developmental System Testing 13.5 Operational Test and Evaluation 13.6 Summary Problems Further Reading 443 443 450 455 462 467 475 478 478 PART IV 481 14 PRODUCTION 14.1 Systems Engineering in the Factory 14.2 Engineering for Production 14.3 Transition from Development to Production 14.4 Production Operations 14.5 Acquiring a Production Knowledge Base 14.6 Summary Problems Further Reading 483 483 485 489 492 497 500 502 503 15 OPERATIONS AND SUPPORT 15.1 Installing, Maintaining, and Upgrading the System 15.2 Installation and Test 15.3 In-Service Support 15.4 Major System Upgrades: Modernization 15.5 Operational Factors in System Development 15.6 Summary Problems Further Reading 505 505 507 512 516 520 522 523 524 INDEX ftoc.indd xi POSTDEVELOPMENT STAGE 525 2/8/2011 11:05:50 AM ftoc.indd xii 2/8/2011 11:05:50 AM LIST OF ILLUSTRATIONS 1.1 1.2a 1.2b 1.3a 1.3b 1.4 2.1a 2.1b 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Career opportunities and growth Technical orientation phase diagram Technical orientation population density distribution Systems engineering (SE) career elements derived from quality work experiences Components of employer development of systems engineers “T” model for systems engineer career development Performance versus cost Performance/cost versus cost The ideal missile design from the viewpoint of various specialists The dimensions of design, systems engineering, and project planning and control Systems engineering domains Examples of systems engineering fields Examples of systems engineering approaches Life cycle systems engineering view Knowledge domains of systems engineer and design specialist Context diagram Context diagram for an automobile Environments of a passenger airliner Functional interactions and physical interfaces Pyramid of system hierarchy DoD system life cycle model System life cycle model Principal stages in system life cycle Concept development phases of system life cycle Engineering development phases in system life cycle Principal participants in a typical aerospace system development DoD MIL-STD499B IEEE-1220 systems engineering process EIA-632 systems engineering process 14 16 16 19 19 20 29 29 31 32 34 35 36 37 45 53 54 56 59 63 71 72 75 76 78 86 90 90 91 xiii fbetw01.indd xiii 2/9/2011 6:29:47 PM xiv 4.10 4.11 4.12 4.13 5.1 5.2 5.3 5.4 5.5 6.1 6.2 6.3 6.4 6.5 7.1 7.2 7.3 7.4 7.5 7.6 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 8.17 8.18a 8.18b 8.19 8.20 9.1 9.2 9.3 9.4 fbetw01.indd xiv LIST OF ILLUSTRATIONS ISO-15288 Systems engineering process Systems engineering method top-level flow diagram Systems engineering method flow diagram Spiral model of the defense system life cycle Systems engineering as a part of project management Place of SEMP in program management plans Variation of program risk and effort throughout system development Example of a risk mitigation waterfall chart An example of a risk cube display Needs analysis phase in the system life cycle Needs analysis phase flow diagram Objectives tree structure Example objectives tree for an automobile Analysis pyramid Concept exploration phase in system life cycle Concept exploration phase flow diagram Simple requirements development process Triumvirate of conceptual design Hierarchy of scenarios Function category versus functional media Concept definition phase in system life cycle Concept definition phase flow diagram IDEF0 functional model structure Functional block diagram of a standard coffeemaker Traditional view of architecture DODAF version 2.0 viewpoints UML models Use case diagram UML activity diagram UML sequence diagram Example of a class association Example of a class generalization association Class diagram of the library check-out system SysML models SysML requirements diagram SysML block definition SysML block associations SysML functional hierarchy tree SysML activity diagram Baker ’s MDSD subprocesses Baker ’s information model for MDSD Basic decision-making process Traditional hierarchical block diagram Context diagram of a passenger aircraft Air defense functional flow block diagram 92 92 94 104 112 118 121 122 124 140 147 150 151 156 166 170 171 175 177 181 198 202 208 210 223 227 229 231 233 234 235 236 237 237 238 240 241 242 242 244 244 256 265 266 267 2/9/2011 6:29:47 PM LIST OF ILLUSTRATIONS 9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 9.13 9.14 9.15 9.16 9.17 9.18 9.19 9.20 10.1 10.2 10.3 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9 11.10 11.11 11.12 11.13 12.1 12.2 12.3 13.1 13.2 13.3 13.4 13.5 13.6a 13.6b 13.7 14.1 14.2 fbetw01.indd xv System effectiveness simulation Hardware-in-the-loop simulation Virtual reality simulation Candidate utility functions Criteria profile Union of two events Conditional events AHP example AHP results Decision tree example Decision path Decision tree solved Utility function Decision tree solved with a utility function Example of cost-effectiveness integration QFD house of quality Advanced development phase in system life cycle Advanced development phase flow diagram Test and evaluation process of a system element IEEE software systems engineering process Software hierarchy Notional 3-tier architecture Classical waterfall software development cycle Software incremental model Spiral model State transition diagram in concurrent development model User needs, software requirements and specifications Software generation process Principles of modular partitioning Functional flow block diagram example Data flow diagram: library checkout Robustness diagram: library checkout Engineering design phase in system life cycle Engineering design phase in relation to integration and evaluation Engineering design phase flow diagram Integration and evaluation phase in system life cycle Integration and evaluation phase in relation to engineering design System test and evaluation team System element test configuration Subsystems test configuration Operation of a passenger airliner Operational testing of an airliner Test realism versus cost Production phase in system life cycle Production phase overlap with adjacent phases xv 275 277 280 289 290 297 297 300 301 302 302 303 304 304 305 307 318 321 345 357 359 359 367 369 370 371 376 376 379 381 381 384 410 411 413 445 445 446 456 459 469 469 471 484 485 2/9/2011 6:29:47 PM xvi 14.3 15.1 15.2 15.3 15.4 fbetw01.indd xvi LIST OF ILLUSTRATIONS Production operation system Operations and support phase in system life cycle System operations history Non-disruptive installation via simulation Non-disruptive installation via a duplicate system 494 506 507 510 511 2/9/2011 6:29:47 PM LIST OF TABLES 1.1 1.2 2.1 2.2 3.1 3.2 3.3 3.4 4.1 4.2 4.3 5.1 5.2 5.3 5.4 6.1 7.1 8.1 8.2 9.1 9.2 9.3 9.4 9.5 9.6 10.1 10.2 10.3 10.4 11.1 Examples of Engineered Complex Systems: Signal and Data Systems Examples of Engineered Complex Systems: Material and Energy Systems Comparison of Systems Perspectives Systems Engineering Activities and Documents System Design Hierarchy System Functional Elements Component Design Elements Examples of Interface Elements Evolution of System Materialization through the System Life Cycle Evolution of System Representation Systems Engineering Method over Life Cycle System Product WBS Partial Breakdown Structure Risk Likelihood Risk Criticality Sample Risk Plan Worksheet Status of System Materialization at the Needs Analysis Phase Status of System Materialization of the Concept Exploration Phase Status of System Materialization of Concept Definition Phase Use Case Example—“Check-out Book” Decision Framework Simon’s Decision Process Weighted Sum Integration of Selection Criteria Weighted Sum of Actual Measurement Weighted Sum of Utility Scores Trade-Off Matrix Example Status of System Materialization at the Advanced Development Phase Development of New Components Selected Critical Characteristics of System Functional Elements Some Examples of Special Materials Software Types 11 11 33 38 43 47 49 60 84 88 102 114 125 125 128 143 168 200 232 259 261 288 289 290 293 320 326 329 335 361 xvii fbetw02.indd xvii 2/9/2011 6:29:55 PM xviii 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9 11.10 12.1 12.2 13.1 13.2 13.3 fbetw02.indd xviii LIST OF TABLES Categories of Software-Dominated Systems Differences between Hardware and Software Systems Engineering Life Cycle and the Waterfall Model Commonly Used Computer Languages Some Special-Purpose Computer Languages Characteristics of Prototypes Comparison of Computer Interface Modes Capability Levels Maturity Levels Status of System Materialization at the Engineering Design Phase Configuration Baselines Status of System Materialization at the Integration and Evaluation Phase System Integration and Evaluation Process Parallels between System Development and Test and Evaluation (T&E) Planning 362 364 368 387 388 390 391 398 399 412 437 448 449 451 2/9/2011 6:29:55 PM PREFACE TO THE SECOND EDITION It is an incredible honor and privilege to follow in the footsteps of an individual who had a profound influence on the course of history and the field of systems engineering. Since publication of the first edition of this book, the field of systems engineering has seen significant advances, including a significant increase in recognition of the discipline, as measured by the number of conferences, symposia, journals, articles, and books available on this crucial subject. Clearly, the field has reached a high level of maturity and is destined for continued growth. Unfortunately, the field has also seen some sorrowful losses, including one of the original authors, Alexander Kossiakoff, who passed away just 2 years after the publication of the book. His vision, innovation, excitement, and perseverance were contagious to all who worked with him and he is missed by the community. Fortunately, his vision remains and continues to be the driving force behind this book. It is with great pride that we dedicate this second edition to the enduring legacy of Alexander Ivanovitch Kossiakoff. ALEXANDER KOSSIAKOFF, 1914–2005 Alexander Kossiakoff, known to so many as “Kossy,” gave shape and direction to the Johns Hopkins University Applied Physics Laboratory as its director from 1969 to 1980. His work helped defend our nation, enhance the capabilities of our military, pushed technology in new and exciting directions, and bring successive new generations to an understanding of the unique challenges and opportunities of systems engineering. In 1980, recognizing the need to improve the training and education of technical professionals, he started the master of science degree program at Johns Hopkins University in Technical Management and later expanded it to Systems Engineering, one of the first programs of its kind. Today, the systems engineering program he founded is the largest part-time graduate program in the United States, with students enrolled from around the world in classroom, distance, and organizational partnership venues; it continues to evolve as the field expands and teaching venues embrace new technologies, setting the standard for graduate programs in systems engineering. The first edition of the book is the foundational systems engineering textbook for colleges and universities worldwide. xix fpref01.indd xix 2/8/2011 3:49:23 PM xx PREFACE TO THE SECOND EDITION OBJECTIVES OF THE SECOND EDITION Traditional engineering disciplines do not provide the training, education, and experience necessary to ensure the successful development of a large, complex system program from inception to operational use. The advocacy of the systems engineering viewpoint and the goal for the practitioners to think like a systems engineer are still the major premises of this book. This second edition of Systems Engineering Principles and Practice continues to be intended as a graduate-level textbook for courses introducing the field and practice of systems engineering. We continue the tradition of utilizing models to assist students in grasping abstract concepts presented in the book. The five basic models of the first edition are retained, with only minor refinements to reflect current thinking. Additionally, the emphasis on application and practice is retained throughout and focuses on students pursuing their educational careers in parallel with their professional careers. Detailed mathematics and other technical fields are not explored in depth, providing the greatest range of students who may benefit, nor are traditional engineering disciplines provided in detail, which would violate the book’s intended scope. The updates and additions to the first edition revolve around the changes occurring in the field of systems engineering since the original publication. Special attention was made in the following areas: • • • • • fpref01.indd xx The Systems Engineer ’s Career. An expanded discussion is presented on the career of the systems engineer. In recent years, systems engineering has been recognized by many companies and organizations as a separate field, and the position of “systems engineer” has been formalized. Therefore, we present a model of the systems engineer ’s career to help guide prospective professionals. The Systems Engineering Landscape. The only new chapter introduced in the second edition is titled by the same name and reinforces the concept of the systems engineering viewpoint. Expanded discussions of the implications of this viewpoint have been offered. System Boundaries. Supplemental material has been introduced defining and expanding our discussion on the concept of the system boundary. Through the use of the book in graduate-level education, the authors recognized an inherent misunderstanding of this concept—students in general have been unable to recognize the boundary between the system and its environment. This area has been strengthened throughout the book. System Complexity. Significant research in the area of system complexity is now available and has been addressed. Concepts such as system of systems engineering, complex systems management, and enterprise systems engineering are introduced to the student as a hierarchy of complexity, of which systems engineering forms the foundation. Systems Architecting. Since the original publication, the field of systems architecting has expanded significantly, and the tools, techniques, and practices of this 2/8/2011 3:49:23 PM PREFACE TO THE SECOND EDITION • • xxi field have been incorporated into the concept exploration and definition chapters. New models and frameworks for both traditional structured analysis and objectoriented analysis techniques are described and examples are provided, including an expanded description of the Unified Modeling Language and the Systems Modeling Language. Finally, the extension of these new methodologies, modelbased systems engineering, is introduced. Decision Making and Support. The chapter on systems engineering decision tools has been updated and expanded to introduce the systems engineering student to the variety of decisions required in this field, and the modern processes, tools, and techniques that are available for use. The chapter has also been moved from the original special topics part of the book. Software Systems Engineering. The chapter on software systems engineering has been extensively revised to incorporate modern software engineering techniques, principles, and concepts. Descriptions of modern software development life cycle models, such as the agile development model, have been expanded to reflect current practices. Moreover, the section on capability maturity models has been updated to reflect the current integrated model. This chapter has also been moved out of the special topics part and introduced as a full partner of advanced development and engineering design. In addition to the topics mentioned above, the chapter summaries have been reformatted for easier understanding, and the lists of problems and references have been updated and expanded. Lastly, feedback, opinions, and recommendations from graduate students have been incorporated where the wording or presentation was awkward or unclear. CONTENT DESCRIPTION This book continues to be used to support the core courses of the Johns Hopkins University Master of Science in Systems Engineering program and is now a primary textbook used throughout the United States and in several other countries. Many programs have transitioned to online or distance instruction; the second edition was written with distance teaching in mind, and offers additional examples. The length of the book has grown, with the updates and new material reflecting the expansion of the field itself. The second edition now has four parts: • • fpref01.indd xxi Part I. The Foundation of Systems Engineering, consisting of Chapters 1–5, describes the origins and structure of modern systems, the current field of systems engineering, the structured development process of complex systems, and the organization of system development projects. Part II. Concept Development, consisting of Chapters 6–9, describes the early stages of the system life cycle in which a need for a new system is demonstrated, 2/8/2011 3:49:23 PM xxii PREFACE TO THE SECOND EDITION • • its requirements identified, alternative implementations developed, and key program and technical decisions made. Part III. Engineering Development, consisting of Chapters 10–13, describes the later stages of the system life cycle, in which the system building blocks are engineered (to include both software and hardware subsystems) and the total system is integrated and evaluated in an operational environment. Part IV. Postdevelopment, consisting of Chapters 14 and 15, describes the roles of systems in the production, operation, and support phases of the system life cycle and what domain knowledge of these phases a systems engineer should acquire. Each chapter contains a summary, homework problems, and bibliography. ACKNOWLEDGMENTS The authors of the second edition gratefully acknowledge the family of Dr. Kossiakoff and Mr. William Sweet for their encouragement and support of a second edition to the original book. As with the first edition, the authors gratefully acknowledge the many contributions made by the present and past faculties of the Johns Hopkins University Systems Engineering graduate program. Their sharp insight and recommendations on improvements to the first edition have been invaluable in framing this publication. Particular thanks are due to E. A. Smyth for his insightful review of the manuscript. Finally, we are exceedingly grateful to our families—Judy Seymour and Michele and August Biemer—for their encouragement, patience, and unfailing support, even when they were continually asked to sacrifice, and the end never seemed to be within reach. Much of the work in preparing this book was supported as part of the educational mission of the Johns Hopkins University Applied Physics Laboratory. Samuel J. Seymour Steven M. Biemer 2010 fpref01.indd xxii 2/8/2011 3:49:23 PM PREFACE TO THE FIRST EDITION Learning how to be a successful systems engineer is entirely different from learning how to excel at a traditional engineering discipline. It requires developing the ability to think in a special way, to acquire the “systems engineering viewpoint,” and to make the central objective the system as a whole and the success of its mission. The systems engineer faces three directions: the system user ’s needs and concerns, the project manager ’s financial and schedule constraints, and the capabilities and ambitions of the engineering specialists who have to develop and build the elements of the system. This requires learning enough of the language and basic principles of each of the three constituencies to understand their requirements and to negotiate balanced solutions acceptable to all. The role of interdisciplinary leadership is the key contribution and principal challenge of systems engineering and it is absolutely indispensable to the successful development of modern complex systems. 1.1 OBJECTIVES Systems Engineering Principles and Practice is a textbook designed to help students learn to think like systems engineers. Students seeking to learn systems engineering after mastering a traditional engineering discipline often find the subject highly abstract and ambiguous. To help make systems engineering more tangible and easier to grasp, the book provides several models: (1) a hierarchical model of complex systems, showing them to be composed of a set of commonly occurring building blocks or components; (2) a system life cycle model derived from existing models but more explicitly related to evolving engineering activities and participants; (3) a model of the steps in the systems engineering method and their iterative application to each phase of the life cycle; (4) a concept of “materialization” that represents the stepwise evolution of an abstract concept to an engineered, integrated, and validated system; and (5) repeated references to the specific responsibilities of systems engineers as they evolve during the system life cycle and to the scope of what a systems engineer must know to perform these effectively. The book’s significantly different approach is intended to complement the several excellent existing textbooks that concentrate on the quantitative and analytical aspects of systems engineering. xxiii fpref02.indd xxiii 2/8/2011 3:49:24 PM xxiv PREFACE TO THE FIRST EDITION Particular attention is devoted to systems engineers as professionals, their responsibilities as part of a major system development project, and the knowledge, skills, and mind-set they must acquire to be successful. The book stresses that they must be innovative and resourceful, as well as systematic and disciplined. It describes the special functions and responsibilities of systems engineers in comparison with those of system analysts, design specialists, test engineers, project managers, and other members of the system development team. While the book describes the necessary processes that systems engineers must know and execute, it stresses the leadership, problem-solving, and innovative skills necessary for success. The function of systems engineering as defined here is to “guide the engineering of complex systems.” To learn how to be a good guide requires years of practice and the help and advice of a more experienced guide who knows “the way.” The purpose of this book is to provide a significant measure of such help and advice through the organized collective experience of the authors and other contributors. This book is intended for graduate engineers or scientists who aspire to or are already engaged in careers in systems engineering, project management, or engineering management. Its main audience is expected to be engineers educated in a single discipline, either hardware or software, who wish to broaden their knowledge so as to deal with systems problems. It is written with a minimum of mathematics and specialized jargon so that it should also be useful to managers of technical projects or organizations, as well as to senior undergraduates. 1.2 ORIGIN AND CONTENTS The main portion of the book has been used for the past 5 years to support the five core courses of the Johns Hopkins University Master of Science in Systems Engineering program and is thoroughly class tested. It has also been used successfully as a text for distance course offerings. In addition, the book is well suited to support short courses and in-house training. The book consists of 14 chapters grouped into five parts: • Part I. The Foundations of Systems Engineering, consisting of Chapters 1–4, describes the origin and structure of modern systems, the stepwise development process of complex systems, and the organization of system development projects. • Part II. Concept Development, consisting of Chapters 5–7, describes the first stage of the system life cycle in which a need for a new system is demonstrated, its requirements are developed, and a specific preferred implementation concept is selected. • Part III. Engineering Development, consisting of Chapters 8–10, describes the second stage of the system life cycle, in which the system building blocks are engineered and the total system is integrated and evaluated in an operational environment. fpref02.indd xxiv 2/8/2011 3:49:24 PM PREFACE TO THE FIRST EDITION xxv • Part IV. Postdevelopment, consisting of Chapters 11 and 12, describes the role of systems engineering in the production, operation, and support phases of the system life cycle, and what domain knowledge of these phases in the system life cycle a systems engineer should acquire. • Part V. Special Topics consists of Chapters 13 and 14. Chapter 13 describes the pervasive role of software throughout system development, and Chapter 14 addresses the application of modeling, simulation, and trade-off analysis as systems engineering decision tools. Each chapter also contains a summary, homework problems, and a bibliography. A glossary of important terms is also included. The chapter summaries are formatted to facilitate their use in lecture viewgraphs. ACKNOWLEDGMENTS The authors gratefully acknowledge the many contributions made by the present and past faculties of the Johns Hopkins University Systems Engineering Masters program. Particular thanks are due to S. M. Biemer, J. B. Chism, R. S. Grossman, D. C. Mitchell, J. W. Schneider, R. M. Schulmeyer, T. P. Sleight, G. D. Smith, R. J. Thompson, and S. P. Yanek, for their astute criticism of passages that may have been dear to our hearts but are in need of repairs. An even larger debt is owed to Ben E. Amster, who was one of the originators and the initial faculty of the Johns Hopkins University Systems Engineering program. Though not directly involved in the original writing, he enhanced the text and diagrams by adding many of his own insights and fine-tuned the entire text for meaning and clarity, applying his 30 years’ experience as a systems engineer to great advantage. We especially want to thank H. J. Gravagna for her outstanding expertise and inexhaustible patience in typing and editing the innumerable rewrites of the drafts of the manuscript. These were issued to successive classes of systems engineering students as the book evolved over the past 3 years. It was she who kept the focus on the final product and provided invaluable assistance with the production of this work. Finally, we are eternally grateful to our wives, Arabelle and Kathleen, for their encouragement, patience, and unfailing support, especially when the written words came hard and the end seemed beyond our reach. Much of the work in preparing this book was supported as part of the educational mission of the Johns Hopkins Applied Physics Laboratory. Alexander Kossiakoff William N. Sweet 2002 fpref02.indd xxv 2/8/2011 3:49:24 PM fpref02.indd xxvi 2/8/2011 3:49:24 PM PART I FOUNDATIONS OF SYSTEMS ENGINEERING Part I provides a multidimensional framework that interrelates the basic principles of systems engineering, and helps to organize the areas of knowledge that are required to master this subject. The dimensions of this framework include 1. a hierarchical model of the structure of complex systems; 2. a set of commonly occurring functional and physical system building blocks; 3. a systems engineering life cycle, integrating the features of the U.S Department of Defense, ISO/IEC, IEEE, and NSPE models; 4. four basic steps of the systems engineering method that are iterated during each phase of the life cycle; 5. three capabilities differentiating project management, design specialization, and systems engineering; 6. three different technical orientations of a scientist, a mathematician, and an engineer and how they combine in the orientation of a systems engineer; and 7. a concept of “materialization” that measures the degree of transformation of a system element from a requirement to a fully implemented part of a real system. Systems Engineering Principles and Practice, Second Edition. Alexander Kossiakoff, William N. Sweet, Samuel J. Seymour, and Steven M. Biemer © 2011 by John Wiley & Sons, Inc. Published 2011 by John Wiley & Sons, Inc. 1 p01.indd 1 2/9/2011 4:16:37 PM 2 FOUNDATIONS OF SYSTEMS ENGINEERING Chapter 1 describes the origins and characteristics of modern complex systems and systems engineering as a profession. Chapter 2 defines the “systems engineering viewpoint” and how it differs from the viewpoints of technical specialists and project managers. This concept of a systems viewpoint is expanded to describe the domain, fields, and approaches of the systems engineering discipline. Chapter 3 develops the hierarchical model of a complex system and the key building blocks from which it is constituted. This framework is used to define the breadth and depth of the knowledge domain of systems engineers in terms of the system hierarchy. Chapter 4 derives the concept of the systems engineering life cycle, which sets the framework for the evolution of a complex system from a perceived need to operation and disposal. This framework is systematically applied throughout Parts II–IV of the book, each part addressing the key responsibilities of systems engineering in the corresponding phase of the life cycle. Finally, Chapter 5 describes the key parts that systems engineering plays in the management of system development projects. It defines the basic organization and the planning documents of a system development project, with a major emphasis on the management of program risks. p01.indd 2 2/9/2011 4:16:37 PM 1 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS 1.1 WHAT IS SYSTEMS ENGINEERING? There are many ways in which to define systems engineering. For the purposes of this book, we will use the following definition: The function of systems engineering is to guide the engineering of complex systems. The words in this definition are used in their conventional meanings, as described further below. To guide is defined as “to lead, manage, or direct, usually based on the superior experience in pursuing a given course” and “to show the way.” This characterization emphasizes the process of selecting the path for others to follow from among many possible courses—a primary function of systems engineering. A dictionary definition of engineering is “the application of scientific principles to practical ends; as the design, construction and operation of efficient and economical structures, equipment, and systems.” In this definition, the terms “efficient” and “economical” are particular contributions of good systems engineering. The word “system,” as is the case with most common English words, has a very broad meaning. A frequently used definition of a system is “a set of interrelated Systems Engineering Principles and Practice, Second Edition. Alexander Kossiakoff, William N. Sweet, Samuel J. Seymour, and Steven M. Biemer © 2011 by John Wiley & Sons, Inc. Published 2011 by John Wiley & Sons, Inc. 3 c01.indd 3 2/8/2011 11:04:29 AM 4 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS components working together toward some common objective.” This definition implies a multiplicity of interacting parts that collectively perform a significant function. The term complex restricts this definition to systems in which the elements are diverse and have intricate relationships with one another. Thus, a home appliance such as a washing machine would not be considered sufficiently diverse and complex to require systems engineering, even though it may have some modern automated attachments. On the other hand, the context of an engineered system excludes such complex systems as living organisms and ecosystems. The restriction of the term “system” to one that is complex and engineered makes it more clearly applicable to the function of systems engineering as it is commonly understood. Examples of systems requiring systems engineering for their development are listed in a subsequent section. The above definitions of “systems engineering” and “system” are not represented as being unique or superior to those used in other textbooks, each of which defines them somewhat differently. In order to avoid any potential misunderstanding, the meaning of these terms as used in this book is defined at the very outset, before going on to the more important subjects of the responsibilities, problems, activities, and tools of systems engineering. Systems Engineering and Traditional Engineering Disciplines From the above definition, it can be seen that systems engineering differs from mechanical, electrical, and other engineering disciplines in several important ways: 1. Systems engineering is focused on the system as a whole; it emphasizes its total operation. It looks at the system from the outside, that is, at its interactions with other systems and the environment, as well as from the inside. It is concerned not only with the engineering design of the system but also with external factors, which can significantly constrain the design. These include the identification of customer needs, the system operational environment, interfacing systems, logistics support requirements, the capabilities of operating personnel, and such other factors as must be correctly reflected in system requirements documents and accommodated in the system design. 2. While the primary purpose of systems engineering is to guide, this does not mean that systems engineers do not themselves play a key role in system design. On the contrary, they are responsible for leading the formative (concept development) stage of a new system development, which culminates in the functional design of the system reflecting the needs of the user. Important design decisions at this stage cannot be based entirely on quantitative knowledge, as they are for the traditional engineering disciplines, but rather must often rely on qualitative judgments balancing a variety of incommensurate quantities and utilizing experience in a variety of disciplines, especially when dealing with new technology. 3. Systems engineering bridges the traditional engineering disciplines. The diversity of the elements in a complex system requires different engineering disci- c01.indd 4 2/8/2011 11:04:29 AM ORIGINS OF SYSTEMS ENGINEERING 5 plines to be involved in their design and development. For the system to perform correctly, each system element must function properly in combination with one or more other system elements. Implementation of these interrelated functions is dependent on a complex set of physical and functional interactions between separately designed elements. Thus, the various elements cannot be engineered independently of one another and then simply assembled to produce a working system. Rather, systems engineers must guide and coordinate the design of each individual element as necessary to assure that the interactions and interfaces between system elements are compatible and mutually supporting. Such coordination is especially important when individual system elements are designed, tested, and supplied by different organizations. Systems Engineering and Project Management The engineering of a new complex system usually begins with an exploratory stage in which a new system concept is evolved to meet a recognized need or to exploit a technological opportunity. When the decision is made to engineer the new concept into an operational system, the resulting effort is inherently a major enterprise, which typically requires many people, with diverse skills, to devote years of effort to bring the system from concept to operational use. The magnitude and complexity of the effort to engineer a new system requires a dedicated team to lead and coordinate its execution. Such an enterprise is called a “project” and is directed by a project manager aided by a staff. Systems engineering is an inherent part of project management—the part that is concerned with guiding the engineering effort itself—setting its objectives, guiding its execution, evaluating its results, and prescribing necessary corrective actions to keep it on course. The management of the planning and control aspects of the project fiscal, contractual, and customer relations is supported by systems engineering but is usually not considered to be part of the systems engineering function. This subject is described in more detail in Chapter 5. Recognition of the importance of systems engineering by every participant in a system development project is essential for its effective implementation. To accomplish this, it is often useful to formally assign the leader of the systems engineering team to a recognized position of technical responsibility and authority within the project. 1.2 ORIGINS OF SYSTEMS ENGINEERING No particular date can be associated with the origins of systems engineering. Systems engineering principles have been practiced at some level since the building of the pyramids and probably before. (The Bible records that Noah’s Ark was built to a system specification.) The recognition of systems engineering as a distinct activity is often associated with the effects of World War II, and especially the 1950s and 1960s when a number of textbooks were published that first identified systems engineering as a distinct c01.indd 5 2/8/2011 11:04:29 AM 6 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS discipline and defined its place in the engineering of systems. More generally, the recognition of systems engineering as a unique activity evolved as a necessary corollary to the rapid growth of technology, and its application to major military and commercial operations during the second half of the twentieth century. The global conflagration of World War II provided a tremendous spur to the advancement of technology in order to gain a military advantage for one side or the other. The development of high-performance aircraft, military radar, the proximity fuse, the German VI and V2 missiles, and especially the atomic bomb required revolutionary advances in the application of energy, materials, and information. These systems were complex, combining multiple technical disciplines, and their development posed engineering challenges significantly beyond those that had been presented by their more conventional predecessors. Moreover, the compressed development time schedules imposed by wartime imperatives necessitated a level of organization and efficiency that required new approaches in program planning, technical coordination, and engineering management. Systems engineering, as we know it today, developed to meet these challenges. During the Cold War of the 1950s, 1960s, and 1970s, military requirements continued to drive the growth of technology in jet propulsion, control systems, and materials. However, another development, that of solid-state electronics, has had perhaps a more profound effect on technological growth. This, to a large extent, made possible the still evolving “information age,” in which computing, networks, and communications are extending the power and reach of systems far beyond their previous limits. Particularly significant in this connection is the development of the digital computer and the associated software technology driving it, which increasingly is leading to the replacement of human control of systems by automation. Computer control is qualitatively increasing the complexity of systems and is a particularly important concern of systems engineering. The relation of modern systems engineering to its origins can be best understood in terms of three basic factors: 1. Advancing Technology, which provide opportunities for increasing system capabilities, but introduces development risks that require systems engineering management; nowhere is this more evident than in the world of automation. Technology advances in human–system interfaces, robotics, and software make this particular area one of the fastest growing technologies affecting system design. 2. Competition, whose various forms require seeking superior (and more advanced) system solutions through the use of system-level trade-offs among alternative approaches. 3. Specialization, which requires the partitioning of the system into building blocks corresponding to specific product types that can be designed and built by specialists, and strict management of their interfaces and interactions. These factors are discussed in the following paragraphs. c01.indd 6 2/8/2011 11:04:29 AM ORIGINS OF SYSTEMS ENGINEERING 7 Advancing Technology: Risks The explosive growth of technology in the latter half of the twentieth century and into this century has been the single largest factor in the emergence of systems engineering as an essential ingredient in the engineering of complex systems. Advancing technology has not only greatly extended the capabilities of earlier systems, such as aircraft, telecommunications, and power plants, but has also created entirely new systems such as those based on jet propulsion, satellite communications and navigation, and a host of computer-based systems for manufacturing, finance, transportation, entertainment, health care, and other products and services. Advances in technology have not only affected the nature of products but have also fundamentally changed the way they are engineered, produced, and operated. These are particularly important in early phases of system development, as described in Conceptual Exploration, in Chapter 7. Modern technology has had a profound effect on the very approach to engineering. Traditionally, engineering applies known principles to practical ends. Innovation, however, produces new materials, devices, and processes, whose characteristics are not yet fully measured or understood. The application of these to the engineering of new systems thus increases the risk of encountering unexpected properties and effects that might impact system performance and might require costly changes and program delays. However, failure to apply the latest technology to system development also carries risks. These are the risks of producing an inferior system, one that could become prematurely obsolete. If a competitor succeeds in overcoming such problems as may be encountered in using advanced technology, the competing approach is likely to be superior. The successful entrepreneurial organization will thus assume carefully selected technological risks and surmount them by skillful design, systems engineering, and program management. The systems engineering approach to the early application of new technology is embodied in the practice of “risk management.” Risk management is a process of dealing with calculated risks through a process of analysis, development, test, and engineering oversight. It is described more fully in Chapters 5 and 9. Dealing with risks is one of the essential tasks of systems engineering, requiring a broad knowledge of the total system and its critical elements. In particular, systems engineering is central to the decision of how to achieve the best balance of risks, that is, which system elements should best take advantage of new technology and which should be based on proven components, and how the risks incurred should be reduced by development and testing. The development of the digital computer and software technology noted earlier deserves special mention. This development has led to an enormous increase in the automation of a wide array of control functions for use in factories, offices, hospitals, and throughout society. Automation, most of it being concerned with information processing hardware and software, and its sister technology, autonomy, which adds in capability of command and control, is the fastest growing and most powerful single influence on the engineering of modern systems. c01.indd 7 2/8/2011 11:04:29 AM 8 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS The increase in automation has had an enormous impact on people who operate systems, decreasing their number but often requiring higher skills and therefore special training. Human–machine interfaces and other people–system interactions are particular concerns of systems engineering. Software continues to be a growing engineering medium whose power and versatility has resulted in its use in preference to hardware for the implementation of a growing fraction of system functions. Thus, the performance of modern systems increasingly depends on the proper design and maintenance of software components. As a result, more and more of the systems engineering effort has had to be directed to the control of software design and its application. Competition: Trade-offs Competitive pressures on the system development process occur at several different levels. In the case of defense systems, a primary drive comes from the increasing military capabilities of potential adversaries, which correspondingly decrease the effectiveness of systems designed to defeat them. Such pressures eventually force a development program to redress the military balance with a new and more capable system or a major upgrade of an existing one. Another source of competition comes with the use of competitive contracting for the development of new system capabilities. Throughout the competitive period, which may last through the initial engineering of a new system, each contractor seeks to devise the most cost-effective program to provide a superior product. In developing a commercial product, there are nearly always other companies that compete in the same market. In this case, the objective is to develop a new market or to obtain an increased market share by producing a superior product ahead of the competition, with an edge that will maintain a lead for a number of years. The above approaches nearly always apply the most recent technology in an effort to gain a competitive advantage. Securing the large sums of money needed to fund the development of a new complex system also involves competition on quite a different level. In particular, both government agencies and industrial companies have many more calls on their resources than they can accommodate and hence must carefully weigh the relative payoff of proposed programs. This is a primary reason for requiring a phased approach in new system development efforts, through the requirement for justification and formal approval to proceed with the increasingly expensive later phases. The results of each phase of a major development must convince decision makers that the end objectives are highly likely to be attained within the projected cost and schedule. On a still different basis, the competition among the essential characteristics of the system is always a major consideration in its development. For example, there is always competition between performance, cost, and schedule, and it is impossible to optimize all three at once. Many programs have failed by striving to achieve levels of performance that proved unaffordable. Similarly, the various performance parameters of a vehicle, such as speed and range, are not independent of one another; the efficiency of most vehicles, and hence their operating range, decreases at higher speeds. c01.indd 8 2/8/2011 11:04:29 AM ORIGINS OF SYSTEMS ENGINEERING 9 Thus, it is necessary to examine alternatives in which these characteristics are allowed to vary and to select the combination that best balances their values for the benefit of the user. All of the forms of competition exert pressure on the system development process to produce the best performing, most affordable system, in the least possible time. The process of selecting the most desirable approach requires the examination of numerous potential alternatives and the exercise of a breadth of technical knowledge and judgment that only experienced systems engineers possess. This is often referred to as “trade-off analysis” and forms one of the basic practices of systems engineering. Specialization: Interfaces A complex system that performs a number of different functions must of necessity be configured in such a way that each major function is embodied in a separate component capable of being specified, developed, built, and tested as an individual entity. Such a subdivision takes advantage of the expertise of organizations specializing in particular types of products, and hence is capable of engineering and producing components of the highest quality at the lowest cost. Chapter 3 describes the kind of functional and physical building blocks that make up most modern systems. The immensity and diversity of engineering knowledge, which is still growing, has made it necessary to divide the education and practice of engineering into a number of specialties, such as mechanical, electrical, aeronautical, and so on. To acquire the necessary depth of knowledge in any one of these fields, further specialization is needed, into such subfields as robotics, digital design, and fluid dynamics. Thus, engineering specialization is a predominant condition in the field of engineering and manufacturing and must be recognized as a basic condition in the system development process. Each engineering specialty has developed a set of specialized tools and facilities to aid in the design and manufacture of its associated products. Large and small companies have organized around one or several engineering groups to develop and manufacture devices to meet the needs of the commercial market or of the system-oriented industry. The development of interchangeable parts and automated assembly has been one of the triumphs of the U.S. industry. The convenience of subdividing complex systems into individual building blocks has a price: that of integrating these disparate parts into an efficient, smoothly operating system. Integration means that each building block fits perfectly with its neighbors and with the external environment with which it comes into contact. The “fit” must be not only physical but also functional; that is, its design will both affect the design characteristics and behavior of other elements, and will be affected by them, to produce the exact response that the overall system is required to make to inputs from its environment. The physical fit is accomplished at intercomponent boundaries called interfaces. The functional relationships are called interactions. The task of analyzing, specifying, and validating the component interfaces with each other and with the external environment is beyond the expertise of the individual design specialists and is the province of the systems engineer. Chapter 3 discusses further the importance and nature of this responsibility. c01.indd 9 2/8/2011 11:04:29 AM 10 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS A direct consequence of the subdivision of systems into their building blocks is the concept of modularity. Modularity is a measure of the degree of mutual independence of the individual system components. An essential goal of systems engineering is to achieve a high degree of modularity to make interfaces and interactions as simple as possible for efficient manufacture, system integration, test, operational maintenance, reliability, and ease of in-service upgrading. The process of subdividing a system into modular building blocks is called “functional allocation” and is another basic tool of systems engineering. 1.3 EXAMPLES OF SYSTEMS REQUIRING SYSTEMS ENGINEERING As noted at the beginning of this chapter, the generic definition of a system as a set of interrelated components working together as an integrated whole to achieve some common objective would fit most familiar home appliances. A washing machine consists of a main clothes tub, an electric motor, an agitator, a pump, a timer, an inner spinning tub, and various valves, sensors, and controls. It performs a sequence of timed operations and auxiliary functions based on a schedule and operation mode set by the operator. A refrigerator, microwave oven, dishwasher, vacuum cleaner, and radio all perform a number of useful operations in a systematic manner. However, these appliances involve only one or two engineering disciplines, and their design is based on well-established technology. Thus, they fail the criterion of being complex, and we would not consider the development of a new washer or refrigerator to involve much systems engineering as we understand the term, although it would certainly require a high order of reliability and cost engineering. Of course, home appliances increasingly include clever automatic devices that use newly available microchips, but these are usually self-contained add-ons and are not necessary to the main function of the appliance. Since the development of new modern systems is strongly driven by technological change, we shall add one more characteristic to a system requiring systems engineering, namely, that some of its key elements use advanced technology. The characteristics of a system whose development, test, and application require the practice of systems engineering are that the system • • • is an engineered product and hence satisfies a specified need, consists of diverse components that have intricate relationships with one another and hence is multidisciplinary and relatively complex, and uses advanced technology in ways that are central to the performance of its primary functions and hence involves development risk and often a relatively high cost. Henceforth, references in this text to an engineered or complex system (or in the proper context, just system) will mean the type that has the three attributes noted above, that is, is an engineered product, contains diverse components, and uses advanced technology. These attributes are, of course, in addition to the generic definition stated c01.indd 10 2/8/2011 11:04:29 AM 11 EXAMPLES OF SYSTEMS REQUIRING SYSTEMS ENGINEERING earlier and serve to identify the systems of concern to the systems engineer as those that require system design, development, integration, test, and evaluation. In Chapter 2, we explore the full spectrum of systems complexity and why the systems engineering landscape presents a challenge for systems engineers. Examples of Complex Engineered Systems To illustrate the types of systems that fit within the above definition, Tables 1.1 and 1.2 list 10 modern systems and their principal inputs, processes, and outputs. TABLE 1.1. Examples of Engineered Complex Systems: Signal and Data Systems System Inputs Weather satellite Images Terminal air traffic control system Aircraft beacon responses Track location system Cargo routing requests Travel requests Airline reservation system Clinical information system • • • Patient ID Test records Diagnosis Process • • • • Data storage Transmission Identification Tracking Map tracing Communication Data management • • Information management Outputs Encoded images • • • • • • • • • • Identity Air tracks Communications Routing information Delivered cargo Reservations Tickets Patient status History Treatment TABLE 1.2. Examples of Engineered Complex Systems: Material and Energy Systems System Passenger aircraft • • Passengers Fuel Modern harvester combine Oil refinery • • • • • • • Grain field Fuel Crude oil Catalysts Energy Auto parts Energy • • Fuel Air Auto assembly plant Electric power plant c01.indd 11 Inputs Process • • • • • • • • • • • • • Combustion Thrust Lift Cutting Threshing Cracking Separation Blending Manipulation Joining Finishing Power generation Regulation Outputs Transported passengers Harvested grain Gasoline Oil products Chemicals Assembled auto • • • • • Electric AC power Waste products 2/8/2011 11:04:29 AM 12 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS It has been noted that a system consists of a multiplicity of elements, some of which may well themselves be complex and deserve to be considered a system in their own right. For example, a telephone-switching substation can well be considered as a system, with the telephone network considered as a “system of systems.” Such issues will be discussed more fully in Chapters 2 and 4, to the extent necessary for the understanding of systems engineering. Example: A Modern Automobile. A more simple and familiar system, which still meets the criteria for an engineered system, is a fully equipped passenger automobile. It can be considered as a lower limit to more complex vehicular systems. It is made up of a large number of diverse components requiring the combination of several different disciplines. To operate properly, the components must work together accurately and efficiently. Whereas the operating principles of automobiles are well established, modern autos must be designed to operate efficiently while at the same time maintaining very close control of engine emissions, which requires sophisticated sensors and computer-controlled mechanisms for injecting fuel and air. Antilock brakes are another example of a finely tuned automatic automobile subsystem. Advanced materials and computer technology are used to an increasing degree in passenger protection, cruise control, automated navigation and autonomous driving and parking. The stringent requirements on cost, reliability, performance, comfort, safety, and a dozen other parameters present a number of substantive systems engineering problems. Accordingly, an automobile meets the definition established earlier for a system requiring the application of systems engineering, and hence can serve as a useful example. An automobile is also an example of a large class of systems that require active interaction (control) by a human operator. To some degree, all systems require such interaction, but in this case, continuous control is required. In a very real sense, the operator (driver) functions as an integral part of the overall automobile system, serving as the steering feedback element that detects and corrects deviations of the car ’s path on the road. The design must therefore address as a critical constraint the inherent sensing and reaction capabilities of the operator, in addition to a range of associated human–machine interfaces such as the design and placement of controls and displays, seat position, and so on. Also, while the passengers may not function as integral elements of the auto steering system, their associated interfaces (e.g., weight, seating and viewing comfort, and safety) must be carefully addressed as part of the design process. Nevertheless, since automobiles are developed and delivered without the human element, for purposes of systems engineering, they may be addressed as systems in their own right. 1.4 SYSTEMS ENGINEERING AS A PROFESSION With the increasing prevalence of complex systems in modern society, and the essential role of systems engineering in the development of systems, systems engineering as a profession has become widely recognized. Its primary recognition has come in companies specializing in the development of large systems. A number of these have estab- c01.indd 12 2/8/2011 11:04:29 AM SYSTEMS ENGINEERING AS A PROFESSION 13 lished departments of systems engineering and have classified those engaging in the process as systems engineers. In addition, global challenges in health care, communications, environment, and many other complex areas require engineering systems methods to develop viable solutions. To date, the slowness of recognition of systems engineering as a career is the fact that it does not correspond to the traditional academic engineering disciplines. Engineering disciplines are built on quantitative relationships, obeying established physical laws, and measured properties of materials, energy, or information. Systems engineering, on the other hand, deals mainly with problems for which there is incomplete knowledge, whose variables do not obey known equations, and where a balance must be made among conflicting objectives involving incommensurate attributes. The absence of a quantitative knowledge base previously inhibited the establishment of systems engineering as a unique discipline. Despite those obstacles, the recognized need for systems engineering in industry and government has spurred the establishment of a number of academic programs offering master ’s degrees and doctoral degrees in systems engineering. An increasing number of universities are offering undergraduate degrees in systems engineering as well. The recognition of systems engineering as a profession has led to the formation of a professional society, the International Council on Systems Engineering (INCOSE), one of whose primary objectives is the promotion of systems engineering, and the recognition of systems engineering as a professional career. Career Choices Systems engineers are highly sought after because their skills complement those in other fields and often serve as the “glue” to bring new ideas to fruition. However, career choices and the related educational needs for those choices is complex, especially when the role and responsibilities of a systems engineer is poorly understood. Four potential career directions are shown in Figure 1.1: financial, management, technical, and systems engineering. There are varying degrees of overlap between them despite the symmetry shown in the figure. The systems engineer focuses on the whole system product, leading and working with many diverse technical team members, following the systems engineering development cycle, conducting studies of alternatives, and managing the system interfaces. The systems engineer generally matures in the field after a technical undergraduate degree with work experience and a master of science degree in systems engineering, with an increasing responsibility of successively larger projects, eventually serving as the chief or lead systems engineer for a major systems, or systems-of-systems development. Note the overlap and need to understand the content and roles of the technical specialists and to coordinate with the program manager (PM). The project manager or PM, often with a technical or business background, is responsible for interfacing with the customer and for defining the work, developing the plans, monitoring and controlling the project progress, and delivering the finished output to the customer. The PM often learns from on the job training (OJT) with c01.indd 13 2/8/2011 11:04:29 AM 14 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS CFO MBA One must keep fresh in the technical field to avoid obsolescence BS Developing fiscal skills and tools through horizontal and lateral transitions CTO BS MS OJT CFO Financial Technical management Technical specialty Systems engineering Interfacing with the customer and managing WBS, budgets and schedules Program manager BS PhD MS BS Increasing technical specialty MS Focus on whole systems product OJT Increasing technical and Leading multidisciplinary teams program and developing diverse products responsibility Chief or lead systems engineer Copyright 2008 S.J. Seymour Figure 1.1. Career opportunities and growth. projects of increasing size and importance, enhancing the toolset available with a master of science degree in technical/program management. While not exclusively true, the chief executive officer (CEO) frequently originates from the ranks of the organization’s PMs. The financial or business career path that ultimately could lead to a chief financial officer (CFO) position usually includes business undergraduate and master of business administration (MBA) degrees. Individuals progress through their careers with various horizontal and vertical moves, often with specialization in the field. There is an overlap in skill and knowledge with the PM in areas of contract and finance management. Many early careers start with a technical undergraduate degree in engineering, science or information technology. The technical specialist makes contributions as part of a team in the area of their primary knowledge, honing skills and experience to develop and test individual components or algorithms that are part of a larger system. Contributions are made project to project over time, and recognition is gained from innovative, timely, and quality workmanship. Technical specialists need to continue to learn about their field and to stay current in order to be employable compared to the next generation of college graduates. Often advanced degrees (MS and PhDs) are acquired to enhance knowledge, capability, and recognition, and job responsibilities can lead to positions such as lead engineer, lead scientist, or chief technology officer (CTO) in an organization. The broader minded or experienced specialist often considers a career in systems engineering. c01.indd 14 2/8/2011 11:04:29 AM SYSTEMS ENGINEERING AS A PROFESSION 15 Orientation of Technical Professionals The special relationship of systems engineers with respect to technical disciplines can be better understood when it is realized that technical people not only engage in widely different professional specialties, but their intellectual objectives, interests, and attitudes, which represent their technical orientations, can also be widely divergent. The typical scientist is dedicated to understanding the nature and behavior of the physical world. The scientist asks the questions “Why?” and “How?” The mathematician is usually primarily concerned with deriving the logical consequences of a set of assumptions, which may be quite unrelated to the real world. The mathematician develops the proposition “If A, then B.” Usually, the engineer is mainly concerned with creating a useful product. The engineer exclaims “Voila!” These orientations are quite different from one another, which accounts for why technical specialists are focused on their own aspects of science and technology. However, in most professionals, those orientations are not absolute; in many cases, the scientist may need some engineering to construct an apparatus, and the engineer may need some mathematics to solve a control problem. So, in the general case, the orientation of a technical professional might be modeled by a sum of three orthogonal vectors, each representing the extent of the individual’s orientation being in science, mathematics, or engineering. To represent the above model, it is convenient to use a diagram designed to show the composition of a mixture of three components. Figure 1.2a is such a diagram in which the components are science, mathematics, and engineering. A point at each vertex represents a mixture with 100% of the corresponding component. The composition of the mixture marked by the small triangle in the figure is obtained by finding the percentage of each component by projecting a line parallel to the baseline opposite each vertex to the scale radiating from the vertex. This process gives intercepts of 70% science, 20% mathematics, and 10% engineering for the orientation marked by the triangle. Because the curricula of technical disciplines tend to be concentrated in specialized subjects, most students graduate with limited general knowledge. In Figure 1.2b, the circles representing the orientation of individual graduates are seen to be concentrated in the corners, reflecting their high degree of specialization. The tendency of professional people to polarize into diverse specialties and interests tends to be accentuated after graduation, as they seek to become recognized in their respective fields. Most technical people resist becoming generalists for fear they will lose or fail to achieve positions of professional leadership and the accompanying recognition. This specialization of professionals inhibits technical communication between them; the language barrier is bad enough, but the differences in basic objectives and methods of thought are even more serious. The solution of complex interdisciplinary problems has had to depend on the relatively rare individuals who, for one reason or another, after establishing themselves in their principal profession, have become interested and involved in solving system problems and have learned to work jointly with specialists in various other fields. c01.indd 15 2/8/2011 11:04:29 AM 16 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS (a) (b) Figure 1.2. (a) Technical orientation phase diagram. (b) Technical orientation population density distribution. c01.indd 16 2/8/2011 11:04:29 AM SYSTEMS ENGINEERING AS A PROFESSION 17 The occasional evolution of technical specialists into systems engineers is symbolized in Figure 1.2b by the arrows directed from the vertices toward the center. The small black triangle corresponds to such an evolved individual whose orientation is 30% science, 50% engineering, and 20% mathematics, a balance that would be effective in the type of problem solving with which a systems engineer is typically involved. It is the few individuals who evolve into systems engineers or system architects who become the technical leaders of system development programs. The Challenge of Systems Engineering An inhibiting factor in becoming a professional systems engineer is that it represents a deviation from a chosen established discipline to a more diverse, complicated professional practice. It requires the investment of time and effort to gain experience and an extensive broadening of the engineering base, as well as learning communication and management skills, a much different orientation from the individual’s original professional choice. For the above reasons, an engineer considering a career in systems engineering may come to the conclusion that the road is difficult. It is clear that a great deal must be learned; that the educational experience in a traditional engineering discipline is necessary; and that there are few tools and few quantitative relationships to help make decisions. Instead, the issues are ambiguous and abstract, defying definitive solutions. There may appear to be little opportunity for individual accomplishment and even less for individual recognition. For a systems engineer, success is measured by the accomplishment of the development team, not necessarily the system team leader. What Then Is the Attraction of Systems Engineering? The answer may lie in the challenges of systems engineering rather than its direct rewards. Systems engineers deal with the most important issues in the system development process. They design the overall system architecture and the technical approach and lead others in designing the components. They prioritize the system requirements in conjunction with the customer to ensure that the different system attributes are appropriately weighted when balancing the various technical efforts. They decide which risks are worth undertaking and which are not, and how the former should be hedged to ensure program success. It is the systems engineers who map out the course of the development program that prescribes the type and timing of tests and simulations to be performed along the way. They are the ultimate authorities on how the system performance and system affordability goals may be achieved at the same time. When unanticipated problems arise in the development program, as they always do, it is the systems engineers who decide how they may be solved. They determine whether an entirely new approach to the problem is necessary, whether more intense effort will accomplish the purpose, whether an entirely different part of the system can c01.indd 17 2/8/2011 11:04:29 AM 18 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS be modified to compensate for the problem, or whether the requirement at issue can best be scaled back to relieve the problem. Systems engineers derive their ability to guide the system development not from their position in the organization but from their superior knowledge of the system as a whole, its operational objectives, how all its parts work together, and all the technical factors that go into its development, as well as from their proven experience in steering complex programs through a maze of difficulties to a successful conclusion. Attributes and Motivations of Systems Engineers In order to identify candidates for systems engineering careers, it is useful to examine the characteristics that may be useful to distinguish people with a talent for systems engineering from those who are not likely to be interested or successful in that discipline. Those likely to become talented systems engineers would be expected to have done well in mathematics and science in college. A systems engineer will be required to work in a multidisciplinary environment and to grasp the essentials of related disciplines. It is here that an aptitude for science and engineering helps a great deal because it makes it much easier and less threatening for individuals to learn the essentials of new disciplines. It is not so much that they require in depth knowledge of higher mathematics, but rather, those who have a limited mathematical background tend to lack confidence in their ability to grasp subjects that inherently contain mathematical concepts. A systems engineer should have a creative bent and must like to solve practical problems. An interest in the job should be greater than an interest in career advancement. Systems engineering is more of a challenge than a quick way to the top. The following characteristics are commonly found in successful systems engineers. They 1. 2. 3. 4. 5. 6. 7. 8. 9. 1.5 enjoy learning new things and solving problems, like challenges, are skeptical of unproven assertions, are open-minded to new ideas, have a solid background in science and engineering, have demonstrated technical achievement in a specialty area, are knowledgeable in several engineering areas, pick up new ideas and information quickly, and have good interpersonal and communication skills. SYSTEMS ENGINEER CAREER DEVELOPMENT MODEL When one has the characteristics noted above and is attracted to become a systems engineer, there are four more elements that need to be present in the work environment. As shown in Figure 1.3a, one should seek assignments to problems and tasks that are c01.indd 18 2/8/2011 11:04:29 AM SYSTEMS ENGINEER CAREER DEVELOPMENT MODEL 19 (a) (b) Figure 1.3. (a) Systems engineering (SE) career elements derived from quality work experiences. (b) Components of employer development of systems engineers. very challenging and are likely to expand technical domain knowledge and creative juices. Whatever the work assignment, understanding the context of the work and understanding the big picture is also essential. Systems engineers are expected to manage many activities at the same time, being able to have broad perspectives but able to delve deeply into to many subjects at once. This ability to multiplex is one that takes time to develop. Finally, the systems engineer should not be intimidated by complex problems since this is the expected work environment. It is clear these elements are not part of an educational program and must be gained through extended professional work experience. This becomes the foundation for the systems engineering career growth model. Employers seeking to develop systems engineers to competitively address more challenging problems should provide key staff with relevant systems engineering work experience, activities that require mature systems thinking, and opportunities for systems engineering education and training. In Figure 1.3b, it can be seen that the experience can be achieved not only with challenging problems but also with c01.indd 19 2/8/2011 11:04:29 AM 20 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS Domain Breadth Systems Program Lead Systems Engineering Leader (>20 years) Program Lead DSci PhD BS Edu ucation MS CE ME EE Mentoring Technical Depth Large Project Lead Operational and Field Experience Senior Systems Engineer (13–20 years) Small Project Lead Systems Engineer (9–12 years) Team Participant (5–8 years) Technical Contributor (1–4 years) AE App Math … Educational Disciplines Figure 1.4. “T” model for systems engineer career development. CE, chemical engineering; ME, mechanical engineering; EE, electrical engineering; AE, aeronautical engineering; App Math, applied mathematics. experienced mentors and real, practical exercises. While using systems thinking to explore complex problem domains, staff should be encouraged to think creatively and out of the box. Often, technically trained people rigidly follow the same processes and tired ineffective solutions. Using lessons learned from past programs and case studies creates opportunities for improvements. Formal training and use of systems engineering tools further enhance employee preparation for tackling complex issues. Interests, attributes, and training, along with an appropriate environment, provide the opportunity for individuals to mature into successful systems engineers. The combination of these factors is captured in the “T” model for systems engineer career development illustrated in Figure 1.4. In the vertical, from bottom to top is the time progression in a professional’s career path. After completion of a technical undergraduate degree, shown along the bottom of the chart, an individual generally enters professional life as a technical contributor to a larger effort. The effort is part of a project or program that falls in a particular domain such as aerodynamics, biomedicine, combat systems, information systems, or space exploration. Within a domain, there are several technical competencies that are fundamental for systems to operate or to be developed. The T is formed by snapshots during a professional’s career that illustrates in the horizontal part of the T the technical competencies at the time that were learned and used to meet the responsibilities assigned at that point in their career. After an initial c01.indd 20 2/8/2011 11:04:30 AM THE POWER OF SYSTEMS ENGINEERING 21 experience in one or two technical domains as technical contributor, one progresses to increasing responsibilities in a team setting and eventually to leading small technical groups. After eight or more years, the professional has acquired both sufficient technical depth and technical domain depth to be considered a systems engineer. Additional assignments lead to project and program systems engineering leadership and eventually to being the senior systems engineer for a major development program that exercises the full range of the technical competencies for the domain. In parallel with broadening and deepening technical experience and competencies, the successful career path is augmented by assignments that involve operational field experiences, advanced education and training, and a strong mentoring program. In order to obtain a good understanding of the environment where the system under development will operate and to obtain firsthand knowledge of the system requirements, it is essential for the early systems engineer professional to visit the “field site” and operational location. This approach is important to continue throughout one’s career. A wide variety of systems engineering educational opportunities are available in both classroom and online formats. As in most engineering disciplines where the student is not planning on an academic career, the master of science is the terminal degree. Courses are usually a combination of systems engineering and domain or concentration centric focused with a thesis or capstone project for the students to demonstrate their knowledge and skills on a practical systems problem. Large commercial companies also provide training in systems engineering and systems architecting with examples and tools that are specific to their organization and products. Finally, the pairing of a young professional with an experienced systems engineer will enhance the learning process. 1.6 THE POWER OF SYSTEMS ENGINEERING If power is measured by authority over people or money, then systems engineers would appear to have little power as members of the system development team. However, if power is measured by the influence over the design of the system and its major characteristics, and over the success or failure of the system development, then systems engineers can be more powerful than project managers. The sources of this power come from their knowledge, skills, and attitude. Each of these is discussed in the following paragraphs. The Power of Multidisciplinary Knowledge A major system development project is a veritable “Tower of Babel.” There are literally dozens of specialists in different disciplines whose collective efforts are necessary to develop and produce a successful new system. Each group of specialists has its own language, making up for the imprecision of the English language with a rich set of acronyms, which convey a very specific meaning but are unintelligible to those outside the specialty. The languages, in turn, are backed up by knowledge bases, which the specialists use to ply their trade. These knowledge bases contain descriptions of the different materials peculiar to each discipline, as well as bodies of relationships, many c01.indd 21 2/8/2011 11:04:30 AM 22 SYSTEMS ENGINEERING AND THE WORLD OF MODERN SYSTEMS of them expressed in mathematical terms, that enable the specialists to compute various characteristics of their components on the basis of design assumptions. These knowledge bases are also foreign to those outside the discipline. Such a collection of multi-tongued participants could never succeed in collectively developing a new system by themselves, just as the citizens of Babylon could never build their tower. It is the systems engineers who provide the linkages that enable these disparate groups to function as a team. The systems engineers accomplish this feat through the power of multidisciplinary knowledge. This means that they are sufficiently literate ...
Purchase answer to see full attachment