Software Measurement and Metrics

• Project Management is a discipline about planning, monitoring, and controlling

software projects, identifying the scope, estimating the work involved, and
creating a project schedule.
• Along with it is also responsible to keep the team up to date on the project’s
progress and handle problems and discuss solutions.
• Metrics:
• A metric is a measurement of the level at which any impute belongs to a system
product or process.
• There are 4 functions related to software metrics:
• Planning
• Organizing
• Controlling
• Improving
Project planning
• Once a project is found to be feasible and requirements specified in the
SRS, software project managers undertake project planning. Project
planning consists of the following essential activities:
• Estimating the following attributes of the project:
• Project size: What will be problem complexity in terms of the effort and time
required to develop the product?
• Cost: How much is it going to cost to develop the project?
• Duration: How long is it going to take to complete development?
• Effort: How much effort would be required?
• Scheduling manpower and other resources
• Staff organization and staffing plans
• Risk identification, analysis, and abatement planning
• Miscellaneous plans such as quality assurance plan, configuration
management plan, etc.
Estimation Model:
• Post Estimation
• Base Estimation
• Decomposition
• LOC (White Box)
• Function Point (Black Box)
• Empirical Model (Formula based)
Metrics for software project size estimation

• Accurate estimation of the problem size is fundamental to

satisfactory estimation of effort, time duration and cost of a software
project.
• The project size is a measure of the problem complexity in terms of
the effort and time required to develop the product.
• Currently two metrics are popularly being used widely to estimate
size:
• lines of code (LOC) and
• function point (FP).
Lines of Code (LOC)

• LOC is the simplest among all metrics available to estimate project

size.
• Using this metric, the project size is estimated by counting the
number of source instructions in the developed program.
• In order to estimate the LOC count at the beginning of a project,
project managers usually divide the problem into modules, and each
module into submodules and so on, until the sizes of the different
leaf-level modules can be approximately predicted.
 A line of code (LOC) is any line of text in a code that is not a comment or blank line, and also
header lines, in any case of the number of statements or fragments of statements on the line.
LOC clearly consists of all lines containing the declaration of any variable, and executable and
non-executable statements.

Features :
• Variations such as “source lines of code”, are used to set out a codebase.
• LOC is frequently used in some kinds of arguments.
• They are used in assessing a project’s performance or efficiency.
Advantages :
• Most used metric in cost estimation.
• Its alternates have many problems as compared to this metric.
• It is very easy in estimating the efforts.
Disadvantages :
• Very difficult to estimate the LOC of the final program from the problem specification.
• It correlates poorly with quality and efficiency of code.
• It doesn’t consider complexity.
void main() void selSort(int x[], int n) {
{ //Below function sorts an array in ascending order
int fN, sN, tN; int i, j, min, temp;
cout << "Enter the 2 integers: "; // Loop
cin >> fN >> sN; for (i = 0; i < n - 1; i++) {
// sum of two numbers in stored in variable sum min = i;
sum = fN + sN; //Nested Loop
// Prints sum for (j = i + 1; j < n; j++)
cout << fN << " + " << sN << " = " << sum; if (x[j] < x[min])
return 0; min = j;
} temp = x[i];
LoC= 11 or 9 x[i] = x[min];
x[min] = temp;
}
}
LoC= ?
Function point metrics
• Introduce by Alan Albrecht while working for IBM in1970s
• This metric overcomes the shortcoming of the LOC metric.
• In LOC metric size can be determine accurately only after the product
has fully been developed but in function point size can be determine
directly from program specification.
• Here the size of a software product is directly dependent on the
number of different function or features it supported. It also depend
on the number of the file and the interfaces.
• It is certain that a product support many features is larger in size than
a product with few features.
Steps to compute function point
• Beside using the number of the input and output data values function
point metric computes the size of a software product (in unit of
function points or FPs).
• The steps for computing function point-
• Count the number of functions of each proposed type.
• Compute the Unadjusted Function Points(UFP) (Using Table)

• Find Total Degree of Influence (TDI).

• Compute Value Adjustment Factor (VAF)/ Calculate Complexity Adjustment
Factor (CAF) = (TDI * 0.01) + 0.65

• Find the Function Point Count (FPC) = UFP * VAF

