Life Cycle Models

Dr. Bharat Singh

1
Contents

• Classical Waterfall model

• Iterative Waterfall model
• V-model
• Prototype model
• Incremental development
• Evolutionary model
• RAD (Rapid Application Development)
• Agile Development
• Spiral Model
2
 Classical Waterfall Model
(Winston W. Royce)

• Classical waterfall model divides

life cycle into phases:
− feasibility study,
− requirements analysis and
specification,
− design,
− coding and unit testing,
− integration and system testing,
− maintenance.
3
Classical Waterfall Model

Feasibility Study

Req. Analysis and

specification
Design

Coding

Integration and
Testing
Maintenance

4
Relative Effort for Phases
• Phases between feasibility
study and testing 60
− known as development 50
Relative Effort
phases.
40
• Among all life cycle phases 30
− maintenance phase
consumes maximum effort. 20
10
• Among development
phases, 0

Maintnce
Design
Coding
Test
Req. Sp
− testing phase consumes the
maximum effort.

5
Classical Waterfall Model
(CONT.)

• Most organizations usually define:

− standards on the outputs (deliverables) produced
at the end of every phase
− entry and exit criteria for every phase.
• They also prescribe specific
methodologies for:
− specification,
− design,
− testing,
− project management, etc.

6
Classical Waterfall Model
(CONT.)

• The guidelines and methodologies of an

organization:
− called the organization's software
development methodology.
• Software development organizations:
− expect fresh engineers to master the
organization's software development
methodology.

7
Feasibility Study
• Main aim of feasibility study:determine whether
developing the product
− financially worthwhile
− technically feasible.
• First roughly understand what the customer
wants:
− different data which would be input to the system,
− processing needed on these data,
− output data to be produced by the system,
− various constraints on the behavior of the system.

8
Activities during Feasibility
Study
• Work out an overall understanding
of the problem.
• Formulate different solution
strategies.
• Examine alternate solution
strategies in terms of:
 resources required,
 cost of development, and
 development time.
9
Activities during Feasibility
Study
• Perform a cost/benefit analysis:
− to determine which solution is the
best.
− you may determine that none of
the solutions is feasible due to:
 high cost,
 resource constraints,
 technical reasons.

10
Requirements Analysis and
Specification
• Aim of this phase:
− understand the exact
requirements of the customer,
− document them properly.
• Consists of two distinct
activities:
− requirements gathering and
analysis
− requirements specification. 11
Goals of Requirements
Analysis
• Collect all related data from the
customer:
− analyze the collected data to
clearly understand what the
customer wants,
− find out any inconsistencies and
incompleteness in the
requirements,
− resolve all inconsistencies and
incompleteness. 12
Requirements Gathering

• Gathering relevant data:

− usually collected from the end-
users through interviews and
discussions.
− For example, for a business
accounting software:
 interview all the accountants of the
organization to find out their
requirements.
13
Requirements Analysis (CONT.)

• The data you initially collect

from the users:
−would usually contain several
contradictions and
ambiguities:
−each user typically has only a
partial and incomplete view of
the system.
14
Requirements Analysis (CONT.)

• Ambiguities and contradictions:

− must be identified
− resolved by discussions with the
customers.
• Next, requirements are organized:
− into a Software Requirements
Specification (SRS) document.

15
Requirements Analysis (CONT.)

• Engineers doing
requirements analysis and
specification:
−are designated as analysts.

16
Design
• Design phase transforms
requirements specification:
− into a form suitable for
implementation in some
programming language.

17
Design
• In technical terms:
− during design phase, software
architecture is derived from the
SRS document.
• Two design approaches:
− traditional approach,
− object oriented approach.

18
Traditional Design Approach

• Consists of two activities:

−Structured analysis
−Structured design

19
Structured Analysis
Activity
• Identify all the functions to be
performed.
• Identify data flow among the
functions.
• Decompose each function
recursively into sub-functions.
− Identify data flow among the
subfunctions as well.

