New Approaches: RAD, Agile and eXtreme Programming

1. New Approaches:RAD, 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 • 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

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/newMethodology.html • http://agilemanifesto.org/