methods of software development versioning

1Institute for Software Research, International

1

Methods of Software Development

Versioning

Chris Scaffidi

2

Institute for Software Research, International

2

Was the reading clear?

You can talk intelligently about the terms… “factor” and “actor” “production function” and “utility function” “quality attribute”, “metric”, and “validity” “qualitative” and “quantitative” “ATAM” and “COCOMO II” “process” and “CMM”

Questions?

3


3

Why version? Pricing is a challenge Differentiation is one key

How to version? Identify important attributes Design to optimize on those attributes Implement to achieve the design

Overview

4


4

What is this curve?

Pricing is a challenge

Why Version?

5


5

A demand curve is a utility curve between product and money.

Price versus quantity

Why Version? > Pricing is a challenge

Quantity

Pri

ce

6


6

Why does it start high and then slope down?

Price versus quantity


Quantity

Pri

ce

7


7

Value versus quantity


Only a few people find enough value (utility) in the product to justify paying higher prices.

But lots of people find enough value in the product to justify paying lower prices.

Quantity

Pri

ce

8


8

Maximizing profit


Challenge: Maximize your profit by picking the best price to charge.

Quantity

Pri

ce

Production Cost Per Unit

9


9

The challenge is complicated by competition.

You compete with other vendors. You compete with yourself!

One tractable solution is differentiation.

Versions can vary in functionality. Versions can vary in price.

Differentiation is one key

Why Version?

10


10

Scenario #1: One version

Why Version? > Differentiation is one key

•Make one version.•Pick a price.•That tells quantity sold.•Profit is shown in shaded box.

(Minus flat costs, of course.)

Quantity

Pri

ce


11


11

Scenario #2: Two versions


•Make two versions: Different price & functionality.

•This entices a few more buyers.•You get a little extra profit.

Danger: Self-Competition

Quantity

Pri

ce


12


12

Scenario #2: Two versions


This is what happens when you compete with yourself too much.

Danger: Self-Competition

Quantity

Pri

ce


13


13

Scenario #3: Several versions


If two is good, more is better?

Quantity

Pri

ce


14


14

Scenario #4: Infinitely many versions


Quantity

Pri

ce


“1st Degree Price Discrimination”

Perfectly personalized productsPerfectly matches the curveMaximizes the profit?

What’s wrong with this picture?

15


15

“1st degree price discrimination”= Personalized pricing

Fits the demand curve closely May raise production costs a lot May be impossible with some products

“2nd degree price discrimination”= Versioning (or volume discounts)

Approximates the demand curve May raise production costs

1st vs 2nd degree price discrimination


16


16

“3rd degree price discrimination”= Group pricing

Targets each version at a group of buyers Can simplify design and marketing process Can boost network effects (value) Most useful when buyers fall into clean

categories

Price discrimination means matching good prices to your product’s differentiated versions.

3rd degree price discrimination


17


17

Why version? Pricing is a challenge Differentiation is one key

How to version? Identify important attributes Design to optimize on those attributes Implement to achieve the design

How to Version?

How to Version?

You are here

18


18

Versions are differentiated (i.e.: their attributes vary).

You want your versions to have varied utility (why?)

The key: know thy customers’ utility function

If you know how utility depends on attributes, then you know which attributes should vary by version.

Utility curves differ

How to Version? > Identify important attributes

19


19

Example: Utility of availability


Utility in e-Commerce as a function of availability

B. Boehm, et al. “The ROI of Software Dependability: The iDAVE Model”, IEEE Software, May/June 2004.

20


20

Example: Utility of timeliness


Timeliness

Uti

lity

Timeliness

Uti

lity

Timeliness

Uti

lity

NASA Mission Control Software

B. Boehm. HDCP Review Talk at CMU. Oct 15, 2004.

Real-Time Control

Weather Prediction

Uti

lity

Timeliness

21


21

Utility can be a function of many attributes… Functional attributes

Formats supported Precision supported Searches supported Calculations supported Views / interfaces provided Image resolution

The wide-wide world of attributes


22


22

Utility can be a function of many attributes… Functional attributes Extra-functional attributes

Timeliness to market Timeliness of the software’s outputs (≈

performance) Availability of technical support Availability of the software itself Maintainability Flexibility & extensibility Platforms supported & portability



23


23

Utility can be a function of many attributes… Functional attributes Extra-functional attributes

… and also a function of whether that irritating “Please Register this Software”box keeps popping up in demoware versions!



24


24

Example: Suppose we’re designing an e-Commerce platform.

Our target market is online booksellers.

How should versions vary by availability? What other attributes will probably affect

utility?

Example: e-Commerce platform

How to Version?

25


25

