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 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 predictionpeople over practices, with an

emphasis on what works in the real world

The Light Weight Methodologies

eXtreme ProgrammingCrystal Development Methodologies

Adaptive Software Development

Open Source MethodsScrumCOADs Feature Driven DevelopmentDynamic System Development Method

Agile MethodsCollaboration of the different light

weight methodologiesCame together at a conference in

Snowbird Utah in February 2001Resulted 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 cyclesfeature- or story-driven developmentcontinuous 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 XP10. 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 ProgrammingProgrammers 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.orghttp://www.cutter.com/research/2000/crb

001003.htmlhttp://www.martinfowler.com/articles/

newMethodology.html http://agilemanifesto.org/