37_ch26

8/7/2019 37_ch26

1/36

8/7/2019 37_ch26

2/36

Note content copyright 2004 Ian Sommerville. NU-specific content copyright 2004 M. E. Kabay. All rights reserved.

Objectives

To introduce the fundamentals of softwarecosting and pricing

To describe three metrics for softwareproductivity assessment

To explain why different techniques shouldbe used for software estimation

To describe the principles of the COCOMO 2algorithmic cost estimation model

8/7/2019 37_ch26

3/36


Topics covered

Software productivity

Estimation techniques

Algorithmic cost modeling

Project duration and staffing

8/7/2019 37_ch26

4/36


Fundamental estimationquestions

How much effort is required to complete anactivity?

How much calendar time is needed tocomplete an activity?

What is the total cost of an activity?

Project estimation and scheduling areinterleaved management activities.

8/7/2019 37_ch26

5/36


Software cost componentsHardware and software costs.

Travel and training costs.

Effort costs (the dominant factor in mostprojects)

The salaries of engineers involved in the

project;

Social and insurance costs.

Effort costs must take overheads into account

Costs of building, heating, lighting.

Costs of networking and communications.

Costs of shared facilities (e.g library, staffrestaurant, etc.).

8/7/2019 37_ch26

6/36


Costing and pricing

Estimates are made to discover the cost, tothe developer, of producing a softwaresystem.

There is not a simple relationship between thedevelopment cost and the price charged tothe customer.

Broader organizational, economic, politicaland business considerations influence the

price charged.

8/7/2019 37_ch26

7/36Note content copyright 2004 Ian Sommerville. NU-specific content copyright 2004 M. E. Kabay. All rights reserved.

Software pricing factors(1)

Market opportunity

A development organization may quote alow price because it wishes to move into anew segment of the software market.

Accepting a low profit on one project maygive the opportunity of more profit later.

The experience gained may allow newproducts to be developed.

Cost estimate uncertainty

If an organization is unsure of its costestimate, it may increase its price by somecontingency over and above its normalprofit.

8/7/2019 37_ch26



Contractual terms

A customer may be willing to allow the developer toretain ownership of the source code and reuse it inother projects.

The price charged may then be less than if thesoftware source code is handed over to thecustomer.

Requirements volatility

If the requirements are likely to change, an

organization may lower its price to win a contract.After the contract is awarded, high prices can be

charged for changes to the requirements.

8/7/2019 37_ch26



Financial health

Developers in financial difficulty may lowertheir price to gain a contract.

It is better to make a smaller than normalprofit or break even than to go out ofbusiness.

8/7/2019 37_ch26


Software productivity

A measure of the rate at which individualengineers involved in software developmentproduce software and associateddocumentation.

Not quality-oriented although qualityassurance is a factor in productivityassessment.

Essentially, we want to measure useful

functionality produced per time unit.

8/7/2019 37_ch26


Productivity measures

Size-related measures

Based on some output from the softwareprocess.

This may be lines of delivered sourcecode, object code instructions, etc.

Function-related measures

Based on an estimate of the functionalityof the delivered software.

Function-points are the best known of thistype of measure.

8/7/2019 37_ch26


Measurement problems

Estimating the size of the measure

(e.g. how many function points).

Estimating the total number of programmer

months that have elapsed.Estimating contractor productivity

(e.g., documentation team) and

incorporating this estimate in overall

estimate.

8/7/2019 37_ch26


Lines of code (LOC)

What's a line of code?The measure was first proposed when

programs were typed on cards with one line percard;

How does this correspond to statements as inJava which can span several lines or wherethere can be several statements on one line?

What programs should be counted as part of thesystem?

This model assumes that there is a linearrelationship between system size and volume ofdocumentation.

8/7/2019 37_ch26


Productivity comparisons

The more verbose the programmer, the higherthe productivity?

But measures of productivity based onLOC suggest that programmers who write

verbose code are more productive thanprogrammers who write compact code (!)

The lower-level the language, the moreproductive the programmer?

Same functionality takes more code toimplement in a lower-level language thanin a high-level language

8/7/2019 37_ch26


System developmenttimes

Analysis Design Coding Testing Documentation

Assembly code

High-level language

3 weeks

3 weeks

5 weeks

5 weeks

8 weeks

4 weeks

10

weeks

6 weeks

2 weeks

2 weeks

Size Effort Productivity

Assembly code

High-level language

5000 lines

1500 lines

28 weeks

20 weeks

714 lines/month

300 lines/month

8/7/2019 37_ch26


Productivity estimates

Real-time embedded systems, 40-160LOC/P-month.

Systems programs , 150-400 LOC/P-month.

Commercial applications, 200-900LOC/P-month.

In object points, productivity has beenmeasured between 4 and 50 objectpoints/month depending on tool support and

developer capability.

8/7/2019 37_ch26


Factors affectingproductivity

8/7/2019 37_ch26


Quality and productivity

All metrics based on volume/unit time areflawed because they do not take quality intoaccount.

Productivity may generally be increased at

the cost of quality.

It is not clear how productivity/quality metrics

are related.

If requirements are constantly changing thenan approach based on counting lines of codeis not meaningful as the program itself is notstatic.

8/7/2019 37_ch26



There is no simple way to make an accurateestimate of the effort required to develop asoftware system

