SOFTWARE

DEVELOPMENT
LIFE CYCLE
MODELS
ADAPTIVE (AGILE)
MODELS
CONTENTS OF PROJECT PLAN
Standards,
Process Organization Management
Introduction Guidelines,
Model of Project Activities
Procedures

Methods and Quality Work

Risks Staffing
Techniques Assurance Packages

Budget and
Resources Changes Delivery
Schedule

2
SOFTWARE DEVELOPMENT MODELS

SDLC Models

Heavyweight Lightweight
(Predictive) (Adaptive)

Waterfall Incremental Iterative RAD and Agile

Models Models Model DSDM Frameworks

Waterfall Sashimi Prototype Extreme

V Model Spiral Model Scrum Lean
Model Model model Programming

3
PREDICTIVE VS ADAPTIVE MODELS

4
 WATERFALL MODEL

V&V

V&V

V&V

V&V

V&V

5
V MODEL SASHIMI MODEL

6
INCREMENTAL MODELS ITERATIVE MODEL

7
RATIONAL UNIFIED PROCESS (RUP)
establish scope,
foundation of
feasibility, critical use release to user
architecture, establish manufacturing process,
cases, candidate community, often
tool support, get all use one or more releases
architectures, schedule several releases
cases
and cost estimates

• Complement to UML
(Unified Modeling
Language)

• Iterative approach for

object-oriented systems,
strongly embraces use
cases for modeling
requirements

8
PROTOTYPE MODEL SPIRAL MODEL

9
MODEL CATEGORY MATRIX (1 to 5 scale)
Risk Quality/Cost Visibility of Customer
Predictability
Management Control Progress Involvement

Code-and-Fix 1 1 1 3 2
Waterfall
Models 2 4 3 1 2
Incremental 3 5 3 3 4
Iterative
(Prototype) 3 3 2 5 5
Iterative
(Spriral) 5 5 3 3 3

10
SOFTWARE DEVELOPMENT MODELS

SDLC Models

Heavyweight Lightweight
(Predictive) (Adaptive)

Waterfall Incremental Iterative RAD and Agile

Models Models Model DSDM Frameworks

Waterfall Sashimi Prototype Extreme

V Model Spiral Model Scrum Lean
Model Model model Programming

11
COMMON FEARS FOR DEVELOPERS

The project will produce the wrong product.

The project will produce a product of inferior quality.
The project will be late.
We’ll have to work 80 hour week.
We’ll have to break commitments.
We won’t be having fun.
12
MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT
“We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
4 Agile Values

That is, while there is value in the items on the right, we value the items on the left more. ”
https://www.youtube.com/watch?v=rf8Gi2RLKWQ
-- Kent Beck et al.
13
MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT
12 Agile Principles

https://www.youtube.com/watch?v=LMnozmayNJQ 14
PRINCIPLES OF AGILITY
 Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
 Welcome changing requirements, even late in development.
Agile processes harness change for the customer’s competitive
advantage.
 Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter time scale.
 Businesspeople and developers must work together daily
throughout the project.

15
PRINCIPLES OF AGILITY
 Build projects around motivated individuals. Give them the
environment and support their need and trust them to get the job
done.
 The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.
 Working software is the primary measure of progress.
 Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant rhythm
indefinitely.

16
PRINCIPLES OF AGILITY
 Continuous attention to technical excellence and good design
enhances agility.
 Simplicity is essential.
 The best architectures, requirements, and designs emerge from
self-organizing teams.
 At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

17
WHAT IS AGILITY?
 Effective (rapid and adaptive) response to change
 Effective communication among all stakeholders
 Bring the customer into the team
 Organizing a team so that it is in control of the work performed

➔ Rapid, incremental delivery of software

18
AN AGILE PROCESS
 Is driven by customer descriptions of what is required (scenarios)
 Recognizes that plans are short-lived
 Develops software iteratively with a heavy emphasis on
construction activities
 Delivers multiple software increments
 Adapts as changes occur

19
ADAPTIVE MODELS

 advantages  disadvantage

 Detect translation issues early  Architecture/Design/Database modeling

is challenging
 Validate user needs earlier
 Lack of control / Unpredictable Journey
 Detect integration issues early
 Very uncomfortable for
Leaders/Organizations
 Requires participation from customers
throughout the development process

20
SOFTWARE DEVELOPMENT MODELS

SDLC Models

Heavyweight Lightweight
(Predictive) (Adaptive)

Waterfall Incremental Iterative RAD and Agile

Models Models Model DSDM Frameworks

Waterfall Sashimi Prototype Extreme

V Model Spiral Model Scrum Lean
Model Model model Programming

