Difference between pages "Risk Management" and "Applying Life Cycle Processes"

From SEBoK
(Difference between pages)
Jump to navigation Jump to search
 
(Tech and grammar edits as discussed with Bkcase)
 
Line 1: Line 1:
−
The purpose of [[Risk Management (glossary)|risk management]] is to reduce potential [[Risk (glossary)|risks]] to an acceptable level before they occur throughout the life of the product or project.  Risk management is a continuous, forward-looking process that is applied to anticipate and avert risks that may adversely impact the project and can be considered both a [[Project Management (glossary)|project management]] and a [[Systems Engineering (glossary)|systems engineering]] process. A balance must be achieved on each project in terms of overall risk management ownership, implementation, and day-to-day responsibility between these two top-level processes.
+
----
 +
'''''Lead Author:''''' ''Rick Adcock''
 +
----
 +
The [[Generic Life Cycle Model]] describes a set of life cycle stages and their relationships.  In defining this we described some of the technical and management activities critical to the success of each stage.  While this association of activity to stage is important, we must also recognize the through life relationships between these activities to ensure we take a {{Term|Systems Approach (glossary)}}.
  
−
For the SEBoK, risk management falls under the umbrella of [[Systems Engineering Management]], though the wider body of risk literature is explored below.
+
Systems Engineering technical and management activities are defined in a set of {{Term|Life Cycle Process (glossary)|life cycle processes}}.  These group together closely related activities and allow us to describe the relationships between them.  In this topic, we discuss a number of views on the nature of the inter-relationships between process activities within a life cycle model.  
  
−
==Risk Management Process Overview==
+
In general, the technical and management activities are applied in accordance with the principles of {{Term|Concurrent (glossary)|concurrency}}, {{Term|Iteration (glossary)}} and {{Term|Recursion (glossary)}} described in the [[Introduction to Life Cycle Processes|generic systems engineering paradigm]].  These principles overlap to some extent and can be seen as related views of the same fundamental need to ensure we can take a holistic systems approach, while allowing for some structuring and sequence of our activities. The views presented below should be seen as examples of the ways in which different SE authors present these overlapping ideas.
−
[[Risk (glossary)|Risk]] is a measure of the potential inability to achieve overall program objectives within defined cost, schedule, and technical constraints. It has the following two components (DAU 2003a):
 
−
#the probability (or likelihood) of failing to achieve a particular outcome; and  
 
−
#the consequences (or impact) of failing to achieve that outcome.  
 
−
In the domain of catastrophic risk analysis, risk has three components: (1) threat, (2) vulnerability, and (3) consequence (Willis et al. 2005).
 
  
−
[[Risk Management (glossary)|Risk management]] involves defining a risk management strategy, identifying and analyzing risks, handling selected risks, and monitoring the progress in reducing risks to an acceptable level.  (SEI 2010; DoD 2006; DAU 2003a; DAU 2003b; PMI 2008)  ([[Opportunity (glossary)|Opportunity]] and opportunity management is briefly discussed in below.)
+
==Life Cycle Process Terminology==
  
−
The SE risk management process includes the following activities:
+
===Process===
−
*Risk planning
 
−
*Risk identification
 
−
*Risk analysis
 
−
*Risk handling
 
−
*Risk monitoring
 
  
−
===Risk Planning===
+
A {{Term|Process (glossary)|process}} is a series of actions or steps taken in order to achieve a particular end.  Processes can be performed by humans or machines transforming inputs into outputs.
−
Risk planning establishes and maintains a strategy for identifying, analyzing, handling, and monitoring risks within the project. The strategy, both the process and its implementation, is documented in a risk management plan (RMP).
 
  
−
The risk management process and its implementation should be tailored to each project, updated as appropriate throughout the life of the project, and the RMP transmitted in an appropriate means to the project team and key stakeholders.  
+
In the SEBoK, processes are interpreted in several ways, including: technical, life cycle, business, or manufacturing flow processes.  Many of the Part 3 sections are structured along technical processes (e.g. design, verification); however, [[Life Cycle Models]] also describes a number of high-level program life cycle sequence which call themselves processes (e.g. rational unified process (RUP), etc.).
 +
 
 +
[[Applications of Systems Engineering|Part 4: Applications of Systems Engineering]] and [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] utilize processes that are related to services and business enterprise operations.  
  
−
The RMP should contain key risk management information; Conrow (2003) identifies the following as key components of RMP:  
+
Systems Engineering {{Term|Life Cycle Process (glossary)|life cycle processes}} define technical and management activities performed across one or more stages to provide the information needed to make life cycle decisions; and to enable realization, use and sustainment of a {{Term|System-of-Interest (glossary)}} (SoI) across its life cycle model as necessary. This relationship between {{Term|Life Cycle Model (glossary)|life cycle models}} and process activities can be used to describe how SE is applied to different system contexts.
−
*a project summary;
 
−
*project acquisition and contracting strategies;
 
−
*key definitions;
 
−
*a list of key documents;
 
−
*process steps;
 
−
*inputs, tools and techniques, and outputs per process step;
 
−
*linkages between risk management and other project processes;
 
−
*key ground rules and assumptions;
 
−
*risk categories;
 
−
*seller and buyer roles and responsibilities; and,
 
−
*organizational and personnel roles and responsibilities.
 
  
−
Generally, the level of detail in a RMP is risk-driven: simple plans for low risk projects; detailed plans for high risk projects.
+
===Requirement===
  