20
Structured Analysis (CONT.)

• Carried out using Data flow

diagrams (DFDs).
• After structured analysis, carry
out structured design:
− architectural design (or high-level
design)
− detailed design (or low-level
design).
21
Structured Design
• High-level design:
− decompose the system into modules,
− represent invocation relationships
among the modules.
• Detailed design:
− different modules designed in greater
detail:
 data structures and algorithms for each
module are designed.

22
Object Oriented Design

• First identify various objects (real

world entities) occurring in the
problem:
− identify the relationships among the
objects.
− For example, the objects in a pay-roll
software may be:
 employees,
 managers,
 pay-roll register,
 Departments, etc. 23
Object Oriented Design (CONT.)

• Object structure
− further refined to obtain the
detailed design.
• OOD has several advantages:
− lower development effort,
− lower development time,
− better maintainability.

24
Implementation

• Purpose of implementation
phase (aka coding and unit
testing phase):
−translate software design into
source code.

25
Implementation

• During the implementation

phase:
− each module of the design is
coded,
− each module is unit tested
 tested independently as a stand
alone unit, and debugged,
− each module is documented.
26
Implementation (CONT.)

• The purpose of unit testing:

− test if individual modules work
correctly.
• The end product of
implementation phase:
− a set of program modules that
have been tested individually.

27
Integration and System
Testing
• Different modules are integrated in
a planned manner:
− modules are almost never integrated
in one shot.
− Normally integration is carried out
through a number of steps.
• During each integration step,
− the partially integrated system is
tested.
28
Integration and System
Testing

M1 M2

M3 M4

29
System Testing

• After all the modules have been

successfully integrated and
tested:
− system testing is carried out.
• Goal of system testing:
− ensure that the developed system
functions according to its
requirements as specified in the
SRS document. 30
Maintenance
• Maintenance of any
software product:
−requires much more effort than
the effort to develop the product
itself.
−development effort to
maintenance effort is typically
40:60.
31
Maintenance (CONT.)

• Corrective maintenance:
− Correct errors which were not discovered
during the product development phases.
• Perfective maintenance:
− Improve implementation of the system
− enhance functionalities of the system.
• Adaptive maintenance:
− Port software to a new environment,
 e.g. to a new computer or to a new operating system.

32
Iterative Waterfall Model
Iterative Waterfall Model
• Classical waterfall model is
idealistic:
− assumes that no defect is
introduced during any
development activity.
− in practice:
 defects do get introduced in almost
every phase of the life cycle.

34
Iterative Waterfall Model
(CONT.)

• Defects usually get detected

much later in the life cycle:
−For example, a design defect might
go unnoticed till the coding or
testing phase.

35
Iterative Waterfall Model
(CONT.)

• Once a defect is detected:

− we need to go back to the phase
where it was introduced
− redo some of the work done during
that and all subsequent phases.
• Therefore we need feedback paths
in the classical waterfall model.

36
Iterative Waterfall Model
(CONT.)

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance

37
Iterative Waterfall Model
(CONT.)

• Errors should be detected

• in the same phase in which they are
introduced.
• For example:
• if a design problem is detected in
the design phase itself,
• the problem can be taken care of much
more easily
• than say if it is identified at the end of
the integration and system testing phase.

38
Phase containment of
errors
• Reason: rework must be carried out not
only to the design but also to code and
test phases.
• The principle of detecting errors as close to
its point of introduction as possible:
− is known as phase containment of errors.
• Iterative waterfall model is by far the most
widely used model.
− Almost every other model is derived from the
waterfall model.
39
Classical Waterfall Model
(CONT.)

• Irrespective of the life cycle

model actually followed:
− the documents should reflect a
classical waterfall model of
development,
− comprehension of the documents is
facilitated.

