cpsc 871 john d. mcgregor m11s2 value-driven software engineering – part 2

37
CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Upload: giles-greer

Post on 01-Jan-2016

219 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

CPSC 871

John D. McGregorM11S2

Value-driven Software Engineering – part 2

Page 2: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

What is SIMPLE? Why do we need it? - 1

Launching a software product line– Software product lines are touted for their economic advantages. To date,

most economic evidence has been • anecdotal or intuitive• based on simplistic cost models• single data points (from case studies)

– Software product lines are not always the best approach for an organization. There may be substantial overhead. The payoff might not materialize.

– How can an organizational decision-maker decide the best course for the organization to take?

– We have seen organizations reluctant to take the plunge because of the economic unknowns.

Page 3: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

What is SIMPLE? Why do we need it? - 2

Running a software product line– After a product line has been launched, decision-makers are faced with critical

decision points throughout its life.• Shall we add a new product to the family?• Shall we change the architecture?• Shall we split the product line into two or more smaller product lines?• Shall we merge two or more product lines?• Would a different organizational structure be more cost-effective?

Page 4: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Answering the need: SIMPLEStructure Intuitive Model for Product Line Economics

– Created in 2002 by researchers from academia and industry

Objectives– It must model real situations completely and correctly so that it can give high-fidelity

answers to the real problems of organizations. – It must be sufficiently intuitive for product line personnel to easily produce answers

whose derivation can be shown to and understood by others. – It should be understandable by managers and technicians alike. – It should be sufficiently flexible to be useful in answering a wide range of questions.

Since its inception, SIMPLE has been used to– Help organizations make strategic product decisions– Teach about software product line decision points and economics– Calculate the ROI of a software product line investment

Page 5: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Basic Costs

The cost of building a product as a stand-alone product can be represented by Equation A above.

Cprod is a cost function. Given actual parameters, the function returns the portion of the cost of building producti during the time interval t.

