Software Project Management

Bob Hughes, Mike cotterell,

"Software Project Management",
Tata McGraw Hill, New Delhi, 2002
 SOFTWARE EFFORT ESTIMATION

(Text 1: Chapter 5): Introduction, Where are estimates done? , Problems

with over- and underestimates, the basis for software estimating, Software
effort estimation techniques, bottom -up estimating, the top-down
approach and parametric models, Expert judgment, estimating by analogy.

What are we going to learn:

1. How to avoid dangers of unrealistic estimates
2. Know different estimation methods
3. Learn how to estimate using estimation methods
 Introduction
Software Effort Estimation
• Successful project is one delivered “on time, within budget and required quality”

• Success implies that:

– Targets are set
– Project manager tries to achieve the targets

• Assumption:
– Targets are reasonable
– No record levels of productivity are achieved
– Estimation is good and there was no incorrect estimate that could have caused delay

• Realistic estimates are crucial

• The difficulty of estimating comes from

– Complexity of software
– Invisibility of software
– Human intense activities cannot be approached in a mechanistic way
 Introduction
Software Effort Estimation
Other difficulties are:
1. Subjective nature of estimating
– People tend to underestimate small project and over estimate large ones

2. Political implications
– Different people have different objectives
– Estimators may be biased to reduce cost and influence senior management to
approve project
– To avoid a such political influences estimation must be performed by specialist
group

3. Changing technology
– As technology changes rapidly previous project experience may not be useful for
future projects

4. Lack of homogeneity
– In situations where same technology exists, the knowledge of typical task duration
may not be transferrable to other projects easily as there will be large differences in
projects
 Software Estimation

• Amount of work produced = Productivity

• Amount of labour required to complete task = Effort

• Software Size = KLOC or function points

• Effort = (system size) * (productivity rate)

• Productivity rate = effort / size

– SLOC / Work Month or workday or hour
 Software Estimation
• Amanda works at a productivity rate of 4 days per KLOC per day

• How many days or wm are required to complete 2000 KLOC

Ans:

– Daily productivity = 1000 /4 =250 KLOC

– For completing 2000 LOC = 2000 / 250 = 8 days

– In work month (30.5 days/mn) = 8 / 30.5 = 0.262 Wm

 Software Effort Estimation
Exercise
• Calculate the productivity (SLOC per work month, per day) for each project

Alternate 30.5
Design Coding Testing Total 30/31 days/m
Project days/mn n
SLOC/
Wm Percent Wm Percent Wm Percent Wm SLOC SLOC/Mn
Day
A 3.9 23 5.3 32 7.4 45 17 6050 364 12
B 2.7 12 13.4 59 6.5 29 23 8363 370 12
C 3.5 11 26.8 83 1.9 6 32 13334 414 14
D 0.8 21 2.4 62 0.7 18 4 5942 1524 50

• SLOC per day varies from 12 to 50 for projects A, B, C, and D

• Industry standards for generic SW development is about 10 Lines of code/day
• Question is to consider as 10 SLOC/day as too low or ?
 Where are Estimates Done ?
Estimates are carried out at various stages of software project for different reasons
• Strategic Planning
– Project portfolio mgmt. priorities new projects based on cost and benefits
– These estimates influence the scale of development staff requirement
• Feasibility Study
– Justifies cost benefits of potential system
• System Specification
– System development methodologies distinguishes between
• User requirements and design of how these requirements are fulfilled in each stage
– The effort requirement for each stage must be estimated
– Design estimates confirm validity of feasibility study
• Evaluation of suppliers proposals
– Tenders provide requirements (for scrutinizing system specifications by suppliers)
and prepare the bid proposal
– A low bid may imply requirements not correctly understood by supplier
OR
– Bid proposal may be compared with opportunity to do in-house development
 Where are Estimates Done ?