40
Iterative Waterfall Model
(CONT.)
• An improved version of the traditional
Waterfall Model, combining the
structured, sequential approach
• Allows for revisions and feedback at each
phase.
• A refined and reliable final product.
• Allows for continuous improvement,
ensuring that the software meets evolving
business needs while minimizing risks and
costs.
V-Model (Verification and
Validation)
V-Model (Verification and Validation)

43
V-Model (Verification and Validation)

• Verification and validation software

development process model.
• This V shape demonstrates the
relationships between each phase of the
development life cycle and its associated
phase of testing.

44
V-Model (Verification and Validation)

• Any phase in the development process begins only if

the previous phase is complete and has a
correspondence related testing phase which is
performed against this phase completion.
− Similar to the Waterfall model, the V-Model does not
define the process to go back to the previous phase to
handle changes in requirement.
• The technical aspect of the project cycle is considered
as a V shape starting with the business needs on the
upper left and ending with the user acceptance testing
on the upper right.

45
V-Model (Verification and Validation)

• The usage of V-Model can fall under the projects

which not focus on changing the requirements,
for example:
• Projects initiated from a request for proposals
(RFPs), the customer has a very clear
documented requirements
− Military projects
− Mission Critical projects, for example, in a Space
shuttle
− Embedded systems.
− Projects with defined and clear requirements
46
Prototyping Model
Prototyping Model
• Before starting actual
development,
− a working prototype of the system
should first be built.
• A prototype is a toy implementation
of a system:
− limited functional capabilities,
− low reliability,
− inefficient performance.
48
Reasons for developing a
prototype
• Illustrate to the customer:
− input data formats, messages, reports,
or interactive dialogs.
• Examine technical issues associated
with product development:
− Often major design decisions depend
on issues like:
 response time of a hardware controller,
 efficiency of a sorting algorithm, etc.

49
Prototyping Model (CONT.)

• The third reason for developing a

prototype is:
− it is impossible to ``get it right'' the
first time,
− we must plan to throw away the
first product
 if we want to develop a good product.

50
Prototyping Model (CONT.)

• Start with approximate requirements.

• Carry out a quick design.
• Prototype model is built using several
short-cuts:
− Short-cuts might involve using inefficient,
inaccurate, or dummy functions.
 A function may use a table look-up rather than
performing the actual computations.

51
Prototyping Model (CONT.)

• The developed prototype is

submitted to the customer for his
evaluation:
− Based on the user feedback, requirements
are refined.
− This cycle continues until the user approves
the prototype.
• The actual system is developed
using the classical waterfall
approach.
52
Prototyping Model (CONT.)

Build Prototype

Requirements Customer Customer

Quick Design Evaluation of satisfied Design
Gathering Prototype

Refine Implement
Requirements

Test

Maintain

53
Prototyping Model (CONT.)

• Requirements analysis and specification

phase becomes redundant:
− final working prototype (with all user
feedbacks incorporated) serves as an animated
requirements specification.
• Design and code for the prototype is
usually thrown away:
− However, the experience gathered from
developing the prototype helps a great deal
while developing the actual product.
54
Prototyping Model (CONT.)

• Even though construction of a working

prototype model involves additional cost --
- overall development cost might be lower
for:
− systems with unclear user requirements,
− systems with unresolved technical issues.
• Many user requirements get properly
defined and technical issues get resolved:
− these would have appeared later as change requests
and resulted in incurring massive redesign costs.
55
Evolutionary Model
Evolutionary Model
• Evolutionary model (aka successive
versions or incremental model):
− The system is broken down into several
modules which can be incrementally
implemented and delivered.
• First develop the core modules of the
system.
• The initial product skeleton is refined
into increasing levels of capability:
− by adding new functionalities in successive
versions.
57
Evolutionary Model (CONT.)

• Successive version of the

product:
− functioning systems capable of
performing some useful work.
− A new release may include new
functionality:
 also existing functionality in the
