06 Sofa Bddintro

SOFA
BDD
2013 Armando Fox & David Patterson, all rights reserved
Outline
9.5 Identifying Whats Wrong: Smells, Metrics,
SOFA
9.4 Comments
7.1 Intro to BDD & User Stories
7.2 Points, Velocity, and Pivotal Tracker
7.3 SMART User Stories
7.4 Lo-Fi User Interface Sketches and Storyboards
7.5 Agile Cost Estimation
7.10 Plan-and-Document Perspective
2
END
3
Identifying Whats Wrong:

Smells, Metrics, SOFA
(ESaaS 9.5)
http://pastebin.com/gtQ7QcHu
2012 Armando Fox & David Patterson

Licensed under
Creative Commons Attribution-NonCommercial-ShareAli
ke 3.0 Unported License
Beyond Correctness
Can we give feedback on software beauty?
Guidelines on what is beautiful?
Qualitative evaluations?
Quantitative evaluations?
If so, how well do they work?
And does Rails have
tools to support them?
Qualitative: Code Smells

SOFA captures symptoms that often indicate
code smells:
Is it Short?
Does it do One thing?
Does it have Few arguments?
Is it a consistent level of Abstraction?
Rails tool reek finds code smells
Single Level of Abstraction

Complex tasks need divide & conquer
Yellow flag for encapsulate this task in a
method
Like a good news story, classes & methods
should read top down!
Good: start with a high level summary of key
points, then go into each point in detail
Good: Each paragraph deals with 1 topic
Bad: ramble on, jumping between levels of
abstraction rather than progressively refining
Why Lots of Arguments is Bad

Hard to get good testing coverage
Hard to mock/stub while testing
Boolean arguments should be a yellow flag
If function behaves differently based on Boolean

argument value, maybe should be 2 functions
If arguments travel in a pack, maybe you

need to extract a new class
Same set of arguments for a lot of methods
Program X & Smells

class TimeSetter
time_setterTimeSetter#self.convert calls
def self.convert(d)
(y + 1) twice (Duplication)
y = 1980
.rb -- 5 warnings
while (d > 365) do
if (y % 400 == 0 ||
1. TimeSetter#self.convert calls
(y % 4 == 0 && y % 100 != 0)) (y + 1) twice (Duplication)
if (d > 366)
2. TimeSetter#self.convert has approx 6
d -= 366
statements (LongMethod)
y += 1
3. TimeSetter#self.convert has the parameter
end
name 'd' (UncommunicativeName)
else
d -= 365
4. TimeSetter#self.convert has the variable
y += 1
name 'd' (UncommunicativeName)
end
5. TimeSetter#self.convert has the variable
end
name 'y (UncommunicativeName)
return y
end
end
9
Quantitative: ABC Complexity
Counts Assignments, Branches, Conditions

Complexity Score = (A2 + B2 + C2)
NIST (Natl. Inst. Stds. & Tech.): 20/method
Rails tool flog checks ABC complexity
10
Quantitative: Cyclomatic Complexity

# of linearly-independent paths thru code =
EN+2P (edges, nodes, connected components)
def m ym eth
w hile(...)
....
Rails tool saikuro
end
calculates cyclomatic
if (...)
complexity (CC)
do_som ething
end
end
Here, E=9, N=8, P=1, so CC=3
NIST: 10/module
11
Quantitative: Metrics
Metric
Tool
Target score
Code-to-test ratio
rake stats
1:2
C0 (statement) coverage
SimpleCov
90%+
ABC score
flog
< 20/method (NIST)
CC score
saikuro
< 10/method (NIST)
Hotspots: places where multiple metrics raise red

flags
add require 'm etric_fu'to Rakefile
rakemetrics:all
Take metrics with a grain of salt
Like coverage, better for identifying where improvement

is needed than for signing of
12
Leap Year & Metrics

class TimeSetter
def self.convert(d)
y = 1980
while (d > 365) do
if (y % 400 == 0 ||
(y % 4 == 0 && y % 100 != 0))
if (d > 366)
d -= 366
y += 1
end
else
d -= 365
y += 1
end
end
return y
end
end
13
Revised Leap Year & Metrics

class TimeSetter
def self.convert(day)
year = 1980
while (day > 365) do
if leap_year?(year)
if (day >= 366)
day -= 366
end
else
day -= 365
end
year += 1
end
return year
end
private
14
END
15
Which SOFA guideline is most

