Software Metrics

A metric is a measurement of the level at which any impute belongs to a system product or process.

Software metrics are a quantifiable or countable assessment of the attributes of a software product.
There are 4 functions related to software metrics:

 Planning
 Organizing
 Controlling
 Improving

Characteristics of software Metrics

 Quantitative: Metrics must possess a quantitative nature. It means metrics can be expressed in
numerical values.
 Understandable: Metric computation should be easily understood, and the method of
computing metrics should be clearly defined.
 Applicability: Metrics should be applicable in the initial phases of the development of the
software.
 Repeatable: When measured repeatedly, the metric values should be the same and consistent.
 Economical: The computation of metrics should be economical.
 Language Independent: Metrics should not depend on any programming language.

Types of Software Metrics

 Product Metrics: Product metrics are used to evaluate the state of the product, tracing risks and
undercover prospective problem areas. The ability of the team to control quality is evaluated.
Examples include lines of code, cyclomatic complexity, code coverage, defect density, and code
maintainability index.
 Process Metrics: Process metrics pay particular attention to enhancing the long-term process of
the team or organization. These metrics are used to optimize the development process and
maintenance activities of software. Examples include effort variance, schedule variance, defect
injection rate, and lead time.
 Project Metrics: The project metrics describes the characteristic and execution of a
project. Examples include effort estimation accuracy, schedule deviation, cost variance, and
productivity. Usually measures-
 1. Number of software developer
2. Staffing patterns over the life cycle of software
3. Cost and schedule
4. Productivity

Advantages of Software Metrics

 Reduction in cost or budget.

 It helps to identify the particular area for improvising.
 It helps to increase the product quality.
 Managing the workloads and teams.
 Reduction in overall time to produce the product,.
 It helps to determine the complexity of the code and to test the code with resources.
 It helps in providing effective planning, controlling and managing of the entire product.

Disadvantages of Software Metrics

 It is expensive and difficult to implement the metrics in some cases.

 Performance of the entire team or an individual from the team can’t be determined. Only the
performance of the product is determined.
 Sometimes the quality of the product is not met with the expectation.
 It leads to measure the unwanted data which is wastage of time.
 Measuring the incorrect data leads to make wrong decision making.

Process Metrics

 Process Metrics are the measures of the development process that create a body of software. A
common example of a process metric is the length of time that the process of software creation
tasks.
 Based on the assumption that the quality of the product is a direct function of the process,
process metrics can be used to estimate, monitor, and improve the reliability and quality of
software. ISO- 9000 certification, or "Quality Management Standards", is the generic reference
for a family of standards developed by the International Standard Organization (ISO).
 Often, Process Metrics are tools of management in their attempt to gain insight into the creation
of a product that is intangible. Since the software is abstract, there is no visible, traceable
artifact from software projects. Objectively tracking progress becomes extremely difficult.
Management is interested in measuring progress and productivity and being able to make
predictions concerning both.
 Process metrics are often collected as part of a model of software development. Models such
as Boehm's COCOMO (Constructive Cost Model) make cost estimations for software projects.
The boat's COPMO makes predictions about the need for additional effort on large projects.
 Although valuable management tools, process metrics are not directly relevant to program
understanding. They are more useful in measuring and predicting such things as resource usage
and schedule.

Halstead’s Software Metrics – Software Engineering

Halstead’s Software metrics are a set of measures proposed by Maurice Halstead to evaluate the
complexity of a software program. These metrics are based on the number of distinct operators and
operands in the program and are used to estimate the effort required to develop and maintain the
program. These metrics provide a quantitative assessment of software complexity, aiding in software
development, maintenance, and quality assurance processes. They include measures such as program
length, vocabulary, volume, difficulty, and effort, calculated based on the number of unique operators
and operands in a program. Halstead’s metrics help developers understand and manage software
complexity, identify potential areas for optimization, and improve overall software quality.

Structure of COCOMO Model

