System Lifecycle Models

The Life Cycle Model is one of the key concepts of Systems Engineering.

Topics

The topics contained within this knowledge area include:

Overview

A life cycle for a system generally consists of a series of stages regulated by a set of management decisions confirming that the system is mature enough to leave one stage and enter another. Frequently, portions of a system may complete the stages on different timelines, as in the case of a mobile phone basic platform that will be incorporated into multiple hand sets Instance (glossary). Different phones in the family may have different features and different hardware/software designs (e.g., for cameras, Global Positioning Satellite (GPS), or keyboards), and may be developed on different timelines. Another example is a vehicle platform and its several classes of payloads or mission equipment. The nature of the mission equipment element may not be fully known in advance, so elements may be defined, developed, and joined to the system in a number of evolutionary increment . Still, each element can be considered as a system of interest (soi) , and it will proceed through a general set of stages such as those depicted in Figure 1.

Figure 1 – Conceptual Life Cycle Transformations (System-of-Interest Versions)

Note: For many systems the various system versions are developed either concurrently or evolved via multiple iterations between stages (Lawson 2010, 124).

For complex systems whose elements are evolving on different timelines, however, much more nuanced definitions of complex-system “stages” will need to be defined to be able to synchronize all of their evolutionary increments. Also it is critical for the project team to focus at the outset on key operational issues such as maintenance (design for maintainability ) and late-stage requirement such as disposal . Note: the Development Stage often, but not exclusively, includes realization of a prototype , thus the boundary between Development and Production is indicated with dotted lines in Figure 1.

At the top of Figure 1, the System-of-Interest is first described in terms of desired capabilities, along with evidence that they should be feasible to develop and cost-effective to employ. The desired capabilities are then transformed into specific requirements and a solution architecture, again with evidence of feasibility and operational cost-effectiveness. The architecture is then used to develop Defined Physical and/or Human Activity Systems when they become a product , which is again tested and evaluated for cost-effectiveness and instantiated for utilization. An eventual retirement of a System-of-Interest involves disposing of instances and can also involve retirement of the system definition, that is, the Defined Abstract Systems. Note that in the life cycle portrayal the intermediate work products developed during the life cycle are identified as systems in their own right that identify various views of the System-of-Interest.

In some cases, organizations with the authority and ability to control the definition and sequencing of the various elements of a system can and should organize the product and the process to treat it as a single System-of-Interest. In such cases, large, complex projects such as designing and producing an aircraft like the Boeing 787 or the Airbus A380, with their worldwide distributions of suppliers and subcontractors, can be defined and managed as a single system. Example families of systems would be variants of the basic passenger aircraft for different national airlines or classes of service, or for non-passenger variants such as tanker or cargo versions.

However, even such large Systems-of-Interest will need to operate within one or generally more systems of systems such as the airport system (runways, terminal buildings, related ground support equipment, and human-intensive services such as handling airport security or disabled passengers), the end-to-end transportation system for passengers or cargo, and the various national and international air traffic control systems, which may be evolving on different modernization timescales such as for transitioning to a Global Positioning Satellite (GPS) system for in-flight navigation (NextGen). In such cases, processes oriented around a centrally-controlled individual System-of-Interest cannot provide realistic guidance at the system of (independently evolving) systems level.

References

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

The following three books are not referenced in the SEBOK text, nor are they "Systems Engineering Texts." However they contain very important systems engineering lessons, and readers of this SEBOK are encouraged to read them.

Kinder, Gary. 1998. Ship of Gold in the Deep Blue Sea. Grove Press.

This is an excellent book that follows the inception of an idea to its ultimately successful conclusion. While systems engineering is not discussed, it is clearly illustrated in the whole process from early project definition, to alternate concept development, to phased exploration and “thought experiments” to address challenges along the way. It also shows the problem of not anticipating critical problems outside the usual project and engineering scope, namely it took about five years to locate and recover the 24 tons of gold bars and coins from the sunken ship in the 2,500 meter deep sea, but it took ten years to win the legal battle with the lawyers representing insurance companies who claimed ownership based on 130-year-old policies they issued to the gold owners in 1857.

McCullough, David. 1977. The Path Between the Seas: The Creation of the Panama Canal (1870 – 1914). Simon & Schuster.

Although “systems engineering” is not mentioned, this book highlights many systems engineering issues and illustrates the need for SE as a discipline. The book also illustrates the danger of applying a previously successful concept (the sea level canal used in Suez a decade earlier) in a similar but different situation. Ferdinand de Lesseps led both the Suez and Panama projects. It illustrates the danger of not having a fact-based project cycle and meaningful decision gates throughout the project cycle. It also highlights the danger of providing project status without visibility, since after five years into the ten-year project investors were told the project was over 50% complete when in fact only 10% of the work was done. The second round of development under Stevens in 1904 focused on “moving dirt” rather than digging a canal, a systems engineering concept key to the completion of the canal. The Path Between the Seas won the National Book Award for history (1978), the Francis Parkman Prize (1978), the Samuel Eliot Morison Award (1978), and the Cornelius Ryan Award (1977).

Shackleton, Sir Ernest Henry. 2008. (Originally published in by William Heinemann, London, 1919). South; The Last Antarctic Expedition of Shackleton and the Endurance. Lyons Press.

This is the amazing story of the last Antarctic expedition of Shackleton and the Endurance in 1914 to 1917. The systems engineering lesson is the continuous, daily risk assessment by the captain, expedition leader, and crew as they lay trapped in the arctic ice for 18 months. All 28 crew survived.