CIS210: Software Engineering and Development
Project Management Metrics
1. Measuring Software
The software metrics are quantitative measures that enable software
engineers to gain insight into the efficacy of the software process.
In order to apply the metrics for estimation of the software quality
and productivity data are collected and next analyzed.
Software metrics are analyzed and assessed by the software managers.
The software engineers are responsible for collecting the data, for
producing and collecting the measures.
Software measurement is important as it helps to identify trends in the
engineering process with which true improvements can be made over time,
without relying on subjective judgements.
Reasons for measuring the software:
-
to indicate the quality of the product
-
to assess the productivity of the people
-
to assess the benefits from the new methods
-
to form a baseline for estimation
-
to help justify the needs for new tools
The first application of project metrics occurs during project estimation.
Metrics collected from past projects are used as a basis from which effort
and time duration estimates are made for the current software work.
The project manager uses these measures to monitor and control progress
in the following ways:
- to minimize the development schedule by making adjustments
necessary to avoid delays and mitigate risks;
- to assess the software quality on an on-going basis and modify
the technical approach to improve the quality.
During the software evolution additional metrics are collected to assess
the design quality and to provide indicators that will influence the
approach taken to code generation and testing.
2. Direct and Indirect Software Metrics
The direct software metrics are:
- lines of code
- memory size
- defects reported over a period of time
The indirect software metrics are:
- functionality
- quality
- complexity
- efficiency
- reliability
- maintainability
3. Size-Oriented Metrics
Size-oriented metrics are derived by normalizing the productivity
measures considering the size of software that has been produced.
Productivity = KLOC / person-month,
where:
KLOC- thousand lines of code
Quality = defects / KLOC
Cost = $ / KLOC
Documentation = pages of documentation / KLOC
4. Function-Oriented Metrics
Function-oriented metrics use as a normalization value
the functionality delivered by the application.
Since the functionality can not be measured directly, estimates
called function points are derived based on countable information in
the software domain and assessments of the software complexity.
Five information domain characteristics are determined as follows:
- number of user inputs: each user input provides distinct application data;
- number of user outputs: each output provides different information to the
user, like reports, screens and messages;
- number of user inquiries: these are on-line inputs that require immediate
response from the software program;
- number of files: each file is counted;
- number of external interfaces: all machine readable interfaces are counted.
Function points are computed according to the following equation:
FP = count-total  [ 0.65 + 0.01  SUM( Fi ) ]
where: count-total is the sum of all FP entries obtained
Fi - are complexity adjustment values
Productivity = FP / person-month,
Quality = defects / FP
Cost = $ / FP
Documentation = pages of documentation / FP
Example: Perform software project estimation using the FunctionPoints
metric, assuming the following software information domain characteristics:
Measurement parameter
count
factor
number of user inputs
number of user outputs
number of user inquiries
number of files
number of external interfaces
20
15
28
5
3
4
5
5
10
7
Suppose that the software complexity adjustment factors are as follows:
Complexity adjustment
value (Fi)
Backup and recovery
Data communications
Distributed processing
Performance critical
Existing operating environment
On-line data entry
Input transaction over multiple screens
Master files updated on-line
Information domain values complex
Internal processing complex
Code designed for reuse
Conversion/installation in design
Multiple installations
5
4
2
5
3
3
5
2
4
5
3
4
5
Application designed for change
5
a) Estimated number of function points
FPest = count-total  [ 0.65 + 0.01  SUM(Fi) ]
FPest = 366  [ 0.65 + 0.01  55 ] = 439.2
b) Productivity of the team for 3 person-months using the derived function points
Productivity = FPest / person-month
Productivity = 439.2 / 3 = 146.4 [function points per person month]
c) Quality of this software having 5 defects using the derived function points
Quality = defects / FPest
Quality = 5 / 439.2 = 0.011 [defects per function point]
d) Software cost using the derived function points if there have been spend 3000 pounds
Cost = $ / FPest
Cost = 3000 / 439.2 = 6.83 [pounds per function point]
e) Documentation size using these function points if 100 pages have been produced
Documentation = pages of documentation / FPest
Documentation = 100 / 439.2 = 0.228 [pages per function point]
5. Extended Function Point Metrics
A number of extensions to the basic function-point measure have been
proposed to make it more adequate for systems engineering applications.
The feature-point measure is a superset of the basic function-point measure
especially for application requiring complex software.
The feature-point measure count another software characteristic: algorithms
in addition to the basic information domain characteristics.
The 3D Function Points Measure
This measure has been developed to provide a language independent
estimate that emphasizes on functional and control program capabilities.
The 3D Function Points Measure accounts for software characteristics
from the following three dimensions:
 data dimension- counts retained data
 quantified dimension- considers the number of internal operations
required to transform input to output data
 transformed dimension- it is measured by counting the number of
transitions between the internal system states
The 3D Function Points Measure is defined with the equation:
3Dindex = I + O + Q + F + E + T + R
where the concrete weighted complexity values are as follows:
I - inputs
O - outputs
Q - inquiries
F - internal data structures
E - external files
T - transformations
R - transitions
Exach of these values is weighted in the following way:
weighting = NilWil + NiaWia + NihWih
where: N is number of occurrences of the i-th element
W are the corresponding weights
the second indices are complexities: low, medium, high
Web Resources:
Function Point Frequently Asked Questions (FAQ)
http://ourworld.compuserve.com/homepages/softcomp/
NASA Software Technology Research Program
http://www.ivv.nasa.gov/publications/stp/index.shtml