Why do we Measure?

• assess the status of an ongoing project

• track potential risks
• uncover problem areas before they go “critical,”
• adjust work flow or tasks,
• evaluate the project team’s ability to control quality of software work
products.
Software Metrics
• Software Metrics are quantitative measurements used to assess
various aspects of a software product, the development process, and
the overall project. These metrics provide valuable information to
evaluate software development's quality, performance, and progress.
• Software metrics is a standard of measure that contains many
activities which involve some degree of measurement.
• Also it is a measure with software characteristics(quality of
s/w,quantity..etc) which are quantifiable and countable.
• Software metrics are important for measuring software performance
,planning work item,measuring productivity, debugging and
estimating cost.this component imp for dev and dev team leader.
Software Measurement
• Software measurement is indicator of size , quantity amount or
dimension of particular attribute of a product or process.
• It helps project manager and entire software team to make decision
that lead to successful completion of the project by generating
quantity result.
• Direct measure
• Indirect measure
Classification of Software Metrics

• There are three types of software metrics in software

engineering: product metrics, process metrics, and project metrics.
Product metrics are used to define product attributes such as
size, design features, complexity, performance, level of quality, and
so on. In contrast, process metrics are used to optimize software
development and maintenance. Project metrics, such as the number
of software developers, cost, and so on, indicate the project's
characteristics and performance.
process process
Measurement
product product
project
Product Metrics
Product Metrics focus on measuring the characteristics and
quality of the software product itself. They help us understand how
well the software performs and whether it meets the desired
requirements. Some standard product metrics include:
1. Defect Density: This metric indicates the number of defects (bugs or errors)
found in the software per lines of code or function points. It helps identify the
software's reliability and stability.
2. Code Coverage: It measures the percentage of code that has been tested by the
software's automated tests. Better code coverage leads to improved performance
and reduces the chances of untested code causing issues.
3. Response Time: This metric evaluates how quickly the software responds to
user inputs or requests. Lower response time indicates better performance and
user experience.
• Product metrics represent product attributes such as
size, complexity, design features, performance, and quality level. A
working product is created at the end of each successive phase of
the software development process. At any step of development, a
product can be measured. Metrics are built for these items to
determine whether a product is being developed in accordance with
user requirements. If a product fails to satisfy consumer
expectations, the relevant steps are made in the appropriate phase.
Product metrics assist software engineers in detecting and correcting
possible issues before they cause catastrophic failures.
Process Metrics
• Process Metrics focus on measuring the effectiveness and efficiency of the
software development process itself. They help in identifying areas where
the development process can be improved for better productivity and
quality. Some common process metrics include:
• 1. Cycle Time: It measures the time taken to complete a specific task or
user story from the beginning to the end. Shorter cycle times indicate
better efficiency in the development process.
• 2. Defect Removal Efficiency (DRE): This metric evaluates how effective the
development process is at finding and fixing defects during testing. Higher
DRE implies a more robust testing process.
• 3. Code Review Effectiveness: It assesses how well code reviews catch
defects and improve code quality. Regular and effective code reviews lead
to better code and reduced errors.
• To improve any process, it is important to measure its defined
properties, establish a set of meaningful metrics based on these
attributes, and then utilize these metrics to generate indicators to
develop a process improvement strategy.
• Software engineers can measure the performance of a software
process that is executed using the process as a framework by
utilizing software process metrics.
• The process is at the center of the triangle that connects three
aspects (product, people, and technology) that significantly impact
software quality and organizational performance.
• People's competence and motivation, the complexity of the product,
and the level of technology utilized in software development all
significantly impact quality and team performance.
Project Metrics

