Difference between pages "Integration of Process and Product Models" and "System Life Cycle Process Models: Vee"

From SEBoK
(Difference between pages)
Jump to: navigation, search
(Robot improving glossary links)
 
(Tech and grammar edits as discussed with Bkcase)
 
Line 1: Line 1:
When performing systems engineering activities, it is important to consider the mutual relationship between processes and the desired system. The type of system (see [[Types of Systems]]) being produced will affect the needed processes, as indicated in [[System Life Cycle Process Drivers and Choices|system life cycle process drivers and choices]]. This may cause the {{Term|Tailoring (glossary)|tailoring (glossary)}} of defined processes as described in [[Application of Systems Engineering Standards|application of systems engineering standards]].
+
There are a large number of [[Life Cycle Models|life cycle process models]]. As discussed in the [[System Life Cycle Process Drivers and Choices]] article, these models fall into three major categories: (1) primarily pre-specified and sequential processes; (2) primarily evolutionary and concurrent processes (e.g., the rational unified process and various forms of the Vee and spiral models); and (3) primarily interpersonal and unconstrained processes (e.g., agile development, Scrum, extreme programming (XP), the dynamic system development method, and innovation-based processes).
  
==Process and Product Models==
+
This article specifically focuses on the Vee Model as the primary example of pre-specified and sequential processes. In this discussion, it is important to note that the Vee model, and variations of the Vee model, all address the same basic set of systems engineering (SE) activities. The key difference between these models is the way in which they group and represent the aforementioned SE activities.  
Figure 1 of  [[Life Cycle Models|life cycle models]] introduced the perspective of viewing stage work products provided by process execution as versions of a system-of-interest (SoI) at various life stages. The fundamental changes that take place during the life cycle of any man-made system include definition, production, and utilization. Building upon these, it is useful to consider the structure of a generic process and product life cycle stage model as portrayed in Figure 1 below.
 
  
[[File:Generic_(T)_Stage_Structure_of_System_Life_Cycle_Models_(Lawson_2010,_Figure_6-2).png|frame|center|500px|'''Figure 1. Generic (T) Stage Structure of System Life Cycle (Lawson 2010).''' Reprinted with permission of Harold "Bud" Lawson. All other rights are reserved by the copyright owner.]]
+
General implications of using the Vee model for system design and development are discussed below; for a more specific understanding of how this life cycle model impacts systems engineering activities, please see the other knowledge areas (KAs) in Part 3.
  
The (T) model indicates that a definition stage precedes a production stage where the implementation (acquisition, provisioning, or development) of two or more {{Term|System Element (glossary)|system elements}} has been accomplished. The system elements are integrated according to defined relationships into the SoI. Thus, both the process and product aspects are portrayed. The implementation and integration processes are followed in providing the primary stage results—namely, in assembled system product or service instances. However, as noted in [[Life Cycle Models|life cycle models]], the definition of the SoI when provided in a development stage can also be the result of first versions of the system. For example, a {{Term|Prototype (glossary)|prototype (glossary)}}, which may be viewed as a form of production or pre-production stage. Following the production stage is a utilization stage. Further relevant stages can include support and retirement. Note that this model also displays the important distinction between definition versus implementation and integration.
+
==A Primarily Pre-specified and Sequential Process Model: The Vee Model==
 +
The sequential version of the Vee Model is shown in Figure 1. Its core involves a sequential progression of plans, specifications, and products that are baselined and put under configuration management. The vertical, two-headed arrow enables projects to perform concurrent opportunity and risk analyses, as well as continuous in-process validation. The Vee Model encompasses the first three life cycle stages listed in the "Generic Life Cycle Stages" table of the INCOSE ''Systems Engineering Handbook'': exploratory research, concept, and development (INCOSE 2012)
 +
 +
