Difference between revisions of "Applying the Systems Approach"

Revision as of 15:50, 6 September 2011

The Systems Approach is described in the SEBoK primarily through five topics: Exploring a Problem or Opportunity, Systems Analysis Approach, Synthesis of a System, Proving a System, and Owning and Making Use of a System. Together, understanding these five topics enables 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 and to the levels of system relationship and detailed management and engineering activities this implies.

Application Principles

Concurrency

Normally, the five topics of the systems approach are applied concurrently , reflecting their interrelationships and dependencies. (Ring, 1998) defines a System Value Cycle which describes three levels which a systems approach must consider to deliver real world benefit: 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. (INCOSE, 2011) In System Engineering and Management practices, (INCOSE, 2011), this leads to the creation of:

life cycle : stakeholder value and problem resolution described as a set of Life Cycle Stages over which problems can be explored and resolved, and resources managed.
life cycle process : 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:

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.
Lifecycle Processes define a system of engineering and management activities based on the detailed information needed to ensure a systems approach across a lifecycle, 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.
The sequence and control of the life cycle stages and concurrent process activities must be tailored to the problem situation and commerical environment (Lawson, 2010), leading to the selection of an appropriate life cycle model .
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) to provide solutions within this cycle we must consider 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 have been implemented in Systems Engineering are discussed in System Life Cycle Process Models: Vee amd System Life Cycle Process Models: Iterative.

Iteration

The Systems Approach can be apply 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, by which a Systems Approach is applied iteratively to move towards 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, which can be related to the Systems Approach:

What value do Stakeholders want/need? = Explore Problems and Oppourtunities
What system outcomes could improve this value? = System Analysis
What system can provide these outcomes? = Synthesis
Have such a system been created? = Proving (Verification)
Have the system been deployed to achieve the outcomes? = Proving (Validation)
Do these outcomes provide the expected improvement in value? = Ownership and use.

This cycle continues until statekholders 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 Systems Engineering, or applications of a Systems Approach to the Enterprise is a matter of debate within the systems community (see Enterprise Systems Engineering and System of Systems).

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 of one of three types (Adcock, 2005):

Sequential: a single application of the systems approach is sufficient, with iteration between the stages to solve detailed issues as they arise.
incremental : successive versions of the sequential approach 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 to increase problem understanding

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 better understanding of a situation; product system and/or service system solutions to operational needs; enabling systems to support an aspect of the product or service lifecycle; or enabling systems used directly by the enterprise system .

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. In a recursive application the system approach for which one SoI is nested inside another, this might be:

The exploration of a problem situation requires a stakeholder exploration team
The analysis of a problem statement requires some system model
The synthesis of a solution system requires one or more sub-system elements
The verification of a product system requires a test facility
The deployment of a product system requires operator training
The use of a service system requires communication infrastructure

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 Systems Engineering to levels of system element , with each application representing a system project . (Martin,1997) describes the recursive application of System Engineering 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 concept of recursive application, and how it relates to life cycle models is described in Systems Engineering and Management.

Systems Approach and Systems Engineering

This section provides a direct mapping of the five topics in the Systems Approach to the elements of Systems Engineering and a direct link to the topics describing those elements.

Exploring a Problem or Opportunity

The problem or opportunity to be addressed may be determined by conducting a Mission Analysis and by determining requirements from the stakeholders. See Mission Analysis and Stakeholders Requirements in Part 3 for more information about how this is done. Hence, the Systems Approach principle of Exploring a Problem or Opportunity engenders the Systems Engineering concepts of Mission Analysis and Stakeholder Requirements.

System Analysis Approach

Identification of the Elements of the System