−
===Risk Identification===
+
A {{Term|Requirement (glossary)|requirement}} is something that is needed or wanted but may not be compulsory in all circumstances. Requirements may refer to product or process characteristics or constraints.  Different understandings of requirements are dependent upon process state, level of abstraction, and type (e.g. functional, performance, constraint).  An individual requirement may also have multiple interpretations over time.
−
Risk identification is the process of examining the project products, processes, and requirements to identify and document candidate risks. Risk identification should be performed continuously at the individual-level as well as through formerly structured events at both regular intervals and following major program changes (e.g., project initiation, re-baselining, change in acquisition phase).
 
  
−
Conrow (2009) states that systems engineers should use one or more top-level approaches (e.g., work breakdown structure (WBS), key processes evaluation, key requirements evaluation, etc.) and one or more lower-level approaches (e.g., affinity, brainstorming, checklists and taxonomies, examining critical path activities, expert judgment, Ishikawa diagrams, etc.) in risk identification. For example, lower-level checklists and taxonomies exist for software risk identification (Conrow and Shishido 1997, 83-89, p. 84; Boehm 1989, 115-125, Carr et al. 1993, p. A-2) and operational risk identification (Gallagher et al. 2005, p. 4), and have been used on a wide variety of programs.  Both the top and lower-level approaches are essential but there is no single accepted method — all approaches should be examined and used as appropriate.  
+
Requirements exist at multiple levels of enterprise or systems with multiple levels of abstraction.  This ranges from the highest level of the enterprise capability or customer need to the lowest level of the system design. Thus, requirements need to be defined at the appropriate level of detail for the level of the entity to which they apply. See the article [[Life Cycle Processes and Enterprise Need|Life Cycle Processes and Enterprise Needs]] for further detail on the transformation of needs and requirements from the enterprise to the lowest system element across concept definition and system definition.
  
−
Candidate risk documentation should include the following items where possible, as identified by Conrow (2003 p.198): 
+
===Architecture===
−
*risk title;
 
−
*a structured risk description;
 
−
*applicable risk categories;
 
−
*potential root causes;
 
−
*relevant historical information; and
 
−
*responsible individual and manager.
 
  
−
It is important to use structured risk descriptions such as an "if, then, because" format: ''if'' (an event occurs--trigger), ''then'' (an outcome or affect occurs), ''because'' (of the following reasons, or root cause). Another useful construct is a ''condition'' (that exists) that leads to a potential ''consequence'' (outcome) (Gluch 1994). These approaches help the analyst to better think through the potential nature of the risk.  
+
An {{Term|Architecture (glossary)|architecture}} refers to the organizational structure of a system, whereby the system can be defined in different contexts.  Architecting is the art or practice of designing the structures. See below for further discussions on the use of levels of Logical and Physical architecture models to define related system and system elements; and support the requirements activities.
  
−
Risk analysis and risk handling activities should only be performed on approved risks to ensure the best use of scarce resources and maintain focus on the correct risks.
+
Architectures can apply for a system product, enterprise, or service.  For example, Part 3 mostly considers product or service related architectures that systems engineers create, but enterprise architecture describes the structure of an organization.  [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] interprets enterprise architecture in a much broader manner than an IT system used across an organization, which is a specific instance of architecture.
 +
 +
Frameworks are closely related to architectures, as they are ways of representing architectures.  See {{Term|Architecture Framework (glossary)|Architecture Framework}} for definition and examples.
 +
===Other Processes===
  
−
===Risk Analysis===
+
A number of other life cycle processes are mentioned below, including {{Term|System Analysis (glossary)}}, {{Term|Integration (glossary)}}, {{Term|Verification (glossary)}}, {{Term|Validation (glossary)}}, deployment, operation, {{Term|Maintenance (glossary)}} and {{Term|Disposal (glossary)}}; they are discussed in detail in the [[System Realization]] and [[System Deployment and Use]] knowledge areas.
−
Risk analysis is the process of systematically evaluating each identified, approved risk to estimate the probability of occurrence (likelihood) and consequence of occurrence (impact), converting the results to a corresponding risk level or rating.
 
  
−
There is no "best" analysis approach for a given risk category. Risk scales and a corresponding matrix, simulations; probabilistic risk assessments are often used for technical risks, while decision trees, simulations, and payoff matrices are used for cost risk; and simulations are used for schedule risk. Risk analysis approaches are sometimes grouped into qualitative and quantitative methods. A structured, repeatable methodology should be used in order to increase analysis accuracy and reduce uncertainty over time.
+
==Life Cycle Process Concurrency==
  
−
The most common qualitative method (typically) uses ordinal probability and consequence scales coupled with a risk matrix (also known as a risk cube or mapping matrix) to convert the resulting values to a risk level. Here, one or more probability of occurrence scales, coupled with three consequence of occurrence scales (cost, performance, schedule) are typically used. Mathematical operations should not be performed on ordinal scale values to prevent erroneous results (Conrow 2003, pp. 187-364).
+
In the [[Generic Life Cycle Model]], we have listed key activities critical to successful completion of each stage. This is a useful way to illustrate the goals of each stage and gives an indication of how processes align with these stages.  This can be important when considering how to plan for resources, milestones, etc. However, it is important to observe that the execution of process activities is not compartmentalized to particular life cycle stages (Lawson 2010).
  
−
Once the risk level for each risk is determined, the risks need to be prioritized. Prioritization is typically performed by risk level (e.g., low, medium, high), risk score (the pair of max (probability), max (consequence) values), and other considerations such as time-frame, frequency of occurrence, and interrelationship with other risks (Conrow 2003, pp. 187-364). An additional prioritization technique is to convert results into an estimated cost, performance, and schedule value (e.g., probability * budget consequence). However, the result is only a point estimate and not a distribution of risk.
+
Figure 1 shows a simple illustration of the through life nature of technical and management processes.  This figure builds directly on the "hump diagram" principles described in [[Systems Approach Applied to Engineered Systems]].
 +
[[File:SE Hump diagram.PNG|thumb|center|650px|Figure 1: Generic Relationships between life cycle stages and processes (modified from Lawson 2010)]]
  
−
Widely used quantitative methods include decision trees and the associated expected monetary value analysis (Clemen and Reilly 2001), modeling and simulation (Law 2007; Mun 2010; Vose 2000), payoff matrices (Kerzner 2009, pp. 747-751), probabilistic risk assessments (Kumamoto and Henley 1996; NASA 2002), and other techniques. Risk prioritization can directly result from the quantitative methods employed. For quantitative approaches, care is needed in developing the model structure, since the results will only be as good as the accuracy of the structure, coupled with the characteristics of probability estimates or distributions used to model the risks (Law 2007; Evans, Hastings, and Peacock 2000).
+
The lines on this diagram represent the amount of activity for each process over the generic life cycle. The peaks (or humps) of activity represent the periods when a process activity becomes the main focus of a stage. The activity before and after these peaks may represent through life issues raised by a process focus, e.g. how likely maintenance constraints will be represented in the system requirements.  These considerations help maintain a more holistic perspective in each stage, or they can represent forward planning to ensure the resources needed to complete future activities have been included in estimates and plans, e.g. all resources needed for verification are in place or available. Ensuring this hump diagram principle is implemented in a way which is achievable, affordable and appropriate to the situation is a critical driver for all life cycle models.
  
