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 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.
|