Difference between revisions of "Synthesizing Possible Solutions"

From SEBoK
Jump to navigation Jump to search
m (Text replacement - "SEBoK v. 2.9, released 20 November 2023" to "SEBoK v. 2.10, released 06 May 2024")
 
(107 intermediate revisions by 15 users not shown)
Line 1: Line 1:
This article considers the activities of the [[Systems Approach (glossary)]] related to the [[Synthesis (glossary)]] of possible solutions options in detail. Any of the activities described below may need to be considered [[concurrently (glossary)]] with other activities of in the Systems Approach.  The final article in this knowledge area, [[Applying the Systems Approach]], considers the dynamic aspects of how these activities are used as part of the Systems Approach and how this relates in detail to elements of Systems Engineering.
+
----
 +
'''''Lead Author:''''' ''Rick Adcock'', '''''Contributing Authors:''''' ''Scott Jackson, Janet Singer, Duane Hybertson''
 +
----
 +
[[File:PPI.png|thumb|250px|right|<center>The "Systems Approach Applied to Engineered Systems" knowledge area is graciously sponsored by PPI.<center>]]
 +
This topic is part of the [[Systems Approach Applied to Engineered Systems]] knowledge area (KA).  It describes knowledge related to the {{Term|Synthesis (glossary)|synthesis}} of possible {{Term|Solution (glossary)|solution}} options in response to the {{Term|Problem (glossary)|problem}} situations described by activities from [[Identifying and Understanding Problems and Opportunities]] topic.  The solution options proposed by the synthesis activities will form the starting point for the [[Analysis and Selection between Alternative Solutions]]. Any of the activities described below may also need to be considered {{Term|Concurrently (glossary)|concurrently}} with other activities in the {{Term|Systems Approach (glossary)|systems approach}} at a particular point in the life of a {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI).
 +
 
 +
The activities described below should be considered in the {{Term|Context (glossary)|context}} of the [[Overview of the Systems Approach]] topic at the start of this KA.  The final topic in this KA, [[Applying the Systems Approach]], considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to {{Term|Element (glossary)|elements}} of {{Term|Systems Engineering (glossary)|systems engineering}} (SE).
 +
 
 +
==Synthesis Overview==
 +
 
 +
System synthesis is an activity within the systems approach that is used to describe one or more system solutions based upon a problem context for the {{Term|Life Cycle (glossary)|life cycle}} of the {{Term|System (glossary)|system}} to:
 +
 
 +
*  Define options for a SoI with the required properties and {{Term|Behavior (glossary)|behavior}} for an identified problem or {{Term|Opportunity (glossary)|opportunity}} context.
 +
* Provide solution options relevant to the SoI in its intended {{Term|Environment (glossary)|environment}}, such that the options can be assessed to be potentially realizable within a prescribed time limit, {{Term|Cost (glossary)|cost}}, and {{Term|Risk (glossary)|risk}} described in the problem context.
 +
* Assess the properties and behavior of each candidate solution in its wider system context.
 +
 
 +
The {{Term|Iteration (glossary)|iterative}} activity of system synthesis develops possible solutions and may make some overall judgment regarding the feasibility of said solutions. The detailed judgment on whether a solution is suitable for a given iteration of the systems approach is made using the [[Analysis and Selection between Alternative Solutions]] activities.
 +
 
 +
Essential to synthesis is the {{Term|Concept (glossary)|concept}} of {{Term|Holism (glossary)|holism}}(Hitchins 2009), which states that a system must be considered as a whole and not simply as a collection of its elements. The holism of any potential solution system requires that the behavior of the whole be determined by addressing a system within an intended environment and not simply the accumulation of the properties of the elements. The latter {{Term|Process (glossary)|process}} is known as {{Term|Reductionism (glossary)|reductionism}} and is the opposite of holism, which Hitchins (2009, 60) describes as the notion that “the properties, capabilities, and behavior of a system derive from its parts, from interactions between those parts, and from interactions with other systems.”
 +
 
 +
When the system is considered as a whole, properties called {{Term|Emergence (glossary)|emergent}} properties often appear (see [[Emergence]]). These properties are often difficult to predict from the properties of the elements alone. They must be evaluated within the systems approach to determine the complete set of performance levels of the system. According to Jackson (2010), these properties can be considered in the {{Term|Design (glossary)|design}} of a system, but to do so, an iterative approach is required.
 +
 +
In {{Term|Complex (glossary)|complex}} systems, individual elements will {{Term|Adaptability (glossary)|adapt}} to the behavior of the other elements and to the system as a whole. The entire collection of elements will behave as an organic whole. Therefore, the entire synthesis activity, particularly in complex systems, must itself be adaptive.
 +
 
 +
Hence, synthesis is often not a one-time process of solution design, but is used in combination with problem understanding and solution analysis to progress towards a more complete understanding of problems and solutions over time (see [[Applying the Systems Approach]] topic for a more complete discussion of the dynamics of this aspect of the approach).
  
==System Analysis==
+
==Problem or Opportunity Context==
System Analysis is an activity within the Systems Approach to evaluate one or more system artefacts created during the Systems Approach activities:
 
*to define Assessment Criteria based on the required properties and behavior of an identified problem or opportunity system situation;
 