important for unit-level testing?
1. Short
2. Do
One thing
3. Have
Few arguments
4. Stick
to one level of Abstraction

16
END
17
Good Comments
Comments Should Describe Things

That Arent Obvious From The Code:
Why, not What
(9.4 ESaaS)
(from officemate John Ousterhout)
Bad Comments
// Add one to i.
i++;
// Lock to protect against concurrent access.

SpinLock mutex;
// This function swaps the panels.

void swap_panels(Panel* p1, Panel* p2) {...}
Comments, contd
Comments should be at a higher abstract level than code:
# Scan the array to see if the symbol exists
not
#
#
#
#
#
Loop through every array index, get the

third value of the list in the content to
determine if it has the symbol we are looking
for. Set the result to the symbol if we
find it.
END
21
Introduction to
Behavior-Driven
Design and
User Stories
(Engineering Software
as a Service 7.1)
2013 David Patterson & David Patterson

Licensed under
22
Why Do SW Projects Fail?
Dont do what customers want

Or projects are late
Or over budget
Or hard to maintain and evolve
Or all of the above
How does Agile try to avoid failure?
23
Agile Lifecycle Review

Work closely, continuously with stakeholders
to develop requirements, tests
Users, customers, developers, maintenance
programmers, operators, project managers,
Maintain working prototype while deploying

new features every iteration
Typically every 1 or 2 weeks
Instead of 5 major phases, each months long
Check with stakeholders on whats next,

to validate building right thing (vs. verify)
24
Agile Iteration
25
Behavior-Driven Design (BDD)

BDD asks questions about behavior of app
before and during development to reduce
miscommunication
Validation vs. Verification
Requirements written down as user stories

Lightweight descriptions of how app used
BDD concentrates on behavior of app vs.

implementation of app
Test Driven Design or TDD (future segments)

tests implementation
26
User Stories
1-3 sentences in everyday language
Fits on 3 x 5 index card
Written by/with customer
Connextra format:
Feature name
As a [kind of stakeholder],
So that [I can achieve some goal],
I want to [do some task]
3 phrases must be there, can be in any order
Idea: user story can be formulated as acceptance

test before code is written
27
Why 3x5 Cards?

(from User Interface community)
Nonthreatening => all stakeholders
participate in brainstorming
Easy to rearrange => all stakeholders
participate in prioritization
Since stories must be short, easy to change
during development
Often get new insights during development
28
Different Stakeholders May

Describe Behavior Differently
See which of my friends are going to a show
As a theatergoer
So that I can enjoy the show with my friends
I want to see which of my Facebook friends are
attending a given show
Show patrons Facebook friends
As a box office manager

So that I can induce a patron to buy a ticket
I want to show her which of her Facebook friends
are going to a given show
29
Product Backlog
Real systems have 100s of user stories
Backlog: User Stories not yet completed
(Well see Backlog again with Pivotal Tracker)
Prioritize so most valuable items highest

Organize so they match SW releases over
time
30
Related Issue
Spike
Short investigation into technique or

problem
E.g. spike on recommendation algorithms
After spike done, code must be thrown

away
Now know approach you want, write it

correctly
Not all code branches merge into production
31
END
32
Which expression statement regarding BDD

and user stories is FALSE?
1. BDD
is designed to help with validation (build

the right thing) in addition to verification
2. BDD
should test app implementation
3. User
stories in BDD play same role as design

requirements in Plan-and-Document
4. This is a valid User Story: Search TMDb
I want to search TMDb
As a movie fan
So that I can more easily find info
33
END
34
Points, Velocity, and

Pivotal Tracker
(Engineering Software as a Service 7.2)

Licensed under
35
Productivity and Tools

Dont we want to avoid major planning effort
in Agile? If so, how to estimate time without
a plan?
Can User Stories be used to measure
progress on project?
What should a tool do to help measure
progress for Agile?
36
Measuring Productivity
A measure of team productivity:
calculate avg. no. stories / week?
But some stories much harder than others
Rate each user story in advance on a simple

integer scale
1 for straightforward, 2 for medium, 3 for very
complex
Velocity: avg. number of points / week

37
More on Points
Once get experience, Fibonnaci scale is
commonly used: 1, 2, 3, 5, 8
(Each new number is sum of previous 2)
At Pivotal Labs, 8 is extremely rare
Teams assign value: vote by holding up

