Difference between revisions of "Applying the Systems Approach"

From SEBoK
Jump to navigation Jump to search
m (Protected "Applying the Systems Approach": Protecting for publication. ([edit=sysop] (indefinite) [move=sysop] (indefinite)))
Line 1: Line 1:
The [[Systems Approach]] is described in the SEBoK primarily through five groups of activities which describe the application of [[Systems Thinking (glossary)|systems thinking (glossary)]] to an [[Engineered System (glossary)|engineered system (glossary)]] throughout the life of that system. This article describes how the systems approach relates to both the dynamics of problem resolution and stakeholder value over time, as well as to the levels of system relationship, detailed management, and engineering activities this implies.
+
The [[Systems Approach]] is described in the SEBoK primarily through five groups of activities which describe the application of [[Systems Thinking (glossary)|systems thinking (glossary)]] to an [[Engineered System (glossary)|engineered system (glossary)]] throughout the life of that system. This article describes how the systems approach relates to both the dynamics of problem resolution and stakeholder value over time, as well as to the levels of system relationship, detailed management, and the engineering activities this implies.
  
 
==Activity Mapping==
 
==Activity Mapping==
  
The [[Systems Approach]] activities are directly related to the high level technical processes defined in Part 3 [[Systems Engineering and Management]] of the SEBOK.
+
The [[Systems Approach]] activities are directly related to the high level technical processes defined in Part 3, [[Systems Engineering and Management]], of the SEBOK.
 
*[[Identifying and Understanding Problems and Opportunities]] relates to [[Concept Definition]].
 
*[[Identifying and Understanding Problems and Opportunities]] relates to [[Concept Definition]].
 
*[[Synthesizing Possible Solutions]] and [[Analysis and Selection between Alternative Solutions]] relate to [[System Definition]].
 
*[[Synthesizing Possible Solutions]] and [[Analysis and Selection between Alternative Solutions]] relate to [[System Definition]].
Line 9: Line 9:
 
*[[Deploying, Using, and Sustaining Systems to Solve Problems]] relates to [[Product and Service Life Management]].
 
*[[Deploying, Using, and Sustaining Systems to Solve Problems]] relates to [[Product and Service Life Management]].
  
The principles defined in each of the Systems Approach activities and how they help shape the technical processes in each of these areas are discussed in Part 3.
+
The principles defined in each of the systems approach activities and how they help shape the technical processes in each of these areas are discussed in Part 3.
  
 
==Application Principles==
 
==Application Principles==
Line 17: Line 17:
 
Normally, the activities of the systems approach should be applied [[Concurrent (glossary)|concurrently (glossary)]], reflecting their interrelationships and dependencies. Ring (1998) defines a system value cycle with three levels that a systems approach must consider to deliver real world benefit. These three levels are stakeholder value, system problem situation (or purpose), and system solution (or intervention). Value will only be fully realized when it is considered within the context of time, cost, and other resource issues appropriate to key stakeholders. A developer must consider not only what to do, but when and how much to do in order to provide real value (Senge 1990).
 
Normally, the activities of the systems approach should be applied [[Concurrent (glossary)|concurrently (glossary)]], reflecting their interrelationships and dependencies. Ring (1998) defines a system value cycle with three levels that a systems approach must consider to deliver real world benefit. These three levels are stakeholder value, system problem situation (or purpose), and system solution (or intervention). Value will only be fully realized when it is considered within the context of time, cost, and other resource issues appropriate to key stakeholders. A developer must consider not only what to do, but when and how much to do in order to provide real value (Senge 1990).
  
Greater understanding of the value that an engineered system is to offer enables more effective application of the systems approach, which in turn enables the problem situation to be agreed to and appropriate system interventions to be created, deployed, and used (Ring 1998). All of these activities happen concurrently. Efficient application of the systems approach requires awareness of constrained time and funding resources to realize desired value. In systems engineering (SE) and management practices this leads to the creation of (INCOSE 2011):  
+
A greater understanding of the value that an engineered system is to offer enables more effective application of the systems approach, which in turn enables the problem situation to be agreed to and appropriate system interventions to be created, deployed, and used (Ring 1998). All of these activities happen concurrently. Efficient application of the systems approach requires awareness of constrained time and funding resources to realize the desired value. In systems engineering (SE) and management practices this leads to the creation of the following (INCOSE 2011):
  