−
If multiple risk facets exist for a given item (e.g., cost risk, schedule risk, and technical risk), the different results should be integrated into a cohesive three-dimensional “picture” of risk. Sensitivity analyses can be applied to both qualitative and quantitative approaches in an attempt to understand how potential variability will affect results. Particular emphasis should be paid to compound risks (e.g., highly coupled technical risks with inadequate fixed budgets and schedules).
+
==Life Cycle Process Iteration==
  
−
===Risk Handling===
+
The concept of iteration applies to life cycle stages within a life cycle model, and also applies to processes.  Figure 2 below gives an example of iteration in the life cycle processes associated with concept and system definition.  
−
Risk handling is the process that identifies and selects options and implements the desired option to reduce a risk to an acceptable level, given program constraints (budget, other resources) and objectives (DAU 2003a, pp. 20-23, 70-78).  
 
  
−
For a given [[System of Interest (SoI) (glossary)|system-of-interest]] (SoI), risk handling is primarily performed at two levels. At the system level, the overall ensemble of system risks is initially determined and prioritized, and second-level draft risk element plans (REP's) are prepared for handling the risks. For more complex systems, it is important that the REP's at the higher SoI level are kept consistent with the system RMPs at the lower SoI level, and that the top-level RMP preserves continuing risk traceability across the SoI.
+
[[File:Ex_Itera_of_processes_related_to_Sys_Def_AF_052312.png|thumb|center|650px|'''Figure 2. Example of Iterations of Processes Related to System Definition (Faisandier 2012).''' Permission Granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
  
−
The risk handling strategy selected is the combination of the most desirable risk handling option coupled with a suitable implementation approach for that option (Conrow 2003). Risk handling options include assumption, avoidance, control (mitigation), and transfer. All four options should be evaluated and the best one chosen for each risk. An appropriate implementation approach is then chosen for that option. Hybrid strategies can be developed that include more than one risk handling option, but with a single implementation approach. Additional risk handling strategies can also be developed for a given risk and either implemented in parallel with the primary strategy or made a contingent and implemented if a particular trigger event occurs during the execution of the primary strategy. Often, this choice is difficult because of uncertainties in the risk probabilities and impacts.  In such cases, buying information to reduce risk uncertainty via prototypes, benchmarking, surveying, modeling, etc. will clarify risk handling decisions (Boehm, 1981).
+
There is generally a close coupling between the exploration of a problem or opportunity and the definition of one or more feasible solutions; see [[Systems Approach Applied to Engineered Systems|Systems Approach to Engineered Systems]]. Thus, the related processes in this example will normally be applied in an iterative way. The relationships between these processes are further discussed in the [[System Definition]] KA.
  
−
====Risk Handling Plans====
+
Figure 3 below gives an example of the iteration between the other life cycle processes.
−
A risk handling plan (RHP - a REP at the system level), should be developed and implemented for all "high" and "medium" risks and selected "low" risks as warranted.
 
  
−
As identified by Conrow (2003 pp. 365-387), each RHP should include 
+
[[File:JS_Figure_1.png|thumb|600 px|center|'''Figure 3. System Realization.''' (SEBoK Original)]]
−
*a risk owner and management contacts;
 
−
*selected option;
 
−
*implementation approach;
 
−
*estimated probability and consequence of occurrence levels at the start and conclusion of each activity;
 
−
*specific measurable exit criteria for each activity;
 
−
*appropriate metrics; and
 
−
*resources needed to implement the RHP.
 
  
−
Metrics included in each RHP should provide an objective means of determining whether the risk handling strategy is on track, and whether it needs to be updated. On larger projects these can include earned value, variation in schedule and technical performance measures (TPMs), and changes in risk level vs. time.  
+
The iterations in this example relate to the overlaps in process outcomes shown in Figure 1.  They either allow consideration of cross process issues to influence the system definition (e.g. considering likely integration or verification approaches might make us think about failure modes or add data collection or monitoring elements into the system) or they allow risk management and through life planning activities to identify the need for future activities.
  
−
The activities present in each RHP should be integrated into the project’s integrated master schedule or equivalent; otherwise there will be ineffective risk monitoring and control.
+
The relationships between these processes are further discussed in [[System Realization|system realization]] and [[System Deployment and Use|system deployment and use]].
  
−
===Risk Monitoring===
+
==Life Cycle Process Recursion==
−
Risk monitoring is used to evaluate the effectiveness of risk handling activities against established metrics and provide feedback to the other risk management process steps. Risk monitoring results may also provide a basis to update RHPs, develop additional risk handling options and approaches, and re-analyze risks. In some cases, monitoring results may also be used to identify new risks, revise an existing risk with a new facet, or revise some aspects of risk planning (DAU 2003a, p. 20). Some risk monitoring approaches that can be applied include earned value, program metrics, TPMs, schedule analysis, and variations in risk level. Risk monitoring approaches should be updated and evaluated at the same time and WBS level; otherwise, the results may be inconsistent.
 
  
−
==Opportunity and Opportunity Management==
+
The comprehensive definition of a SoI is generally achieved using decomposition layers and {{Term|System Element (glossary)|system elements}}. Figure 4 presents a fundamental schema of a system breakdown structure.  
−
In principle, opportunity management is the dual to risk management, with two components: probability of achieving an improved outcome, and impact of achieving the outcome. Thus, both should be addressed in risk management planning and execution. In practice, however, a positive opportunity exposure will not match a negative risk exposure in utility space, since the positive utility magnitude of improving an expected outcome is considerably less than the negative utility magnitude of failing to meet an expected outcome (Canada 1971; Kahneman-Tversky 1979). Further, since many opportunity-management initiatives have failed to anticipate serious side effects, all candidate opportunities should be thoroughly evaluated for potential risks to prevent unintended consequences from occurring.
 
  
−
==Linkages to Other Systems Engineering Management Topics==
+
[[File:Hierarchical_decomposition_of_a_system-of-interest_060612.jpg|thumb|center|650px|'''Figure 4. Hierarchical Decomposition of a System-of-Interest (Faisandier 2012).''' Permission Granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
−
The [[Measurement]] process provides indicators for risk analysis. Project [[Planning]] involves the identification of risk and planning for stakeholder involvement. Project [[Assessment and Control]] monitors project risks. [[Decision Management]] evaluates alternatives for selection and handling of identified and analyzed risks.
 
  
−
==Practical Considerations==
+
In each decomposition layer and for each system, the [[System Definition]] processes are applied recursively because the notion of "system" is in itself recursive; the notions of SoI, system, and system element are based on the same concepts (see [[Foundations of Systems Engineering|Part 2]]). Figure 5 shows an example of the recursion of life cycle processes.
−
Key pitfalls and good practices related to systems engineering risk management are described in the next two sections.  
 
  
−
===Pitfalls===
+
[[File:Recursion_of_processes_on_layers_060612.jpg|thumb|center|650px|'''Figure 5. Recursion of Processes on Layers (Faisandier 2012).''' Permission Granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
−
Some of the key pitfalls encountered in performing risk management are below.
 
  
−
{|  
+
==Systems Approach to Solution Synthesis==
−
|+ '''Table 1. Risk Management Pitfalls.''' (SEBoK Original)
+
The sections above give different perspectives on how SE life cycle processes are related and how this shapes their application.  Solution {{Term|Synthesis (glossary)|synthesis}} is described in Part 2 as a way of taking a {{Term|Systems Approach (glossary)|systems approach}} to creating solutions.  Synthesis is, in general, a mixture of top-down and bottom-up approaches as discussed below.
−
|-
+
===Top-Down Approach: From Problem to Solution===
−
! Name
+
In a top-down approach, concept definition activities are focused primarily on understanding the problem, the operational needs/requirements within the problem space, and the conditions that constrain the solution and bound the solution space. The concept definition activities determine the mission context, {{Term|Mission Analysis (glossary)|mission analysis}}, and the needs to be fulfilled in that context by a new or modified system (i.e. the SoI), and address {{Term|Stakeholder Requirement (glossary)|stakeholder needs and requirements}}.
−
! Description
 
−
|-
 
−
| Process Over-reliance
 
−
|
 
−
*Over-reliance on the process side of risk management without sufficient attention to human and organizational behavioral considerations.
 
−
|-
 
−
|Lack of Continuity
 
−
|
 
−
* Failure to implement risk management as a continuous process.  Risk management will be ineffective if it’s done just to satisfy project reviews or other discrete criteria.  (Charette, Dwinnell, and McGarry 2004, 18-24 and Scheinin 2008).
 
−
|-
 
−
|Tool and Technique Over-reliance
 
−
|
 
−
*Over-reliance on tools and techniques, with insufficient thought and resources expended on how the process will be implemented and run on a day-to-day basis.
 
−
|-
 
−
| Lack of Vigilance
 
−
|
 
−
*A comprehensive risk identification will generally not capture all risks; some risks will always escape detection, which reinforces the need for risk identification to be performed continuously.
 
−
|-
 
−
|Automatic Mitigation Selection
 
−
|
 
−
*Automatically select the risk handling mitigation option, rather than evaluating all four options in an unbiased fashion and choosing the “best” option.
 
−
|-
 
−
|Sea of Green
 
−
|
 
−
*Tracking progress of the risk handling plan, while the plan itself may not adequately include steps to reduce the risk to an acceptable level. Progress indicators may appear “green” (acceptable) associated with the risk handling plan:  budgeting, staffing, organizing, data gathering, model preparation, etc.  But the risk itself may be largely unaffected if the handling strategy and the resulting plan is poorly developed, does not address potential root cause(s), and does not incorporate actions that will effectively resolve the risk.
 
−
|-
 
−
|Band-Aid Risk Handling
 
−
|
 
−
*Handling risks (e.g., interoperability problems with changes in external systems) by patching each instance, rather than addressing the root cause(s) and reducing the likelihood of future instances.
 
−
|}
 
  
−
===Good Practices===
+
The {{Term|System Definition (glossary)|system definition}} activities consider functional, behavioral, temporal, and physical aspects of one or more solutions based on the results of concept definition.  {{Term|System Analysis (glossary)|System analysis}} considers the advantages and disadvantages of the proposed system solutions both in terms of how they satisfy the needs established in concept definition, as well as the relative cost, time scales and other development issues.  This may require further refinement of the concept definition to ensure all legacy relationships and stakeholders relevant to a particular solution architecture have been considered in the stakeholder requirements.
−
Some good practices, gathered from the references are below.
+
 +
The outcomes of this iteration between Concept Definition and System Definition define a required system solution and its associated problem context, which are used for {{Term|System Realization (glossary)|System Realization}}, {{Term|System Deployment and Use (glossary)|System Deployment and Use}}, and [[Product and Service Life Management| Product and Service Life Management]] of one or more solution implementations. In this approach, problem understanding and solution selection activities are completed in the front-end portion of system development and design and then maintained and refined as necessary throughout the life cycle of any resulting solution systems. Top-down activities can be sequential, iterative, recursive or evolutionary depending upon the life cycle model.
  
−
{|
+
===Bottom-Up Approach: Evolution of the Solution===
−
|+ '''Table 2. Risk Management Good Practices.''' (SEBoK Original)
 
−
|-
 
−
! Name
 
−
! Description
 
−
|-
 
−
| Top Down and Bottom Up
 
−
|
 
−
*Risk management should be both “top down” and “bottom up” in order to be effective.  The project manager or deputy need to own the process at the top level.  But risk management principles should be considered and used by all project personnel.
 
−
|-
 
−
| Early Planning
 
−
|
 
−
*Include the planning process step in the risk management process.  Failure to adequately perform risk planning early in the project phase, contributes to ineffective risk management.
 
−
|-
 
−
| Risk Analysis Limitations
 
−
|
 
−
*Understand the limitations of risk analysis tools and techniques.  Risk analysis results should be challenged because considerable input uncertainty and/or potential errors may exist.
 
−
|-
 
−
| Robust Risk Handling Strategy
 
−
|
 
−
*The risk handling strategy should attempt to reduce both the probability and consequence of occurrence terms.  It is also imperative that the resources needed to properly implement the chosen strategy be available in a timely manner, else the risk handling strategy, and the entire risk management process, will be viewed as a “paper tiger.”
 
  
−
|-
+
In some situations, the concept definition activities determine the need to evolve existing capabilities or add new capabilities to an existing system. During the concept definition, the alternatives to address the needs are evaluated. Engineers are then led to reconsider the system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the {{Term|Product (glossary)|product}} or {{Term|Service (glossary)|service}} life cycle for a changing {{Term|context (glossary)|context}} of use or for the purpose of improving existing solutions.  
−
| Structured Risk Monitoring
 
−
|
 
−
*Risk monitoring should be a structured approach to compare actual vs. anticipated cost, performance, schedule, and risk outcomes associated with implementing the RHP. When ad-hoc or unstructured approaches are used, or when risk level vs. time is the only metric tracked, the resulting risk monitoring usefulness can be greatly reduced.
 
−
|-
 
−
| Update Risk Database
 
−
|
 
−
*The risk management database (registry) should be updated throughout the course of the program, striking a balance between excessive resources required and insufficient updates performed.  Database updates should occur at both a tailored, regular interval and following major program changes.
 
  
−
|}
+
{{Term|Reverse Engineering (glossary)|Reverse engineering}} is often necessary to enable system engineers to (re)characterize the properties of the system-of-interest (SoI) or its elements. This is an important step to ensure that system engineers understand the SoI before beginning modification. For more information on system definition, see the [[System Definition]] article.
 +
 +
A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design {{Term|Architecture (glossary)|architecture}}. Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.
  
−
==References==
+
===Solution Synthesis===
−
===Works Cited===
+
In most real problems, a combination of bottom-up and top-down approaches provides the right mixture of innovative solution thinking driven by need, and constrained and pragmatic thinking driven by what already exists.  This is often referred to as a “middle-out” approach.
−
Boehm, B. 1981. ''Software Engineering Economics''.  Upper Saddle River, NJ, USA: Prentice Hall.  
 
  
−
Boehm, B. 1989. ''Software Risk Management''. Los Alamitos, CA; Tokyo, Japan: IEEE Computer Society Press: 115-125.
+
As well as being the most pragmatic approach, synthesis has the potential to keep the life cycle focused on whole system issues, while allowing the exploration of the focused levels of detail needed to describe realizable solutions; see [[Synthesis of a System|Synthesising System Solutions]] for more information.
  
−
Canada, J.R. 1971. ''Intermediate Economic Analysis for Management and Engineering''. Upper Saddle River, NJ, USA: Prentice Hall.
 
  
−
Carr, M., S. Konda, I. Monarch, F. Ulrich, and C. Walker. 1993. ''Taxonomy-based risk identification''. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-93-TR-6.
+
==References==
−
 
+
===Works Cited===
−
Charette, R., L. Dwinnell, and J. McGarry. 2004. "Understanding the roots of process performance failure." ''CROSSTALK: The Journal of Defense Software Engineering'' (August 2004): 18-24.
+
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.
−
 
 
−
Clemen, R., and T. Reilly. 2001. ''Making hard decisions''. Boston, MA, USA: Duxbury.
 
  
−
Conrow, E. 2003. ''[[Effective Risk Management: Some Keys to Success]].'' 2nd ed. Reston, VA, USA: American Institute of Aeronautics and Astronautics (AIAA).
+
Lawson, H. 2010. ''A Journey Through the Systems Landscape.'' London, UK: College Publications.
−
 
 
−
Conrow, E. 2008. "Risk analysis for space systems." Paper presented at Space Systems Engineering and Risk Management Symposium, 27-29 February, 2008, Los Angeles, CA, USA. 
 
−
 
 
−
Conrow, E., and P. Shishido. 1997. "Implementing risk management on software intensive projects." ''IEEE Software'' 14(3) (May/June 1997): 83-9.
 
−
 
 
−
DAU.  2003a.  ''Risk Management Guide for DoD Acquisition: Fifth Edition.'' Version 2.  Ft. Belvoir, VA, USA: Defense Acquisition University (DAU) Press.
 
−
 
 
−
DAU. 2003b. ''U.S. Department of Defense extension to: A guide to the project management body of knowledge (PMBOK(R) guide), first edition''. Version 1. 1st ed. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU) Press.
 
−
 
 
−
DoD. 2006.  ''[[Risk Management Guide for DoD Acquisition]].'' 6th edition, version 1. Washington, DC, USA:  Office of the Under Secretary of Defense (Acquisition, Technology & Logistics)/Department of Defense.
 
−
 
 
−
Evans, M., N. Hastings, and B. Peacock. 2000. ''Statistical Distributions.'' 3rd ed. New York, NY, USA: Wiley-Interscience.
 
−
 
 
−
Gallagher, B., P. Case, R. Creel, S. Kushner, and R. Williams. 2005. ''A taxonomy of operational risk''. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-2005-TN-036.
 
−
 
 
−
Gluch, P. 1994. ''A Construct for Describing Software Development Risks''. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-94-TR-14.
 
−
 
 
−
Kerzner, H. 2009. ''Project Management: A Systems Approach to Planning, Scheduling, and Controlling.'' 10th ed. Hoboken, NJ, USA: John Wiley & Sons.
 
−
 
 
−
Kahneman, D., and A. Tversky. 1979.  "Prospect theory: An analysis of decision under risk." ''Econometrica'' 47(2) (Mar., 1979): 263-292.
 
−
 
 
−
Kumamoto, H., and E. Henley. 1996.  ''Probabilistic Risk Assessment and Management for Engineers and Scientists.'' 2nd ed. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers (IEEE) Press.
 
−
 
 
−
Law, A. 2007. ''Simulation Modeling and Analysis.'' 4th ed. New York, NY, USA: McGraw Hill.
 
−
 
 
−
Mun, J. 2010. ''Modeling Risk.'' 2nd ed. Hoboken, NJ, USA: John Wiley & Sons. 
 
−
 
 
−
NASA. 2002. ''Probabilistic Risk Assessment Procedures Guide for NASA Managers and Practitioners.'' Version 1.1. Washington, DC, USA: Office of Safety and Mission Assurance/National Aeronautics and Space Administration (NASA).
 
−
 
 
−
PMI. 2008. ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide),'' 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).
 
−
 
 
−
Scheinin, W. 2008. "Start Early and Often: The Need for Persistent Risk Management in the Early Acquisition Phases." Paper presented at Space Systems Engineering and Risk Management Symposium, 27-29 February 2008, Los Angeles, CA, USA.
 
−
 
 
−
SEI. 2010. ''[[Capability Maturity Model Integrated (CMMI) for Development]]''.  Version 1.3. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).
 
−
 
 
−
Vose, D. 2000. ''Quantitative Risk Analysis.'' 2nd ed. New York, NY, USA: John Wiley & Sons.
 
−
 
 
−
Willis, H.H., A.R. Morral, T.K. Kelly, and J.J. Medby. 2005. ''Estimating Terrorism Risk''. Santa Monica, CA, USA: The RAND Corporation, MG-388.
 
  
 
===Primary References===
 
===Primary References===
−
Boehm, B. 1981. ''[[Software Engineering Economics]].'' Upper Saddle River, NJ, USA:Prentice Hall.
+
INCOSE. 2015. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.
−
 
 
−
Boehm, B. 1989. ''[[Software Risk Management]].'' Los Alamitos, CA; Tokyo, Japan: IEEE Computer Society Press, p. 115-125.
 
−
 
 
−
Conrow, E.H. 2003. ''[[Effective Risk Management: Some Keys to Success]],'' 2nd ed. Reston, VA, USA: American Institute of Aeronautics and Astronautics (AIAA).
 
−
 
 
−
DoD. 2006.  ''[[Risk Management Guide for DoD Acquisition]].'' 6th ed., version 1. Washington, D. C., USA: Office of the Under Secretary of Defense (Acquisition, Technology & Logistics)/Department of Defense (DoD).
 
−
 
 
−
SEI. 2010. ''[[Capability Maturity Model Integrated (CMMI) for Development]]''. Version 1.3. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU).
 
  
 
===Additional References===
 
===Additional References===
−
Canada, J.R. 1971. ''Intermediate Economic Analysis for Management and Engineering''.  Upper Saddle River,NJ, USA: Prentice Hall.
+
None.
−
 
 
−
Carr, M., S. Konda, I. Monarch, F. Ulrich, and C. Walker. 1993. ''Taxonomy-Based Risk Identification''. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-93-TR-6. 
 
−
 
 
−
Charette, R. 1990. ''Application Strategies for Risk Management''. New York, NY, USA: McGraw-Hill.
 
−
 
 
−
Charette, R.  1989.  ''Software Engineering Risk Analysis and Management''.  New York, NY, USA: McGraw-Hill (MultiScience Press).
 
  
−
Charette, R., L. Dwinnell, and J. McGarry. 2004. "Understanding the Roots of Process Performance Failure." ''CROSSTALK: The Journal of Defense Software Engineering'' (August 2004): 18-24. 
 
−
 
−
Clemen, R.T. and T. Reilly. 2001. ''Making Hard Decisions''. Boston, MA, USA: Duxbury. 
 
−
 
−
Conrow, E. 2010. "Space program schedule change probability distributions." Paper presented at American Institute of Aeronautics and Astronautics (AIAA) Space 2010, 1 September 2010, Anaheim, CA, USA.
 
−
 
−
Conrow, E. 2009. "Tailoring risk management to increase effectiveness on your project." Presentation to the Project Management Institute, Los Angeles Chapter, 16 April, 2009, Los Angeles, CA.
 
−
 
−
Conrow, E. 2008. "Risk analysis for space systems." Paper presented at Space Systems Engineering and Risk Management Symposium, 27-29 February, 2008, Los Angeles, CA, USA. 
 
−
 
−
Conrow, E., and P. Shishido. 1997. "Implementing risk management on software intensive projects." ''IEEE Software'' 14(3) (May/June 1997): 83-9. 
 
−
 
−
DAU.  2003a.  ''Risk Management Guide for DoD Acquisition.'' 5th edition, version 2.  Ft. Belvoir, VA, USA: Defense Acquisition University (DAU) Press.
 
−
 
−
DAU. 2003b. ''U.S. Department of Defense extension to: A guide to the project management body of knowledge (PMBOK(R) guide).'' 1st ed., version 1. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU) Press. 
 
−
 
−
Dorofee, A., J. Walker, C. Alberts, R. Higuera, R. Murphy, and R. Williams (eds). 1996. ''Continuous Risk Management Guidebook.'' Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). 
 
