Chapter 9 • Methodologies for Custom Software Development 373redo some aspects of the prior step, but there is usually great
resistance to going back several steps, even when the situation
demands this. Hence, it is not uncommon that a project is ter-
minated at a milestone because the project is not going well or
the business situation has changed since the project began.
Fifth, the role of system users, and in fact each partic-
ipant, is usually very narrowly defined. This can be restric-
tive for technology-savvy users, especially in organizations
that regularly move employees between IT and general
business positions as part of their career development.
Finally, the SDLC tends to enforce strict dates for
each milestone and completion. If these dates are not met,
for whatever reason, the project may be deemed a failure.
Although it is good to place realistic time limits on any
project, time to completion is but one of three project
trade-offs (along with project scope and project resources).
Next we look at an alternative approach to systems
development that addresses some of these disadvantages.
Prototyping Methodology
The SDLC methodology is based on the premise that busi-
ness requirements for the system will be static over the life
of the project. Thus, the system requirements must be
completely and finally specified before the Construction
phase is begun. Once the requirements have been agreed
upon, changing them leads to significant project costs and
potential schedule delays.
In the second half of the 1980s, the growing availabil-
ity of fourth generation nonprocedural languages and rela-
tional database management systems began to offer an al-
ternative approach. These tools make it possible to initially
build a system (or part of a system) more quickly and then
repeatedly revise it after users have tried it out and provided
their feedback to the developers. Thus, rather than first ini-
tially defining the system on paper and then building it, the
initial system can be revised based upon the user’s experi-
ence and understanding gained from the earlier versions.
This approach is very powerful because, although
most people find it very difficult to specify in great detail
exactly what they need from a new system, it is quite easy
for them to point out what they do not like about computer
screens that they can try out and use.
This general approach is most commonly known as
prototyping.It is a type of evolutionary development
process. The prototyping concept can also be applied to a
process in which a real system is developed for the user to
try out as well as for situations in which only a “toy” (non-
operational, usually thrown away without converting to an
operational system) prototype is developed. For example,
prototype input and output screens are often developed for
users to work with as part of the requirements definition or
detailed design steps. Other examples of prototyping in-
clude a “first-of-a-series” prototype in which a completely
operational prototype is used as a pilot and a “selected fea-
tures” prototype in which only some essential features are
included in the prototype and more features are added in
later modules (Kendall and Kendall, 1999).
In the next section, we first discuss prototyping as a
complete alternativeto the traditional SDLC methodolo-
gy: its steps, project management considerations, and its
overall advantages and disadvantages in comparison to an
SDLC methodology. This approach is particularly attrac-
tive when the requirements are hard to define (“we’ll know
what we want when we see it”), when one or a few stake-
holders/users are involved, when a critical system is need-
ed quickly, when communication problems have existed in
the past between end users and developers, or when the
system will be used infrequently (or even only once)—so
that operating efficiency is not a major consideration. Note
that these are all system characteristics that apply to some
types of managerial support systems.
Prototyping as an alternative to an SDLC methodol-
ogy is impractical for large, complex system efforts.
However, when prototyping is used withinan SDLC
process to help determine requirements of a new custom
application, it can increase the likelihood that the system
project is a success. Prototyping provides a practical way
for organizations to experiment with real systems, not just
abstract diagrams, where the requirements are not totally
clear and where the probability of success is unclear but
the rewards for success appear to be very high.The Prototyping Steps
Figure 9.8 presents the steps for an evolutionary methodol-
ogy for developing a new, working system. The process be-
gins with the identification of the basicrequirements of the
initial version of the system (Step 1). The analyst/builder(s)
and user(s) meet and agree on the inputs, the data process-
ing, and the system outputs. These are not complete de-
tailed requirements; rather, this is a starting point for the
system. If several builders and users are involved, a joint
application design (JAD) session may be used to determine
requirements (see the description of JAD in the section en-
titled “Newer Approaches” later in this chapter).
In Step 2, the system builders produce an initial pro-
totype system according to the basic requirements agreed
on in Step 1. The system builders select the software tools,
locate the necessary data and make these data accessible to
the system, and construct the system using higher-level
languages. This step should take from a few days to a few
weeks, depending on the system’s size and complexity.
Note, this step works best when high-quality data already