This chapter is from the book
This chapter is from the book
This chapter is from the book
1.5 The System Life Cycle
Before studying the requirements and architecture methods, we must understand what purpose they serve. One way to illustrate this is to look at what the methods do and where they fit in the total system life cycle. This is shown in Figure 1.2 in which the development levels correspond to the hierarchical levels of Figure 1.1.
){kind=link}
)
Figure 1.2. The total system life cycle.
The figure illustrates that the requirements and architecture models apply throughout all levels of systems development and both are applied at each level. A set of requirements is generated at a given level, using the requirements model. These requirements are allocated to physical units or modules using the architecture model. The requirements for each unit are then expanded to more detail, and the whole process is repeated at the next level.
Of course, most projects will only deal with perhaps one or two of these iterative cycles, but on the other hand, most projects fit into a larger picture—they may be part of a complete aircraft, or of a manufacturing plant, or of a communication network—in which many more cycles will occur. It is good to have an understanding of the larger framework in which your project fits.
The final level, at which implementation is to take place, may require modification to the architecture model, or may require a language-dependent representation (Ada PDL, for example), depending on the language or implementation needs.
While we do not address testing activities in this book, we have found that structured development proves to be very beneficial in this area. Having the system defined both functionally and physically in a layered hierarchy of processes arid units leads to a similar organization of the test procedures. The testing can proceed very methodically from the bottom up, verifying the functionality and the structure at each level up to the top.
Some caveats
Some key points illustrated in Figure 1.2 need to be emphasized:
- The life cycle does not end at the point of system delivery, as is so often implied: It continues on into the service phase, usually for much longer than the development and build phases. It is customary for modifications and upgrades to occur while the system is in service. This is illustrated in Figure 1.2 via the loop from System in Service through Deploy System and Field Issues and back to the development cycle. These changes, together with the system maintenance cost, can make the cost during service much higher than during development. The benefits of formal methods are most obvious at the development phase, but in fact, their benefits can be multiplied many times over during the service phase because of the ease with which changes can be made after the original developers are gone.
- Contrary again to common misconceptions, the development does not occur in simple sequential steps. There is extensive overlap, feedforward, and feedback between each phase and its neighbors. The process is, in fact, iterative, both within each phase and over multiple phases. The requirements and architecture models record their respective definitions regardless of the order in which they are done. As we shall show in the chapters that follow, everything is traceable between levels and between phases so risk of confusion due to iterative updates is minimized.
- In large, software-intensive systems, the activities of defining the requirements, the architecture, and the hardware and software design are (or should be) much more extensive than the actual implementation. In fact, with the advent of tools that will generate code automatically from requirements statements, we are rapidly approaching the point at which, for all intents and purposes, the definition is the implementation. The two methods exist specifically to support this front-end definition activity.
- Systems themselves, and the process of developing them, are leveled hierarchies. In the extreme, we can consider the whole universe, the elementary particles of which it is composed, and every structure in between, as one huge leveled hierarchy of systems, as was shown in Figure 1.1. The particular systems in which we are interested fall somewhere in this range, and the points we choose to call “top level” and “implementation” are quite arbitrary. This perspective makes it clear why there is so much confusion over the definitions of “requirements” and “design.” The fact is that one person’s requirement is another person’s design, depending on the particular interests of those people relative to the hierarchy. The methods exactly reflect this hierarchical nature of large systems.