21
RAD: RAPID APPLICATION DEVELOPMENT
 Evolutionary development, within fixed time boxes
 Time frame is decided upon first, then one tries to realize as
much as possible within that time frame
 Requirements prioritization through a triage

22
RAD: RAPID APPLICATION DEVELOPMENT
 Other elements:
 Joint Requirements Planning (JRD)
 Joint Application Design (JAD)

 development in a SWAT team: Skilled Workers with Advanced

Tools

23
DSDM FRAMEWORK
 Dynamic Systems Development
Method, #1 RAD framework in UK
 Created in 1994 (before Agile)
 Fix time and resources (timebox)
and adjust functionality accordingly
 One can be a member of the DSDM
consortium (now called Agile
Business Consortium)
24
DSDM PHASES
Feasibility: delivers feasibility
report and outline plan, optionally
fast prototype (few weeks)
Business study: analyze
characteristics of business and
technology (in workshops), delivers
a.o. System Architecture Definition
Functional model iteration:
timeboxed iterative, Implementation,
incremental phase, yields transfer to production
requirements environment

25
DSDM PRACTICES
 Active user involvement is imperative
 Empowered teams
 Frequent delivery of products
 Acceptance determined by fitness for business purpose
 Iterative, incremental development
 All changes are reversible
 Requirements baselined at high level
 Testing integrated in life cycle
 Collaborative, cooperative approach shared by all stakeholders is essential

26
RAD AND DSDM
 advantages
 deliver projects on time
 flexible workflow
 prioritizes business cases
 Developments and
progression occur quickly
 Suitable for small projects
 disadvantage
 large management overheads
 impractical for low budget
companies since implementation
can be costly
 doesn't encourage developer
creativity
27
SOFTWARE DEVELOPMENT MODELS

SDLC Models

Heavyweight Lightweight
(Predictive) (Adaptive)

Waterfall Incremental Iterative RAD and Agile

Models Models Model DSDM Frameworks

Waterfall Sashimi Prototype Extreme

V Model Spiral Model Scrum Lean
Model Model model Programming

28
XP – EXTREME PROGRAMMING

 Everything is done in small steps

 The system always compiles, always runs
 Client as the center of development
team
 Developers have same responsibility
w.r.t. software and methodology

29
13 PRACTICES OF XP

 Whole team: client part of the team  Test-driven development: tests

 Metaphor: common analogy for the developed first
system  Design improvement (refactoring)
 The planning game, based on user  Collective code ownership
stories
 Simple design
 Continuous integration: system
always runs
 Small releases (e.g. 2 weeks)
 Sustainable pace: no overtime
 Customer tests
 Coding standards
 Pair programming

30
SCRUM

31
SCRUM FRAMEWORK

32
SCRUM: OVERALL SCHEME

33
PRODUCT OWNER
 The Product Owner represents stakeholders and is the voice of the customer.
 Product Owner is accountable for ensuring that the team delivers value to the
business.
 Product Owner
 writes customer-centric items (typically user stories),
 prioritizes them, and
 adds them to the product backlog.
 Note:
 Scrum teams should have one Product Owner.
 May also be a member of the development team
 Not recommend this person be Scrum Master.

34
SCRUM MASTER
 Scrum is facilitated by a Scrum Master : Accountable for removing
impediments for team to deliver sprint goal / deliverables.
 Scrum Master is not the team leader, but acts as a buffer between the
team and any distracting influences.
 Scrum Master ensures process is used as intended.
 Scrum Master is the enforcer of rules.
 Scrum Master’s role: protect the Team and keep it focused on the
tasks at hand.

35
DEVELOPMENT TEAM
 The Development Team is responsible for delivering shippable
product increments at end of each Sprint.
 Team = 3–9 people with cross-functional skills.
 Team does actual work (analyze, design, develop, test, technical
communication, document, etc.).
 Team is self-organizing, even though they may interface with
project management organizations (PMOs).

36
PRODUCT BACKLOG (1)
 Product backlog is an ordered list of requirements that is maintained for a product
 Contains Product Backlog Items ordered by the Product Owner based on
 considerations like risk,
 business value,
 dependencies,
 date needed, etc.

 Features added to backlog commonly written in story format

 The product backlog is the “What” that will be built, sorted in the relative order it should
be built in.
 Is open and editable by anyone,
 Product Owner is ultimately responsible for ordering the stories on the backlog for the Development
Team.

37
PRODUCT BACKLOG (2)
 The product backlog contains rough estimates of both business value
and development effort, these values are often stated in story points
using a rounded Fibonacci sequence.
 Those estimates help the Product Owner to manage the timeline
