Software Development

Methodologies
Ashish Kumar

1
Rapid Application Development Model
RAD model is Rapid Application Development
model.
It is an adoption of the waterfall model.
It targets at developing software in a short span
of time.
It is a type of incremental model.
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 4. Application
a working Generation
prototype.
5. Testing and Turnover
RAD model has following phases
1. Business Modeling 2
RAD Model

3
Different phases of RAD model
Phases of Activities performed in RAD Model
RAD model

Business •On basis of the flow of information and distribution

Modeling between various business channels, the product is
designed

Data •The information collected from business modeling is

Modeling refined into a set of data objects that are significant for the
business
Process •The data object that is declared in the data modeling
Modeling phase is transformed to achieve the information flow
necessary to implement a business function

Application •Automated tools are used for the construction of the

Generation software, to convert process and data models into
prototypes

Testing and •As prototypes are individually tested during every

Turnover iteration, the overall testing time is reduced in RAD.
4
When to use RAD Methodology?
When a system needs to be produced in a short
span of time (2-3 months)
When the requirements are known
When the user will be involved all through the life
cycle
When technical risk is less
When there is a necessity to create a system that
can be modularized in 2-3 months of time
When a budget is high enough to afford designers
for modeling along with the cost of automated
tools for code generation

5
RAD Model Vs Traditional SDLC
The traditional SDLC follows a rigid process models
with high emphasis on requirement analysis and
gathering before the coding starts. It puts pressure on
the customer to sign off the requirements before the
project starts and the customer doesn’t get the feel of
the product as there is no working build available for
a long time.
The customer may need some changes after he gets to
see the software. However, the change process is
quite rigid and it may not be feasible to incorporate
major changes in the product in the traditional SDLC.
The RAD model focuses on iterative and incremental
delivery of working models to the customer. This
results in rapid delivery to the customer and customer
involvement during the complete development cycle of6
Advantages of the RAD Model
Changing requirements can be accommodated.
Progress can be measured.
Iteration time can be short with use of powerful
RAD tools.
Productivity with fewer people in a short time.
Reduced development time.
Increases reusability of components.
Quick initial reviews occur.
Encourages customer feedback.
Integration from very beginning solves a lot of
integration issues.

7
Disadvantages of the RAD Model
Dependency on technically strong team members for
identifying business requirements.
Only system that can be modularized can be built
using RAD.
Requires highly skilled developers/designers.
High dependency on modeling skills.
Inapplicable to cheaper projects as cost of modeling
and automated code generation is very high.
Management complexity is more.
Suitable for systems that are component based and
scalable.
Requires user involvement throughout the life cycle.
Suitable for project requiring shorter development
times. 8
Agile Modeling
Rapid development and delivery is now often the
most important requirement for software systems
 Businesses operate in a fast –changing requirement and
it is practically impossible to produce a set of stable
software requirements
 Software has to evolve quickly to reflect changing
business needs.
Plan-driven development is essential for some
types of system but does not meet these business
needs.
Dissatisfaction with the overheads involved in
software design methods of the 1980s and 1990s
led to the creation of agile methods.
Agile development methods emerged in the late
9
Agile Development
Program specification, design and
implementation are inter-leaved.
The system is developed as a series of versions or
increments with stakeholders involved in version
specification and evaluation.
Frequent delivery of new versions for evaluation.
Extensive tool support (e.g. automated testing
tools) used to support development.
Minimal documentation – focus on working code.

10
Agile Model
Agile model is a combination of iterative and
incremental process models with focus on process
adaptability and customer satisfaction by rapid
delivery of working software product.
Agile Methods break the product into small
incremental builds.
These builds are provided in iterations.
Each iteration typically lasts from about one to three
weeks.
Every iteration involves cross functional teams
working simultaneously on various areas like –
 Planning / Requirement gathering
 Requirements Analysis
 Design
11
 Coding
4 core values of Agile Model
Individual and team interactions over processes
and tools
Working software over comprehensive
documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

12
Agile Models
Actually Agile model refers to a group of
development processes. These processes share
some basic characteristics but do have certain
subtle differences among themselves.
 A few Agile SDLC models are given below:
 Crystal
 Atern
 Feature-driven development
 Scrum
 Extreme programming (XP)
 Lean development
 Unified process
 DSDM (Dynamic Software Development Method )
13
Principles of Agile methods
Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.

Incremental delivery The software is developed in increments with the customer

specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.

Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and in
the development process. Wherever possible, actively work to
eliminate complexity from the system.

