The Development Process

Development begins with requirements and design, culminating in implementation after the finalization the requirements and design phases. Choose a development process that takes performance and footprint issues into account from the very beginning. The following sections discuss how performance and footprint fit in the overall development process.

Prototyping

Build prototypes to show the client a more concrete idea of what the final product will look like. Keep in mind, however, that a prototype does not have to be a fully functional test version of a product. In fact, the purpose of prototyping is to offer the clients and developers a chance to get their heads pointed in the same direction before investing much development effort. The prototype is, therefore, more of a simulation. It hints at the look and feel of the interface and the functionality it offers.

Often, a prototype is nothing more than a user interface that has stubbed functionality. The stubs deliver predefined values instead of doing actual data processing. Or the prototype might be nothing more than a set of slides or drawings. Whatever its setup, it tests the completeness of the requirements and design.

As previously discussed, requirements are determined interactively with the client. After this, the design is made from the written requirements specification. However, these steps should not be seen as directly derivable; moreover, they are the result of translations. The person writing the requirements specification translates the interaction with the client into technical and nontechnical requirements. Quite likely, some elements will be lost in the translation because of the different backgrounds and focus of the writer and the client. For example, the writer might miss exact insight in the everyday work situation of the client, and the client, in turn, might miss insight in what is technically possible. This scenario can repeat itself in the design phase, where the original requirements may have been right on the nose. They are, however, translated once more, this time by people who are probably even more technically oriented. It is not a luxury to stand still at this point in the process and ask the client whether he still agrees with the vision finally put forward in the design. The prototype is something that clients can directly comment on.

While building prototypes, it is a good idea to keep the following issues in mind.

• Make sure the client is aware that the prototype is a simulation and not the real thing.

• The downside of a good prototype (simulation) is that the client cannot easily assess how much of the work has already been done. The client may assume that the demo constitutes the final product. During the demo, make clear to the client that all results are artificial—that the user interface is just an initial setup that does not actually do anything.

• Although it is possible for a demo to be quite fast, it is wise to avoid perceived performance issues by keeping the prototype's speed consistent with that of the final product. This will deter any false expectations on the client's behalf. It is, therefore, a good idea to use initial response predictions to build artificial slowdown into the prototype. Just make the user interface wait a specified number of seconds before it produces the predefined results. Even more prudent would be to add a percentage of overhead to the worst-case predicted responses. This way, it should be possible to make each following version of the program (prototype, alpha version, beta version, and so on) increasingly responsive.

• Footprint and other target impressions need the same treatment, as was mentioned in the previous bullet. Although most prototypes are unlikely to be resource intensive, it is a good idea to pay attention to the hardware used for the demo. This is because the client may not fully understand the technical implications of prototyping and may not even think to ask if the final product needs more memory, disks, or processing speed than the system on which the prototype runs.

Scheduling Performance and Footprint Measurements

The actual implementation begins after it is clear that the requirements and design reflect what the client has in mind. During implementation, it is important to keep doing performance and footprint tests.

Often, implementation problems occur only when the final product (be it in the alpha, beta, or release stage) is tested for performance and footprint problems. Developers might discover that the program does not run as fast as expected when used in a network with 50 users, or that the product no longer fits on the hard disk initially chosen. To avoid having to reengineer the existing code, it is better to incorporate frequent performance and footprint tests in the implementation planning.

Performance and footprint trouble can be identified early on in the implementation stage by looking for the following signs:

• Performance and footprint restrictions are getting tight, even though a sizable amount of functionality still has to be added.

• Performance and footprint test results differ disproportionately from previous tests. As the program grows, you expect it to be slower and larger, but sudden jumps in size and slowdown can indicate something has gone wrong.

• Unpredictable results. If the same test with the same software version of the project generates different results, there is some kind of dynamic behavior in play—the software test results lack reproducibility. Perhaps the program is suffering from memory leaks.

Another advantage of scheduling these tests in the planning is that implementers get used to the idea of doing performance and footprint testing as part of the development cycle. During implementation, they will be more aware of its importance and be continually reminded of the perhaps less-visible requirements for these topics.