Managing

Software Projects
Estimation
 Why Measure?
⚫ Make informed and effective decision

⚫ Which metrics to use?

⚫ When to use?

⚫ How to interpret them?

 What do companies measure?
⚫ Business and Corporate measure
⚫ SOX (Sarbanes & Oxley Act)
⚫ Balanced Scorecard
⚫ ROI, IRR, TCO, NPV
⚫ Shareholder measure, market share measure
⚫ Quality measure
⚫ Software configuration measure
⚫ Earned Value measure
 Why do we need Metrics?

⚫ To evaluate
⚫ To improve
⚫ To estimate
 Metrics - Critical for Project
⚫ Scope, Time, Cost, Quality, Resources, and
Risk in order to accurately estimate the project.
⚫ Common questions at the start of the project
• How much work is to be estimated (scope).
• How much time it will require to complete the project
(Schedule).
• Who will be doing the project (resources)?
• What is the budget required to deliver the project
(cost)?
• Any intermediary dependencies that may delay or
impact the project (Risks).
• How to estimate the project (techniques).
 For your project:
⚫ How are you going to give feedback to your
team members?
⚫ How are you going to assess the quality of
the code produced?
⚫ How are you going to track progress?
⚫ How are you going to assign tasks?
 Development Methodologies

⚫ Fifty different kinds of technology

⚫ TSP (Team Software Process)

⚫ Agile
⚫ Use Case

⚫ Create fifty different kinds of measurement?

 For measures
⚫ Info required
⚫ Hard data
⚫ Data that can be easily quantified
⚫ Ex. No of defects, no. of staff, schedule
⚫ Soft data
⚫ Topics in which human opinion must be evaluated
▪ Ex. Skill and experience of the team
▪ User satisfaction with project
▪ Schedule pressure on the team
⚫ Normalized data
⚫ Measure of productivity, quality.
 Software Estimation
⚫ Inputs needed for estimation
⚫ WBS
⚫ Initiation Document
⚫ Statement of requirements
⚫ Features
⚫ Evaluation
⚫ Performance
⚫ Processes and standards to be used
⚫ Critical Path
 Software Estimation
⚫ Inputs needed for estimation
⚫ Prior Experience in similar tasks
⚫ Historical Estimation data
⚫ Programming languages to be used
⚫ Re-usable software information
⚫ Software Architecture

Unlikely that all will be available

 Inputs to estimate effort
⚫ Tasks
⚫ S/W Development Tasks (Design, Code, Test)
⚫ Support Tasks (CM, QA)
⚫ Additional dollar Cost (Travel, Equipment,
Overheads)
⚫ Size estimate
⚫ Historical Data on effort and productivity
⚫ Process and Methods
⚫ Programming Language
⚫ OS, Tools to be used
⚫ Staff Experience Level
 Metrics factors
⚫ Domain
⚫ Size
⚫ Complexity
⚫ Platform
⚫ Technology
⚫ Domain Category
 Software Estimation Techniques
Estimation: To predict size, effort, schedule, cost etc.
Estimation Models:
– Historical - Experimental Model
⚫ Empirical Model – relate observation of the past performance
to predictions of future efforts.
– Statistically Based Model (Regression Model) – derived from
historical data & describe the mathematical relationship among
project variables.
⚫ Ex., Unadjusted Function Points, Basic COCOMO Model
– Theoretically Base Model – based on the underlying theoretical
considerations of software development processes.
⚫ Ex., SLIM/Putnam, Resource Allocation Model, Halstead Software
Science Model
– Composite Model
⚫ Ex., COCOMO, Function Points/Feature Points
 Accuracy of Estimation

4x
Estimates can be off by a factor of
2x
four early in the SDLC
1.50x
1.25x
1x

0.5x

0.25x

Feasibility Requirements HLD LLD Coding & Accepted

Analysis Testing Software
Development Phase
 Project measurements

⚫ Direct measures
⚫ Lines of code

⚫ Indirect measures
⚫ Function points
 Size Measures for Software