Detailed 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 .
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.
The Six phases of detailed COCOMO are:
1. Planning and requirements: This initial phase involves
defining the scope, objectives, and constraints of the
project. It includes developing a project plan that outlines
the schedule, resources, and milestones
2. System design: : In this phase, the high-level architecture
of the software system is created. This includes defining
the system’s overall structure, including major components,
their interactions, and the data flow between them.
3. Detailed design: This phase involves creating detailed
specifications for each component of the system. It breaks
down the system design into detailed descriptions of each
module, including data structures, algorithms, and
interfaces.
4. Module code and test: This involves writing the actual
source code for each module or component as defined in
the detailed design. It includes coding the functionalities,
implementing algorithms, and developing interfaces.
5. Integration and test: This phase involves combining
individual modules into a complete system and ensuring
that they work together as intended.
6. Cost Constructive model: The Constructive Cost Model
(COCOMO) is a widely used method for estimating the cost
and effort required for software development projects.
1. Planning and requirements: This initial phase involves
defining the scope, objectives, and constraints of the
project. It includes developing a project plan that outlines
the schedule, resources, and milestones
2. System design: : In this phase, the high-level architecture
of the software system is created. This includes defining
the system’s overall structure, including major components,
their interactions, and the data flow between them.
3. Detailed design: This phase involves creating detailed
specifications for each component of the system. It breaks
down the system design into detailed descriptions of each
 module, including data structures, algorithms, and
interfaces.
4. Module code and test: This involves writing the actual
source code for each module or component as defined in
the detailed design. It includes coding the functionalities,
implementing algorithms, and developing interfaces.
5. Integration and test: This phase involves combining
individual modules into a complete system and ensuring
that they work together as intended.
6. Cost Constructive model: The Constructive Cost Model
(COCOMO) is a widely used method for estimating the cost
and effort required for software development projects.

Types of COCOMO models

The COCOMO model is divided into three types based on the

accuracy quotient.Any of the three types can be adapted according
to our requirements:

 Basic model
 Intermediate model
 Detailed model

Basic model

The basic model is used for quick and rough cost calculations for the
software. It calculates the effort, time, and number of people
required to use a project's kLOC (kilo lines of code).

The formulae to calculate these entities are:

Effort(E)=a(kLOC)bEffort(E)=a(kLOC)b
Time(T)=c(E)dTime(T)=c(E)d
People required=ETPeople required=TE
The effort is measured in person-months and time in months. The
constants a,b,c,and da,b,c,and d vary for each model type. The
following are the constant values for the basic model:

Project Type a b c d
Organic 2.4 1.0 2.5 0.38
5
Semi-detached 3.0 1.1 2.5 0.35
2
Embedded 3.6 1.2 2.5 0.32
0

Example

Suppose a project was estimated to be made in 400 kLOC. Lets

calculate its effort, time, and the number of people required while
considering the project is of organic type:

Effort(E)=2.4(400 kLOC)1.05=1295.31 person−monthsEffort(E)=2.4(400 kLOC)1.05=1295.3

1 person−months
Time(T)=2.5(1295.31)0.38=30.07 monthsTime(T)=2.5(1295.31)0.38=30.07 months
People required=1295.3130.07=43.07 personsPeople required=30.071295.31=43.07 pe
rsons

Intermediate model

The intermediate model is an extension of the basic model and

includes a set of cost drivers to calculate the estimates with better
accuracy. The effort factor includes the effort adjustment factor
(EAF) that is calculated with the cost drivers.

The formulae to calculate these entities are:

Effort(E)=a(kLOC)b∗EAFEffort(E)=a(kLOC)b∗EAF
Time(T)=c(E)dTime(T)=c(E)d

The effort is measured in person-months and time in months. The

constants a,b,c,and da,b,c,and d vary for each model type. The
following are the constant values for the basic model:

Project Type a b c d
Organic 3.2 1.0 2.5 0.38
5
Semi-detached 3.0 1.1 2.5 0.35
2
Embedded 2.8 1.2 2.5 0.32
0

Cost drivers

The cost drivers and their attributes are as follows:

Product attributes

The product attributes are as follows:

 Required software reliability extent

 Size of the application database
 The complexity of the product
Product Very Low Lo Nominal High Very High Extra High
Attributes w
RELY 0.75 0.88 1.00 1.15 1.40 ...
DATA ... 0.94 1.00 1.08 1.16 ...
CPLX 0.70 0.85 1.00 1.15 1.30 1.65
Hardware attributes

The hardware attributes are as follows:

 Run time performance constraints

 Memory constraints
 The volatility of the virtual machine environment
 Required turnabout time