• Project Planning
– Preparing a detailed estimates involves estimating smaller work components
– This will confirm the high level estimates done previously, supporting more
detailed estimates and staff allocation
• The accuracy if the estimates improves as project progresses
– Since project knowledge increases
• DO’s
– Apply step wise refinement which provides:
• To produce high level estimates in step 3
• Analyze project characteristics
• Obtain estimates for each individual activity
• Try to obtain estimates at a finer level

• Dont’s
– Discourage a premature estimation at the beginning of the project for
implementation
– Do not produce estimates before speculating and knowing the shape of the
application
 Selection of an appropriate project approach

• Selection of project
– 1. Scope
– 2. Infrastructure
– 3. Analyze Project characteristics
• Software processes
– Requirements, Design, Development,
Testing
• Process model
– Waterfall, Prototyping, Incremental
delivery, Agile
– 4. Identify Project activities
• 5. Estimate effort
• 6. Identify risks
– For each activity
– 7. Allocate resources
– 8. Review / Publicize plan
• 9. Execute plan
– 10. Lower level planning
• Lower level details
• Review
 Problems with over and under estimates
An over estimate causes project to take longer
• Parkinson's Law:
– “Work expands to fill the time available”
• Given an easy target staff will work less hard
• Brooks Law:
– Effort of implementing a project will go up disproportionately with
the number of staff assigned to the project.
– As Staff will grow as project team grows in size
• Effort that goes into managing, coordinating and communicating also
increase
– “Putting more people on a late job makes it later”
• An overestimate of effort leads to more staff allocation and managerial
overheads
An under estimate causes project to take longer
• Effect Quality
• Less experienced staff may produce substandard work for pressing deadlines
 Problems with over and under estimates
• Weignberg’s zeroth law of reliability:
– “If a system does not have to be reliable, It can meet any other objective”
• Under estimation effects quality, Staff not producing quality products on time
• Substandard work becomes visible during testing, it is difficult to control and produces high
amount if rework, this delays the project
Inference:
• Set achievable realistic goals
• When targets are achieved
– Motivation and morale are enhanced
• When targets are not achievable, and targets are routinely missed
– Reduces motivation
– Put success down
– Blame organization
• Barry Boehm: Estimation is not a prediction but a management goal
– If software development cost is less than 20% of the estimated cost for the job,
then a project manager can turn it into a self fulfilling prophecy
• Team will believe in success and work hard achieve it
• A self-fulfilling prophecy is the socio psychological phenomenon of someone "predicting" or
expecting something, and this "prediction" or expectation coming true simply because the
person believes or anticipates it will and the person's resulting behaviors align to fulfill the
belief. Wikipedia
 Basis for software estimation
• The need for historical data
– Estimation methods use past project data
– Care must be applied when applying past performance to new projects in factors such
as
• Programming language and experience of staff
– If past data is not available, data from external datasets can be obtained
• Ex: From International Software Benchmarking Standards Group (ISBSG)
• Parameters to be estimated
– Two parameters are estimated during project planning
• Duration in months
• Effort in work month or person month or person year
– Ex: Person month is effort one individual can put in one month
– Implicitly takes into account the loss due to holidays, weekly off, coffee breaks, etc.
• Measure of work
– Is also called the size of the project
– Work can be characterized by cost in accomplishing project and completion time
– Direct calculation of cost is difficult to estimate at early stage of planning
– Estimated time to complete task based on competencies and experience of
developer may not have been available
– Implementation may vary based on the CASE tools available in the environment
– The general approach is to estimate project size first
• Using the project size effort and time required to complete project is computed
– So, project size is an independent variable. Effort and time are dependent variables
 Basis for software estimating
