Difference between revisions of "System Lifecycle Process Models: Vee"

From SEBoK
Jump to navigation Jump to search
Line 1: Line 1:
−
There are a large number of life cycle process models in which systems engineering may operate. For the most part, these models fall into three major categories:
+
There are a large number of life cycle process models. These models fall into three major categories:
  
 
#Primarily Prespecified and Sequential Processes.   
 
#Primarily Prespecified and Sequential Processes.   
Line 5: Line 5:
 
#Primarily Interpersonal and Unconstrained Processes. Examples are Agile development, Scrum, eXtreme Programming, Dynamic System Development Method, and innovation-based processes.
 
#Primarily Interpersonal and Unconstrained Processes. Examples are Agile development, Scrum, eXtreme Programming, Dynamic System Development Method, and innovation-based processes.
  
−
There are considerable gray areas among the categories.  Versions of the Vee model show concurrent system development, verification, and validation activities, although the language and tables describing the Vee model below generally assign activities to stages more exclusively and sequentially.  The ICSM has a prespecified approach for developing increments, while destabilizing change traffic is routed to a concurrent agile rebaselining team as in Figure 2.  Organizations have found ways to scale up agile methods to projects of up to 100 people using a Scrum of Scrums approach within and overall architecture.  Furthermore, very large systems and systems of systems will generally find it best to apply all three process categories to portions of their systems and their life cycles.
+
This article discusses the Vee model as the primary example of the first category.  The second two are discussed in the article [[System Life Cycle Process Models: Iterative]].   
  
  
 
==A Primarily Prespecified and Sequential Process Model: The Vee Model==
 
==A Primarily Prespecified and Sequential Process Model: The Vee Model==
  
−
The sequential version of the Vee model is shown in Figure 3.  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, and continuous in-process validation.
+
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, and continuous in-process validation.
 
   
 
   
 
[[File:KF_VeeModel_Left.png|500px|Left side of the Vee model (Forsberg, Mooz, and Cotterman 2005. Pg 111)]]
 
[[File:KF_VeeModel_Left.png|500px|Left side of the Vee model (Forsberg, Mooz, and Cotterman 2005. Pg 111)]]
  
−
Figure 3 – Left side of the sequential Vee model (Forsberg, Mooz, and Cotterman 2005. Pg 111)
+
Figure 1 – Left side of the sequential Vee model (Forsberg, Mooz, and Cotterman 2005. Pg 111)
  
  
  
−
The Vee model endorses the INCOSE Systems Engineering Handbook 2011 definition of life cycle stages and their purposes or activities, as shown in Table 3.  
+
The Vee model endorses the INCOSE Systems Engineering Handbook 2011 definition of life cycle stages and their purposes or activities, as shown in Table 1.  
  
 
[[File:Generic_life_cycle_stages,_their_purposes,_and_decision_gate_options.PNG|650px|Generic life cycle stages, their purposes, and decision gate options(INCOSE Systems Engineering Handbook 2011, p 25; also ISO/IEC 15288:2008)]]
 
[[File:Generic_life_cycle_stages,_their_purposes,_and_decision_gate_options.PNG|650px|Generic life cycle stages, their purposes, and decision gate options(INCOSE Systems Engineering Handbook 2011, p 25; also ISO/IEC 15288:2008)]]
  
−
Table 3 - Generic life cycle stages, their purposes, and decision gate options
+
Table 1 - Generic life cycle stages, their purposes, and decision gate options
 
(INCOSE Systems Engineering Handbook 2011, p 25; also ISO/IEC 15288:2008)
 
(INCOSE Systems Engineering Handbook 2011, p 25; also ISO/IEC 15288:2008)
  
Line 30: Line 30:
 
[[File:KF_GenericStageStructure.png|600px|Generic (T) Stage Structure of System Life Cycle Models]]
 
[[File:KF_GenericStageStructure.png|600px|Generic (T) Stage Structure of System Life Cycle Models]]
 
   
 
   
−
Figure 4 - Generic (T) Stage Structure of System Life Cycle Models
+
Figure 2 - Generic (T) Stage Structure of System Life Cycle Models
 
(Lawson 2010, Figures 6-2 to 6-5)
 
(Lawson 2010, Figures 6-2 to 6-5)
  
