Transcript B. SW Project planning & scheduling

D. Size and Cost Estimation
• Section 5.3 Estimated resource requirements of the SDP template
includes the following Note on estimation:
• Basic approach:
– Break work into “small” tasks, then estimate time and cost for each
task. Finally estimate whole project by accumulating or synthesizing
the individual task estimates.
– It is wise to base estimates on valid past experience.
– In addition, other approaches may be sometimes useful such as
• - prototyping
• - cost models (e.g. COCOMO, function points).
• We expand on the topic of “estimation” in this part of the course.
1
D. Size and Cost Estimation - Overview
• Difficulties in estimating IS projects:
– IS projects tend to be one-off “affairs”, undertaken to achieve some
specific objective. May be using familiar methods etc but in novel
ways (although technology changes quite often also).
– Initial estimates for IS projects may be made long before there is a
detailed requirement specification available on which to base them.
– IS estimating is most often done by people who are not
professional estimators.
• Each of the above points would not be true for traditional
engineering disciplines, particularly Civil Engineering.
2
D. Size and Cost Estimation - Overview
• Some general lessons can be drawn from the above:
– Base estimates on the known, rather than the innovative components of a
project
– Be very careful that firm estimates are only offered on the basis of firm
specifications
– Aim for some measure of specialization in estimating (e.g. select and train
particular people to take the lead in estimating on IS projects).
– Be active in compiling “metrics” on projects so as to improve estimating
accuracy in the future. However, even where data from previous projects
are available they may not be that useful always. For example, Hughes &
Cotterell “Software Project Management” present the following data for
actual projects carried out by the same organisation (where wm = work
month(or person month), sloc = source lines of code and Design, Coding
and Test columns contain % of total wm):
3
D. Size and Cost Estimation – Overview
The table below shows much variation between actual projects:
Proj.
Des. %
Code % Test %
wm
sloc
1
23
32
44
16.7
6050
2
12
59
26
22.6
8363
3
11
83
6
32.2
13334
4
21
62
18
3.9
5942
5
10
44
45
17.3
3315
6
28
44
28
67.7
38988
7
21
74
5
10.1
38614
8
7
66
27
19.3
12762
4
D. Size and Cost Estimation – Overview
Following is a plot of “wm” versus “sloc” for previous table:
Sample data from actual projects
Effort (wm)
80
60
40
Series1
20
0
0
10000
20000
30000
40000
50000
Lines of source code (sloc)
5
D. Size and Cost Estimation - Methods
• There are a number of methods used in estimating
for IS projects. We discuss some of the most
common of these next.
• As overview, Boehm identified the following
ways of estimating SW development effort:
– algorithmic models, expert judgement, analogy,
Parkinson, price to win, top-down and bottom-up.
• He rejected 2 of these as effort prediction
methods, namely
– Parkinson (see what staff are available, use that as the estimate)
– Price to win (“estimate” is pitched at a level thought low enough to win)
6
D. Size and Cost Estimation - Methods
• Specifically, we examine the following methods:
–
–
–
–
Analogy method
Bottom-up estimating
Expert Judgement (Delphi technique)
Top-down approach & parametric models
• Analysis effort method
• COCOMO
• Function point analysis
• In addition, it is important to include “estimating
for supporting activities”
7
D. Size and Cost Estimation – Methods
Analogy method
• Seek out projects that have been completed and that have similar
characteristics to the new project. Then use the known (?) effort for the
old cases as a base estimate for the new.
• Ideally, similarities between old & new should extend to the type of
business involved, overall size, customer culture, technical methods
and languages used.
• It is very important also to identify any significant differences between
old & new, and to adjust estimate accordingly.
• Major advantage of the method is to enable an early, overall estimate
to be made.
• Danger is that there are in fact fewer similarities between old and new
than originally thought.
8
D. Size and Cost Estimation – Methods
Bottom-up estimating
• This is the most detailed technique and depends on having done a
breakdown of the project work, down to tasks that can be executed by
one person in a week or so, say.
• An effort estimate is made for each lowest level task (ideally by more
than one estimator, for cross checking)
• The total effort is then obtained by adding the individual elements.
• Generally, most suited to later stages of a project (e.g. after detailed
design process).
• At or near the start of a project or when making a bid
– May not have enough information to use the method
– or it might require too much time and resources to do the detailed
breakdown of work necessary for the method
9
D. Size and Cost Estimation – Methods
Expert Judgement (Delphi technique)
• Based on the idea of obtaining estimates from suitably qualified people
and then synthesising them to produce the final estimate. Can break
into following steps:
– Each estimator is given a specification of the work and asked to
provide an estimate (anonymously)
– The estimates are summarised anonymously and then circulated to
each estimator.
– Estimators re-consider their own estimates in the light of the
summary and provide a revised estimate if they wish.
• The steps can be repeated as necessary until a reasonable concensus is
reached.
10
D. Size and Cost Estimation – Methods
Analysis effort method
• Most suited to doing initial estimates, probably before detailed analysis is done.
• Assume following simplified, 4-stage lifecycle:
– Some analysis work leading to functional specification
– Design work leading to system design, followed by writing SW module
specifications (e.g. pseudo-code for classes and their methods)
– SW modules are coded and unit tested (CUT)
– Integration and then full system testing.
• General idea (simplified outline only) is to
– (a) estimate the effort required to perform the analysis for an assumed number of
project functions
– (b) derive the estimates for subsequent project stages via the use of ratios to the
analysis effort (ratios based on experience of previous projects).
• Note: In a previous slide of actual project data analysis effort is not included explicitly (perhaps included with
design?) but the notion of effort ratios between stages is illustrated.
11
D. Size and Cost Estimation – Methods
COCOMO (constructive cost model, due to B. Boehm)
• This approach was introduced in the early 1980s and has been refined
at various times since. One can identify three versions,
– Basic COCOMO
– Intermediate COCOMO
– Detailed COCOMO
• We will mainly focus on Basic COCOMO to give the gist of the
approach (or model) with just a few notes on the other versions.
• In summary, the model presents formulae for calculating both the
effort & elapsed time to develop software based on an assessment on
the amount of source code to be developed (expressed in thousands of
delivered source code instructions or KDSI).
• The original model was based on a study of 63 actual projects, and
later developments of the approach continue to be grounded on data
from actual projects.
12
D. Size and Cost Estimation – Methods
COCOMO (constructive cost model, due to B. Boehm)
• (1) The basic COCOMO formula for development effort is
– MM = 2.4(KDSI)1.05, where MM = effort in person/months = 152
working hours = 19 working days @ 8 hours per day.
• (2) The basic COCOMO formula for elapsed time is
– TDEV = 2.5(MM)0.38, where TDEV = total development time in
months.
• These formulae are concerned with the total development effort for a
whole project and produce estimates which should lie within a factor
of two of the actual outcome about 60% of the time. As such, the
formulae are mainly useful in the early stages in planning a project or
as a cross-check on estimates from other methods.
• The following slide illustrates formula (1) for KDSI from 1 to 20 (i.e.
up to 20,000 source instructions).
13
D. Size and Cost Estimation – Methods
COCOMO (constructive cost model, due to B. Boehm)
Effort (peroon/month)
Basic COCOMO
60
50
40
30
Series1
20
10
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Source Lines (000s)
14
D. Size and Cost Estimation – Methods
COCOMO (constructive cost model, due to B. Boehm)
• The following slide illustrates formula (2) for KDSI from 1
to 20 (i.e. up to 20,000 source instructions). (One proceeds
by calculating MM from formula (1) and then substituting
that into formula (2)).
• Formula (2), relating elapsed time to effort, has a quite
interesting implication. It shows that adding staff to a
project to try to shorten its timescale will probably not
work. This can be seen from the following graph where the
elapsed time begins to level off with increasing effort i.e.
no point in adding more people above a certain level.
15
D. Size and Cost Estimation – Methods
COCOMO (constructive cost model, due to B. Boehm)
Elapsed Time (Months)
Basic COCOMO
14
12
10
8
6
Series1
4
2
0
0
10
20
30
40
50
60
Effort (person months)
16
D. Size and Cost Estimation – Methods
COCOMO (constructive cost model, due to B. Boehm)
• It is of interest to see how the basic COCOMO
formulae estimates work on actual project data.
• The following table uses the data for 8 actual
projects presented in a previous slide.
• It can be seen that the COCOMO formula (1) does
quite well for some projects but is rather
inaccurate for others. Hence, the need for some
refinements.
17
D. Size and Cost Estimation – Methods
COCOMO (constructive cost model, due to B. Boehm)
Proj.
wm
(actual)
sloc
1
16.7
6050
2
22.6
8363
3
32.2
13334
4
3.9
5942
5
17.3
3315
6
67.7
38988
7
10.1
38614
8
19.3
12762
KDSI
wm
TDEV
(COCOMO)
(COCOMO)
6.05
8.34
13.33
15.9
22.3
36.4
7.2
8.1
9.8
5.94
3.32
38.99
15.6
8.4
112.4
7.1
5.6
15.0
38.61
12.76
111.2
34.8
15.0
9.6
18
D. Size and Cost Estimation – Methods
COCOMO (constructive cost model, due to B. Boehm)
• Intermediate COCOMO takes into account many more of the
variable factors which can influence project outcomes. Such things as
– Product attributes (reliability, complexity, …)
– Personnel attributes (capability, general experience, specific
language experience, etc)
– Project attributes (use of modern tools, language used, …).
• Essentially, these factors are used to adjust the basic estimate. For
example, if the nominal capability of personnel is 1 then use of very
highly capable personnel would reduce the basic estimate by a factor
of 0.7. On the other hand, use of very low capability personnel would
increase the basic estimate by a factor of 1.46.
• This version takes more time to use but should produce results within
20% of the actual outcomes 68% of the time.
19
D. Size and Cost Estimation – Methods
COCOMO (constructive cost model, due to B. Boehm)
• Detailed COCOMO considers the different factors which apply
during the different stages of a system development and produces more
detailed estimates on a phase by phase basis.
• The main disadvantage of the COCOMO equations is that they depend
upon an assessment of the number of delivered source instructions.
Obviously, in practice, this won’t be known accuaratel until quite late
in a project. Also, exactly how one should define “delivered source
instruction” may not be entirely clear.
• Nevertheless, the whole COCOMO approach gives good insights into
the nature of the software development process.
20
D. Size and Cost Estimation – Methods
Function point analysis
• This is a top-down approach, due to Albrecht originally. It was devised
as a way of quantifying the functional size of programs independently
of how or in what language they were coded. We just give a brief
introduction and do not discuss a further development of the approach
called “Mk II function point analysis”.
• Albrecht identified 5 major external user types that are of benefit to
users:
– External input types – input transactions that update internal computer files
– External output types – transactions where data is output to user (e.g. printed
reports)
– Logical internal files – such a “file” refers to a group of data usually accessed
together & might be made up of one or more record types
– External interface file types – allow for output and input that might pass to & from
other computer applications
– External inquiry types – user-initiated transactions to provide information but not
to update the internal files
21
D. Size and Cost Estimation – Methods
Function point analysis
• A. An analyst proceeds as follows to apply the method:
– 1. Identify each instance of each external user type in the projected
system. These are the components of the function point analysis.
– 2. Classify each component as of either high, average or low complexity.
(There are guidelines to help in this classification). There are associated
complexity weighting factors (e.g. an “external inquiry type” has weight
3, 4 or 6 depending on whether it is of low, average or high complexity).
– 3. Apply the appropriate complexity factor for each component and then
add up all the factors to arrive at the overall function point (FP) score.
• B. Finally, the analyst applies a technical complexity adjustment (TCA) to
take account of the operating environment for the system. (This step has been
problematic in deciding how it should best be implemented).
22
D. Size and Cost Estimation – Methods
Function point analysis
• Tables have been devised to convert FP scores to lines of
code for various languages. This could provide an input to
COCOMO, for example.
• The “Mk II function point analysis” version provides
formulae which can be used to estimate the effort and
elapsed time for a project.
• If one has data from previous projects in terms of both the
effort expended on them and their FP size then one can
work out a productivity rate = size/effort. Then, you can
estimate the effort for a new project if you have an
estimate iof its (FP) size.
23
D. Size and Cost Estimation – Supporting
Activities
•
•
•
While some projects go over time or budget due to under-estimation of the
identified work elements, other projects do so because activities have been
missed out altogether. This might be because of an error in creating the work
breakdown structure (WBS) or maybe because some activities were considered
insignificant.
Yeates & Cadle give the example that the activity Review program spec X has
been identified in the WBS but (possibly) related activities Revise spec X after
review, Re-review spec X and Re-work spec X after second review have been
left out. Omission of these types of supporting activities could add up to a lot
of time and effort over the course of a project.
Supporting activities can be accounted for
– Either by estimating them explicitly (e.g. add a task Quality Review &
allow time and effort for it)
– Or by adding a percentage on top of a basic activity (e.g. add 5% to 10%
on top of program spec. for quality reviews).
24
D. Size and Cost Estimation – Supporting
Activities
• Some supporting activities can be estimated as
proportions of explicitly estimated tasks, including
Team leading/Supervision during coding to system
testing, Documentation such as User or Operations
Manuals, Peer and other reviews.
• Other supporting activities are more related to the
elapsed duration of a project, such as Project
management, Configuration management, Project
Office (secretarial and administrative support),
and Sub-contractor management.
25
D. Size and Cost Estimation – Some tips to
improve estimation (Yeates & Cadle)
• Build up metrics - ideally throughout an organisation.
• Use standard project structures - as far as possible as then it is more valid
to use data from previous projects in estimating new projects.
• Get more than one view - more than one person involved, more than one
method used.
• Qualify estimates - by stating the assumptions on which they are based.
• Document estimates (and store them) - recording thought processes and
calculations
•
– allows one to compare the results of different estimating methods
– should help the project manager to analyse the reasons for disparities between
estimated and actual time and cost both during the project and on its completion.
In turn, this should allow estimation to be improved.
Estimation and Risk Analysis – initial project risk analysis should include an
assessment of the reliability and accuracy of the estimation methods.
26