What is project size ?
• Project size is a measure of problem complexity in terms of
– Effort
– Time required to complete the product
– Metrics used to measure size are
• Source Lines of Code (SLOC)
– SLOC has many disadvantages
– Intuitively simpler and is widely used
– Short comings of SLOC
» No precise definition: Comment line & data declaration calculated in SLOC
» Difficult to estimate at start of a project: Generally a guess / gut estimate
» Only a code measure: It is only a coding estimate, other stages estimates also must be
considered
» Programmer dependent: Provides only a numerical value of problem size
• This varies widely based on coding style of individual programmers
» Does not consider code complexity:
• Two SW components of same KLOC will take different time to develop to write, even
if it is done by same programmer
• Since complexity of each component may be different
• Function point (FP)
– FP corrects the disadvantages of SLOC
 Software effort estimation techniques
• Bottom-up
– Where component tasks are identified and sized and these
individual estimates are aggregated

• Procedure oriented approach

– Uses ‘effort drivers’ representing the characteristic of the target
system and the implementation environment to predict effort

• Top-down and parametric models

– Where an overall estimate for the whole project is broken down into
the effort required for component tasks
• Expert Judgment
– Based on the advise of knowledgeable staff
• Estimation by Analogy
– Similar completed project is identified and its actual effort is used as
the basis of estimate
 Bottom-up estimating
• Precursor Involves breaking project into component tasks
– In large project breaking task into subtasks is iterative
– Process continues until tasks can be executed in one /two week
• A work break down structure (WBS) is created

• The bottom up estimates involves:

– Adding up the calculated effort for each WBS activity
– Obtain an overall estimate

• Best results when used during more detailed stages of project

planning

• Is useful when project is novel and no historical data is available

• Applicable at the activity level

 Bottom-up estimating
A procedural code-oriented approach
• During software development, “procedural code-oriented approach” is used
to estimate writing code for software components
– Envisage the number and type of software modules in the final system
• Software is built from small set of system operations, ex: Insert, Amend, Update,
Display, Delete, Print etc.

– Estimate the SLOC of each identified module

• Draw the program structure
• Visualize number of instructions needed for the procedure

– Estimate the work content, taking into account complexity and

technical difficulty
• Multiply the SLOC estimate by factor for complexity and technical difficulty
• Factor is the subjective judgement of the estimator

– Calculate the work-days effort

• Use historical data to convert SLOC to effort
 Top-down approach and parametric model
• Top down approach is associated with parametric (or algorithmic) model
– Is associated with parameters associated for estimation
– Project effort relates to variables associated with characteristics of the final
system
– Formula for parametric model
• Effort = (system size) * (productivity rate)
– First Amount ow work needed
» System size in the form of KLOC (KLOC is the size driver)
– Second rate of work at which task can be done
» Productivity rate 40 days per KLOC (developer experience is the
productivity driver)
• Productivity = effort / size
• Using statistical technique (Regression):
– Effort = constant1 + (size * constant2)
• Function point method → focusses of system or task size
• Cocomo method → focusses on productivity factor
 Expert Judgement

• Asking for estimate of task effort from someone who is

knowledgeable about either application or development
environment.
• Estimator examines existing code in order to judge the
proportion of code affected and derive an estimate from that
• Experts use the combination of informal analogy approach
where similar projects from past are identified and bottom up
estimating.
 Estimating by Analogy
• Also called “case based analogy”.
• Identifies completed projects source cases (projects that have been completed)
and that have similar characteristics to the new project (the target case)
• Effort recorded for the matching source case is used as base estimate for the
target
• Identify the difference between the target and the source and adjust the base
estimate to produce estimate for the new project
TOOL – ANGEL software tool when many source cases exist
• Measuring Euclidean Distance between the cases
• Euclidean distance is calculated as :
Distance = square-root of ((target_parameter1 - source_parameter1)2 + …
(target_parametern- source_parametern)2)
Example:
I. One of the past cases Project A, has 8 inputs and 17 outputs.
II. Number of inputs to and the number of outputs for new project is known as 7 inputs
and 15 outputs.
III. The Euclidean distance between the source and the target is therefore the square-
root of ((7 - 8)2+ (17 - 15)2) = 2.24