As the example discussed in the previous sections indicate, SPE techniques should be integrated into the software development life cycle. Several methodologies for software development have been proposed and used successfully in the software industry. Consider, for example, the waterfall model, introduced by Boehm , which decomposes the software development life cycle into five main phases: requirement analysis and specification, system design, program design, program coding, and system testing. Fig. 9.9 illustrates these various phases and the relationships between each phase.
Figure 9.9. Waterfall model of software development.
The requirement analysis and specification phase describes the problem to be solved by the new software. As a result of this phase, two types of requirements are generated: functional and non-functional requirements. The functional requirements describe the activities that the new system is supposed to perform. The non-functional requirements include SLAs on response times, throughputs, and availability, as well as a specification of the target hardware/software platform. This includes a specification of the processors, storage devices, operating system, database management system, transaction processing monitors, and middleware, of the target hardware/software platform.
The system design phase describes the solution to the problem specified in the previous requirements phase. The system is decomposed into modules and pseudo code for each module is generated. The relationship between modules is established and the type of data used by each module is specified. The number of invocations per module are derived from the system design. This allows a first approximation of the service demands. Performance predictions obtained with SPE data collected during this phase should be within 30% of the actual performance of the fully implemented application .
The third phase, program design, describes the mechanisms that best implement the solution. Algorithms and data structures are specified in this phase. Each of the modules resulting from the system design phase is mapped into one or more programs. A complete specification of each transaction is given in this phase. This specification is generally given in some form of pseudocode and is independent of the target programming language. Clisspe is appropriate in this phase. More precise estimates of the transaction service demands may be obtained in this phase since the number of I/O operations and/or DBMS calls can be derived from the transaction descriptions. The accuracy of the predictions obtained in this phase is expected to be in the range 15 to 20% .
The actual implementation occurs during the program coding phase. This phase is used to refine the I/O and CPU service demands for the various transactions as they are implemented. Test experiments of each transaction type on the target software/hardware platform are possible. These yield accurate values for I/O and CPU demands.
The final phase is system testing. In this phase, an overall verification of I/O and service demand estimates is performed. Validation of performance predictions made by the models is possible.
Each phase of the software development life cycle increases the level of accuracy of the service demand estimates. The initial models developed during the early stages of the design can only be expected to provide gross order-of-magnitude performance predictions. Gunther indicates that progressively more accurate data can be captured in each phase of the software development life cycle using the spiral methodology for software development .
9.4.1 Obtaining Data for SPE
Application sizing involves cooperating with people from several departments, mainly the developers. This may pose problems of a managerial nature. Developers must appreciate and value the importance of SPE so that they assign it enough importance and give priority to it . Numerous approaches can be used to obtain cooperation from people that should provide data for SPE  .
The primary difficulties in obtaining the proper data may arise from :
It should also be realized that not all transactions will have a relevant impact on performance. In fact, as observed by practitioners [5, 15], more than 80% of user requests result in less than 20% of the transactions. This 80-20 rule of thumb calls for giving priority to obtaining SPE data for the 20% most frequent transactions.
Whenever there is a high degree of uncertainty over the value of a given service demand or workload intensity parameter, the use of best-case and worst-case analysis is appropriate . In the process of refining the estimates, resources that have the greatest impact on performance should be identified. It is important to concentrate most of the effort in trying to obtain better estimates for the key parameters .
The service demand, Di,r, of class r transactions at device i is estimated as follows in an SPE study:
The flow of control of each transaction or application determines the average number of times that a certain portion of the code is executed. For example, the analysis of a specification of a transaction in Clisspe allows for the easy computation of ns and ps through the nesting of loops and through branching statements . can be obtained from simple experiments.