fingers simultaneously, take average
If a big disagreement (2 and 5), discuss more
38
More on Points
5 => divide user story into
simpler stories
backlog not too demanding
Doesnt matter if velocity is

5 or 10 points per iteration
As long as team is consistent
Idea is to improve self-evaluation

and suggest number of iterations
for feature set
39
Pivotal Tracker
Calculates velocity for team, manages user
stories: Current, Backlog, Icebox
40
Pivotal Tracker
Prioritize user stories by where place them
in Current, Backlog, Icebox panels
When completed, move to Done panel
Can add logical Release points, so can
figure out when a Release will really happen
Remaining points/Velocity
Epic (with own panel)
Combine related user stories together

Ordered independent of user story in Backlog
41
Tracker Roles
Developers dont decide when user stories
completed
Pushes Finish button, which sends to Product

Owner (as in Scrum team organization)
Product Owner tries out the user story and

then either hits
Accept, which marks user story as done, or
Reject, which marks story as needing to be
Restarted by developer
42
Pivotal Tracker:
Features vs. Chores
Features
User stories that provide verifiable business

value to customer
Add agree box to checkout page
Worth points & therefore must be estimated
Chores
User Stories that are necessary, but provide no

direct, obvious value to customer
Find out why test suite is so slow
No points
43
Team Cyberspace Whiteboard

Tracker allows attaching documents to User
stories (e.g., LoFi UI)
Wiki with Github repository
Google Documents: joint creation and
viewing of drawings, presentations,
spreadsheets, and text documents
Campfire: web-based service for passwordprotected online chat rooms
44
END
45
Which expression statement regarding

Points, Velocity, and Tracker is TRUE?
1. When
comparing two teams, the one with the

higher velocity is more productive
2. When
you dont know how to approach a given

user story, just give it 3 points
3. With
Tracker, developers pick the user stories

and mark as Accepted when done
4. Tracker
helps prioritize and keep track of user

stories and their status, calculates velocity, and
predicts software development time
46
END
47
SMART User
Stories
(Engineering Software
as a Service 7.3)

Licensed under
48
Creating User Stories

How do you know if you have a good user
story vs. bad user story?
Right size?
Not too hard?
Is worthwhile?
49
SMART Stories
Specific
Measurable
Achievable
(ideally, implement in
1 iteration)
Relevant
(the 5 whys)
Timeboxed
(know when to give up)
50
Specific & Measurable

Each scenario testable
Implies known good input

and expected results exist
Anti-example:
UI should be user-friendly
Example: Given/When/Then
1.Given some specific starting condition(s),

2.When I do X,
3.Then one or more specific thing(s) should
happen
51
Achievable
Complete in 1 iteration
If cant deliver feature in
1 iteration, deliver
subset of stories
Always aim for working
code @ end of iteration
If <1 story per iteration,

need to improve point
estimation per story
52
Relevant: Business Value

Discover business value, or kill the story:
Protect revenue
Increase revenue
Manage cost
Increase brand value
Making the product remarkable
Providing more value to your customers
53
5 Whys to Find Relevance

Show patrons Facebook friends
As a box office manager
So that I can induce a patron to
buy a ticket
I want to show her which Facebook
friends are going to a given show
1.Why?
2.Why?
3.Why?
4.Why?
5.Why?
54
Timeboxed
Stop story when exceed time
budget
Give up or divide into smaller

stories or reschedule what is left
undone
To avoid underestimating
length of project
Pivotal Tracker tracks velocity,
helps avoid underestimate
55
END
56
Which feature below is LEAST SMART?
1. User
can search for a movie by title
2. Rotten
Potatoes should have good response
time
3. When
adding a movie, 99% of Add Movie pages

should appear within 3 seconds
4. As
a customer, I want to see the top 10 movies

sold, listed by price, so that I can buy the
cheapest ones first
57
END
58
Lo-Fi UI Sketches and

Storyboards

Licensed under
59
Building Successful UI
SaaS app often faces users
User stories need User Interface (UI)
How to get customer to participate in UI
design so is happy when complete?
Avoid WISBNWIW* UI
UI version of 3x5 cards?
How to show UI interactivity without building a
prototype?
*
What-I-Said-But-Not-What-I-Want
60
SaaS User Interface Design

