Lecture 12 Rapid Application Development Paradigm - PowerPoint Presentation

Slide1

Lecture 12

Rapid Application Development Paradigm

Slide2

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.

Slide3

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.

Slide4

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.

Slide5

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)

Slide6

CHARACTERISTICS OF RAD

RAD uses "timeboxing“ - fixed time frames within which activities are done

Secondary features are dropped as necessary to stay on schedule.

Slide7

CHARACTERISTICS OF RAD

RAD uses prototyping

Evolutionary prototyping – iterate until done

Throw-away prototyping – to capture requirements

Slide8

SCHEDULE vs ECONOMY vs QUALITY

Schedule – faster than average

Economy –

costs less than average

Quality –

better than average

Slide9

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

Slide10

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)

Slide11

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.

Slide12

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.

Slide13

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

Slide14

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

Slide15

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)

Slide16

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)

Slide17

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)

Slide18

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)

Slide19

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

Slide20

Prototyping

Slide21

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

Slide22

Prototyping

Types:

Evolutionary prototyping

Throw-away (disposable) prototyping

Slide23

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

Slide24

Evolutionary prototyping

Advantages:

Better user-involvement (feedback)

Better acceptance due to feel of ownership

More clear requirements

Improved progress visibility

Slide25

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

Slide26

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

Slide27

Throw-away prototyping

Areas of implication

Exploration of unclear requirements

User interface

Reporting

Performance test

Slide28

Throw-away prototyping

Advantages

Clarification of requirements

Time-efficient

Disadvantages

Unrealistic expectations

Keeping alive

Perceived as dublicating of efford

Slide29

Reading

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

Slide30

The End