[[File:KF_VeeModel_Left.png|thumb|1200px|center|'''Figure 1. Left Side of the Sequential Vee Model (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
 +
 
 +
The Vee Model endorses the INCOSE ''Systems Engineering Handbook'' (INCOSE 2012) definition of life cycle stages and their purposes or activities, as shown in Figure 2 below.
 +
 
 +
[[File:Fig_2_Life_Cycle_Stages_Vee_KF.png|thumb|500px|center|'''Figure 2. An Example of Stages, Their Purposes and Major Decision Gates.''' (SEBoK Original)]]
 +
 
 +
The INCOSE ''Systems Engineering Handbook'' 3.2.2 contains a more detailed version of the Vee diagram (2012, Figures 3-4, p. 27) which incorporates life cycle activities into the more generic Vee model. A similar diagram, developed at the U.S. Defense Acquisition University (DAU), can be seen in Figure 3 below.
  
According to [[ISO/IEC/IEEE 15288]] (2015), this structure is generic for any type of man-made SoI to undergo life cycle management. The production stage thus becomes the focal point of the (T) model at which system elements are implemented and integrated into system product or service instances based upon the definitions. For defined physical systems, this is the point at which product instances are manufactured and assembled (singularly or mass-produced). For non-physical systems, the implementation and integration processes are used in service preparation (establishment) prior to being instantiated to provide a service. For software systems, this is the point at which builds that combine software elements into versions, releases, or some other form of managed software product are produced.  
+
[[File:JS_Figure_2.png|thumb|600px|center|'''Figure 3. The Vee Activity Diagram (Prosnik 2010).''' Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]]
  
Using {{Term|Recursion (glossary)|recursive decomposition}}, the implementation of each system element can involve the invocation of the standard again at the next lowest level, thus treating the system element as a SoI in its own right. A new life cycle structure is then utilized for the lower level SoIs.
+
===Application of the Vee Model===
 +
Lawson (Lawson 2010) elaborates on the activities in each life cycle stage and notes that it is useful to consider the structure of a generic life cycle stage model for any type of system-of-interest (SoI) as portrayed in Figure 4. This '''(T)''' model indicates that one or more definition stages precede a production stage(s) where the implementation (acquisition, provisioning, or development) of two or more system elements has been accomplished.
 +
 
 +
[[File:KF_GenericStageStructure.png|frame|center|600px|'''Figure 4. Generic (T) Stage Structure of System Life Cycle Models (Lawson 2010).''' Reprinted with permission of Harold Lawson. All other rights are reserved by the copyright owner.]]
 
   
 
   
This is illustrated in the Dual Vee model (Figures 2a and 2b). The Dual Vee model is a three-dimensional system development model that integrates product and process in the creation of the system and component architectures. It emphasizes
+
Figure 5 shows the generic life cycle stages for a variety of stakeholders, from a standards organization (ISO/IEC) to commercial and government organizations. Although these stages differ in detail, they all have a similar sequential format that emphasizes the core activities as noted in Figure 2 (definition, production, and utilization/retirement). 
 +
 
 +
[[File:Comparisons_of_life_cycle_models.PNG|frame|center|500px|'''Figure 5. Comparisons of Life Cycle Models (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons. All other rights are reserved by the copyright owner.]]
 +
 
 +
It is important to note that many of the activities throughout the life cycle are iterated. This is an example of {{Term|Recursion (glossary)|recursion (glossary)}} as discussed in the [[Systems Engineering and Management|Part 3 Introduction]].
 +
 
 +
==Fundamentals of Life Cycle Stages and Program Management Phase==
 +
 
 +
For this discussion, it is important to note that:
 +
 
 +
*The term '''{{Term|Stage (glossary)|stage}}''' refers to the different states of a system during its life cycle; some stages may overlap in time, such as the utilization stage and the support stage. The term “stage” is used in [[ISO/IEC/IEEE 15288]].
  
*concurrent opportunity and risk management;  
+
*The term '''phase''' refers to the different steps of the program that support and manage the life of the system; the phases usually do not overlap. The term “phase” is used in many well-established models as an equivalent to the term “stage.
*user in-process {{Term|Validation (glossary)|validation (glossary)}};
 
*{{Term|Integration (glossary)|integration (glossary)}}, {{Term|Verification (glossary)|verification (glossary)}}, and {{Term|Validation (glossary)|validation (glossary)}} planning; and
 
*{{Term|Verification (glossary)|verification (glossary)}} problem resolution.
 
  
When decomposition terminates according to the practical need and risk-benefit analysis, system elements are then implemented (acquired, provisioned, or developed) according to the type of element involved.
+
{{Term|Program Management (glossary)|Program management}} employs phases, {{Term|Milestone (glossary)|milestones}}, and {{Term|Decision Gate (glossary)|decision gates}} which are used to assess the evolution of a system through its various stages. The stages contain the activities performed to achieve goals and serve to control and manage the sequence of stages and the transitions between each stage. For each project, it is essential to define and publish the terms and related definitions used on respective projects to minimize confusion.
  
[[File:@@BKCASE_Wiki_Section_2.5_Fig_2a_PDF_110820.png|thumb|center|500px|'''Figure 2a. The Dual Vee Model (2a) (Forsberg, Mooz, Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
+
A typical {{Term|Program (glossary)|program}} is composed of the following phases:
  
[[File:@@BKCASE_Wiki_Section_2.5_Fig_2b_PDF_110820.png|thumb|center|500px|'''Figure 2b. The Dual Vee Model (2b) (Forsberg, Mooz, Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
+
*The '''pre-study phase''', which identifies potential opportunities to address user needs with new solutions that make business sense.  
 +
*The '''feasibility phase''' consists of studying the feasibility of alternative concepts to reach a second decision gate before initiating the execution stage. During the feasibility phase, stakeholders' requirements and system requirements are identified, viable solutions are identified and studied, and virtual {{Term|prototype (glossary)|prototypes (glossary)}} can be implemented. During this phase, the decision to move forward is based on:
 +
**whether a concept is feasible and is considered able to counter an identified threat or exploit an opportunity;
 +
**whether a concept is sufficiently mature to warrant continued development of a new product or line of products; and
 +
**whether to approve a proposal generated in response to a request for proposal.
 +
*The '''execution phase''' includes activities related to four stages of the system life cycle: ''development, production, utilization, and support''. Typically, there are two decision gates and two milestones associated with execution activities. The first milestone provides the opportunity for management to review the plans for execution before giving the go-ahead. The second milestone provides the opportunity to review progress before the decision is made to initiate production. The decision gates during execution can be used to determine whether to produce the developed SoI and whether to improve it or retire it.
  
A practical aspect that can very well affect the process and product aspect is the decision to use off-the-shelf elements in commercial-off-the-shelf (COTS) form. In this case, further decomposition of the element is not necessary. The use of COTS elements (and their internally created neighbor or non-development item (NDI)) has become widespread, and they have proven their value. However, developers must make sure that the COTS product is appropriate for their environment.  
+
These program management views apply not only to the SoI, but also to its elements and structure.
  
A known flaw which occurs infrequently in normal use of the product in its intended environment may be benign and easily dealt with. In a new situation, it could have dramatic adverse consequences, such as those that occurred on the USS Yorktown Cruiser in 1998 (Wired News Contributors 1998). The customer mandated that Windows NT be used as the primary operating system for the ship. A ''divide by zero'' fault caused the operating system to fail, and the ship was dead in the water. It had to be towed back to port on three occasions.
+
==Life Cycle Stages==
 +
Variations of the Vee model deal with the same general stages of a life cycle:
 +
*New projects typically begin with an exploratory research phase which generally includes the activities of [[Concept Definition|concept definition]], specifically the topics of [[Business or Mission Analysis|business or mission analysis]] and the understanding of [[Stakeholder Needs and Requirements|stakeholder needs and requirements]]. These mature as the project goes from the exploratory stage to the concept stage to the development stage.
 +
*The production phase includes the activities of [[System Definition|system definition]] and [[System Realization|system realization]], as well as the development of the system {{Term|System Requirement (glossary)|requirements (glossary)}} and {{Term|Architecture (glossary)|architecture (glossary)}} through [[System Verification|verification]] and [[System Validation|validation]].
 +
*The utilization phase includes the activities of [[System Deployment|system deployment]] and [[Operation of the System|system operation]].
 +
*The support phase includes the activities of [[System Maintenance|system maintenance]], [[Logistics|logistics]], and [[Product and Service Life Management|product and service life management]], which may include activities such as [[Service Life Extension|service life extension]] or [[Capability Updates, Upgrades, and Modernization|capability updates, upgrades, and modernization]].
 +
*The retirement phase includes the activities of [[Disposal and Retirement|disposal and retirement]], though in some models, activities such as [[Service Life Extension|service life extension]] or [[Capability Updates, Upgrades, and Modernization|capability updates, upgrades, and modernization]] are grouped into the "retirement" phase.
  
Spiral models concurrently engineer not only process and product models, but also property and success models. Figure 3 shows how these models provide checks and balances, both at {{Term|Milestone (glossary)|milestone}} reviews and as individual model choices are made. Methods and tools supporting this concurrent engineering are provided in “When Models Collide: Lessons from Software System Analysis” (Boehm and Port 1999), “Avoiding the Software Model-Clash Spiderweb” (Boehm, Port, and Al-Said 2000), and “Detecting Model Clashes During Software Systems Development” (Al-Said 2003).
+
Additional information on each of these stages can be found in the sections below (see links to additional Part 3 articles above for further detail). It is important to note that these life cycle stages, and the activities in each stage, are supported by a set of [[Systems Engineering Management|systems engineering management processes]].
   
 
[[File:Figure_3._Spiral_Model_support_for_Process_Models,_Product_Models....png|thumb|center|600px|'''Figure 3. Spiral Model Support for Process Models, Product Models, Success Models, Property Models (Boehm and Port 1999).''' Reprinted with permission of  © Copyright  IEEE – All rights reserved. All other rights are reserved by the copyright owner.]]  
 
  
For software systems, entry into the production stages is the point at which builds that combine software elements (code modules) into versions, releases, or some other form of managed software product are created. Thus, the major difference between systems in general and software systems is the slight variant of the generic model as presented in Figure 4.
+
===Exploratory Research Stage===
 +
[[Stakeholder Needs and Requirements|User requirements]] analysis and agreement is part of the exploratory research stage and is critical to the development of successful systems. Without proper understanding of the user needs, any system runs the risk of being built to solve the wrong problems. The first step in the exploratory research phase is to define the user (and stakeholder) requirements and constraints. A key part of this process is to establish the feasibility of meeting the user requirements, including technology readiness assessment. As with many SE activities this is often done iteratively, and stakeholder needs and requirements are revisited as new information becomes available.  
  
[[File:T-Model_for_Software_System_(Lawson_2010,_Figure_6-3).png|frame|center|600px|'''Figure 4. T-Model for Software System (Lawson 2010).''' Reprinted with permission of Harold "Bud" Lawson. All other rights are reserved by the copyright owner.]]
+
A recent study by the National Research Council (National Research Council 2008) focused on reducing the development time for US Air Force projects. The report notes that, “simply stated, systems engineering is the translation of a user’s needs into a definition of a system and its architecture through an iterative process that results in an effective system design.” The iterative involvement with stakeholders is critical to the project success.
 +
 
 +
Except for the first and last decision gates of a project, the gates are performed simultaneously. See Figure 6 below.
 +
 +
[[File:KF_SchedulingDevelopment.png|800px|thumb|center|'''Figure 6. Scheduling the Development Phases.''' (SEBoK Original)]]
  
==Stage Execution Order==
+
===Concept Stage===
 +
During the [[Concept Definition|concept stage]], alternate concepts are created to determine the best approach to meet stakeholder needs. By envisioning alternatives and creating models, including appropriate prototypes, stakeholder needs will be clarified and the driving issues highlighted. This may lead to an incremental or evolutionary approach to system development. Several different concepts may be explored in parallel.
  
A sequential execution of life cycle stages is the most straightforward. As presented in [[System Life Cycle Process Models: Vee]] and [[System Life Cycle Process Models: Iterative]], variants of the Vee model and the spiral model provide non-sequential models when practical considerations require a non-linear execution of life cycle stages. Building upon these two models, it is important to note that various types of complex systems require that the stages of the life cycle model be revisited as insight (knowledge) is gained, as well as when stakeholder requirements change. The iterations may involve necessary changes in the processes and in the product or service system. Thus, within the context of the (T) stage model, various orderings of stage execution - reflecting forms of non-sequential stage ordering - can be conveniently described, as portrayed in Figure 5.
+
===Development Stage===
 +
The selected concept(s) identified in the concept stage are elaborated in detail down to the lowest level to produce the solution that meets the {{Term|Stakeholder Requirement (glossary)|stakeholder requirements}}. Throughout this stage, it is vital to continue with user involvement through in-process validation (the upward arrow on the Vee models). On hardware, this is done with frequent program reviews and a customer resident representative(s) (if appropriate). In agile development, the practice is to have the customer representative integrated into the development team.
  
[[File:Iteration_through_Life_Cycle_Stages_(Lawson_2010,_Figure_6-4).png|frame|center|700px|'''Figure 5. Iteration Through Life Cycle Stages (Lawson 2010).''' Reprinted with permission of Harold "Bud" Lawson. All other rights are reserved by the copyright owner.]]
+
===Production Stage===
 +
The production stage is where the SoI is built or manufactured. Product modifications may be required to resolve production problems, to reduce production costs, or to enhance product or SoI capabilities. Any of these modifications may influence system requirements and may require system re-{{Term|qualification (glossary)|qualification}}, re-{{Term|verification (glossary)|verification}}, or re-{{Term|validation (glossary)|validation}}. All such changes require SE assessment before changes are approved.
  
Each pattern of stage execution involves iteration of the previous stages, perhaps with altered requirements for the processes or the system. The heavy lines in Figure 5 denote the demarcation of the revisited end points. Three are iterative forms, for which several variants can be extracted:
+
===Utilization Stage===
 +
A significant aspect of product life cycle management is the provisioning of supporting systems which are vital in sustaining operation of the product. While the supplied product or service may be seen as the narrow system-of-interest (NSOI) for an {{Term|Acquirer (glossary)|acquirer}}, the acquirer also must incorporate the supporting systems into a wider system-of-interest (WSOI). These supporting systems should be seen as system assets that, when needed, are activated in response to a situation that has emerged in respect to the operation of the NSOI. The collective name for the set of supporting systems is the integrated logistics support (ILS) system.
  
#'''Iterative development''' is quite frequently deployed in order to assess stakeholder requirements, analyze the requirements, and develop a viable architectural design. Thus, it is typical that the concept stage may be revisited during the development stage. For systems where products are based upon physical structures (electronics, mechanics, chemicals, and so on), iteration after production has begun can involve significant costs and schedule delays. It is, therefore, important to get it ''"right"'' before going to production. The early stages are thus used to build confidence (verify and validate) that the solution works properly and will meet the needs of the stakeholders. Naturally, such an approach could be used for software and human activity systems as well; however, due to their soft nature, it can be useful to go further by experimenting and evaluating various configurations of the system.
+
It is vital to have a holistic view when defining, producing, and operating system products and services. In Figure 7, the relationship between system design and development and the ILS requirements is portrayed.
#'''Iterative development and implementation''' involves producing (defining, implementing, and integrating) various versions of the system, evaluating how well they meet stakeholder requirements, perhaps in the context of changing requirements, and then revisiting the concept and/or development stages. Such iterations are typical within software system development, where the cost of production is not as significant as for defined physical systems. A variant of this approach is the spiral model, where successive iterations fill in more detail (Boehm and May 1998). The use of this approach requires careful attention to issues related to baseline and configuration management. In this approach, significant verification (testing) should be performed on software systems in order to build confidence that the system delivered will meet stakeholder requirements.
 
#'''Incremental or progressive acquisition''' involves releasing systems in the form of products and/or services to the consumers. This approach is appropriate when structural and capability (functions) changes are anticipated in a controlled manner after deployment. The use of this approach can be due to not knowing all of the requirements at the beginning, which leads to progressive acquisition/deployment, or due to a decision to handle the complexity of the system and its utilization in increments—namely, incremental acquisition. These approaches are vital for complex systems in which software is a significant system element. Each increment involves revisiting the definition and production stages. The utilization of these approaches must be based upon well-defined, agreed relationships between the supplying and acquiring enterprises. In fact, the iteration associated with each resulting product and/or service instance may well be viewed as a joint project, with actor roles being provided by both enterprises.
 
  
In all of the approaches it is wise to use modeling and simulation techniques and related tools to assist in understanding the effect of changes made in the complex systems being life cycle managed. These techniques are typically deployed in the earlier stages; however, they can be used in gaining insight into the potential problems and opportunities associated with the latter stages of utilization and maintenance (for example, in understanding the required logistics and help-desk aspects).
+
[[File:KF_ILSSystemLifeCycle.png|frame|center|1100px|'''Figure 7. Relating ILS to the System Life Cycle (Eichmueller and Foreman 2009)'''.  Reprinted with permission of of ASD/AIA S3000L Steering Committee. All other rights are reserved by the copyright owner.]]
  
==Allocating and Meeting Requirements - Integration of Process and Product Models==
+
The requirements for reliability, resulting in the need of maintainability and testability, are driving factors.
  
Regardless of the order in which life cycle stages are executed, stakeholder requirements for the system, including changed requirements in each iteration, must be allocated into appropriate activities of the processes used in projects for various stages as well as to the properties of the elements of the product system or service system and their defined relationships. This distribution was illustrated in the fourth variant of Lawson’s T-model as presented in [[System Life Cycle Process Models: Iterative]] and [[System Life Cycle Process Models: Vee]].
+
===Support Stage===
 +
In the support stage, the SoI is provided services that enable continued operation.  Modifications may be proposed to resolve supportability problems, to reduce operational costs, or to extend the life of a system. These changes require SE assessment to avoid loss of system capabilities while under operation. The corresponding technical process is the maintenance process.
  
Ideally, the project management team should implement proven processes that will integrate the technical process models with the project management product models to manage any of the processes discussed earlier, including incremental and evolutionary development. The processes shown are the project management flow, starting with the beginning of the development phase (Forsberg, Mooz, and Cotterman 2005, 201).
+
===Retirement Stage ===
 +
In the retirement stage, the SoI and its related services are removed from operation. SE activities in this stage are primarily focused on ensuring that disposal requirements are satisfied. In fact, planning for disposal is part of the system definition during the concept stage. Experiences in the 20th century repeatedly demonstrated the consequences when system retirement and disposal was not considered from the outset. Early in the 21st century, many countries have changed their laws to hold the creator of a SoI accountable for proper end-of-life disposal of the system.
  
[[File:@@BKCASE_Sect_2.5_Fig_6A.png|thumb|center|500px|'''Figure 6a. New Product Planning Process – Getting Started (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
+
==Life Cycle Reviews==
  
[[File:@@BKCASE_Sect_2.5_Fig_6B.png|thumb|center|500px|'''Figure 6b. New Product Planning Process Solving the Problem (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
+
To control the progress of a project, different types of reviews are planned. The most commonly used are listed as follows, although the names are not universal:
 +
*The '''system requirements review''' (SRR) is planned to verify and validate the set of system requirements before starting the detailed design activities.
 +
*The {{Term|Preliminary Design Review (PDR) (glossary)|preliminary design review}} (PDR) is planned to verify and validate the set of system requirements, the design artifacts, and justification elements at the end of the first engineering loop (also known as the "design-to" gate).
 +
*The {{Term|Critical Design Review (CDR) (glossary)|critical design review}} (CDR) is planned to verify and validate the set of system requirements, the design artifacts, and justification elements at the end of the last engineering loop (the “build-to” and “code-to” designs are released after this review).
 +
*The {{Term|integration (glossary)|integration}}, {{Term|verification (glossary)|verification}}, and {{Term|validation (glossary)|validation}} reviews are planned as the components are assembled into higher level subsystems and elements. A sequence of reviews is held to ensure that everything integrates properly and that there is objective evidence that all requirements have been met. There should also be an in-process validation that the system, as it is evolving, will meet the stakeholders’ requirements (see Figure 7).
 +
*The final validation review is carried out at the end of the integration phase.
 +
*Other management related reviews can be planned and conducted in order to control the correct progress of work, based on the type of system and the associated risks.
  
[[File:QQBKCASE_Sect_2.5_Fig_6C.png|thumb|center|600px|'''Figure 6c. New Product Planning Process – Getting Commitment (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
+
[[File:KF_VeeModel_Right.png|frame|center|600px|'''Figure 8. Right Side of the Vee Model (Forsberg, Mooz, and Cotterman 2005).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]
  
==References==  
+
==References==
  
 
===Works Cited===
 
===Works Cited===
 +
Eichmueller, P. and B. Foreman. 2010. ''S3000LTM''. Brussels, Belgium: Aerospace and Defence Industries Association of Europe (ASD)/Aerospace Industries Association (AIA).
 +
 +
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.
  
Boehm, B. and W. May. 1988. "A Spiral Model of Software Development and Enhancement."  IEEE ''Computer'' 21(5): 61-72.
+
Forsberg, K., H. Mooz, and H. Cotterman. 2005. ''Visualizing Project Management,'' 3rd ed. New York, NY, USA: J. Wiley & Sons.
  
Boehm, B. and D. Port. 1999. "When Models Collide: Lessons From Software System Analysis." ''IT Professional'' 1(1): 49-56.
+
INCOSE. 2012. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,'' version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
  
Boehm, B., J. Lane, S. Koolmanojwong, and R. Turner (forthcoming). ''Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model.'' New York, NY, USA: Addison Wesley.
+
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' London, UK: College Publications, Kings College, UK.
 +
 
 +
===Primary References===
 +
Beedle, M., et al. 2009. "[[The Agile Manifesto: Principles behind the Agile Manifesto]]". in ''The Agile Manifesto'' [database online]. Accessed December 04 2014 at www.agilemanifesto.org/principles.html
  
Forsberg, K., H. Mooz, and H. Cotterman. 2005. ''Visualizing Project Management.'' 3rd ed. New York, NY, USA: J. Wiley & Sons.
+
Boehm, B. and R. Turner. 2004. ''[[Balancing Agility and Discipline]].'' New York, NY, USA: Addison-Wesley.
  
ISO/IEC/IEEE. 2015.''[[ISO/IEC/IEEE 15288|Systems and Software Engineering]]-- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions.[[ISO/IEC/IEEE 15288]]:2015
+
Fairley, R. 2009. ''[[Managing and Leading Software Projects]].'' New York, NY, USA: J. Wiley & Sons.
  
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' London, UK: College Publications.
+
Forsberg, K., H. Mooz, and H. Cotterman. 2005. ''[[Visualizing Project Management]].'' 3rd ed.  New York, NY, USA: J. Wiley & Sons.
  
Wired News Contributors. 2011. “Sunk by Windows NT,” ''Wired News'', last modified July 24, 1998. Accessed on September 11, 2011. Available at http://www.wired.com/science/discoveries/news/1998/07/13987.
+
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
  
===Primary References===
+
Lawson, H. 2010. ''[[A Journey Through the Systems Landscape]].'' Kings College, UK: College Publications.
Boehm, B. and W. May. 1988. “[[A Spiral Model of Software Development and Enhancement]].” IEEE ''Computer.'' 21(5): 61-72.  
 
  
Forsberg, K., H. Mooz, and H. Cotterman. 2005. ''[[Visualizing Project Management]],'' 3rd ed. New York, NY, USA: John Wiley & Sons.
+
Pew, R., and A. Mavor (eds.) 2007. ''[[Human-System Integration in the System Development Process]]: A New Look.'' Washington, DC, USA: The National Academies Press.
  
Lawson, H. 2010. ''[[A Journey Through the Systems Landscape]].'' London, UK: College Publications.
+
Royce, W.E. 1998. ''[[Software Project Management]]: A Unified Framework''. New York, NY, USA: Addison Wesley.
  
 
===Additional References===
 
===Additional References===
 +
Anderson, D. 2010. ''Kanban''.  Sequim, WA, USA: Blue Hole Press.
 +
 +
Baldwin, C. and K. Clark. 2000. ''Design Rules: The Power of Modularity.'' Cambridge, MA, USA: MIT Press.
 +
 +
Beck, K. 1999. ''Extreme Programming Explained.'' New York, NY, USA: Addison Wesley.
 +
 +
Beedle, M., et al. 2009. "The Agile Manifesto: Principles behind the Agile Manifesto". in The Agile Manifesto [database online]. Accessed 2010. Available at: www.agilemanifesto.org/principles.html
 +
 +
Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, and P. Gruenbacher (eds.). 2005. ''Value-Based Software Engineering''. New York, NY, USA: Springer.
 +
 +
Boehm, B. 1988. “A Spiral Model of Software Development.” IEEE ''Computer'' 21(5): 61-72.
 +
 +
Boehm, B. 2006. “Some Future Trends and Implications for Systems and Software Engineering Processes.” ''Systems Engineering.'' 9(1): 1-19.
 +
 +
Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy. 1998. “Using the WinWin Spiral Model: A Case Study.” IEEE ''Computer.'' 31(7): 33-44.
 +
 +
Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (in press). ''Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model''. Boston, MA, USA: Addison Wesley.
 +
 +
Castellano, D.R. 2004. “Top Five Quality Software Projects.” ''CrossTalk.'' 17(7) (July 2004): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf
 +
 +
Checkland, P. 1981. ''Systems Thinking, Systems Practice''. New York, NY, USA: Wiley.
 +
 +
Crosson, S. and B. Boehm. 2009. “Adjusting Software Life cycle Anchorpoints: Lessons Learned in a System of Systems Context.” Proceedings of the Systems and Software Technology Conference, 20-23 April 2009, Salt Lake City, UT, USA.
 +
 +
Dingsoyr, T., T. Dyba. and N. Moe (eds.). 2010. "Agile Software Development: Current Research and Future Directions.”  Chapter in B. Boehm, J. Lane, S. Koolmanjwong, and R. Turner, ''Architected Agile Solutions for Software-Reliant Systems.'' New York, NY, USA: Springer.
 +
 +
Dorner, D. 1996. ''The Logic of Failure''.  New York, NY, USA: Basic Books.
 +
 +
Forsberg, K. 1995. "'If I Could Do That, Then I Could…' System Engineering in a Research and Development Environment.” Proceedings of the Fifth Annual International Council on Systems Engineering (INCOSE) International Symposium. 22-26 July 1995. St. Louis, MO, USA.
 +
 +
Forsberg, K. 2010. “Projects Don’t Begin With Requirements.” Proceedings of the IEEE Systems Conference, 5-8 April 2010, San Diego, CA, USA.
 +
 +
Gilb, T. 2005.  ''Competitive Engineering''.  Maryland Heights, MO, USA: Elsevier Butterworth Heinemann.
 +
 +
Goldratt, E. 1984. ''The Goal''. Great Barrington, MA, USA: North River Press.
 +
 +
Hitchins, D.  2007. ''Systems Engineering: A 21st Century Systems Methodology.''  New York, NY, USA: Wiley.
 +
 +
Holland, J. 1998. ''Emergence''. New York, NY, USA: Perseus Books.
 +
 +
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.
 +
 +
ISO/IEC/IEEE. 2015. ''Systems and Software Engineering -- System Life Cycle Processes.'' Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
 +
 +
ISO/IEC. 2003. ''Systems Engineering — A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).
 +
 +
Jarzombek, J. 2003. “Top Five Quality Software Projects.” ''CrossTalk.'' 16(7) (July 2003): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.
 +
 +
Kruchten, P. 1999. ''The Rational Unified Process.'' New York, NY, USA: Addison Wesley.
 +
 +
Landis, T. R. 2010. ''Lockheed Blackbird Family (A-12, YF-12, D-21/M-21 & SR-71).''  North Branch, MN, USA: Specialty Press.
 +
 +
Madachy, R. 2008. ''Software Process Dynamics''.  Hoboken, NJ, USA: Wiley.
 +
 +
Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. “Architecture Reviews: Practice and Experience.” IEEE ''Software.'' 22(2): 34-43.
 +
 +
National Research Council of the National Academies (USA). 2008. ''Pre-Milestone A and Early-Phase Systems Engineering''. Washington, DC, USA: The National Academies Press.
 +
 +
Osterweil, L. 1987. “Software Processes are Software Too.” Proceedings of the SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.
 +
 +
Poppendeick, M. and T. Poppendeick. 2003. ''Lean Software Development: an Agile Toolkit.''  New York, NY, USA: Addison Wesley.
 +
 +
Rechtin, E. 1991. ''System Architecting: Creating and Building Complex Systems.'' Upper Saddle River, NY, USA: Prentice-Hall.
  
Al-Said, M. 2003. "Detecting Model Clashes During Software Systems Development." PhD Diss. Department of Computer Science, University of Southern California, December 2003.
+
Rechtin, E., and M. Maier. 1997. ''The Art of System Architecting''. Boca Raton, FL, USA: CRC Press.  
  
Boehm, B., J. Lane, S. Koolmanojwong, and R. Turner. (forthcoming). ''Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model.'' New York, NY, USA: Addison Wesley.
+
Schwaber, K. and M. Beedle. 2002. ''Agile Software Development with Scrum''. Upper Saddle River, NY, USA: Prentice Hall.  
  
Boehm, B. and D. Port. 1999. "Escaping the Software Tar Pit: Model Clashes and How to Avoid Them." ''ACM Software Engineering Notes.'' (January, 1999): p. 36-48.
+
Spruill, N. 2002. “Top Five Quality Software Projects.''CrossTalk.'' 15(1) (January 2002): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2002/200201/200201-0-Issue.pdf.
  
Boehm, B. and D. Port. 1999. "When Models Collide: Lessons From Software System Analysis." ''IT Professional.'' 1(1): 49-56.
+
Stauder, T. 2005. “Top Five Department of Defense Program Awards.''CrossTalk.'' 18(9) (September 2005): 4-13. Available at http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.
  
Boehm, B., D. Port, and M. Al-Said. 2000.  "Avoiding the Software Model-Clash Spiderweb." IEEE ''Computer.'' 33(11): 120-122.
+
Warfield, J. 1976. ''Societal Systems: Planning, Policy, and Complexity''. New York, NY, USA: Wiley.
  
Lawson, H. and M. Persson. 2010. “Portraying Aspects of System Life Cycle Models.” Proceedings of the European Systems Engineering Conference (EuSEC). 23-26 May 2010. Stockholm, Sweden.
+
Womack, J. and D. Jones. 1996. ''Lean Thinking.'' New York, NY, USA: Simon and Schuster.
  
 
----
 
----
  
<center>[[System Life Cycle Process Models: Iterative|< Previous Article]] | [[Life Cycle Models|Parent Article]] | [[Lean Engineering|Next Article >]]</center>
+
<center>[[System Life Cycle Process Drivers and Choices|< Previous Article]] | [[Life Cycle Models|Parent Article]] | [[System Life Cycle Process Models: Iterative|Next Article >]] </center>
  
 
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
 
<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>
  
[[Category:Part 3]][[Category:Topic]]
+
[[Category: Part 3]][[Category:Topic]]
 
[[Category:Life Cycle Models]]
 
[[Category:Life Cycle Models]]

Revision as of 03:16, 19 October 2019

There are a large number of life cycle process models. As discussed in the System Life Cycle Process Drivers and Choices article, these models fall into three major categories: (1) primarily pre-specified and sequential processes; (2) primarily evolutionary and concurrent processes (e.g., the rational unified process and various forms of the Vee and spiral models); and (3) primarily interpersonal and unconstrained processes (e.g., agile development, Scrum, extreme programming (XP), the dynamic system development method, and innovation-based processes).

This article specifically focuses on the Vee Model as the primary example of pre-specified and sequential processes. In this discussion, it is important to note that the Vee model, and variations of the Vee model, all address the same basic set of systems engineering (SE) activities. The key difference between these models is the way in which they group and represent the aforementioned SE activities.

General implications of using the Vee model for system design and development are discussed below; for a more specific understanding of how this life cycle model impacts systems engineering activities, please see the other knowledge areas (KAs) in Part 3.

A Primarily Pre-specified and Sequential Process Model: The Vee Model

The sequential version of the Vee Model is shown in Figure 1. Its core involves a sequential progression of plans, specifications, and products that are baselined and put under configuration management. The vertical, two-headed arrow enables projects to perform concurrent opportunity and risk analyses, as well as continuous in-process validation. The Vee Model encompasses the first three life cycle stages listed in the "Generic Life Cycle Stages" table of the INCOSE Systems Engineering Handbook: exploratory research, concept, and development (INCOSE 2012).

Figure 1. Left Side of the Sequential Vee Model (Forsberg, Mooz, and Cotterman 2005). Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.

The Vee Model endorses the INCOSE Systems Engineering Handbook (INCOSE 2012) definition of life cycle stages and their purposes or activities, as shown in Figure 2 below.

Figure 2. An Example of Stages, Their Purposes and Major Decision Gates. (SEBoK Original)

The INCOSE Systems Engineering Handbook 3.2.2 contains a more detailed version of the Vee diagram (2012, Figures 3-4, p. 27) which incorporates life cycle activities into the more generic Vee model. A similar diagram, developed at the U.S. Defense Acquisition University (DAU), can be seen in Figure 3 below.

Figure 3. The Vee Activity Diagram (Prosnik 2010). Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).

Application of the Vee Model

Lawson (Lawson 2010) elaborates on the activities in each life cycle stage and notes that it is useful to consider the structure of a generic life cycle stage model for any type of system-of-interest (SoI) as portrayed in Figure 4. This (T) model indicates that one or more definition stages precede a production stage(s) where the implementation (acquisition, provisioning, or development) of two or more system elements has been accomplished.

Figure 4. Generic (T) Stage Structure of System Life Cycle Models (Lawson 2010). Reprinted with permission of Harold Lawson. All other rights are reserved by the copyright owner.

Figure 5 shows the generic life cycle stages for a variety of stakeholders, from a standards organization (ISO/IEC) to commercial and government organizations. Although these stages differ in detail, they all have a similar sequential format that emphasizes the core activities as noted in Figure 2 (definition, production, and utilization/retirement).

Figure 5. Comparisons of Life Cycle Models (Forsberg, Mooz, and Cotterman 2005). Reprinted with permission of John Wiley & Sons. All other rights are reserved by the copyright owner.

It is important to note that many of the activities throughout the life cycle are iterated. This is an example of recursion (glossary)recursion (glossary) as discussed in the Part 3 Introduction.

Fundamentals of Life Cycle Stages and Program Management Phase

For this discussion, it is important to note that:

  • The term stagestage refers to the different states of a system during its life cycle; some stages may overlap in time, such as the utilization stage and the support stage. The term “stage” is used in ISO/IEC/IEEE 15288.
  • The term phase refers to the different steps of the program that support and manage the life of the system; the phases usually do not overlap. The term “phase” is used in many well-established models as an equivalent to the term “stage.”

Program managementProgram management employs phases, milestonesmilestones, and decision gatesdecision gates which are used to assess the evolution of a system through its various stages. The stages contain the activities performed to achieve goals and serve to control and manage the sequence of stages and the transitions between each stage. For each project, it is essential to define and publish the terms and related definitions used on respective projects to minimize confusion.

A typical programprogram is composed of the following phases:

  • The pre-study phase, which identifies potential opportunities to address user needs with new solutions that make business sense.
  • The feasibility phase consists of studying the feasibility of alternative concepts to reach a second decision gate before initiating the execution stage. During the feasibility phase, stakeholders' requirements and system requirements are identified, viable solutions are identified and studied, and virtual prototypes (glossary)prototypes (glossary) can be implemented. During this phase, the decision to move forward is based on:
    • whether a concept is feasible and is considered able to counter an identified threat or exploit an opportunity;
    • whether a concept is sufficiently mature to warrant continued development of a new product or line of products; and
    • whether to approve a proposal generated in response to a request for proposal.
  • The execution phase includes activities related to four stages of the system life cycle: development, production, utilization, and support. Typically, there are two decision gates and two milestones associated with execution activities. The first milestone provides the opportunity for management to review the plans for execution before giving the go-ahead. The second milestone provides the opportunity to review progress before the decision is made to initiate production. The decision gates during execution can be used to determine whether to produce the developed SoI and whether to improve it or retire it.

These program management views apply not only to the SoI, but also to its elements and structure.

Life Cycle Stages

Variations of the Vee model deal with the same general stages of a life cycle:

Additional information on each of these stages can be found in the sections below (see links to additional Part 3 articles above for further detail). It is important to note that these life cycle stages, and the activities in each stage, are supported by a set of systems engineering management processes.

Exploratory Research Stage

User requirements analysis and agreement is part of the exploratory research stage and is critical to the development of successful systems. Without proper understanding of the user needs, any system runs the risk of being built to solve the wrong problems. The first step in the exploratory research phase is to define the user (and stakeholder) requirements and constraints. A key part of this process is to establish the feasibility of meeting the user requirements, including technology readiness assessment. As with many SE activities this is often done iteratively, and stakeholder needs and requirements are revisited as new information becomes available.

A recent study by the National Research Council (National Research Council 2008) focused on reducing the development time for US Air Force projects. The report notes that, “simply stated, systems engineering is the translation of a user’s needs into a definition of a system and its architecture through an iterative process that results in an effective system design.” The iterative involvement with stakeholders is critical to the project success.

Except for the first and last decision gates of a project, the gates are performed simultaneously. See Figure 6 below.

Figure 6. Scheduling the Development Phases. (SEBoK Original)

Concept Stage

During the concept stage, alternate concepts are created to determine the best approach to meet stakeholder needs. By envisioning alternatives and creating models, including appropriate prototypes, stakeholder needs will be clarified and the driving issues highlighted. This may lead to an incremental or evolutionary approach to system development. Several different concepts may be explored in parallel.

Development Stage

The selected concept(s) identified in the concept stage are elaborated in detail down to the lowest level to produce the solution that meets the stakeholder requirementsstakeholder requirements. Throughout this stage, it is vital to continue with user involvement through in-process validation (the upward arrow on the Vee models). On hardware, this is done with frequent program reviews and a customer resident representative(s) (if appropriate). In agile development, the practice is to have the customer representative integrated into the development team.

Production Stage

The production stage is where the SoI is built or manufactured. Product modifications may be required to resolve production problems, to reduce production costs, or to enhance product or SoI capabilities. Any of these modifications may influence system requirements and may require system re-qualificationqualification, re-verificationverification, or re-validationvalidation. All such changes require SE assessment before changes are approved.

Utilization Stage

A significant aspect of product life cycle management is the provisioning of supporting systems which are vital in sustaining operation of the product. While the supplied product or service may be seen as the narrow system-of-interest (NSOI) for an acquireracquirer, the acquirer also must incorporate the supporting systems into a wider system-of-interest (WSOI). These supporting systems should be seen as system assets that, when needed, are activated in response to a situation that has emerged in respect to the operation of the NSOI. The collective name for the set of supporting systems is the integrated logistics support (ILS) system.

It is vital to have a holistic view when defining, producing, and operating system products and services. In Figure 7, the relationship between system design and development and the ILS requirements is portrayed.

Figure 7. Relating ILS to the System Life Cycle (Eichmueller and Foreman 2009). Reprinted with permission of of ASD/AIA S3000L Steering Committee. All other rights are reserved by the copyright owner.

The requirements for reliability, resulting in the need of maintainability and testability, are driving factors.

Support Stage

In the support stage, the SoI is provided services that enable continued operation. Modifications may be proposed to resolve supportability problems, to reduce operational costs, or to extend the life of a system. These changes require SE assessment to avoid loss of system capabilities while under operation. The corresponding technical process is the maintenance process.

Retirement Stage

In the retirement stage, the SoI and its related services are removed from operation. SE activities in this stage are primarily focused on ensuring that disposal requirements are satisfied. In fact, planning for disposal is part of the system definition during the concept stage. Experiences in the 20th century repeatedly demonstrated the consequences when system retirement and disposal was not considered from the outset. Early in the 21st century, many countries have changed their laws to hold the creator of a SoI accountable for proper end-of-life disposal of the system.

Life Cycle Reviews

To control the progress of a project, different types of reviews are planned. The most commonly used are listed as follows, although the names are not universal:

  • The system requirements review (SRR) is planned to verify and validate the set of system requirements before starting the detailed design activities.
  • The preliminary design reviewpreliminary design review (PDR) is planned to verify and validate the set of system requirements, the design artifacts, and justification elements at the end of the first engineering loop (also known as the "design-to" gate).
  • The critical design reviewcritical design review (CDR) is planned to verify and validate the set of system requirements, the design artifacts, and justification elements at the end of the last engineering loop (the “build-to” and “code-to” designs are released after this review).
  • The integrationintegration, verificationverification, and validationvalidation reviews are planned as the components are assembled into higher level subsystems and elements. A sequence of reviews is held to ensure that everything integrates properly and that there is objective evidence that all requirements have been met. There should also be an in-process validation that the system, as it is evolving, will meet the stakeholders’ requirements (see Figure 7).
  • The final validation review is carried out at the end of the integration phase.
  • Other management related reviews can be planned and conducted in order to control the correct progress of work, based on the type of system and the associated risks.
Figure 8. Right Side of the Vee Model (Forsberg, Mooz, and Cotterman 2005). Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.

References

Works Cited

Eichmueller, P. and B. Foreman. 2010. S3000LTM. Brussels, Belgium: Aerospace and Defence Industries Association of Europe (ASD)/Aerospace Industries Association (AIA).

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.

Forsberg, K., H. Mooz, and H. Cotterman. 2005. Visualizing Project Management, 3rd ed. New York, NY, USA: J. Wiley & Sons.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.

Primary References

Beedle, M., et al. 2009. "The Agile Manifesto: Principles behind the Agile Manifesto". in The Agile Manifesto [database online]. Accessed December 04 2014 at www.agilemanifesto.org/principles.html

Boehm, B. and R. Turner. 2004. Balancing Agility and Discipline. New York, NY, USA: Addison-Wesley.

Fairley, R. 2009. Managing and Leading Software Projects. New York, NY, USA: J. Wiley & Sons.

Forsberg, K., H. Mooz, and H. Cotterman. 2005. Visualizing Project Management. 3rd ed. New York, NY, USA: J. Wiley & Sons.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. A Journey Through the Systems Landscape. Kings College, UK: College Publications.

Pew, R., and A. Mavor (eds.) 2007. Human-System Integration in the System Development Process: A New Look. Washington, DC, USA: The National Academies Press.

Royce, W.E. 1998. Software Project Management: A Unified Framework. New York, NY, USA: Addison Wesley.

Additional References

Anderson, D. 2010. Kanban. Sequim, WA, USA: Blue Hole Press.

Baldwin, C. and K. Clark. 2000. Design Rules: The Power of Modularity. Cambridge, MA, USA: MIT Press.

Beck, K. 1999. Extreme Programming Explained. New York, NY, USA: Addison Wesley.

Beedle, M., et al. 2009. "The Agile Manifesto: Principles behind the Agile Manifesto". in The Agile Manifesto [database online]. Accessed 2010. Available at: www.agilemanifesto.org/principles.html

Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, and P. Gruenbacher (eds.). 2005. Value-Based Software Engineering. New York, NY, USA: Springer.

Boehm, B. 1988. “A Spiral Model of Software Development.” IEEE Computer 21(5): 61-72.

Boehm, B. 2006. “Some Future Trends and Implications for Systems and Software Engineering Processes.” Systems Engineering. 9(1): 1-19.

Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy. 1998. “Using the WinWin Spiral Model: A Case Study.” IEEE Computer. 31(7): 33-44.

Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (in press). Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model. Boston, MA, USA: Addison Wesley.

Castellano, D.R. 2004. “Top Five Quality Software Projects.” CrossTalk. 17(7) (July 2004): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf

Checkland, P. 1981. Systems Thinking, Systems Practice. New York, NY, USA: Wiley.

Crosson, S. and B. Boehm. 2009. “Adjusting Software Life cycle Anchorpoints: Lessons Learned in a System of Systems Context.” Proceedings of the Systems and Software Technology Conference, 20-23 April 2009, Salt Lake City, UT, USA.

Dingsoyr, T., T. Dyba. and N. Moe (eds.). 2010. "Agile Software Development: Current Research and Future Directions.” Chapter in B. Boehm, J. Lane, S. Koolmanjwong, and R. Turner, Architected Agile Solutions for Software-Reliant Systems. New York, NY, USA: Springer.

Dorner, D. 1996. The Logic of Failure. New York, NY, USA: Basic Books.

Forsberg, K. 1995. "'If I Could Do That, Then I Could…' System Engineering in a Research and Development Environment.” Proceedings of the Fifth Annual International Council on Systems Engineering (INCOSE) International Symposium. 22-26 July 1995. St. Louis, MO, USA.

Forsberg, K. 2010. “Projects Don’t Begin With Requirements.” Proceedings of the IEEE Systems Conference, 5-8 April 2010, San Diego, CA, USA.

Gilb, T. 2005. Competitive Engineering. Maryland Heights, MO, USA: Elsevier Butterworth Heinemann.

Goldratt, E. 1984. The Goal. Great Barrington, MA, USA: North River Press.

Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. New York, NY, USA: Wiley.

Holland, J. 1998. Emergence. New York, NY, USA: Perseus Books.

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.

ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

ISO/IEC. 2003. Systems Engineering — A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).

Jarzombek, J. 2003. “Top Five Quality Software Projects.” CrossTalk. 16(7) (July 2003): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.

Kruchten, P. 1999. The Rational Unified Process. New York, NY, USA: Addison Wesley.

Landis, T. R. 2010. Lockheed Blackbird Family (A-12, YF-12, D-21/M-21 & SR-71). North Branch, MN, USA: Specialty Press.

Madachy, R. 2008. Software Process Dynamics. Hoboken, NJ, USA: Wiley.

Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. “Architecture Reviews: Practice and Experience.” IEEE Software. 22(2): 34-43.

National Research Council of the National Academies (USA). 2008. Pre-Milestone A and Early-Phase Systems Engineering. Washington, DC, USA: The National Academies Press.

Osterweil, L. 1987. “Software Processes are Software Too.” Proceedings of the SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.

Poppendeick, M. and T. Poppendeick. 2003. Lean Software Development: an Agile Toolkit. New York, NY, USA: Addison Wesley.

Rechtin, E. 1991. System Architecting: Creating and Building Complex Systems. Upper Saddle River, NY, USA: Prentice-Hall.

Rechtin, E., and M. Maier. 1997. The Art of System Architecting. Boca Raton, FL, USA: CRC Press.

Schwaber, K. and M. Beedle. 2002. Agile Software Development with Scrum. Upper Saddle River, NY, USA: Prentice Hall.

Spruill, N. 2002. “Top Five Quality Software Projects.” CrossTalk. 15(1) (January 2002): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2002/200201/200201-0-Issue.pdf.

Stauder, T. 2005. “Top Five Department of Defense Program Awards.” CrossTalk. 18(9) (September 2005): 4-13. Available at http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.

Warfield, J. 1976. Societal Systems: Planning, Policy, and Complexity. New York, NY, USA: Wiley.

Womack, J. and D. Jones. 1996. Lean Thinking. New York, NY, USA: Simon and Schuster.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.0, released 1 June 2019