Prototyping is one of the most important aspects of our development process. We consider the act of prototyping to be a risk mitigation strategy. If approached correctly, we believe that prototyping can reduce the risks in Web application development. In addition, by reducing risks we are often able to reduce project costs.

Prototyping may be done in a number of ways and it may actually employ more than one method over the course of development.

We may begin with hand drawn diagrams and flowcharts to represent User Interface (UI) elements and business processes. These drawings are then converted into HTML-based prototypes of the UI that incorporate a minimal level of functionality.

Customer acceptance tests are then prepared to document the required functionality. These tests are then validated against the prototype, as well as the established business, user and system requirements to ensure that the final system meets the stated goals of the project.

We emphasize to clients that testing should begin early and should be carried out continuously. Testing begins during requirements analysis and prototyping when project managers work with the customer to develop high-level Customer Acceptance Tests that validate the business, user, and system requirements.

During development, unit tests ensure that individual, functional packages of code at the lowest levels do what they are designed to do. Integration testing ensures that all the parts (i.e. functional packages of code) that make up a system function together to meet the specified requirement.

Final Acceptance Testing validates the completed system against the requirements as defined during the requirements analysis and prototyping phase. When all of the final acceptance tests have passed, the system should be ready for production.

Small releases provide positive results to clients in a timely manner, adding value to their business processes as quickly as possible.

Small releases also prevent the project from straying too far from the intended goals before the direction can be corrected. In this regard smaller releases can be considered a risk mitigation strategy as well. The key to a small release approach is to identify the individual subsystems that make up the larger system and rank those subsystems by importance. The most important pieces are then delivered first to add value quickly.

Pair programming is the most difficult to implement of all the development processes identified in this article. While we do not advocate pair programming in all instances, we do feel that there is great value to be gained in many cases. Clients are generally concerned about the development costs of a system. And while the idea of having two developers working side-by-side on the same piece of code may seem counterintuitive, cost savings can be achieved due to shorter testing cycles and less rework as a result of pair programming.

At the same time, managers see the use of two people on one task to be a waste of valuable resources, which can be true if the task is not of sufficient complexity. However, in those situations where it fits, if quality is increased and testing and rework reduced, then we believe the trade-offs are warranted.