Agile Life Cycle

5/28/2018 Agile Life Cycle

1/41

This document is copyright (C) Stanford Computer Science and Marty Stepp, licensed under Creative Commons Attribution 2.5 License. All rights reserved.

CS 194, Lecture 2Software Lifecycle Models;

Requirements/Design;Agile Development


2/412

Today's lecture

Today we will: identify major "phases" of activity performed when making software

talk about some major components of two particular phases

requirements design

discuss several "models" for performing these phases

when to do each, for how long, etc.

discuss the Agile / Scrumsoftware dev methodology in detail


3/413

The "Software Lifecycle"

software lifecycle: The entire process of creating a softwareproduct from an initial concept until the last user stops using it.

often divided into conceptual phases:

RequirementsAnalysis & Specification

Design, High-level (Architectural) and Detailed (e.g. Object-oriented)

Implementation, Integration, Debugging

Testing, Profiling, Quality Assurance

Maintenance/ Operationother possibilities: Risk Assessment, Prototyping

goals of each phase:

mark out a clear set of steps to perform

produce a tangible document or item

allow for review of work

specify actions to perform in the next phase


4/41


Software Requirements


5/415

Software requirements

requirements: goals that the software needs to accomplish"what" and not "how"

the system design, not the software design

describes the problem, not the (detailed) solution

roles of requirements

customers: show what should be delivered; contractual base

managers: a scheduling / progress indicator

designers: provide a spec to designcoders: list a range of acceptable implementations / output

QA / testers: a basis for testing, validation, verification


6/416

"Digging" for requirements

How does one figure out the requirements for a project?

Do:

Talk to the users, or work with them, to learn how they work.

Ask questions throughout the process to "dig" for requirements.

Think about why users do something in your app, not just what.

Allow (and expect) requirements to change later.

Don't:

Describe complex business logic or rules of the system.Be too specific or detailed.

Describe the exact user interface used to implement a feature.

Try to think of everythingahead of time. (You will fail.)

Add unnecessary features not wanted by the customers.


7/417

Cockburn's template

Alistair Cockburn's suggested outline for functional requirements:1. purpose and scope2. terms / glossary3. use cases4. technology used5. other

a. development process:participants, values (fast, good, cheap?),visibility, competition, dependencies

b. business rules / constraintsc. performance demandsd. security (now a hot topic), documentatione. usabilityf. portabilityg. unresolved / deferred

6. human issues: legal, political, organizational, training

Cockburn says the central artifact of requirements is the use case.
http://alistair.cockburn.us/http://alistair.cockburn.us/


8/418

Use cases

use case: a written description of the user's interaction with thesoftware product to accomplish a goal

interactions between an actor and the system

3-9 clearly written steps lead to a "main success scenario"

written from actor's point of view, not the system's

benefits of doing use cases?

helps us discover and document functional requirements

agreement as to the system's responsibilities

provides executives a skeleton for planning project priorities

helps provide a list of error cases to test


9/419

Example use case

Use Case 12. Buy stocks over the web

Primary Actor: Purchaser (user) Level: user goal

Precondition: User already has Personal Advisors/Finance ("PAF") program open and is logged in.

Minimal Guarantee: sufficient log information exists that PAF can detect what went wrong.

Success Guarantees: remote web site acknowledged purchase, user's portfolio updated.

Main success scenario:1. User selects to buy stocks over the web.

2. PAF gets name of web site to use (E*Trade, Schwabb, etc.)

3. PAF opens web connection to the site, retaining control.

4. User browses and buys stock from the web site.

5. PAF intercepts responses from the web site, and updates the user's portfolio.

6. PAF shows the user the new portfolio standing.

Extensions:

2a. User wants a web site PAF does not support:

2a1. System gets new suggestion from user, with option to cancel use case.

3a. Web failure of any sort during setup:

3a1. System reports failure to purchaser with advice, backs up to previous step.3a2. Purchaser either backs out of use case or tries again.


10/4110

Prototyping

prototyping: Creating a scaled-down or incomplete version of asystem to demonstrate or test aspects of it.

aids UI design

help discover requirements

help discover test cases and provide a basis for testing

allows interaction with user and customer to ensure satisfaction

Methods of prototyping

UI builders (Visual Studio, etc.): drag/drop UI controls on screen

implementation by hand: write a "rough" version of your code

paper prototype: draw a rough version of your UI on paper


11/4111

Some prototyping methods

UI builders (Visual Studio, etc.)draw a GUI visually by dragging/dropping UI controls on screen

implementation by hand

writing a "rough" version of your code

paper prototyping: a paper version of a UI

Question: Why not just code up a working code prototype?

much faster to create than codecan change faster than code

more visual bandwidth (can see more at once)

more conducive to working in teams

can be done by non-technical people


12/4112

Paper prototypes

Paper prototype benefitsmuch faster to create and modify than code

more visual bandwidth (can see more at once)

more conducive to working in teams

can be done by non-technical people

