Software Development Methodologies

(Software Development Process

Models)
 Introduction…
• A so f t w a re d e v e lo p m e nt m e t ho d o lo g y o r sy st e m
development methodology in software engineering is a
framework that is used to structure, plan, and control the
process of developing an information system.
• Some of the methodologies are:
• Waterfall (Traditional)
• Spiral
• Rapid Prototyping
•Agile Software Development
• Joint Application Development (JAD) Methodology

2
The Waterfall Model
• The waterfall model is the classic lifecycle

model – it is widely known, understood

and (commonly?) used.
• In some respect, waterfall is the ”common

sense” approach.
• Introduced by Royce 1970.

3
 phase
User Requirements output User Requirements Document

Software Requirements Software Requirements

Document

Architecture Design Architectural Design

Document

”Swimming Detailed design & Coding Detailed

upstream” Design
& Code
The Waterfall Testing
Lifecycle Workflow
Delivery
Time
4
Advantages
• Easy to understand , use and implement.
• Widely used and known (in theory!)
• Reinforces good habits: define-before- design,
design-before-code
• Identifies deliverables and milestones/ each phase
has specific deliverables and a review process.
• In this model, phases are processed and
completed one at a time. Phases do not overlap.
• Document driven, URD (user requirements
document), SRD (system requirements document)
• Works well on mature products and weak teams.
• Works well for smaller projects.

5
Cont…………

• Provides structure to inexperienced staff

• Milestones are well understood

• Sets requirements stability

• Good for management control (plan, staff, track)

• Works well when quality is more important than cost

or schedule

6
Disadvantages
• Idealised, doesn’t match reality well.

• Doesn’t reflect iterative nature of exploratory

development.

• Unrealistic to expect accurate requirements so early

in a project

• Software is delivered late in project, delays

discovery of serious errors.

7
Cont...........
•Difficult to integrate risk management

•Difficult and expensive to make changes to

documents, ”swimming upstream”.

•Significant administrative overhead.

8
Cont……
• All requirements must be known upfront

• Deliverables created for each phase are considered

frozen – inhibits flexibility

• Can give a false impression of progress

• Does not reflect problem-solving nature of software

development – iterations of phases

• Little opportunity for customer to preview the system

(until it may be too late)

9
When to use the Waterfall Model
Requirements are very well known

Product definition is stable

Technology is understood

New version of an existing product

Porting an existing product to a new platform.

High risk for new systems because of specification
and

design problems.
Low risk for well-understood developments using
familiar technology. 10
 Spiral Model
Since end-user requirements are hard to obtain/define, it
is natural to develop software in an experimental way:
e.g.
• Build some software

• See if it meets customer requirements

• If no go to 1

• else stop.

11
This loop approach gives rise to structured iterative lifecycle
models.
In 1988 Boehm developed the spiral model as an iterative
model which includes risk analysis and risk management.

Key idea: on each iteration, identify and solve the sub-problems

with the highest risk.

12
 Cumulative cost Evaluate alternatives,
Determine objectives, Identify & resolve risks
alternatives & constraints

Prototypes Operational
Review & Start P1 P2 P3 Prototype
commitment RequirementsConcept Design, Detailed design
plan Of Operation Validation
Development & Verification
plan Requirements
validation Coding
Integration &
Test plan Unit & Integration
Testing
End Acceptance Develop & verify
Plan next phase Testing
next-level product
13
Each cycle follows a waterfall model by:

• Determining objectives

• Specifying constraints

• Generating alternatives

• Identifying risks

• Resolving risks

• Developing next-level product

• Planning next cycle

14
Advantages
• Realism: the model accurately reflects the iterative nature
of software development on projects with unclear
requirements

• Flexible: incoporates the advantages of the waterfal and

rapid prototyping methods

• Comprehensive model decreases risk

• Good project visibility.

15
 Cont……….
• Provides early indication of insurmountable risks, without
much cost

• Users see the system early because of rapid prototyping tools

• Critical high-risk functions are developed first

• The design does not have to be perfect

• Users can be closely tied to all lifecycle steps

• Early and frequent feedback from users

• Cumulative costs are assessed frequently

16
Disadvantages
• Needs technical expertise in risk analysis to really work

• M o d e l is p o o rly und e rsto o d b y no n-t e c hnic a l

management, hence not so widely used

• Complicated model needs competent professional

management.

• High administrative overhead.

17
 Cont….