Hardware Attributes Very L Low Nomina High Very High Extra High
ow l
TIME ... ... 1.00 1.11 1.30 1.66
STOR ... ... 1.00 1.06 1.21 1.56
VIRT ... 0.87 1.00 1.15 1.30 ...
TURN ... 0.87 1.00 1.07 1.15 ...

Personal attributes

The personal attributes are as follows:

 Analyst capabilities
 Software engineering capabilities
 Applications experience
 Virtual machine experience
 Programming language experience
Personal attributes Very Low Low Nominal High Very High Extra High
ACAP 1.46 1.19 1.00 0.86 0.71 ...
AXEP 1.29 1.13 1.00 0.91 0.82 ...
PCAP 1.42 1.17 1.00 0.86 0.70 ...
VEXP 1.21 1.10 1.00 0.90 ... ...
LEXP 1.14 1.07 1.00 0.95 ... ...
Project attributes

The project attributes are as follows:

 Use of software tools

 Application of software engineering methods
 Required development schedule
Project Very Low Low Nominal High Very High Extra High
Attributes
MODP 1.24 1.10 1.00 0.91 0.82 ...
TOOL 1.24 1.10 1.00 0.91 0.83 ...
SCED 1.23 1.08 1.00 0.04 1.10 ...

The EAF is calculated by multiplying the parameter values of

different cost driver attributes. Ideally, the value is 1.

Example

Suppose a project was estimated to be made in 400 kLOC.let's

calculate its effort, time, and the number of people required while
considering the project is of organic type and has a nominal
complexity. The developer has a high virtual machine experience.

The value of the nominal complexity of a project is 1.00, and the

high virtual experience of the developer is 0.90, according to the
tables mentioned above:

EAF=1.00∗0.90=0.9EAF=1.00∗0.90=0.9
Effort(E)=3.2(400 kLOC)1.05∗0.9=1554.37 person−monthsEffort(E)=3.2(400 kLOC)1.05∗0.
9=1554.37 person−months
Time(T)=2.5(1554.37)0.38=40.80 monthsTime(T)=2.5(1554.37)0.38=40.80 months
People required=1554.3740.80=38.09 personsPeople required=40.801554.37=38.09 pe
rsons

Detailed model

The detailed model is a combination of both the basic model and the
intermediate model. The model is decomposed into multiple
modules, and the COCOMO model is applied to them individually.
This model uses various effort multipliers for each cost driver
attribute, and the cost is calculated at each stage separately.

The six stages of the detailed model are as follows:

 Planning and requirements

 System design
 Detailed design
 Module code and test
 Integration and test
 Cost constructive model
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
consists of all lines containing the declaration of any variable, and
executable and non-executable statements.

Features of Lines of Code (LOC)

 Change Tracking: Variations in LOC as time passes can
be tracked to analyze the growth or reduction of a
codebase, providing insights into project progress.
 Limited Representation of Complexity: Despite LOC
provides a general idea of code size, it does not accurately
depict code complexity. It is possible for two programs
having the same LOC to be incredibly complex.
  Ease of Computation: LOC is an easy measure to obtain
because it is easy to calculate and takes little time.
 Easy to Understand: The idea of expressing code size in
terms of lines is one that stakeholders, even those who are
not technically inclined, can easily understand.
Advantages of Lines of Code (LOC)
 Effort Estimation: LOC is occasionally used to estimate
development efforts and project deadlines at a high level.
Although caution is necessary, project planning can begin
with this.
 Comparative Analysis: High-level productivity comparisons
between several projects or development teams can be
made using LOC. It might provide an approximate figure of
the volume of code generated over a specific time frame.
 Benchmarking Tool: When comparing various iterations of
the same program, LOC can be used as a benchmarking
tool. It may bring information on how modifications affect
the codebase’s total size.
Disadvantages of Lines of Code (LOC)
 Challenges in Agile Work Environments: Focusing on initial
LOC estimates may not adequately reflect the iterative and
dynamic nature of development in agile development, as
requirements may change.
 Not Considering Into Account External Libraries: Code from
other libraries or frameworks, which can greatly enhance a
project’s overall usefulness, is not taken into account by
LOC.
 Challenges with Maintenance: Higher LOC codebases are
larger codebases that typically demand more maintenance
work.