*[[Life Cycle (glossary)|Life Cycles (glossary)]]: stakeholder value and problem resolution described as a set of [[Stage (glossary)|life cycle stages (glossary)]] over which problems can be explored and resolved, and resources can be managed.  
+
*[[Life Cycle (glossary)|Life Cycles (glossary)]]: Stakeholder value and problem resolution described as a set of [[Stage (glossary)|life cycle stages (glossary)]] over which problems can be explored and resolved, and resources can be managed.  
*[[Process (glossary)|Life Cycle Processes (glossary)]]: systems of activities focused on creation and sharing of knowledge associated with the systems approach, which can be employed to promote a [[holism (glossary)|holistic (glossary)]] approach over a life cycle.
+
*[[Process (glossary)|Life Cycle Processes (glossary)]]: Systems of activities focused on creation and sharing of knowledge associated with the systems approach, which can be employed to promote a [[holism (glossary)|holistic (glossary)]] approach over a life cycle.
  
 
For the generic systems approach, the following fundamental principles apply:  
 
For the generic systems approach, the following fundamental principles apply:  
Line 27: Line 27:
 
#Life cycle processes define a system of engineering and management activities based on the detailed information needed to ensure a systems approach across a life cycle (e.g., requirements, architecture, verification, and validation).   
 
#Life cycle processes define a system of engineering and management activities based on the detailed information needed to ensure a systems approach across a life cycle (e.g., requirements, architecture, verification, and validation).   
 
#Activities in any of the processes may be employed in all of the stages to allow for appropriate concurrency.
 
#Activities in any of the processes may be employed in all of the stages to allow for appropriate concurrency.
#The sequence and control of the life cycle stages and concurrent process activities must be [[Tailoring (glossary)|tailored (glossary)]] to the problem situation and commerical environment (Lawson 2010), thus leading to the selection of an appropriate [[Life Cycle Model (glossary)|life cycle model (glossary)]].
+
#The sequence and control of the life cycle stages and concurrent process activities must be [[Tailoring (glossary)|tailored (glossary)]] to the problem situation and commercial environment (Lawson 2010), thus leading to the selection of an appropriate [[Life Cycle Model (glossary)|life cycle model (glossary)]].
 
#Appropriate management activities must be included in the life cycle to ensure consideration of time, cost, and resource drivers.
 
#Appropriate management activities must be included in the life cycle to ensure consideration of time, cost, and resource drivers.
#In focusing on the creation of a specific [[System of Interest (SoI) (glossary)|system of interest (SoI)]] to provide solutions within the cycle, it is important to recognize the need to employ the right balance between [[reductionism (glossary)]] and [[holism (glossary)]] by considering the appropriate [[System Context (glossary)|system context]].
+
#In focusing on the creation of a specific [[System of Interest (SoI) (glossary)|system of interest (SoI)]] to provide solutions within the cycle, it is important to recognize the need to employ the right balance between [[reductionism (glossary)]] and [[holism (glossary)]] by considering the appropriate [[System Context (glossary)|system context (glossary)]].
  
 
The ways in which this idea of concurrent process activity across a life cycle has been implemented in SE are discussed in [[System Life Cycle Process Models: Vee]] and [[System Life Cycle Process Models: Iterative]].
 
The ways in which this idea of concurrent process activity across a life cycle has been implemented in SE are discussed in [[System Life Cycle Process Models: Vee]] and [[System Life Cycle Process Models: Iterative]].
Line 37: Line 37:
  
 
Hitchins (2009) defines the principle of ''adaptive satisficing'' wherein a systems approach is applied iteratively to move towards the resolution of real world stakeholder needs. The system value cycle (Ring 1998) can be expressed as six groups of questions to cycle around value, problem, and solution questions that can be related to the systems approach:
 
Hitchins (2009) defines the principle of ''adaptive satisficing'' wherein a systems approach is applied iteratively to move towards the resolution of real world stakeholder needs. The system value cycle (Ring 1998) can be expressed as six groups of questions to cycle around value, problem, and solution questions that can be related to the systems approach:
#What value do Stakeholders want/need? = Explore Problems and Oppourtunities
+
#What values do Stakeholders want/need? = Explore problems and opportunities
#What system outcomes could improve this value? = System Analysis
+
#What system outcomes could improve this value? = System analysis
 
#What system can provide these outcomes? = Synthesis
 
#What system can provide these outcomes? = Synthesis
#Has such a system been created? = Proving (Verification)
+
#Has such a system been created? = Proving (verification)
#Has the system been deployed to achieve the outcomes? = Proving (Validation)
+
#Has the system been deployed to achieve the outcomes? = Proving (validation)
 
#Do these outcomes provide the expected improvement in value? = Ownership and use
 
#Do these outcomes provide the expected improvement in value? = Ownership and use
  
This cycle continues until statekholders are satisfied or resources are exhausted.
+
This cycle continues until stakeholders are satisfied or resources are exhausted.
  
