NASA Engineering Handbook
Published on: Mar 3, 2016
Transcripts - NASA Engineering Handbook
NASA Systems Engineering Handbook Page iiForeword from a systems perspective, starting at mission needs and conceptual studies through operations and disposal. In an attempt to demonstrate the potential While it would be impossible to thank all of thedangers of relying on purely cookbook" logical people directly involved, it is essential to note the efforts ofthinking, the mathematician/philosopher Carl Hempel Dr. Robert Shishko of the Jet Propulsion Laboratory. Bobposed a paradox. If we want to prove the hypothesis was largely responsible for ensuring the completion of this“AII ravens are black," we can look for many ravens effort. His technical expertise and nonstop determinationand determine if they all meet our criteria. Hempel were critical factors to ensure the success of this project.suggested changing the hy –pothesis to its logicalcontrapositive (a rewording with identical meaning) Mihaly Csikzenthmihali defined an optimalwould be easier. The new hypothesis becomes: "All experience as one where there is "a sense of exhilaration, a deep sense of enjoyment that is long cherished andnonblack things are nonravens." This transformation, becomes a landmark in memory of what life should be like." Isupported by the laws of logical thinking, makes it am not quite sure if the experience which produced this handmuch easier to test, but unfortunately is ridiculous. –book can be described exactly this way, yet the sentimentHempels raven paradox points out the importance of seems reasonably close.common sense and proper background exploration,even to subjects as intricate as systems engineering. —Dr. Edward J. Hoffman Program Manager, NASA HeadquartersIn 1989, when the initial work on the NASA Systems Spring 199Engineering Handbook was started, there were manywho were concerned about the dangers of adocument that purported to teach a generic NASAapproach to systems engineering. Like Hempelsraven, there were concerns over the potential ofproducing a "cookbook" which of fered the illusion oflogic while ignoring experience and common sense.From the tremendous response to the initial(September 1992) draft of the handbook (in terms ofboth requests for copies and praise for the product), itseems early concerns were largely unfounded andthat there is a strong need for this handbook. The document you are holding represents whatwas deemed best in the original draft and updatesinformation necessary in light of recommendations andchanges within NASA. This handbook represents some ofthe best thinking from across NASA. Many expertsinfluenced its outcome, and consideration was given to eachidea and criticism. It truly represents a NASA-wide productand one which furnishes a good overview of NASA systemsengineering. The handbook is intended to be an educationalguide written from a NASA perspective. Individuals who takesystems engineering courses are the primary audience forthis work. Working professionals who require a guidebook toNASA systems engineering represent a secondaryaudience. It was discovered during the review of the draftdocument that interest in this work goes far beyond NASA.Requests for translating this work have come frominternational sources, and we have been told that the drafthand book is being used in university courses on the subject.All of this may help explain why copies of the original drafthandbook have been in short supply. The main purposes of the NASA SystemsEngineering Handbook are to provide: 1) useful informationto system engineers and project managers, 2) a genericdescription of NASA systems engineering which can besupported bycenter-specific documents, 3) a common language andperspective of the systems engineering process, and 4) areference work which is consistent with NMI 7120.4/NHB7120.5. The handbook approaches systems engineering
NASA Systems Engineering Handbook Page iiiForeword to the September 1992 Draft As such, this present document is to be considered a next-to-final draft. Your comments, When NASA began to sponsor agency – corrections and suggestions are welcomed, valuedwide classes in systems engineering, it was to a and appreciated. Please send your remarks directly todoubting audience. Top management was quick to Robert Shishko, NASA Systemsexpress concern. As a former Deputy Administrator Engineering Working Group. NASA/Jet Propulsionstated "How can you teach an agency-wide systems Laboratory, California Institute of Technology,engineering class when we cannot even agree on 4800 Oak Grove Drive, Pasadena, CAhow to define it?" Good question, and one I must 91109-8099.admit caused us considerable concern at that time. —Francis T. HobanThe same doubt continued up until the publication of Program Manager, NASA Headquartersthis handbook. The initial systems engineering educationconference was held in January 1989 at the JohnsonSpace Center. A number of representatives fromother Centers at tended this meeting and it wasdecided then that we needed to form a working groupto support the development of appropriate andtailored systems engineering courses. At this meetingthe representatives from Marshal1 Space FlightCenter (MSFC) expressed a strong desire to document their own historic systems engineering processbefore any more of the key players left the Center.Other Centers also expressed a desire, if not asurgent as MSFC, to document their processes. It was thought that the best way to reflect thetotality of the NASA systems engineering process andto aid in developing the needed training was toprepare a top level (Level 0) document that wouldcontain a broad definition of systems engineering, abroad process outline, and typi cal tools andprocedures. In general, we wanted a top leveloverview of NASA systems engineering. To thisdocument would be appended each Centers uniquesystems engineering manual. The group was wellaware of the diversity each Center may have, butagreed that this approach would be quite acceptable. The next step and the most difficult in thisarduous process was to find someone to head thisyet-to-be-formed working group. Fortunately forNASA, Donna [Pivirotto] Shirley of the Jet PropulsionLaboratory stepped up to the challenge. Today,through her efforts, those of the working group, andthe skilled and dedicated authors, we have a uniqueand possibly a historic document. During the development of the manual wedecided to put in much more than may be appropriatefor a Level 0 document with the idea that we couldalways refine the document later. It was moreimportant to capture the knowledge when we could inorder to better position our selves for laterdissemination. If there is any criticism, it may be thelevel of detail contained in the manual, but this detailis necessary for young engineers. The presentdocument does appear to serve as a goodinstructional guide, although it does go well beyond itsoriginal intent.
NASA Systems Engineering Handbook Page 5Preface JSC-49040. The SEPIT project life cycle is intentionally consistent with that in NMI 7120.4/NHB This handbook was written to bring the 7120.5 (Management of Major System Programs andfundamental concepts and techniques of systems Projects), but provides more detail on its systemsengineering to NASA personnel in a way that engineering aspects.recognizes the nature of NASA systems and theNASA environment. The authors readily acknowledge This handbook consists of five corethat this goal will not be easily realized. One reason is chapters: (1) systems engineerings intellectualthat not everyone agrees on what systems process, (2) the NASA project life cycle, (3)engineering is, nor on how to do it. There are management issues in systems engineering, (4)legitimate differences of opinion on basic definitions, systems analysis and modeling issues, and (5)content, and techniques. Systems engineering itself is engineering specialty integration. These corea broad subject, with many different aspects. This chapters are supplemented by appendices, which caninitial handbook does not (and cannot) cover all of be expanded to accommodate any number ofthem. templates and examples to illustrate topics in the core chapters. The handbook makes extensive use of The content and style of this handbook show sidebars to define, refine, illustrate, and extenda teaching orientation. This handbook was meant to concepts in the core chapters without diverting theaccompany formal NASA training courses on systems reader from the main argument. There are noengineering, not to be a stand-alone, comprehensive footnotes; sidebars are used instead. The structure ofview of NASA systems engineering. Systems the handbook also allows for additional sections andengineering, in the authors opinions, cannot be chapters to be added at a later date.learned simply by starting at a well-defined beginning Finally, the handbook should be considered only aand proceeding seamlessly from one topic to another. starting point. Both NASA as a systems engineeringRather, it is a field that draws from many engineering organization, and systems engineering as a discipline,disciplines and other intellectual domains. The are undergoing rapid evolution. Over the next fiveboundaries are not always clear, and there are many years, many changes will no doubt occur, and someinteresting intellectual offshoots. Consequently, this are already in progress. NASA, for instance, ishandbook was designed to be a top-level overview of moving toward implementation of the standards in thesystems engineering as a discipline; brevity of International Standards Organization (ISO) 9000exposition and the provision of pointers to other books family, which will affect many aspects of systemsand documents for details were considered important engineering. In systems engineering as a discipline,guidelines. efforts are underway to merge existing systems engineering standards into a common American The material for this handbook was drawn National Standard on the Engineering of Systems,from many different sources, including field center and then ultimately into an international standard.systems engineering handbooks, NASA management These factors should be kept in mind when using thisinstructions (NMls) and NASA handbooks (NHBs), handbookfield center briefings on systems engineeringprocesses, non-NASA systems engineering textbooksand guides, and three independent systemsengineering courses taught to NASA audiences. Thehandbook uses this material to provide only top-levelinformation and suggestions for good systemsengineering practices; it is not intended in any way tobe a directive. By design, the handbook covers some topicsthat are also taught in Project Management/ProgramControl (PM/PC) courses, reflecting the unavoidableconnectednessof these three domains. The material on the NASAproject life cycle is drawn from the work of the NASA-wide Systems Engineering Working Group (SEWG),which met periodically in 1991 and 1992, and itssuccessor, the Systems Engineering ProcessImprovement Task (SEPIT) team, which met in 1993And 1994. This handbooks project life cycle isidentical to that promulgated in the SEPIT report,NASA SystemsEngineering Process for Programs and Projects,
NASA Systems Engineering Handbook Page 6Acknowledgements Mr. Don Woodruff, NASA/Marshall Space FlightThis work was conducted under the overall direction Centerof Mr. Frank Hoban, and then Dr. Ed Hoffman, NASAHeadquarters/Code FT, under the NASA Pro- Other Sources:gram/Project Management Initiative (PPMI). Dr. Mr. Dave Austin, NASA Headquarters/Code DSSShahid Habib, NASA Headquarters/Code QW, Mr. Phillip R. Barela, NASA/Jet Propulsion Laboratoryprovided additional financial support to the NASA- Mr. J.W. Bott, NASA/Jet Propulsion Laboratorywide Systems Engineering Working Group and Dr. Steven L. Cornford, NASA/Jet PropulsionSystems Engineering Process Improvement Task Laboratoryteam. Many individuals, both in and out of NASA, Ms. Sandra Dawson, NASA/Jet Propulsion Laboratorycontributed material, reviewed various drafts, or Dr. James W. Doane, NASA/Jet Propulsionotherwise provided valuable input to this handbook. LaboratoryUnfortunately, the lists below cannot include everyone Mr. William Edminston, NASA/Jet Propulsionwho shared their ideas and experience. Laboratory Mr. Charles C. Gonzales, NASA/Jet PropulsionPrincipal Contributors: LaboratoryDr. Robert Shishko, NASA/Jet Propulsion Laboratory Dr. Jairus Hihn, NASA/Jet Propulsion LaboratoryMr. Robert G. Chamberlain, P.E., NASA/Jet Dr. Ed Jorgenson, NASA/Jet Propulsion LaboratoryPropulsion Laboratory Mr. Richard V. Morris, NASA/Jet Propulsion LaboratoryOther Contributors: Mr. Tom Weber, Rockwell International/SpaceMr. Robert Aster, NASA/Jet Propulsion Laboratory SystemsMs. Beth Bain, Lockheed Missiles and SpaceCompany Reviewers:Mr. Guy Beutelschies, NASA/Jet Propulsion Mr. Robert C. Baumann, NASA/Goddard Space FlightLaboratory CenterDr. Vincent Bilardo, NASA/Ames Research Center Mr. Chris Carl, NASA/Jet Propulsion LaboratoryMs. Renee I. Cox, NASA/Marshall Space Flight Dr. David S.C. Chu, Assistant Secretary ofCenter Defense/Pro-gramDr. Kevin Forsberg, Center for Systems Management Analysis and EvaluationDr. Walter E. Hammond, Sverdrup Techology, Inc. Mr. M.J. Cork, NASA/Jet Propulsion LaboratoryMr. Patrick McDuffee, NASA/Marshall Space Flight Mr. James R. French, JRF Engineering ServicesCenter Mr. John L. Gasery, Jr., NASA/Stennis Space CenterMr. Harold Mooz, Center for Systems Management Mr. Frederick D. Gregory, NASA Headquarters/CodeMs. Mary Beth Murrill, NASA/Jet Propulsion QLaboratory Mr. Don Hedgepeth, NASA/Langley Research CenterDr. Les Pieniazek Lockheed Engineering and Mr. Jim Hines, Rockwell International/Space SystemsScienceS Mr. Keith L. Hudkins, NASA Headquarters/Code MZCo. Mr. Lou Polaski, Center for Systems Management Dr. Jerry Lake, Defense Systems ManagementMr. Neil Rainwater, NASA/Marshall Space Flight CollegeCenter Mr. T.J. Lee, NASA/Marshall Space Flight CenterMr. Tom Rowell, NASA/Marshall Space Flight Center Mr. Jim Lloyd, NASA Headquarters/Code QSMs. Donna Shirley, NASA/Jet Propulsion Laboratory Mr. Woody Lovelace, NASA/Langley ResearchMr. Mark Sluka, Lockheed Engineering and Sciences CenterCo. Mr. Ron Wade, Center for Systems Management Dr. Brian Mar, Department of Civil Engineering,SEPIT team members (not already mentioned): UniversityMr. Randy Fleming, Lockheed Missiles and Space of WashingtonCo. Dr. Ralph F. Miles, Jr., Center for Safety and SystemDr. Frank Fogle, NASA/Marshall Space Flight Center Management, University of Southern CaliforniaMr. Tony Fragomeni, NASA/Goddard Space Flight Dr. Richard A. Montgomery, Montgomery andCenter Dr. Shahid Habib, NASA Headquarters/Code AssociatesQW Mr. Bernard G. Morais, Synergistic Applications, Inc.Mr. Henning Krome, NASA/Marshall Space Flight Mr. Ron Moyer, NASA Headquarters/Code QWCenter Mr. Rudy Naranjo, NASA Headquarters/Code MZMr. Ray Lugo, NASA/Kennedy Space Center Mr. Raymond L. Nieder, NASA/Johnson SpaceMr. William C. Morgan, NASA/Johnson Space Center CenterDr. Mike Ryschkewitsch, NASA/Goddard Space Flight Mr. James E. Pearson, United TechnologiesCenter ResearchMr. Gerry Sadler, NASA/Lewis Research Center CenterMr. Dick Smart, Sverdrup Technology, Inc. Mr. Leo Perez, NASA Headquarters/Code QPDr. James Wade, NASA/Johnson Space Center Mr. David Pine, NASA Headquarters/Code BMr. Milam Walters, NASA/Langley Research Center
NASA Systems Engineering Handbook Page 7Mr. Glen D. Ritter, NASA/Marshall Space FlightCenterDr. Arnold Ruskin, NASA/Jet PropulsionLaboratory and University of California atLos AngelesMr. John G. Shirlaw, Massachusetts Institute ofTechnologyMr. Richard E. Snyder, NASAlLangley ResearchCenterMr. Don Sova, NASA Headquarters/Code AEMr. Marvin A. Stibich, USAF/Aeronautical SystemsCenterMr. Lanny Taliaferro, NASAtMarshall Space FlightCenterEditorial and graphics support:Mr. Stephen Brewster, NASA/Jet PropulsionLaboratoryMr. Randy Cassingham, NASA/Jet PropulsionLaboratoryMr. John Matlock, NASA/Jet Propulsion Laboratory—Dr. Robert ShishkoTask Manager, NASA/Jet Propulsion Laboratory
NASA Systems Engineering Handbook Page 11 Introduction The subject matter of systems engineering is1.1 Purpose very broad. The coverage in this handbook is limited to general concepts and generic descriptions of This handbook is intended to provide processes, tools, and techniques. It providesinformation on systems engineering that will be useful information on good systems engineering practices,to NASA sys-tem engineers, especially new ones. Its and pitfalls to avoid.primary objective is to provide a generic description of There are many textbooks that can be consulted forsystems engineering as it should be applied in-depth tutorials.throughout NASA. Field centers handbooks areencouraged to provide center-specific details of This handbook describes systemsimplementation. engineering as it should be applied to the development of major NASA systems. Systems For NASA system engineers to choose to engineering deals both with the system beingkeep a copy of this handbook at their elbows, it must developed (the product system) and the system thatprovide answers that cannot be easily found does the developing (the producing system).elsewhere. Conse-quently, it provides NASA-relevant Consequently, the handbooks scope properlyperspectives and NASA-particular data. NASA includes systems engineering functions regardless ofmanagement instructions (NMIs) are referenced when whether they are performed by an in-house systemsapplicable. engineering organization, a program/project office, or a system contractor. This handbooks secondary objective is toserve as a useful companion to all of the various While many of the producing systemscourses in systems engineering that are being offered design features may be implied by the nature of theunder NASAs auspices. tools and techniques of systems engineering, it does not follow that institutional procedures for their application must be uniform from one NASA field1.2 Scope and Depth center to another. Selected Systems Engineering Reading See the Bibliography for full reference data and further reading suggestions. Fundamentals of Systems Engineering Systems Engineering and Analysis (2nd ed.), B.S. Blanchard and W.J. Fabrycky Systems Engineering, Andrew P. Sage An Introduction to Systems Engineering, J.E. Armstrong and Andrew P. Sage Management Issues in Systems Engineering Systems Engineering, EIA/IS-632 IEEE Trial-Use Standard for application and Management of the Systems Engineering Process, IEEE Std 1220- 1994 Systems Engineering Management Guide, Defense Systems Management College System Engineering Management, B.S. Blanchard Systems Engineering Methods, Harold Chestnut Systems Concepts, Ralph Miles, Jr. (editor) Successful Systems Engineering for Engineers and Managers, Norman B. Reilly Systems Analysis and Modeling Systems Engineering Tools, Harold Chestnut Systems Analysis for Engineers and Managers, R. de Neufville and J.H. Stafford Cost Considerations in Systems Analysis, Gene H. Fisher Space Systems Design and Operations Space Vehicle Design, Michael D. Griffin and James R. French Space Mission Analysis and Design (2nd ed.), Wiley J. Larson and James R. Wertz (editors) D i fG h S ft B ij N A l
NASA Systems Engineering Handbook Page 22 Fundamentals of Systems Engineering The NASA management instruction for the acquisition of “major" systems (NMI 7120.4) defines a2.1 Systems, Supersystems, and program as “a related series of undertakings that continue over a period of time (normally years), whichSubsystems are designed to pursue, or are in support of, a focused scientific or technical goal, and which areA system is a set of interrelated components which characterized by: design, development, andinteract with one another in an organized fashion operations of systems." Programs are managed bytoward a common purpose. The components of a NASA Headquarters, and may encompass severalsystem may be quite diverse, consisting of persons, projects.organizations, procedures, software, equipment, end In the NASA context, a project encompassesor facilities. The purpose of a system may be as the design, development, and operation of one orhumble as distributing electrical power within a more sys-tems, and is generally managed by a NASAspacecraft or as grand as exploring the surface of field center.Mars. Headquarters management concerns include not only the engineering of the systems, but Every system exists in the context of a all of the other activities required to achieve thebroader supersystem, i.e., a collection of related desired end. These other activities include explainingsystems. It is in that context that the system must be the value of programs and projects to Congress and enlisting international cooperation. The term mission A Hierarchical System Terminology is often used for a program projects purpose; its connotations of fervor make it particu-larly suitable for The following hierarchical sequence of terms for such political activities, where the emo-tional content suc-cessively finer resolution was adopted by the of the term is a desirable factor. In everyday NASA –wide Systems Engineering Working conversation, the terms "project," "mission," and Group (SEWG) and its successor, the Systems "system" are often used interchangeably; while Engineering Process Im-provement Task (SEPIT) imprecise, this rarely causes difficulty. team: System The Technical Sophistication Required to do Segment Systems Engineering Depends on the Project Element Subsystem • The systems goals may be simple and easy to Assembly identify and measure—or they may be technically Subassembly complicated, requiring a great deal of insight Part about the environment or technology within or with which the system must operate. Particular projects may need a different sequence of layers— an instrument may not need as many • The system may have a single goal—or multiple layers, while a broad initiative may need to goals. There are techniques available for distinguish more layers. Projects should establish determining the relative values of multiple goalsjudged. Thus, managers in the supersystem set — but sometimes goals are truly incommensuratesystem policies, establish system objectives, and unquantifiable.determine system constraints, and define what costsare relevant. They often have oversight authority over • The system may have users representingsystem design and operations decisions. factions with conflicting objectives. When there are conflicting objectives, negotiated Most NASA systems are sufficiently complex compromises will be required.that their components are subsystems, which mustfunction in a coordinated way for the system to • Alternative system design concepts may beaccomplish its goals. From the point of view of abundant—or they may require creative genius tosystems engineering, each subsystem is a system in develop.its own right—that is, policies, requirements,objectives, and which costs are relevant are • A "back-of-the-envelope" computation may beestablished at the next level up in the hierarchy. satisfactory for prediction of how well theSpacecraft systems often have such subsystems as alternative design concepts would do inpropulsion, attitude control telecommunications, and achievement of the goals—or credibility maypower. In a large project, the subsystems are likely to depend upon construction and testing of hardwarebe called "systems". The word system is also used or software models.within NASA generically, as defined in the firstparagraph above. In this handbook, system" isgenerally used in its generic form.
NASA Systems Engineering Handbook Page 32.2 Definition of Systems Engineering system must provide the most effectiveness for the resources expended or, equivalently, it must be theSystems engineering is a robust approach to the least expensive for the effectiveness it provides. Thisdesign, creation, and operation of systems. In simple condition is a weak one because there are usuallyterms, the approach consists of identification and many designs that meet the condition. Think of eachquantification of system goals, creation of alternative possible design as a point in the tradeoff spacesystem design concepts, performance of design Costtrades, selection and implementation of the best The cost of a system is the foregone value of the Systems Engineering per ElA/IS-632 re-sources needed to design, build, and operate it. Be-cause resources come in many forms— work Systems engineering is "an interdisciplinary approach encompassing the entire technical effort to evolve and per-formed by NASA personnel and contractors, verify an integrated and life-cycle balanced set of sys- materials, energy, and the use of facilities and tem people, product, and process solutions that satisfy equipment such as wind tunnels, factories, offices, customer needs. Systems engineering encompasses (a) and computers—it is of en convenient to express the technical efforts related to the development, these values in common terms by using monetary manufacturing, verification, deployment, operations, units (such as dollars). support) disposal of, and user training for, system prod- ucts and processes; (b) the definition and management Effectiveness of the system configuration; (c) the translation of the system definition into work breakdown structures; and The effectiveness of a system is a quantitative (d) development of information for management deci- sion making." measure of the degree to which the systems purpose is achieved. Effectiveness measures are usually very dependent upon systemdesign, verification that the design is properly built performance. For example, launch vehicleand integrated, and post-implementation assessment effectiveness depends on the probability ofof how well the system meets (or met) the goals. The successfully injecting a payload onto a usableapproach is usually applied repeatedly and trajectory. The associated system performancerecursively, with several increases in the resolution of attributes include the mass that can be put into athe system baselines (which contain requirements, specified nominal orbit, the trade between injecteddesign details, verification procedures and standards, mass and launch velocity, and launch availability.cost and performance estimates, and so on). Cost-Effectiveness Systems engineering is performed in concertwith system management. A major part of the system The cost-effectiveness of a system combines bothengineers role is to provide information that the the cost and the effectiveness of the system in thesystem manager can use to make the right decisions. context of its objectives. While it may beThis includes identification of alternative design necessary to measure either or both of those inconcepts and characterization of those concepts inways that will help the system managers first discover between effectiveness and cost. A graph plotting thetheir preferences, then be able to apply them astutely. maximum achievable effectiveness of designsAn important aspect of this role is the creation of available with current technology as a function of costsystem models that facilitate assessment of the would in general yield a curved line such as the onealternatives in various dimensions such as cost, shown in Figure 1. (In the figure, all the dimensions ofperformance, and risk. effectiveness are represented by the ordinate and all the dimensions of cost by the abscissa.) In other Application of this approach includes words, the curved line represents the envelope of theperformance of some delegated management duties, currently available technology in terms of cost -such as maintaining control of the developing effectiveness.configuration and overseeing the integration of Points above the line cannot be achievedsubsystems. with currently available technology e that is, they do not represent feasible designs. (Some of those points2.3 Objective of Systems Engineering may be feasible in the future when further technological advances have been made.) Points inside the envelope are feasible, but are dominated The objective of systems engineering is to by designs whose combined cost and effectivenesssee to it that the system is designed, built, and lie on the envelope. Designs represented by points onoperated so that it accomplishes its purpose in the the envelope are called cost-effective (or efficient ormost cost-effective way possible, considering non-dominated) solutions.performance, cost, schedule, and risk. Design trade studies, an important part of the systems engineering process, often attempt toA cost-effective system must provide a particular kind find designs that provide a better combination of theof balance between effectiveness and cost: the
NASA Systems Engineering Handbook Page 4various dimensions of cost and effectiveness. When likely point, as is shown for design concept A in thethe starting point for a design trade study is inside the figure. Distributions resulting from designs which haveenvelope, there are alternatives that reduce costs little uncertainty are dense and highly compact, as iswithout decreasing any aspect of effectiveness. or shown for concept B. Distributions associated withincrease some aspect of effectiveness with risky designs may have significant probabilities of producing highly undesirable outcomes, as is suggested by the presence of an additional low effectiveness/high cost cloud for concept C. (Of course, the envelope of such clouds cannot be a sharp line such as is shown in the figures, but must itself be rather fuzzy. The line can now be thought of as representing the envelope at some fixed confidence level -- that is, a probability of x of achieving that effectiveness.) Both effectiveness and cost may require several descriptors. Even the Echo balloons obtained scientific data on the electromagnetic environment and atmospheric drag, in addition to their primary mission as communications satellites. Furthermore, Echo was the first satellite visible to the naked eye, an unquantified -- but not unrecognized —aspect of itsFigure 1 -- The Enveloping Surface of Non-dominated effectiveness. Costs, the expenditure of limitedDesigns. resources, may be measured in the several dimensions of funding, personnel, use of facilities,out decreasing others and without increasing costs. and so on. Schedule may appear as an attribute ofThen, the system managers or system engineers effectiveness or cost, or as a constraint. Sputnik, fordecision is easy. Other than in the sizing of example, drew much of its effectiveness from the factsubsystems, such "win-win" design trades are that it was a "first"; a mission to Mars that misses itsuncommon, but by no means rare. When the launch window has to wait about two years foralternatives in a design trade study, however, require another opportunity—a clear schedule constraint.trading cost for effectiveness, or even one dimension Risk results from uncertainties in realizedof effectiveness for another at the same cost, the effectiveness, costs, timeliness, and budgets.decisions become harder. Sometimes, the systems that provide the highest ratio of effectiveness to cost are the most desirable. However, this ratio is likely to be meaningless or—worse—misleading. To be useful and meaningful, that ratio must be uniquely determined and independent of the system cost. Further, there must be but a single measure of effectiveness and a single measure of cost. If the numerical values of those metrics are obscured by probability distributions, the ratios become uncertain as well; then any usefulness the simple, single ratio of two numbers might have had disappears. In some contexts, it is appropriate to seek the most effectiveness possible within a fixed budget; in other contexts, it is more appropriate to seek the least cost possible with specified effectiveness. In these cases, there is the question of what level ofFigure 2--Estimates of Outcomes to be Obtained from effectiveness to specify or of what level of costs to fix.Several Design Concepts Including Uncertainty. In practice, these may be mandated in the form of performance or cost requirements; it then becomes The process of finding the most cost- appropriate to ask whether a slight relaxation ofeffective design is further complicated by uncertainty, requirements could produce a significantly cheaperwhich is shown in Figure 2 as a modification of Figure sys-tem or whether a few more resources could1. Exactly what outcomes will be realized by a produce a significantly more effective system.particular system design cannot be known in advance Usually, the system manager must choosewith certainty, so the projected cost and effectiveness among designs that differ in terms of numerousof a design are better described by a probability attributes. A variety of methods have been developeddistribution than by a point. This distribution can be that can be used to help managers uncover theirthought of as a cloud which is thickest at the most preferences between attributes and to quantify theirlikely value and thinner farther away from the most
NASA Systems Engineering Handbook Page 5 The System Engineers Dilemma analytic methods. These specialty engineering areas typically include reliability, maintainability, logistics, At each cost-effective solution: test, production, transportation, human factors, quality • To reduce cost at constant risk, performance assurance, and safety engineering. Specialty must be reduced. engineers contribute throughout the systems • To reduce risk at constant cost, performance engineering process; part of the system engineers job must be reduced. is to see that these functions are coherently • To reduce cost at constant performance, higher integrated into the project at the right times and that risks must be accepted. they address the relevant issues. One of the objectives for Chapter 6 is to develop an • To reduce risk at constant performance, higher understanding of how these specialty engineers costs must be accepted. contribute to the objective of systems engineering. In both systems analysis and systems In this context, time in the schedule is often a engineering, the amounts and kinds of resources to critical resource, so that schedule behaves like a be made available for the creation of the system are kind assumed to be among the decisions to be made. f tsubjective assessments of relative value. When this Systems engineering concentrates on the creation ofcan be done, trades between attributes can be hardware and software architectures and on theassessed quantitatively. Often, however, the development and management of the interfacesattributes seem to be truly incommensurate; between subsystems, while relying on systemsmanagers must make their decisions in spite of this analysis to construct the mathematical models andmultiplicity. analyze the data to evaluate alternative designs and to perform the actual design trade studies. Systems2.4 Disciplines Related to Systems analysis often requires the use of tools fromEngineering operations research, economics, or other decision sciences, and systems analysis curricula generally The definition of systems engineering given include extensive study of such topics as probability,in Section 2.2 could apply to the design task facing a statistics, decision theory, queueing theory, gamebridge designer, a radio engineer, or even a theory, linear and non-linear programming, and so on.committee chair. The systems engineering process In practice, many system engineers academiccan be a part of all of these. It cannot be the whole of background is richer in the engineering disciplinesthe job—the bridge designer must know the than in the decision sciences. As a consequence, theproperties of concrete and steel, the radio engineer system engineer is often a consumer of systemsmust apply Maxwells equations, and a committee analysis products, rather than a producer of them.chair must understand the personalities of the One of the major objectives for Chapter 5 is tomembers of the committee. In fact, the optimization of develop an understanding and appreciation of thesystems requires collaboration with experts in a state of that art.variety of disciplines, some of which are compared to Operations research and operationssystems engineering in the remainder of this section. engineering confine their attention to systems whose The role of systems engineering differs from components are assumed to be more or lessthat of system management in that engineering is an immutable. That is, it is assumed that the resourcesanalytical, advisory and planning function, while with which the system operates cannot be changed,management is the decision-making function. Very but that the way in which they are used is amenableoften, the distinction is irrelevant, as the same to optimization. Operations research techniques oftenindividuals may perform both roles. When no factors provide powerful tools for the optimization of systementer the decision-making process other than those designs.that are covered by the analyses, system Within NASA, terms such as missionmanagement may delegate some of the management analysis and engineering are often used to describeresponsibility to the systems engineering function. all study and design efforts that relate to Systems engineering differs from what might determination of what the projects mission should bebe called design engineering in that systems and how it should be carried out. Sometimes theengineering deals with the relationships of the thing scope is limited to the study of future projects.being designed to its supersystem (environment) and Sometimes the charters of organizations with suchsubsystems, rather than with the internal details of names include monitoring the capabilities of systems,how it is to accomplish its objectives. The systems ensuring that important considerations have not beenviewpoint is broad, rather than deep: it encompasses overlooked, and overseeing trades between majorthe system functionally from end to end and systems— thereby encompassing operationstemporally from conception to disposal. research, systems analysis, and systems engineering System engineers must also rely on activities.contributions from the specialty engineering Total quality management (TQM) is thedisciplines, in addition to the traditional design application of systems engineering to the workdisciplines, for functional expertise and specialized environment. That is, part of the total quality
NASA Systems Engineering Handbook Page 6management paradigm is the realization that anoperating organization is a particular kind of systemand should be engineered as one. A variety ofspecialized tools have been developed for thisapplication area; many of them can be recognized asestablished systems engineering tools, but withdifferent names. The injunction to focus on thesatisfaction of customer needs, for example, is evenexpressed in similar terms. The use of statisticalprocess control is akin to the use of technicalperformance and earned value measurements.Another method, qualify function deployment (QFD),is a technique of requirements analysis often used insystems engineering. The systems approach is common to all ofthese related fields. Essential to the systemsapproach is the recognition that a system exists, thatit is embedded in a supersystem on which it has animpact, that it may contain subsystems, and that thesystems objectives must be understood preferablyexplicitly identified.2.5 The Doctrine of Successive Refinement The realization of a system over its life cycle integration of lower-level elements is a part of theresults from a succession of decisions among systems engineering process. In fact, there is alwaysalternative courses of action. If the alternatives are a danger that the top-down process cannot keep upprecisely enough defined and thoroughly enough with the bottom-up process.understood to be well differentiated in the cost- There is often an early need to resolve theeffectiveness space, then the system manager can issues (such as the system architecture) enough somake choices among them with confidence. that the system can be modeled with sufficient realism The systems engineering process can be to do reliable trade studies.thought of as the pursuit of definition and When resources are expended toward theunderstanding of design alternatives to support those implementation of one of several design options, thedecisions, coupled with the overseeing of their resources required to complete the implementation ofimplementation. To obtain assessments that are crisp that design decrease (of course), while there isenough to facilitate good decisions, it is often usually little or no change in the resources that wouldnecessary to delve more deeply into the space of be required by unselected alternatives. Selectedpossible designs than has yet been done, as is alternatives thereby become even more attractiveillustrated in Figure 3. than those that were not selected. It should be realized, however, that this Consequently, it is reasonable to expect thespiral represents neither the project life cycle, which system to be defined with increasingly betterencompasses the system from inception through resolution as time passes. This tendency is formalizeddisposal, nor the product development process by at some point (in Phase B) by defining a baselinewhich the system design is developed and system definition. Usually, the goals, objectives, andimplemented, which occurs in Phases C and D (see constraints are baselined as the requirements portionChapter 3) of the project life cycle. Rather, as the of the baseline. The entire baseline is then subjectedintellectual process of systems engineering, it is to configuration control in an attempt to ensure thatinevitably reflected in both of them. successive changes are indeed improvements. As the system is realized, its particulars become clearer—but also harder to change. As statedFigure 3—The Doctrine of Successive Refinement above, the purpose of systems engineering is to make sure that the development process happens in a way that leads to the most cost-effective final system. The Figure 3 is really a double helix—each basic idea is that before those decisions that are hardcreate concepts step at the level of design to undo are made, the alternatives should be carefullyengineering initiates a ca-pabilities definition spiral assessed.moving in the opposite direction. The concepts can The systems engineering process is appliednever be created from whole cloth. Rather, they result again and again as the system is developed. As thefrom the synthesis of potential capabilities offered by system is realized, the issues addressed evolve andthe continually changing state of technology. This the particulars of the activity change.process of design concept development by the
NASA Systems Engineering Handbook Page 7 As an Example of the Process of Successive but its first cause. It could be argued that recognition Refinement, Consider the Choice of Altitude for a of the need or opportunity for a new system is an Space Station such as Alpha entrepreneurial activity, rather than an engineering one.• The first issue is selection of the general The end result of this step is the discoverylocation. Alternatives include Earth orbit, one of and delineation of the systems goals, which generallythe Earth-Moon Lagrange points, or a solar orbit. express the desires and requirements of the eventualAt the current state of technology, cost and risk users of the system. In the NASA context, theconsiderations made selection of Earth orbit an systems goals should also represent the long termeasy choice for Alpha. • Having chosen Earth interests of the taxpaying public.orbit, it is necessary to select an orbit region.Alternatives include low Earth orbit (LEO), high Identify and Quantify Goals. Before it is possible toEarth orbit and geosynchronous orbit; orbital compare the cost-effectiveness of alternative systeminclination and eccentricity must also be chosen. design concepts, the mission to be performed by theOne of many criteria considered in choosing LEO system must be delineated. The goals that arefor Alpha was the design complexity associated developed should cover all relevant aspects ofwith passage through the Van Allen radiation effectiveness, cost, schedule, and risk, and should bebelts. traceable to the goals of the supersystem. To make it• System design choices proceed to the selection easier to choose among alternatives, the goals shouldof an altitude maintenance strategy—rules that be stated in quantifiable, verifiable terms, insofar asimplicitly determine when, where, and why to re- that is possible and meaningful to do.boost, such as "maintain altitude such that there It is also desirable to assess the constraintsare always at least TBD days to reentry," "collision that may apply. Some constraints are imposed by theavoidance maneuvers shall always increase the state of technology at the time of creating oraltitude," "reboost only after resupply flights that modifying system design concepts. Others mayhave brought fuel," "rotate the crew every TBD appear to be inviolate, but can be changed by higherdays." levels of management. The assumptions and other• A next step is to write altitude specifications. relevant information that underlie constraints shouldThese choices might consist of replacing the always be recorded so that it is possible to estimateTBDs (values to be determined) in the altitude the benefits that could be obtained from theirstrategy with explicit numbers. relaxation.• Monthly operations plans are eventually part of At each turn of the spiral, higher-level goalsthe complete system design. These would include are analyzed. The analysis should identify thescheduled reboost burns based on predictions of subordinate enabling goals in a way that makes themthe accumulated effect of drag and the details of traceable to the next higher level. As the systemson-board microgravity experiments. engineering process continues, these are documented as functional requirements (what must• Actual firing decisions are based on determinations of be done to achieve the next-higher-level goals) andthe orbit which results from the momentum actuallyadded by previous firings, the atmospheric density as performance requirements (quantitativevariations actually encountered, and so on. descriptions of how well the functional requirements must be done). A clear operations concept often helps Note that decisions at every step require that to focus the require-ments analysis so that boththe capabilities offered by available technology be functional and performance requirements areconsidered—often at levels of design that are more ultimately related to the original need or opportunity.detailed than seems necessary at first In later turns of the spiral, further elaborations may become documented as detailed functional and Most of the major system decisions (goals, performance specifications.architecture, acceptable life-cycle cost, etc.) are madeduring the early phases of the project, so the turns of Create Alternative Design Concepts. Once it isthe spiral (that is, the successive refinements) do not under-stood what the system is to accomplish, it iscorrespond precisely to the phases of the system life possible to devise a variety of ways that those goalscycle. Much of the system architecture can be seen" can be met. Sometimes, that comes about as aeven at the outset, so the turns of the spiral do not consequence of considering alternative functionalcorrespond exactly to development of the allocations and integrating available subsystemarchitectural hierarchy, either. Rather, they design options. Ideally, as wide a range of plausiblecorrespond to the successively greater resolution by alternatives as is consistent with the designwhich the system is defined. organizations charter should be defined, keeping in Each of the steps in the systems engineering mind the current stage in the process of successiveprocess is discussed below. refinement. When the bottom-up process is operating, a problem for the system engineer is that theRecognize Need/Opportunity. This step is shown in designers tend to become fond of the designs theyFigure 3 only once, as it is not really part of the spiral create, so they lose their objectivity; the system
NASA Systems Engineering Handbook Page 8engineer often must stay an "outsider" so that there is associated with the continually improving resolutionmore objectivity. reduces the spread between upper and lower bounds On the first turn of the spiral in Figure 3, the as the process proceeds.sub-ject is often general approaches or strategies,sometimes architectural concepts. On the next, it is Select Concept. Selection among the alternativelikely to be functional design, then detailed design, design concepts is a task for the system manager,and so on. who must take into account the subjective factors that The reason for avoiding a premature focus the system engineer was unable to quantify, inon a single design is to permit discovery of the truly addition to the estimates of how well the alternativesbest design. Part of the system engineers job is to meet the quantified goals (and any effectiveness,ensure that the design concepts to be compared take cost, schedule, risk, or other constraints).into account all interface requirements. "Did you When it is possible, it is usually well worthinclude the cabling?" is a characteristic question. the trouble to develop a mathematical expression,When possible, each design concept should be called an objective function, that expresses the valuesdescribed in terms of controllable design parameters of combinations of possible outcomes as a singleso that each represents as wide a class of designs as measure of cost-effectiveness, as is illustrated inis reasonable. In doing so, the system engineer Figure 4, even if both cost and effectiveness must beshould keep in mind that the potentials for change described by more than one measure. Whenmay include organizational structure, schedules, achievement of the goals can be quantitativelyprocedures, and any of the other things that make up expressed by such an objective function, designs cana system. When possible, constraints should also be be compared in terms of their value. Risks associateddescribed by parameters. with design concepts can cause these evaluations to Owen Morris, former Manager of the Apollo be somewhat nebulous (because they are uncertainSpacecraft Program and Manager of Space Shuttle and are best described by probability distributions). InSystems and Engineering, has pointed out that it is this illustration, the risks are relatively high for designoften useful to define design reference missions concept A. There is little risk in either effectiveness orwhich stress all of the systems capabilities to a cost for concept B. while the risk of an expensivesignificant extent and which al1 designs will have to failure is high for concept C, as is shown bybe able to accomplish. The purpose of such missionsis to keep the design space open. Consequently, itcan be very dangerous to write them into the systemspecifications, as they can have just the oppositeeffect.Do Trade Studies. Trade studies begin with anassess-ment of how well each of the designalternatives meets the system goals (effectiveness,cost, schedule, and risk, both quantified andotherwise). The ability to perform these studies isenhanced by the development of system models thatrelate the design parameters to those assessments—but it does not depend upon them.Controlled modification and development of designconcepts, together with such system models, oftenpermits the use of formal optimization techniques tofind regions of the design space that warrant furtherinvestigation— those that are closer to the optimum Figure 4—A Quantitative Objective Function, De"surface indicated in Figure 1. pendent on Life-Cycle Cost and All Aspects of Whether system models are used or not, the Effec-tiveness.design concepts are developed, modified,reassessed, and compared against competing the cloud of probability near the x axis with a high costalternatives in a closed-loop process that seeks the and essentially no effectiveness. Schedule factorsbest choices for further development. System and may affect the effectiveness values, the cost values,subsystem sizes are often determined during the and the risk distributions.trade studies. The end result is the determination of The mission success criteria for systemsbounds on the relative cost-effectivenesses of the differ significantly. In some cases, effectiveness goalsdesign alternatives, measured in terms of the may be much more important than all others. Otherquantified system goals. (Only bounds, rather than projects may demand low costs, have an immutablefinal values, are possible because determination of schedule, or require minimization of some kinds ofthe final details of the design is intentionally deferred. risks. Rarely (if ever) is it possible to produce aThe bounds, in turn, may be derived from the combined quantitative measure that relates all of theprobability density functions.) Increasing detail important factors, even if it is expressed as a vector
NASA Systems Engineering Handbook Page 9with several components. Even when that can be often desirable. The accounting system should followdone, it is essential that the underlying factors and (not lead) the system architecture. In terms ofrelationships be thoroughly revealed to and breadth, partitioning should be done essentially all atunderstood by the system manager. The system once. As with system design choices, alternative partimanager must weigh the importance of the -tioning plans should be considered and comparedunquantifiable factors along with the quantitative data before implementation.provided by the system engineer. If a requirements-driven design paradigm is used for Technical reviews of the data and analyses tile development of the system architecture, it must beare an important part of the decision support applied with care, for the use of "shells" creates apackages prepared for the system manager. The tendency for the requirements to be treated asdecisions that are made are generally entered into the inviolable con straints rather than as agents of theconfiguration management system as changes to (or objectives. A goal, ob -jective or desire should neverelaborations of) the system baseline. The supporting be made a requirement until its costs. are understoodtrade studies are archived for future use. An essential and the buyer is willing to pay for it. The capability tofeature of the systems engineering process is that compute the effects of lower -level decisions on thetrade studies are performed before decisions are quantified goals should be maintained throughout themade. They can then be baselined with much more partitioning process. That is, there should be a goalsconfidence. flowdown embedded in the requirements allocation At this point in the systems engineering process.process, there is a logical branch point. For those The process continues with creation of aissues for which the process of successive refinement variety of alternative design concepts at the next levelhas proceeded far of resolution, construction of models that permit prediction of how well those alternatives will satisfy Simple Interfaces are Preferred the quantified goals, and so on. It is imperative that According to Morris, NASAs former Acting plans for subsequent integration be laid throughout Administrator George Low, in a 1971 paper titled the partitioning. Integration plans include verification "What Made Apollo a Success," noted that only and validation activities as a matter of course. 100 wires were needed to link the Apollo spacecraft to the Saturn launch vehicle. He Implement the Selected Design Decisions. When emphasized the point that a single person could the process of successive refinement has proceeded fully understand the interface and cope with all the far enough, the next step is to reverse the partitioningenough, the next step is to implement the decisions at process. When applied to the system architecture,that level of resolution (that is, unwind the recursive this "unwinding" of the process is called systemprocess). For those issues that are still insufficiently integration. Conceptual system integration takesresolved, the next step is to refine the development place in all phases of the project life cycle. That is,further. when a design approach has been selected, the approach is verified by "unwinding the process" to testIncrease the Resolution of the Design. One of the whether the concept at each physical level meets thefirst issues to be addressed is how the system should expectations and requirements. Physical integration isbe subdivided into subsystems. (Once that has been accomplished during Phase D. At the finer levels ofdone, the focus changes and the subsystems become resolution, pieces must be tested, assembled and/orsystems -- from the point of view of a system integrated, and tested again. The system engineersengineer. The partitioning process stops when the role includes the performance of the delegatedsubsystems are simple enough to be managed management du ties, such as configuration controlholistically.) As noted by Morris, "the divi- be and overseeing the integration, verification, andmanaged holistically.) As noted by Morris, "the validation process.division of program activities to minimize the number The purpose of verification of subsystemand complexity of interfaces has a strong influence on integration is to ensure that the subsystems conformthe overall program cost and the ability of the program to what was designed and interface with each otherto meet schedules." as expected in all re spects that are important: Charles Leising and Arnold Ruskin have mechanical connections, effects on center of mass(separately) pointed out that partitioning is more art and products of inertia, electromagnetic interference,than science, but that there are guidelines available: connector impedance and voltage, power conTo make interfaces clean and simple, similar sumption, data flow, and so on. Validation consists offunctions, designs and tech nologies should be ensuring that the interfaced subsystems achieve theirgrouped. Each portion of work should be verifiable. intended results. While validation is even morePieces should map conveniently onto the important than verification, it is usually much moreorganizational structure. Some of the functions that difficult to accomplish.are needed throughout the design (such as electricalpower) or throughout the organization (such as Perform the Mission. Eventually, the system ispurchasing) can be centralized. Standardization—of called upon to meet the need or seize the opportunitysuch things as parts lists or reporting formats—is for which it was designed and built.
NASA Systems Engineering Handbook Page 10 The system engineer continues to perform avariety of supporting functions, depending on thenature and duration of the mission. On a large projectsuch as Space Station Alpha, some of thesecontinuing functions include the validation of systemeffectiveness at the operational site, overseeing themaintenance of configuration and logisticsdocumentation, overseeing sustaining engineeringactivities, compiling development and operations"lessons reamed" documents, and, with the help ofthe specialty engineering disciplines, identifyingproduct improvement opportunities. On smallersystems, such as a Spacelab payload, only the lasttwo may be needed.
NASA Systems Engineering Handbook Page 113 The Project Life Cycle for Major in government. In general, the engineeringNASA Systems development life cycle is dependent on the technical nature of whats being developed, and the project life cycle may need to be tailored accordingly. Barry W. One of the fundamental concepts used Boehm described how several contemporary softwarewithin NASA for the management of major systems is development processes work; in some of thesethe pro-gram/ project life cycle, which consists of a processes, the development and constructioncategorization of everything that should be done to activities proceed in parallel, so that attempting toaccomplish a project into distinct phases, separated separate the associated phases on a time line isby control gates. Phase boundaries are defined so undesirable. Boehm describes a spiral, which reflectsthat they provide more-or-less natural points for the doctrine of successive refinement depicted ingo/no-go decisions. Decisions to proceed may be Figure 3, but Boehms spiral describes the softwarequalified by liens that must be removed within a product development process in particular. Hisreasonable time. A project that fails to pass a control discussion applies as well to the development ofgate and has enough resources may be allowed to hardware products as it does to software. Other“go back to the drawing board"—or it may be exam-ples of alternative processes are the rapidterminated. prototyping and rapid development approaches. All systems start with the recognition of a Selection of a product development process paradigmneed or the discovery of an opportunity and proceed must be a case-dependent decision, based on thethrough various stages of development to a final system engineers judgment and experience.disposition. While the most dramatic impacts of the Sometimes, it is appropriate to perform someanalysis and optimization activities associated with long-lead-time activities ahead of the time they wouldsystems engineering are obtained in the early stages, nominally be done. Long-lead-time activities mightdecisions that affect millions of dollars of value or cost consist of technology developments, prototypecontinue to be amenable to the systems approach construction and testing, or even fabrication of difficulteven as the end of the system lifetime approaches. components. Doing things out of their usual sequence Decomposing the project life cycle into increases risk in that those activities could wind upphases or-ganizes the entire process into more having been either unnecessary or improperlymanageable pieces. The project life cycle should specified. On the other hand, overall risk canprovide managers with incremental visibility into the sometimes be reduced by removal of such activitiesprogress being made at points in time that fit with the from the critical path.management and budgetary environments. NASA Figure 5 (foldout, next page) details thedocuments governing the acquisition of major resulting management and major systemssystems (NMI 7120.4 and NHB 7120.5) define the engineering products and control gates thatphases of the project life cycle as: characterize the phases in NMI 7120.4 and NHB 7120.5. Sections 3.1 to 3.6 contain narrative• Pre-Phase A—Advanced Studies ("find a suitable descriptions of the purposes, major activities, project") products, and control gates of the NASA project life• Phase A—Preliminary Analysis ("make sure the cycle phases. Section 3.7 provides a more project is worthwhile") concentrated discussion of the role of systems• Phase B—Definition ("define the project and engineering in the process. Section 3.8 describes the establish a preliminary design") NASA budget cycle within which program/project• Phase C—Design ("complete the system design") managers and system engineers must operate. Phase D — Development ("build, integrate, and verify the system, and prepare for operations") 3.1 Pre-Phase A—Advanced Studies• Phase E—Operations ("operate the system and dispose of it properly"). The purpose of this activity, which is usually per- formed more or less continually by "Advanced Phase A efforts are conducted by NASA field Projects" groups, is to uncover, invent, create,cen-ters; such efforts may rely, however, on pre- concoct and/or devise a broad spectrum of ideas andPhase A in-house and contracted advanced studies. alternatives for missions from which new projectsThe majority of Phase B efforts are normally (programs) can be selected. Typically, this activityaccomplished by industry under NASA contract, but consists of loosely structured ex-aminations of newNASA field centers typically conduct parallel in-house ideas, usually without central control and mostlystudies in order to validate the contracted effort and oriented toward small studies. Its major product is aremain an informed buyer. NASA usually chooses to stream of suggested projects, based on thecontract with industry for Phases C and D, and often identification of needs and the discovery ofdoes so for Phase E. Phase C is nominally combined opportunities that are potentially consistent withwith Phase D, but when large production quantities NASAs mission. capabilities, priorities, andare planned, these are treated separately. resources. Alternatives to the project phases describedabove can easily be found in industry and elsewhere
NASA Systems Engineering Handbook Page 12 Pre-Phase A—Advanced Studies system before seeking significant funding. According to NHB 7120.5, the major products of this phase are a Purpose: To produce a broad spectrum of ideas formal Mission Needs Statement (MNS) and one or and alternatives for missions from which new pro- more credible, feasible designs and operations grams/ projects can be selected. concepts. John Hodge describes this phase as "a Major Activities and their Products: Identify structured version of the previous phase." missions consistent with charter Identify and Phase A—Preliminary Analysis involve users Perform preliminary evaluations of possible Purpose: To determine the feasibility and missions Prepare program/project proposals, desirability of a suggested new major system and which include: its compatibility with NASAs strategic plans. • Mission justification and objectives Major Activities and their Products: • Possible operations concepts Prepare Mission Needs Statement • Possible system architectures Develop top-level requirements • Cost, schedule, and risk estimates. Develop corresponding evaluation criteria/metrics Develop master plans for existing program areas Identify alternative operations and logistics Information Baselined: concepts (nothing) Identify project constraints and system boundaries Control Gates: Consider alternative design concepts, including: Mission Concept Review feasibility and risk studies, cost and schedule Informal proposal reviews estimates, and advanced technology requirements In the NASA environment, demands for new Demonstrate that credible, feasible design(s) existsystems derive from several sources. A major one is Acquire systems engineering tools and modelsthe opportunity to solve terrestrial problems that may Initiate environmental impact studiesbe ad-dressed by putting instruments and other Prepare Project Definition Plan for Phase Bdevices into space. Two examples are weather Information Baselined:prediction and communications by satellite. General (nothing)improvements in technology for use in space will Control Gates:continue to open new possibilities. Such opportunities Mission Definition Revieware rapidly perceived as needs once the magnitude of Preliminary Non-Advocate Reviewtheir value is understood. Preliminary Program/Project Approval Review Technological progress makes possiblemissions that were previously impossible. Mannedtrips to the moon and the taking of high resolution In Phase A, a larger team, often associatedpictures of planets and other objects in the universe with an ad hoc program or project office, readdressesillustrate past responses to this kind of opportunity. the mission concept to ensure that the projectNew opportunities will continue to become available justification and practicality are sufficient to warrant aas our technological capabilities grow. place in NASAs budget. The teams effort focuses on Scientific progress also generates needs for analyzing mission requirements and establishing aNASA systems. As our understanding of the universe mission architecture. Activities become formal, andaround us continues to grow, we are able to ask new the emphasis shifts toward establishing optimalityand more precise questions. The ability to answer rather than feasibility. The effort addresses morethese questions often depends upon the changing depth and considers many alternatives. Goals andstate of technology. objectives are solidified, and the project develops Advanced studies may extend for several more definition in the system requirements, top-levelyears, and may be a sequence of papers that are only system architecture, and operations concept.loosely connected. These studies typically focus on Conceptual designs are developed and exhibit moreestablishing mission goals and formulating top-level engineering detail than in advanced studies.system requirements and operations concepts. Technical risks are identified in more detail andConceptual designs are often offered to demonstrate technology development needs become focused.feasibility and support programmatic estimates. The The Mission Needs Statement is not shownemphasis is on establishing feasibility and desirability in the sidebar as being baselined, as it is not underrather than optimality. Analyses and designs are configuration control by the project. It may be underaccordingly limited in both depth and number of configuration control at the program level, as may theoptions. program requirements documents and the Preliminary Program Plan.3.2 Phase A—Preliminary AnalysisThe purpose of this phase is to further examine thefeasibility and desirability of a suggested new major