Chapter 9 • Methodologies for Custom Software Development 379Advantages- Dramatic savings in development time
- Focuses on essential system requirements
- Ability to rapidly change system design at user request
Disadvantages- Quality may be sacrificed for speed
- Time-consuming commitments for key user personnel
- Possible shortcuts on internal standards and module reusability
FIGURE 9.13 RAD Advantages and Disadvantages- The business (and developers, too) may not know
what is possible with IT, so they may limit their re-
quirements to what they think is possible or to cur-
rent business rules rather than what could be done
with “out-of-the-box” thinking. - Business conditions are constantly changing, so
freezing requirements always means being out of
step once the system is implemented (by the way,
there is a similar truth with textbooks!) - There is often not a consensus about what is required
(due to different situations or cultures in different
user groups), so agreements may not be able to be
reached until well into a project. - Personnel turnover during a project, from both the
user community and the development team, means
new ideas, new skills, and relearning.
Different methodologies attempt to deal with these issues
in different ways.
In recent years an agile software development disci-
pline has emerged as an alternative methodology for smaller
projects (e.g., project teams not larger than 20) in order to ad-
dress some of these issues. The objective is to deliver software
with very low defect rates, based on a set of four key values:
- Simplicity
- Communication
- Feedback
- Courage
A project is not a full application, but rather one mod-
ule or working piece of a full application. These four prin-
ciples are based on “The Agile Manifesto,” which has been
adopted by 17 leaders in the field (see http://www.agileAlliance.
org, http://agilemanifesto.org, and Hoffer et al, 2011).
A “whole team” approach is taken in which business
representatives (customers) and technical team members
(programmers) work in a co-located workspace (some-
times called a bullpen) on a daily basis. Emphasis is placed
on interactions among these participants, rather than on the
processes they follow, tools they use, or formal contracts
between developers and clients. Daily, face-to-face conver-
sations among these core team members, rather than docu-
mentation and interviews with subject matter experts,
dominate requirements determination. Team members use
processes utilizing adaptation rather than planning.
Working versions of software, not artifacts, are measures
of progress, and these working components or increments
(pieces of the whole) are produced very frequently.
Proponents suggest that the more engineering approach of
traditional systems development methods fails because it is
not designed to handle the changing requirements (due to
business changes or better understanding of needs) in most
software development activities. Late changes to require-
ments are welcomed by agile methods. In fact, a core prin-
ciple of agile methods is to respond to change rather than
adhere to a plan. Learning occurs through repletion and
readdressing requirements in increments.
Agile methods are similar to other iterative methods,
such as prototyping and RAD, but differ in that cycles for
delivery of new code products are much shorter (in fact,
timeboxed to be weeks not months) and in the very close
collaboration of team members. Emphasis is on working
software over comprehensive documentation. Figure 9.14Steps Focus
Feasibility
Requirements
Design
Coding
Testing
Documentation
InstallationFunctionalityArchitectureRelease 1 Release 2TimeRelease 3FIGURE 9.14 Agile Systems Development Process