The above questions focus on the iteration of the systems approach to deliver stakeholder goals within an enterprise context. Whether the first and last questions in this cycle are applications of SE or applications of a systems approach to the enterprise is a matter of debate within the systems community (see [[Enterprise Systems Engineering]] and [[Systems of Systems (SoS)]]).
+
The above questions focus on the iteration of the systems approach to deliver stakeholder goals within an enterprise context. Whether the first and last questions in this cycle are applications of SE or applications of a systems approach to the enterprise is a matter of debate within the systems community (see [[Enterprise Systems Engineering]] and [[Systems of Systems (SoS)]]).
  
 
The systems approach can be applied to multiple systems within an engineered system context, as discussed below. At each level, the approach may be applied iteratively to cycle between what is needed and versions of the solutions within a life cycle model. In general, these iterations are one of three types (Adcock 2005):
 
The systems approach can be applied to multiple systems within an engineered system context, as discussed below. At each level, the approach may be applied iteratively to cycle between what is needed and versions of the solutions within a life cycle model. In general, these iterations are one of three types (Adcock 2005):
Line 57: Line 57:
 
===Recursion===
 
===Recursion===
  
The stakeholder value, problem resolution, and system creation aspects of the system value cycle may each require the use of a focused systems approach. These might be [[Soft System (glossary)|soft systems (glossary)]] to prove a better understanding of a situation, [[Product System (glossary)|product systems (glossary)]] and/or [[Service System (glossary)|service systems (glossary)]] solutions to operational needs, [[Enabling System (glossary)|enabling systems (glossary)]] to support an aspect of the product or service life cycle, or enabling systems used directly by the [[Enterprise System (glossary)|enterprise system (glossary)]].
+
The stakeholder value, problem resolution, and system creation aspects of the system value cycle may each require the use of a focused systems approach. These might be [[Soft System (glossary)|soft systems (glossary)]] to prove a better understanding of a situation, [[Product System (glossary)|product systems (glossary)]] and/or [[Service System (glossary)|service systems (glossary)]] solutions to operational needs, [[Enabling System (glossary)|enabling systems (glossary)]] to support an aspect of the product or service life cycle, or enabling systems used directly by the [[Enterprise System (glossary)|enterprise system (glossary)]].
  
Each of these systems may be identified as a system of interest and require the application of the systems approach. This application may be sequential (the start of one system approach dependent on the completion of another) or parallel (independent approaches which may or may not overlap in time), but will often be recursive in nature.  
+
Each of these systems may be identified as a system of interest (SoI) and require the application of the systems approach. This application may be sequential (the start of one system approach dependent on the completion of another) or parallel (independent approaches which may or may not overlap in time), but will often be recursive in nature.  
  
Recursion is a technique borrowed from computer science, where a function calls itself repeatedly to logically simplify an algorithm. In a recursive application applied to systems, the systems approach for one system of interest is nested inside another. Examples include cases where:
+
Recursion is a technique borrowed from computer science. In computer science recursion occurs when a function calls itself repeatedly to logically simplify an algorithm. In a recursive application applied to systems, the systems approach for one system of interest is nested inside another. Examples include cases where
  
*Trades made at one level of the system require trades to be made for a system element.
+
*trades made at one level of the system require trades to be made for a system element;
*The analysis of a system requires analysis of a system element.
+
*the analysis of a system requires analysis of a system element;
*The synthesis of a solution system requires one or more sub-system elements.
+
*the synthesis of a solution system requires one or more sub-system elements; and
*The verification of a product system requires verification of a system element.
+
*the verification of a product system requires verification of a system element.
  
 
In each case, the "outer" system approach may continue in parallel with the "inner" to some extent, but will be dependent on key outcomes for its own progress.
 
In each case, the "outer" system approach may continue in parallel with the "inner" to some extent, but will be dependent on key outcomes for its own progress.
  
As with all recursive processes, at some stage the application of the approach must reach a level at which it can be completed successfully. This then "rolls up" to allow higher levels to move forward and eventually complete all nested applications successfully.   
+
As with all recursive processes, at some stage the application of the approach must reach a level at which it can be completed successfully. This then "rolls up" to allow higher levels to move forward and eventually complete all nested applications successfully.   
  