−
 
−
Evans, M., N. Hastings, and B. Peacock. 2000. ''Statistical Distributions.'' 3rd ed. New York, NY, USA: Wiley-Interscience. 
 
−
 
−
Gallagher, B., P. Case, R. Creel, S. Kushner, and R. Williams. 2005. ''A Taxonomy of Operational Risk''. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-2005-TN-036.
 
−
 
−
Gluch, P. 1994. ''A Construct for Describing Software Development Risks''. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU), CMU/SEI-94-TR-14. 
 
−
 
−
Haimes, Y.Y. 2009. ''Risk Modeling, Assessment, and Management''. Hoboken, NJ,USA: John Wiley & Sons, Inc. 
 
−
 
−
Hall, E. 1998.'' Managing Risk: Methods for Software Systems Development.'' New York, NY, USA: Addison Wesley Professional.
 
−
 
−
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities''.  Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.
 
−
 
−
ISO. 2009. ''Risk Management—Principles and Guidelines''. Geneva, Switzerland: International Organization for Standardization (ISO), ISO 31000:2009.
 
−
 
−
ISO/IEC. 2009. ''Risk Management—Risk Assessment Techniques''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), ISO/IEC 31010:2009.
 
−
 
−
ISO/IEC/IEEE. 2006. ''Systems and Software Engineering - Risk Management''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 16085.
 
