Software
estimation
metrics
Module-03
THE MANAGEMENT SPECTRUM
Software project management is an art and
discipline of planning and supervising software
projects.
Software project management involves -
• planning,
• implementation,
• monitoring, and
• controlling the people, process, and events that
occur.
Effective software project management
focuses on the four P’s: People, Product,
Process, and Project.
The People
The people who participate in the software
process are
1) The Stakeholders -
a. Senior managers
b. Project (technical) managers
c. Practitioners (Technical Skill)
d. Customers
e. End users
2) Team Leaders
3)The Software Team
B. The Product
1. Software Scope
-Context-
-Information objectives-
-Function and performance-
2. Problem decomposition
C. The Process
A software process provides the
framework from which a comprehensive
plan for software development can be
established.
D. The Project
Inorder to manage a successful software
project, you have to understand what
can go wrong so that problems can be
avoided.
SOFTWARE PROCESS AND
PROJECT METRICS
Measurement can be used throughout a
software project to assist in
• estimation,
• quality control,
• productivity assessment, and
• project control.
Process Metrics and Software
Process Improvement
Project metrics enable a software project
manager to
(1) assess the status of an ongoing project,
(2) track potential risks,
(3) uncover problem areas before they go
“critical”,
(4) adjust work flow or tasks, and
(5) evaluate the project team’s ability to control
quality of software work products.
Project Metrics
SOFTWARE MEASUREMENT
• direct measures (e.g., the length of a bolt)
and
• indirect measures (e.g., the “quality” of
bolts produced, measured by counting
rejects).
SOFTWARE MEASUREMENT
Direct measures –
lines of code (LOC) produced
execution speed
memory size
defects reported over some set period of
time.
SOFTWARE MEASUREMENT
Indirect measures –
Functionality
Quality
Complexity
Efficiency
Reliability
maintainability
Process, project, and product metrics are
considered as software metrics.
Two software metrics-
1. Size-Oriented Metrics
2. Function-Oriented Metrics
1. SIZE-ORIENTED METRICS
Direct measures of the software product.
lines of code developed (LOC)
efforts required in person-months (pm)
cost of development
pages of documentation developed (Pp. Doc.)
errors recorded before release
defects encountered after release to the customer
people worked on the development of software
for project
Example in table format
In order to develop metrics that can be
compared with similar metrics from other
projects, lines of code (LOC) is chosen as
a normalization value.
Errors per KLOC (thousand lines of code)
Defects per KLOC
Rs per KLOC
Pages of documentation per KLOC
2. FUNCTION-ORIENTED
METRICS
The most widely used function-oriented metric
is the function point (FP).
FP metric can be used to
1. estimate the cost or effort required to design,
code, and test the software;
2. predict the number of errors that will be
encountered during testing; and
3. forecast the number of components and/or
the number of projected source lines in the
implemented system.
Information domain values
used in function points are-
To use function point methods
• determine complexity of product,
• complexity of project can be simple,
average, or complex, and
• for each complexity level, weights
(multiplying values) have been
experimentally determined
To compute function points (FP), the
following equation is used:
where count total is the sum of all FP
entries obtained from table.
The Fi (i = 1 to 14) are value adjustment
factors (VAF).
Fi is based on responses to the
14 questions
1. Does the system require reliable backup and recovery?
2. Are specialized data communications required to transfer
information to or from the application?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational
environment?
6. Does the system require online data entry?
7. Does the online data entry require the input transaction to
be built over multiple screens or operations?
8. Are the ILFs updated online?
9. Are the inputs, outputs, files, or inquiries
complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in
the design?
13. Is the system designed for multiple
installations in different organizations?
14. Is the application designed to facilitate
change and ease of use by the user?
To calculate Fi, each of these questions is
answered using a scale that ranges from 0 to
5 as
• 0 - not important,
• 1 – incidental,
• 2 – moderate,
• 3 – average,
• 4 – significant, and
• 5 – essential.
EXAMPLE-1
Calculate function point (FP) value for an
inventory system that needs to
– ‘Add a record’
– ‘Delete a record’,
– ‘Display a record’,
– ‘Edit a record’, and
– ‘Print a record’.
A system maintains one internal data file with all
records.
Σ(Fi) is given as 23.
Solution-
From given data, the information domain
value parameters can be determined as
• external outputs (EO) - 1
• external inquiry (EQ) - 1
• internal files (ILF) - 1
• external interfaces (EIF) - 0
• external inputs (EI) - 3
Considering“Average” complexity for
project, Count_total can be calculated
as
FP is calculated as
Other metrics can be
computed
• Productivity = FP/ Effort (effort is measured in
person-months)
• Errors/FP
• Cost (₹)/FP
• Defects/FP
• Pages of documentation/FP
• Errors/PM
• Cost (₹)/Page of Documentation