making a paper prototype

get materials: paper, pencils/pens, tape,

scissors, highlighters, transparencies, ...

identify screens and transitions in UI

consider use cases, inputs and outputs to user

represent dynamic UI with layover cutouts

think about how to get from one screen to next


13/41


Software Design


14/41

14

Class design

class identification from project proposal / spec / requirements:nouns are potential classes, objects, fields

verbs are potential methods or responsibilities of a class

CRC cardexercises

write down classes' names on index cardsnext to each class, list the following:

responsibilities: problems to be solved; short verb phrases

collaborators: other classes that are sent messages by this class(asymmetric)

UML

class diagrams

sequence diagrams

...


15/41

15

UML

Unified Modeling Language (UML): A standard style of diagramsthat depict parts of an OO system.

programming languages are not abstract enough for OO design

UML is an open standard; lots of companies use it

many programmers either know UML or a "UML-like" variant

UML is ...

a descriptivelanguage: rigid formal syntax (like programming)

aprescriptivelanguage: shaped by usage and convention

UML has a rigid syntax, but some don't follow it religiously

it's okay to omit things from UML diagrams if they aren't needed by

team/supervisor/instructor


16/41

16

UML class diagrams

class diagram: Shows a system's classes, their data,behavior, and relationships to each other.

Class diagrams are great for:

discovering related data and attributes

getting a quick picture of the important entities in a system

seeing whether you have too few/many classes

seeing whether the relationships between objects are too complex, too

many in number, simple enough, etc.

spotting dependencies between classes/objects

Not so great for:

discovering algorithmic (not data-driven) behavior

finding the flow of steps for objects to solve a given problem

seeing app's overall control flow


17/41

17

Poker class diagram


18/41

18

Sequence diagrams

sequence diagram: an "interaction diagram" that models a singlescenario executing in the system

perhaps 2nd most used UML diagram (behind class diagram)

participant: object that acts in the diagram

message: communication between objects

(method calls)

the axes in a sequence diagram:

horizontal: which object/participant is acting

vertical: time (down = forward in time)


19/41

19

State diagrams

state diagram: Depicts data and behavior of a single objectthroughout its lifetime.

set of states (including initial start state)

transitions between states

diagram is from that object's perspective

similar to finite state machines

Works best with:

large, complex objects with a long lifespandomain ("model") objects

User account management


20/41


Software Lifecycle Models


21/41

21

Some lifecycle models

waterfall: standard phases (req., design, code, test) in order

staged delivery: build initial requirements/designs for severalreleases first, then code-and-test each in sequence

evolutionary prototyping: minimal spec/design, code up aprototype, then "evolve" the spec and code as needed

spiral: assess risks at each step; do most critical action first

agile development: iterative, adaptive, incremental improvementdone by self-organizing cross-functional teams


22/41

22

Waterfall

requirementsverify

retirement

operations

test

implementverify

design

req. change

waterfall: Do all requirements, then all design,

then all coding, then all testing, then release, ...

+ formal, standard; specific phases with clear goals

+ clear divisions between phasesassumes requirements will be clear and well-understood

requires a lot of planning up front (not always easy)

rigid, linear; not adaptable to change in the product

nothing to show until almost done ("we're 90% done, I swear!")


23/41

23

Staged delivery

staged deliverywaterfall-like beginnings

(requirements and design),

then build/test in short stages

pros/cons:

+ produces steady signs of progress, builds customer confidence

+ customer involvement ("What do you think of this version?")

difficult to do when requirements are not known well at beginning

still requires a lot of up-front requirements / design work


24/41

24

Evolutionary prototyping

evolutionary prototyping:minimize requirements/design phases

quickly build a working minimal prototype

show it to customer/users, get feedback

refine prototype, repeat

pros/cons:

+ useful when requirements are not well known or change rapidly

unclear how much iteration/time will be needed to finishtemporary fixes/hacks become permanent

no real "spec" exists most of the time

difficult to integrate separate pieces


25/41

25

steps taken at each loop:determine objectives, constraints

identify risks

evaluate options to resolve risks

develop and verify deliverables

pros/cons:

+ provides early indication of unforeseen problems

+ always addresses the biggest risk first

+ accommodates changes, growth

+ eliminates errors and unattractive choices early

relies on developers to have risk-assessment expertise

over-focuses on "putting out fires"; other features may go ignored

works poorly when bound to an inflexible contract

SpiralBarry Boehm, USC


26/41


Agile Development and Scrum


27/41

27

Agile development

agile software development: An adaptive, iterative process whereteams self-organize and build features dynamically.

Extreme Programming

Scrum

values:

Individuals and interactions

over processes and tools

Working software

over documentationCustomer collaboration

over contract negotiation

Responding to change

over following a plan


28/41

28

Agile Manifesto

The 12-point Agile Manifesto: customer satisfaction by rapid deliveryof useful software

welcome changing requirements, even late in development

working software is delivered frequently(weeks rather than months)

