Performance

Engineering
Services

Old Approach

Many organizations have used a "fix-it-later" approach to performance. This approach advocated concentrating on correctness and deferring consideration of performance until the testing phase. Performance problems detected then, were corrected by adding additional hardware, tuning the software (usually in a crisis-mode), or both.

Because it is based on several performance myths, this approach can be dangerous. These myths include:

• Performance problems are rare: The reality is that the number, size and complexity of systems has increased dramatically and todays developers are less expert at dealing with performance than their predecessors. As a result, performance problems are all too common.
• Hardware is fast and inexpensive: The reality is that processor speeds have increased dramatically, but networks are far slower. Furthermore, software threading issues cause performance problems despite the availability of hardware resources. No one has an unlimited hardware budget, and some software may require more resources than the hardware technology can provide.
• Responsive software costs too much to build: This is no longer true thanks to SPE methods and tools. In fact, the "fix-it-later" approach is likely to have higher costs.
• You can tune it later: This myth is based on the erroneous assumption that performance problems are due to inefficient coding rather than fundamental architectural or design problems. Re-doing a design late in the process is very expensive.

Engineering Alternative

SPE provides an engineering approach to performance, avoiding the extremes of performance-driven development and "fix-it-later." SPE uses model predictions to evaluate trade-offs in software functions versus hardware costs. The models assist developers in controlling resource requirements by selecting architecture and design alternatives with acceptable performance characteristics. They aid in tracking performance throughout the development process and prevent problems from surfacing late in the life cycle (typically during performance and stress testing).

Is SPE Viable for Your Projects?

SPE is tried and proven technology – performance experts have always used these techniques for building high-performance software. Beginning in 1981, with an award-winning paper that first coined the term "software performance engineering," the techniques have become more accessible to non-performance experts. Performance management products such as SPE·ED now make it quick and easy to evaluate software/hardware plans early in development. Books explain the techniques. Consulting and mentoring services are available to help you get started. So the following aspects of a new performance paradigm are now achievable:

• You can deliver that application on time and within budget while meeting your performance requirements - with the first release.
• You can know the hardware capacity requirements for your new application before it is developed.
• Architects know that their architecture will support performance requirements before committing to code.
• Project managers can track the status of performance while the software is being developed.
• Performance specialists have time to run performance tests, load and stress tests without encountering "surprises."
• Risks to achieving performance requirements are identified and addressed early in the process, saving both time and money.
• Software that meets performance requirements is delivered on time and within budget.

SPE is language and platform independent. Performance models are constructed from architectural and design-level information. Thus, SPE works with C++, C# and Java as well as with other object-oriented and non-object-oriented languages. The execution behavior of the software will be different with different languages and platforms. Nevertheless, this is reflected in the resource requirement specifications, not the model structure.

SPE uses deliberately simple models of software processing with the goal of using the simplest possible model that identifies problems with the system architecture, design, or implementation plans. It is relatively easy to construct and solve these models to determine whether the proposed software is likely to meet performance requirements. As the software development process proceeds, we refine the models to more closely represent the performance of the emerging software and re-evaluate performance.

SPE can be easily integrated into the software development process. It has been used with traditional process models, such as the waterfall model. It works especially well with iterative, incremental processes such as the Unified Process. With an iterative, incremental process, you can use SPE techniques to assess and reduce the risk of performance failure at the project outset, and at each subsequent iteration.