1. Rapid Application Development Paradigm
Lecture 12
Rapid Application Development Paradigm

2. Principles behind the RAD
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.

3. PROBLEMS ADDRESSED BY RAD
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.

4. CHARACTERISTICS OF RAD
RAD USES HYBRID TEAMS
Teams should consist of several people, including both developers and full-time users of the system plus anyone else who has a stake in the requirements.
Developers chosen for RAD teams should be multi-talented people who are analysts, designers and programmers all rolled into one.

5. CHARACTERISTICS OF RAD
RAD USES SPECIALIZED TOOLS THAT SUPPORT ...
"visual" development
creation of fake prototypes (pure simulations)
creation of working prototypes
teamwork and collaboration
use of reusable components
use of standard APIs
version control (because lots of versions will be generated)

6. CHARACTERISTICS OF RAD
RAD uses "timeboxing“ - fixed time frames within which activities are done
Secondary features are dropped as necessary to stay on schedule.

7. CHARACTERISTICS OF RAD
RAD uses prototyping
Evolutionary prototyping – iterate until done
Throw-away prototyping – to capture requirements

8. SCHEDULE vs ECONOMY vs QUALITY
Schedule – faster than average
Quality –
better than average
Economy –
costs less than average

9. SCHEDULE vs ECONOMY vs QUALITY
For RAD, something other than schedule must be negotiable.
RAD has a fair chance of success if the customer will negotiate either economy or quality
RAD has a better chance for success if the customer will negotiate both economy and quality
NOTE: Negotiating quality does NOT mean accepting a higher defect rate. It means accepting a product that is less usable, less fully-featured, or less efficient.

10. SCHEDULE vs ECONOMY vs QUALITY
So, with RAD, one or more of the following goals may be unachievable.
the fewest possible defects
(because developers may not have the legal right to modify the source for some plug-in components)
the highest possible level of customer satisfaction
(because secondary requirements may be sacrificed to stay on schedule)
the lowest development costs
(because buying reusable components may cost more than building)

11. IMPORTANT RAD CONSTRAINTS
Fitness for a “business purpose" must be the criterion for acceptance of deliverables.
Customers, developers and management must accept informal deliverables.
Paper prototypes rather than full-scale systems
Notes from user workshops rather than formal requirements documents
Notes from designers' meetings rather than formal design documents
PRINCIPLE: Create the minimum documentation necessary to facilitate future development and maintenance.

12. IMPORTANT RAD CONSTRAINTS
Development teams must be empowered to make some decisions traditionally left to management.
Iteration must be used in such a way that the development process converges toward an acceptable business solution.
Prototyping must incorporate evolving requirements quickly, in real time, and gain consensus early.

13. RAD TENDS TO WORK WHEN The application will be run standalone.
Major use can be made of preexisting class libraries (APIs, ready components).
Performance is not critical.
Product distribution will be narrow (in-house).
Reliability is not critical.
System can be split into several independent modules.
The project has strong micro-schedule constraints (timeboxes).

14. RAD TENDS TO FAIL WHEN ...
Application must interoperate with existing programs.
Few plug-in components are available.
Optimal performance is required.
Product development can't take advantage of high-end tools (e.g., 4GLs).
Product distribution will be wide (mass market).
RAD methods are used to build operating systems (reliability target too high for RAD), computer games (performance target too high for RAD).
The product is mission- or life-critical.
The system cannot be modularized (defeats parallelism).

15. ADVANTAGES OF RAD
Development conducted at a higher level of abstraction
(because RAD tools operate at that level)
Early visibility
(because of prototyping)
Greater flexibility
(because developers can redesign without changing tones of documentation)
Greatly reduced manual coding
(because of wizards, code generators, code reuse)

16. ADVANTAGES OF RAD Increased user involvement
(because they are represented on the team at all times)
Possibly fewer defects
(due to automatic code generation)
Possibly reduced cost
(because of reuse of existing code, ready components)
Shorter development cycles
(because development tilts toward schedule and away from economy and quality)
Standardized look and feel
(because APIs and other reusable components give a consistent appearance)

17. DISADVANTAGES OF RAD Harder to gauge progress
(because there are no classic milestones)
Less efficient
(because code isn't hand crafted)
Costly
(if the components used are expensive)

18. DISADVANTAGES OF RAD Loss of quality
(because no formal methods are used)
May accidentally empower a return to code-and-fix approach
More defects
(because of the "code-like-hell" syndrome)

19. DISADVANTAGES OF RAD Prototype may not scale up Reduced features
(because of timeboxing, software reuse)
Reliance on third-party components may:
sacrifice needed functionality
add unneeded functionality
create legal problems

20. Prototyping

21. Prototyping
Prototyping is a process of producing a preliminary version of part or a framework of all of an information system which can be reviewed by end-users

22. Prototyping Types: Evolutionary prototyping
Throw-away (disposable) prototyping

23. Evolutionary prototyping
“Refine until done”
Start by designing and implementing the most prominent parts of the program in a prototype and then adding to and refining the prototype until done
Last prototype = ready to release software

24. Evolutionary prototyping
Advantages:
Better user-involvement (feedback)
Better acceptance due to feel of ownership
More clear requirements
Improved progress visibility

25. Evolutionary prototyping
Disadvantages
Poor performance/quality (since designed as for “a prototype”)
Longer development time due to “feature hunger”
Unrealistic performance expectations
Some users could give wrong feedback
Poor maintainability due to lack of documentation

26. Throw-away prototyping
Also known as Disposable Prototyping
Code is developed to explore factors critical the system’s success and then that code is thrown away

27. Throw-away prototyping
Areas of implication
Exploration of unclear requirements
User interface
Reporting
Performance test

28. Throw-away prototyping
Advantages
Clarification of requirements
Time-efficient
Disadvantages
Unrealistic expectations
Keeping alive
Perceived as dublicating of efford

29. Reading
McConnell, S., (1996) Rapid Development: Taming Wild Software Schedules, Microsoft Press

30. The End