DISCLAIMER STATEMENT

 In preparation of these slides, materials have been

taken from different online sources in the shape of
books, websites, research papers and presentations
etc. However, the author does not have any intention
to take any benefit of these in her/his own name. This
lecture (audio, video, slides etc) is prepared and
delivered only for educational purposes and is not
intended to infringe upon the copyrighted material.
Sources have been acknowledged where applicable.
The views expressed are presenter’s alone and do not
necessarily represent actual author(s) or the
institution.
1
 AGILE METHODOLOGY
&
Rapid Application Development

(RAD)
2
 Definition
 Manifesto
 Principles
 Characteristics
 Overview
 Philosophy
 Agile methods
 Agile practices
 Experience and Adoption
 Pitfalls
 Application outside software development
 RAD

3
 Rapid Software Development
• Because of rapidly changing business
environments, businesses have to respond to new
opportunities and competition.
– This requires software rapid development and delivery is
often the most critical requirement for software systems.
• Businesses may be willing to accept lower quality
software if rapid delivery of essential functionality is
possible.
• Due to the changing environment
– it is often impossible to arrive at a stable, consistent set of
system requirements.
• A waterfall model of development is impractical
• An approach to development based on iterative specification and
delivery is the only way to deliver software quickly.

4
 Agile methods
• Dissatisfaction with the overheads involved in design
methods led to the creation of agile methods.
– What if:
• the design is simple and the code quality is high
• These methods:
– Focus on the code rather than the design;
– Are based on an iterative approach to software development;
– Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
• What if:
– the customer can change their mind, substitute functionality, and change
priorities
• Agile methods are probably best suited to small/medium-
sized business systems.

5
What is Agile software development?

Agile software development is a set

of principles for software
development in which
and solutions evolverequirements
through
collaboration between self-
organizing,cross-functional teams.

6
Agile SDLC

7
 Agile Manifesto
 Individuals and self-organization and
interactions: motivation are interactions like co-
location and pair
important, as programming.
are
 Working software: working software is more useful and
welcomed than just presenting documents to clients in
meetings.
 Customer collaboration: requirements cannot be fully
collected at the beginning of the software development
cycle, therefore continuous customer or stakeholder
involvement is very important.
 Responding to change: agile methods are focused on quick
responses to change and continuous development.

8
 Principles
The Agile Manifesto is based on
twelve principles:
 Customer satisfaction by early and continuous delivery of
valuable software
 Welcome changing requirements, even in late development
 Working software is delivered frequently (weeks
rather than months)
 Close and daily cooperation between business people and
developers
 Projects are built around motivated individuals,
who should be trusted.

9
Principles continued..
 Face-to-face conversation is the best form of
communication (co-location)
 Working software is the principal measure of progress
 Sustainable development, able to maintain a constant pace
 Continuous attention to technical excellence and good design
 Simplicity—the art of maximizing the amount of work
not done—is essential (This idea is central to eliminating waste.
To make your process more agile, do less. )
 Best architectures, requirements, and designs emerge from self-
organizing teams
 Regularly, the team reflects on how to become more effective,
and adjusts accordingly
10
Characteristics of Agile Software
Development
-- Light Weighted methodology
-- Small to medium sized teams
-- vague and/or changing
requirements
-- vague and/or changing techniques
-- Simple design
-- Minimal system into production

11
 Overview
There are many agile
development specific
promote development,
methods. teamwork,
Most
collaboration, and process
adaptability throughout the life-
cycle of the project.

12
 Philosophy
 Compared to traditional software engineering,
agile software development mainly targets
complex systems and projects with dynamic, non-
deterministic and non-linear characteristics,
where accurate estimates, stable plans, and
predictions are often hard to get in early stages—
and big up-front designs and arrangements would
probably cause a lot of waste, economically.

13
 Adaptive vs. predictive
 Agile methods lie on the adaptive side of this
continuum. One key of adaptive development
methods is a "Rolling Wave" approach to schedule
planning, which identifies milestones but leaves
flexibility in the path to reach them, and also
allows for the milestones themselves to change.
 Adaptive methods focus on adapting quickly to
changing realities. When the needs of a project
change, an adaptive team changes as well.

14
 Predictive
 Predictive methods, focus on analysing and planning
the future in detail and cater for known risks.
 In the extremes, a predictive team can report
exactly what features and tasks are planned for the
entire length of the development process.
 Predictive methods rely on effective early phase
analysis and if this goes very wrong, the project may
have difficulty changing direction.
 Predictive teams often formulate a change control