• Count the number of functions of each proposed type:
• Find the number of functions belonging to the following types:
• External Inputs: Functions related to data entering the system.
• External outputs: Functions related to data exiting the system.
• External Inquiries: They lead to data retrieval from the system but
don’t change the system.
• Internal Files: Logical files maintained within the system. Log files
are not included here.
• External interface Files: These are logical files for other applications
which are used by our system.
• Compute the Unadjusted Function Points(UFP):
• Categorize each of the five function types like simple, average, or
complex based on their complexity.
• Multiply the count of each function type with its weighting factor and
find the weighted sum. The weighting factors for each type based on
their complexity are as follows:
Type Simple Average complex
Input 3 4 6
Output 4 5 7
Inquiry 3 4 6
Number of files 7 10 15
Number of interfaces 5 7 10
• Find Total Degree of Influence: Use the ’14 general characteristics’ of a system to
find the degree of influence of each of them.
1. Reliable backup/recovery needed? 8. Are master files updated online?
2. Any data communications needed? 9. Are inputs, outputs, queries
3. Any distributed processing complex?
functions? 10. Is internal processing complex?
4. Performance critical? 11. Must code be reusable?
5. Will system run in an existing 12. Are conversion and installation
heavily utilized operational included in design?
environment? 13. Is multiple installations in different
6. Any online data entry? organizations needed in design?
7. Does online data entry need 14. Is the application to facilitate
multiple screens/operations? change and ease of use by user?

Each of the 14 criteria are given a rating of 0 to 5 as:

No Influence = 0; Incidental = 1;
Moderate = 2 Average = 3;
Significant = 4 Essential = 5
Summary
Function Point (FP) is an element of software development which helps to approximate the cost
of development early in the process. It may measures functionality from user’s point of view.
Step-1: Step-3: Calculate Unadjusted Function Point (UFP).
F = 14 * scale TABLE (Required)
Scale varies from 0 to 5 according to character of
Complexity Adjustment Factor (CAF). Below table
shows scale:
0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential

Step-2:
Calculate Complexity Adjustment Factor (CAF).
CAF = 0.65 + ( 0.01 * F ) Step-4: Calculate Function Point.
FP = UFP * CAF
Given the following values, compute function point when all complexity adjustment
factor (CAF) and weighting factors are average.

User Input = 50
User Output = 40
User Inquiries = 35
User Files = 6
External Interface = 4
Step-1: As complexity adjustment factor is average (given in question),
hence, scale = 3.
F = 14 * 3 = 42
Step-2:
CAF = 0.65 + ( 0.01 * 42 ) = 1.07
Step-3: As weighting factors are also average (given in question) hence we will
multiply each individual function point to corresponding values in TABLE.
UFP = (50*4) + (40*5) + (35*4) + (6*10) + (4*7) = 628
Step-4:
Function Point = 628 * 1.07 = 671.96
Example
• Example: Compute the function point, productivity, documentation,
cost per function for the following data:
• Number of user inputs = 24
• Number of user outputs = 46
• Number of inquiries = 8
• Number of files = 4
• Number of external interfaces = 2
• Effort = 36.9 p-m
• Technical documents = 265 pages
• User documents = 122 pages
• Cost = $7744/ month
• Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3,
2, 2, 4, 5.
• Assume weighing factor is high.
Solution
Software Project Cost Estimation
• Dr. Barry Boehm suggested that any software development project can be
classified into one of the following three categories based on the development
complexity: organic, semidetached, and embedded.
• Organic, Semidetached and Embedded software projects
• Organic (application): If the project deals with developing a well understood
application program, the size of the development team is reasonably small, and
the team members are experienced in developing similar types of projects. (e.g.
Management systems)
• Semidetached (utility): If the development consists of a mixture of experienced
and inexperienced staff. Team members may have limited experience on related
systems but may be unfamiliar with some aspects of the system being developed.
(e.g. Innovative projects )
• Embedded (system): If the software being developed is strongly coupled to
complex hardware, or if the stringent regulations on the operational procedures
exist. (e.g. robotics, ATM, aircraft, robotic arms)
COCOMO

• COCOMO (Constructive Cost Estimation Model) was proposed by

Boehm [1981]. According to Boehm, software cost estimation should
be done through three stages:
• Basic COCOMO,
• Intermediate COCOMO, and
• Complete COCOMO.
Basic COCOMO Model
• The basic COCOMO model gives an approximate estimate of the
project parameters.
• The basic COCOMO estimation model is given by the following
expressions:
Effort = a х (KLOC)b PM
Tdev = c x (Effort)d Months
• Where
• KLOC is the estimated size of the software product expressed in Kilo Lines of
Code,
• a, b, c, d are constants for each category of software products,
• Tdev is the estimated time to develop the software, expressed in months,
• Effort is the total effort required to develop the software product, expressed
in person months (PMs).
• Estimation of development effort
• For the three classes of software products, the formulas for
estimating the effort based on the code size are shown below:
• Organic : Effort = 2.4(KLOC) 1.05 PM
• Semi-detached : Effort = 3.0(KLOC) 1.12 PM
• Embedded : Effort = 3.6(KLOC) 1.20 PM
• Estimation of development time
• For the three classes of software products, the formulas for
estimating the development time based on the effort are given
below:
• Organic : Tdev = 2.5(Effort) 0.38 Months
• Semi-detached : Tdev = 2.5(Effort) 0.35 Months
• Embedded : Tdev = 2.5(Effort) 0.32 Months
Example:
1. Calculate development effort, duration and team size of an organic project, which is having
20KLOC.
2. Calculate development effort, duration and team size of an semidetached project, which is
having 20KLOC.
3. Calculate development effort, duration and team size of an Embedded project, which is having
20KLOC.

