Generic Life Cycle Model

This introductory article is the first in a series on life cycle models. It discusses how different types of systems require tailored approaches towards managing life cycle, and the role of systems engineers in managing them.

Type of Value Added Products/Services

Adding value, as a product, a service, or both, is the common purpose of all organizations. This holds whether 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, for example one producing nuts, bolts, and lock washer products, sells their products as value added elements to be used by other enterprises who 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 “products” as services 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, including health care, highways and roads, pensions, police, and defense. Where 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 their process needs makes it clear there is no one-size-fits-all process that defines the systems life cycle. Management and leadership approaches must consider the type of systems involved, their longevity, and he need for rapid adaptation to unforeseen changes, whether in competition, technology, leadership, or mission priorities. In turn, the management and leadership approaches impact the type and number of life cycle models that are deployed as well as the processes used within any particular life cycle.

Systems Engineering Responsibility

The role of the systems engineer encompasses the entire life cycle for the System-of-Interest. Systems engineers orchestrate the development of a solution from requirements determination through operations, and ultimately system retirement. They assure that domain experts are properly involved, all advantageous opportunities are pursued, and all significant risks are identified and, where possible, mitigated. The systems engineer works closely with the project manager in tailoring the generic life cycle, including key decision gates (glossary)|decision gates , 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) and can adversely affect the technical development by reducing the level of the SE effort.

Systems engineering tasks are usually concentrated at the beginning of the life cycle, but both commercial and government organizations recognize the need for SE throughout the system’s life span. Often this ongoing effort is to modify or change a system product or service after it enters production or is placed in operation. Consequently, SE is an important 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, all activities essential to ongoing support of the system.

All project managers must ensure that the business aspect (cost, schedule, and value) and the technical aspect of the project cycle stay synchronized. For most programs the technical aspect drives the project, and it is the systems engineers’ responsibility 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 business bounds. These issues also drive the need for decision gates 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 (hardware, software, human system interaction, 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 very outset of the project during user needs discovery and continues through daily activities, formal decision gate reviews, final product or solution delivery, operations, and ultimately to system closeout and disposal.

References

This article relies on limited sources. Reviewers are requested to identify additional sources.

Works Cited

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

No additional references have been identified for version 0.75. Please provide any recommendations on additional references in your review.

---

< Previous Article | Parent Article | Next Article >

Comments from SEBok 0.5 Wiki

No comments were logged for this article in the SEBoK 0.5 wiki. Because of this, it is especially important for reviewers to provide feedback on this article. Please see the discussion prompts below.

SEBoK v. 1.9.1 released 30 September 2018

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

SEBoK v. 1.9.1 released 30 September 2018

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