Applying Life Cycle Processes
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 recognise the through life relationships between these activities to ensure we take a systems approach .
Systems Engineering technical and management activities are defined in a set of 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.
In general, the technical and management activities are applied in accordance with the principles of concurrency, iteration and recursion 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 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.
In 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 process define technical and management activities performed across one or more stages to provide the information needed to make life cycle decisions; and to enable to realization, use and sustainment of systems across the life cycle as necessary. This relationship between life cycle model and process activities can be used to describe how SE is applied to different system contexts.
Requirement
A 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 on 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 system with multiple levels 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 it applies. 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 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.
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. The terms Architecture Framework and Architectural Framework both refer to the same. Examples include: DoDAF, MoDAF, NAF for representing systems in defense applications, the TOGAF open group Architecture Framework, and the Federal Enterprise Architecture Framework (FEAF) for information technology acquisition, use and disposal. See the glossary of terms Architecture Framework for definition and other examples.
Other Processes
A number of other life cycle processes are mentioned below, including system analysis integration verification validation deployment, operation, maintenance and disposal 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 are not compartmentalized to particular life cycle stages (Lawson 2010).
Figure 1 show 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.
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 will likely maintenance constraints 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. are all resources need for verification 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.
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 process are further discussed in the System Definition KA.
Figure 3 below gives an example of the iteration between the other life cycle processes.
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 elements . Figure 4 presents a fundamental schema of a system breakdown structure.
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.
References
Works Cited
Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.
Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering Complex Systems with Models and Objects. New York, NY, USA: McGraw-Hill.
Primary References
Additional References
Bell Telephone Laboratories. 1982. Engineering and Operations in the Bell System. Murray Hill, NJ: Bell Telephone Laboratories.
Fortescue, P.W., J. Stark, and G. Swinerd. 2003. Spacecraft Systems Engineering. New York, NY, USA: J. Wiley.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus