Budgeting and cost estimation

Project Management

Lesson 7

Fundamental estimation questions

How much effort is required to complete an activity? How much calendar time is needed to complete an activity? What is the total cost of an activity? Project estimation and scheduling are interleaved management activities.

Software cost components

Hardware and software costs. Travel and training costs. Effort costs (the dominant factor in most projects)

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, staff restaurant, etc.).

Costing and pricing

Estimates are made to discover the cost, to the developer, of producing a software system. There is not a simple relationship between the development cost and the price charged to the customer. Broader organisational, economic, political and business considerations influence the price charged.

Software pricing factors

Market opportunity A d evelopment organisation may quote a low price because it wishes to move into a new segment of the software market. Accepting a low profit on one project may give the opportunity of more profit later. T he experience gained may allow new products to be developed. If an organisation is unsure of its cost estimate, it may increase its price by some contingency over and above its normal profit. A c ustomer may be willing to allow the developer to retain ownership of the source code and reuse it in other projects. T he price charged may then be less than if the software source code is handed over to the customer. If the requirements are likely to change, an organisation may lower its price to win a contract. After the contract is awarded, high prices can be charged for changes to the requirements. Developers in financial difficulty may lower their price to gain a c ontract. It is better to make a sm aller than normal profit or break even than to go out of business.

Cost estimate uncertainty Contractual terms

Requirements volatility Financial health

Software productivity

A measure of the rate at which individual engineers involved in software development produce software and associated documentation. Not quality-oriented although quality assurance is a factor in productivity assessment. Essentially, we want to measure useful functionality produced per time unit.

Productivity measures
Size related measures based on some output from the software process. This may be lines of delivered source code, object code instructions, etc. Function-related measures based on an estimate of the functionality of the delivered software. Function-points are the best known of this type of measure.

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.

Lines of code

What's a line of code? The measure was first proposed when programs were typed on cards with one line per card; How does this correspond to statements as in Java which can span several lines or where there can be several statements on one line. What programs should be counted as part of the system? This model assumes that there is a linear relationship between system size and volume of documentation.

Project planning process

Software scope - determination of function and performance Resources - estimation of required resources Project estimation - quantitative analysis of cost and duration Risk analysis - risk identification, assessment and solution Scheduling - production of software development time tables Decision making - selection of cost-effective design methods Organisational planning - organisation of software teams

Software scope and resources

Scope

Well-bounded specification of software function Well-bounded specification of interfaces Well-bounded specification of constraints Human resources: selection of skills required for software development Hardware resources: determination of the development system, target machine, and other hardware devices Software resources: determination of CASE (computer-aided software engineering) tools

Resources

Project estimation techniques

Algorithmic cost modelling based on historical information Static models such as COCOMO Dynamic models such as Putnam Expert judgement based on expert's experience Estimation by analogy based on similar completed projects Pricing to win based on availability of customer's budgets Bottom-up estimation based on costs of software components

Algorithmic cost modelling

Cost is estimated as a mathematical function of product, project and process attributes The function is derived from a study of historical costing data Most commonly used product attribute for cost estimation is LOC (code size) Most models are basically similar but with different attribute values

Estimation of code size

Number of lines of code

Estimation based on source code files Major advantage: easy measurement based on programs Major weakness: programming-language and designdetail dependencies Information domain characteristics and values Domain characteristics Distinct application-oriented data given to software Application-oriented information produced to the user On-line inputs which result in on-line outputs Logical master files All machine-readable interfaces

Function points

Values Number of user inputs Number of user outputs Number of user inquiries Number of files
Number of external interfaces

Complexity adjustment values

0 1 2 3 4 5 no influence incidental moderate average significant essential
Fi : 1. Does the system require reliable 8. Are the master files updated on-line? backup and recovery? 9. Are the inputs, outputs, files or inquires 2. Are data communications complex? required? 3. Are there distributed processing 10. Is the internal processing complex? 11. Is the code designed to be reusable? functions? 12. Are conversion and installation 4. Is performance critical? 5. Will the system run in an existing, included in the design? 13. Is the system designed for multiple heavily utilised operational installations in different organisations? environment? 6. Does the system require on-line 14. Is the application designed to facilitate change and ease of use by the user? data entry? 7. Does the on-line data entry require input transactions to be built over multiple screens?

Estimating code size using function points

Computation of function points

count total ( w i numberi )
i =1 5

complexity total Fi
i =1

14

functionpoints count total (0.65 0.01 complexity total)

Where wi: weighting factors determined empirically

0.65 and 0.01: constant values determined empirically

Subjective assessment of the complexity factors Early size prediction and language independence

Weakness and advantage

Estimation example
Number of user inputs Number of user outputs Number of user inquiries 32 60 24 W1 W2 W3 W4 W5 4 5 4 10 7

Number of files 8 Number of external interfaces 2

Count total = (32 x 4) + (60 x 5) + (24 x 4) + (8 x 10) + (2 x 7) = 618 Assume all complexity adjustment values are average complexity total = 3 x 14 = 42 function points = 618 x (0.65 + (0.01 x 42)) = 661.26
Assume the complexity total = 50 function points = 618 x (0.65 + (0.01 x 50)) = 710.7 Assume assume that one point is 100 lines of C code Difference = (710.7 661.26) x 100 = 4944 LOC

COCOMO (COnstructive COst MOdel)

COCOMO can be applied in three increasing sophisticated ways: Basic COCOMO

a function of program size a function of program size and a set of "cost drivers" extension of the intermediate model with regard to the cost driver's impact on each step of the software development

Intermediate COCOMO

Advanced COCOMO

Basic COCOMO

Classes of software projects

Organic mode projects: small teams, familiar working environment and well understood applications Semi-detached mode projects: teams of experienced and inexperienced staff, limited experience of related systems, and unfamiliarity with some aspects of the systems being developed Embedded mode projects: tight hardware, software, and operational constraints

Basic COCOMO
Estimation of project effort ( E ) in person - months E ab KLOC bb where KLOC number of thousandlines of code where ab , bb constant v alues determined empirically
Software project organic semi-detached embedded ab 2.4 3.0 3.6 bb 1.05 1.12 1.20

For example, the organic model is Eorganic 2.4 KLOC1.05

Basic COCOMO

Comparison of the models 1600 1400 Example: 1200 assuming that 1000 an embedded800 project 600 consists of 400 128000 200 delivered 0 source instructions, the project effort is
Effort (PM)

COCOMO estimated effort Organic Semi-detached Embedded

20

40

60

80 KLOC

100

120

140

Eembedded = 3.6 128 1.20 1216 p.m.

Basic COCOMO
Estimation of development time ( D) in months D cb E db wherecb , d b constant v alues determined empirically
Software project organic semi-detached embedded

cb 2.5 2.5 2.5

db 0.38 0.35 0.32

For example, the semi - detached model is Dsemidetached 2.5 E 0.35

Basic COCOMO

Development Dembedded 2.5 1216 0.32 24 months schedule 1216 N 51 people Example: the effort 24 of the embedded Development time project is 1216 p.m. 30
25
Months

20 15 10 5 0 0 20 40 60 80 KLOC 100 120 140 Semi-detached

The End

Zainudin Johari

B Sc. (Hons) Computer Science, UPM

M Sc. Computer Science (Information Systems) UPM