14
Advantages of Agile Model
Working through Pair programming produce well
written compact programs which has fewer
errors as compared to programmers working
alone.
It reduces total development time of the whole
project.
Customer representative get the idea of updated
software products after each iteration. So, it is
easy for him to change any requirement if
needed.

15
Disadvantages of Agile Model
Due to lack of formal documents, it creates
confusion and important decisions taken during
different phases can be misinterpreted at any
time by different team members.
Due to absence of proper documentation, when
the project completes and the developers are
assigned to another project, maintenance of the
developed project can become a problem.

16
Agile Vs Waterfall Method
Agile Model Waterfall Model
•Agile method proposes •Development of the software
incremental and iterative flows sequentially from start point
approach to software design to end point.
•The agile process is broken into •The design process is not broken
individual models that designers into an individual models
work on
•The customer has early and •The customer can only see the
frequent opportunities to look at product at the end of the project
the product and make decision
and changes to the project
•Agile model is considered •Waterfall model are more secure
unstructured compared to the because they are so plan oriented
waterfall model
•Small projects can be •All sorts of project can be
implemented very quickly. For estimated and completed.
large projects, it is difficult to
estimate the development time.
17
Agile Vs Waterfall Method
Agile Model Waterfall Model
•Error can be fixed in the middle •Only at the end, the whole
of the project. product is tested. If the
requirement error is found or any
changes have to be made, the
project has to start from the
beginning
•Development process is iterative, •The development process is
and the project is executed in phased, and the phase is much
short (2-4) weeks iterations. bigger than iteration. Every phase
Planning is very less. ends with the detailed description
of the next phase.
•Documentation attends less •Documentation is a top priority
priority than software and can even use for training staff
development and upgrade the software with
another team
•Every iteration has its own •Only after the development
testing phase. It allows phase, the testing phase is
implementing regression testing executed because separate parts 18
Agile Vs Waterfall Method
Agile Model Waterfall Model
•In agile testing when an iteration •All features developed are
end, shippable features of the delivered at once after the long
product is delivered to the implementation phase.
customer. New features are usable
right after shipment.
•Testers and developers work •Testers work separately from
together developers
•At the end of every sprint, user •User acceptance is performed at
acceptance is performed the end of the project.
•It requires close communication •Developer does not involve in
with developers and together requirement and planning
analyze requirements and process. Usually, time delays
planning between tests and coding

19
Extreme programming
A very influential agile method, developed in
the late 1990s, that introduced a range of
agile development techniques.
Extreme Programming (XP) takes an
‘extreme’ approach to iterative development.
New versions may be built several times per
day;
Increments are delivered to customers every 2
weeks;
All tests must be run for every build and the
build is only accepted if tests run successfully.

20
Extreme Programming Release Cycle

21
Extreme programming practices
Principle or practice Description
Incremental planning Requirements are recorded on story cards and the stories to be
included in a release are determined by the time available and
their relative priority. The developers break these stories into
development ‘Tasks’.

Small releases The minimal useful set of functionality that provides business
value is developed first. Releases of the system are frequent
and incrementally add functionality to the first release.

Simple design Enough design is carried out to meet the current requirements
and no more.
Test-first development An automated unit test framework is used to write tests for a
new piece of functionality before that functionality itself is
implemented.
Refactoring All developers are expected to refactor the code continuously as
soon as possible code improvements are found. This keeps the
code simple and maintainable.

22
Extreme programming practices
Pair programming Developers work in pairs, checking each other’s work and
providing the support to always do a good job.
Collective ownership The pairs of developers work on all areas of the system, so that
no islands of expertise develop and all the developers take
responsibility for all of the code. Anyone can change anything.
Continuous integration As soon as the work on a task is complete, it is integrated into
the whole system. After any such integration, all the unit tests in
the system must pass.
Sustainable pace Large amounts of overtime are not considered acceptable as
the net effect is often to reduce code quality and medium term
productivity
On-site customer A representative of the end-user of the system (the customer)
should be available full time for the use of the XP team. In an
extreme programming process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.

23
XP and agile principles
Incremental development is supported through
small, frequent system releases.
Customer involvement means full-time customer
engagement with the team.
People not process through pair programming,
collective ownership and a process that avoids
long working hours.
Change supported through regular system
releases.
Maintaining simplicity through constant
refactoring of code.

