CSI315 Web Technology and Applications

Rapid Applications Development

Software Process Models-A Reminder

• Waterfall Model (classic and oldest)• Rapid OR Evolutionary

development-prototyping• Formal Transformation• Integration from re-usable

components

Definition• RAD refers to a development life-cycle

designed to give much faster development and higher-quality results than those achieved with the traditional life-cycle

• Provides a series of techniques for compressing the analysis, design, build and test phases into a series of short iterative development cycles

• RAD developments places more emphasis on the importance of the user in the development process:

The Aim of RAD

Low Cost

High Quality

High Speed

Traditional SDLCProblems of traditional “waterfall

life” cycle:• developments are rarely sequential• users often do not know what they

want• errors in design may not be obvious

until very late in the project• is not the best model for modern

development tools• addresses technical rather than user

needs

RAD Life Cycle

User Design Phase(including prototype construction)

Cutover

Construction Phase

Requirement Planning Phase

RAD-PhasesRequirements and Planning: Define model, data

requirements

User Design Phase: Model and prototype design, data conversion, test plan

Construction: Complete application dev, develop data conversion modules, conduct user testing

Cutover: Install Application, Implement Conversion Plan, end-user training

RAD vs Traditional SDLC

Process Model SDLC uses logical process model to define reqs, physical process model defines system design

RAD a prototype is a major component of the process model and it is used for user reqs and system design

Data ModelRAD uses prototype to design and refine data. Data model and process model and prototype evolve in parallel.

Parallel DevelopmentSystem is devided into chunks that can be

developed and tested independently. Data and process models interlinked

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.

Why use RAD?

• 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

WHEN NOT TO USE

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

• Performance is mission critical• Avoid if building OS, wide mass

market/distribution or if the system cant be modularized

Advantages of RAD• Time savings in overall project phases• Reduces Overall project costs and

human resources• System Design Changes can be

effected• User Perspective is represented in the

final (Functionally and Interface)• Creates a strong sense of ownership

Disadvantages of RAD

• Focus in time & delivery cost may result in lower functionality

• Little time left on overall business view of the environment

• Less consistency and integration with other organizational systems

• Document quality and conformity reduced

• System scalability difficult

Rapid Development Tools• Various techniques may be used for

rapid development– Dynamic high-level language development– Database programming– Component and application assembly

• These are not exclusive techniques - they are often used together

• Visual programming is an inherent part of most prototype development systems

RAD Techniques• Prototyping• Integrated Software-CASE• Time box approach• JAD

Prototyping• A process of building a model that

demonstrates the features of a proposed product.

• A prototype is a model of the proposed product. It reduces the risk of delivering a system that does not meet their needs.

Prototyping process

Establishprototypeobjectives

Defineprototype

functionality

Developprototype

Evaluateprototype

Prototypingplan

Outlinedefinition

Executableprototype

Evaluationreport

Approaches to prototyping

Evolutionaryprototyping

Throw-awayPrototyping

Deliveredsystem

Executable Prototype +System Specification

OutlineRequirements

Evolutionary prototyping

Build prototypesystem

Develop abstractspecification

Use prototypesystem

Deliversystem

Systemadequate?

YES

N

Evolutionary prototyping

• Specification, design and implementation are inter-twined

• The system is developed as a series of increments that are delivered to the customer

• Techniques for rapid system development are used such as CASE tools and 4GLs

• User interfaces are usually developed using a GUI development toolkit

Evolutionary prototyping

• Must be used for systems where the specification cannot be developed in advance e.g. AI systems and user interface systems

• Based on techniques which allow rapid system iterations

• Verification is impossible as there is no specification. Validation means demonstrating the adequacy of the system

Evolutionary prototyping advantages

• Accelerated delivery of the system– Rapid delivery and deployment are

sometimes more important than functionality or long-term software maintainability

• User engagement with the system– Not only is the system more likely to

meet user requirements, they are more likely to commit to the use of the system

Evolutionary prototyping problems• Management problems

– Existing management processes assume a waterfall model of development

– Specialist skills are required which may not be available in all development teams

• Maintenance problems– Continual change tends to corrupt system

structure so long-term maintenance is expensive

• Contractual problems

Throw-away prototyping

• Used to reduce requirements risk• The prototype is developed from an initial

specification, delivered for experiment then discarded

• The throw-away prototype should NOT be considered as a final system– Some system characteristics may have been left out– There is no specification for long-term maintenance– The system will be poorly structured and difficult to

maintain

Throw-away prototyping

Outlinerequirements

Developprototype

Evaluateprototype

Specifysystem

Developsoftware

Validatesystem

Deliveredsoftwaresystem

Reusablecomponents

Throw-away Prototype Problems

• Developers may be pressurised to deliver a throw-away prototype as a final system

• This is not recommended– It may be impossible to tune the prototype

to meet non-functional requirements– The prototype is inevitably undocumented– The system structure will be degraded

through changes made during development– Normal organisational quality standards

may not have been applied

TUTORIAL

• Integrated Software-CASE• Time box approach• Joint Application Design