The INCOSE ''Systems Engineering Handbook'' (INCOSE 2011) describes a recursive application of SE to levels of [[System Element (glossary)|system elements (glossary)]], with each application representing a system [[project (glossary)]]. Martin (1997) describes the recursive application of SE within a product system hierarchy until a [[component (glossary)]] level is reached, at which point procurement of design and build processes can be used to create solution elements.
+
The INCOSE ''Systems Engineering Handbook'' (INCOSE 2011) describes a recursive application of SE to levels of [[System Element (glossary)|system elements (glossary)]] with each application representing a system [[project (glossary)]]. Martin (1997) describes the recursive application of SE within a product system hierarchy until a [[component (glossary)]] level is reached, at which point procurement of design and build processes can be used to create solution elements.
  
 
The principle of recursive application and how it relates to life cycle models is described in [[Systems Engineering and Management]].
 
The principle of recursive application and how it relates to life cycle models is described in [[Systems Engineering and Management]].
Line 78: Line 78:
 
==Linkages to other topics==
 
==Linkages to other topics==
  
This topic is linked to [[Mission Analysis]], and [[Stakeholder Needs and Requirements]], [[System Realization]], and [[Architectural Design: Logical]] and [[Architectural Design: Physical]].
+
This topic is linked to [[Mission Analysis]], [[Stakeholder Needs and Requirements]], [[System Realization]], [[Architectural Design: Logical]], and [[Architectural Design: Physical]].
  
 
==References==  
 
==References==  

Revision as of 19:50, 14 March 2012

The Systems Approach is described in the SEBoK primarily through five groups of activities which describe the application of systems thinking to an engineered system throughout the life of that system. This article describes how the systems approach relates to both the dynamics of problem resolution and stakeholder value over time, as well as to the levels of system relationship, detailed management, and the engineering activities this implies.

Activity Mapping

The Systems Approach activities are directly related to the high level technical processes defined in Part 3, Systems Engineering and Management, of the SEBOK.

The principles defined in each of the systems approach activities and how they help shape the technical processes in each of these areas are discussed in Part 3.

Application Principles

Concurrency

Normally, the activities of the systems approach should be applied concurrently , reflecting their interrelationships and dependencies. Ring (1998) defines a system value cycle with three levels that a systems approach must consider to deliver real world benefit. These three levels are stakeholder value, system problem situation (or purpose), and system solution (or intervention). Value will only be fully realized when it is considered within the context of time, cost, and other resource issues appropriate to key stakeholders. A developer must consider not only what to do, but when and how much to do in order to provide real value (Senge 1990).

A greater understanding of the value that an engineered system is to offer enables more effective application of the systems approach, which in turn enables the problem situation to be agreed to and appropriate system interventions to be created, deployed, and used (Ring 1998). All of these activities happen concurrently. Efficient application of the systems approach requires awareness of constrained time and funding resources to realize the desired value. In systems engineering (SE) and management practices this leads to the creation of the following (INCOSE 2011):

  • life cycles : Stakeholder value and problem resolution described as a set of life cycle stages over which problems can be explored and resolved, and resources can be managed.
  • life cycle processes : Systems of activities focused on creation and sharing of knowledge associated with the systems approach, which can be employed to promote a holistic approach over a life cycle.

For the generic systems approach, the following fundamental principles apply:

  1. A life cycle has groups of stages which cover understanding stakeholder value; exploration of a problem situation (see System Definition); creation of a system solution, including analysis, synthesis, and proving (see System Realization); and System Deployment and Use.
  2. Life cycle processes define a system of engineering and management activities based on the detailed information needed to ensure a systems approach across a life cycle (e.g., requirements, architecture, verification, and validation).
  3. Activities in any of the processes may be employed in all of the stages to allow for appropriate concurrency.
  4. The sequence and control of the life cycle stages and concurrent process activities must be tailored to the problem situation and commercial environment (Lawson 2010), thus leading to the selection of an appropriate life cycle model .
  5. Appropriate management activities must be included in the life cycle to ensure consideration of time, cost, and resource drivers.
  6. In focusing on the creation of a specific system of interest (SoI) to provide solutions within the cycle, it is important to recognize the need to employ the right balance between reductionism and holism by considering the appropriate system context .

The ways in which this idea of concurrent process activity across a life cycle has been implemented in SE are discussed in System Life Cycle Process Models: Vee and System Life Cycle Process Models: Iterative.

Iteration

The systems approach can be applied in an iterative way to move towards an acceptable solution to a problem situation within a larger cycle of stakeholder value.

Hitchins (2009) defines the principle of adaptive satisficing wherein a systems approach is applied iteratively to move towards the resolution of real world stakeholder needs. The system value cycle (Ring 1998) can be expressed as six groups of questions to cycle around value, problem, and solution questions that can be related to the systems approach:

  1. What values do Stakeholders want/need? = Explore problems and opportunities
  2. What system outcomes could improve this value? = System analysis
  3. What system can provide these outcomes? = Synthesis
  4. Has such a system been created? = Proving (verification)
  5. Has the system been deployed to achieve the outcomes? = Proving (validation)
  6. Do these outcomes provide the expected improvement in value? = Ownership and use

