Generic Life Cycle Model

This article is the first in a series on life cycle models. It discusses how different types of systems require tailored approaches, and the the role of systems engineers in delivering 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 gate , 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.

Citations

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

Primary References

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

Additional References

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

---

Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->

Signatures

--Dholwell 19:50, 30 August 2011 (UTC) core team edit --Rturner 18:35, 1 September 2011 (UTC)