24
Influential XP practices
Extreme programming has a technical focus
and is not easy to integrate with management
practice in most organizations.
Consequently, while agile development uses
practices from XP, the method as originally
defined is not widely used.
Key practices
User stories for specification
Refactoring
Test-first development
Pair programming

25
User stories for requirements
In XP, a customer or user is part of the XP team
and is responsible for making decisions on
requirements.
User requirements are expressed as user stories
or scenarios.
These are written on cards and the development
team break them down into implementation
tasks. These tasks are the basis of schedule and
cost estimates.
The customer chooses the stories for inclusion in
the next release based on their priorities and the
schedule estimates.

26
A ‘prescribing medication’ story

27
Examples of task cards for prescribing
medication

28
Refactoring
Conventional wisdom in software engineering is to
design for change. It is worth spending time and effort
anticipating changes as this reduces costs later in the
life cycle.
XP, however, maintains that this is not worthwhile as
changes cannot be reliably anticipated.
Rather, it proposes constant code improvement
(refactoring) to make changes easier when they have
to be implemented.
Programming team look for possible software
improvements and make these improvements even
where there is no immediate need for them.
This improves the understandability of the software
and so reduces the need for documentation.
Changes are easier to make because the code is well-
29
structured and clear.
Test-first development
Testing is central to XP and XP has developed an
approach where the program is tested after every
change has been made.
XP testing features:
 Test-first development.
 Incremental test development from scenarios.
 User involvement in test development and validation.
 Automated test harnesses are used to run all component
tests each time that a new release is built.
 Writing tests before code clarifies the requirements to be
implemented.
 Tests are written as programs rather than data so that they
can be executed automatically. The test includes a check
that it has executed correctly.
 Usually relies on a testing framework such as Junit.
 All previous and new tests are run automatically when new
30
Problems with test-first development
Programmers prefer programming to testing and
sometimes they take short cuts when writing
tests. For example, they may write incomplete
tests that do not check for all possible exceptions
that may occur.
Some tests can be very difficult to write
incrementally. For example, in a complex user
interface, it is often difficult to write unit tests for
the code that implements the ‘display logic’ and
workflow between screens.
It difficult to judge the completeness of a set of
tests. Although you may have a lot of system
tests, your test set may not provide complete
coverage. 31
Pair programming
Pair programming involves programmers working
in pairs, developing code together.
This helps develop common ownership of code
and spreads knowledge across the team.
It serves as an informal review process as each
line of code is looked at by more than 1 person.
It encourages refactoring as the whole team can
benefit from improving the system code.

32
Pair programming
In pair programming, programmers sit together
at the same computer to develop the software.
Pairs are created dynamically so that all team
members work with each other during the
development process.
The sharing of knowledge that happens during
pair programming is very important as it reduces
the overall risks to a project when team members
leave.
Pair programming is not necessarily inefficient
and there is some evidence that suggests that a
pair working together is more efficient than 2
programmers working separately.
33
Scrum
Scrum is an agile method that focuses on
managing iterative development rather than
specific agile practices.
Originally proposed by Schwaber and Beedle.
There are three phases in Scrum.
 The initial phase is an outline planning phase where
you establish the general objectives for the project
and design the software architecture.
 This is followed by a series of sprint cycles, where
each cycle develops an increment of the system.
 The project closure phase wraps up the project,
completes required documentation such as system
help frames and user manuals and assesses the
lessons learned from the project. 34
Scrum terminology
Scrum term Definition

Development team A self-organizing group of software developers, which should be no more

than 7 people. They are responsible for developing the software and other
essential project documents.

Potentially The software increment that is delivered from a sprint. The idea is that this
shippable product should be ‘potentially shippable’ which means that it is in a finished state
increment and no further work, such as testing, is needed to incorporate it into the
final product. In practice, this is not always achievable.

Product backlog This is a list of ‘to do’ items which the Scrum team must tackle. They may
be feature definitions for the software, software requirements, user stories
or descriptions of supplementary tasks that are needed, such as
architecture definition or user documentation.

Product owner An individual (or possibly a small group) whose job is to identify product
features or requirements, prioritize these for development and
continuously review the product backlog to ensure that the project
continues to meet critical business needs. The Product Owner can be a
customer but might also be a product manager in a software company or
other stakeholder representative.
35
Scrum terminology
Scrum term Definition
Scrum A daily meeting of the Scrum team that reviews progress and prioritizes
work to be done that day. Ideally, this should be a short face-to-face
meeting that includes the whole team.