−
 
−
ISO. 2003. ''Space Systems - Risk Management.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 17666:2003.
 
−
 
−
Jones, C. 1994. ''Assessment and Control of Software Risks.'' Upper Saddle River, NJ, USA: Prentice-Hall. 
 
−
 
−
Kahneman, D. and A. Tversky. 1979. ''Prospect Theory: An Analysis of Decision under Risk. ''Econometrica'' 47(2) (Mar., 1979): 263-292.
 
−
 
−
Kerzner, H. 2009. ''Project Management: A Systems Approach to Planning, Scheduling, and Controlling.'' 10th ed. Hoboken, NJ: John Wiley & Sons. 
 
−
 
−
Kumamoto, H. and E. Henley. 1996.  ''Probabilistic Risk Assessment and Management for Engineers and Scientists.'' 2nd ed. Piscataway, NJ, USA: Institute of Electrical and Electronics Engineers (IEEE) Press.
 
−
 
−
Law, A. 2007. ''Simulation Modeling and Analysis.'' 4th ed. New York, NY, USA: McGraw Hill.
 
−
 
−
MITRE. 2012. [http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/risk_management/ Systems Engineering Guide to Risk Management]. Available online: http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/risk_management/.  Accessed on July 7, 2012.  Page last updated on May 8, 2012. 
 
