Transcript New Approaches: RAD and eXtreme Programming

New Approaches:
RAD, Agile and eXtreme
Programming
CSIS3600
The Introduction of RAD
Rapid Application Development (RAD) is a
systems development methodology that grew out
of a need to reduce the systems development life
cycle.
James Martin is credited with inventing RAD
and his book was published in 1991.
Martin claims that RAD can produce a system
in six months that would take 24 months using
traditional techniques.
RAD Methodology
RAD is not a single methodology but is a
general strategy for developing information
systems.
There are several different approaches to RAD.
Most of the major consulting firms and software
vendors have implemented some form of a RAD
methodology.
Many of these methodologies are considered
proprietary by their respective companies and
are not publicly shared.
RAD and the SDLC
While RAD shortens the development life
cycle, the basic principles are the same
to rapidly analyze a business problem
to design a viable system solution that meets
the needs of end users
quickly get the finished application in the
hands of users

RAD and the SDLC continued
RAD, however, is not as segmented as
SDLC.
Rather it is based on doing different tasks
in parallel with each other.
The basic premise of RAD is that systems
developers and end users work together
in real-time to develop systems.
4 Phases of RAD
Usually RAD methodologies contain 4
phases
requirements phase
user design
construction
cutover (or rollout).
Phases of RAD
The requirements phase is not much different
than what is included in the SDLC.
Within RAD, this phase is shortened.
For instance, less emphasis is placed on
reviewing current systems and JAD sessions are
usually employed.
RAD is also heavily dependent on software
tools such as CASE tools and other visual
development tools like Powersoft's
PowerBuilder.
RAD and Prototyping
The real key to RAD is its iterative nature
especially within the user design and
construction phases.
End users work jointly with developers
using prototypes.
The goal is to continuously expand and
refine the prototype using constant
feedback from the end users.
Martin's 4 'pillars' of RAD
Software development tools
People trained in the right skills
Coherent methodology which spells out
tasks to be done
Support and facilitation of management
Issues with RAD
RAD is not applicable for all situations.
RAD receives the most criticism from groups
developing large complex systems.
Common problems with RAD include:
Lack of consistency
Programming standards overlooked
Module reuse forgotten
Scalability problems
Ignoring system administration (database
maintenance, backup and recovery procedures, etc.)
RAD and a Methodology
There are NO silver bullets in systems
development
(silver bullet syndrome is the belief that a new and
usually untried technology is all that is needed to
cure the ills of any development project)
But as was stressed in the beginning of this
course, having some form of methodology does
attribute to systems development success.
A methodology keeps a project focused and
provides means for communicating with all
those involved.
Why Light Weight
Cutter Consortium Council fellows
maintain that traditional (heavy)
methodologies "fall short in this new ebusiness environment. They are unable to
keep up with the fast-paced, everchanging e-business projects.“
Council Opinion from Cutter Consortium's
Business Technology Trends and Impacts
Advisory Service (Vol. 1, No. 5)
Why Light Weight
It's virtually impossible to define and
document a stable set of requirements at
the beginning of a project
A light methodology is less structured. It
provides guidance and boundaries,
whereas a heavy methodology dictates
every activity and documentation
Why Light Weight
The Council recommends organizations take the
following actions before moving to a lighter
methodology:
Assess your real needs, strengths, and challenges.
Assess the willingness and ability of your current IT
culture to relax its insistence on heavy methodologies.
Investigate light methodologies and determine how
one or more may fit within your organization.
Act. Pick a project and test one or more of the light
methodologies.
New Methodologies
Martin Fowler's New Methodology,
with its two key attributes:
Adaptation rather than prediction
people over practices, with an
emphasis on what works in the
real world
The Light Weight Methodologies
eXtreme Programming
Crystal Development Methodologies
Adaptive Software Development
Open Source Methods
Scrum
COADs Feature Driven Development
Dynamic System Development Method
Agile Methods
Collaboration of the different light
weight methodologies
Came together at a conference in
Snowbird Utah in February 2001
Resulted in a Manifesto for Agile
Software Development, a statement of
the common values and principles of
agile processes
Manifesto for Agile
Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
What Drives Agile?
The three most crucial things are:
short iteration cycles
feature- or story-driven development
continuous customer feedback
Principles of Agile
Deliver working software frequently,
from a couple of weeks to a couple of
months, with a preference for the
shorter timescale
Business people and developers work
together daily throughout the project
Principles of Agile
Build projects around motivated
individuals, give them the environment
and support they need and trust them to
get the job done
The most efficient and effective method of
conveying information with and within a
development team is face-to-face
conversation
Principles of Agile
Working software is the primary measure of
progress
Agile processes promote sustainable
development. The sponsors, developers and
users should be able to maintain a constant
pace indefinitely
Continuous attention to technical excellence
and good design enhances agility
Principles of Agile
Simplicity—the art of maximizing the
amount of work not done—is essential
The best architectures, requirements and
designs emerge from self-organizing teams
At regular intervals, the team reflects on how
to become more effective, then tunes and
adjusts its behavior accordingly
Extreme Programming (XP): A
New Approach
A deliberate and disciplined approach to
software development
About five years old
Catching on much more quickly in the
UK than in the US
Doesn't work well with large projects or
organizations
XP emphasizes
Customer Satisfaction
Team Work - But Small Development
Teams
Pairs at least 2 programmers together on
one project
Uses simple and 'clean' designs
The 4 Principles of XP
Communication
Simplicity
Feedback
Courage
eXtreme Progamming
12 Practices
1. The Planning Process
 "customer" defines the business value of desired