⚫ Lines of Code (LOC/KSLOC)
⚫ Function points
⚫ Feature Points
⚫ No. of Bubbles on a DFD
⚫ No. of Entities in a ERD
⚫ Count of process boxes in a structure chart
⚫ No. of objects, attributes and services on an
Object diagram
 Estimation
⚫ Use expert opinion
⚫ Algorithmic models
⚫ ‘Price to win’
⚫ By analogy
⚫ Guidelines for counting LOC (PPA)
⚫ Each “source line(s)” should contain only one
instruction statement
⚫ Count all deliverable, executable statements
⚫ Do not count lines that contain comments
⚫ Do not count reusable code container
⚫ Ex. LocMetrics, SCC
 Advantages of using LOC as
measure
⚫ Widely and universally accepted
⚫ Directly relates to end-product
⚫ Measures from the point-of-view of the
developer
⚫ Easily measurable
⚫ Provides historical data for future estimations
⚫ Provides comparison between productivity
and size
 Disadvantages of using LOC
as measure
⚫ LOC difficult to estimate early in the life cycle
⚫ Sources of instruction vary with programming
language
⚫ No industry standards
⚫ Code generators often produce excess code
lines
⚫ Programmers may be rewarded for large
LOC, mistaking it for productivity
 Total software Development
Costing
⚫ Hardware and software costs including maintenance
⚫ Travel and training costs
⚫ Effort costs (the costs of paying people other than
software engineers).
⚫ Costs of providing, heating and lighting office space
⚫ Costs of support staff such as accountants,
administrators, system managers, cleaners and
technicians
⚫ Costs of networking and communications
⚫ Costs of central facilities such as a library or
recreational facilities
⚫ Costs of Social Security and employee benefits such
as pensions and health insurance.
 “Good” software cost estimate
⚫ It is conceived and supported by the project
manager and the development team.
⚫ It is accepted by all stakeholders as
realizable.
⚫ It is based on a well-defined software cost
model with a credible basis.
⚫ It is based on a database of relevant project
experience
⚫ It is defined in enough detail
 Poor Software Cost Estimates
⚫ Lack of a historical database of cost
measurement
⚫ Software development involving many
interrelated factors, which affect development
effort and productivity, and whose relationships
are not well understood.
⚫ Lack of trained estimators and estimators with
the necessary expertise
⚫ Little penalty is often associated with a poor
estimate
 Steps in Sizing and Estimation
Analogy, Delphi, FP, Feature Points, Historical Database
Estimate
Size COCOMO, SLIM, Domain Experts
Estimate
Effort
Estimate
Duration
Estimate
Cost
Forecast
Resource
Needs
Model
OO Methods, Requirements
Structured Methods
Create
SRS
 Software Requirements
Specifications

⚫ Visibility Technique

⚫ To collect all software requirements

surrounding a project into one document

⚫ Identifies what must be learnt and who has

the needed information
 Desired characteristics in SRS

⚫ Correct
⚫ Unambiguous
⚫ Traceable
⚫ Consistent
⚫ Complete
⚫ Verifiable
⚫ Understandable by the customer
⚫ Design independent
 Identify and Link

⚫ Functional requirements, each has an origin

from where they came

⚫ Link requirements with their sources, by

giving a unique ID to the requirement.
Identify and Link (Ex.)
 Requirements Traceability
Matrix - RTM

⚫ "chain of custody" document for requirements

⚫ Requirements lead to a design element, that

leads to a code unit, to testing.

⚫ Visibility technique

⚫ Requirement no., name important

Sample RTM
 Steps in estimating - 1
⚫ Step 1:
⚫ Establish Cost-estimation Objectives
⚫ Step 2:
⚫ Develop a plan for estimation activities
⚫ Step 3:
⚫ Clarify software requirements
⚫ Step 4
⚫ Explore as much detail as feasible
 Steps in estimating
…cont’d
⚫ Step 5:
⚫ Use several independent techniques

⚫ Step 6:
⚫ Compare, understand and Iterate Estimates

⚫ Step 7:
⚫ Review Estimate Accuracy
 Function Points (FP)
⚫ Measure based on complexity and number of
end-user business functions that the software
performs