current release might have been
enhanced.
58
Evolutionary Model (CONT.)

C
A AB A
B

59
Necessary Conditions for
Implementing of Evolutionary
Model
• Customer needs are clear and been explained in
deep to the developer team.
• There might be small changes required in separate
parts but not a major change.
• As it requires time, so there must be some time
left for the market constraints.
• Risk is high and continuous targets to achieve and
report to customer repeatedly.
• It is used when working on a technology is new
and requires time to learn.

60
Advantages of Evolutionary
Model
• Users get a chance to experiment with a
partially developed system:
− much before the full working version is
released,
• Helps finding exact user requirements:
− much before fully working system is developed.
• Core modules get tested thoroughly:
− reduces chances of errors in final product.

61
Disadvantages of
Evolutionary Model
• Often, difficult to subdivide
problems into functional units:
− which can be incrementally
implemented and delivered.
− evolutionary model is useful for
very large problems,
 where it is easier to find modules for
incremental implementation.

62
Evolutionary Model with
Iteration
• Many organizations use a
combination of iterative and
incremental development:
− a new release may include new
functionality
− existing functionality from the
current release may also have
been modified.
63
Evolutionary Model with
iteration
• Several advantages:
− Training can start on an earlier release
 customer feedback taken into account
− Markets can be created:
 for functionality that has never been
offered.
− Frequent releases allow developers to
fix unanticipated problems quickly.

64
RAPID APPLICATION DEVELOPMENT
(RAD)
RAPID APPLICATION
DEVELOPMENT (RAD)

• Emphasizes quick and iterative release

cycles, primarily focusing on delivering
working software in shorter timelines.
• RAD is designed to be more flexible and
responsive to user feedback
• Changing requirements throughout the
development process.

66
RAPID APPLICATION
DEVELOPMENT (RAD)

• The major goals of the RAD model are as

follows:
− To decrease the time taken and the cost
incurred to develop software systems.
− To limit the costs of accommodating change
requests.
− To reduce the communication gap between
the customer and the developers.

67
RAPID APPLICATION
DEVELOPMENT (RAD)

68
RAPID APPLICATION
DEVELOPMENT (RAD)
RAPID APPLICATION
DEVELOPMENT (RAD)

• The major goals of the RAD model are as

follows:
− To decrease the time taken and the cost
incurred to develop software systems.
− To limit the costs of accommodating change
requests.
− To reduce the communication gap between
the customer and the developers.
• This model has the features of both
prototyping and evolutionary models. 70
RAPID APPLICATION
DEVELOPMENT (RAD)

• In this, prototypes are constructed, and

incrementally the features are developed
and delivered to the customer.
− But unlike the prototyping model, the
prototypes are not thrown away but are
enhanced and used in the software
construction.

71
RAPID APPLICATION
DEVELOPMENT (RAD)

• Software often does not meet the customer

expectations and many change request are
generated by the customer.
− The changes are incorporated through subsequent
maintenance efforts.
− This made the cost of accommodating the changes
extremely high and it usually took a long time to
have a good solution in place that could reasonably
meet the requirements of the customers.

72
RAPID APPLICATION
DEVELOPMENT (RAD)

• Software often does not meet the customer

expectations and many change request are
generated by the customer.
− The changes are incorporated through subsequent
maintenance efforts.
− This made the cost of accommodating the changes
extremely high and it usually took a long time to
have a good solution in place that could reasonably
meet the requirements of the customers.