• Project Metrics focus on measuring the progress and success of the entire
software development project. They help in tracking the project's status,
budget, and overall health. Some common project metrics include
• 1. Schedule Variance (SV): It measures the difference between the planned
schedule and the actual progress of the project. Positive SV indicates the
project is ahead of schedule, while negative SV indicates delays.
• 2. Cost Performance Index (CPI): This metric assesses the cost efficiency of
the project by comparing the budget spent with the work completed.
• 3. Defect Arrival Rate: It measures the rate at which defects are identified
during the testing phase. Tracking this metric helps in understanding the
defect trend over time.
• Project metrics explain the characteristics and execution of a project.
Examples include the number of software developers, the staffing
pattern throughout the software's life cycle, cost, schedule,
and productivity. The project manager monitors the project's
progress using measures known as project metrics. Various metrics,
such as time, cost, and so on, are collected using data from previous
projects and utilised as an estimate for the new initiative.
• The project manager monitors the project's progress on a regular
basis, and effort, time, and cost are compared to the initial effort,
time, and cost. These indicators can help lower development costs,
efforts, hazards, and time. The project's quality can also be improved.
• With an improvement in quality, there is a decrease in the number of
errors, time, cost, and so on.
• Types of Software Metrics
• Internal metrics: Internal metrics are used to measure properties
that are deemed more important to a software developer than the
users. Lines of Code (LOC) is one example.
• External metrics: External metrics are used to measure features that
are deemed more important to the user than the software
developers, such as portability, reliability, functionality, usability,
and so on.
• Hybrid Metrics: Metrics that mix product, process, and resource
metrics are known as hybrid metrics. Cost per FP is an example,
where FP stands for Function Point Metric.
• Characteristics of Software Metrics
• Software metrics in software engineering should possess the following
characteristics:
• It I simple and computable
• Quantitative: Metrics must be quantitative in order to be helpful. It means
that metrics can be stated numerically.
• Understandable: Metric computation should be simple to grasp, and the
method for computing them should be well explained.
• Applicability: Metrics should be applied during the early stages
of software development.
• Repeatable: When measured regularly and consistently in nature, the
metric values should be the same.
Use consistent unit measurement. Easy to calibrate and adaptable.
• Economical: Metric computation should be cost-effective.
• Language agnostic: Metrics should be language-independent, meaning
their computation should not depend on any programming language.
• Need for Software Metrics
• Software metrics in software engineering can be used for a variety of
purposes, including analyzing software performance, planning work
items, estimating productivity, and so on.
• For example, you can use software metrics to monitor performance,
plan upcoming work tasks, track productivity, and better regulate the
production process throughout project management if you can view
distinct statistics and trends as production takes place.
• You can also use software metrics in conjunction with management
functions to simplify your projects by building more efficient
procedures, creating software maintenance plans, and keeping
production teams updated on issues that need to be resolved.
• Software metrics are needed for various reasons, including the
following:
• By preventing faults, it is possible to save money.
• Aids in the improvement of overall project planning
• Aids in the advancement of overall project planning

• Encourages eagerness to improve processes

