Applying the Systems Approach

From SEBoK
Revision as of 19:18, 18 June 2011 by Bkcase (talk | contribs) (Created page with ''''Content moved from "Incremental Problem Resolution or Opportunity Realization''' The Systems Approach is not a linear, one-dimensional process with a predictable solution at ...')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Jump to navigation Jump to search

Content moved from "Incremental Problem Resolution or Opportunity Realization

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 in-cremental and evolutionary nature of the beast.

Incremental Problem Resolugion or Opportunity Realization Overview

First, remember that the Systems Approach does not begin with a defined system; there is only a problem or opportunity that has been defined. There may be some existing elements 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.

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 become physical objects eventually. This progression from the abstract to the concrete is discussed by (Hitchins, 2009, p. 59). The relationships between these objects 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 al-so 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.

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.

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.

Linkages to other topics

This topic is linked to the Systems Engineering processes of Conceptual Design, Preliminary Design, and Detail Design.

Primary References

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

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

Additional References

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