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.
Life Cycle Process Terminology
Process
A process is a series of actions or steps taken in order to achieve a particular end; as a verb it is the performing of the operations. 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 af bstraction. 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 Transforming Enterprise Need to Requirements 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 the article Iterative and Recursive System Definition for further discussion on the use of levels of Logical and Physical architecture 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-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 is also applied to processes. Figure 2 below gives an example of iteration in life cycle processes. The processes in this example are further discussed in the System Definition KA.
Life Cycle Process Recursion
The comprehensive definition of a SoI is generally achieved using decomposition layers and system elements . Figure 3 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 4 shows an example of the recursion of life cycle processes.
References
Works Cited
Collins English Dictionary, s.v. "Ontology." 2011.
Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.
INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
ISO/IEC. 2003. Systems Engineering — A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).
ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute for Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
ISO. 2007. Systems Engineering and Design. Geneva, Switzerland: International Organization for Standardization (ISO). ISO 10303-AP233.
Oliver, D., T. Kelliher, and J. Keegan. 1997. Engineering Complex Systems with Models and Objects. New York, NY, USA: McGraw-Hill.
Primary References
INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.
ISO/IEC/IEEE. 2015. Systems and Software Engineering -- System Life Cycle Processes. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2015.
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