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 Speed

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

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

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

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

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

Approaches to prototyping

Evolutionary prototyping

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

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