This expression is used to evaluate the approach in which the organization hires sufficient staff to build n standalone products. The value returned by Cprod includes all costs associated with that staff and other related costs (including severance costs for when the project is completed).

),(1

tproductCn

iiprod

Page 6: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Cost Benefit Analysis – Cost Functions

Four basic cost functions support the modeling of most of the costs of a software product line:

1. Corg returns the cost to an organization of adopting the product line approach for its products.

2. Ccab returns the development cost to develop a core asset base suited to satisfy a particular scope.

3. Cunique returns the development cost to develop unique software that itself is not based on a product line platform.

4. Creuse returns the development cost to reuse core assets in a core asset base.

Rather than rigorously defined mathematical functions, these are invitations to do thought experiments to come up with a reasonable cost (or monetary benefit) estimate in each area.

)),(),(()()(1

tproductCtproductCtCtC ireuse

n

iiuniquecaborg

Page 7: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

nbrBen

jben tB

j1

)(

Cost Benefit Analysis: Benefit Functions

A general benefit function can be used to model as many benefits as necessary.

Bben returns the value derived from a particular benefit.The difference between two release dates can be modeled

as a difference in revenue.Increased quality or customer satisfaction might be

modeled as increased revenue from increased sales and as a reduction in costs for handling trouble reports.

The benefit of reduced cost is captured in the cost functions. Be careful not to count that benefit twice!

Page 8: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Economic models

• SIMPLE is good but as the product line matures deeper models are needed.

• One approach is to use value-based software engineering.

• Value is difficult to work with because it changes, perhaps frequently, but it is a useful perspective.

• Real options is one modeling tool.

Page 9: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Real options

• An option is the right but not the obligation to carry out a certain activity such as buying a piece of real estate.

• A variation point gives the developer the option to provide different behaviors at a specific point in the flow.

• Whether or not to insert a variation point is a cost decision.

Page 10: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Real options

where

The term transforms all monetary amounts back todollars at time t.

v is the value of a specific variation point at time t for use at time T.c is the cost of getting the variation point ready. The cost is per time period.p is the probability that the variation point will actually be used at time T.VMP is the value of the variation point to a specific product in a specific time period.MC is the cost of providing that value.

)( tre

)()()( ,,, kikiki MCVMPX

Page 11: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Craftsmanship vs paint-by-numbers

• There is a place for both• Core assets should be built by craftsmen so

that products are as simple as painting by the numbers

• That way the expensive craftsmanship is amortized over the cheaper paint-by-numbers

• There are a number of organizational structures that will work

Page 12: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Problem - 1

• When determining the scope of the SPL or when asked to create a new core asset or when asked to create an additional variant for an existing asset, what is the basis for making such a decision?

• The answer is to maximize Value – Cost• For the purposes of this presentation the value of

an item will be represented by all possible revenue coming from that item. Products that use it and any licensing fees that might result from leasing it out.

Page 13: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Problem - 2

• We will focus on the value of a variation point with the constraint that only one variation point is allowed per asset – just to keep the math simple.

• We also assume that each asset is independent of other assets.

• Since a finite amount of time is involved and there is some chance of failure we chose to use a Real Options formulation of the problem.

Page 14: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Basic model

Page 15: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

concept

time

asset1

asset2

asset3

product1

product2

asset4

Page 16: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Parameters to the model - 1

• r is the assumed interest rate – in our case the riskless interest rate – often this is taken to be the interest on US Treasury Bonds

• i is the ith variation point in the set. Alternatively we could use asset or variant. Each level of granularity requires changes in how the other parameters are computed.

• T is the target date for use of the variation point (in our model it is the first use)

• T* is the limit of the model in terms of time

Page 17: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Parameters to the model - 2

• is the probability that variation point i will be ready for use by time T

• Currently we assume “ready” means it is completely ready by time T (including all variants).

• It could mean sufficiently complete for the first product that wishes to use it.

Tip ,

Page 18: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Parameters to the model - 3

• is the cost of creating the ith variation point and is a function of time. So input data is a vector of expenditures over a set of time intervals.

• Since this is cost data it could be estimated based on past development experience.

• Initially, an organization could estimate the cost to develop the variation point and then evenly distribute the costs. As they gain experience the cost data could be more accurately distributed.

• In the example in the paper we used some different distributions of cost from one asset to another

)(ic

Page 19: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Parameters to the model - 4• is the marginal value of the ith variation point in the kth

product. That value is a function of time.• Value is a function of revenue – we consider ways of making

marketing projections of revenue to be beyond our scope but this is one of the practice areas and should be reasonably available.

• We take projections of revenue (however they were derived) and allocate them across time increments (which is how most revenue projections are stated). Then we divide by each product’s contents, in terms of number of variation points used, to allocate revenue per product per variation point per time period.

• This treats all variation points the same which is certainly not accurate. We will explore parameters such as variation point complexity as a possible weighting factor.

)(, kiVMP

Page 20: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Parameters to the model - 5

• is the marginal cost of taking the specified variation point and tailoring it to work in a particular product.

• We take this to be similar to the Creuse factor in the SIMPLE model and use a flat percentage of the original development cost for this and allocate it uniformly over the time periods.

• We could include here the cost of adding a new variant.

)(, kiMC

Page 21: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

Cost spent to build variation point i at time τ

i = index over variation points

Page 22: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

…adjusted by a factor to account for net present value of money

r = assumed interest ratei = index over variation points

Cost spent to build variation point i at time τ

Page 23: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

…adjusted by a factor to account for net present value of money

Expected cost summed overall relevant time intervals

Cost spent to build variation point i at time τ

r = assumed interest ratei = index over variation points

Page 24: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

Expected costs of building variation point i incurred from now until time T

r = assumed interest ratei = index over variation points

Page 25: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

value of variation point i in product kat time τ

r = assumed interest ratei = index over variation points

Page 26: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

marginal value of the ith variation point in the kth product at time τ.

marginal cost of tailoring variation point i for use in product k

value of variation point i in product kat time τ =

r = assumed interest ratei = index over variation points

Page 27: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

marginal value of the ith variation point in the kth product at time τ.

marginal cost of tailoring variation point i for use in product k

…adjusted by a factor to account for net present value of money

value of variation point i in product kat time τ =

r = assumed interest ratei = index over variation points

Page 28: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

marginal value of the ith variation point in the kth product at time τ.

marginal cost of tailoring variation point i for use in product k

…adjusted by a factor to account for net present value of money

summed over all time

value of variation point i in product kat time τ =

r = assumed interest ratei = index over variation points

Page 29: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

marginal value of the ith variation point in the kth product at time τ.

marginal cost of tailoring variation point i for use in product k

…adjusted by a factor to account for net present value of money

summed over all time

value of variation point i in product kat time τ =

r = assumed interest ratei = index over variation points

Value cannot be negative

Page 30: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

r = assumed interest ratei = index over variation points

value of variation point i in product kover all time

Page 31: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

r = assumed interest ratei = index over variation points

value of variation point i in product kover all time…

…and over all products

Page 32: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

probability that variation point i will be ready for use by time T

r = assumed interest ratei = index over variation points

value of variation point i in product kover all time…

…and over all products

Page 33: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

probability that variation point i will be ready for use by time T

r = assumed interest ratei = index over variation points

value of variation point i in product kover all time…

…and over all products

Expected costs of building variation point i incurred from now until time T

Page 34: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

probability that variation point i will be ready for use by time T

r = assumed interest ratei = index over variation points

value of variation point i in product kover all time…

…and over all products

Expected costs of building variation point i incurred from now until time T

Value cannot be negative

Page 35: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

probability that variation point i will be ready for use by time T

r = assumed interest ratei = index over variation points

value of variation point i in product kover all time…

…and over all products

Expected costs of building variation point i incurred from now until time T

Value cannot be negative

Value of variation point i over the time interval (t,T)

Page 36: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

k = index over products

SYMBOLS FOR TIMEτ = time variablet = time now,T = target date T* = modeling limit (t=forever)

probability that variation point i will be ready for use by time T

marginal value of the ith variation point in the kth product at time τ.

marginal cost of tailoring variation point i for use in product k

Value of variation point i over the time interval (t,T)

…adjusted by a factor to account for net present value of money

Cost spent to build a variation point at time τ

Expected cost summed overall relevant time intervals

Value cannot be negative

summed over all time

expected value over all products

value of variation point i in product kat time τ =

r = assumed interest ratei = index over variation points

Value cannot be negative

Page 37: CPSC 871 John D. McGregor M11S2 Value-driven Software Engineering – part 2

Readings

• Value-Based Software Engineering : Seven Key Elements and Ethical Considerations http://www.mendeley.com/research/valuebased-software-engineering-seven-key-elements-ethical-considerations/

• Paul C. Clements, John D. McGregor, Dirk Muthig: Predicting Product Line Payoff with SIMPLE. SPLC (2) 2007: 10

• John D. McGregor, J. Yates Monteith, Jie Zhang: Quantifying value in software product line design. SPLC Workshops 2011: 40