csi315 web technology and applications rapid applications development
TRANSCRIPT
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