−
The generic life cycle stages for a variety of different organizations, from standards (ISO/IEC) to commercial to government, are shown in Figure 5.  Note that although different in detail, all have a similar sequential format that emphasizes the core activities as noted in Figure 4.   
+
The generic life cycle stages for a variety of different organizations, from standards (ISO/IEC) to commercial to government, are shown in Figure 3.  Note that although different in detail, all have a similar sequential format that emphasizes the core activities as noted in Figure 2.   
  
 
[[File:Comparisons_of_life_cycle_models.PNG|600px|Comparisons of life cycle models (Forsberg, Mooz, and Cotterman 2005, p 87 updated)]]
 
[[File:Comparisons_of_life_cycle_models.PNG|600px|Comparisons of life cycle models (Forsberg, Mooz, and Cotterman 2005, p 87 updated)]]
  
−
Figure 5 - Comparisons of life cycle models (Forsberg, Mooz, and Cotterman 2005, p. 87 updated)
+
Figure 3 - Comparisons of life cycle models (Forsberg, Mooz, and Cotterman 2005, p. 87 updated)
  
 
===Fundamentals of Life Cycle Stages and Program Management Phase===
 
===Fundamentals of Life Cycle Stages and Program Management Phase===
Line 48: Line 48:
 
Program management employs phases, milestones, and decision gates during which the stages of the system evolve.  The stages contain the activities performed to achieve their goals; the phases serve to the control and the management of the sequence of stages and the transitions from one stage to the others.  For each project it is essential that the team define and publish the terms and related definitions used on their project to minimize confusion.
 
Program management employs phases, milestones, and decision gates during which the stages of the system evolve.  The stages contain the activities performed to achieve their goals; the phases serve to the control and the management of the sequence of stages and the transitions from one stage to the others.  For each project it is essential that the team define and publish the terms and related definitions used on their project to minimize confusion.
  
−
As an example, Figure 6 shows a typical program management sequence.    This classical program is composed of the following phases:
+
As an example, Figure 4 shows a typical program management sequence.    This classical program is composed of the following phases:
  
 
* '''The pre-study phase'''  
 
* '''The pre-study phase'''  
Line 64: Line 64:
 
[[File:KF_ProgramManagement&EngineeringViews.png|600px|Program Management and Engineering Views of the System Life Cycle]]  
 
[[File:KF_ProgramManagement&EngineeringViews.png|600px|Program Management and Engineering Views of the System Life Cycle]]  
 
   
 
   
−
Figure 6 - Program Management and Engineering Views of the sequential System Life Cycle
+
Figure 4 - Program Management and Engineering Views of the sequential System Life Cycle
 
(ISO/IEC 19760:2003)
 
(ISO/IEC 19760:2003)
  
Line 74: Line 74:
 
A key part of this process is to establish the feasibility of meeting the user requirements.   
 
A key part of this process is to establish the feasibility of meeting the user requirements.   
  
−
Except for the first and last Decision Gates of a project, the two Gates are performed simultaneously.  See Figure 9.
+
Except for the first and last Decision Gates of a project, the two Gates are performed simultaneously.  See Figure 5.
 
   
 
   
 
[[File:KF_SchedulingDevelopment.png|600px|Scheduling the Development Phases]]
 
[[File:KF_SchedulingDevelopment.png|600px|Scheduling the Development Phases]]
  
−
Figure 9 - Scheduling the Development Phases (Faisandier 2010)
+
Figure 5 - Scheduling the Development Phases (Faisandier 2010)
  
 
====Reviews====
 
====Reviews====
Line 94: Line 94:
 
[[File:KF_VeeModel_Right.png|600px|Right side of the Vee Model ]]
 
[[File:KF_VeeModel_Right.png|600px|Right side of the Vee Model ]]
 
   
 
   
−
Figure 10 - Right side of the Vee Model (Forsberg, Mooz, and Cotterman 2005, Pg. 115)
+
Figure 6 - Right side of the Vee Model (Forsberg, Mooz, and Cotterman 2005, Pg. 115)
  
 
===Production Stage===
 
===Production Stage===
Line 102: Line 102:
 
===Utilization Stage===
 
===Utilization Stage===
  
