New Approaches: RAD, Agile and eXtreme Programming - PowerPoint PPT Presentation

About This Presentation
Title:

New Approaches: RAD, Agile and eXtreme Programming

Description:

New Approaches: RAD, Agile and eXtreme Programming CSIS3600 The Introduction of RAD Rapid Application Development (RAD) is a systems development methodology that grew ... – PowerPoint PPT presentation

Number of Views:197
Avg rating:3.0/5.0
Slides: 39
Provided by: AMCIS2
Category:

less

Transcript and Presenter's Notes

Title: 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/
Write a Comment
User Comments (0)
About PowerShow.com