r.a.d. - rapid application development

A 1986 Movie about a young boy going against the man to win it all in a BMX trick competition

Rad

RAPID APPLICATION DEVELOPMENTjoel@mediotype.comBy Joel

Hart

definition “a software development process that allows usable systems to be built

in as little as 60-90 days, often with some compromises” “a software development methodology that uses minimal planning in favor of rapid

prototyping.”

Ressons to use R.A.D. Bad Reasons: To prevent cost overruns

(RAD needs a team already disciplined in cost management)

to prevent runaway schedules (RAD needs a team already disciplined in time management)

Good Reasons: to converge early toward a design

acceptable to the customer and feasible for the developers

to limit a project's exposure to the forces of change

to save development time, possibly at the expense of economy or product quality

Principals of R.A.D.In certain situations, a usable 80% solution can be produced in 20% of the time that would have been required to produce a total solution.

In certain situations, the business requirements for a system can be fully satisfied even if some of its operational requirements are not satisfied.

In certain situations, the acceptability of a system can be assessed against the agreed minimum useful set of requirements rather than all requirements.

Problems? With Development Projects?

NEVER!

Problems addressed

With conventional methods, there is a long delay before the customer gets to see any results.

With conventional methods, development can take so long that the customer's business has fundamentally changed by the time the system is ready for use.

With conventional methods, there is nothing until 100% of the process is finished, then 100% of the software is delivered.

Iteration must be used in such a way that the development process converges toward an acceptable business solution.

RAD USES ITERATIVE, EVOLUTIONARY PROTOTYPING

What’s SDLC? Software Development Lifecycle

R.A.D. SDLC

Development teams must be empowered to make some decisions traditionally left to management.

Step 1

JAD (Joint Application Development) MEETINGHigh-level end-users and designers meet in a brainstorming session to generate a rough list of initial requirements.• Developers talk and listen

• Customers talk and listen"Fitness for a business purpose" must be the criterion for acceptance of deliverables. – Sun Microsystems

Step 2 ITERATE UNTIL DONE

Developers build / evolve prototype based on current requirements.

Designers review the prototype.

Customers try out the prototype, evolve their requirements.

FOCUS GROUP meetingCustomers and developers meet to review product together, refine requirements, generate change requests.

Developers listen.

Customers talk.

Requirements and change requests are "timeboxed".

Changes that cannot be accommodated within existing timeboxes are eliminated.

If necessary to stay "in the box," secondary requirements are dropped.

All constituencies that can impact application requirements must have representation on the development team throughout the process.

Prototyping must incorporate evolving requirements quickly, in real time, and gain consensus early.

Iterations require between 1 day and 3 weeks.At some stage, exploratory prototypes may evolve into operational prototypes.Focus Group Sessionslast about 2 hours

are led by an experienced facilitator, who keeps the group "on focus"

by having clear goals regarding the kind of information that needs to be elicited

by preparing an issue-oriented agenda in advance of the meeting

by ensuring that adequate discussion is directed toward each issue

by ensuring everyone has an adequate opportunity to participate

are followed by a report from the facilitator

Customers, developers and management must accept informal deliverables.

R.A.D. ! But When ??? RAD TENDS TO WORK WHENThe application will be run standalone.Major use can be made of preexisting class libraries (APIs).Performance is not critical.Product distribution will be narrow (in-house or vertical market).Project scope (macro-schedule) is constrained.Reliability is not critical.System can be split into several independent modules.The product is aimed at a highly specialized IS (information systems) market. The project has strong micro-schedule constraints (timeboxes).The required technology is more than a year old.

RAD TENDS TO FAIL WHENApplication must interoperate with existing programs.Few plug-in components are available.Optimal performance is required.Product development can't take advantage of high-end IS tools (e.g., 4GLs).Product distribution will be wide (horizontal or mass market).RAD becomes QADAD (Quick And Dirty Application Development).RAD methods are used to build operating systems (reliability target too high for RAD), computer games (performance target too high for RAD).Technical risks are high due to use of "bleeding" edge technology.The product is mission- or life-critical.The system cannot be modularized (defeats parallelism).

Huh? It sounds a lot like Agile!

R.A.D. Is Not Agile

10 Reasons R.A.D. != Agile Agile embraces the concept of contract first development required for either Object Orientated or Service Orientated

architecture – RAD did not acknowledge the realities of designing to interfaces, partially because it preceded the widespread use of these techniques.

Agile does not allow prototypes – RAD was based on designing prototypes and then reengineering them into production quality code (or not as was often the case).

Agile projects logically break down the solution into features – the RAD approach did not do this; instead developers would focus on delivering all the features of the application by first doing it badly and then improving on the code base overtime..

Agile teams are democratic. This means that the whole team has a say in the architecture of the solution, but the team is still lead by an architect. In contrast, RAD solutions were not based around the concept of a common architecture and thus individuals worked in silos.

Agile development team members are self managing. In contrast, RAD teams are managed by a project manager. Note do not confuse the term management with leadership.

Agile engineering practices (such as test driven development, and continuous integration) are stringent and thorough, ensuring that problems in the design or the code base are highlighted and fixed as quickly as possible, and that the team has the confidence to change the code base without breaking the product. None of these concepts were used in RAD projects.

Agile teams focus on team communication and designing as a group. RAD teams tend to work as individuals, resulting in unmaintainable and poorly designed code.

Agile teams only demonstrate completed work. RAD teams tend to demonstrate screen mockups, or prototypes, which lead the product owner to question why they now need to wait another six months for the completed product.

Agile teams are based around disciplined individuals that remain continually focused on delivering real software. RAD teams lack discipline, simply because there was no structure to either the process, architecture or engineering practices.

Agile teams are inclusive of testers and analysts and user experience specialists. RAD teams did not traditionally include non technical team members.

What makes the most sense?

Well what do I do now?