*to assess the Properties and Behavior of each candidate solution in comparison to these criteria;
 
*to compare the assessment of the candidate solutions and to identify if any of them could resolve the problem or exploit the opportunities, and if so to select which ones should be explored further.
 
  
As discussed in [[Synthesizing Possible Solutions]] the problem context for an [[Engineered System (glossary) will include a logical or ideal system solution description.  It is assumed that the solution which “best” matches the ideal will be the most acceptable to the stakeholders.  Note, as discussed below “best” should include an understanding of cost and risk as well as effectiveness.  The problem context may include a [[Soft System (glossary)]] Conceptual Model describing the logical elements of a system to resolve the problem situation and how these are perceived by different stakeholders (Checkland 1999).  This soft context view will provide additional criteria for the analysis process, which may become the critical issues in selecting between two equally effective solution alternatives.  
+
System synthesis needs the problem or opportunity that the system is intended to address to have already been identified and described and for non-trivial systems, the problem or opportunity needs to be identified and understood concurrently with solution synthesis activities.
  
===Effectiveness Analysis===
+
As discussed in [[Identifying and Understanding Problems and Opportunities]], the systems approach should not consider strictly soft or hard situations. In general, the application of the systems approach, with a focus on {{Term|Engineered System (glossary)|engineered system}} contexts, will lead to {{Term|Hard System (glossary)|hard system}} contexts in which an identified SoI and required outcome are defined. Even in these cases, a soft context view of the SoI context will help ensure wider {{Term|Stakeholder (glossary)|stakeholder}} concerns are considered.
Effectiveness studies use the problem or opportunity system as a starting point.  
 
  
The effectiveness of a synthesized system solution will included performance criteria associated with the system primary functions.  These are derived from the systems purpose in enabling the realisation of stakeholder needs in one or more wider system contexts.
+
The problem context should include some {{Term|Boundary (glossary)|boundaries}} on the cost, time to deployment, time in use, and operational effectiveness needed by stakeholders. In general, the goal is not to synthesize the perfect solution to a problem, but rather to find the best available solution for the agreed version of the problem.
  
For a [[Product System (glossary)]] there are a set of generic non functional qualities which are associated with different types of solution pattern or technology, e.g. safety, security, reliability, maintainability, useability, etc.  These criteria are often explicitly stated as part of the domain knowledge of related technical disciplines of technology domains.
+
==Synthesis Activities==
  
For a [[Service System (glossary)]] or [[Enterprise System (glossary)]] the criteria will be more directly linked to the identified user need or enterprise goals.  Typical qualities for such systems include agility, resilience, flexibility, upgradeability, etc.
+
The following activities provide an outline for defining the SoI: grouping of {{Term|Element (glossary)|elements}}, identification of the interactions among the elements, identification of {{Term|Interface (glossary)|interfaces}} between elements, identification of external interfaces to the SoI boundary and common sub-elements within the SoI boundary.
  
In addition to assessments of the absolute effectiveness of a given solution system we must also be able to combine effectiveness with limitations of the cost and timescales included in the problem context.  In general, the role of System Analysis is to identify those proposed solutions which can provide some effectiveness within the cost and time allocated to any given iteration of the Systems Approach, see [[Applying the Systems Approach]] for details.  If none of the solutions can deliver effectiveness that justifies the proposed investment then it is necessary to return to the original framing of the problem.  If at least one solution is assessed as sufficiently effective then a choice between solutions can be proposed.
+
The activities of systems synthesis are built on the idea of a balanced reduction vs. holism approach as discussed in [[What is Systems Thinking?]] topic. It is necessary to divide system elements and {{Term|Function (glossary)|functions}} to create a description of the SoI which is realizable, either through combinations of available elements or through the design and construction of new elements. However, if the system is simply decomposed into smaller and smaller elements, the {{Term|Holistic (glossary)|holistic}} nature of systems will make it more and more difficult to predict the function and behavior of the whole. Thus, synthesis progresses through activities that divide, group, and allocate elements, and then assesses the complete system’s properties in context relevant to the {{Term|User (glossary)|user}} need the SoI will fulfill. Hence, synthesis occurs over the entire {{Term|Life Cycle (glossary)|life cycle}} of the system as the system and its {{Term|Environment (glossary)|environment}} change.
  
===Trade-off studies===
+
===Identification of the Boundary of a System===
In the context of the definition of a system, a trade-off study consists of comparing the characteristics of each candidate system element to determine the solution that best globally balances the assessment criteria. The various characteristics analyzed are gathered in cost analysis, technical risks analysis, and effectiveness analysis (NASA 2007). Each class of analysis is the subject of the following topics:
+
Establishing the boundary of a system is essential to synthesis, the determination of the system's interaction with its environment and with other systems, and the extent of the SoI. Buede (2009, 1102) provides a comprehensive discussion of the importance of, and methods of, defining the boundary of a system in a SE context.
#[[Assessment Criterion (glossary)|Assessment criteria]] are used to classify the various candidate solutions between themselves. They are absolute or relative. For example: maximum cost per unit produced is cc$, cost reduction shall be x%, effectiveness improvement is y%, and risk mitigation is z%.
 
#'''Boundaries''' identify and limit the characteristics or criteria to be taken into account in the analysis. For example: kind of costs to be taken into account, acceptable technical risks, and type and level of effectiveness.
 
#'''Scales''' are used to quantify the characteristics, properties, and/or criteria and to make comparisons. Their definition requires knowing the highest and lowest limits as well as the type of evolution of the characteristic (linear, logarithmic, etc.).
 
#An [[Assessment Score (glossary)|assessment score]] is assigned to a characteristic or criterion for each candidate solution. The goal of the trade-off study is to succeed in quantifying the three variables (and their decomposition in sub-variables) of cost, risk, and effectiveness for each candidate solution. This operation is generally complex and requires the use of models.
 
#The '''optimization''' of the characteristics or properties improves the scoring of interesting solutions.
 
  
A decision-making process is not an accurate science and trade-off studies have limits. The following concerns should be taken into account:
+
===Identification of the Functions of the System===
*Subjective criteria: for example, the component has to be beautiful. What is a beautiful component?
 
*Uncertain data: for example, inflation has to be taken into account to estimate the cost of maintenance during the complete life cycle. What will be inflation for the next five years?
 
*Sensitivity analysis: a global assessment score associated to every candidate solution is not absolute; it is recommended to get a robust selection by performing sensitivity analysis that considers small variations of assessment criteria values (weights). The selection is robust if the variations do not change the order of scores.
 
  
A thorough trade-off study specifies the assumptions, variables, and confidence intervals of the results.  
+
The function of a system at a given level of {{Term|Abstraction (glossary)|abstraction}} is critical to synthesis since the primary goal of the synthesis activity is to propose realizable system descriptions which can provide a given function.  The function of a system is distinct from its behavior as it describes what the system can be used for or is asked to do in a larger system context.  
  
== Systems Principles of System Analysis==
+
Buede (2009, 1091-1126) provides a comprehensive description of functional analysis in a SE context.
  
From the discussions above, the following general [[Principles (glossary)]] of Systems Analysis can be defined:
+
===Identification of the Elements of a System===
  
#Systems Analysis is based on Assessment Criteria based upon a Problem or Opportunity System description.
+
System synthesis calls for the identification of the elements of a system. Typical elements of an [[Engineered System Context]] may be physical, conceptual, or processes. Physical elements may be hardware, {{Term|Software (glossary)|software}}, or humans. Conceptual elements may be ideas, plans, concepts, or hypotheses. Processes may be mental, mental-motor (writing, drawing, etc.), mechanical, or electronic (Blanchard and Fabrycky 2006, 7).
##These criteria will be based around an Ideal System description, which assumes a [[Hard System (glossary)]] problem context can be defined.
 
##Criteria must consider required system behaviour and properties of the complete solution, in all possible wider system contexts and environments.
 
##These must consider non functional issues such as system safety, security, etc.
 
##This idea system description may be supported by [[Soft System (glossary)]] descriptions, from which additional “soft” criteria may be defined, e.g. a stakeholder preference for or against certain kinds of solution, relevant social, political or cultural conventions to be considered in the likely solution environment, etc.
 
#The assessment criteria should include as a minimum the constraints on cost and time scales acceptable to stakeholders; but may also include preferences for or against certain kinds of solution, etc.
 
#Trade studies provide a mechanism for conducting Analysis of alternative solutions.
 
##A trade Study should consider a “System of Assessment Criteria”, with appropriate awareness of the limitations and dependencies between individual criteria.
 
##Trade studies need to deal with both objective and subjective criteria.  Care must be taken to assess the sensitivity of the overall assessment to particular criteria.
 
  
==References==
+
In addition to the elements of the system under consideration (i.e., a SoI), ISO 15288 (ISO/IEC/IEEE 15288 2015) also calls for the identification of the enabling systems. These are systems (or services) utilized at various stages in the life cycle, e.g., development, utilization or support stages, to facilitate the SoI in achieving its objectives.
 +
 
 +
Today's systems often include existing elements. It is rare to find a true "greenfield" system, in which the developers can specify and implement all new elements from scratch. "Brownfield" systems, wherein {{Term|Legacy System (glossary)|legacy}} elements constrain the system {{Term|Structure (glossary)|structure}}, {{Term|Capability (glossary)|capabilities}}, technology choices, and other aspects of implementation, are much more typical (Boehm 2009).
  
===Works Cited===
+
===Division of System Elements===
  
Beishon, J. 1980. Systems Organisations: the Management of Complexity. Milton Keynes; Open University press.  
+
System synthesis may require elements to be divided into smaller elements. The division of elements into smaller elements allows the systems to be grouped and leads to the SE concept of {{Term|Physical Architecture (glossary)|physical architecture}}, as described by Levin (2009, 493-495). Each layer of division leads to another layer of the hierarchical view of a system. As Levin points out, there are many ways to depict the physical architecture, including the use of wiring diagrams, block diagrams, etc. All of these {{Term|View (glossary)|views}} depend on arranging the elements and dividing them into smaller elements. According to the principle of {{Term|Recursion (glossary)|recursion}}, these decomposed elements are either terminal elements, or are decomposable. The hierarchical view does not imply a top-down analytical approach to defining a system. It is simply a view. In the systems approach, levels of the hierarchy are defined and considered recursively with one level forming the context for the next.
  
Blanchard, B. and W.J. Fabrcky. 2006. Systems Engineering and Analysis. Upper Saddle River, NJ: Prentice Hall.
+
===Grouping of System Elements===
  
Boehm, B. 2009. "Applying the Incremental Commitment Model to Brownfield System Development". Proceedings of the 7th Annual Conference on Systems Engineering Research (CSER), Loughborough, UK.  
+
System synthesis may require that elements be grouped. This leads to the identification of the sub-systems that are essential to the definition of a system. Synthesis determines how a system may be partitioned and how each sub-system fits and functions within the whole system. The largest group is the SoI, also called the relevant system by Checkland (1999, 166). According to Hitchins, some of the properties of a SoI are as follows: the SoI is open and dynamic, the SoI interacts with other systems, and the SoI contains sub-systems (Hitchins 2009, 61). The SoI is brought together through the concept of synthesis.
  
Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations". In Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management," 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.
+
===Identification of the Interactions among System Elements===
  
Buede, D.M. 2009. "Functional Analysis". In Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management," 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.  
+
System synthesis may require the identification of the interactions among system elements. These interactions lead to the SE process of interface analysis. Integral to this aspect is the principle of interactions. Interactions occur both with other system elements as well as with external elements and the environment. In a systems approach, interfaces have both a technical and managerial importance. Managerial aspects include the contracts between interfacing {{Term|Organization (glossary)|organizations}}. Technical aspects include the properties of the physical and functional interfaces. Browning provides a list of desirable characteristics of both technical and managerial interface characteristics (Browning 2009, 1418-1419) .
  
Checkand, P. 1999. Systems Thinking, Systems Practice. New York, NY, USA: John Wiley & Sons.  
+
System synthesis will include activities to understand the properties of system elements, the structure of proposed system solutions, and the resultant behavior of the composed system. A number of system concepts for describing system behavior are discussed in the [[Concepts of Systems Thinking]] topic. It should be noted that in order to fully understand a system’s behavior, we must consider the full range of environments in which it might be placed and its allowable {{Term|State (glossary)|state}} in each. According to Page, in complex systems, the individual elements of the system are characterized by properties which enhance the systems as a whole, such as their adaptability (Page 2009).
  
Flood, R. L. and E.R. Carson. 1993. Dealing with Complexity: An Introduction to the Theory and Application of Systems Science, 2nd ed. New York, NY, USA: Plenum Press.
+
==Defining the System-of-Interest==
  
Hitchins, D. 2009. "What are the General Principles Applicable to Systems?" INCOSE Insight. 12(4) (December 2009): 59-63.  
+
Flood and Carson provide two ways to identify system boundaries: a bottom-up, or '''structural approach''', which starts with significant system elements and builds out, and a top down, or '''behavioral approach''', in which major systems needed to fulfill a goal are identified and then the work flows downward (Flood and Carson 1993). They identify a number of rules proposed by Beishon (1980) and Jones (1982) to help in the selection of the best approach.
  
INCOSE. 1998. "INCOSE SE Terms Glossary." INCOSE Concepts and Terms WG (eds.). Seattle, WA, USA: International Council on Systems Engineering.  
+
In either case, the ways in which system elements are refined, grouped, and allocated must be driven towards the synthesis of a realizable system solution description. A realizable solution must consider elements that are either already available, can be created from existing system elements, or are themselves described as system contexts which will need to be synthesized at a future point. In the third case, it is one of the outcomes of the [[Analysis and Selection between Alternative Solutions]] activities that is used to assess the risk that a given element may not be able to be synthesized in the required time limit or cost budget.
  
Jackson, S., D. Hitchins and H. Eisner. 2010. "What is the Systems Approach?". INCOSE Insight. 13(1) (April 2010): 41-43.  
+
A top down approach might start with a system boundary and an overall description of system functions. Through the repeated application of element identification, division, grouping, and allocation of functions, a complete description of the elements needed for the SoI can be defined. In this case, the choice of system elements and allocation of functions may be guided by pre-defined ways of solving a given problem or by identified system {{Term|Pattern (glossary)|patterns}}; both can support as well as insert bias into the synthesis. For example, one might start with the need to provide energy to a new housing project and propose solution options based around connections to an existing power grid, local power generators, renewable energy sources, increased energy efficiency, etc.
  
Jackson, S., D. Hitchins and H. Eisner. 2010. "What is the Systems Approach?". INCOSE Insight. 13(1) (April 2010): 41-43.  
+
The iterative nature of analysis also reflects the need to change the solution as the life cycle progresses and changes the system's environment; thereby, possibly changing what a "best" solution is.
  
Jones, L. 1982, "Defining System Boundaries in Practice: Some Proposals and Guidelines." Journal of Applied Systems Analysis, 9: 41-55.  
+
A bottom up approach starts with major elements and interactions. Again, division, grouping, and identification allows for the construction of a full system description that is capable of providing all the necessary functions, at which point the final SoI boundary can be set. In this case, the choice of system elements and groupings will be driven by the goal of ensuring that the major system elements can be formed together into a viable system whole. For example, there may be a need to replace an existing delivery vehicle and produce solution options that consider vehicle ownership/leasing, driver training, petrol, diesel or electric fuel, etc.
  
Levin, A.H. 2009. "System Architectures". In Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management," 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.  
+
The systems approach aspect of synthesis leads to SE terms such as “design” and “development.” Wasson describes synthesis from a SE point of view (Wasson 2006, 390-690). White provides a comprehensive discussion of methods of achieving design synthesis  (White 2009, 512-515). The systems approach treats synthesis at the abstract level while the SE process definitions provide the concrete steps.
  
Page, S.E. 2009. Understanding Complexity. The Great Courses. Chantilly, VA, USA: The Teaching Company.  
+
The SoI brings together elements, sub-systems and systems through the concept of synthesis to identify a solution option.
  
Shorter Oxford English Dictionary on Historical Principles, 3rd ed. s.v. "Analysis." Oxford, UK: Oxford University Press. 1973.  
+
Synthesis of possible solutions may result in the development of artifacts documenting the synthesis itself and provide the basis for analysis and selection between alternative solutions. These artifacts are dynamic and will change as the SoI changes its environment throughout the system life cycle.
  
Wasson, C.S. 2006. System Analysis, Design, and Development. Hoboken, NJ, USA: John Wiley & Sons.
+
==References==
  
White, Jr., K.P. 2009. "Systems Design." In Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management, 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.
+
===Works Cited===
  
 +
Beishon, J. 1980. ''Systems Organisations: The Management of Complexity''. Milton Keynes, UK: Open University Press.
  
===Primary References===
+
Blanchard, B. and W.J. Fabrycky. 2006. ''Systems Engineering and Analysis''. Upper Saddle River, NJ, USA: Prentice Hall.  
Hitchins, D. 2009. "[[What are the General Principles Applicable to Systems?]]"  INCOSE ''Insight.'' 12(4) (December 2009): 59-63.
 
  
Jackson, S., D. Hitchins and H. Eisner. 2010. "[[What is the Systems Approach?]]" INCOSE ''Insight''. 13(1) (April 2010): 41-43.
+
Boehm, B. 2009. "Applying the Incremental Commitment Model to Brownfield System Development". Proceedings of the 7th Annual Conference on Systems Engineering Research (CSER), Loughborough, UK.  
  
ISO/IEC 2008. Systems and software engineering -- System life cycle processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.  
+
Browning, T.R. 2009. "Using the design structure matrix to design program organizations," in Sage, A.P. and W.B. Rouse (eds.). ''Handbook of Systems Engineering and Management,'' 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.  
  
===Additional References===
+
Buede, D.M. 2009. "Functional analysis," in Sage, A.P. and W.B. Rouse (eds.). ''Handbook of Systems Engineering and Management,'' 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.
  
Blanchard, B. and W.J. Fabrcky. 2006. Systems Engineering and Analysis. Upper Saddle River, NJ: Prentice Hall.  
+
Checkand, P. 1999. ''Systems Thinking, Systems Practice''. New York, NY, USA: John Wiley & Sons.  
  
Browning, T.R. 2009. "Using the Design Structure Matrix to Design Program Organizations". In A.P. Sage and W.B. Rouse, W.B. (eds.) Handbook of Systems Engineering and Management, 2nd Ed. Hoboken, NJ: John Wiley & Sons.  
+
Flood, R.L. and E.R. Carson. 1993. ''Dealing with Complexity: An Introduction to the Theory and Application of Systems Science'', 2nd ed. New York, NY, USA: Plenum Press.  
  
Buede, D.M. 2009. "Functional Analysis." In A.P. Sage and W.B. Rouse, W.B. (eds.). Handbook of Systems Engineering and Management, 2nd Ed.. Hoboken, NJ: John Wiley & Sons.  
+
Hitchins, D. 2009. "What are the general principles applicable to systems?" INCOSE ''Insight'', vol. 12, no. 4, December, pp. 59-63.  
  
 
INCOSE. 1998. "INCOSE SE Terms Glossary." INCOSE Concepts and Terms WG (eds.). Seattle, WA, USA: International Council on Systems Engineering.  
 
INCOSE. 1998. "INCOSE SE Terms Glossary." INCOSE Concepts and Terms WG (eds.). Seattle, WA, USA: International Council on Systems Engineering.  
  
Levin, A.H. 2009. "System Architectures." In A.P. Sage and W.B. Rouse, W.B. (eds.). Handbook of Systems Engineering and Management, 2nd Ed. Hoboken, NJ: John Wiley & Sons.  
+
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the systems approach?" INCOSE ''Insight'', vol.  13, no. 1, April, pp. 41-43.
 +
 
 +
Jones, L. 1982. "Defining system boundaries in practice: Some proposals and guidelines," ''Journal of Applied Systems Analysis'', vol. 9, pp. 41-55.
 +
 
 +
Levin, A.H. 2009. "System architectures," in Sage, A.P. and W.B. Rouse (eds.). ''Handbook of Systems Engineering and Management'', 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.
 +
 
 +
Page, S.E. 2009. "Understanding Complexity." The Great Courses. Chantilly, VA, USA: The Teaching Company.
 +
 
 +
Wasson, C.S. 2006. ''System Analysis, Design, and Development''. Hoboken, NJ, USA: John Wiley & Sons.
 +
 
 +
White, Jr., K.P. 2009. "Systems design," in Sage, A.P. and W.B. Rouse (eds.). ''Handbook of Systems Engineering and Management'', 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.
  
Page, S.E. 2009. Understanding Complexity. The Great Courses. Chantilly, VA, USA: The Teaching Company.  
+
===Primary References===
 +
Hitchins, D. 2009. "[[What are the General Principles Applicable to Systems?|What are the general principles applicable to systems?]]" INCOSE ''Insight,'' vol. 12, no. 4, December, pp. 59-63.
  
Wasson, C.S. 2006. System Analysis, Design, and Development. Hoboken, NJ, USA: John Wiley & Sons.  
+
ISO/IEC/IEEE. 2015. [[ISO/IEC/IEEE 15288|Systems and software engineering -- System life cycle processes]]. Geneva, Switzerland: International Organisation for Standardisation/International Electrotechnical Commissions / Institute of Electrical and Electronics Engineer. [[ISO/IEC/IEEE 15288|ISO/IEC/IEEE 15288]]:2015.
  
White, Jr., K.P. 2009. "Systems Design." In Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management, 2nd ed. Hoboken, NJ, USA: John Wiley & Sons
+
Jackson, S., D. Hitchins and H. Eisner. 2010. "[[What is the Systems Approach?|What is the systems approach?]]" INCOSE ''Insight,'' vol. 13, no. 1, April, pp. 41-43.
 +
 
 +
===Additional References===
 +
None
  
 
----
 
----
  
<center>[[Identifying and Understanding Problems and Opportunities|<- Previous Article]] | [[Systems Approach|Parent Article]] | [[Analysis and Selection between Alternative Solutions|Next Article ->]]</center>
+
<center>[[Identifying and Understanding Problems and Opportunities|< Previous Article]] | [[Systems Approach Applied to Engineered Systems|Parent Article]] | [[Analysis and Selection between Alternative Solutions|Next Article >]]</center>
[[Category:Part 2]][[Category:Topic]]
 
  
 +
<center>'''SEBoK v. 2.10, released 06 May 2024'''</center>
  
{{5comments}}
+
[[Category:Part 2]][[Category:Topic]]
[[Category:Systems Approach]]
+
[[Category:Systems Approach Applied to Engineered Systems]]

Latest revision as of 22:30, 2 May 2024


Lead Author: Rick Adcock, Contributing Authors: Scott Jackson, Janet Singer, Duane Hybertson


The "Systems Approach Applied to Engineered Systems" knowledge area is graciously sponsored by PPI.

This topic is part of the Systems Approach Applied to Engineered Systems knowledge area (KA). It describes knowledge related to the synthesissynthesis of possible solutionsolution options in response to the problemproblem situations described by activities from Identifying and Understanding Problems and Opportunities topic. The solution options proposed by the synthesis activities will form the starting point for the Analysis and Selection between Alternative Solutions. Any of the activities described below may also need to be considered concurrentlyconcurrently with other activities in the systems approachsystems approach at a particular point in the life of a system-of-interestsystem-of-interest (SoI).

The activities described below should be considered in the contextcontext of the Overview of the Systems Approach topic at the start of this KA. The final topic in this KA, Applying the Systems Approach, considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to elementselements of systems engineeringsystems engineering (SE).

Synthesis Overview

System synthesis is an activity within the systems approach that is used to describe one or more system solutions based upon a problem context for the life cyclelife cycle of the systemsystem to:

  • Define options for a SoI with the required properties and behaviorbehavior for an identified problem or opportunityopportunity context.
  • Provide solution options relevant to the SoI in its intended environmentenvironment, such that the options can be assessed to be potentially realizable within a prescribed time limit, costcost, and riskrisk described in the problem context.
  • Assess the properties and behavior of each candidate solution in its wider system context.

The iterativeiterative activity of system synthesis develops possible solutions and may make some overall judgment regarding the feasibility of said solutions. The detailed judgment on whether a solution is suitable for a given iteration of the systems approach is made using the Analysis and Selection between Alternative Solutions activities.

Essential to synthesis is the conceptconcept of holismholism(Hitchins 2009), which states that a system must be considered as a whole and not simply as a collection of its elements. The holism of any potential solution system requires that the behavior of the whole be determined by addressing a system within an intended environment and not simply the accumulation of the properties of the elements. The latter processprocess is known as reductionismreductionism and is the opposite of holism, which Hitchins (2009, 60) describes as the notion that “the properties, capabilities, and behavior of a system derive from its parts, from interactions between those parts, and from interactions with other systems.”

When the system is considered as a whole, properties called emergentemergent properties often appear (see Emergence). These properties are often difficult to predict from the properties of the elements alone. They must be evaluated within the systems approach to determine the complete set of performance levels of the system. According to Jackson (2010), these properties can be considered in the designdesign of a system, but to do so, an iterative approach is required.

In complexcomplex systems, individual elements will adaptadapt to the behavior of the other elements and to the system as a whole. The entire collection of elements will behave as an organic whole. Therefore, the entire synthesis activity, particularly in complex systems, must itself be adaptive.

Hence, synthesis is often not a one-time process of solution design, but is used in combination with problem understanding and solution analysis to progress towards a more complete understanding of problems and solutions over time (see Applying the Systems Approach topic for a more complete discussion of the dynamics of this aspect of the approach).

Problem or Opportunity Context

System synthesis needs the problem or opportunity that the system is intended to address to have already been identified and described and for non-trivial systems, the problem or opportunity needs to be identified and understood concurrently with solution synthesis activities.

As discussed in Identifying and Understanding Problems and Opportunities, the systems approach should not consider strictly soft or hard situations. In general, the application of the systems approach, with a focus on engineered systemengineered system contexts, will lead to hard systemhard system contexts in which an identified SoI and required outcome are defined. Even in these cases, a soft context view of the SoI context will help ensure wider stakeholderstakeholder concerns are considered.

The problem context should include some boundariesboundaries on the cost, time to deployment, time in use, and operational effectiveness needed by stakeholders. In general, the goal is not to synthesize the perfect solution to a problem, but rather to find the best available solution for the agreed version of the problem.

Synthesis Activities

The following activities provide an outline for defining the SoI: grouping of elementselements, identification of the interactions among the elements, identification of interfacesinterfaces between elements, identification of external interfaces to the SoI boundary and common sub-elements within the SoI boundary.

The activities of systems synthesis are built on the idea of a balanced reduction vs. holism approach as discussed in What is Systems Thinking? topic. It is necessary to divide system elements and functionsfunctions to create a description of the SoI which is realizable, either through combinations of available elements or through the design and construction of new elements. However, if the system is simply decomposed into smaller and smaller elements, the holisticholistic nature of systems will make it more and more difficult to predict the function and behavior of the whole. Thus, synthesis progresses through activities that divide, group, and allocate elements, and then assesses the complete system’s properties in context relevant to the useruser need the SoI will fulfill. Hence, synthesis occurs over the entire life cyclelife cycle of the system as the system and its environmentenvironment change.

Identification of the Boundary of a System

Establishing the boundary of a system is essential to synthesis, the determination of the system's interaction with its environment and with other systems, and the extent of the SoI. Buede (2009, 1102) provides a comprehensive discussion of the importance of, and methods of, defining the boundary of a system in a SE context.

Identification of the Functions of the System

The function of a system at a given level of abstractionabstraction is critical to synthesis since the primary goal of the synthesis activity is to propose realizable system descriptions which can provide a given function. The function of a system is distinct from its behavior as it describes what the system can be used for or is asked to do in a larger system context.

Buede (2009, 1091-1126) provides a comprehensive description of functional analysis in a SE context.

Identification of the Elements of a System

System synthesis calls for the identification of the elements of a system. Typical elements of an Engineered System Context may be physical, conceptual, or processes. Physical elements may be hardware, softwaresoftware, or humans. Conceptual elements may be ideas, plans, concepts, or hypotheses. Processes may be mental, mental-motor (writing, drawing, etc.), mechanical, or electronic (Blanchard and Fabrycky 2006, 7).

In addition to the elements of the system under consideration (i.e., a SoI), ISO 15288 (ISO/IEC/IEEE 15288 2015) also calls for the identification of the enabling systems. These are systems (or services) utilized at various stages in the life cycle, e.g., development, utilization or support stages, to facilitate the SoI in achieving its objectives.

Today's systems often include existing elements. It is rare to find a true "greenfield" system, in which the developers can specify and implement all new elements from scratch. "Brownfield" systems, wherein legacylegacy elements constrain the system structurestructure, capabilitiescapabilities, technology choices, and other aspects of implementation, are much more typical (Boehm 2009).

Division of System Elements

System synthesis may require elements to be divided into smaller elements. The division of elements into smaller elements allows the systems to be grouped and leads to the SE concept of physical architecturephysical architecture, as described by Levin (2009, 493-495). Each layer of division leads to another layer of the hierarchical view of a system. As Levin points out, there are many ways to depict the physical architecture, including the use of wiring diagrams, block diagrams, etc. All of these viewsviews depend on arranging the elements and dividing them into smaller elements. According to the principle of recursionrecursion, these decomposed elements are either terminal elements, or are decomposable. The hierarchical view does not imply a top-down analytical approach to defining a system. It is simply a view. In the systems approach, levels of the hierarchy are defined and considered recursively with one level forming the context for the next.

Grouping of System Elements

System synthesis may require that elements be grouped. This leads to the identification of the sub-systems that are essential to the definition of a system. Synthesis determines how a system may be partitioned and how each sub-system fits and functions within the whole system. The largest group is the SoI, also called the relevant system by Checkland (1999, 166). According to Hitchins, some of the properties of a SoI are as follows: the SoI is open and dynamic, the SoI interacts with other systems, and the SoI contains sub-systems (Hitchins 2009, 61). The SoI is brought together through the concept of synthesis.

Identification of the Interactions among System Elements

System synthesis may require the identification of the interactions among system elements. These interactions lead to the SE process of interface analysis. Integral to this aspect is the principle of interactions. Interactions occur both with other system elements as well as with external elements and the environment. In a systems approach, interfaces have both a technical and managerial importance. Managerial aspects include the contracts between interfacing organizationsorganizations. Technical aspects include the properties of the physical and functional interfaces. Browning provides a list of desirable characteristics of both technical and managerial interface characteristics (Browning 2009, 1418-1419) .

System synthesis will include activities to understand the properties of system elements, the structure of proposed system solutions, and the resultant behavior of the composed system. A number of system concepts for describing system behavior are discussed in the Concepts of Systems Thinking topic. It should be noted that in order to fully understand a system’s behavior, we must consider the full range of environments in which it might be placed and its allowable statestate in each. According to Page, in complex systems, the individual elements of the system are characterized by properties which enhance the systems as a whole, such as their adaptability (Page 2009).

Defining the System-of-Interest

Flood and Carson provide two ways to identify system boundaries: a bottom-up, or structural approach, which starts with significant system elements and builds out, and a top down, or behavioral approach, in which major systems needed to fulfill a goal are identified and then the work flows downward (Flood and Carson 1993). They identify a number of rules proposed by Beishon (1980) and Jones (1982) to help in the selection of the best approach.

In either case, the ways in which system elements are refined, grouped, and allocated must be driven towards the synthesis of a realizable system solution description. A realizable solution must consider elements that are either already available, can be created from existing system elements, or are themselves described as system contexts which will need to be synthesized at a future point. In the third case, it is one of the outcomes of the Analysis and Selection between Alternative Solutions activities that is used to assess the risk that a given element may not be able to be synthesized in the required time limit or cost budget.

A top down approach might start with a system boundary and an overall description of system functions. Through the repeated application of element identification, division, grouping, and allocation of functions, a complete description of the elements needed for the SoI can be defined. In this case, the choice of system elements and allocation of functions may be guided by pre-defined ways of solving a given problem or by identified system patternspatterns; both can support as well as insert bias into the synthesis. For example, one might start with the need to provide energy to a new housing project and propose solution options based around connections to an existing power grid, local power generators, renewable energy sources, increased energy efficiency, etc.

The iterative nature of analysis also reflects the need to change the solution as the life cycle progresses and changes the system's environment; thereby, possibly changing what a "best" solution is.

A bottom up approach starts with major elements and interactions. Again, division, grouping, and identification allows for the construction of a full system description that is capable of providing all the necessary functions, at which point the final SoI boundary can be set. In this case, the choice of system elements and groupings will be driven by the goal of ensuring that the major system elements can be formed together into a viable system whole. For example, there may be a need to replace an existing delivery vehicle and produce solution options that consider vehicle ownership/leasing, driver training, petrol, diesel or electric fuel, etc.

The systems approach aspect of synthesis leads to SE terms such as “design” and “development.” Wasson describes synthesis from a SE point of view (Wasson 2006, 390-690). White provides a comprehensive discussion of methods of achieving design synthesis (White 2009, 512-515). The systems approach treats synthesis at the abstract level while the SE process definitions provide the concrete steps.

The SoI brings together elements, sub-systems and systems through the concept of synthesis to identify a solution option.

Synthesis of possible solutions may result in the development of artifacts documenting the synthesis itself and provide the basis for analysis and selection between alternative solutions. These artifacts are dynamic and will change as the SoI changes its environment throughout the system life cycle.

References

Works Cited

Beishon, J. 1980. Systems Organisations: The Management of Complexity. Milton Keynes, UK: Open University Press.

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

Boehm, B. 2009. "Applying the Incremental Commitment Model to Brownfield System Development". Proceedings of the 7th Annual Conference on Systems Engineering Research (CSER), Loughborough, UK.

Browning, T.R. 2009. "Using the design structure matrix to design program organizations," in Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management, 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.

Buede, D.M. 2009. "Functional analysis," in Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management, 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.

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

Flood, R.L. and E.R. Carson. 1993. Dealing with Complexity: An Introduction to the Theory and Application of Systems Science, 2nd ed. New York, NY, USA: Plenum Press.

Hitchins, D. 2009. "What are the general principles applicable to systems?" INCOSE Insight, vol. 12, no. 4, December, pp. 59-63.

INCOSE. 1998. "INCOSE SE Terms Glossary." INCOSE Concepts and Terms WG (eds.). Seattle, WA, USA: International Council on Systems Engineering.

Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the systems approach?" INCOSE Insight, vol. 13, no. 1, April, pp. 41-43.

Jones, L. 1982. "Defining system boundaries in practice: Some proposals and guidelines," Journal of Applied Systems Analysis, vol. 9, pp. 41-55.

Levin, A.H. 2009. "System architectures," in Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management, 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.

Page, S.E. 2009. "Understanding Complexity." The Great Courses. Chantilly, VA, USA: The Teaching Company.

Wasson, C.S. 2006. System Analysis, Design, and Development. Hoboken, NJ, USA: John Wiley & Sons.

White, Jr., K.P. 2009. "Systems design," in Sage, A.P. and W.B. Rouse (eds.). Handbook of Systems Engineering and Management, 2nd ed. Hoboken, NJ, USA: John Wiley & Sons.

Primary References

Hitchins, D. 2009. "What are the general principles applicable to systems?" INCOSE Insight, vol. 12, no. 4, December, pp. 59-63.

ISO/IEC/IEEE. 2015. Systems and software engineering -- System life cycle processes. Geneva, Switzerland: International Organisation for Standardisation/International Electrotechnical Commissions / Institute of Electrical and Electronics Engineer. ISO/IEC/IEEE 15288:2015.

Jackson, S., D. Hitchins and H. Eisner. 2010. "What is the systems approach?" INCOSE Insight, vol. 13, no. 1, April, pp. 41-43.

Additional References

None


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.10, released 06 May 2024