Difference between revisions of "Applying the Systems Approach"
| Line 25: | Line 25: | ||
According to the [[System Realization]] section of Part 3, 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 it meets its performance requirements. This process is the Systems Engineering implementation of the Systems Approach principle of verification. | According to the [[System Realization]] section of Part 3, 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 it meets its performance requirements. This process is the Systems Engineering implementation of the Systems Approach principle of verification. | ||
===Validation=== | ===Validation=== | ||
| − | The [[ | + | The [[Systems Approach]] section of Part 3 also provides detail as to how the Systems Engineering process of validation meets the Systems Approach principle of validation. |
Finally, 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 identified in the beginning. | Finally, 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 identified in the beginning. | ||
| + | |||
==Owning and Making Use of a System== | ==Owning and Making Use of a System== | ||
Revision as of 15:41, 3 August 2011
For engineered systems the application of the Systems Approach is Systems Engineering. This section will provide a direct mapping of the various principles of the Systems Approach to the elements of Systems Engineering and a direct link to the descriptions of those elements. The following subsections are organized according to the Systems Approach principles above with a discussion of how these principles are linked to the elements of Systems Engineering. The Systems Approach is not a linear, one-dimensional process with a predictable solution at the end, and neither is its offspring Systems Engineering. This section will describe the incremental and evolutionary nature of the beast. This section will describe how the Systems Engineering process will apply the Systems Approach principles throughout its breadth and scope.
Exploring a Problem or Opportunity
The problem or opportunity to be addressed can best be determined by conducting a Mission Analysis and by determining the requirements from the stakeholders. See the section in Part 3 called Mission Analysis and Stakeholders Requirements to determine 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 Part 3 section called 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 beco me physical objects eventually. This progression from the abstract to the concrete is discussed by Hitchins (Hitchins, 2009, p. 59). The relationships between these elements is also defined and their interactions. 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 (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 Architectural Design section groups of elements are defined that can perform a given function. These groups of elements lead to the concept of a subsystem. According to this section, subsystems are identified during the synthesis process. A set of criteria are defined 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 section also describes the concept of the system of interest (SOI). The boundary of the SOI is the interface between the SOI, 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 SOI in Systems Engineering fulfills the Systems Approach principle of a boundary.
Identification of the Interactions Among the Elements
The Architectural Design section also has a subsection called Concept of Interface. The Systems Engineering concept of interface is the application of the Systems Approach principle of interactions among elements. The Architectural Design section distinguishes between physical interfaces and functional interfaces. This section emphasizes that both types of interfaces should be considered in the system definition.
Synthesis of a System
The Architectural Design section has a subsection called "Designing Physical Candidate Architecture". This subsection describes the process of synthesis and provides a set of criteria for synthesis. According to this subsection, “synthesis is done by grouping the leaf system elements to constitute a group of (sub) systems.” First, 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 may be some existing elements (see Identification of the Elements of a System, above) that will eventually become part of a system, but 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 even more 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 the necessary process.
Proving a System
The System Realization section 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 the System Realization section of Part 3, 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 it meets its performance requirements. This process is the Systems Engineering implementation of the Systems Approach principle of verification.
Validation
The Systems Approach section of Part 3 also provides detail as to how the Systems Engineering process of validation meets the Systems Approach principle of validation. Finally, 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 identified in the beginning.
Owning and Making Use of a System
The System Deployment and Use section of Part 3 also provides detail about 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 the Systems Engineering processes of Conceptual Design, Preliminary Design, and Detail Design.
Primary References
References
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.
Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.
Citations
List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.
Primary References
All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.
Additional References
BLANCHARD, B. & FABRYCKY, W. J. 2006. Systems Engineering and Analysis, Upper Saddle River, NJ, Prentise Hall.