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)

simple design CRC cards user st ories values accept ance t est crit eria it erat ion plan

spike solut ions prot ot ypes

ref act oring pair programming

Release
sof t w are increment proj ect v elocit y comput ed

unit t est cont inuous int egrat ion accept ance t est ing

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 (class-responsibility collaborator) cards of CRC

For difficult design problems, suggests the creation of spike

CRC Cards
Class: Class: Descri p tion: Class: Descri p tion: FloorPlan Class: Descrip tion: Responsibility: Descrip tion: Responsibility: Responsibility: Responsibility:
defines floor plan name/type manages floor plan positio ning scales f lo or plan for display scales f lo or plan for display incorporates w alls , doors and w indow s show s position of video cameras Wall Camera

Collaborator: Collaborator: Collaborator: Collaborator:

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. 2. Develop an overall model Produce class and sequence diagrams from chief architect meeting with domain experts and developers. 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.
4. 5.

Plan by feature -- the development staff plans the development sequence of features
Design by feature -- the team produces sequence diagrams for the selected features 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 Feature List

3.Plan By Feature

4.Design By Feature

5.Build By 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
Self Assessment of Modeling Team Members
Source: Palmer, SR., Felsing , JM.2002,p.135

Exit criteria

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..

CP assigned to business activities.

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 Sequence diagram(s).

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 Transform model(s) into executable code Ensure quality Verify that requirements are met

Implementation

Test

Disciplines
Deployment Make system available to end users Manage access to project artifacts Control and manage changes Managing risks, directing and coordinating people Configuration Management

Project management

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 +/- a week or two
But, a constant duration leads to a better rhythm

Target duration is one month

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 interferences

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

Spring Planning Meeting

Product Backlog Team Capabilities Sprint Goal

Sprint Planning
Business Conditions Technology Current Product

Meeting

Sprint Backlog

Parts of Sprint Planning Meeting

1st Part: Creating Product Backlog Determining the Sprint Goal. Participants: Product Owner, Scrum Master, Scrum Team Participants: Scrum Master, Scrum Team Creating Sprint Backlog

2nd Part:

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

 Team presents what it accomplished during the sprint

Sprint Review Meeting

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)