UI Sketches: pen and paper
drawings or Lo-Fi UI
61
Lo-Fi UI Example
(Figure 7.3, Engineering Long Lasting

Software by Armando Fox and David
Patterson, 1st edition, 2014.)
62
Storyboards
Need to show how
UI changes based on
user actions
HCI => storyboards
Like scenes in a movie
But not linear
63
Example Storyboard
(Figure 7.4, Engineering Long Lasting

Software by Armando Fox and David
Patterson, 1st edition, 2014.)
64
Lo-Fi to HTML
Tedious to do sketches and storyboards,
but easier than producing HTML!
Also less intimidating to nontechnical
stakeholders => More likely to suggest
changes to UI if not code behind it
More likely to be happy with ultimate UI
Next steps: CSS (Cascading Style Sheets)

and Haml (later)
Make it pretty after it works
65
END
66
Which is FALSE about Lo-Fi UI?
Like 3x5 cards, sketches and storyboards are

more likely to involve all stakeholders vs. code
The purpose of the Lo-Fi UI approach is to

debug the UI before you program it
SaaS apps usually have user interfaces
associated with the user stories
While it takes more time than building a
prototype UI in CSS and Haml, the Lo-Fi
approach is more likely to lead to a UI that
customers like
67
END
68
Agile Cost Estimation

Licensed under
69
Agile Cost Estimation

Real world needs to estimate cost before
customer can agree to project
If no careful planning and schedule in Agile,
how can you estimate the cost of a project?
70
Pivotal Labs Model

Pivotal Labs teaches customer Agile
Using Agile, Pivotal never commits to
delivering features X, Y, and Z by date D
Instead, commits resources to work in the
most efficient way possible up to date D
Customer works with team to define priorities

continuously up to date D
Still need estimate for project
71
Pivotal Labs Agile Estimate

1. 1 hour phone call to explain method
Joint effort, customer time commitment,
2. Customer visits for 1.5 hour scoping
Customer brings designer, developer, designs
Anything to clarify what customer wants done
Pivotal brings 2 engineers who ask questions
Trying to identify what adds uncertainty to estimate
3. Engineers take hour to estimate weeks
Little vs. large uncertainty: 20-22 vs. 18-26 wks
4. Bid cost as time and materials to customer

72
END
73
Which expression statement regarding cost

estimation is TRUE?
(PL = Pivotal Labs)
1. As
practitioners of Agile Development, PL does

not use contracts
2. As
practitioners of pair programming, PL estimates

cost for 1 pair, which it assigns to complete project
3. The
cost bid is for PL time and materials that

covers number of weeks in the estimate
4. As
studies show 84%-90% projects are on-time

and on-budget, plan-and-document managers
promise customers a set of features for an
agreed upon cost by an agreed upon date74
END
75
Plan-And-Document Perspective
Licensed under
76
Introduction
What does Plan-and-Document
do instead of:
User stories?
Points?
Velocity?
How does a project manager

estimate costs? Make a schedule?
77
P&D Equivalents+
1.
2.
3.
4.
5.
Requirements Elicitation
Requirements Documentation
Cost Estimation
Scheduling & Monitoring Progress
Change Management for
Requirements, Cost, &Schedule
6. Ensuring Implementation Matches
Requirement Features
7. Risk Analysis & Management
78
P&D Requirements Elicitation

Elicit functional&non-functional requirements:
1.Interviewing - see how currently really done
Stakeholders answer predefined questions
Or just have informal discussions
2.Cooperatively create Scenarios
Initial state, show flow for happy & sad paths,

what is concurrent, final state
3.Create Use Cases
List of steps to achieve goal between user and

system; has language (UML) to describe
79
P&D Requirements Documentation

Document requirements via Software
Requirements Specification (SRS)
100s of pages; IEEE 830-1998 std for SRS!
Have stakeholders read SRS, or build basic

prototype, or generate test cases to check:
Validity: are all requirements necessary?
Consistency: do requirements conflict?
Completeness: are all requirements and
constraints included?
Feasibility: can requirements be implemented?
80
P&D Cost Estimation

Manager decomposes SRS into tasks
Estimates weeks per task
1 week Tasks 8 weeks
Covert person-weeks into $

via salaries and overhead
Estimate before & after contract
Add safety margin: 1.3 to 1.5X

Make 3 estimates (best case, expected, worst)
then make best guess
81
P&D Cost Estimation

1. Experiential Estimate
Rely on managers experience to be accurate
2. Quantitative Estimate
Estimate tasks in lines of code (LOC),

