CS 194, Lecture 2 Software Lifecycle Models; Requirements/Design; Agile Development

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

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 / Scrum software dev methodology in detail

The "Software Lifecycle"

software lifecycle: The entire process of creating a software product from an initial concept until the last user stops using it.
often divided into conceptual phases:
Requirements Analysis & Specification Design, High-level (Architectural) and Detailed (e.g. Object-oriented) Implementation, Integration, Debugging Testing, Profiling, Quality Assurance Maintenance / Operation
other 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
3

Software Requirements

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

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 design coders: list a range of acceptable implementations / output QA / testers: a basis for testing, validation, verification

"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 everything ahead of time. (You will fail.) Add unnecessary features not wanted by the customers.

Cockburn's template
Alistair Cockburn's suggested outline for functional requirements: 1. 2. 3. 4. 5. purpose and scope terms / glossary use cases technology used other a. development process: participants, values (fast, good, cheap?), visibility, competition, dependencies b. business rules / constraints c. performance demands d. security (now a hot topic), documentation e. usability f. portability g. unresolved / deferred 6. human issues: legal, political, organizational, training Cockburn says the central artifact of requirements is the use case.
7

Use cases
use case: a written description of the user's interaction with the software 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

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.

Prototyping
prototyping: Creating a scaled-down or incomplete version of a system 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

10

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 code can 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

11

Paper prototypes
Paper prototype benefits
much 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

12

Software Design

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

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 card exercises

write down classes' names on index cards next 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 ...

14

UML
Unified Modeling Language (UML): A standard style of diagrams that 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 descriptive language: rigid formal syntax (like programming) a prescriptive language: 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
15

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
16

Poker class diagram

17

Sequence diagrams
sequence diagram: an "interaction diagram" that models a single scenario 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)

18

State diagrams
state diagram: Depicts data and behavior of a single object throughout 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 lifespan domain ("model") objects
User account management

19

Software Lifecycle Models

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

Some lifecycle models

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

staged delivery: build initial requirements/designs for several releases first, then code-and-test each in sequence
evolutionary prototyping: minimal spec/design, code up a prototype, then "evolve" the spec and code as needed spiral: assess risks at each step; do most critical action first

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

21

Waterfall
requirements verify req. change

design
verify implement test

waterfall: Do all requirements, then all design, then all coding, then all testing, then release, ...
+ +

operations

retirement

formal, standard; specific phases with clear goals clear divisions between phases assumes 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!")

22

Staged delivery
staged delivery
waterfall-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

23

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 finish temporary fixes/hacks become permanent no real "spec" exists most of the time difficult to integrate separate pieces
24

Spiral
Barry Boehm, USC

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

25

Agile Development and Scrum

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

Agile development
agile software development: An adaptive, iterative process where teams self-organize and build features dynamically.
Extreme Programming Scrum

values:
Individuals and interactions over processes and tools Working software over documentation Customer collaboration over contract negotiation Responding to change over following a plan
27

Agile Manifesto
The 12-point Agile Manifesto:
customer satisfaction by rapid delivery of useful software welcome changing requirements, even late in development working software is delivered frequently (weeks rather than months) working software is the principal measure of progress sustainable development, able to maintain a constant pace close, daily co-operation between business people and developers face-to-face conversation is the best form of communication projects are built around motivated individuals, who are trusted continuous attention to technical excellence and good design simplicity self-organizing teams regular adaptation to changing circumstance

Works well when used with small teams of experts who can handle a bit of uncertainty, chaos, change 28

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

29

Scrum at a Glance
24 hours Daily Scrum Meeting

Sprint Backlog

Backlog tasks expanded by team

30 days

Product Backlog As prioritized by Product Owner

Potentially Shippable Product Increment

Source: Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

30

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 who wants the feature and why.)
31

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!
32

Sprint
sprint: The basic unit of development in Scrum.
A fixed-time work period of roughly 3-30 days in length. A sprint planning meeting decides which user stories to implement. The sprint gets its own sprint backlog listing those stories. Come up with a specific goal for the sprint.
a sprint

sprint backlog
33

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
34

Sprint planning mtg

Team capacity

Sprint planning meeting

Sprint prioritization

Product backlog

Analyze/evaluate product backlog Select sprint goal

Sprint goal

Business conditions

Sprint planning

Current product

Technology

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 backlog

35

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 questions answered by each team member:
1. What did you do yesterday? 2. What will you do today? 3. What obstacles are in your way?
36

Sprint burndown chart

burndown chart: A display of what work has been completed in 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 chart

shows overall progress updated at end of each sprint
37

Burndown charts
Hours

Sprint 1 Burndown
49

48

47

46

Hours remaining

45

44

43

42

41

40 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

38

Sprint review
sprint review: A meeting at the end of a sprint where the team presents 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

39

Scaling up Scrum
Typical individual team is 7 2 people
Scalability comes from teams of teams

Factors in scaling
Type of application Team size Team dispersion Project duration

Scrum has been used on multiple 500+ person projects

40

Sequential vs. Overlap

Requirements Design Code Test

Rather than doing all of one thing at a time... ...Scrum teams do a little of everything all the time

41