• Aids in a more thorough analysis of the dangers involved.
• Aids in studying indicators at each testing stage to increase problem
eradication efficiency.
• Increases the ROI of test automation over time
• Improves the relationship between testing coverage, risks,
and system complexities.
Software measurement principles
Project Estimation
• project estimation is a complex process that revolved around
predicting the time, cost, and scope that a project requires to be
deemed finished.
• But in terms of software development or software engineering, it also
takes the experience of the software outsourcing company, the
technique they have to utilize, the process they need to follow in
order to finish the project (Software Development Life Cycle).
• Project Estimation requires the use of complex tools & good
mathematical as well as knowledge about planning.
The four basic steps in software project estimation are:
1) Estimate the size of the development product. This generally ends up in either
Lines of Code (LOC) or Function Points (FP), but there are other possible units of
measure. A discussion of the pros & cons of each is discussed in some of the
material referenced at the end of this report.
2) Estimate the effort in person-months or person-hours.
3) Estimate the schedule in calendar months.
4) Estimate the project cost in dollars (or local currency
Key elements of software project
• Cost: Determine the financial resources needed to complete the
project.
• Time: Estimate the overall project duration and individual task
timelines.
• Scope: Define the project’s boundaries and deliverables.
• Risk: Identify potential risks and develop mitigation strategies.
• Resources: Assess the required human, technological, and financial
resources.
• Quality: Determine the desired level of quality and standards to be
met.
Estimation take place
• Software project estimation is crucial throughout the project
lifecycle. In waterfall methodologies, estimates are typically conducted
during the initial planning phase.
• In agile methodologies, estimation may occur at the beginning of each
iteration or sprint.
Cost
• 1. While managing software project, cost is one of the three primary
constraints. The project will fail if you do not have sufficient funds to
complete it.
• You can help set client expectations and ensure you have enough money
to complete the work if you can accurately estimate project costs early on.
• Estimating software development costs entails determining how much
money you’ll need and when you’ll need it.
Time
• Another of the project’s three main constraints is the lack of time. It
is critical for project planning to be able to estimate both the overall
project duration and the timing of individual tasks.
• You can plan for people and resources to be available when you need
them if you estimate your project schedule ahead of time. It also
enables you to manage client expectations for key deliverables.
Size or Scope
• The third major project constraint is scope. The project scope refers
to all of the tasks that must be completed in order to complete the
project or deliver a product.
• You can ensure that you have the right materials and expertise on
the project by estimating how much work is involved and exactly
what tasks must be completed.
• Three sides of a triangle are often used to describe the three main
constraints. This is because any changes to one constraint will
inevitably have an effect on the other two.
• You need to know the scope and schedule to accurately estimate the
budget. If one of the three estimates turns out to be higher or lower
than you anticipated, the other two are likely to be off as well.
• An accurate estimate of the size of the software to be built is the first step to an
effective estimate.
• Your source(s) of information regarding the scope of the project should,
wherever possible, start with formal descriptions of the requirements –
• for example, a customer’s requirements specification or request for proposal, a
system specification, a software requirements specification.
• If you are [re-]estimating a project in later phases of the project’s lifecycle,
design documents can be used to provide additional detail.
• Don’t let the lack of a formal scope specification stop you from doing an initial
project estimate. A verbal description or a whiteboard outline are sometimes all
you have to start with.
• In any case, you must communicate the level of risk and uncertainty in an
estimate to all concerned and you must re-estimate the project as soon as more
scope information is determined
• Estimating effort Once you have an estimate of the size of your product, you can
derive the effort estimate. This conversion from software size to total project
effort can only be done if you have a defined software development lifecycle and
development process that you follow to specify, design, develop, and test the
software.

• A software development project involves far more than simply coding the
software – in fact, coding is often the smallest part of the overall effort. Writing
and reviewing documentation, implementing prototypes, designing the
deliverables, and reviewing and testing the code take up the larger portion of
overall project effort.
• The project effort estimate requires you to identify and estimate, and then sum
up all the activities you must perform to build a product of the estimated size.
• There are two main ways to derive effort from size: 1) The best way is to use your
organization’s own historical data to determine how much effort previous projects of the
estimated size have taken.
assumes
• (a) your organization has been documenting actual results from previous projects,
• (b) that you have at least one past project of similar size (it is even better if you have
several projects of similar size as this reinforces that you consistently need a certain level
of effort to develop projects of a given size), and
• (c) that you will follow a similar development lifecycle, use a similar development
methodology, use similar tools, and use a team with similar skills and experience for the
new project.
• 2) If you don’t have historical data from your own organization because you haven’t
started collecting it yet or because your new project is very different in one or more key
aspects, you can use a mature and generally accepted algorithmic approach such as
Barry Boehm’s COCOMO model
• or the Putnam Methodology to convert a size estimate into an effort estimate. These
models have been derived by studying a significant number of completed projects from
various organizations to see how their project sizes mapped into total project effort.
These “industry data” models may not be as accurate as your own historical data, but
they can give you useful effort estimates
• Estimating schedule The step in estimating a software development
project is to determine the project schedule from the effort estimate.
• This generally involves estimating the number of people who will
work on the project, what they will work on (the Work Breakdown
Structure), when they will start working on the project and when they
will finish (this is the “staffing profile”).
• Once you have this information, you need to lay it out into a calendar
schedule. Again, historical data from your organization’s past projects
or industry data models can be used to predict the number of people
you will need for a project of a given size and how work can be
broken down into a schedule.
To understand scope
• Understand the customers needs
• understand the business context
• understand the project boundaries
• understand the customer’s motivation
• understand the likely paths for change
• understand that ...
What is Scope?
• Software scope describes
• the functions and features that are to be delivered to end-users
• the data that are input and output
• the “content” that is presented to users as a consequence of using the
software
• the performance, constraints, interfaces, and reliability that bound the
system.
• Scope is defined using one of two techniques:
• A narrative description of software scope is developed after communication with all stakeholders.
• A set of use-cases is developed by end-users.
Risk
• Any unforeseen event that could positively or negatively impact your
project is referred to as project risk. Estimating risk entails predicting
what events will occur during the project’s life cycle and how serious
they will be.
• You can better plan for potential issues and create risk management
plans if you estimate what risks could affect your project and how
they will affect it.
Resources
• Resources
• The assets you’ll need to complete the project are known as project
resources. Tools, people, materials, subcontractors, software, and
other resources are all examples of resources. Resource management
ensures that you have all of the resources you require and make the
best use of them.
• It’s challenging to plan how you’ll manage resources without knowing
what you’ll need and when. This can result in people sitting around
doing nothing or materials arriving weeks after you need them.
Quality
• Quality is concerned with the completion of project deliverables.
Products that must adhere to stringent quality standards, such as
environmental regulations, may require more money, time, and other
resources than those with lower standards.
• Estimating the level of quality required by the customer aids in the
planning and estimating the remaining five aspects of your
project. Because all six project factors are interconnected, forecasts
for one can have an impact on forecasts for the other five.
Estimation Techniques
• Past (similar) project experience
• Conventional estimation techniques
• task breakdown and effort estimates
• size (e.g., FP) estimates
• Empirical models
• Automated tools
Project Accuracy
the degree to which the planner has properly estimated the size of the
product to be built
the ability to translate the size estimate into human effort, calendar
time, and dollars
the degree to which the project plan reflects the abilities of the
software team
the stability of product requirements and the environment that
supports the software engineering effort.
Steps of software project Estimation
software size estimation
Line of code
declaration,actual code including logic ane computation
LOC is the simplest among all metrics available to estimate project size.
this metrics is very popular bcz it is simplest to use.
Using this metrics ,the project size estimate by counting the number of
source instruction in developed program.
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.
As Lines of Code (LOC) only counts the volume of code, you can
only use it to compare or estimate projects that use the same
language and are coded using the same coding standards.
The line of code (LOC) metric is any line of text in a code that is not
a comment or blank line, in any case of the number of statements or
fragments of statements on the line.
LOC consists of all lines containing program header files,
declaration of any variable, and executable and non-executable
statements.
As Lines of Code (LOC) only counts the proportion of code, you can
only utilize it to compare or estimate projects that utilize the same
language and are programmed using the same coding standards.
void selSort(int x[], int n) {
//Below function sorts an array in ascending order
int i, j, min, temp;
for (i = 0; i < n - 1; i++) {
min = i;
for (j = i + 1; j < n; j++)
if (x[j] < x[min])
min = j;
temp = x[i];
x[i] = x[min];
x[min] = temp;
}
}
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.
Function point
Function points measure the size of an application system based on
the functional view of the system.
The size is determined by counting the number of inputs, outputs,
queries, internal files and external files in the system and adjusting
that total for the functional complexity of the system.
Function point analysis, originally developed at IBM, has as an
advantage its focus on measuring software produced in terms of
functionality delivered to the end user, rather than in terms of
development deliverables, which have no direct bearing on the end
user.
Function point analysis
3

2
14)Facilitate change