divide by LOC/person-month
COCOMO (Constructive Cost Model):
Effort = OrgFactor CodeSizePenalty ProdFactor
Organization Factor = 2.94, 1.10SizePenalty1.24,

0.90 Product Factor 1.40
. 92% use experiential, not formula
82
P&D Scheduling
Use PERT chart to show task parallelism and
critical path to make schedule
Nodes are milestones, link names are tasks, link

numbers are effort, arrows are dependencies
83
P&D Monitoring Progress

Compare predicted to actual
Time for tasks
Expenditures
Intermediate milestone
help all stakeholders
see if project is
on schedule & on budget
84
P&D Requirements Checking

Manager uses tools for
requirements traceability
Tool has cross
references between
Portion of SRS with
requirement
Portion of code that
implements requirement
Tests that validate
requirement
85
P&D Risk Analysis & Management

To improve accuracy of budget/schedule
Identify risks early to
Do extra work to reduce risk
Change plan to avoid risk
Technical: RDB cant scale

Organizational: J2EE???
Business: too late for market
Create Risk Table: % chance x impact
Address top 20%, hoping 80% of risk
86
P&D vs. Agile Requirements and

Schedule/Cost Estimation
87
END
88
Which statement regarding P&D

requirements and cost estimation is
FALSE?
1. The
closest to the P&D schedule and monitoring

tasks are Agile points and velocity
2. The
closest to the P&D Software Requirements

Specification (SRS) document is Agile User Stories
3. Agile
has no equivalent to ensuring requirements,

such as traceability
4. P&D
requires risk analysis, while Agile does not
89
END
90
And in Conclusion:
9.4-9.5, 7.1-7.5, 7.10
SOFA methods: Short, do One thing,

Few arguments, consistent Abstraction
Metrics point to problem code
BDD: User stories to elicit requirements
SMART: Specific, Measureable, Achievable,

Relevant, Timeboxed
Points/Velocity to calculate progress (Tracker)

Lo-Fi UI/storyboard: sketch to elicit UI design
Lifecycles: Plan&Document (careful planning
& documentation) v. Agile (embrace change)
91

06 Sofa Bddintro

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

06 Sofa Bddintro

Caricato da

Copyright:

Formati disponibili

SOFA

2013 Armando Fox & David Patterson, all rights reserved

Identifying Whats Wrong:

2012 Armando Fox & David Patterson

Qualitative: Code Smells

Single Level of Abstraction

Why Lots of Arguments is Bad

If function behaves differently based on Boolean

If arguments travel in a pack, maybe you

Program X & Smells

Quantitative: ABC Complexity

Counts Assignments, Branches, Conditions

Quantitative: Cyclomatic Complexity

< 20/method (NIST)

< 10/method (NIST)

Hotspots: places where multiple metrics raise red

Take metrics with a grain of salt

Like coverage, better for identifying where improvement

Leap Year & Metrics

Revised Leap Year & Metrics

Which SOFA guideline is most

to one level of Abstraction

Comments Should Describe Things

// Lock to protect against concurrent access.

// This function swaps the panels.

Loop through every array index, get the

2013 David Patterson & David Patterson

Why Do SW Projects Fail?

Dont do what customers want

Agile Lifecycle Review

Maintain working prototype while deploying

Check with stakeholders on whats next,

Behavior-Driven Design (BDD)

Requirements written down as user stories

BDD concentrates on behavior of app vs.

Test Driven Design or TDD (future segments)

Idea: user story can be formulated as acceptance

Why 3x5 Cards?

Different Stakeholders May

Show patrons Facebook friends

As a box office manager

(Well see Backlog again with Pivotal Tracker)

Prioritize so most valuable items highest

Short investigation into technique or

E.g. spike on recommendation algorithms

After spike done, code must be thrown

Now know approach you want, write it

Which expression statement regarding BDD

is designed to help with validation (build

should test app implementation

stories in BDD play same role as design

Points, Velocity, and

(Engineering Software as a Service 7.2)

Productivity and Tools

But some stories much harder than others

Rate each user story in advance on a simple

Velocity: avg. number of points / week

Teams assign value: vote by holding up

If a big disagreement (2 and 5), discuss more

Doesnt matter if velocity is

As long as team is consistent

Idea is to improve self-evaluation

Epic (with own panel)

Combine related user stories together