Generic Life Cycle Model
A life cycle is the evolution of a system, product, service, project or other human-made entity from conception through retirement (ISO/IEC 15288). This article is the first in a series on life cycle models and focuses specifically on the characteristics used to classify, discuss, and differentiate various life cycle models. It discusses how different types of systems require tailored approaches aimed toward managing life cycle and the role of systems engineers in managing them. The concepts in this article provide a foundation for the discussion of different types of life cycle models (e.g. Vee models and iterative models), which are discussed later within this knowledge area. Finally, life cycles provide a foundational understanding and context which supports the various phases of systems engineering, as seen throughout Part 3 (e.g. Concept Definition, System Definition, System Realization, System Deployment and Use, etc.).
Types of Value Added Products/Services
Adding value through products, services, or a combination of the two, is the common purpose of all organizations; the life cycle processes used by an organization may impact their ability to deliver this value. This generally holds true whether an organization is public or private, for profit or non-profit. Value is produced by providing and integrating the elements of a system into a product or service according to the system description. Various management and leadership approaches can be required based upon the type and complexity of the work and the type of enterprise involved in the production. Some examples are as follows (Lawson 2010, 193-217):
- A manufacturing enterprise produces nuts, bolts, and lock washer products, sells their products as value added elements to be used by other enterprises. These enterprises then integrate these products into their more encompassing value added system; for example, an aircraft or an automobile.
- A wholesaling or retailing enterprise offers products to their customers. Their customers (individuals or enterprises) acquire the products and use them as elements in their systems.
- A commercial service enterprise such as a bank sells a variety of services as “products” to their customers; for example, current accounts, savings accounts, loans, and investment management. These services add value and are incorporated into customer systems of individuals or enterprises.
- A governmental service enterprise provides citizens with services that vary widely, but may include such services as health care, highways and roads, pensions, law enforcement, and defense. When appropriate, these services become infrastructure elements utilized in larger encompassing systems of interest to individuals and/or enterprises.
- A consulting enterprise via its services adds value in the form of knowledge and know-how for its customers. For such an enterprise, the set of services “produced” can remain stable for some customers but can also change rapidly as agreements with new customers are established and as customer agreements are terminated.
- An IT service enterprise provides data processing and information access capability by operating computers, communication equipment, and software systems.
- A software development enterprise provides software products that meet stakeholder requirements (needs) thus providing services to product users. Both the developed software and the operations service become part of the set of infrastructure systems of the user enterprise.
Within these examples, there are systems that remain stable over reasonably long periods of time and those that change rapidly. The diversity represented by these examples and substantial range of their process needs makes it evident that there is not a one-size-fits-all process that defines a particular systems life cycle. Management and leadership approaches must consider the type of systems involved, their longevity, and the need for rapid adaptation to unforeseen changes, including competition, technology, leadership, or mission priorities. In turn, management and leadership approaches may impact the type and number of life cycle models that are deployed as well as the processes used within any particular life cycle.
Systems Engineer's Responsibilities
The role of the systems engineer encompasses the entire life cycle for the system-of-interest (SoI). Systems engineers orchestrate the development of a solution from operations to determining the initial requirements ultimately until system retirement. They assure that domain experts are properly involved, all advantageous opportunities are pursued, and all significant risks are identified, and when possible, mitigated. The systems engineer works closely with the project manager in tailoring the generic life cycle, including establishing key decision gates , that are designed to meet the needs of their specific project.
Defining the system life cycle establishes a framework for meeting the stakeholders’ needs in an orderly and efficient manner. This is usually done by defining life cycle stages and establishing decision gates to determine readiness to move from one stage to the next. Skipping stages and eliminating “time consuming” decision gates can greatly increase the programmatic risks (cost, schedule, and value) or can adversely affect the technical development by reducing the level of the SE effort.
Systems engineering tasks are typically given the most concentration at the beginning of the life cycle; however, both commercial and government organizations recognize the need for SE throughout a system’s life span. In most cases, this ongoing effort is to modify or change a system product or service after it enters production or is placed into operation. Consequently, SE is a critical part of all life cycle stages. During operations and support (O&S) stages, for example, SE executes performance analysis, interface monitoring, failure analysis, logistics analysis, tracking, and management, which are all activities that are essential to ongoing support of the system (see System Deployment and Use).
All project managers must ensure that the business aspects (e.g. cost, schedule, and value) and the technical aspects of a project cycle remain synchronized. For most programs, the technical aspects drive the project and it is the responsibility of the systems engineer to ensure that the technical solutions considered are consistent with the cost and schedule objectives. This can require working with the users and customers to revise objectives to fit within the businesses boundaries. These issues also drive the need for decision gates to be appropriately spaced throughout the project cycle. Decision gates such as the user requirements review, concept selection review, and system requirements review are early gates that ensure that the project is on the right path and will produce an integrated product (e.g., hardware, software, human system interaction, or services) that meets the user and customer needs. To ensure that the project is on the right path, frequent in-process validation must be performed between the developers and the end users. In-process validation asks the question: “Will what we are planning or creating satisfy the users’ needs?” In-process validation begins at the initialization of the project during user needs discovery and continues through daily activities, formal decision gate reviews, final product or solution delivery, operations, and ultimately until system closeout and disposal.
References
Works Cited
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.
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.
Primary References
Blanchard, B. S., and W. J. Fabrycky. 2011. Systems Engineering and Analysis, 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.
Additional References
None.
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