ScrumMaster The ScrumMaster is responsible for ensuring that the Scrum process is
followed and guides the team in the effective use of Scrum. He or she
is responsible for interfacing with the rest of the company and for
ensuring that the Scrum team is not diverted by outside interference.
The Scrum developers are adamant that the ScrumMaster should not
be thought of as a project manager. Others, however, may not always
find it easy to see the difference.

Sprint A development iteration. Sprints are usually 2-4 weeks long.

Velocity An estimate of how much product backlog effort that a team can cover
in a single sprint. Understanding a team’s velocity helps them estimate
what can be covered in a sprint and provides a basis for measuring
improving performance.

36
Scrum Sprint Cycle

37
Scrum Sprint Cycle
 Sprints are fixed length, normally 2–4 weeks.
 The starting point for planning is the product backlog,
which is the list of work to be done on the project.
 The selection phase involves all of the project team who
work with the customer to select the features and
functionality from the product backlog to be developed
during the sprint.
 Once these are agreed, the team organize themselves to
develop the software.
 During this stage the team is isolated from the customer
and the organization, with all communications channelled
through the so-called ‘Scrum master’.
 The role of the Scrum master is to protect the development
team from external distractions.
 At the end of the sprint, the work done is reviewed and
presented to stakeholders. The next sprint cycle then38
Advantages of Scrum
The product is broken down into a set of
manageable and understandable chunks.
Unstable requirements do not hold up progress.
The whole team have visibility of everything and
consequently team communication is improved.
Customers see on-time delivery of increments
and gain feedback on how the product works.
Trust between customers and developers is
established and a positive culture is created in
which everyone expects the project to succeed.

39
Practical problems with agile methods
The informality of agile development is
incompatible with the legal approach to contract
definition that is commonly used in large
companies.
Agile methods are most appropriate for new
software development rather than software
maintenance. Yet the majority of software costs in
large companies come from maintaining their
existing software systems.
Agile methods are designed for small co-located
teams yet much software development now
involves worldwide distributed teams.

40
Agile methods and software maintenance
Most organizations spend more on
maintaining existing software than they do on
new software development. So, if agile
methods are to be successful, they have to
support maintenance as well as original
development.
Two key issues:
Are systems that are developed using an agile
approach maintainable, given the emphasis in
the development process of minimizing formal
documentation?
Can agile methods be used effectively for
evolving a system in response to customer41
Agile maintenance
Key problems are:
Lack of product documentation
Keeping customers involved in the
development process
Maintaining the continuity of the development
team
Agile development relies on the development
team knowing and understanding what has to
be done.
For long-lifetime systems, this is a real
problem as the original developers will not
always work on the system.
42
Dynamic System Development Method
 The Dynamic Systems Development technique (DSDM)
is an associate degree agile code development approach
that provides a framework for building and maintaining
systems.
 The DSDM philosophy is borrowed from a modified version
of the sociologist principle—80% of An application is often
delivered in twenty percent of the time it’d desire deliver
the entire (100 percent) application.
 DSDM is a Rapid Application Development (RAD) approach
to software development and provides an agile project
delivery framework.
 The important aspect of DSDM is that the users are
required to be involved actively, and the teams are given
the power to make decisions.
 Frequent delivery of product becomes the active focus with
DSDM. 43
DSDM Life Cycle
 DSDM life cycle that defines 3 different unvarying cycles,
preceded by 2 further life cycle activities:
 Feasibility Study: It establishes the essential business
necessities and constraints related to the applying to be
designed then assesses whether or not the application
could be a viable candidate for the DSDM method.
 Business Study: It establishes the use and knowledge
necessities that may permit the applying to supply business
value; additionally, it is the essential application design and
identifies the maintainability necessities for the applying.
 Functional Model Iteration: It produces a collection of
progressive prototypes that demonstrate practicality for
the client. The intent throughout this unvarying cycle is to
collect further necessities by eliciting feedback from users
as they exercise the paradigm.
44
DSDM Life Cycle
 Design and Build Iteration: It revisits prototypes
designed throughout useful model iteration to make sure
that everyone has been designed during a manner that may
alter it to supply operational business price for finish users.
In some cases, useful model iteration and style and build
iteration occur at the same time.
 Implementation: It places the newest code increment (an
“operationalized” prototype) into the operational
surroundings. It ought to be noted that:
(a) the increment might not 100% complete or,
(b) changes are also requested because the increment is placed
into place.
 In either case, DSDM development work continues by
returning to the useful model iteration activity.

45
46
Thank You

47