Information Technology Reference
In-Depth Information
surveying potential clients, developing prototypes, and so on, in or
der to refine detailed specifications. The program specifications then
are mostly fixed before the design can start. Carefully developing
the specifications allows the design phase to have a complete outline
of just what is required and what is not required. With that knowl
edge, designers can select algorithms and data storage that take
maximum advantage of the details of the problem. Later, design is
similarly fixed, so coding and testing also can depend on a full un
derstanding of those decisions and framework.
Although this classical development cycle can be effective, each
step typically takes considerable time, and the first version of a
product becomes available only well after the customer or client
first had the idea for the project. Often this time may extend a year
or more from the initial conception of a system to the first release of
software to the client. Unfortunately, in the intervening time, cir
cumstances sometimes change. The original specifications may no
longer address current needs, and the resulting software may not be
as helpful as originally anticipated.
To address the long times generally needed during the classical
development cycle, a relatively recent approach has been to recog
nize that needs change continuously, to develop software in small
increments, and to release new versions of software frequently.
One approach for rapid software development sometimes is called
extreme programming
or
agile programming
. Although this
methodology has many interrelated characteristics, an important
component involves viewing each version of a software package as
another prototype. With each release, the customer(s) can evaluate
current functionality, determine what changes are desired, and
identify new features to be added. Of course, a first streamlined
version of software may take a few months to appear, as it must
contain some minimal functionality, but this can be significantly
shorter than the time for a fullfunctionality version. After this first
version/prototype, subsequent versions may appear every few
weeks, in each case adding functionality and adjusting capabilities
based on user feedback.
Whether following the traditional approach to specifications or
a more streamlined approach, the selection of capabilities for soft
ware normally is userdriven. A developer tries to determine what
customers want and then produces software to meet those needs.