• Time spent for evaluating risks is too large for small or low-
risk projects
• Time spent for planning, resetting objectives, doing risk
analysis and prototyping may be excessive
• The model is complex
• Risk assessment expertise is required
• Spiral may continue indefinitely
• Developers must be reassigned during non-development
phase activities
• May be hard to define objective, verifiable milestones that
indicate readiness to proceed through the next iteration

18
 When to use Spiral Model
• When creation of a prototype is appropriate
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment is unwise because of
potential changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line
• Significant changes are expected (research and exploration)
19
 Rapid Prototyping
Key idea: Customers are non-technical and usually don’t
know what they want/can have.

Rapid prototyping emphasises on requirements analysis and

validation, also called:

• customer oriented development,

• evolutionary prototyping

20
Requirements Capture

Iterate
Quick Design

Build Prototype

Customer Evaluation of
Prototype

The Rapid Engineer Final

Product
Prototype Workflow

21
Advantages
• Reduces risk of incorrect user requirements

• Good where requirements are

changing/uncommitted

• Regular visible progress aids management

• Supports early product marketing

22
Disadvantages
• An unstable/badly implemented prototype often
becomes the final product.

• Requires extensive customer collaboration

Costs customer’s money
Needs committed customers
Difficult to finish if customer withdraws
May be too customer specific, no broad market

23
 Cont.......
• Difficult to scale up to large projects where documentation
is essential

• Needs experience and skill if not to degenerate into code-

and-fix

• Programming pairs is costly

• Test case construction is a difficult and specialised skill.

• Difficult to know how long project will last

• Easy to fall back into code-and-fix without proper

requirements analysis, design, customer evaluation and
24
feedback.
Differences B/n Spiral and RP Models

25
 An Iterative Development Process...
• Recognizes the reality of changing requirements
•Caspers Jones’s research on 8000 projects
• 40% of final requirements arrived after the analysis
phase, after development had already begun
• Promotes early risk mitigation, by breaking down the system
into mini-projects and focusing on the riskier elements first
• Allows you to “plan a little, design a little, and code a little”
• Encourages all participants, including testers, integrators, and
technical writers to be involved earlier
• Allows the process itself to modulate with each iteration,
allowing you to correct errors sooner and put into practice
lessons learned in the prior iteration
• Focuses on component architectures, not final big bang
deployments
 An Incremental Development Process...
• Allows for software to evolve, not be produced in one huge
effort
• Allows software to improve, by giving enough time to the
evolutionary process itself
• Forces attention on stability, for only a stable foundation can
support multiple additions
• Allows the system (a small subset of it) to actually run much
sooner than with other processes
• Allows interim progress to continue through the stubbing of
functionality
• Allows for the management of risk, by exposing problems
earlier in the development process
 Risk Management
• Identification of the risks

• Iterative/Incremental Development

• The prototype or pilot project

• Early testing and deployment as opposed to late

testing in traditional methods
Agile Software Development
• Agile software development is a conceptual framework
for software engineering that promotes development
iterations throughout the life-cycle of the project.

• Software developed during one unit of time is referred to

as an iteration, which may last from one to four weeks.

• Agile methods also emphasize working software as the

primary measure of progress
Agile Software Development…..
• 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

Cont……
To generalize, the characteristics of ASD
• Modularity

• Iterative

• Time-bound

• Incremental

• Convergent

• People-oriented

• Collaborative


Joint Application Development (JAD) Methodology

• JAD is a requirements-def inition and user-interface design
methodology in which end-users, executives, and developers
attend intense off-site meetings to work out a system's
details.

• So the Joint Application Development (JAD) methodology

aims to involve the client in the design and development of
an application.

• This is accomplished through a series of collaborative

workshops called JAD sessions.

• Two employees of IBM, Chuck Morris and Tony Crawford,

developed the JAD methodology in the late 1970s and began
teaching the approach in to the 1980s.
32


Joint Application Development (JAD) Methodology


• JAD focuses on the business problem rather than
technical details. It is most applicable to the
development of business systems, but it can be
used successfully for systems software.

• It produces its savings by shortening the elapsed

time required to gather a system's requirements and
by gathering requirements better, thus reducing the
n u mber of costly, down stream requ iremen ts
changes.

• Its success depends on effective leadership of the

JAD sessions; on participation by key end-users,
executives, and developers; and on achieving group
synergy during JAD sessions. 33
 Joint Application Development (JAD)
Methodology
• In contrast to the Waterfall approach, JAD is
thought to lead to shorter development times and
greater client satisfaction, both of which stem
from the constant involvement of the client
throughout the development process. On the
other hand, with the traditional approach to
systems development, the developer investigates
th e sy stem requ iremen ts an d d evelop s an
application, with client input consisting of a series
of interviews.

34