−
A significant aspect of Product Life Cycle Management is the provisioning of supporting systems that are vital in sustaining operation of the product.  While the supplied product or service may be seen as the NSOI (Narrow System of Interest) for an acquirer, the acquirer also must incorporate the supporting systems into a WSOI (Wider System of Interest).  These supporting systems should be seen as system assets that when needed are activated in responding to some situation that has arisen in respect to operation of the NSOI.  The collective name for the set of supporting systems is the Integrated Logistics Support (ILS) System.  Some typical types of ILS supporting systems are indicated in Figure 11.
+
A significant aspect of Product Life Cycle Management is the provisioning of supporting systems that are vital in sustaining operation of the product.  While the supplied product or service may be seen as the NSOI (Narrow System of Interest) for an acquirer, the acquirer also must incorporate the supporting systems into a WSOI (Wider System of Interest).  These supporting systems should be seen as system assets that when needed are activated in responding to some situation that has arisen in respect to operation of the NSOI.  The collective name for the set of supporting systems is the Integrated Logistics Support (ILS) System.  Some typical types of ILS supporting systems are indicated in Figure 7.
  
 
The ILS portrayed in the figure identifies several typical elements of this ILS system.  The elements are system assets for a supplying enterprise that are instantiated and put into operation in responding to logistics related situations.
 
The ILS portrayed in the figure identifies several typical elements of this ILS system.  The elements are system assets for a supplying enterprise that are instantiated and put into operation in responding to logistics related situations.
  
−
As has been emphasized several times earlier, it is vital to have a holistic view when defining, producing and operating system products and services. T In Figure 11 the relationship between system design and development and the ILS requirements is portrayed.
+
As has been emphasized several times earlier, 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.
  
 
[[File:Typical_Integrated_Logistics_Support_(ILS)_Supporting_Systems.PNG|600px|Typical Integrated Logistics Support (ILS) Supporting Systems (Blanchard 2004)]]
 
[[File:Typical_Integrated_Logistics_Support_(ILS)_Supporting_Systems.PNG|600px|Typical Integrated Logistics Support (ILS) Supporting Systems (Blanchard 2004)]]
  
−
Figure 11 - Typical Integrated Logistics Support (ILS) Supporting Systems (Blanchard 2004)
+
Figure 7 - Typical Integrated Logistics Support (ILS) Supporting Systems (Blanchard 2004)
  
 
[[File:KF_ILSSystemLifeCycle.png|600px|Relating ILS to the System Life Cycle]]
 
[[File:KF_ILSSystemLifeCycle.png|600px|Relating ILS to the System Life Cycle]]
 
   
 
   
−
Figure 12 - Relating ILS to the System Life Cycle  (ASD-STAN, Fig 1, 2009 Products and Services S3000L, www.asd-stn.org.)
+
Figure 8 - Relating ILS to the System Life Cycle  (ASD-STAN, Fig 1, 2009 Products and Services S3000L, www.asd-stn.org.)
  
 
The requirements for reliability resulting in the need of maintainability and testability are driving factors.   
 
The requirements for reliability resulting in the need of maintainability and testability are driving factors.   

Revision as of 14:10, 31 August 2011

There are a large number of life cycle process models. These models fall into three major categories:

  1. Primarily Prespecified and Sequential Processes.
  2. Primarily Evolutionary and Concurrent Processes. Examples are the Rational Unified Process and various forms of the Vee and spiral models.
  3. Primarily Interpersonal and Unconstrained Processes. Examples are Agile development, Scrum, eXtreme Programming, Dynamic System Development Method, and innovation-based processes.

This article discusses the Vee model as the primary example of the first category. The second two are discussed in the article System Life Cycle Process Models: Iterative.


A Primarily Prespecified 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, and continuous in-process validation.

Left side of the Vee model (Forsberg, Mooz, and Cotterman 2005. Pg 111)

Figure 1 – Left side of the sequential Vee model (Forsberg, Mooz, and Cotterman 2005. Pg 111)


The Vee model endorses the INCOSE Systems Engineering Handbook 2011 definition of life cycle stages and their purposes or activities, as shown in Table 1.

Generic life cycle stages, their purposes, and decision gate options(INCOSE Systems Engineering Handbook 2011, p 25; also ISO/IEC 15288:2008)

