This document discusses software cost estimation and factors that influence productivity. It defines software cost estimation as predicting resources needed for development like effort, time and total cost. Cost components include hardware/software, travel/training, and effort costs like salaries and overheads. Productivity measures include lines of code, function points based on functionality, and object points. Factors like language, code verbosity, and system characteristics can impact productivity estimates.
3. 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 and interleaved
management activities
4. Software cost components
Hardware and software costs
Travel and training costs
Effort costs (the dominant factor in most
projects)
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.)
5. 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
7. Programmer 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
8. 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
9. 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.
10. 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?
Assumes linear relationship between system
size and volume of documentation
11. Productivity comparisons
The lower level the language, the more productive
the programmer
The same functionality takes more code to implement in a
lower-level language than in a high-level language.
The more verbose the programmer, the higher
the productivity
Measures of productivity based on lines of code suggest that
programmers who write verbose code are more productive
than programmers who write compact code.
13. 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 and the
function point count is computed by multiplying
each raw count by the weight and summing all
values.
14. Object points
Object points are an alternative function-related
measure to function points
Object points are NOT the same as object classes
The number of object points in a program is a
weighted estimate of
The number of separate screens that are displayed
The number of reports that are produced by the system
The number of modules that must be developed