Project Estimation

25
3. Project Estimation Kasun Ranga Wijeweera ([email protected])

Transcript of Project Estimation

3. Project Estimation

Kasun Ranga Wijeweera([email protected])

Why We Need Estimation?• Large software systems usually take 200-300% cost overruns and a 100% schedule slip

• 15% of large projects fail without delivering anything

• Failures occur basically due to poor management and inaccurate estimations of development cost and development schedule

• Developers have to pay the price in schedule slips

Estimation Problems• Software cost prediction• Software schedule prediction• Software risk control• Progress tracking• Project management

Software Cost• Hardware and software• Travel and training• Effort: (dominant factor)

– Salaries of engineers– Social and insurance

• Other– Building, heating, lighting– Networking and communications– Shared facilities (E.g. library, restaurant)

Cost and Price• The relationship between the software development cost and charged price from the customer is not simple

• Price is influenced by– Organization– Economy– Politics– Business considerations

Pricing Factors• Market opportunity– Accepting low profit on one project may give the opportunity of more profit later

– Gaining experience– Wish of moving into a new segment in market

• Cost estimate uncertainty– Unsure cost estimate can lead expecting higher than normal profit

Pricing Factors…• Contractual terms– Customer allows developers to retain the ownership of the source code and reuse it in other projects

• Requirements volatility– Requirements are likely to change– Price can be lowered to win the contract

– Higher prices can be charged later for changing requirements

Pricing Factors…• Financial health– Developers may be in financial difficulty

– Price can be lowered to win the contract– Better to make smaller profit than normal profit than to go out of business

– Break even may also be a solution

Estimation Models• Expert judgment• Analogy• Parkinson’s law• Price to win

Expert Judgment• Experts in both software development and application domain use their experience

• Advantages– Relatively cheap– Accurate if they have knowledge in similar systems

• Disadvantages– If there are no experts!

Analogy• The project is compared to a similar project in the same application domain

• Advantages– Accurate if project data is available and people/tools are the same

• Disadvantages– Impossible without a similar project available

– Systematically maintained cost database is necessary

Parkinson’s Law• Whatever the resources available is the cost of the project

• Advantages– No need to overspend

• Disadvantages– System is usually unfinished

Cost Pricing to Win• Whatever the customer is able to spend is the cost of the project

• Advantages– Can get the contract

• Disadvantages– Customer satisfaction of the product is less

– Cost does not reflect the work required

Algorithmic Cost Modeling

• A mathematical function is used to estimate the cost– Inputs: Project, Process, Product– Decided by project managers

• Historical data are studied to derive the function

• Commonly used product attribute is LOC (code size)

Software Productivity• The rate at which individual software engineers involve in development process is known as software productivity

• Although quality assurance is a factor in productivity assessment, the productivity is not quality oriented

• The useful functionality produced per time unit should be measured

Productivity Measures• Size related measures:– Lines of delivered source code– Object code instructions– Etc

• Function related measures:– Functionality of the delivered software

– E.g. Function points

Lines of Code• What programs should be considered as part of the system?

• Assumption of the model:– The relationship between system size and volume of documentation is linear

• Key thing to remember:– Uncertainty is more important than the initial line

– Seek justifiable bounds

Productivity Comparison• Low level language verses high level language

• Verbose code verses compact code

Function Points• Program characteristics are considered– External inputs and outputs– User interactions– External interfaces– Files used by the system

• Corresponding weights are assigned to each characteristic

FPs and LOC• FPs can be used to estimate LOC

– LOC = AVC * (Number of FPs)– AVC is a factor which depends on the programming language•Assembly language: AVC = 200 to 300•4 GL language: AVC = 2 to 40

• FPs are subjective and dependent on the estimator– FP automation is impossible

Productivity Estimates• Real time embedded systems

– 40 to 60 LOC per month• Systems programs

– 150 to 400 LOC per month• Commercial applications

– 200 to 900 LOC per month

Productivity Factors• Application domain experience• Process quality• Product size• Technology support• Working environment

Changing Technologies• Previous estimating experience does not carry over to new systems due to changes in technology – Use of web services– Use of CASE tools and program generators

– Development for and with reuse– Using scripting languages

COCOMO• Constructive Cost Model (COCOMO)• Estimates are derived as functions of variables

• Data of past projects must be available

• First published by Dr. Barry Boehm in 1981

• Derived through statistical regression of data from 63 past projects

Thank you!