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.
About the author:
The AVS Group is a
marketing, training, and communications company. AVS is in La
Crosse, Wisconsin. AVS helps clients communicate and market
effectively. AVS can be found online at
http://www.avsgroup.com