Table 1 - Generic life cycle stages, their purposes, and decision gate options (INCOSE Systems Engineering Handbook 2011, p 25; also ISO/IEC 15288:2008)

Application of the Vee Model

Generic (T) Stage Structure of System Life Cycle Models

Figure 2 - Generic (T) Stage Structure of System Life Cycle Models (Lawson 2010, Figures 6-2 to 6-5)

The generic life cycle stages for a variety of different organizations, from standards (ISO/IEC) to commercial to government, are shown in Figure 3. Note that although different in detail, all have a similar sequential format that emphasizes the core activities as noted in Figure 2.

Comparisons of life cycle models (Forsberg, Mooz, and Cotterman 2005, p 87 updated)

Figure 3 - Comparisons of life cycle models (Forsberg, Mooz, and Cotterman 2005, p. 87 updated)

Fundamentals of Life Cycle Stages and Program Management Phase

The notion of life cycle is related to the notion of program management that was presented in the previous section. Note that:

  • The term "stage" refers to the different states of the 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 15288.
  • The term "phase" refers to the different steps of the program that supports and manages the life of the system; the phases usually do not overlap. The term “Phase” is used in many well-established models as equivalent to “Stage.”

Program management employs phases, milestones, and decision gates during which the stages of the system evolve. The stages contain the activities performed to achieve their goals; the phases serve to the control and the management of the sequence of stages and the transitions from one stage to the others. For each project it is essential that the team define and publish the terms and related definitions used on their project to minimize confusion.

As an example, Figure 4 shows a typical program management sequence. This classical program is composed of the following phases:

  • The pre-study phase
  • The feasibility phase - This phase consists of studying the feasibility of alternative concepts to reach a second decision gate before initiating the execution stage. It is the “go-ahead decision” 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.
    • Whether to approve a proposal generated in response to an RFP (Request for Proposal).

During the feasibility phase stakeholders' requirements and system requirements are identified, viable solutions are designed and studied, virtual prototypes are engineered and can be implemented.

  • The execution phase – This phase includes activities related to four stages of the system: 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 system-of-interest and whether to improve it or retire it.

These Program Management views apply not only to the system-of-interest but also to its elements and structure.

Program Management and Engineering Views of the System Life Cycle

Figure 4 - Program Management and Engineering Views of the sequential System Life Cycle (ISO/IEC 19760:2003)

Life Cycle Stages

Exploratory Research Stage

The most important phase in the project cycle is the User Requirements Analysis and Agreement phase, which is part of the Exploratory Research Stage. First, define the user (and stakeholder) requirements and constraints.

A key part of this process is to establish the feasibility of meeting the user requirements.

Except for the first and last Decision Gates of a project, the two Gates are performed simultaneously. See Figure 5.

Scheduling the Development Phases

Figure 5 - Scheduling the Development Phases (Faisandier 2010)

Reviews

To control the progress of a project different types of Reviews are planned. The most commonly used are listed below but the names are not universal:

  • System Requirements Review - SRR is planned to verify and validate the set of system requirements before starting the detailed design activities.
  • 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. This review is sometimes called the “Design-to” gate.
  • 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” design is released after this review.
  • Integration, Verification, and Validation (IV&V) (glossary) Reviews – As the components are assembled into higher level subsystems and elements, a sequence of reviews are held to ensure that everything integrates properly and that there is objective evidence that all requirements have been met (I&V). There should also be an in-process validation that the system, as it is evolving, will meet the Stakeholders’ Requirements (see Figure 10).
  • Final Validation Review – FVR is carried out at the end of the integration phase.
  • Other Project Reviews related to management can be planned in order to control the correct progress of work, based on the type of system and associated risks.


Right side of the Vee Model

Figure 6 - Right side of the Vee Model (Forsberg, Mooz, and Cotterman 2005, Pg. 115)

Production Stage

The Production Stage is where the system-of-interest is produced or manufactured. Product modifications may be required to resolve production problems, to reduce production costs, or to enhance product or system-of-interest capabilities. Any of these may influence system requirements and may require system re-qualification, re-verification, or re-validation. 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 that are vital in sustaining operation of the product. While the supplied product or service may be seen as the NSOI (Narrow System of Interest) for an acquirer, the acquirer also must incorporate the supporting systems into a WSOI (Wider System of Interest). These supporting systems should be seen as system assets that when needed are activated in responding to some situation that has arisen in respect to operation of the NSOI. The collective name for the set of supporting systems is the Integrated Logistics Support (ILS) System. Some typical types of ILS supporting systems are indicated in Figure 7.