and may influence ordering of backlog items.
 Example
if the « add spellcheck » and « add table support » features have the same
business value, the one with the smallest development effort will probably have
higher priority, because the Return on Investment is higher.

38
THE SPRINT (1)
 Sprint: basic unit of development in Scrum.
 Sprint duration: one week to one month;
 « Time Boxed » effort of a constant length.
 Each sprint is preceded by a planning meeting
 where the tasks for sprint are identified, and
 Tasks: Added to story at beginning of a sprint and broken down into hours.
 Each task should not exceed 12 hours, but it's common for teams to insist that a task take no more
than a day to finish
 estimated commitment for the sprint goal made, and followed by
 a review or retrospective meeting, where the progress is reviewed and lessons for the
next sprint are identified.

39
THE SPRINT (2)
 The team after current sprint determines how many selected items
can be completed during the next sprint.
 These then go into the Sprint Backlog.
 Sprint Backlog is property of the development team
 During a sprint, no one is allowed to edit the sprint backlog except for
development team.
 Development: time-boxed; Sprint must end on time
 Requirements not completed for any reason? are omitted and returned to Product
Backlog.
 When Sprint is done, team demonstrates software.

40
SPRINT BACKLOG
 Sprint Backlog: list of work the Development Team must
address during the next sprint.
 List derived by selecting stories/features from the top of the product
backlog until the Development Team feels it has enough work to fill the
sprint.
 Thinking: This is done by the Development Team asking "Can we also do
this?" and adding stories/features to the sprint backlog.
 History: Development Team should note velocity of previous Sprints
(total story points completed from each of the last sprints’ stories) when
selecting stories/features for the new sprint.
 Use number as guide for "effort" they can complete.

41
MORE TERMINOLOGY USED IN SCRUM
 Sprint burn down chart: Daily progress for a Sprint over the sprint’s
length.
 User Story: A feature added to the backlog is commonly referred to
as a story; has a specific suggested structure.
 Done so development team can identify user, action and required result in a
request; simple way of writing requests anyone can understand.
 Example:
As a wiki user, I want a Tools menu on the Edit screen so that I can easily apply font
formatting.

42
THE LEAN STARTUP
“The only way to win is to learn faster than anyone else.”
“We must learn what customers really want, not what they say they
want or what we think they should want.”

“Reading is good, action is better.”

Eric Rise 43
LEAN
 Learn what customers really want
 Not what they say they want

 Discover whether we are on a

path that will lead to growing a
sustainable business
 Incremental and iterative
 Complete the loop as quickly as
possible

44
LEAN EXAMPLE: ZAPPOS.COM
 Selling shoes online

45
LEAN EXAMPLE: DROPBOX

46
LEAN AND SCRUM

 advantages  disadvantage

 Helps you learn faster and  May result in rework

build the right product
 Requires you to experiment
 Speed to market iteratively with clients and users

47
MODEL SELECTION: EXAMPLE 1

48
EXAMPLE 1 ANALYSIS

49
MODEL SELECTION: EXAMPLE 2

50
EXAMPLE 2 ANALYSIS

51
MODEL SELECTION: EXAMPLE 3

52
EXAMPLE 3 ANALYSIS

53
SOFTWARE DEVELOPMENT MODELS

SDLC Models

Heavyweight Lightweight
(Predictive) (Adaptive)

Waterfall Incremental Iterative RAD and Agile

Models Models Model DSDM Frameworks

Waterfall Sashimi Prototype Extreme

V Model Spiral Model Scrum Lean
Model Model model Programming

54
DIFFERENCES FOR DEVELOPERS

 Adaptive/Agile: knowledgeable, collocated, collaborative

 Heavyweight: plan-driven, adequate skills, access to external

knowledge

55
DIFFERENCES FOR CUSTOMERS

 Adaptive/Agile : dedicated, knowledgeable, collocated,

collaborative, representative, empowered

 Heavyweight: access to knowledgeable, collaborative,

representative, empowered customers

56
DIFFERENCES FOR REQUIREMENTS

 Adaptive/Agile: largely emergent, rapid change

 Heavyweight: knowable early, largely stable

57
DIFFERENCES FOR ARCHITECTURE

 Adaptive/Agile: designed for current requirements

 Heavyweight: designed for current and foreseeable

requirements

58
DIFFERENCES FOR SIZE

 Adaptive/Agile: smaller teams and products

 Heavyweight: larger teams and products

59
DIFFERENCES FOR PRIMARY OBJECTIVE

 Adaptive/Agile: rapid value

 Heavyweight: high assurance

60
READING REFERENCE

61