73
RAPID APPLICATION
DEVELOPMENT (RAD)
• Development takes place in a series of short cycles or iterations.
• At any time, the development team focuses on the present iteration
only, and therefore plans are made for one increment at a time.
• The time planned for each iteration is called a time box.
• Each iteration is planned to enhance the implemented functionality of
the application by only a small amount.
• During each time box, a quick-and-dirty prototype-style software for
some functionality is developed.
• The customer evaluates the prototype and gives feedback on the
specific improvements that may be necessary. The prototype is refined
based on the customer feedback.
• The development team almost always includes a
customer representative to clarify the
requirements. 74
RAPID APPLICATION
DEVELOPMENT (RAD)
• Application characteristics that render RAD
unsuitable
− Generic products (wide distribution)
− Requirement of optimal performance and/or
reliability
− Lack of similar products
− Monolithic entity- uses one code base to perform
multiple business functions.
• Though RAD is expected to lead to faster software
development compared to the traditional models (such as
the prototyping model), the quality and reliability would be
inferior. 75
Spiral Model
Spiral Model
• Proposed by Boehm in 1988.
• Each loop of the spiral represents a
phase of the software process:
− the innermost loop might be concerned with
system feasibility,
− the next loop with system requirements
definition,
− the next one with system design, and so on.
• There are no fixed phases in this model,
the phases shown in the figure are just
examples.
77
Spiral Model (CONT.)

• The team must decide:

− how to structure the project into phases.
• Start work using some generic model:
− add extra phases
 for specific projects or when problems are
identified during a project.
• Each loop in the spiral is split into
four sectors (quadrants).

78
Spiral Model (CONT.)

Determine Identify &

Objectives Resolve Risks

Customer
Evaluation of Develop Next
Prototype Level of Product

79
Spiral Model (CONT.)

80
Objective Setting (First
Quadrant)

• Identify objectives of the phase,

• Examine the risks associated with
these objectives.
− Risk:
 any adverse circumstance that might
hamper successful completion of a
software project.

• Find alternate solutions possible.

81
Risk Assessment and Reduction (Second
Quadrant)

• For each identified project risk,

− a detailed analysis is carried out.
• Steps are taken to reduce the risk.
• For example, if there is a risk that the
requirements are inappropriate:
− a prototype system may be developed.

82
Spiral Model (CONT.)

• Development and Validation (Third

quadrant):
− develop and validate the next level of the
product.
• Review and Planning (Fourth quadrant):
− review the results achieved so far with the
customer and plan the next iteration around the
spiral.
• With each iteration around the spiral:
− progressively more complete version of the
software gets built. 83
Spiral Model as a meta
model
• Subsumes all discussed models:
− a single loop spiral represents waterfall
model.
− uses an evolutionary approach --
 iterations through the spiral are evolutionary
levels.
− enables understanding and reacting to risks
during each iteration along the spiral.
− uses:
 prototyping as a risk reduction mechanism
 retains the step-wise approach of the waterfall
model.
84
Comparison of Different Life Cycle
Models
• Iterative waterfall model
− most widely used model.
− But, suitable only for well-understood
problems.
• Prototype model is suitable for
projects not well understood:
− user requirements
− technical aspects

85
Comparison of Different Life Cycle
Models (CONT.)

• Evolutionary model is suitable for

large problems:
− can be decomposed into a set of modules that
can be incrementally implemented,
− incremental delivery of the system is
acceptable to the customer.
• The spiral model:
− suitable for development of technically
challenging software products that are subject
to several kinds of risks.
86
Agile Model

87
Agile Model
• Businesses now operate in a global, rapidly
changing environment.
• Plan-driven software development processes
are not geared to rapid software
development.
− As the requirements change or as requirements
problems are discovered, the system design or
implementation has to be reworked and retested.
• Therefore, for business systems in particular,
development processes that focus on rapid
software development and delivery are
essential. 88
Agile Model
• Rapid software development became known as
agile development or agile methods.
• So, the main aim of the Agile model is to
facilitate quick project completion.
• These agile methods are designed to produce
useful software quickly.
• Agility is achieved by fitting the process to the
project and removing activities that may not be
essential for a specific project.

