|
|
| Line 1: |
Line 1: |
| − | This article highlights some of the differences between the so-called classical, traditional, or conventional [[Systems Engineering|systems engineering]] (SE) approaches and the newer, and, as yet, less defined principles of [[System of Systems (SoS) (glossary)|system of systems]] (SoS) engineering (SoSE). [[Enterprise Systems Engineering|enterprise systems engineering]] (ESE), and/or [[Complex (glossary)|complex]] systems engineering (CSE) or [[Complex Adaptive System (CAS) (glossary)|complex adaptive systems]] engineering (Gorod et al. 2015). The topic is still somewhat controversial, especially considering those that are sceptical that broader views of SE might work better when one is immersed in trying to cope with our most difficult problems. Indeed, the lack of a unified theory of SE is one of the prime motivations for producing and analysing case studies to develop more knowledge of what seems to work, what does not seem to work, and reasons why, really challenging SE environments.
| + | ---- |
| − | | + | '''''Lead Authors:''''' ''Kevin Forsberg, Richard Turner'', '''''Contributing Author:''''' ''Rick Adcock'' |
| − | For addition information, refer to Systems Engineering: [[Systems Engineering: Historic and Future Challenges|Historic and Future Challenges]], Systems Engineering and [[Systems Engineering and Other Disciplines|Other Disciplines]], [[Enterprise Systems Engineering]], and [[Systems of Systems (SoS)|System of Systems Engineering.]]
| + | ---- |
| − | | + | As discussed in the generic life cycle paradigm in [[Introduction to Life Cycle Processes]], each {{Term|System-of-Interest (glossary)}} (SoI) has an associated {{Term|Life Cycle Model (glossary)}}. The generic life cycle model below applies to a single SoI. SE must generally be synchronized across a number of tailored instances of such life cycle models to fully satisfy stakeholder needs. More complex life cycle models which address this are described in [[Life Cycle Models]]. |
| − | Rather than modifying the previous discussion of the [[Global Positioning System Case Study]] in SEBoK, the focus is on comparing and contrasting the older and newer forms of SE by commenting on quotations from the original case study source documents (O’Brien and Griffin 2007).
| |
| − | | |
| − | == Preface ==
| |
| − | The original case study begins by describing systems engineering (SE) principles. For example,
| |
| − | | |
| − | <blockquote>System requirements are critical to all facets of successful system program development. First, system development must proceed from a well-developed set of [[Requirement (glossary)|requirements]]. Second, regardless of the evolutionary acquisition approach, the system requirements must flow down to all subsystems and lower-level components. And third, the system requirements must be stable, balanced, and must properly reflect all activities in all intended environments. However, system requirements are not unchangeable. As the system [[Design (glossary)|design]] proceeds, if a requirement or set of requirements is proving excessively expensive to satisfy, the process must rebalance schedule, [[Cost (glossary)|costs]], and performance by changing or modifying the requirements or set of requirements. (O’Brien and Griffin 2007, p. 9)</blockquote>
| |
| − | | |
| − | The Global Positioning System (GPS), including its multi-various applications, was developed over many years as the result of the efforts of a host of contributors. It is very difficult to believe that the classical, traditional or conventional systems engineering approach described in the above paragraph (especially those phrases highlighted in bold by the present authors) was truly responsible for this remarkable achievement that so profoundly impacts our lives. Rather, some more advanced form of systems engineering (SE), that might be called, system of systems (SoS) engineering (SoSE), enterprise systems engineering (ESE), or complex (adaptive) systems engineering (CSE), or a blend and/or combination of these approaches or methodologies, had to be responsible. This premise is supported explicitly and repeatedly in the following case study revision using bold font.
| |
| − | | |
| − | Continuing, the following quoted paragraphs seem flawed in several places highlighted in bold. The bold phrases might be replaced by the phrases in brackets […]. Such brackets might also include other editorial comments of the present authors.<blockquote>Systems engineering includes making key system and design trades early in the process to establish the [[System (glossary)|system]] [[Architecture (glossary)|architecture]]. These architectural artifacts This [[Architecture (glossary)|architecture]] can depict any new system, legacy system, modifications thereto, introduction of new technologies, and overall system-level behavior and performance. Modeling and [[Simulation (glossary)|simulation]] are generally employed to organize and assess architectural system alternatives at this stage. System and subsystem design follows the functional [system] architecture [as defined from a functional point of view]. System architectures [[Design (glossary)|designs]] are modified if elements are too risky, expensive, or time-consuming. (O’Brien and Griffin 2007, p. 9)</blockquote>
| |
| − | | |
| − | A good architecture, once established, should guide [[Systems Development (glossary)|systems development]], and not change very much, if at all, at least compared to possible changes in the system design, which, of course, can evolve as one learns more about the problem and potential solutions that may increase the system’s capability. Thus, it is crucial to not confuse architecture with designs instantiating the architecture, contrary to what seems to be the case in (Ricci, et al. 2013).
| |
| − | | |
| − | <blockquote>Important to the efficient decomposition and creation of functional and physical architectural designs are the management of interfaces and the [[Integration (glossary)|integration]] of subsystems. [[Interface (glossary)|interface]] management and integration is applied to subsystems within a system or across a large, complex system of systems. Once a solution is planned, analyzed, designed, and constructed, validation and verification take place to ensure satisfaction of requirements. Definition of test criteria, measures of effectiveness (MOEs), and measures of performance (MOPs) are established as part of the requirements process, taking place well before any component/subsystem assembly design and construction occurs. (O’Brien and Griffin 2007, p. 10)</blockquote>
| |
| − | | |
| − | In the quoted paragraph just above bold phrases note the emphasis on a reductionist approach, [[Reductionism (glossary)|reductionism]], where great attention is paid to the subsystems and managing the interfaces among them. This is the antithesis of a [[Holistic (glossary)|holistic]] approach where one concentrates on the whole system, recognizing that it is difficult to identify overall system behavior as depending on any particular subsystem or set of subsystems. In a truly complex system that is continually evolving, the above-mentioned requirements process is flawed because the system is continually changing, i.e., the system is [[Evolutionary (glossary)|evolutionary]]; the requirements are either ill-defined at the outset, or are modified because [[Stakeholder (glossary)|stakeholders ]]<nowiki/>change their minds, or become somewhat irrelevant because the system environment changes.
| |
| − | | |
| − | <blockquote>There are several excellent representations of the [usual traditional or conventional] systems engineering process presented in the literature. These depictions present the current state of the art in maturity and evaluation of the systems engineering process. One can find systems engineering process definitions, guides, and handbooks from the International Council on Systems Engineering (INCOSE), European Industrial Association (EIA), Institute of Electrical and Electronics Engineers (IEEE), and various Department of Defense (DoD) agencies and organizations. They show the process as it should be applied [Really? In all situations?] by today’s experienced practitioner. One of these processes, long used by the Defense Acquisition University (DAU), is [a model] not accomplished in a single pass. This iterative and nested process gets repeated to the lowest level of definition of the design and its interfaces. (O’Brien and Griffin 2007, p. 10)</blockquote>
| |
| − | | |
| − | The above description appears to be written with pride without any acknowledgement that this SE methodology might fail to work if applied according to these guidelines, or that there might be new SE techniques that could be more effective in some situations. Again, this reflects a reductionist approach that ignores holism and emergent properties that might not be explained even when thoroughly understanding the systems components and their interactions. On the positive side, the next paragraph suggest how the world is changing and hints that something more is needed. Nevertheless, the advice seems to be oriented toward applying the existing SE discipline more vigorously instead of seeking new methods that might be more effective.
| |
| − | | |
| − | <blockquote>The DAU model, like all others, has been documented in the last two decades, and has expanded and developed to reflect a changing environment. Systems are becoming increasingly complex internally and more interconnected externally. The process used to develop aircraft and systems of the past was effective at the time. It served the needs of the practitioners and resulted in many successful systems in our inventory. Notwithstanding, the cost and schedule performance of the past programs are replete with examples of well-managed programs and ones with less-stellar execution. As the nation entered the 1980s and 1990s, large DoD and commercial acquisitions experienced overrunning costs and slipping schedules. The aerospace industry and its organizations were becoming larger and were more geographically and culturally distributed. Large aerospace companies have worked diligently to establish common systems engineering practices across their enterprises. However, because of the mega-trend of teaming in large (and some small) programs, these common practices must be understood and used beyond the enterprise and to multiple corporations. It is essential that the systems engineering process govern integration, balance, allocation, and verification, and be useful to the entire program team down to the design and interface level. (O’Brien and Griffin 2007, p. 11)</blockquote>
| |
| − |
| |
| − | Finally, in the next paragraph there is a suggestion that SE could be made more sophisticated but there is no mention of addressing people problems or advocating a broader transdisciplinary approach.
| |
| − | | |
| − | <blockquote>Today, many factors overshadow new acquisition; including system-of-systems (SoS) con-
| |
| − | text, network centric warfare and operations, and rapid growth in information technology. These factors are driving a more sophisticated systems engineering process with more complex and capable features, along with new tools and procedures. One area of increased focus of the systems engineering process is the informational systems architectural definitions used during system analysis. This process, described in DoD Architectural Framework (DoDAF), emphasizes greater reliance on reusable architectural views describing the system context and concept of operations, interoperability, information and data flows, and network service-oriented characteristics. (O’Brien and Griffin 2007, p. 11)</blockquote>
| |
| − | | |
| − | The last two sections of the systems engineering principles portion of the original case study address case studies themselves, mainly for academic purposes, to help people appreciate systems engineering principles, and the framework used in the case study, namely the rather narrowly defined Friedman-Sage framework that will be discussed briefly in Section II below.
| |
| − | | |
| − | The treatment of the reason for case studies is quite good in that it talks about the benefits of applying systems engineering principles, as highlighted from real-world examples of what works and what does not. Except near the end, where there is allusion to the possibility of new endeavor systems engineering principles, the principles espoused tend to be traditional or conventional.
| |
| − | | |
| − | On the other hand, based upon the original case study (O’Brien and Griffin 2007), if one views the boundary of the GPS system to include primarily the technology associated with the GPS space segment and its controlling ground network, then it can be assumed that system was likely implemented primarily by following traditional or conventional systems engineering processes. If one takes this viewpoint, then all of the above criticism which attempts to point out some of the shortcomings of conventional systems engineering, may seem vacuous at best, or politically incorrect at worst. It may well be that many would rather not denigrate the original GPS case study by exposing it to the possibilities of a broader system engineering approach.
| |
| − | | |
| − | Unless otherwise indicated, as the present authors have already been doing, unchanged quotations from the existing SEBoK are indented below. Modifications to such quotations are shown in brackets [...]; deletions are not necessarily shown explicitly.
| |
| − | | |
| − | == Background ==
| |
| − | <blockquote>The Global Positioning System (GPS) case study was developed by the United States Air Force Center for Systems Engineering (AF CSE) located at the Air Force Institute of Technology (AFIT). The GPS is a space-based radio-positioning system. A constellation of twenty-four satellites, including three spares, comprise the overall system which provides navigation and timing information to military and civilian users worldwide. GPS satellites, in one of six Earth orbits, circle the globe every twelve hours, emitting continuous navigation signals on two different L-band frequencies. The system consists of two other major segments: a world-wide satellite control network, and the GPS user equipment that can either be carried by a human user or integrated into host platforms such as ships, vehicles, or aircraft.</blockquote>
| |
| − | | |
| − | A user needs to receive signals from at least four GPS satellites simultaneously (satellite orbital positions and terrestrial terrain blockage can be issues that degrade performance) to determine one’s position in three dimensions; the altitude determination is typically less accurate than the other two dimensions.
| |
| − | | |
| − | <blockquote>When looking at [GPS], it would be difficult to imagine another system that relies so heavily upon such a wide range of [domains containing systems that must interact effectively to achieve successful GPS operation]. It is evident that [GPS directly relates to many domains and applications including:
| |
| − | * position location and tracking
| |
| − | * time synchronization
| |
| − | * navigation
| |
| − | * transportation
| |
| − | * times of arrival
| |
| − | * air traffic management
| |
| − | * situational awareness
| |
| − | * jam-resistant communications
| |
| − | * business and commerce
| |
| − | * farming
| |
| − | * aerospace
| |
| − | * sensing nuclear detonations from space
| |
| − | * military war-fighting
| |
| − | * targeting
| |
| − | * weapons delivery
| |
| − | * etc.].
| |
| − | [GPS is] an example of [a collaborative (Dahmann, et al. 2008) systems of systems (SoS)]. As such, no one is in charge, and the capabilities (not requirements) flow from the bottom-up, as opposed to top-down.</blockquote>
| |
| − | | |
| − | == Purpose ==
| |
| − | <blockquote>The GPS case study includes a detailed discussion of the development of the GPS and its components, as well as other applicable areas. The reader of this study will gain an increased understanding of the effect that GPS has on military and commercial industries in the context of the systems engineering support required to achieve success.</blockquote>
| |
| − | | |
| − | This may be, but the principal purpose of this revised case study is to suggest a broader view of GPS that discusses signature aspects of SoS, enterprises, and complex systems, and emphasizes SoSE, ESE, and CSE.
| |
| − | | |
| − | <blockquote>[AF CSE] was tasked to develop case studies focusing on the application of [SE] principles within various aerospace programs. The GPS case study [was developed in support of SE] graduate school instruction using the Friedman-Sage framework (Friedman and Sage 2003) (Friedman and Sage 2004).]</blockquote>
| |
| − | | |
| − | However, the Friedman-Sage framework involves only two contractual stakeholders, the Government and the contractor; further, the framework is limited to the traditional or conventional SE life cycle which mainly treats activities in a linear instead of nonlinear fashion; still further, only risks are considered, not a balance of risk and opportunity. Thus, the present authors believe a broader framework embracing SoSE, ESE, and CSE is more appropriate.
| |
| − | | |
| − | == Challenges ==
| |
| − | In the original case study the first highly technical section (Section 2) was the system description. The original idea derived from trying to determine the precise orbital parameters of the first artificial satellites such as Sputnik launched by the Soviets in 1957. Researchers at Johns Hopkins realized the inverse, that if one knew precisely the orbital parameters, the locations of ground stations receiving satellite signals could be determined quite accurately. (O’Brien and Griffin 2007, p. 20)
| |
| − | | |
| − | GPS got its start in the early 70s (O’Brien and Griffin 2007, p. 19) building upon several previous satellite navigation systems. The primary motive was very accurate position information for the purposes of military applications. For example, the U.S. Air Force wanted to deliver nuclear weapons from bombers with unprecedented accuracy and precision. (O’Brien and Griffin 2007, p. 29)
| |
| | | | |
| − | With such an intense interest from the military, the first real challenge, other than the many technical challenges of making GPS work as well as envisioned, might have been the question of how to make GPS available to the civilian community so they could share the benefits. The study claimed that the system was always offered for civilian use, albeit with some charge. After the Korean airliner went astray and got shot down by a Soviet interceptor aircraft, President Reagan made GPS officially available for civilian use free of charge. (O’Brien and Griffin 2007, p. 14)
| + | ==A Generic System Life Cycle Model== |
| | | | |
| − | The second challenge could be associated with preserving precision capabilities for the military only, and relegating course acquisition (C/A) accuracy to the civilian community. (O’Brien and Griffin 2007, p. 15) Later this dichotomy was essentially eliminated with the realization that a differential GPS configuration involving a fixed ground station with a precisely known location will yield great accuracy. (Kee, et al. 1991)
| + | There is no single “one-size-fits-all” system life cycle model that can provide specific guidance for all project situations. Figure 1, adapted from (Lawson 2010, ISO 2015, and ISO 2010), provides a generic life cycle model that forms a starting point for the most common versions of pre-specified, evolutionary, sequential, opportunistic, and concurrent life cycle processes. The model is defined as a set of stages, within which technical and management activities are performed. The stages are terminated by {{Term|Decision Gate (glossary)|decision gates}}, where the key stakeholders decide whether to proceed into the next stage, to remain in the current stage, or to terminate or re-scope related projects. |
| | | | |
| − | The GPS satellites used space-borne atomic clocks. To alleviate the need for updating these clocks too often a successful effort was initiated to revise the international time standard which ended up using relatively infrequent “leap seconds”. (O’Brien and Griffin 2007, p. 23) Even these are still annoying for many other applications, such as the continual need to achieve precise synchronization of frequency hopping radios.
| + | [[File:Fig_1_A_generic_life_cycle_KF.png|thumb|600px|center|'''Figure 1. A Generic Life Cycle Model.''' (SEBoK Original)]] |
| | | | |
| − | An organizational challenge of inter-service rivalries was overcome with the formation of the Joint Program Office (JPO). (O’Brien and Griffin 2007, p. 25)
| + | Elaborated definitions of these stages are provided in the glossary below and in various other ways in subsequent articles. |
| | | | |
| − | In the early days of satellite communication systems, for example, the satellites were quite small and low powered while the terminals were large and high-powered. By the time GPS came along, the satellites are getting bigger and more sophisticated. Then the challenge to develop relatively low-cost terminals, particularly for mobile users, greatly increased. (O’Brien and Griffin 2007, p. 29)
| + | The '''Concept Definition''' stage begins with a decision by a protagonist (individual or organization) to invest resources in a new or improved {{Term|Engineered System (glossary)|engineered system}}. Inception begins with a set of {{Term|Stakeholder (glossary)|stakeholders}} agreeing to the need for change to an [[Engineered System Context|engineered system context]] and exploring whether new or modified SoI can be developed, in which the {{Term|Life Cycle (glossary)|life cycle}} benefits are worth the investments in the {{Term|Life Cycle Cost (LCC) (glossary)|life cycle costs}}. Activities include: developing the concept of operations and business case; determining the key stakeholders and their desired capabilities; negotiating the stakeholder requirements among the key stakeholders and selecting the system’s non-developmental items (NDIs). |
| | | | |
| − | A small but interesting challenge was the definition of system of systems (SoS). It was decided that GPS was an SoS because it involved three independent systems, namely, the space vehicle (SV), the control segment (CS), and the user equipment (UE), that “merely” had to interface with each other. (O’Brien and Griffin 2007, p. 30)
| + | The '''System Definition''' stage begins when the key stakeholders decide that the business needs and stakeholder requirements are sufficiently well defined to justify committing the resources necessary to define a solution options in sufficient detail to answer the life cycle cost question identified in concept definition and provide a basis of system realization if appropriate. Activities include developing system architectures; defining and agreeing upon levels of system requirements; developing systems-level life cycle plans and performing system analysis in order to illustrate the compatibility and feasibility of the resulting system definition. The transition into the system realization stage can lead to either single-pass or multiple-pass development. |
| | | | |
| − | Continually changing requirements is usually a problem, although in this case the requirements did not change as often as they could have. (O’Brien and Griffin 2007, p. 31)
| + | It should be noted that the concept and system definition activities above describe activities performed by ''systems engineers'' when performing ''systems engineering''. There is a very strong concurrency between proposing a problem situation or opportunity and describing one or more possible system solutions, as discussed in [[Systems Approach Applied to Engineered Systems]]. Other related definition activities include: prototyping or actual development of high-risk items to show evidence of system feasibility; collaboration with business analysts or performing mission effectiveness analyses to provide a viable business case for proceeding into realization; and modifications to realized systems to improve their production, support or utilization. These activities will generally happen through the system life cycle to handle system evolution, especially under multiple-pass development. This is discussed in more detail in the [[Life Cycle Models]] knowledge area. |
| | | | |
| − | Difficulties of defining and updating the many GPS interfaces was largely overcome by the GPS program director, Col. Brad Parkinson, when he convinced his own management, Gen. Schultz at Space and Missile Systems Office (SAMSO) (which eventually became the Space Division) that GPS ought to be defined solely by the signal-structure-in-space and not the physical interfaces. (O’Brien and Griffin 2007, p. 31)
| + | The '''System Realization''' stage begins when the key stakeholders decide that the SoI architecture and feasibility evidence are sufficiently low-risk to justify committing the resources necessary to develop and sustain the initial operational capability (IOC) or the single-pass development of the full operational capability (FOC). Activities include: construction of the developmental elements; integration of these elements with each other and with the non-developmental item (NDI) elements; verification and validation of the elements and their integration as it proceeds; and preparing for the concurrent production, support, and utilization activities. |
| | | | |
| − | == Systems Engineering Practices ==
| + | The '''System Production, Support, and Utilization (PSU)''' stages begin when the key stakeholders decide that the SoI life-cycle feasibility and safety are at a sufficiently low-risk level that justifies committing the resources necessary to produce, field, support, and utilize the system over its expected lifetime. The lifetimes of production, support, and utilization are likely to be different. After market support will generally continue after production is complete and users will often continue to use unsupported systems. |
| − | <blockquote>Although the systems engineering process in Phase I has been discussed previously, this section will expand on the concepts. For example, one of the user equipment contractors was technically competent, but lacked effective management. The JPO strongly suggested that a systems engineering firm be hired to assist the contractor in managing program and they agreed. (O’Brien and Griffin 2007, p. 42)</blockquote>
| |
| | | | |
| − | There did not seem to be any mention of what SE firm was hired, if any. The Aerospace Corporation, a non-profit Federally Funded Research and Development Center (FFRDC), which had such a key role in the run-up to GPS was also prominently and centrally involved in development phase of this humungous project. (O’Brien and Griffin 2007, pp. 20, 22, 25, 33, 34, 40, 41, 44, 48, 50-52, 56, 57, 62, 63, 64, 66, 67, 71)
| + | '''System Production''' involves the fabrication of instances or versions of an SoI and of associated after-market spare parts. It also includes production quality monitoring and improvement; product or service acceptance activities; and continuous production process improvement. It may include low-rate initial production (LRIP) to mature the production process or to promote the continued preservation of the production capability for future spikes in demand. |
| | | | |
| − | == Lessons Learned ==
| + | '''Systems Support''' includes various classes of maintenance: corrective (for defects), adaptive (for interoperability with independently evolving co-dependent systems), and perfective (for enhancement of performance, usability, or other key performance parameters). It also includes hot lines and responders for user or emergency support and the provisioning of needed consumables (gas, water, power, etc.). Its boundaries include some gray areas, such as the boundary between small system enhancements and the development of larger complementary new additions, and the boundary between rework/maintenance of earlier fielded increments in incremental or evolutionary development. ''Systems Support'' usually continues after ''System Production'' is terminated. |
| − | <blockquote>Communications was a key ingredient that was fostered throughout GPS
| |
| − | development. (O’Brien and Griffin 2007, p. 71)</blockquote>
| |
| | | | |
| − | Yes, from reading the original case study there seems to have been a lot of cooperation among the various organizations, more so than might have been expected in a less compelling case.
| + | '''System Utilization''' includes the use of the SoI in its context by operators, administrators, the general public, or systems above it in the system-of-interest hierarchy. It usually continues after ''Systems Support'' is terminated. |
| | | | |
| − | <blockquote>Several precepts or foundations of the Global Positioning Satellite program are the reasons for its success. These foundations are instructional for today’s programs because they are thought-provoking to those who always seek insight into the program’s progress under scrutiny. These foundations of past programs are, of course, not a complete set of necessary and sufficient conditions. For the practitioner, the successful application of different systems engineering processes is required throughout the continuum of a program, from the concept idea to the usage and eventual disposal of the system. Experienced people applying sound systems engineering principles, practices, processes, and tools are necessary every step of the way. Mr. Conley, formerly of the GPS JPO, provided these words: “Systems engineering is hard work. It requires knowledgeable people who have a vision of the program combined with an eye for detail.” (O’Brien and Griffin 2007, p. 72)</blockquote>
| + | The '''System Retirement''' stage is often executed incrementally as system versions or elements become obsolete or are no longer economical to support and therefore undergo disposal or recycling of their content. Increasingly affordable considerations make system re-purposing an attractive alternative. |
| | | | |
| − | In very complex systems engineering efforts of this type, it is also important to explore new techniques that attempt to deal with “soft” issues involving people. Those that seem to work can be added to the systems engineering process collection.
| + | ==Applying the Life Cycle Model== |
| − |
| |
| − | <blockquote>Systems engineering played a major role in the success of this program. The challenges of integrating new technologies, identifying system requirements, incorporating a system of systems approach, interfacing with a plethora of government and industry agencies, and dealing with the lack of an operational user early in the program formation required a strong, efficient systems engineering process. The GPS program embedded systems engineering in their knowledge-base, vision, and day-to-day practice to ensure proper identification of system requirements. It also ensured the allocation of those requirements to the almost-autonomous segment developments and beyond to the subcontractor/vendor level, the assessments of new requirements, innovative test methods to verify design performance to the requirements, a solid concept of operations/mission analysis, a cost-benefit analysis to defend the need for the program, and a strong system integration process to identify and control the “hydra” of interfaces that the program encountered. The program was able to avoid major risks by their acquisition strategy, the use of trade studies, early testing of concept designs, a detailed knowledge of the subject matter, and the vision of the program on both the government and contractor side. (O’Brien and Griffin 2007, p. 72)</blockquote>
| |
| | | | |
| − | This well summarizes the successful systems engineering approach utilized in GPS. Another element of achieving overall balance is the pursuit of opportunities as the “flipside” of risk mitigation.
| + | Figure 1 shows just the single-step approach for proceeding through the stages of a SoI life cycle. In the [[Life Cycle Models]] knowledge area, we discuss examples of real-world enterprises and their drivers, both technical and organizational. These have led to a number of documented approaches for sequencing the life cycle stages to deal with some of the issues raised. The Life Cycle Models KA summarizes a number of {{Term|Incremental (glossary)|incremental}} and {{Term|Evolutionary (glossary)|evolutionary}} life cycle models, including their main strengths and weaknesses, and also discusses criteria for choosing the best-fit approach. |
| | | | |
| − | Finally, here is the list of academic questions offered in original case study.
| + | In Figure 1, we have listed key technical and management activities critical to successful completion of each stage. This is a useful way to illustrate the goals of each stage and gives an indication of how processes align with these stages. This can be important when considering how to plan for resources, milestones, etc. However, it is important to observe that the execution of process activities is not compartmentalized to particular life cycle stages (Lawson 2010). In [[Applying Life Cycle Processes]], we discuss a number of views on the nature of the inter-relationships between process activities within a life cycle model. In general, the technical and management activities are applied in accordance with the principles of {{Term|Concurrent (glossary)|concurrency}}, {{Term|Iteration (glossary)}} and {{Term|Recursion (glossary)}} described in the [[Introduction to Life Cycle Processes|generic life cycle paradigm]]. |
| | | | |
| − | <blockquote>QUESTIONS FOR THE STUDENT (O’Brien and Griffin 2007, p. 73)
| + | ==References== |
| − | The following questions are meant to challenge the reader and prepare for a case discussion.
| |
| − | * Is this program start typical of an ARPA/ DARPA funded effort? Why or why not?
| |
| − | * Have you experiences similar or wildly different aspects of a Joint Program?
| |
| − | * What were some characteristics that should be modeled from the JPO?
| |
| − | * Think about the staffing for the GPS JPO. How can this be described? Should it be duplicated in today’s programs? Can it?
| |
| − | * Was there anything extraordinary about the support for this program?
| |
| − | * What risks were present throughout the GPS program. How were these handled?
| |
| − | * Requirement management and stability is often cited as a central problem in DoD acquisition. How was this program like, or [un]like, most others?
| |
| − | * Could the commercial aspects of the User Equipment be predicted or planned? Should the COTS aspect be a strategy in other DoD programs, where appropriate? Why or why not?</blockquote>
| |
| − | | |
| − | Other questions might be: What possible influences did the demand for or offering to the public of this GPS capability entail?What differences in the development of GPS might have emerged if the public was more aware of the potential applications for their benefit at the outset?
| |
| − | | |
| − | ==References== | |
| | | | |
| | ===Works Cited=== | | ===Works Cited=== |
| | + | ISO/IEC/IEEE. 2015.''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288|ISO/IEC 15288]]:2015. |
| | | | |
| − | Dahmann, J. S., George Rebovich, Jr., and Jo Ann Lane. November 2008. “Systems Engineering for Capabilities.” CrossTalk, The Journal of Defense Software Engineering. http://www.stsc.hill.af.mil/crosstalk/2008/11/index.html. Accessed 12 May 2015).
| + | ISO/IEC. 2010. Systems and Software Engineering, Part 1: Guide for Life Cycle Management. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 24748-1:2010. |
| − |
| |
| − | Friedman, G.R., and A.P. Sage. 19 January 2003. Systems Engineering Concepts: Illustration Through Case Studies. Accessed September 2011. http://www.afit.edu/cse/docs/Friedman-Sage%20Framework.pdf.
| |
| | | | |
| − | Gorod, A., B. E. White, V. Ireland, S. J. Gandhi, and B. J. Sauser. 2015. Case Studies in System of Systems, Enterprise Systems, and Complex Systems Engineering. Boca Raton, FL: CRC Press, Taylor & Francis Group. 2015. http://www.taylorandfrancis.com/books/details/9781466502390/. Accessed 8 May 2015
| + | Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' London, UK: College Publications. |
| | | | |
| − | Friedman, G.R., and A.P. Sage. 2004. “Case Studies of Systems Engineering and Management in Systems Acquisition.” Systems Engineering 7(1): 84-96.
| + | ===Primary References=== |
| | + | Forsberg, K., H. Mooz, H. Cotterman. 2005. ''[[Visualizing Project Management]]'', 3rd Ed. Hoboken, NJ: J. Wiley & Sons. |
| | | | |
| − | Kee, Changdon, Bradford W. Parkinson, Penina Axelrad. Summer 1991. “Wide Area Differential GPS.” Journal of The Institute of Navigation 38(2): 123-46.
| + | INCOSE. 2015. '[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0. |
| | | | |
| − | O’Brien, Patrick J., and John M. Griffin. 4 October 2007. Global Positioning System. Systems Engineering Case Study. Air Force Center for Systems Engineering (AFIT/SY) Air Force Institute of Technology (AFIT). 2950 Hobson Way, Wright-Patterson AFB OH 45433-7765.
| + | Lawson, H. 2010. ''[[A Journey Through the Systems Landscape]].'' London, UK: College Publications. |
| | | | |
| − | Ricci, Nicola, Adam M. Ross, Donna H. Rhodes, and Matthew E. Fitzgerald. 2013. “Considering Alternative Strategies for Value Sustainment in Systems-of-Systems.” 6th IEEE International Systems Conference (SysCon). 15-18 April. Orlando, FL.
| |
| − |
| |
| − | ===Primary References===
| |
| − |
| |
| − | Gorod, A., B. E. White, V. Ireland, S. J. Gandhi, and B. J. Sauser. 2015. [[Case Studies in System of Systems, Enterprise Systems, and Complex Systems Engineering]]. Boca Raton, FL: CRC Press, Taylor & Francis Group. 2015. http://www.taylorandfrancis.com/books/details/9781466502390/. Accessed 12 May 2015
| |
| | ===Additional References=== | | ===Additional References=== |
| − | | + | None. |
| − | None | |
| − | | |
| | ---- | | ---- |
| − | <center>[[Global Positioning System Case Study|< Previous Article]] | [[Case Studies|Parent Article]] | [[Medical Radiation Case Study|Next Article>]]</center> | + | <center>[[Introduction to Life Cycle Processes|< Previous Article]] | [[Introduction to Life Cycle Processes|Parent Article]] | [[Applying Life Cycle Processes|Next Article >]]</center> |
| | | | |
| − | {{DISQUS}}
| + | <center>'''SEBoK v. 2.1, released 31 October 2019'''</center> |
| | | | |
| − | [[Category:Part 7]] [[Category:Case Study]] | + | [[Category: Part 3]][[Category:Topic]] |
| | + | [[Category:Introduction to Life Cycle Processes]] |
Lead Authors: Kevin Forsberg, Richard Turner, Contributing Author: Rick Adcock
As discussed in the generic life cycle paradigm in Introduction to Life Cycle Processes, each system-of-interestsystem-of-interest (SoI) has an associated life cycle modellife cycle model. The generic life cycle model below applies to a single SoI. SE must generally be synchronized across a number of tailored instances of such life cycle models to fully satisfy stakeholder needs. More complex life cycle models which address this are described in Life Cycle Models.
A Generic System Life Cycle Model
There is no single “one-size-fits-all” system life cycle model that can provide specific guidance for all project situations. Figure 1, adapted from (Lawson 2010, ISO 2015, and ISO 2010), provides a generic life cycle model that forms a starting point for the most common versions of pre-specified, evolutionary, sequential, opportunistic, and concurrent life cycle processes. The model is defined as a set of stages, within which technical and management activities are performed. The stages are terminated by decision gatesdecision gates, where the key stakeholders decide whether to proceed into the next stage, to remain in the current stage, or to terminate or re-scope related projects.
Figure 1. A Generic Life Cycle Model. (SEBoK Original)
Elaborated definitions of these stages are provided in the glossary below and in various other ways in subsequent articles.
The Concept Definition stage begins with a decision by a protagonist (individual or organization) to invest resources in a new or improved engineered systemengineered system. Inception begins with a set of stakeholdersstakeholders agreeing to the need for change to an engineered system context and exploring whether new or modified SoI can be developed, in which the life cyclelife cycle benefits are worth the investments in the life cycle costslife cycle costs. Activities include: developing the concept of operations and business case; determining the key stakeholders and their desired capabilities; negotiating the stakeholder requirements among the key stakeholders and selecting the system’s non-developmental items (NDIs).
The System Definition stage begins when the key stakeholders decide that the business needs and stakeholder requirements are sufficiently well defined to justify committing the resources necessary to define a solution options in sufficient detail to answer the life cycle cost question identified in concept definition and provide a basis of system realization if appropriate. Activities include developing system architectures; defining and agreeing upon levels of system requirements; developing systems-level life cycle plans and performing system analysis in order to illustrate the compatibility and feasibility of the resulting system definition. The transition into the system realization stage can lead to either single-pass or multiple-pass development.
It should be noted that the concept and system definition activities above describe activities performed by systems engineers when performing systems engineering. There is a very strong concurrency between proposing a problem situation or opportunity and describing one or more possible system solutions, as discussed in Systems Approach Applied to Engineered Systems. Other related definition activities include: prototyping or actual development of high-risk items to show evidence of system feasibility; collaboration with business analysts or performing mission effectiveness analyses to provide a viable business case for proceeding into realization; and modifications to realized systems to improve their production, support or utilization. These activities will generally happen through the system life cycle to handle system evolution, especially under multiple-pass development. This is discussed in more detail in the Life Cycle Models knowledge area.
The System Realization stage begins when the key stakeholders decide that the SoI architecture and feasibility evidence are sufficiently low-risk to justify committing the resources necessary to develop and sustain the initial operational capability (IOC) or the single-pass development of the full operational capability (FOC). Activities include: construction of the developmental elements; integration of these elements with each other and with the non-developmental item (NDI) elements; verification and validation of the elements and their integration as it proceeds; and preparing for the concurrent production, support, and utilization activities.
The System Production, Support, and Utilization (PSU) stages begin when the key stakeholders decide that the SoI life-cycle feasibility and safety are at a sufficiently low-risk level that justifies committing the resources necessary to produce, field, support, and utilize the system over its expected lifetime. The lifetimes of production, support, and utilization are likely to be different. After market support will generally continue after production is complete and users will often continue to use unsupported systems.
System Production involves the fabrication of instances or versions of an SoI and of associated after-market spare parts. It also includes production quality monitoring and improvement; product or service acceptance activities; and continuous production process improvement. It may include low-rate initial production (LRIP) to mature the production process or to promote the continued preservation of the production capability for future spikes in demand.
Systems Support includes various classes of maintenance: corrective (for defects), adaptive (for interoperability with independently evolving co-dependent systems), and perfective (for enhancement of performance, usability, or other key performance parameters). It also includes hot lines and responders for user or emergency support and the provisioning of needed consumables (gas, water, power, etc.). Its boundaries include some gray areas, such as the boundary between small system enhancements and the development of larger complementary new additions, and the boundary between rework/maintenance of earlier fielded increments in incremental or evolutionary development. Systems Support usually continues after System Production is terminated.
System Utilization includes the use of the SoI in its context by operators, administrators, the general public, or systems above it in the system-of-interest hierarchy. It usually continues after Systems Support is terminated.
The System Retirement stage is often executed incrementally as system versions or elements become obsolete or are no longer economical to support and therefore undergo disposal or recycling of their content. Increasingly affordable considerations make system re-purposing an attractive alternative.
Applying the Life Cycle Model
Figure 1 shows just the single-step approach for proceeding through the stages of a SoI life cycle. In the Life Cycle Models knowledge area, we discuss examples of real-world enterprises and their drivers, both technical and organizational. These have led to a number of documented approaches for sequencing the life cycle stages to deal with some of the issues raised. The Life Cycle Models KA summarizes a number of incrementalincremental and evolutionaryevolutionary life cycle models, including their main strengths and weaknesses, and also discusses criteria for choosing the best-fit approach.
In Figure 1, we have listed key technical and management activities critical to successful completion of each stage. This is a useful way to illustrate the goals of each stage and gives an indication of how processes align with these stages. This can be important when considering how to plan for resources, milestones, etc. However, it is important to observe that the execution of process activities is not compartmentalized to particular life cycle stages (Lawson 2010). In Applying Life Cycle Processes, we discuss a number of views on the nature of the inter-relationships between process activities within a life cycle model. In general, the technical and management activities are applied in accordance with the principles of concurrencyconcurrency, iterationiteration and recursionrecursion described in the generic life cycle paradigm.
References
Works Cited
ISO/IEC/IEEE. 2015.Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers. ISO/IEC 15288:2015.
ISO/IEC. 2010. Systems and Software Engineering, Part 1: Guide for Life Cycle Management. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 24748-1:2010.
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.
Primary References
Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management, 3rd Ed. Hoboken, NJ: J. Wiley & Sons.
INCOSE. 2015. 'Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.
Additional References
None.
< Previous Article | Parent Article | Next Article >
SEBoK v. 2.1, released 31 October 2019
