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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
4/41
This document is copyright (C) Stanford Computer Science and Marty Stepp, licensed under Creative Commons Attribution 2.5 License. All rights reserved.
Software Requirements
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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.
5/28/2018 Agile Life Cycle
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/5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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.
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
13/41
This document is copyright (C) Stanford Computer Science and Marty Stepp, licensed under Creative Commons Attribution 2.5 License. All rights reserved.
Software Design
5/28/2018 Agile Life Cycle
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
...
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
17/41
17
Poker class diagram
5/28/2018 Agile Life Cycle
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)
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
20/41
This document is copyright (C) Stanford Computer Science and Marty Stepp, licensed under Creative Commons Attribution 2.5 License. All rights reserved.
Software Lifecycle Models
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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!")
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
26/41
This document is copyright (C) Stanford Computer Science and Marty Stepp, licensed under Creative Commons Attribution 2.5 License. All rights reserved.
Agile Development and Scrum
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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.
5/28/2018 Agile Life Cycle
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.)
5/28/2018 Agile Life Cycle
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!
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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?
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
5/28/2018 Agile Life Cycle
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
Top Related