The ILS portrayed in the figure identifies several typical elements of this ILS system. The elements are system assets for a supplying enterprise that are instantiated and put into operation in responding to logistics related situations.

As has been emphasized several times earlier, 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.

Typical Integrated Logistics Support (ILS) Supporting Systems (Blanchard 2004)

Figure 7 - Typical Integrated Logistics Support (ILS) Supporting Systems (Blanchard 2004)

Relating ILS to the System Life Cycle

Figure 8 - Relating ILS to the System Life Cycle (ASD-STAN, Fig 1, 2009 Products and Services S3000L, www.asd-stn.org.)

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

Support Stage

In the Support Stage the system-of-interest 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 system-of-interest 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. Experience in the 20th century repeatedly demonstrated the consequences when system retirement and disposal are not considered from the outset. Early in the 21st century, many countries have changed their laws to hold the creator of a system-of-interest accountable for proper end-of-life disposal of the system.

References

Citations

Aerospace and Defense Indistries of Europe (ASD). 2009. ASD-STAN, Products and Services S3000L. www.asd-stan.org

Boehm, B., May 1988. “A Spiral Model of Software Development,” Computer, pp. 61-72.

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

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

Boehm, B., and J. Lane, October 2007. “Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering,” CrossTalk, pp. 4-9.

Boehm, B., and R. Turner. 2004. Balancing Agility and Discipline, Addison-Wesley.

Boehm, B., J. Lane, S. Koolmanjwong, and R, Turner. 2012 (planned publication date). Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model. Addison Wesley

CrossTalk, January 2002, July 2003, July 2004, September 2005. “Top Five Quality Software Projects,” www.stsc.hill.af.mil/crosstalk

Crosson, S., and B. Boehm, April 2009. “Adjusting Software Life cycle Anchorpoints: Lessons Learned in a System of Systems Context,” Proceedings, SSTC 2009.

Cusumano, M. and R. Selby, 1996. Microsoft Secrets. Harper Collins.

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

Fairley, R. 2009. Managing and Leading Software Projects. J. Wiley & Sons.

Faisandier, A. 2011.Engineering and Architecting Multidisciplinary Systems (to be published)..

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management. 3rd Ed., J. Wiley & Sons.

Forsberg, K. 1995. “’If I Could Do That, Then I Could…’ System Engineering in a Research and Development Environment,” Proceedings of Fifth NCOSE Summer Symposium.

Forsberg, K. 2010. “Projects Don’t Begin With Requirements.” IEEE Systems Conf. San Diego, CA. April.

INCOSE. 2011. Systems Engineering Handbook, version 3.2.1. INCOSE-TP-2003-002-03.2.1.

ISO/IEC 15288:2008. Systems and software engineering – System life cycle processes.

ISO/IEC 19760:2003. A guide for application of ISO/IEC 15288 System Life Cycle Processes.

ISO/IEC 24748-1:2010. Systems and software engineering, Part 1: Guide for life cycle management

Kruchten, P., 1999. The Rational Unified Process. Addison Wesley.

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

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

Maranzano, J., et al., March/April 2005, “Architecture reviews: Practice and experience,” IEEE Software, pp. 34-43.

National Research Council of the National Academies (USA). 2008. Pre-Milestone A and Early-Phase Systems Engineering, Washington, D.C.: The National Academies Press. http://www.nap.edu

Pew, R., and A. Mavor (eds.) 2007. Human-System Integration in the System Development Process: A New Look, The National Academies Press. http://www.nap.edu

“Principles behind the Agile Manifesto,” 15 Dec 2009, http://www.agilemanifesto.org/principles.html

Rechtin, E. 1991. System Architecting.: Creating and Building Complex Systems. Prentice-Hall.

Royce, W. E. 1998. Software Project Management. Addison Wesley.

Washington Post, February 11, 2009, “NASA’s Ambitious New Mars Rover Is Too Costly, Critics Say.”

Wikipedia, 15 Aug 2011. http://en.wikipedia.org/wiki/James_Webb_Space_Telescope.