89
Agile Model
• All of the agile methods that have been proposed
share a number of common characteristics:
− The processes of specification, design and
implementation are interleaved. The user requirements
document is an outline definition of the most important
characteristics of the system.
− The system is developed in a series of increments. End-users and
other system stakeholders are involved in specifying and evaluating
each increment.
− Extensive tool support is used to support the
development process. Tools that may be used include
automated testing tools, tools to support configuration
management, and system integration and tools to
automate user interface production. 90
Agile Model
• particularly successful for two kinds of system
development.
− 1. Product development where a software company is developing a
small or medium-sized product for sale. Virtually all software
products and apps are now developed using an agile approach.
− 2. Custom system development within an organization, where there
is a clear commitment from the customer to become involved in the
development process and where there are few external
stakeholders and regulations that affect the software.

91
Agile Model

92
Plan-driven and agile
development
• Plan-driven development
− A plan-driven approach to software engineering is based around
separate development stages with the outputs to be produced
at each of these stages planned in advance.
− Not necessarily waterfall model – plan-driven, incremental
development is possible
− Iteration occurs within activities.
• Agile development
− Specification, design, implementation and testing are inter-
leaved and the outputs from the development process are
decided through a process of negotiation during the software
development process.

93
Plan-driven and agile
specification

94
Agile Development Techniques
• Crystal
• ATERN (DSDM) Dynamic Systems Development technique
• Extreme Programming (XP)
• Pair programming
• Rapid Application Development (RAD)
• Scrum
• Lean project Development
− Kanban

95
Agile Development Techniques
• Extreme Programming (XP). The name was
coined by Kent Beck (Beck 1998)
− the approach was developed by pushing
recognized good practice, such as iterative
development, to “extreme” levels.
− In XP, requirements are expressed as scenarios
(called user stories), which are implemented
directly as a series of tasks.

96
Extreme programming

• Perhaps the best-known and most widely

used agile method.
• 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.97
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.

98
The extreme programming
release cycle

99
Testing in XP

• 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.
100
Test-first development

• 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 functionality is added, thus checking
that the new functionality has not introduced
errors.
101
Customer involvement

• The role of the customer in the testing process is to help

develop acceptance tests for the stories that are to be
implemented in the next release of the system.
• The customer who is part of the team writes tests as
development proceeds. All new code is therefore
validated to ensure that it is what the customer needs.
• However, people adopting the customer role have
limited time available and so cannot work full-time with
the development team. They may feel that providing the
requirements was enough of a contribution and so may
be reluctant to get involved in the testing process.
102
Test case description for
dose checking

103
Test automation

• Test automation means that tests are written as

executable components before the task is implemented
− These testing components should be stand-alone, should
simulate the submission of input to be tested and should check
that the result meets the output specification. An automated
test framework (e.g. Junit) is a system that makes it easy to
write executable tests and submit a set of tests for execution.
• As testing is automated, there is always a set of tests
that can be quickly and easily executed
− Whenever any functionality is added to the system, the tests
can be run and problems that the new code has introduced can
be caught immediately.

104
XP testing difficulties

• 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.
105
Pair programming
• In XP, programmers work in pairs, sitting together to
develop code.
• 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 this.
• Measurements suggest that development productivity
with pair programming is similar to that of two people
working independently.

106
Pair programming

• In pair programming, programmers sit together at the

same workstation 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 evidence that a pair working together is more efficient
than 2 programmers working separately.

107
Advantages of pair
programming

• It supports the idea of collective ownership and

responsibility for the system.
− Individuals are not held responsible for problems with the code.
Instead, the team has collective responsibility for resolving
these problems.
• It acts as an informal review process because each line
of code is looked at by at least two people.
• It helps support refactoring, which is a process of
software improvement.
− Where pair programming and collective ownership are used,
others benefit immediately from the refactoring so they are
likely to support the process.
108
Agile project management

• The principal responsibility of software project managers