−
 
−
Mun, J. 2010. ''Modeling Risk.'' 2nd ed. Hoboken, NJ, USA: John Wiley & Sons. 
 
−
 
−
NASA. 2002. ''Probabilistic Risk Assessment Procedures Guide for NASA Managers and Practitioners.'' Version 1.1. Washington, D.C., USA: Office of Safety and Mission Assurance/National Aeronautics and Space Administration (NASA). 
 
−
 
−
PMI. 2008. ''A Guide to the Project Management Body of Knowledge (PMBOK guide).'' 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI). 
 
−
 
−
Scheinin, W. 2008. "Start early and often: The need for persistent risk management in the early acquisition phases." Paper presented at Space Systems Engineering and Risk Management Symposium, 27-29 February 2008, Los Angeles, CA, USA. 
 
−
 
−
USAF. 2005. ''SMC systems engineering primer & handbook: Concepts, processes, and techniques.'' 3rd ed. Los Angeles, CA, USA: Space & Missile Systems Center/U.S. Air Force (USAF). 
 
−
 
−
Vose, D. 2000. ''Quantitative risk analysis.'' 2nd ed. New York, NY, USA: John Wiley & Sons.
 
−
 
−
Willis, H.H., A.R. Morral, T.K. Kelly, and J.J. Medby. 2005. ''Estimating Terrorism Risk''. Santa Monica, CA, USA: The RAND Corporation, MG-388.
 
  
 