Primary References

Boehm, B., J. Lane, S. Koolmanojwong, and R, Turner. 2012 (planned publication date). Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model. Addison Wesley.

Boehm, B., and R. Turner. 2004. Balancing Agility and Discipline, Addison-Wesley.

Fairley, R. 2009. Managing and Leading Software Projects. J. Wiley & Sons.

Forsberg, K., H. Mooz, H. Cotterman. 2005.Visualizing Project Management. 3rd Ed., J. Wiley & Sons.

Faisandier, A. 2011. Engineering and Architecting Multidisciplinary Systems (to be published).

INCOSE. 2011. Systems Engineering Handbook, version 3.2.1. INCOSE-TP-2003-002-03.2.1.

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

Pew, R., and A. Mavor (eds.) 2007. Human-System Integration in the System Development Process: A New Look. The National Academies Press. http://www.nap.edu

Additional References

Anderson, D., 2010. Kanban, Blue Hole Press.

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

Beck, K., 1999. Extreme Programming Explained, Addison Wesley.

Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, P. Gruenbacher (eds.), 2005. Value-Based Software Engineering, Springer.

Boehm, B., May 1988. “A Spiral Model of Software Development,” Computer, pp. 61-72.

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

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

Boehm, B., and J. Lane, October 2007. “Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering,” CrossTalk, pp. 4-9.

Checkland, P., 1981. Systems Thinking, Systems Practice, Wiley.

CrossTalk, January 2002, July 2003, July 2004, September 2005. “Top Five Quality Software Projects,” www.stsc.hill.af.mil/crosstalk

Crosson, S., and B. Boehm, April 2009. “Adjusting Software Life cycle Anchorpoints: Lessons Learned in a System of Systems Context,” Proceedings, SSTC 2009.

Cusumano, M. and R. Selby, 1996. Microsoft Secrets. Harper Collins.

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

Dorner, D., 1996. The Logic of Failure, Basic Books.

Forsberg, K. 1995. “’If I Could Do That, Then I Could…’ System Engineering in a Research and Development Environment,” Proceedings of Fifth NCOSE Summer Symposium.

Forsberg, K. 2010. “Projects Don’t Begin With Requirements.” IEEE Systems Conf. San Diego, CA. April.

Gilb, T., 2005. Competitive Engineering, Elsevier Butterworth Heinemann.

Goldratt, E., 1984. The Goal, North River Press.

Hitchins, D., 2007. Systems Engineering: A 21st Century Systems Methodology, Wiley.

Holland, J., 1998. Emergence, Perseus Books.

ISO/IEC 15288:2008. Systems and software engineering – System life cycle processes.

ISO/IEC 19760:2003. A guide for application of ISO/IEC 15288 System Life Cycle Processes.

ISO/IEC 24748-1:2010. Systems and software engineering, Part 1: Guide for life cycle management

Kruchten, P., 1999. The Rational Unified Process. Addison Wesley.

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

Madachy, R., 2008. Software Process Dynamics, Wiley.

Maranzano, J., et al., March/April 2005, “Architecture reviews: Practice and experience,” IEEE Software, pp. 34-43.

National Research Council of the National Academies (USA). 2008. Pre-Milestone A and Early-Phase Systems Engineering, Washington, D.C.: The National Academies Press. http://www.nap.edu

Osterweil, L. 1987. “Software Processes are Software Too,” Proceedings, ICSE 9.

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

“Principles behind the Agile Manifesto,” 15 Dec 2009, http://www.agilemanifesto.org/principles.html

Rechtin, E. 1991. System Architecting.: Creating and Building Complex Systems. Prentice-Hall.

Rechtin, E., and M. Maier, 1997. The Art of System Architecting.

Royce, W. E. 1998. Software Project Management. Addison Wesley.

Schwaber, K. and M. Beedle, 2002. Agile Software Development with Scrum, Prentice Hall.

Warfield, J., 1976. Societal Systems: Planning, Policy, and Complexity, Wiley.

Womack, J., and D. Jones, 1996. Lean Thinking, Simon and Schuster.


Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->

Signatures

Retrieved from "https://sandbox.sebokwiki.org/index.php?title=System_Lifecycle_Process_Models:_Vee&oldid=14090"