Once you know which attributes to vary, the next step is knowing how much you want in versions.

This is a Qualitative-to-Quantitative thought process.

There are many approaches to making this transition.

Examples: ATAM COCOMO II Cobb-Douglas

Design to optimize on those attributes

How to Version?

26


26

ATAM utility tree

How to Version? > Design to optimize on those attributes

Build a utility tree

1. Identify attributes2. Operationalize3. Assign priorities4. Design

Repeat until everybody is adequatelyjoyful.

27


27

PM = M * Size S

PM = person-months to build (≈ flat building cost)Size = software size in KSLOC

S = 0.91 + 0.01 * Σ si

si = scale factor i, describes your company

COCOMO II


28


28

PM = M * Size S


S = 0.91 + 0.01 * Σ si


M = 2.94 * mi

mi = effort modifier i, describes your company and also attributes of the version

COCOMO II


29


29

PM = M * Size S


S = 0.91 + 0.01 * Σ si


M = 2.94 * mi

mi = effort modifier i, describes your company and also attributes of the version

COCOMO II


30


30

Production functions can be approximated as

Z = k * Yi

Z = amount of output generatedk = constantY = amount of input required

i = elasticity of input i (0.0 ≤ i ≤ 1.0)

Cobb-Douglas optimization


31


31

Production is a suitable approximation for utility.

You can maximize Z, subject to constraints.



32


32

Back to the book-ordering e-Commerce platform.We have a central web server plus a failover

cluster.

Some handy over-simplifications: Each search tool costs 64MB RAM + 1 cluster server Each “9” costs 10MB + 2 cluster servers (e.g.:

99.999%=5)

Total memory cannot exceed 2048MB RAM Our hosting facility provides 15 failover cluster

servers



33


33

Our buddies in marketing and operations tell us that

Z = $500 * T0.2 * A0.1

Z = sales produced per month, in dollarsT = number of search tools (elasticity = 0.2)A = availability, in “9”s (elasticity = 0.1)

Our constraints were64*T + 10*A ≤ 20481*T + 2*A ≤ 15



34


34

Take the logarithm of both sides.

Maximize (ln Z) = 0.2*(ln T) + 0.1*(ln A) + ln $500

Subject to64*T + 10*A ≤ 20481*T + 2*A ≤ 15

Look familiar?



35


35

Good job so far:1. You identified the important attributes.2. You figured out how much of each attribute

you should put into each version.

One step left:3. Implement to actually deliver the

desired quality attributes in the desired quantities.

Implement to achieve the design

How to Version?

36


36

Metrics For measuring operationalizations of attributes Can be used to evaluate designs or code Ask Ipek for long version of “Digest” for more

examples

Metrics and CMM

How to Version? > Implement to achieve the design

37


37

Metrics For measuring operationalizations of attributes Can be used to evaluate designs or code Ask Ipek for long version of “Digest” for more

examples

CMM Level 1: Chaotic and ad-hoc Level 2: Repeatable process Level 3: Documented process Level 4: Metrics in use Level 5: Optimization underway

Metrics and CMM


38


38

“In many cases, in fact, production of the low-quality version incurs additional costs.”

--

Value-subtracted versions


C. Shapiro, H. Varian. “Information Rules”, Harvard Business School Press, 1999, p. 63.

39


39

“In many cases, in fact, production of the low-quality version incurs additional costs.”

“With information you usually produce the high-quality version first, and then subtract value from it to get to the low-quality version.”

Value-subtracted versions


C. Shapiro, H. Varian. “Information Rules”, Harvard Business School Press, 1999, p. 63.

40


40

What else is there? Complements

You don’t have to build it all at once! Build a version here and another there. Build systems that complement some or all versions.

Partnerships You don’t have to build it all yourself! You may need to build to standards.

Do yourself a favor: Read “Information Rules”

Fill in the gaps


41


41

Why version? Pricing is a challenge

How will you optimize your profits? Differentiation is one key

Lessens competition and facilitates price discrimination

How to version? Identify important attributes

Know thy customers’ utility function Design to optimize on those attributes

ATAM, COCOMO II, Cobb-Douglas, and so forth Implement to achieve the design

Metrics, CMM, value-subtraction, and so forth

Summary

42


42

“You must design desirability into the product from the start… Desire is an emotional state, the anticipation of joy, a bittersweet gladness at the prospect of gratified need.

“Imagine and identify the few properties of the software that will gratify the need… Visualize the properties, desire them for yourself… Meditate on the nature of the properties you’ve identified, and evaluate the versions of your design in their light.”

Questions?

J. McCarthy. “Dynamics of Software Development”, Microsoft Press, 1995, p 70.

methods of software development versioning

Documents