----
 
----
−
<center>[[Assessment and Control|< Previous Article]] | [[Systems Engineering Management|Parent Article]] | [[Measurement|Next Article >]]</center>
+
<center>[[Generic Life Cycle Model|< Previous Article]] | [[Introduction to Life Cycle Processes|Parent Article]] | [[Life Cycle Processes and Enterprise Need|Next Article >]]</center>
−
 
 
  
 +
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
  
 
[[Category: Part 3]][[Category:Topic]]
 
[[Category: Part 3]][[Category:Topic]]
−
[[Category:Systems Engineering Management]]
+
[[Category:Introduction to Life Cycle Processes]]
−
{{DISQUS}}
 

Revision as of 03:38, 19 January 2020

Lead Author: Rick Adcock

The Generic Life Cycle Model describes a set of life cycle stages and their relationships. In defining this we described some of the technical and management activities critical to the success of each stage. While this association of activity to stage is important, we must also recognize the through life relationships between these activities to ensure we take a systems approachsystems approach.

Systems Engineering technical and management activities are defined in a set of life cycle processeslife cycle processes. These group together closely related activities and allow us to describe the relationships between them. In this topic, we discuss a number of views on the nature of the inter-relationships between process activities within a life cycle model.

In general, the technical and management activities are applied in accordance with the principles of concurrencyconcurrency, iterationiteration and recursionrecursion described in the generic systems engineering paradigm. These principles overlap to some extent and can be seen as related views of the same fundamental need to ensure we can take a holistic systems approach, while allowing for some structuring and sequence of our activities. The views presented below should be seen as examples of the ways in which different SE authors present these overlapping ideas.

Life Cycle Process Terminology

Process

A processprocess is a series of actions or steps taken in order to achieve a particular end. Processes can be performed by humans or machines transforming inputs into outputs.

In the SEBoK, processes are interpreted in several ways, including: technical, life cycle, business, or manufacturing flow processes. Many of the Part 3 sections are structured along technical processes (e.g. design, verification); however, Life Cycle Models also describes a number of high-level program life cycle sequence which call themselves processes (e.g. rational unified process (RUP), etc.).

Part 4: Applications of Systems Engineering and Part 5: Enabling Systems Engineering utilize processes that are related to services and business enterprise operations.

Systems Engineering life cycle processeslife cycle processes define technical and management activities performed across one or more stages to provide the information needed to make life cycle decisions; and to enable realization, use and sustainment of a system-of-interestsystem-of-interest (SoI) across its life cycle model as necessary. This relationship between life cycle modelslife cycle models and process activities can be used to describe how SE is applied to different system contexts.

Requirement

A requirementrequirement is something that is needed or wanted but may not be compulsory in all circumstances. Requirements may refer to product or process characteristics or constraints. Different understandings of requirements are dependent upon process state, level of abstraction, and type (e.g. functional, performance, constraint). An individual requirement may also have multiple interpretations over time.

Requirements exist at multiple levels of enterprise or systems with multiple levels of abstraction. This ranges from the highest level of the enterprise capability or customer need to the lowest level of the system design. Thus, requirements need to be defined at the appropriate level of detail for the level of the entity to which they apply. See the article Life Cycle Processes and Enterprise Needs for further detail on the transformation of needs and requirements from the enterprise to the lowest system element across concept definition and system definition.

Architecture

An architecturearchitecture refers to the organizational structure of a system, whereby the system can be defined in different contexts. Architecting is the art or practice of designing the structures. See below for further discussions on the use of levels of Logical and Physical architecture models to define related system and system elements; and support the requirements activities.

Architectures can apply for a system product, enterprise, or service. For example, Part 3 mostly considers product or service related architectures that systems engineers create, but enterprise architecture describes the structure of an organization. Part 5: Enabling Systems Engineering interprets enterprise architecture in a much broader manner than an IT system used across an organization, which is a specific instance of architecture.

Frameworks are closely related to architectures, as they are ways of representing architectures. See Architecture FrameworkArchitecture Framework for definition and examples.

