Life Cycle Models

Dr. Bharat Singh

Contents
· Classical Waterfall model
· Iterative Waterfall model
· V-model
· Prototype model
· Incremental development
· Evolutionary model
· RAD (Rapid Application Development)
· Agile Development
· Spiral Model
 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.
Classical Waterfall Model

Feasibility Study

Req. Analysis and

specification
Design

Coding

Integration and
Testing
Maintenance
Relative Effort for Phases
· Phases between
feasibility study and 60
testing 50 Relative Effort
- known as development
40
phases.
30
· Among all life cycle
20
phases
- maintenance phase 10
consumes maximum 0

Maintnce
Design
Req. Sp

Coding
Test
effort.
· Among development
phases,
- testing phase consumes
the maximum effort.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
Requirements Analysis (CONT.)

· Engineers doing
requirements analysis
and specification:
- are designated as
analysts.
Design
· Design phase transforms
requirements
specification:
- into a form suitable for
implementation in some
programming language.
Design
· In technical terms:
- during design phase,
software architecture is
derived from the SRS
document.
· Two design approaches:
- traditional approach,
- object oriented approach.
Traditional Design Approach

· Consists of two activities:

- Structured analysis
- Structured design
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.
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).
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.
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.
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.
Implementation
· Purpose of
implementation phase
(aka coding and unit
testing phase):
- translate software design
into source code.
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.
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.
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.
Integration and System Testing

M1 M2

M3 M4
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.
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.
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.
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.
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.
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.
Iterative Waterfall Model (CONT.)

Feasibility Study

Req. Analysis

Design

Coding

Testing

Maintenance
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.
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.
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.
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
V-Model (Verification and
Validation)
V-Model (Verification and Validation)
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.
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.
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
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.
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.
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.
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.
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.
Prototyping Model (CONT.)

Build Prototype

Requirements Customer Customer

Gathering Quick Design Evaluation of satisfied Design
Prototype

Refine Implement
Requirements

Test

Maintain
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.
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
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.
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.
Evolutionary Model (CONT.)

C
A AB A
B
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.
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.
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.
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.
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.
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.
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.
RAPID APPLICATION
DEVELOPMENT (RAD)
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
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.
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.
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.
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
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.
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.
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).
Spiral Model (CONT.)

Determine Identify &

Objectives Resolve Risks

Customer
Evaluation of Develop Next
Prototype Level of Product
Spiral Model (CONT.)
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.
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.
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
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:
*
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
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.
Agile Model
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.
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.
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
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.
Agile Model
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.
Plan-driven and agile
specification
Agile Development Techniques
· Crystal
· ATERN (DSDM) Dynamic Systems Development technique
· Extreme Programming (XP)
· Pair programming
· Rapid Application Development (RAD)
· Scrum
· Lean project Development
- Kanban
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.
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
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.
The extreme programming
release cycle
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
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.
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
Test case description for dose
checking
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.
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
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.
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.
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.
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.
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
The Scrum process
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.
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.
Teamwork in Scrum
· Key roles and responsibilities
· The team members assume three
basic roles:
- product owner,
- scrum master,
- team member.
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
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.
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.
Scrum
· Three main artifacts form an
important part of the scrum
methodology.
· These are:
- product backlog,
- sprint backlog,
- sprint burndown chart.
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.
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
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
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
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.
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
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 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.
Kanban
· Kanban (signboard or billboard) is a lean
method to manage and improve work across
human systems.
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.
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
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
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.
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
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.
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.