is to manage the project so that the software is
delivered on time and within the planned budget for the
project.
• The standard approach to project management is plan-
driven. Managers draw up a plan for the project showing
what should be delivered, when it should be delivered
and who will work on the development of the project
deliverables.
• Agile project management requires a different approach,
which is adapted to incremental development and the
particular strengths of agile methods.
109
Scrum
• The Scrum approach is a general agile method
but its focus is on managing iterative
development rather than specific agile practices.
• 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 110
lessons learned from the project.
The Scrum process

111
The Sprint cycle

• Sprints are fixed length, normally 2–4 weeks.

They correspond to the development of a
release of the system in XP.
• 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 to be developed
during the sprint.
112
The Sprint cycle
• 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 then begins.

113
Teamwork in Scrum
• Key roles and responsibilities
• The team members assume three basic
roles:
− product owner,
− scrum master,
− team member.

114
Teamwork in Scrum
• Key roles and responsibilities
• product owner
• The product owner is responsible for communicating the
customer’s perspective of the software to the
development team
• The product owner in consultation with the team
members defines the features of the software to be
developed in the next sprint, decides on the release
dates, and also may reprioritize the required features
that are yet to be developed if necessary

115
Teamwork in Scrum
• Key roles and responsibilities
• Team member.
− A scrum team usually consists of cross-
functional team members with expertise in
areas such as quality assurance,
programming, user interface design, and
testing.

116
Teamwork in Scrum
• The ‘Scrum master’ is a facilitator who arranges daily
meetings, tracks the backlog of work to be done,
records decisions, measures progress against the
backlog and communicates with customers and
management outside of the team.
• The whole team attends short daily meetings where all
team members share information, describe their
progress since the last meeting, problems that have
arisen and what is planned for the following day.
− This means that everyone on the team knows what is going on
and, if problems arise, can re-plan short-term work to cope with
them.

117
Scrum
• Three main artifacts form an important
part of the scrum methodology.
• These are:
− product backlog,
− sprint backlog,
− sprint burndown chart.

118
Scrum Artifacts
• Product Backlog
− document that is periodically updated and reprioritized.
− contains a prioritized listing of all the features that are yet to be
developed.
− written in the form of user stories.
− new features may get added to the product backlog and some
features may even get deleted.

• Sprint Backlog
− The team identifies one or more features (user stories) from the
product backlog
− From sprint backlog lists, the tasks that are identified and
committed by the team to develop and complete during the
ensuing sprint.
119
Scrum
• Sprint Burndown Chart
− The sprint burndown chart is used as a tool
to visualize the progress made and the work
remaining to be undertaken on a daily basis.
− daily stand-up meeting

120
Scrum benefits

• 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.121
Lean software development

• Lean software development is a translation

of lean manufacturing principles and practices to
the software development domain.
• Adapted from the Toyota Production
System, it is emerging with the support of a
pro-lean subculture within the agile community.
• Lean offers a solid conceptual framework,
values and principles, as well as good practices,
derived from experience, that support agile
organizations.
122
Lean software development

• The Lean approach is often associated with the

Minimum Viable Product (MVP) strategy.
− In this strategy, a team releases the most essential
version of their product to the market.
− Subsequently, the team collects feedback from
consumers to understand their preferences, dislikes,
and desired additions. Based on this feedback, they
iterate and refine the product.

123
Lean Principle
• The central theme of Lean is to achieve overall process
efficiency through elimination of various things that
cause waste of work and introduce delays.
• Lean development can be summarized by seven
principles, very close in concept to lean manufacturing
principles:
− Eliminate waste
− Amplify learning
− Decide as late as possible
− Deliver as fast as possible
− Empower the team
− Build in integrity
− Optimize the whole 124
Lean Principle
• Eliminate waste-
− Project managers have regular meetings to discover and reduce waste. It could be in the
form of redundant code, unclear requirements, or insufficient testing. Degrade code quality,
increase development time and effort.

• Amplify learning-
− extensive code review and cross-team meetings.

