Vous êtes sur la page 1sur 38

New Approaches:

RAD, Agile and eXtreme


Programming
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 e-
business environment. They are unable to
keep up with the fast-paced, ever-
changing 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
Simplicitythe art of maximizing the
amount of work not doneis 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 stand-
alone 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/crb001003.html
http://www.martinfowler.com/articles/newMethodology.html
http://agilemanifesto.org/

Vous aimerez peut-être aussi