New Approaches: RAD, Agile and eXtreme Programming

1
New ApproachesRAD, Agile and eXtreme Programming

• CSIS3600

2
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.

3
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.

4
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

5
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.

6
4 Phases of RAD

• Usually RAD methodologies contain 4 phases
• requirements phase
• user design
• construction
• cutover (or rollout).

7
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.

8
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.

9
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

10
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.)

11
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.

12
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)

13
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

14
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.

15
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

16
The Light Weight Methodologies

• eXtreme Programming
• Crystal Development Methodologies
• Adaptive Software Development
• Open Source Methods
• Scrum
• COADs Feature Driven Development
• Dynamic System Development Method

17
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

18
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.

19
What Drives Agile?

• The three most crucial things are
• short iteration cycles
• feature- or story-driven development
• continuous customer feedback

20
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

21
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

22
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

23
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

24
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

25
XP emphasizes

• Customer Satisfaction
• Team Work - But Small Development Teams
• Pairs at least 2 programmers together on one
  project
• Uses simple and 'clean' designs

26
The 4 Principles of XP

• Communication
• Simplicity
• Feedback
• Courage

27
eXtreme Progamming 12 Practices

• The Planning Process
• "customer" defines the business value of desired
  features to choose what needs to be done and what
  needs to be deferred.
• Small Releases
• Put a simple system into production early, and
  update it frequently on a very short cycle.
• Metaphor
• Use a common "system of names" and a common
  system description that guides development and
  communication.

28
12 Practices of XP

• Simple Design.  
• should be the simplest program that meets the
  current requirements. There is not much building
  "for the future"
• 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.

29
12 Practices of XP

• 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.
• Pair Programming
• XP programmers write all production code in
  pairs, two programmers working together at one
  machine.

30
12 Practices of XP

• 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.
• 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.

31
12 Practices of XP

• 40-hour Week
• Tired programmers make more mistakes. XP teams do
  not work excessive overtime, keeping themselves
  fresh, healthy, and effective.
• 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.
• Coding Standard
• Programmers write code in the same way, with
  rules that make sure the code communicates clearly

32
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.

33
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.

34
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

35
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

36
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

37

• 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

38
Resources

• http//www.extremeprogramming.org
• http//www.cutter.com/research/2000/crb001003.html
  
• http//www.martinfowler.com/articles/newMethodolog
  y.html
• http//agilemanifesto.org/