3. Was developed by IBM in 1980
Also known as Rapid application model
Type of incremental model
Need software quickly
Software can be divided into modules
Need more people
People should be high skilled
User should be involved all through the life cycle
Short span of time (2-3 months)
High cost
4.
5. Communication
Collect Information or requirements from user
Planning
Creating of a set of plans to help guide your team
Modeling
Business Modeling
On basis of the flow of information and distribution between
various business channels, the product is designed.
Data Modeling
The information collected from business modeling is refined
into a set of data objects that are significant for the business.
6. Process Modeling
The data object that is declared in the data modeling phase
is transformed to achieve the information flow necessary to
implement a business function
Application Generation
Automated tools are used for the construction of the software, to
convert process and data models into prototypes.
Testing and Turnover
As prototypes are individually tested during every iteration, the
overall testing time is reduced in RAD
Contruction
it highlighting the use of pre-existing software component.
Deployment
Deliver to user
7.
8. Flexible and adaptable to changes
Due to code generators and code reuse, there is a
reduction of manual coding
Due to prototyping in nature, there is a possibility
of lesser defects
It is useful when you have to reduce the overall
project risk
9. It can't be used for smaller projects
If developers are not committed to delivering
software on time, RAD projects can fail
Requires highly skilled designers or developers
11. Requirements are broken down into multiple standalone
modules
Incremental development is done in steps from analysis
design, implementation, testing/verification,
maintenance.
The system is put into production when the first
increment is delivered.
The first increment is often a core product where the
basic requirements are addressed.
Supplementary features are added in the next
increments.
Once the core product is analyzed by the client, there is
plan development for the next increment.
12. Customer feed back is received after the delivery of each
component
Risk of requirement changes is reduced
More flexible
Easy to test and debug
Give quick result
13. Needs proper plan to integrate the components
Needs proper design to integrate the components
More expensive as compared to waterfall model
14.
15. Communication
Gathering requirement or information from user
Planning
Estimating scheduling tracking
Modeling
Analysis design
Construction
Write code test
Deployment
Deliver to user and get feedback
16. Simple and easy to understand and use
Easy to manage due to the rigidity of the model. Each phase has
specific deliverables and a review process.
Phases are processed and completed one at a time.
Works well for smaller projects where requirements are very well
understood.
Clearly defined stages.
Well understood milestones.
Easy to arrange tasks.
Process and results are well documented.
17. Difficult for the customer to state all the requirement explicitly
Assumes patience from customer - working version of program will
not available until programs not getting change fully.
Real projects are rarely follow the sequential model.
Not a good model for complex and object-oriented projects.