Rapid Application Development Paradigm Lecture 12 Rapid Application Development Paradigm

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.

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.

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.

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)

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

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

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

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.

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)

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.

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.

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).

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).

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)

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)

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)

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)

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

Prototyping

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

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

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

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

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

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

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

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

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

The End