Within the activities described in the Part 3 topic Architectural Design, the functional architecture is defined and the physical elements are allocated to the elements of the functional architecture. In the early phases some elements are identified. But these elements are not physically visible. They are abstractly defined. Perhaps only their functions are known at this time. Yet these functions eventually become physical objects. This progression from the abstract to the concrete is discussed in (Hitchins, 2009, p. 59). Relationships between elements are also defined. The architectural relationships will also be defined. When the abstract elements are transformed into defined elements, these two set of elements are also said to be coupled. According to (Blanchard and Fabrycky, 2006, Chapters 3-5), when translated into Systems Engineering terminology, these stages of system evolution are known as Conceptual Design, Preliminary Design, and Detail Design.

Grouping of Elements

Also within the activities identified in Architectural Design, groups of elements are defined that can perform a given function. These groups of elements lead to the concept of a subsystem. According to Architectural Design, subsystems are identified during the synthesis process using a set of criteria for grouping elements. Hence, the Systems Approach concept of grouping gives rise to the Systems Engineering concept of subsystems.

Identification of the Boundary of a System

The Architectural Design topic also describes the concept of the system of interest. The boundary of the system of interest is the interface between the system of interest, its environment, and other systems. According to Checkland (Checkland, 1999, p. 312) a boundary is "the set of elements that define the limit of the System of Interest (SoI)." Hence, the boundary of the system of interest in Systems Engineering fulfills the Systems Approach principle of a boundary.

Identification of the Interactions Among the Elements

The Architectural Design topic describes the concept of interfaces . The Systems Engineering concept of interface is the application of the Systems Approach principle of interactions among elements. The Architectural Design topic distinguishes between physical interfaces and functional interfaces, both of which should be considered in the system definition.

Synthesis of a System

The Architectural Design topic identifies the need to design a physical candidate architecture. Such design is the process of synthesis and should include a set of criteria to guide it. Synthesis is done by grouping the leaf system elements to constitute a group of (sub) systems.

In compliance with the principles of the Systems Approach, the Systems Engineering process of synthesis does not begin with a defined system; there is only a problem or opportunity that has been defined. There are often some existing legacy elements that will eventually become part of a system, but at an abstract level, that fact does not change the approach. The objective is to progress from the problem to a defined system; but how does that happen? When a set of assets becomes a system, the latter is called a respondent system, according to Lawson (Lawson, 2010, Chapter 1). The set of assets and the respondent system are said to be coupled. Complexity makes the process non-linear. As emergent properties begin to be observed, changes may need to be made in component definition and perhaps even in the architectural arrangement. Hence, iterative definition becomes necessary.

Proving a System

The System Realization knowledge area notes that both Verification and Validation are components of the System Realization process. Implementation and Integration are the other two. These two processes are the application of the Systems Approach principle of Proving the System.

Verification

According to System Realization, the Systems Engineering verification process uses the results of the system design, including requirements, to determine whether the system is designed in the way it was intended to be designed and whether it meets its performance requirements. This process is the Systems Engineering implementation of the Systems Approach principle of verification.

Validation

The Systems Approach knowledge area explains how the Systems Engineering process of validation meets the Systems Approach principle of validation. With good judgment and patience a system will emerge. This system must be proved, as previously discussed. If all has been successful, the system will solve the problem or exploit the opportunity that was previously identified.

Owning and Making Use of a System

The System Deployment and Use knowledge area explains the Systems Engineering aspect of deployment and use to apply the Systems Approach principle of the same name. Factors include transition to deployment, maintenance, logistics, and system operation.

Linkages to other topics

This topic is linked to Mission Analysis and Stakeholders Requirements, System Realization, Architectural Design.

References

Citations

Framework for Tailoring Systems Engineering Lifecycle Processes, INCOSE International Conference 2005.

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

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

Hitchins, D. 2009. What are the General Principles Applicable to Systems? Insight. International Council on Systems Engineering.

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

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

Martin J. N. 1997. Systems Engineering Guidebook. CRC Press, 1997. ISBN 0849378370

Ring, J., "Engineering Value-seeking Systems." IEEE-SMC Conference Proceedings, 1998

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

Primary References

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

Hitchins, D. 2009. What are the General Principles Applicable to Systems? Insight. International Council on Systems Engineering.

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

Additional References