Solution for 1:

Development effort
DE=ab(KLOC)bb
2.4(20)1.05 = 55.75 pm

Development duration
DD=cb(Effort)db
2.5(55.75)0.38 = 11.52

Team Size = DE/DB

55.75/11.52 = 5
Constants
Answer
• Example:
• Assume that the size of an organic type software product has been
estimated to be 32,000 lines of source code. Assume that the average
salary of software engineers be Rs. 15,000/- per month. Determine
the effort required to develop the software product and the nominal
development time.
• From the basic COCOMO estimation formula for organic software:
Effort = 2.4 х (32)1.05 = 91 PM
Development time = 2.5 х (91)0.38 = 14 months
Cost required to develop the product = 14 х 15,000 = Rs. 210,000/-
Intermediate COCOMO
• In reality, no system’s effort and schedule can be solely calculated on the basis of Lines
of Code.
• For that, various other factors such as reliability, experience, Capability. These factors
are known as Cost Drivers and the Intermediate COCOMO utilizes 15 such drivers for
cost estimation.
• Product: The characteristics of the product that are considered include the inherent
complexity of the product, reliability requirements of the product, etc.
• Computer: Characteristics of the computer that are considered include the execution
speed required, storage space required etc.
• Personnel: The attributes of development personnel that are considered include the
experience level of personnel, programming capability, analysis capability, etc.
• Development Environment: Development environment attributes capture the
development facilities available to the developers. An important parameter that is
considered is the sophistication of the automation (CASE) tools used for software
development.
Development effort
DE=a(KLOC)b X EAF(Error Adjustment Factor)

No duration and team size will be calculated

Complete COCOMO
• A major shortcoming of both the basic and intermediate COCOMO
models is that they consider a software product as a single
homogeneous entity.
• Complete COCOMO incorporates all characteristics of the
intermediate version with an assessment of the cost driver’s impact
on each step of the software engineering process.
• The Complete COCOMO uses different effort multipliers for each cost
driver attribute.
• In detailed COCOMO, the whole software is divided into different
modules and then we apply COCOMO in different modules to
estimate effort and then sum the effort.
Metrics for Software Quality
• Software Quality Assurance (SAQ) assures the quality of the software. Set of
activities in SAQ are continuously applied throughout the software process.
• Software Quality is measured based on some software quality metrics.
• There are few most useful metrics which are most essential in software quality
measurement. They are –
• Code Quality
• Reliability
• Performance
• Usability
• Correctness
• Maintainability
• Integrity
• Security
Decomposition Techniques
• The Project Estimation Approach that is widely used is Decomposition
Technique. Decomposition techniques take a divide and conquer
approach. Size, Effort and Cost estimation are performed in a
stepwise manner by breaking down a Project into major Functions or
related Software Engineering Activities.
• Software Sizing : size refers to a quantifiable outcome of the
software project. If a direct approach is taken, size can be
measured in LOC. If an indirect approach is chosen, size is
represented as FP.
• Process-Based decomposition
• Problem-Based decomposition
THE MAKE/BUY DECISION

•Software engineering managers are faced with a make/buy

decision that can be further complicated by a number of
acquisition options:
• (1) software may be purchased (or licensed) off-the-shelf,
• (2) “full-experience” or “partial-experience” software components
may be acquired and then modified and integrated to meet
specific needs, or
• (3) software may be custom built by an outside contractor to meet
the purchaser's specifications.
•The steps involved in the acquisition of software are defined by
the criticality of the software to be purchased and the end cost.
•The following guidelines can be applied:
1. Develop specifications for function and performance of the desired
software. Define measurable characteristics whenever possible.
2. Estimate the internal cost to develop and the delivery date.
3. Select three or four functionalities that best meet your specifications.
4. Select reusable software components that will assist in constructing
the required application.
5. Develop a comparison matrix that presents a head-to-head
comparison of key functions.
In the final analysis, the make/buy decision is made based
on the following conditions:
1. Will the delivery date of the software product be sooner than
that for internally developed software?
2. Will the cost of acquisition plus the cost of customization be less
than the cost of developing the software internally?
3. Will the cost of outside support (e.g., a maintenance contract) be
less than the cost of internal support? These conditions apply for
each of the acquisition options.
4. Evaluate each software package or component based on past
product quality, vendor support, product direction, reputation,
and the like.
5. Contact other users of the software and ask for opinions.
Creating a Decision Tree

• For example, a decision tree for a software based system, X. In this

case, the software engineering organization can
1. build system X from scratch,
2. reuse existing “partial-experience” components to construct the
system,
3. buy an available software product and modify it to meet local
needs, or
4. contract the software development to an outside vendor.
The expected value for cost, computed along any branch of the decision tree, is

The expected costs for these paths are

Based on the probability and projected costs, the lowest expected cost is the
"buy" option.