SDLC

AGILE METHODOLOGY

SDLC
SDLC abbreviation stands for software
development life cycle
SDLC is a structured methodology used in the
development of software products and
packages. This methodology is used from the
conception phase through to the delivery and
end of project delivering software product.

SLDC methodology:
SDLC definition
Waterfall SDLC
V-Shape SDLC
Spiral SDLC
RUP SDLC
Agile methods

Some Agile Methods

Extreme Programming (XP)

Feature Driven Development
(FDD)
Scrum
Agile Unified Process(AUP)

Extreme Programming - XP
For small-to-medium-sized teams developing software
with vague or rapidly changing requirements
Coding is the key activity throughout

a software project

Communication among teammates is done with code

Life cycle and behavior of complex objects defined in test
cases again in code

Extreme Programming (XP)

user stories
values
acceptance test criteria
iteration plan

simple design
CRC cards

spike solutions
prototypes

refactoring
pair
programming

Release
software increment
project velocity computed

unit test
continuous integration
acceptance testing

Extreme Programming (XP)

XP Planning
Begins with the creation of user
stories
Agile team assesses each story
and assigns a cost
Stories are grouped to for a
deliverable increment
A commitment
delivery date

is

made

on

After the first increment project

Extreme Programming (XP)

XP Design
Follows the KIS (keep it simple)
principle
Design provides implementation
guidance for a story
Encourage the use of CRC (classresponsibility collaborator) cards
For difficult design problems,
suggests the creation of spike
solutionsa design prototype

CRC Cards
Class:
Class:
Description:
Class:
Description:
Class:FloorPlan
Description:
Responsibility:
Description:
Responsibility:
Responsibility:
Responsibility:

Collaborator:
Collaborator:
Collaborator:
Collaborator:

defines floor plan name/type

manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows

Wall

shows position of video cameras

Camera

Extreme Programming (XP)

XP Coding
Recommends the construction of
a unit test for a store before
coding commences
Encourages pair programming
Integration of work (done by
pair programmer) on daily basis
Yielding

smoke testing
uncover errors early

helps

to

Pair Programming
Pair programming is a dialogue between two people
trying to simultaneously programming (analyze and
design and test) and understand together how to
program better.
It is a conversation at many levels, assisted by and
focused on a computer -- Kent Beck

Extreme Programming (XP)

XP Testing
All unit tests are executed daily
Encourages a regression testing
strategy when ever code is
modified
Acceptance tests are defined
by the customer and executed to
assess
customer
visible
functionality

Feature Driven Design (FDD)

Five FDD process activities
1.

Develop an overall model Produce class and

sequence diagrams from chief architect
meeting with domain experts and developers.

2.

Build a features list Identify all the features

that support requirements. The features are
functionally decomposed into Business
Activities steps within Subject Areas.
Features are functions that can be developed in two
weeks and expressed in client terms with the
template: <action> <result> <object>
i.e.

Calculate the total of a sale

3.

Plan by feature -- the development staff

plans the development sequence of features

4.

Design by feature -- the team produces

sequence diagrams for the selected features

5.

Build by feature the team writes and tests

the code

FDD Process Template

Entry Tasks Verification Exit : (ETVX)
Entry: A brief description of the process, and all preconditions that should hold before the process starts

Tasks: A list of all tasks that should be done during

the process.

Verification: Conditions which clarify if the process

has been completed successfully

FDD Process (1/8)

Activities within each Process follow ETVX Template

FDD A 5 Step Process

1.Develop
an
Overall
Model

2.Build a

3.Plan

4.Design

5.Build

Feature

By

By

By

List

Feature

Feature

Feature

Fig Source: Palmer, SR., Felsing , JM.2002,p.57).

Develop an Overall Model (2/8)

Entry Criteria
Domain experts, Chief Programmers and the Chief
Architect have been selected.

Tasks
Verification
By users & Domain Experts
Exit criteria
Class diagram

(Fig. Source: Palmer, SR., Felsing ,

JM.2002,p.106)

Build a Features List (3/8)

Entry Criteria
Domain experts, CP & CA have been selected
Tasks
Domain decomposed into Major Features Sets
Major Feature Sets comprise of Feature Sets
Feature Sets comprises Features
Verification
Source: Palmer, SR., Felsing , JM.2002,p.135

Self Assessment of Modeling Team Members

Plan by Feature (4/8)

Entry Criteria
Completed Building a Features List

Tasks
To achieve development sequence
Verification
A self-assessment
Exit criteria
Business activities with Completion dates..
Source: Palmer, SR., Felsing , JM.2002,p.146

Design by Feature (5/8)

Entry Criteria
Planning process has completed.

Tasks
CP, Work Package, Feature Team, Sequence
diagram, Update the Object Model. (Next slide)
Verification
Design inspection is made.
Exit criteria

Continued (6/8)

(Fig. Source: Palmer, SR., Felsing , JM.2002,p.160)

Build by Feature (7/8)

Entry Criteria
The Design by Feature process has completed.

Tasks
Class owners implement the classes.

Verification
Successful Code Inspection & Unit Testing

Exit criteria

Iterations of Design by Feature & Build by

Feature Processes (8/8)

AUP (

Agile Unified Process)

Model

Implementation

Test

Deployment

Configuration Management

Project Management

Environment

Agile unified process

Agile Unified Process

Phases
Disciplines
Philosophies
Releases

Disciplines
Model

Understand business & problem domain

Identify a viable solution

Implementation

Transform model(s) into executable code

Test

Ensure quality

Verify that requirements are met

Disciplines
Deployment

Make system available to end users

Configuration Management

Manage access to project artifacts

Control and manage changes

Project management

Managing risks, directing and coordinating people

Disciplines
Environment

Ensuring a proper process, guidance and tools