⚫ Developed by Albrecht of IBM in 1970s

⚫ Caper Jones expanded the idea

 What is needed for FP?

⚫ Standard Environmental factors affecting the

system called GSC (General System
Characteristics) that rates from 0-5
⚫ Raw function points based on inputs, inquiries,
output, external files
⚫ Adjustment Factor constant
⚫ Language conversion factor (Standard table)
General System
Characteristics (GSC)
 Complex DP E-banking

General Distributed Processing

Stringent Performance
Web search engine
Air-traffic control
System Heavily Used
configuration
A university system

Characte Fast Transaction Site Bank – balancing of books

Online Data Entry Conversion of document data
ristics to electronic form
User Friendly Design Software kiosks
: :
: :

Rating
0,1,2,3,4,5
 FP Step-wise
⚫ Step 1: Determine the outputs, inputs,
database inquiries, files/data structures and
external interfaces

⚫ Step 2: Establish Complexity in each –

simple, medium and complex

⚫ Step 3: Establish weights for each complexity

(0-No influence, 1-Incidental influence, 2-
Moderate influence, 3 – Average influence
etc.,)
 FP Step-wise
⚫ Step 4: Multiply each function by its weight
and then sum up to get total function points
⚫ Step 5: Calculate Complexity Adjustment
Factor as
CAF = 0.65 + ( 0.01 * N)
where
N = sum of weighted environmental factors
Step 6: Calculate the Adjusted Function Points
AFP = FP (Raw) * CAF
 FP Step-wise
⚫Step 7: Convert function points to LOC using
the formula
LOC = AFP * LCF
where,
LCF = Language Conversion Factor
LCF is obtained from the conversion table
given by IFPUG for each language
 Function Points
⚫ Advantages
⚫ Can be applied early in the Life cycle
⚫ Independent of any programming language
⚫ Provide a mechanism to track and monitor the
project

⚫ Disadvantages
⚫ Not well-suited for non-MIS applications
⚫ Best performed only after design creation
⚫ Not an effective metric tool for maintenance projects
 Function Points Parameters
⚫ Outputs,
⚫ Reports, confirmation messages, graphs, charts
⚫ Inputs
⚫ User Interfaces, Transactional / process data
⚫ Database inquiries
⚫ Retrieval of data, combination of Inputs/Outputs
⚫ Files/data structures
⚫ Data stored, could be ERDs, Databases
⚫ External interfaces
⚫ Maintained by another application system
 Rating
# Environmental factor (0-5)
1 Data Communications
2 Distributed Computing

GSC 3 Performance Requirements

4 Constrained Configuration
5 Transaction Rate
6 Online Inquiry
7 End-User Efficiency
8 Online Update
9 Complex Processing
10 Reusability
11 Ease of conversion
12 Ease of Operation
13 Used at Multiple sites

14 Potential for Functional Change

 Complexity factor

Simple Average Complex

No. of Inputs __ x 3 __ x 4 __ x 6
No. of Outputs __ x 4 __ x 5 __ x 7
No. of inquiries __ x 3 __ x 4 __ x 6
No. of Files __ x 7 __ x 10 __ x 15
No. of Interfaces __ x 5 __ x 7 __ x 10
 Language Conversion Factors
Language LOC / Adjusted FP
C 130
COBOL 110
Java 55
C++ 50
Turbo Pascal 50
VB 30
Power Builder 15
HTML 15
Packages (Access Excel) 10-40
Example of FP estimation
 Fixed price per unit delivered

FP count Design implement- total cost/FP

cost/FP ation cost/FP
to 2,000 $242 $725 $967
2,001- $255 $764 $1,019
2,500
2,501- $265 $793 $1,058
3,000
3,001- $274 $820 $1,094
3,500
3,501- $284 $850 $1,134
4,000

46
 Fixed price/unit example

⚫ Estimated system size 2,600 FPs

⚫ Price
⚫ 2000 FPs x $967 plus
⚫ 500 FPs x $1,019 plus
⚫ 100 FPs x $1,058
⚫ i.e. $2,549,300
⚫ What would be charge for 3,200 FPs?