features to choose what needs to be done and what
needs to be deferred.
2. Small Releases
 Put a simple system into production early, and
update it frequently on a very short cycle.
3. Metaphor
 Use a common "system of names" and a common
system description that guides development and
communication.
12 Practices of XP
4. Simple Design.
 should be the simplest program that meets the
current requirements. There is not much building
"for the future"
5. Testing
 XP teams focus on validation of the software at
all times. Programmers develop software by
writing tests first, then software that fulfills the
requirements reflected in the tests. Customers
provide acceptance tests that enable them to be
certain that the features they need are provided.
12 Practices of XP
6. Refactoring
 XP teams improve the design of the system
throughout the entire development. This is done
by keeping the software clean: without
duplication, with high communication, simple,
yet complete.
7. Pair Programming
 XP programmers write all production code in
pairs, two programmers working together at
one machine.
12 Practices of XP
8. Collective Ownership
 All code belongs to all programmers. This lets
the team go at full speed, because when
something needs changing, it can be changed
without delay.
9. Continuous Integration
 XP teams integrate and build the software system
multiple times per day. This keeps all the
programmers on the same page, and enables
very rapid progress.
12 Practices of XP
10. 40-hour Week
 Tired programmers make more mistakes. XP
teams do not work excessive overtime, keeping
themselves fresh, healthy, and effective.
11. On-site Customer
 An XP project is steered by a dedicated
individual who is empowered to determine
requirements, set priorities, and answer
questions as the programmers have them.
12. Coding Standard
 Programmers write code in the same way, with
rules that make sure the code communicates
clearly
Steps in eXtreme Programming
Customer lists the features that the software
must provide.
Programmers break the features into standalone tasks and estimate the work needed to
complete each task.
Customer chooses the most important tasks
that can be completed by the next release.
Programmers choose tasks, and work in pairs.
Programmers write unit tests.
Steps in eXtreme Programming
Programmers add features to pass unit tests.
Programmers fix features/tests as necessary,
until all tests pass.
Programmers integrate code.
Programmers produce a released version.
Customer runs acceptance tests.
Version goes into production.
Programmers update their estimates based on
the amount of work they've done in release
cycle.
Concluding Thoughts - What
constitutes good design
Designing a system that is easy to read
and maintain
Division of problem solutions into
smaller and smaller pieces
The smaller piece or module is easier to
program, to read and to revise
Concluding Thoughts
Modularization which reflects function and
maximizes cohesion - the extent to which a part
of the system is designed to perform one and
only one function
Modules that perform a single task are easier to
write and maintain
Minimize coupling or the extent to which
different parts of the system are dependent on
each other
Ten of McConnell's 36 Classic
Development Mistakes
People Related:
Weak personnel (in terms of training and skills)
Adding people to a project late
Unrealistic expectations
Process-Related
Insufficient planning
Overly optimistic schedules
Planning to catch up later
Product - Related
Feature creep (adding features as the project
progresses)
Requirements gold plated (having more
requirements than needed)
Technology - Related
Silver-bullet syndrome (when one believes a new
technology, often untried, is all that is needed to
cure the ills of the development project)
Overestimated savings from new tools or methods
McConnell, S. (1996). Rapid Development. Redmond, WA:
Microsoft Press
Resources
http://www.extremeprogramming.org
http://www.cutter.com/research/2000/crb
001003.html
http://www.martinfowler.com/articles/new
Methodology.html
http://agilemanifesto.org/