Releases

Development release iteration

Deployment to QA or demo area

Production release iteration

Deployment to production area

SCRUM
Product Owner

Is (or is the representative of) the Customer

Develops and maintains the Product Backlog

Prioritizes the Product Backlog
Empowered to make decisions for all customers and users
Presents and explains Product Backlog to team

Scrum Team

Performs the work directed by the Customer

Self-organizing
Business and technical skills to build an increment of functionality
Responsible for estimating and committing to work
Full autonomy and authority during a Sprint

ScrumMaster

Guides the Agile Execution

Responsible for the process

Responsible for maximizing team productivity
Sets up and conducts meetings
Representative to management and team
Characteristics of a border collie or sheepdog

How Scrum Works?

The Key Components of Agile

User Stories Simple statements of requirements written

from the customer's point of view. , user need to be able to
retrieve and update vendor address information.

Product Backlog Collection of user stories that need to

be addressed to consider the effort (Product) complete.

Sprint A fixed length work period in which items taken from

the backlog are satisfied. An Agile project is a sequence of
sprints.

Sprint Planning Session A team meeting in which the

product owner reviews and explains each backlog items and its
priority, the other team members task out the items and commit
(or not) to performing each item, and the agile coach sets up the
sprint management tools.

Sprint Review Session At the closure of each sprint,

work completed is presented and reviewed, lessons learned
discussed, the overall sprint is evaluated and reviewed.

Sprints
Scrum projects make progress in a series of sprints

Analogous to XP iterations

Target duration is one month

+/- a week or two

But, a constant duration leads to a better rhythm

Product is designed, coded, and tested during the sprint

No changes during the sprint

Change

Inputs

Sprint

Tested Code

Plan sprint durations around how long you can commit to keeping change
out of the sprint

Scrum Framework
Roles : Product Owner, ScrumMaster, Team
Ceremonies : Sprint Planning, Sprint Review, Sprint
Retrospective, & Daily Scrum Meeting
Artifacts : Product Backlog, Sprint Backlog, and
Burndown Chart

Product Owner
Define the features of the product
Decide on release date and content
Be responsible for the profitability of the product (ROI)
Prioritize features according to market value
Adjust features and priority every iteration, as needed
Accept or reject work results.

The Scrum Master

Represents management to the
project
Responsible for enacting Scrum
values and practices
Removes impediments
Ensure that the team is fully
functional and productive
Enable close cooperation across all
roles and functions
Shield the team from external

Scrum Team
Typically 5-10 people
Cross-functional
QA, Programmers, UI Designers, etc.

Members should be full-time

May be exceptions (e.g., System
Admin, etc.)

Teams are self-organizing

What to do if a team self-organizes
someone off the team??
Ideally, no titles but rarely a possibility

Ceremonies
Sprint Planning Meeting
Sprint
Daily Scrum
Sprint Review Meeting

en
t
em

er
s

M
an
ag

to
m

Cu
s

Te
am

Sc
ru
m

Pr
od
uc

tO

wn
er

Spring Planning Meeting

Product Backlog
Team Capabilities
Business Conditions
Technology
Current Product

Sprint Planning
Meeting

Sprint Goal

Sprint Backlog

Parts of Sprint Planning Meeting

1st Part:

Creating Product Backlog

Determining the Sprint Goal.

Participants: Product Owner, Scrum Master, Scrum

Team

2nd Part:

Participants: Scrum Master, Scrum Team

Creating Sprint Backlog

Pre-Project/Kickoff Meeting
A special form of Sprint Planning Meeting
Meeting before the begin of the Project

Sprint
A month-long iteration, during which is incremented a
product functionality
NO outside influence can interfere with the Scrum team
during the Sprint
Each Sprint begins with the Daily Scrum Meeting

Daily Scrum
Parameters
Daily
15-minutes
Stand-up
Not for problem solving

Three questions:
1. What did you do yesterday
2. What will you do today?
3. What obstacles are in your way?

Daily Scrum
Is NOT a problem solving session
Is NOT a way to collect information about WHO is behind
the schedule
Is a meeting in which team members make commitments
to each other and to the Scrum Master
Is a good way for a Scrum Master to track the progress of
the Team

Scrum FAQs
Why daily?
How does a project get to be a year
late?
One day at a time.
Fred Brooks, The Mythical ManMonth.

Can Scrum meetings be replaced by

emailed status reports?
No
Entire team sees the whole picture
every day
Create peer pressure to do what

Sprint Review Meeting

Team presents what it

accomplished during the sprint
Typically takes the form of a
demo of new features or
underlying architecture
Informal
2-hour prep time rule

Participants
Customers
Management
Product Owner
Other engineers

Sprint Retrospective Meeting

Scrum Team only
Feedback meeting
Three questions

Start

Stop

Continue

Dont skip for the first 5-6 sprints!!!

Product Backlog
A list of all desired work on the project

Usually a combination of
story-based work (let user search and replace)
task-based work (improve exception handling)

List is prioritized by the Product Owner

Typically a Product Manager, Marketing, Internal

Customer, etc.

Product Backlog
Requirements for a system, expressed as a prioritized list
of Backlog Items
Is managed and owned by a Product Owner
Spreadsheet (typically)
Usually is created during the Sprint Planning Meeting
Can be changed and re-prioritized before each PM

Sample Product Backlog

Sprint Burn down Chart

Depicts the total Sprint Backlog hours remaining per day
Shows the estimated amount of time to release
Ideally should burn down to zero to the end of the Sprint
Actually is not a straight line
Can bump UP

Release Burndown Chart

Will the release be done on right time?
X-axis: sprints
Y-axis: amount of hours remaining
The estimated work remaining can also burn up

Product Burndown Chart

Is a big picture view of projects progress (all the
releases)