47
 Example 1
The following set of requirements (for a Human Resources System) are to be
used to generate a high-level function point count for the size of the
required application software.

Requirements
The Human Resources System must provide three major business processes:
• Manage Employee Records,
• Manage Job Information,
• Manage Assignment Information.

Manage Employee Records

⚫ The system must be able to add, change and delete employee records.
The information to be maintained includes employee information, salary
information, and dependents' information. The location must be a valid
location in the Fixed Asset System. The hourly rate is retrieved by
accessing the Currency Application System, based on the current location
of the employee. It must be possible to inquire on all information about an
individual employee, using the employee-ID, and to retrieve a list of all
employees.
 Example 1… cont’d
Manage Job Information

The system must be able to add, change and delete job information, including
job title, number, pay grade, and description (a collection of free form text
lines). It must be possible to inquire on all information about a job, using the
job-number and to retrieve a list of all jobs.

Manage Assignment Information

The system must be able to capture and maintain job assignment information,
including employee-ID, effective date, salary and performance rating. It must
be possible to transfer an employee to different job assignments, and to delete
a job assignment for an employee. It must also be possible to inquire about an
individual assignment, using the employee-ID and the job-number and to
retrieve a list of all job assignments. There is also a need for a report listing the
employee and all locations for the employee, in paper copy.
 Example 2
A list of employees with their basic pay is sent to a
clerk. He calculates the gross pay using standard
allowances which are known for each pay slab.
Deduction statements such as loan repayment,
subscription to association, etc., are also sent to
another clerk who matches these details with the
details of gross pay and calculates net pay. This
data is used by a third clerk to print out pay
cheques for each employee and sent to the
respective employees. A salary report is also
generated and sent to the Accounts Dept.
 Story Points – Agile Methodology

⚫ A metric used in agile project management

⚫ to estimate the difficulty of implementing a
given story
⚫ Elements considered in assigning a story
point include
⚫ the complexity of the story,
⚫ the number of unknown factors and
⚫ the potential effort required to implement it.
 Examples of user stories
1. As a user, I want to upload photos so that I
can share photos with others.
2. As an administrator, I want to approve
photos before they are posted so that I can
make sure they are appropriate.
3. As a social media manager, I want to tag the
photos under specific categories so that I
can filter and search the photos for future
use.
 Three components of a
user story
⚫ Who- This is typically a job role, customer or
type of user, also known as the user persona.
⚫ What- This is the goal that the user wants the
product to accomplish or implement.
⚫ Why- This is the reason why the user needs
the feature or functionality.
⚫ The result is “As a <who>, I want <what> so
that <why>.”
 Project Sizing
⚫ Sizing is done considering

⚫ The amount of work to do

⚫ The complexity of the work
⚫ Risk or uncertainty in doing the work
⚫ Time / Duration
 Complexities
⚫ Difficulty could be related to complexities, risks, and
efforts involved.

⚫ In most cases a story point uses one of the following

scales for sizing:

⚫ 1,2,4,8,16

⚫ X-Small, Small, Medium, Large, Extra-Large ( known as “T-Shirt

Sizing”)

⚫ Fibonacci sequence: 1,2,3,5,8,13,21

 Measure Velocity
⚫ Velocity in Agile is a simple calculation
measuring units of work completed in a given
timeframe.
⚫ Velocity is a measure of the amount of work
a Team can tackle during a single Sprint and
is the key metric in Scrum.
⚫ Velocity is calculated at the end of the Sprint
by totaling the Points for all fully completed
 Software Non-Functional
Assessment Process (SNAP)
⚫ in order to:
⚫ Improve software cost & resource estimation;

⚫ improve productivity & quality measurement

⚫ build better benchmarks &

⚫ better communicate non-functional issues among

all stakeholders.
 Software Non-Functional
Assessment Process (SNAP)
⚫ SNAP measures the non-functional
requirements
⚫ Complementary to FP
⚫ Sizing process is very similar to the function
point sizing process
⚫ Has defined 31 non-functional characteristics