board to ensure they consider only the most valuable
changes.

15
3/2/ 201 16
6
3/2/ 201 17
6
3/2/ 201 18
6
3/2/ 201 19
6
 Agile Method
 Adaptive software development (ASD)
 Agile modeling
 Agile Unified Process (AUP)
 Business analyst designer method (BADM)
 Crystal Clear Methods
 Disciplined agile delivery
 Dynamic systems development method (DSDM)
 Extreme programming (XP)
 Feature-driven development (FDD)
 Lean software development
20
 Extreme Programming (XP)
Extreme Programming (XP) is an agile software development
framework that aims to produce higher quality software.

When Applicable
The general characteristics where XP is appropriate:
• Dynamically changing software requirements
• Risks caused by fixed time projects using new technology
• Small, co-located extended development team
• The technology you are using allows for automated unit and
functional tests
22
 Agile Practices
 Acceptance test-driven development (ATDD)
 Agile modeling
 Backlogs (Product and Sprint)
 Behavior-driven development (BDD)
 Cross-functional team
 Continuous integration (CI)
 Domain-driven design (DDD)
 Pair programming
 Refactoring (process of clarifying and simplifying the design of
existing code, without changing its behavior)

23
 Experience and Adoption
 Agile methods were first used by technology early
adopters such as Tektronix.
 Agile can be used with any programming paradigm or
language in practice. Agile has usually been closely
associated with object-oriented environments such as
Java.
 The initial adopters of Agile methods were usually
small to medium-sized teams working on unique
systems with requirements that were difficult to
finalize and likely to change as the system was being
developed.

24
 SCRUM

Daily Scrum is a fifteen-minute daily team meeting to share progress,

report weaknesses and make further commitments. During the Daily
scrum each team member answers three questions:

1. "What have I done since the last Scrum meeting? (i.e. yesterday)“

2. "What will I do before the next Scrum meeting? (i.e. today)“

3. "What prevents me from performing my work as efficiently as

possible?"
 Problems with agile methods
• It can be difficult to keep the interest of customers
who are involved in the process.
• Team members may be unsuited to the intense
involvement that characterizes agile methods.
• Prioritizing changes can be difficult where there are
multiple stakeholders.
• Maintaining simplicity is not easy.
• Contracts may be a problem as with other
approaches to iterative development.

26
 Other Pitfalls
 Lack of overall project design
 Adding stories to a sprint in progress
(Scrum which is a specialized agile method, or we can say
specialized Incremental Development process and it uses
the term Sprint for its iterations, that is one development
cycle in Scrum is called a Sprint)
 Lack of sponsor support
 Insufficient training
 Excessive preparation/planning
 Lacking test automation
27
Applications outside s/w development
 Integrated customer engagement - to embed
customers within any delivery process to share
accountability for product/service delivery.
 Facilitation-based management - adopting agile
management models, like the role of Scrum
Master to facilitate the day-to-day operation of
teams.
 An enabling organisational structure - with a focus
on staff engagement,personal autonomy and
outcomes based governance.
28
 The RAD Model
• Rapid application development (RAD) is an incremental
software process model that emphasizes a short
development cycle.
• RAD model is high speed adaptation of the waterfall
model, in which rapid development is achieved by using a
component based construction approach.
• In RAD model the components or functions are developed
in parallel as if they were mini projects. The developments
are time boxed, delivered and then assembled into a
working project.
• If requirements are well understood and scope is limited
the RAD process enables the development team to create
a fully functional system in a very short period (60-90
days).
30
 RAD Framework Activities
• Communication:
• Understand business problems and communicate.
• Planning:
• Is important as multiple software teams work in
parallel on different system functions.
• Modeling:
Three major phases
– Business Modeling
– Data Modeling
– Process Modeling
– And establishes design representations that serves as
the basis for RADs construction activity.
• Construction:
• Emphasizes the use of pre-existing
software components and application of
automatic code generation.
• Testing

• Deployment:
• Integration
• Delivery
• feedback
 Drawbacks of RAD
• For large but scalable projects RAD requires
sufficient human resources to create the right no of
RAD teams.
• If developers and customers are not committed to
the rapid fire activities necessary to complete the
system in time frame the RAD project fails.
• If system cannot be properly modularized, building
the components necessary for RAD will be
problematic.
• If performance is a high issue, RAD has
reservations
• RAD not appropriate when technical risks are high
(e.g. when a new application makes heavy use of
THANKS

34