By John Blyler, Affiliate Professor, PSU
A life cycle is the series of stages that a system passes through during its lifetime. Ideally, these stages are sequential, starting with the conception of the system, continuing through the design, development, integration, and operation, and ending, finally, with its phaseout. In practice, most phases overlap one another, with the next phase beginning before the previous one is complete. We will discuss two types of life cycle models common to systems engineering: the generic time-line model and the hierarchical model. The first emphasizes the time-dependent aspect of the systems engineering process, while the second emphasizes the embedded, hierarchical nature of systems.
Computer system life cycles are often modeled using a time line similar to the one shown in Fig. 2-3, a generic life cycle model. In systems engineering terminology, a time line is a graphic display showing sequential life cycle phases and activities over time. Such life cycle models serve as road maps, indicating where a system is in its life cycle and what phase is next.
The generic life cycle model emphasizes the phases and flow of the life cycle process. Each phase builds upon and further refines work performed in the previous phase. Each phase has specific activities, reviews, baselining criteria, and output products. All of the activities of a given phase culminate in a review, from which a baseline is established and products are provided. The typical activities associated with each phase of a generic computer system are:
- Concept definition. This is the creation phase, in which the problems, highlighted by the shortcomings of the existing system, are identified and described. The scope of the program is defined, including high-level customer objectives, program policies, and budget and schedule constraints. Brainstorming sessions occur among the chief participants to develop candidate high-level solutions.
- Functions and requirements analysis. This is where most of the hard work takes place and where the most return for effort expended is seen. Meaningful, quantitative requirements are synthesized from the high-level objectives, goals, and constraints identified in the previous phase. The activities or functions that the system must perform are determined and specific requirements allocated to each function. Several possible solution architectures are identified.
- Design. Here, the previously developed functions, requirements, and associated solution architectures are allocated to hardware and software subsystems, and the decomposition process continues at the subsystem level.
- Development (or implementation). The system functions, requirements, and solution architectures have now been decomposed and refined to such an extent that an engineer can begin implementing a design. For example, enough information and detailed requirements exist to start writing software code and assembling the necessary hardware components. What originally had been a fairly conceptual system has been decomposed to hundreds or thousands of small, manageable elements, all tightly integrated and related in well-known and documented ways.
- Integration and verification. The stage is also known as the build, test, and deliver phase. The decomposed system can now be recomposed, into an integrated whole. Each decomposed part, that is, each element, component, and subsystem will be tested individually before being assembled and integrated together. This process continues until the entire system is assembled and tested as a whole, before delivery to the customer.
- Operations and maintenance. The new system is ready for operation. User training and technical support activities are key activities in this phase, as are system enhancements, upgrades and improvements.
- Phaseout and disposal. The end of the system’s useful life. The generic life cycle model is only one of many types of life cycle models, each constructed to emphasize a particular aspect of the system. One of the earliest models, the waterfall model, was characterized by successive, linear stages . The prototyping life cycle model emphasized user feedback in developing and validating system requirements. Risk management and process iteration was the focus of the spiral model . The baseline management model was favored by the Department of Defense (DOD) because it provided very specific management control at every phase of the life cycle .
|Systems Engineering Axiom 3 Life cycle models are numerous. Life cycles themselves are short.Choose a model and move on.|
While the names and the number of phases may vary from model to model, all reflect the same basic process: concept definition; refinement of the problem to specific requirements; design of a solution to meet those requirements; building or implementing the solution system; testing; operation and maintenance; and final system phaseout.
Life Cycle Costs
Performing the tasks required in the early phases of the system life cycle in a thorough and complete manner, greatly increases the chances of success in the later phases. The reason is that life cycle costs (LCC) tend to be committed early in the program , , . Life cycle costs are all costs associated with a system throughout its lifetime. Figure 2-4 shows actual life cycle costs, at each major stage, as a percentage of the committed costs for the entire cycle.
The bottom curve of this figure shows the percentage of the actual, expended costs associated with a typical rightsizing project. The top curve represents the percentage of costs that are committed, or locked in, due to decisions and activities performed early in the life cycle. For example, roughly 10 percent of the total system life cycle cost is actually expended by the end of the function and requirements phase, while over 75 percent of the overall life cycle costs are locked in by the end of this same phase. In other words, the early phase activities, such as understanding the problem, determining detailed functions and requirements, and arriving at the corresponding solution architectures, will lock a company in to a particular course of action, associated with specific costs. It will become increasingly expensive to make changes later on in the life cycle process. For example, if requirements that were poorly defined or omitted in the requirements analysis phase are not discovered until the integration and testing phase, it will be very costly to correct the mistakes, and may be impossible. The moral: doing good work in the early life cycle phases pays off throughout the system life cycle.
|NOTE A Word of Caution: Determining the system functions, requirements, and candidate solutions, at every subsystem level, is hard work. Many organizations lack the technical and institutional discipline to complete this time consuming and often arduous work. Much more immediate gratification can be obtained from skipping the hard labor involved in requirements analysis and jumping to the design phase, since almost everyone has a pet idea for solving a rightsizing problem. Resist this temptation as much as possible.|
Hierarchical Life Cycle Model
Another way to look at a system life cycle is by analyzing its constituent parts. This is the perspective favored by many hardware designers and software programmers, who are predisposed to viewing a system as a collection of physical parts. This model, known as the hierarchical model, or top-down design, decomposes the conceptual system into a hierarchy of smaller, related parts, for example, subsystems, components, and elements. The functions, and requirements associated with these progressively smaller parts are decomposed successively until they are in a simple enough form to be worked upon by an individual engineer. After each constituent part is thoroughly understood, all the parts are integrated together to form an actual system (Fig. 2-5).
Most experienced systems engineers prefer to analyze the functionality of the system as a whole, rather than a hierarchy of system parts. This view more readily allows for the evolution of the system, as different functional hierarchies can be developed for each phase of the life cycle without embedding solution designs. This is important because it does not preclude any additional functionality that may be needed in the end state of the future system.
A Matter of Perspectives
Here is one final observation concerning life cycles. A person’s view of the overall life cycle is greatly influenced by the kind of work that person does (Fig. 2-6). A software analyst, for example, will focus on the functions, requirements, and design phases of the life cycle, little knowing or caring what tasks lie beyond his or her responsibility. Similarly, a programmer will tend to concentrate on the implementation (coding) and integration/verification (testing) phases, not appreciating the challenges faced by the analyst.
The systems engineer, however, much like the program manager, must know enough about all phases to ensure that the efforts of the analyst and programmer can be integrated. The systems engineer must think about all life cycle activities; for example, he or she must be sure that testing issues are discussed early on, in the requirements analysis phase, and not left until the tests actually occur. If you have been chosen to lead the rightsizing effort in your group or company, remember to maintain a global, systems perspective. If you lack that perspective, be sure to surround yourself with others who do see the big picture.
Excerpts from: “What’s Size Got to Do With It? Understanding Computer Rightsizing,’ By John Blyler and Gary Ray, IEEE/Wiley Press, Mohamed E. El-Hawary, Series Editor