This cycle continues until stakeholders are satisfied or resources are exhausted.

The above questions focus on the iteration of the systems approach to deliver stakeholder goals within an enterprise context. Whether the first and last questions in this cycle are applications of SE or applications of a systems approach to the enterprise is a matter of debate within the systems community (see Enterprise Systems Engineering and Systems of Systems (SoS)).

The systems approach can be applied to multiple systems within an engineered system context, as discussed below. At each level, the approach may be applied iteratively to cycle between what is needed and versions of the solutions within a life cycle model. In general, these iterations are one of three types (Adcock 2005):

  • Sequential: With iteration between the stages to solve detailed issues as they arise, a single application of the systems approach is sufficient.
  • incremental : Successive versions of the sequential approach are necessary for a solution concept. Each increment adds functionality or effectiveness to the growing solution over time.
  • evolutionary : A series of applications of the sequential approach for alternative solutions intended to both provide stakeholder value and increase problem understanding. Each evolutionary cycle provides an opportunity to examine how the solution is used so these lessons learned can be incorporated in the next iteration.

These aspects of the systems approach form the basis for life cycle models.

Recursion

The stakeholder value, problem resolution, and system creation aspects of the system value cycle may each require the use of a focused systems approach. These might be soft systems to prove a better understanding of a situation, product systems and/or service systems solutions to operational needs, enabling systems to support an aspect of the product or service life cycle, or enabling systems used directly by the enterprise system .

Each of these systems may be identified as a system of interest (SoI) and require the application of the systems approach. This application may be sequential (the start of one system approach dependent on the completion of another) or parallel (independent approaches which may or may not overlap in time), but will often be recursive in nature.

Recursion is a technique borrowed from computer science. In computer science recursion occurs when a function calls itself repeatedly to logically simplify an algorithm. In a recursive application applied to systems, the systems approach for one system of interest is nested inside another. Examples include cases where

  • trades made at one level of the system require trades to be made for a system element;
  • the analysis of a system requires analysis of a system element;
  • the synthesis of a solution system requires one or more sub-system elements; and
  • the verification of a product system requires verification of a system element.

In each case, the "outer" system approach may continue in parallel with the "inner" to some extent, but will be dependent on key outcomes for its own progress.

As with all recursive processes, at some stage the application of the approach must reach a level at which it can be completed successfully. This then "rolls up" to allow higher levels to move forward and eventually complete all nested applications successfully.

The INCOSE Systems Engineering Handbook (INCOSE 2011) describes a recursive application of SE to levels of system elements with each application representing a system project . Martin (1997) describes the recursive application of SE within a product system hierarchy until a component level is reached, at which point procurement of design and build processes can be used to create solution elements.

The principle of recursive application and how it relates to life cycle models is described in Systems Engineering and Management.

Linkages to other topics

This topic is linked to Mission Analysis, Stakeholder Needs and Requirements, System Realization, Architectural Design: Logical, and Architectural Design: Physical.

References

Works Cited

Blanchard, B. and W.J. Fabrycky. 2006. Systems Engineering and Analysis. Upper Saddle River, NJ, USA: Prentice Hall.

Checkland, P. 1999. Systems Thinking, Systems Practice. New York, NY, USA: John Wiley & Sons.

Hitchins, D. 2009. "What are the General Principles Applicable to Systems?" INCOSE Insight. 12(4).

INCOSE. 2011. INCOSE Systems Engineering Handbook, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TP-2003-002-03.2.1.

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

Martin J. N. 1997. Systems Engineering Guidebook. Boca Raton, FL, USA: CRC Press.

Ring, J., 1998. "A Value Seeking Approach to the Engineering of Systems." Proceedings of the IEEE Conference on Systems, Man, and Cybernetics. p. 2704-2708.

Senge, P. 1990. The Fifth Discipline: The Art and Practice of the Learning Organization. New York, NY, USA: Doubleday/Currency.

Primary References

Checkland, P. 1999. Systems Thinking, Systems Practice. New York, NY, USA: John Wiley & Sons.

Hitchins, D. 2009. "What are the General Principles Applicable to Systems?" INCOSE Insight, 12(4).

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

Additional References

Blanchard, B. and W.J. Fabrycky 2006. Systems Engineering and Analysis. Upper Saddle River, NJ: Prentice Hall.


< Previous Article | Parent Article | Next Article >