Managing Information Technology

376 Part III • Acquiring Information Systems

Feasibility Analysis

Prototyping to Define Requirements

Definition Phase

System Design

System Building

System Testing

Construction Phase

Installation

Operations

Maintenance

Implementation Phase

FIGURE 9.9 SDLC with Prototyping to Define Requirements

managers might actually use a working prototype to re-
spond in some way to a current problem or at least to
quickly learn that a given systems approach will not be
the best solution. Although the complete process might
take several months, users might have a working proto-
type in a few weeks or months that allows them to re-
spond to a problem that exists now and is growing in im-
portance; often a business manager cannot wait many
months, let alone years, for a particular system to be
built.
Third, because of the more interactive nature of the
process, with hands-on use of working system models,
strong top-down commitment based on a well-substantiat-
ed justification process might be less necessary at the out-
set of the project. Instead, the costs and benefits of the sys-
tem can be derived after experience with an initial
prototype.
Fourth, initial user acceptance of an application de-
veloped with an evolutionary process is likely to be higher
than with an SDLC process. This is partly because the evo-
lutionary process results in more active involvement and
more joint control of the process on the part of the user.
The disadvantages of an evolutionary methodology
are related to the evolutionary build process. The end pro-
totype typically lacks some of the security and control fea-
tures found in a system developed with an SDLC process.
It also might not undergo the same type of rigorous testing.
Documentation of the final version can be less complete
because of the iterative nature of the process. Because the
focus is on getting the requirements right as well as the
look and feel of the user interface, other critical infrastruc-
ture features of the system may not be quite right.
However, many of these flaws can be corrected in Step 6
when the final prototype is converted to a system that can
go into production. In some cases, it will be necessary for
this final prototype to go through the same audits and con-
trols testing of systems developed by the SDLC before it
can be approved to go into production. Of special concern
will be any dependencies the new system has with existing
systems, usually for the exchange of data.
In the past the operational inefficiencies of fourth
generation tools also contributed to the inadequacies of end
prototypes. However, with recent advancements in hard-
ware and software tools for developers and end users, these
issues have become much less important than implementing
a system that meets user needs. As described earlier, these
potential deficiencies are assessed in Step 5 and corrected in
Step 6 of the evolutionary methodology in Figure 9.8.
Another potential disadvantage is related to manag-
ing user expectations. Frequently, a prototype system ap-
pears to be so good that users are reluctant to wait for a
well-functioning, well-documented operational system.

Prototyping Within an SDLC Process

As fourth generation tools have become commonplace,

the incorporation of a few steps of an evolutionary process

into an SDLC methodology has also become common. In

the following paragraphs we describe two ways that pro-

totyping is commonly incorporated into an SDLC

process.

First, prototyping is used in the Definition phase to

help users define the system requirements, particularly for

the user interface (computer screens and navigation). As

shown in Figure 9.9, the SDLC process still begins with a

feasibility analysis. However, for the requirements defini-

tion step, IS specialists use screen-painting tools to pro-

duce initial versions of screens and reports that users can

experiment with. This might be an example of a nonopera-

tional prototype, in which the screen designs are not con-

nected to a live database. After the requirements have been

determined with the help of a series of prototypes, the rest

of the steps in the SDLC process remain the same.

However, the system builders can also make use of the

screens during the design and build steps, and they may ac-

tually use computer code generated by the prototyping

tools in the final system.

The second way of prototyping used is more

complex and includes a pilot implementation of a work-

ing prototype. This type of prototype is typically a first-

of-a-series type of pilot system. Unlike the pilot rollout

strategy discussed for the Implementation stage of the

SDLC process, in which a complete system is first imple-

mented in only a portion of the organization, here the

intent is to use a scaled-down prototype in only a minimal

number of locations within the organization in order to

assess its feasibility in an operational setting. As shown

in Figure 9.10, the Definition phase of the SDLC process

is replaced by three steps in a Prototyping/Piloting phase.