Initial estimates are based on inadequate

information in a user requirementsdefinition;

The software may run on unfamiliarcomputers or use new technology;

The people in the project may be unknown.Project cost estimates may be self-fulfilling

The estimate defines the budget and theproduct is adjusted to meet the budget.

8/7/2019 37_ch26


Changing technologies

Changing technologies may mean that previousestimating experience does not carry over to newsystems

Distributed object systems rather than

mainframe systems;Use of Web services;

Use of ERP or database-centered systems;

Use of off-the-shelf software;

Development for and with reuse;

Development using scripting languages;

The use of CASE tools and programgenerators.

8/7/2019 37_ch26



Algorithmic cost modeling.

Expert judgement.

Estimation by analogy.

Parkinson's Law.Pricing to win.

8/7/2019 37_ch26


Estimation techniques (1)

Algorithmic cost modellingA model based on historical cost information

that relates some software metric (usually itssize) to the project cost is used.

An estimate is made of that metric and themodel predicts the effort required.

Discussed in the text but not part of IS301

8/7/2019 37_ch26



DELPHI Technique -- Expert judgementconsensus

Several experts on the proposed softwaredevelopment techniques and the application

domain are consulted.They each estimate the project cost.

These estimates are compared and the topand bottom quartiles are discussed.

The estimation process iterates until therange of estimates stabilizes

8/7/2019 37_ch26

24/36


Delphi Technique (contd)

RAND Corporation, 2nd World WarDevelop quantitative estimates using expert

opinion

Ask top and bottom

quartiles to explainreasons

Share reasons

Estimate again

Iterate to stability Es

tima

tes

Days

Top Quartile

8/7/2019 37_ch26

25/36



Estimation by analogy

Applicable when other projects in the sameapplication domain have been completed.

Cost of a new project is estimated by analogywith these completed projects.

Parkinsons Law

Work expands to fill the time available.

Cost determined by available resources ratherthan by objective assessment.

E.g., if the software has to be delivered in 12months and 5 people are available, the effortrequired is estimated to be 60 person-months.

8/7/2019 37_ch26

26/36


Estimation techniques (4)Pricing to win

HowThe software cost is estimated to be whatever

the customer has available to spend on theproject.

The estimated effort depends on thecustomers budget and not on the softwarefunctionality.

Advantages:

You get the contract.

Disadvantages:The probability that the customer gets the

system he or she wants is small.

Costs do not accurately reflect the workrequired.

8/7/2019 37_ch26

27/36


Top-down and bottom-upestimation

Any of these approaches may be used top-down or bottom-up.

Top-down

Start at the system levelAssess the overall system functionality

and how this is delivered through sub-systems.

Bottom-up

Start at the component level and estimatethe effort required for each component.

Add these efforts to reach a final estimate.

8/7/2019 37_ch26

28/36


Top-down estimation

Usable without knowledge of the systemarchitecture and the components that mightbe part of the system.

Takes into account costs such as integration,

configuration management anddocumentation.

Can underestimate the cost of solvingdifficult low-level technical problems.

8/7/2019 37_ch26

29/36


Bottom-up estimation

Usable when the architecture of the system isknown and components identified.

This can be an accurate method if the systemhas been designed in detail.

It may underestimate the costs of systemlevel activities such as integration anddocumentation.

8/7/2019 37_ch26

30/36


Estimation methods

Each method has strengths and weaknesses.

Estimation should be based on severalmethods.

If these do not return approximately thesame result, then you have insufficientinformation available to make an estimate.

Some action should be taken to find outmore in order to make more accurate

estimates.

8/7/2019 37_ch26

31/36


Pricing to win

Pricing to win is sometimes the onlyapplicable method.

This approach may seem unethical and un-businesslike.

However, when detailed information is lackingit may be the only appropriate strategy.

The project cost is agreed on the basis of anoutline proposal and the development is

constrained by that cost.A detailed specification may be negotiated or

an evolutionary approach used for systemdevelopment.

8/7/2019 37_ch26

32/36


Staffing requirements

Staff required cant be computed by dividingthe development time by the requiredschedule.

The number of people working on a project

varies depending on the phase of the project.The more people who work on the project, the

more total effort is usually required.

A very rapid build-up of people often

correlates with schedule slippage.

8/7/2019 37_ch26

33/36


Key points

There is not a simple relationship between theprice charged for a system and itsdevelopment costs.

Factors affecting productivity include

individual aptitude, domain experience, thedevelopment project, the project size, toolsupport and the working environment.

Software may be priced to gain a contract and

the functionality adjusted to the price.

8/7/2019 37_ch26

34/36


Key points

Different techniques of cost estimationshould be used when estimating costs.

Algorithmic cost models support quantitativeoption analysis as they allow the costs of

different options to be compared.The time to complete a project is not

proportional to the number of people workingon the project.

8/7/2019 37_ch26

35/36


Homework

Readall of Chapter 26

Studyin detail only pp. 613-624:

We are not including algorithmicestimation in the course details

Optional (because of lateness in term)

By Tuesday 14 Dec 2004

For up to 30 points, answerin detailany or

all of26.1, 26.2, 26.4, 26.5, 26.10, 2.11 (@5)

8/7/2019 37_ch26

36/36

DISCUSSIO

N

37_ch26

Documents