Other Processes

A number of other life cycle processes are mentioned below, including system analysissystem analysis, integrationintegration, verificationverification, validationvalidation, deployment, operation, maintenancemaintenance and disposaldisposal; they are discussed in detail in the System Realization and System Deployment and Use knowledge areas.

Life Cycle Process Concurrency

In the Generic Life Cycle Model, we have listed key activities critical to successful completion of each stage. This is a useful way to illustrate the goals of each stage and gives an indication of how processes align with these stages. This can be important when considering how to plan for resources, milestones, etc. However, it is important to observe that the execution of process activities is not compartmentalized to particular life cycle stages (Lawson 2010).

Figure 1 shows a simple illustration of the through life nature of technical and management processes. This figure builds directly on the "hump diagram" principles described in Systems Approach Applied to Engineered Systems.

Figure 1: Generic Relationships between life cycle stages and processes (modified from Lawson 2010)

The lines on this diagram represent the amount of activity for each process over the generic life cycle. The peaks (or humps) of activity represent the periods when a process activity becomes the main focus of a stage. The activity before and after these peaks may represent through life issues raised by a process focus, e.g. how likely maintenance constraints will be represented in the system requirements. These considerations help maintain a more holistic perspective in each stage, or they can represent forward planning to ensure the resources needed to complete future activities have been included in estimates and plans, e.g. all resources needed for verification are in place or available. Ensuring this hump diagram principle is implemented in a way which is achievable, affordable and appropriate to the situation is a critical driver for all life cycle models.

Life Cycle Process Iteration

The concept of iteration applies to life cycle stages within a life cycle model, and also applies to processes. Figure 2 below gives an example of iteration in the life cycle processes associated with concept and system definition.

Figure 2. Example of Iterations of Processes Related to System Definition (Faisandier 2012). Permission Granted by Sinergy'Com. All other rights are reserved by the copyright owner.

There is generally a close coupling between the exploration of a problem or opportunity and the definition of one or more feasible solutions; see Systems Approach to Engineered Systems. Thus, the related processes in this example will normally be applied in an iterative way. The relationships between these processes are further discussed in the System Definition KA.

Figure 3 below gives an example of the iteration between the other life cycle processes.

Figure 3. System Realization. (SEBoK Original)

The iterations in this example relate to the overlaps in process outcomes shown in Figure 1. They either allow consideration of cross process issues to influence the system definition (e.g. considering likely integration or verification approaches might make us think about failure modes or add data collection or monitoring elements into the system) or they allow risk management and through life planning activities to identify the need for future activities.

The relationships between these processes are further discussed in system realization and system deployment and use.

Life Cycle Process Recursion

The comprehensive definition of a SoI is generally achieved using decomposition layers and system elementssystem elements. Figure 4 presents a fundamental schema of a system breakdown structure.

Figure 4. Hierarchical Decomposition of a System-of-Interest (Faisandier 2012). Permission Granted by Sinergy'Com. All other rights are reserved by the copyright owner.

In each decomposition layer and for each system, the System Definition processes are applied recursively because the notion of "system" is in itself recursive; the notions of SoI, system, and system element are based on the same concepts (see Part 2). Figure 5 shows an example of the recursion of life cycle processes.

Figure 5. Recursion of Processes on Layers (Faisandier 2012). Permission Granted by Sinergy'Com. All other rights are reserved by the copyright owner.

Systems Approach to Solution Synthesis

The sections above give different perspectives on how SE life cycle processes are related and how this shapes their application. Solution synthesissynthesis is described in Part 2 as a way of taking a systems approachsystems approach to creating solutions. Synthesis is, in general, a mixture of top-down and bottom-up approaches as discussed below.

Top-Down Approach: From Problem to Solution

In a top-down approach, concept definition activities are focused primarily on understanding the problem, the operational needs/requirements within the problem space, and the conditions that constrain the solution and bound the solution space. The concept definition activities determine the mission context, mission analysismission analysis, and the needs to be fulfilled in that context by a new or modified system (i.e. the SoI), and address stakeholder needs and requirementsstakeholder needs and requirements.

The system definitionsystem definition activities consider functional, behavioral, temporal, and physical aspects of one or more solutions based on the results of concept definition. System analysisSystem analysis considers the advantages and disadvantages of the proposed system solutions both in terms of how they satisfy the needs established in concept definition, as well as the relative cost, time scales and other development issues. This may require further refinement of the concept definition to ensure all legacy relationships and stakeholders relevant to a particular solution architecture have been considered in the stakeholder requirements.

The outcomes of this iteration between Concept Definition and System Definition define a required system solution and its associated problem context, which are used for System RealizationSystem Realization, System Deployment and UseSystem Deployment and Use, and Product and Service Life Management of one or more solution implementations. In this approach, problem understanding and solution selection activities are completed in the front-end portion of system development and design and then maintained and refined as necessary throughout the life cycle of any resulting solution systems. Top-down activities can be sequential, iterative, recursive or evolutionary depending upon the life cycle model.

Bottom-Up Approach: Evolution of the Solution

In some situations, the concept definition activities determine the need to evolve existing capabilities or add new capabilities to an existing system. During the concept definition, the alternatives to address the needs are evaluated. Engineers are then led to reconsider the system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the productproduct or serviceservice life cycle for a changing contextcontext of use or for the purpose of improving existing solutions.

Reverse engineeringReverse engineering is often necessary to enable system engineers to (re)characterize the properties of the system-of-interest (SoI) or its elements. This is an important step to ensure that system engineers understand the SoI before beginning modification. For more information on system definition, see the System Definition article.

A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design architecturearchitecture. Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.

Solution Synthesis

In most real problems, a combination of bottom-up and top-down approaches provides the right mixture of innovative solution thinking driven by need, and constrained and pragmatic thinking driven by what already exists. This is often referred to as a “middle-out” approach.

As well as being the most pragmatic approach, synthesis has the potential to keep the life cycle focused on whole system issues, while allowing the exploration of the focused levels of detail needed to describe realizable solutions; see Synthesising System Solutions for more information.


References

Works Cited

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.

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

Primary References

INCOSE. 2015. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0.

Additional References

None.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.1, released 31 October 2019
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Risk_Management&oldid=57964"