Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 1...
-
Upload
joella-york -
Category
Documents
-
view
215 -
download
0
Transcript of Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 1...
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 1
Software Cost EstimationCOMP 3663
D. L. Silver, Ph.D.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 2
Software Cost Estimation
Predicting the resources required for a software development process
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 3
Topics covered
Feasibility Analysis Productivity measures Estimation techniques Algorithmic cost modelling Project duration
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 4
Feasibility Analysis
Feasibility – the measure of how beneficial or practical an information system will be to an organization.
Feasibility analysis – the process by which feasibility is measured.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 5
Three Tests For Feasibility
Technical feasibility – a measure of the practicality of a technical solution and the availability of technical resources and expertise.
Economic feasibility - a measure of the cost-effectiveness of a project or solution.
Operational feasibility – a measure of how well a solution will work or be accepted in an organization.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 6
Economic Feasibilty = Cost-Benefit Analysis
Costs: Development costs are one time costs that will not recur after
the project has been completed. Operating costs are costs that tend to recur throughout the
lifetime of the system. Such costs can be classified as: Fixed costs — occur at regular intervals but at relatively fixed rates. Variable costs — occur in proportion to some usage factor.
Benefits: Tangible benefits are those that can be easily quantified. Intangible benefits are those benefits believed to be difficult or
impossible to quantify.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 7
The Time Value of Money is a concept that should be applied to each technique. The time value of money recognizes that a dollar today is worth more than a dollar one year from now.
Three Popular Techniques to Assess Economic Feasibility
Payback Analysis Return On Investment Net Present Value
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 8
Software cost components Hardware and software costs Travel and training costs Personnel costs (the dominant factor in most
projects) salaries of people involved in the project benefits and insurance costs
Must also take project overhead into account costs of building, heating, lighting costs of networking and communications costs of shared facilities (e.g library, staff restaurant, etc.)
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 9
Costs for a Proposed System
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 10
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
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 11
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
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 12
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
Productivity measures
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 14
What is a line of code? Productivity measures will vary from language to
language – consider difference between lines of code in assembler versus Java
Relationship to functionality must be based on past efforts in the same language
Lines of code
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 15
Productivity estimates - LOC
System Category LOC/person-month
Real-time embedded systems 40-160
Systems programs 150-400
Commercial applications 200-800
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 16
Productivity estimates –Function points
Based on a combination of program characteristics external inputs and outputs user interactions external interfaces files used by the system
A weight is associated with each of these The function point count is computed by
multiplying each raw count by the weight and summing all values
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 17
Function points Function point count modified by complexity of the
project FPs can be used to estimate LOC depending on the
average number of LOC per FP for a given language LOC = AVC * number of function points AVC is a language-dependent factor varying from 200-300 for
assemble language to 2-40 for a high-level languages
FPs are very subjective. They depend on the estimator. Automatic function-point counting is impossible
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 18
Factors affecting productivity
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 19
All metrics based on volume/unit time are flawed because they do not take quality into account
Productivity may generally be increased at the cost of quality
It is not clear how productivity/quality metrics are related
If change is constant then an approach based on counting lines of code is not as meaningful
Quality and productivity
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 20
Estimation techniques There is no simple way to make an accurate
estimate of the effort required to develop a software system Initial estimates are based on inadequate information in a user
requirements definition The software may run on unfamiliar computers or use new
technology The skills of people working on the project may be unknown
Project cost estimates may be self-fulfilling The estimate defines the budget and the product is adjusted to
meet the budget
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 21
Estimation techniques
Expert judgement Estimation by analogy Parkinson's Law Pricing to win Algorithmic cost modelling
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 22
Expert judgement One or more experts in both software
development and the application domain use their experience to predict software costs. Process iterates until some consensus is reached.
Advantages: Relatively cheap estimation method. Can be accurate if experts have direct experience of similar systems
Disadvantages: Very inaccurate if there are no experts!
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 23
Estimation by analogy
The cost of a project is computed by comparing the project to a similar project in the same application domain
Advantages: Accurate if project data available Disadvantages: Impossible if no comparable
project has been tackled. Needs systematically maintained cost database
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 24
Parkinson's Law
The project costs whatever resources are available (typically used within an organization)
Advantages: No overspend Disadvantages: System is usually left unfinished
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 25
Pricing to win
The project costs whatever the customer has to spend on it
Advantages: You get the contract Disadvantages: Costs do not accurately reflect the
work required. Either: The customer does not get the desired system, or The customer overpays.
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 26
Pricing to win
This approach may seem unethical and unbusiness-like
However, when detailed information is lacking it may be the only appropriate strategy
The most ethical approach: The project cost is agreed on the basis of an outline proposal
and the development is constrained by that cost A detailed specification may be negotiated or an evolutionary
approach used for system development
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 27
Top-down and bottom-up estimation
Any of these approaches may be used top-down or bottom-up
Top-down Start at the system level and assess the overall system
functionality and how this is delivered through sub-systems
Bottom-up Start at the component level and estimate the effort required for
each component. Add these efforts to reach a final estimate
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 28
Top-down estimation
Can be used without knowledge of the system architecture and the components that might be part of the system
Takes into account costs such as integration, configuration management and documentation
Can underestimate the cost of solving difficult low-level technical problems
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 29
Bottom-up estimation
Usable when the architecture of the system is known and components identified
Accurate method if the system has been designed in detail
May underestimate costs of system level activities such as integration and documentation
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 30
Estimation methods
Each method has strengths and weaknesses Estimation should be based on several methods If these do not return approximately the same
result and the differences cannot be reconciled, there is insufficient information available
Some action should be taken to find out more in order to make more accurate estimates
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 31
Experience-based estimates
Estimating is primarily experience-based However, new methods and technologies may
make estimating based on experience inaccurate Object-oriented rather than function-oriented development Client-server systems rather than mainframe systems Many off-the-shelf components Component-based software engineering Use of new CASE tools and program generators
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 32
Algorithmic cost modelling
A formulaic approach based on historical cost information and which is generally based on the size of the software
Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 33
Algorithmic cost modelling Effort in PM = A SizeB M
A is depends in on the type of software that is being developed (simple, moderate, embedded) [will vary 2.4-3.5]
Size is an estimate of the code size or other functional assessmemt [thousands of lines of code, ie. 5,400 LOC 5.4]
B reflects the disproportionate effort for large projects over small projects [typically 1.0-1.5]
M is a multiplier reflecting a combination of product, process and people attributes (e.g. desired reliability, reuse required, personnel capability and expereince, support facilities) [will vary up from 1.0]
PM = person months
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 35
Estimate uncertainty
Actualperson-months
x = estimated person-months
Estimate uncertainty:As the project progressesthe probablilty of a difference in actual to estimate decreases
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 36
COCOMO Constructive Cost Model An empirical model based on project experience Well-documented, ‘independent’ model which is not tied
to a specific software vendor Long history from initial version published in 1981
(COCOMO-81) through various instantiations to COCOMO 2
COCOMO 2 takes into account different approaches to software development, reuse, etc.
Can be used as a sanity check
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 37
COCOMO 81 Effort (PM) = A * SizeB * M
PM = person-monthsKDSI = thousand of delivered software instructions
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 38
Basic COCOMO Formulae (Boehm)
Effort in Person-months = aKLOC b
Duration in Months = cEffort d
Software Project a b c d
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Due to Boehm [Bo]
Where c = labour estimate, d = complexity of project typeThese values are selected from a table such as the one below.
(See page 105 of text)
Portions from slides by Ian Sommerville, Software Engineering, 6th edition. Chapter 23 Slide 39
Computing COCOMO Case Study Models
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.