Page 63 -

34 PART ONE THE PRODUCT AND THE PROCESS

The RAD process model is illustrated in Figure 2.6. Obviously, the time constraints
imposed on a RAD project demand “scalable scope” [KER94]. If a business applica-
tion can be modularized in a way that enables each major function to be completed
in less than three months (using the approach described previously), it is a candidate
for RAD. Each major function can be addressed by a separate RAD team and then
integrated to form a whole.
Like all process models, the RAD approach has drawbacks [BUT94]:
XRef
RAD makes heavy use of • For large but scalable projects, RAD requires sufficient human resources to
reusable components.
For further information create the right number of RAD teams.
on component-based • RAD requires developers and customers who are committed to the rapid-fire
development, see
Chapter 27. activities necessary to get a system complete in a much abbreviated time
frame. If commitment is lacking from either constituency, RAD projects will
fail.
• Not all types of applications are appropriate for RAD. If a system cannot be
properly modularized, building the components necessary for RAD will be
problematic. If high performance is an issue and performance is to be
achieved through tuning the interfaces to system components, the RAD
approach may not work.
• RAD is not appropriate when technical risks are high. This occurs when a new
application makes heavy use of new technology or when the new software
requires a high degree of interoperability with existing computer programs.

2.7 EVOLUTIONARY SOFTWARE PROCESS MODELS

There is growing recognition that software, like all complex systems, evolves over a
period of time [GIL88]. Business and product requirements often change as devel-
opment proceeds, making a straight path to an end product unrealistic; tight market
deadlines make completion of a comprehensive software product impossible, but a
limited version must be introduced to meet competitive or business pressure; a set
of core product or system requirements is well understood, but the details of prod-
uct or system extensions have yet to be defined. In these and similar situations, soft-
ware engineers need a process model that has been explicitly designed to
accommodate a product that evolves over time.
The linear sequential model (Section 2.4) is designed for straight-line develop-
ment. In essence, this waterfall approach assumes that a complete system will be
delivered after the linear sequence is completed. The prototyping model (Section
2.5) is designed to assist the customer (or developer) in understanding require-
ments. In general, it is not designed to deliver a production system. The evolu-
tionary nature of software is not considered in either of these classic software
engineering paradigms.