• Decide as late as possible-

− when you develop an application and discover that it is entirely unsuitable for the
market.
− This approach foresees this danger and allows improvement by deferring
irreversible judgments until all experiments are completed.

• Deliver as fast as possible

− Previously, long-term planning was considered critical to
corporate success
− Rapidly developing products with limited functionality and 125
launching them to market to measure reaction.
Lean Principle
• Empower the team
− LSD is more concerned with empowering team members than
with dominating them.
− Establishing a collaborative environment maintains a great
balance when faced with tight deadlines and an enormous
workload.
• Build in integrity
− It is all about minimizing waste while maintaining a focus on quality.
− Developers frequently use test-driven programming to validate their code before
writing it.

• Optimize the whole

− Lean's approach enables managers to break down a problem into
its constituent elements to optimize the team's workflow, foster
team togetherness, and instill a sense of shared responsibility, all
of which result in improved team performance. 126
Kanban

• Kanban (signboard or billboard) is a lean method to

manage and improve work across human systems.

127
Kanban

• This approach aims to manage work by balancing

demands with available capacity, and by improving the
handling of system-level bottlenecks.
• Work items are visualized to give participants a view of
progress and process, from start to finish—usually via
a kanban board.
• Work is pulled as capacity permits, rather than work
being pushed into the process when requested.

128
Scaling agile methods
• Agile methods have proved to be successful for
small and medium sized projects that can be
developed by a small co-located team.
• It is sometimes argued that the success of these
methods comes because of improved
communications which is possible when
everyone is working together.
• Scaling up agile methods involves changing
these to cope with larger, longer projects where
there are multiple development teams, perhaps
working in different locations.
129
Large systems
development

• Large systems are usually collections of separate,

communicating systems, where separate teams develop each
system. Frequently, these teams are working in different
places, sometimes in different time zones.
• Large systems are ‘brownfield systems’, that is they include
and interact with a number of existing systems. Many of the
system requirements are concerned with this interaction and
so don’t really lend themselves to flexibility and incremental
development.
• Where several systems are integrated to create a system, a
significant fraction of the development is concerned with
system configuration rather than original code development.

130
Large system development

• Large systems and their development processes are

often constrained by external rules and regulations
limiting the way that they can be developed.
• Large systems have a long procurement and
development time. It is difficult to maintain coherent
teams who know about the system over that period as,
inevitably, people move on to other jobs and projects.
• Large systems usually have a diverse set of
stakeholders. It is practically impossible to involve all of
these different stakeholders in the development process.

131
Scaling out and scaling up
• ‘Scaling up’ is concerned with using agile
methods for developing large software systems
that cannot be developed by a small team.
• ‘Scaling out’ is concerned with how agile
methods can be introduced across a large
organization with many years of software
development experience.
• When scaling agile methods it is essential to
maintain agile fundamentals
− Flexible planning, frequent system releases,
continuous integration, test-driven development and
132
good team communications.
Scaling up to large
systems

• For large systems development, it is not possible to focus

only on the code of the system. You need to do more up-
front design and system documentation
• Cross-team communication mechanisms have to be designed
and used. This should involve regular phone and video
conferences between team members and frequent, short
electronic meetings where teams update each other on
progress.
• Continuous integration, where the whole system is built every
time any developer checks in a change, is practically
impossible. However, it is essential to maintain frequent
system builds and regular releases of the system.

133
Scaling out to large
companies
• Project managers who do not have experience of agile methods
may be reluctant to accept the risk of a new approach.
• Large organizations often have quality procedures and
standards that all projects are expected to follow and, because
of their bureaucratic nature, these are likely to be incompatible
with agile methods.
• Agile methods seem to work best when team members have a
relatively high skill level. However, within large organizations,
there are likely to be a wide range of skills and abilities.
• There may be cultural resistance to agile methods, especially in
those organizations that have a long history of using
conventional systems engineering processes.

134