working softwareis the principal measure of progress

sustainable development, able to maintain a constant pace close, daily co-operationbetween business people and developers

face-to-faceconversation is the best form of communication

projects are built around motivated individuals, who are trusted

continuous attention to technical excellenceand good design

simplicity self-organizingteams

regular adaptationto changing circumstance

Works well when used with small teams of expertswho can handle

a bit of uncertainty, chaos, change


29/41

29

Scrum

Scrum (in rugby): Restarting the game after an infraction. Scrum (in software): "A flexible, holistic product development

strategy where a development team works as a unit to reach a

common goal."

a reaction to, and rejection of, waterfall-like models

focuses on simple, lightweight practices

iterative and adaptive


30/41

30

Scrum at a Glance

30 days

24 hours

Product Backlog

As prioritized by Product Owner

Sprint Backlog

Backlog tasks

expanded

by team

Potentially Shippable

Product Increment

Daily Scrum

Meeting

Source: Adapted fromAgile Software

Development with Scrum by Ken Schwaber and

Mike Beedle.


31/41

31

User stories

Instead of Use Cases, Agile projects do "user stories".Who (user role) Is this a customer, employee, admin, etc.?

What(goal) What functionality must be achieved/developed?

Why(reason) Why does user want to accomplish this goal?

As a [user role], I want to [goal], so I can [reason].

Example:

"As a document editor, I want my in-progress document to auto-save

every few minutes, so I will not lose my work."

(Basically, user stories are small features and TODOs, but importantly,

each one includes whowants the feature and why.)


32/41

32

Product backlog

backlog: Master set of all user stories to be implemented.Can be written down in a simple way

(Google Doc, Excel file) or using

special Agile dev software

Each user story has a status, such as:

approved, ready to code, developing, ready for test, completed

A story can have a rank or priority indicating its urgency.

story points: Rating of effort/time needed to implement the story

common scales: 1-10, shirt sizes (XS, S, M, L, XL), hours, etc.

If a single story would take several days: break it up into several!


33/41

33

Sprint

sprint: The basic unit of development in Scrum.A fixed-time work period of roughly 3-30 days in length.

A sprint planning meetingdecides which user stories to implement.

The sprint gets its own sprint backloglisting those stories.

Come up with a specific goalfor the sprint.

a sprint

sprint backlog


34/41

34

Scrum roles

Product Owner Possibly a Product Manager or Project Sponsor

Decides features, release date, prioritization, $$$

Scrum Master

Typically a Project Manager or Team Leader

Responsible for enacting Scrum values and practices

Remove impediments / politics, keeps everyone productive

Project Team

5-10 members; Teams are self-organizing

Cross-functional: QA, Programmers, UI Designers, etc.

Membership should change only between sprints


35/41

35

Sprint planning mtg

Sprint planning meeting

Sprint prioritization

Analyze/evaluate product backlog

Select sprint goal

Sprint planning

Decide how to achieve sprint goal

(design) Create sprint backlog (tasks) from

product backlog items (user stories /

features)

Estimate sprint backlog workload in

hours / story points

Sprint

goal

Sprintbacklog

Business

conditions

Teamcapacity

Product

backlog

Technology

Currentproduct


36/41

36

Daily scrum meeting

daily scrum meeting: A short progress meeting every work day.One of the core, most liked parts of Scrum.

~15 minutes long, Stand-up

Anyone late pays a $1 fee

Not for problem solving

Only team members, Scrum Master, product owner, can talk

Whole world is invited

Helps avoid other unnecessary meetings

Three questionsanswered by each team member:

1. What did you do yesterday?

2. What will you do today?

3. What obstacles are in your way?


37/41

37

Sprint burndown chart

burndown chart: A display of what work has been completedin this sprint, and what is left to complete.

The idea: Hope to see graph drop gradually toward 0 during the sprint,

indicating completion of all chosen user stories.

updated every day (best guess about hours/points completed),

if a user story reaches "completed" or "ready for test" status

velocity: Effort that the team is

capable of during a sprint.

variation:Release burndown chartshows overall progress

updated at end of each sprint


38/41

38

Burndown charts

Hours

Sprint 1 Burndown

40

41

42

43

44

45

46

47

48

49

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Days in Sprint

Hoursremaining


39/41

39

Sprint review

sprint review: A meeting at the end of a sprint where the teampresents what it accomplished during the sprint.

Typically takes the form of a demo of new features or architecture.

Informal

2-hour prep time rule

No slides

Whole team participates

Good for team awareness

and motivation


40/41

40

Scaling up Scrum

Typical individual team is 7 2 people

Scalability comes from teams of teams

Factors in scaling

Type of applicationTeam size

Team dispersion

Project duration

Scrum has been used on multiple 500+ person projects


41/41

Sequential vs. Overlap

Rather than doing all of

one thing at a time......Scrum teams do a little

of everything all the time

Requirements Design Code Test

Documents

Agile Life Cycle