Mekelle University

Meklle Institute of Technology

Unit 1: Rapid Application Development Concepts

Prepared By: Mr. Mezgebo Hailu(M.Tech.)

 What is RAD(1)?

 RAD=Rapid Application Development. In software engineering, RAD can also mean

Requirement Analysis Document(RAD)

 It refers to a software development life cycle designed to give much faster development
and higher quality systems than the traditional software development techniques.

 RAD is people-centered and incremental development approach. Active user

involvement as well as collaboration between all stakeholders is very imperative

 The key objectives of RAD are:

 High speed
 High quality
 Low cost
 RAD drastically reduces the time it takes to produce software systems while
1 maintaining the required quality of the products
 What is RAD(2)?

 RAD is a software development methodology that enables organizations to

develop strategically important systems faster while reducing development costs
and maintaining quality.

 This is achieved by using a series of proven application development

techniques, within a well-defined methodology.

Rapid Application Development(RAD) is:

 A process through which the development cycle of an application is expedited

 Thus, it enables products to be developed faster, better and cheaper

 It takes the advantage of automated tools like CASE tools & Code generators and
techniques like prototyping to restructure the process of building software systems
2
 Why RAD(1)?

 Old systems that have been developed using old technologies are
hard to maintain and upgrade. Because of this, the maintenance
and upgrading costs are dramatically increasing.

 Traditional(conventional) software development

processes(PlanAnalyzeDesignBuildTest Deploy) are too slow
and too rigid to meet the demand of today’s economy.

 The traditional/conventional development process :

 Causes long delays before customer can see the final results.

 The final result can be different from what the customer

expected

 Business cases can changed by the time the final results are
ready
3
 Why RAD(2)?

 System requirements will be “locked in” after being determined

(can't change)

 Limited user involvement (only in requirements phase)

 Too much focus on deliverables & deadlines of SDLC phases

 No working prototype till the end of the project

 Therefore, a new development methodology that enables

organizations to develop system in a faster, better and cheaper
way is necessary. And RAD enables such development

 Since RAD uses well-qualified and proven tools, it is more

stable, faster and less error prone than hard coding process

4
 RAD Vs. Traditional Software Development

5
 Essential Aspects of RAD(1)

 Rapid Application Development(RAD) has the following

essential aspects:

6
 Essential Aspects of RAD(2)

 Rapid Application Development(RAD) has the following

essential aspects:

 Methodology : RAD applies the best possible techniques that

will make the development process more effective

 People : the success of RAD depends upon the involvement of

people with the right skills and talents

 Management : management must be totally committed to RAD in

order to manage the complexities of high speed development

 Tools :RAD uses state of the art tools so as to achieve the

goals of high speed and high quality development

7
 Fundamental Principles of RAD(1)

 Combining the best available techniques & tools and specifying

the sequence of tasks that will make those techniques most effective

 Using evolutionary prototypes that are eventually transformed into

the final product

 Active user involvement (JAD) & Involvement of small

empowered teams

8
 Fundamental Principles of RAD(2)

 Selecting a set of CASE tools to support modeling, prototyping and code

reusability, as well as automating many of the combinations of techniques

 Implementing time boxed development that allows development teams to

quickly build the core of the system and implement refinements in subsequent
releases

 Timeboxing is an essential project management aspect of RAD. It forces the

team to anticipate reducing the scale of product delivery, requires focus on
customer priorities, assumes continual change will occur and imparts to the team
a sense of urgency

 Providing guidelines for success and describing pitfalls to avoid

9
 CASE Tools(1)

 Computer-Aided Software Engineering tools

 Software tools providing automated support for systems development

 Project dictionary/workbook: system description and specifications

 Examples of RAD tools

 Oracle Designer: is Oracle’s CASE tool for designing an information system &
generating its code. After generating the information system’s code, one is able to edit
the code with Oracle Developer Suite

 Rational Rose: is an OO UML software design tool intended for visual modeling and
component construction of enterprise-level software applications
10
 Determinant Factors of RAD(1)

 The following are the determinant factors that should be considered when should
we apply RAD and when we should not
 Project Scope

 Focused scope, well defined business objectives

 Project Data

 Data for the project already exists (completely or in part)

 Project Decisions

 Decisions can be made by a small number of available people

11
 Determinant Factors of RAD(2)

 Project Team
 Project team is small, preferably 8 or less

 Project Technical Architecture

 Technical architecture is defined and clear & Key technology components are in place

 Project Technical Requirements

 Reasonable technical requirements : response times, throughput, database size, etc.

12
 RAD Documentation

 Customers, developers and management must accept informal deliverables

– Notes from user meetings rather than formal requirements documents

– Notes from designers meetings rather than formal design documents

 Principle: Create the minimum documentation necessary to facilitate future

development and maintenance

13
 Problems of RAD (1)

 Reduced scalability
– Delivered solution may lack the scalability of a solution that was designed as a full
application from the start.

 Flexibility of RAD systems decreases as applications grow

 Reduced features
– Due to time boxing → features are pushed off to later versions

– RAD may produces systems that are less full featured

14
 Problems of RAD (2)

 RAD tends to fail when

– Application must interoperate with existing programs

– Performance and reliability are critical

– The system cannot be modularized

– New but immature technologies are used

 Reliance on third-party components may

– Sacrifice needed functionality

– Add unneeded functionality

– Create legal problems

15
 Pareto:80/20 Rule with Respect to RAD

 Historical background:
 80% of the land in Italy is owned by 20% of the population

 80% of the production in a given pea plant is caused by 20% of the pea
plantation

 80% of the software crash is caused by 20% most common software bugs

 Pareto rule states that 80% of the results that you

achieve are caused by 20% of the time that you spent

 A usable 80% solution can be produced in

20% of the time that would have been required to produce
a total solution

16
 End of Slides

17