1. CSI315 Web Technology and Applications
Rapid Applications Development

2. Software Process Models-A Reminder
Waterfall Model (classic and oldest)
Rapid OR Evolutionary development-prototyping
Formal Transformation
Integration from re-usable components

3. 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:

4. The Aim of RAD
Low Cost
High
Quality
Speed

5. Traditional SDLC Problems 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

6. Requirement Planning Phase
RAD Life Cycle
User Design Phase
(including prototype construction)
Cutover
Construction Phase
Requirement Planning Phase

7. RAD-Phases Requirements 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

8. 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 Model
RAD uses prototype to design and refine data. Data model and process model and prototype evolve in parallel.
Parallel Development
System is devided into chunks that can be developed and tested independently. Data and process models interlinked

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

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

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

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

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

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

15. RAD Techniques Prototyping Integrated Software-CASE Time box approach
JAD

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

17. Prototyping process

18. Approaches to prototyping

19. Evolutionary prototyping

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

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

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

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

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

25. Throw-away prototyping

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

27. TUTORIAL Integrated Software-CASE Time box approach
Joint Application Design