Table of Contents
hide
Introduction
- Software metrics and models are important concepts and play a crucial role in software engineering; they are used to measure, evaluate, assess objectives, estimate, control, and improve software products and software-development processes.
- Software metrics models enable better planning, control, and continuous improvement in software development.
- Software metrics are collected and are finally used in Software metrics models to estimate or predict development effort, cost, quality, reliability, and schedule.
Definition
- Software metrics are quantitative measures used to evaluate, control, and improve the software development process and the quality of software products. They help managers and developers make informed decisions, estimate effort and cost, monitor progress, and improve software quality.
- Software metrics refer to numerical measures that quantify characteristics of software, software processes, and software products. In other words, a software metric is used to determine the degree to which a software system, component, process, or project possesses or completes a particular characteristic.
Characteristics
- Software metrics are numerical measurements used to evaluate software quality, size, complexity, productivity, cost, performance, and development progress. For example –
Number of lines of code = 20,000
Number of defects = 50
Development effort = 12 person-months
Testing coverage = 85%
- Software Metrics provide a scientific and objective way to assess software development activities instead of relying on intuition.
Objectives
- Software metrics are used to:
- Estimate software size, development cost, development effort, and development time.
- Measure or assess software quality and reliability.
- Determine program complexity.
- Measure programmer/team productivity.
- Monitor project progress and productivity.
- Identify defects and problem areas.
- Improve software-development processes.
- Compare actual project performance with planned performance.
- Support project-management decisions.
- Estimate maintenance requirements.
- To support decision-making and risk management
Types of Software Metrics
Software metrics are commonly classified into –
- Process metrics
- Product metrics
- Project metrics.
Process Metrics
- Process metrics are used to measure the effectiveness and efficiency of the software development process.
- These metrics help organizations to improve the way software is developed. In other words, these metrics help organizations understand how well their development processes are performing and identify areas for improvement.
- Product metrics help assess the quality and performance of the software itself.
- Characteristics of Process Metrics
- Focus on how software is developed
- Help in process improvement
- Support better project planning and control
- Examples/Terms/Work done in Process Metrics
- Defect Removal Efficiency (DRE): It measures how effectively defects are removed during development.
- Process Yield: It gives the percentage of defects detected before software release.
- Cycle Time: It is the time required to complete a development phase.
- Productivity Metrics: It is the output produced per unit of effort (e.g., function points per person-month).
Productivity= Software Size/Development Effort
For example: 10,000 LOC/5 Person-Months =2,000 LOC/Person-Month
-
- Review and Inspection Effectiveness: It measures the success of code and design reviews.
- Average time required to fix a defect
- Number of defects discovered during testing
- Testing effectiveness
- Development-cycle time
- Importance of Process Metrics
- Improve development efficiency
- Reduce rework and development cost
- Enhance the predictability of schedules
- Support continuous process improvement
Product Metrics
- Product metrics measure the characteristics of the software product itself.
- These metrics help evaluate the quality, performance, and maintainability of the final software system.
- Characteristics of Product Metrics
- It focuses on what is being developed
- It is applied to both intermediate and final products
- It is used to assess software quality
- Examples/Terms/Work done in Product Metrics
- Size Metrics: Lines of Code (LOC), Function Points (FP)
- LOC measures the approximate size of software by counting the number of source-code lines.
- LOC is simple, but it depends strongly on the programming language and coding style.
- Function Point Analysis measures software size based on the functionality provided to the user rather than simply counting source-code lines. It considers features such as:
- External inputs
- External outputs
- External inquiries
- Internal logical files
- External interface files
- Program Complexity/Complexity Metrics: Cyclomatic Complexity
- Size Metrics: Lines of Code (LOC), Function Points (FP)
-
-
- Cyclomatic complexity measures the logical complexity of a program based on its control-flow structure. A commonly presented formula is:
-
V(G)=E−N+2P
where:
E = number of edges in the control-flow graph
N = number of nodes
P = number of connected components (often 1 for a single program/module)
-
-
- Higher cyclomatic complexity generally indicates more independent execution paths and potentially more testing/maintenance effort.
-
-
- Quality Metrics: Defect density (defects per KLOC/Number of defects)
- Defect density measures defects relative to software size.
- Quality Metrics: Defect density (defects per KLOC/Number of defects)
Defect Density=Number of Defects/Software Size
For example, if software contains 20 defects in 10 KLOC: 20/10=2
So the defect density is: 2 defects/KLOC.
-
- Reliability Metrics: Mean Time to Failure (MTTF)
- Maintainability Metrics: Code modularity and documentation quality
- Performance Metrics: Response time, throughput, memory requirements
- Execution speed
- Code coverage
- Importance of Product Metrics
- It helps in assessing software quality
- It supports maintenance and enhancement decisions
- It improves software reliability and usability
- It enables comparison between different software versions.
Project Metrics
- Project metrics are concerned with the management and progress of a software project.
- A project manager can use these measurements to determine whether a project is running according to schedule and budget.
- Examples/Terms/Work done in Project Metrics:
- Project cost
- Development effort
- Number of developers
- Project duration
- Schedule variance
- Budget variance
- Productivity
- Number of completed tasks
- Number of unresolved defects
Software Metrics(Measurement) Model
- A software measurement model is a simplified mathematical, conceptual, or empirical representation used to provide structured ways to understand, estimate, analyze, control, and predict software attributes such as size, cost, effort, time, and quality during the development of a project or software system.
- A software model is a simplified mathematical, conceptual, or empirical representation used to understand, estimate, predict, or control some aspect of a software system or development project.
-
Software Models can be used for estimating:Cost → Effort → Schedule → Reliability → Quality → Performance
- Examples of some common Software Measurement Models
LOC (Lines of Code)Metrics/Model
-
LOC (Lines of Code) is a software size metric used to measure the size of a software product by counting the lines of source code.
-
LOC represents the number of lines of source code written to develop a software product.
-
It is one of the simplest and oldest software metrics and is often used in software project estimation(estimating software effort), productivity measurement, cost estimation, defect density, and quality analysis.
- LOC is simple to use but is programming-language dependent and difficult to estimate accurately before coding begins.
- Depending on the counting convention, we may count only the actual executable/declaration statements of the code and exclude blank lines and comments.
-
LOC is commonly expressed as:LOC = Lines of CodeKLOC = Thousand Lines of Code
-
Types of LOC
-
There are two common ways of counting LOC.
-
Physical LOC
-
It counts the actual physical lines appearing in the source code file.
- Physical LOC measures source lines.
-
For example:int a;int b;int c = a + b;This example contains 3 physical lines of code.
-
-
Logical LOC
-
It counts executable statements or logical instructions rather than physical lines.
- Logical LOC measures programming statements.
-
For example:int a; int b; int c = a + b;It is physically one line, but contains 3 logical statements.
-
-
-
-
Important Metrics based on LOCLOC can be used to calculate several other software metrics.-
-
ProductivityProductivity=LOC/EffortorProductivity=KLOC/Person–Months
-
Cost per LOCCost per LOC=Total Development Cost/LOC
-
Defect DensityDefect Density=Number of Defects/KLOC
-
Documentation DensityA simple documentation measure may be expressed as:Documentation Density= Documentation Lines/LOCIt gives an indication of the amount of documentation relative to program size.
-
- Advantages of LOC Metrics
- LOC is simple and easy to understand.
-
LOC model is easy to calculate after coding.
- It provides a quantitative measure of software size.
- It can be used to calculate productivity.
- It helps calculate defect density.
- It can assist in cost and effort estimation.
- Historical LOC data can help estimate similar future projects.
- It is useful after the program has been developed because the actual LOC can be counted accurately.
-
Disadvantages of LOC Metrics
-
LOC is programming-language dependent.
-
It is difficult to estimate accurately during the early stages of a project.
-
Different programmers can solve the same problem using very different numbers of lines of source code.
-
More LOC does not necessarily mean better software.
-
It may indirectly reward programmers for writing longer code.
-
Reusable libraries, frameworks, and generated code can make LOC comparisons misleading.
-
It is difficult to compare productivity across languages.
-
-
Function Point (FP)Metrics/Model
-
- Function Point was introduced by Allan J. Albrecht at IBM in 1979.
- This model also measures software size, but based on functionality (what the software does)provided to the user by the prepared software.
- A Function Point (FP) is a unit used to measure the functional size of a software system from the user’s point of view.
- Function Point is largely independent of the programming language and is useful for estimating software size, effort, cost, and productivity.
-
Function Point measurement considers five types of software functions:
Component – Abbreviation – Description – Example
-
-
-
External Input – EI – Data entering the system – User Registration form.
-
External Output – EO – Information produced by the system – Result report.
-
External Inquiry – EQ – Request that retrieves information – Search student.
-
Internal Logical File – ILF – Data maintained within the system – Student master data.
-
External Interface File – EIF – External data used by the system – External university database
-
- Each function is classified into three ranges: Low, Average, or High complexity.
- Use of Function Point: It can be used to estimate:
- Software size
- Development effort
- Development cost
- Development time
- Programmer productivity
- Project resources
- Productivity can be measured as:
-
Productivity=Function Points/Person-Months
COCOMO (Constructive Cost Model)Metrics/Model
-
-
COCOMO model estimates effort(person used per months), development time, staffing, and cost based on software size and complexity.
-
It was developed by Barry Boehm and is used to estimate software-development effort and schedule based on software size and other project characteristics.
-
The original COCOMO model is commonly distinguished into three levels.
-
Basic COCOMO
-
This level uses mainly software size (KLOC) and development mode to estimate effort and schedule. It is simple but does not consider many detailed project characteristics.
-
-
Intermediate COCOMO
-
This level adds cost drivers to the basic size-based calculation. Cost drivers represent characteristics related to the product, hardware/computer environment, personnel, and project.
-
-
Detailed COCOMO
-
This level extends the intermediate approach by considering the influence of cost drivers across different phases of the software-development life cycle.
-
-
-
-
-
The original COCOMO distinguishes three project modes:
-
Organic Mode: This mode is for relatively small and straightforward projects developed by experienced teams in familiar environments.
-
Semi-detached Mode: This mode is for intermediate projects involving a mixture of experience levels and moderate complexity.
-
Embedded Mode: In this mode, projects are developed under strong hardware, software, operational, or regulatory constraints.
-
-
The basic effort equation of Basic COCOMO is generally expressed as:
-
E=a(KLOC)b
where,
E = effort in person-months
KLOC = thousands of lines of source code
a, b = constants depending on project mode/type of software project
And development time is estimated using:
D=c(E)d
where,
D = development time
E = estimated effort
c, d = model constants
Halstead’s Software Science Metrics/Model
-
- Halstead’s Software Science, also called Halstead Complexity Metrics, is a set of software metrics developed by Maurice Howard Halstead in 1977.
- The basic idea of this model is that a computer program can be studied by counting the operators and operands used in its source code to estimate program complexity and effort.
- Halstead’s Software Science is a software measurement technique developed by Maurice Halstead that measures program complexity using the number of distinct and total operators and operands. From these basic measures, metrics such as program vocabulary, length, volume, difficulty, effort, programming time, and estimated defects can be calculated.
- This model measures the size, complexity, difficulty, programming effort, development time, and possible errors of a program by analyzing its operators and operands.
- Halstead defines four fundamental measures:
Symbols – Meaning
n1 – Number of distinct operators
n2 – Number of distinct operands
N1 – Total occurrences of operators
N2 – Total occurrences of operands
-
- For example, we consider a C program:
c = a + b;
In the above equation, operators are = and +, therefore
n1=2
Operands are: c, a, b; therefore
n2=3
Since each appears once
N1=2, N2=3
Thus, using these four basic values, we can calculate the remaining Halstead metrics, which are explained below:
(i) Program Vocabulary(n)
-
-
- Program vocabulary is the total number of distinct operators and distinct operands.
-
n=n1+n2
For the above example: n=2+3=5
(ii) Program Length(N)
-
-
- Program length is the total number of occurrences of operators and operands.
-
N=N1+N2
For the example: N=2+3=5
(iii) Estimated Program Length(N^)
Halstead proposed that program length can also be estimated as:
N^=n1log2n1+n2log2n2
(iv) Program Volume(V)
Program Volume represents the amount of information contained in the program.
V=Nlog2n
(v) Program Difficulty(D)
Difficulty indicates how difficult the program is to understand or implement.
D=(n1/2)*(N2/n2)
(vi) Programming Effort(E)
Programming effort represents the mental effort required to develop or understand the program.
E=D*V
(vii) Programming Time(T)
Halstead estimated the programming time in seconds as:
T=E/18
(viii) Estimated Number of Bugs(B)
A commonly taught Halstead formula for estimated delivered bugs is:
B=V/3000
-
- Advantages
- Halstead metrics are relatively easy to calculate from source code and provide quantitative measures of program size and complexity.
- They can be used to compare modules, estimate programming effort, identify relatively complex code, and support software quality analysis.
- Limitations
- The metrics depend heavily on how operators and operands are defined and counted for a particular programming language.
- They also do not directly consider program structure, control-flow complexity, programmer experience, modern frameworks, reusable components, or code quality.
- Advantages
Putnam Model
-
- The Putnam model is another mathematical software cost and effort estimation model used to estimate the software size, software effort, development time, staffing, and cost required to develop a software project.
- It was developed by Lawrence H. Putnam and is based on the observation that the staffing/effort pattern of a software project often follows the concept of the Rayleigh distribution/Rayleigh Staffing Curve.
- This model uses a Rayleigh distribution to represent the staffing pattern over the software development life cycle, which assumes that manpower does not remain constant throughout the project development. Typically, in the beginning – few people; as development progresses, Staff increases; in the peak development period – Maximum staff; and as the project approaches completion – Staff decreases.
Thus, Putnam considers the distribution of manpower over the entire software development life cycle, rather than simply assuming the same team size throughout. - The model is also associated with the SLIM (Software Life-Cycle Management) estimation approach.
- The Putnam Model establishes a relationship among software size, development effort, Technology/productivity level, development time, etc.
- An important feature of the model is that reducing development time substantially can cause a large increase in the required development effort.
- It is particularly concerned with the relationship between:
Software Size + Development Time + Development Effort = Project Estimation
-
- A commonly used Putnam form of the software equation is:
S=Ck * E1/3 *td4/3
where
S = software size, usually in LOC
E = total development effort, usually in person-years
td = development time in years
Ck = technology/productivity constant
The equation shows that software size depends on both effort and development time.
-
- Advantages
- It is useful for large software projects.
- It estimates effort and development schedule together.
- It considers the relationship between time and manpower.
- It uses the Rayleigh curve to represent staffing changes.
- It helps study the effect of schedule compression.
- It can support long-term project planning and resource allocation.
- Limitations
- It requires reliable historical information for calibration.
- Software size must be estimated reasonably well.
- The productivity/technology constant can be difficult to determine.
- It is less suitable for very small projects.
- Actual staffing patterns do not always follow a Rayleigh curve closely.
- Estimates can change considerably when the input parameters are inaccurate.
- Advantages
Delphi Method Model
-
- The Delphi Model is an expert-based software estimation technique in which several experts independently estimate project/software cost, development effort, software development time, or resources, project risks, and other factors, and repeatedly revise their estimates using summarized feedback until an acceptable consensus is reached.
- In this method, several experts independently provide their estimates. Their estimates are collected and summarized, and the experts are then allowed to revise their estimates. This process continues until a reasonable consensus is reached.
- The main idea of this model is to obtain estimates independently from several experts and repeatedly refine them until the estimates move toward a reasonable consensus.
-
Wideband Delphi
-
Wideband Delphi is a variation of the Delphi technique commonly discussed in software engineering.
-
In the traditional Delphi method, communication between experts is relatively controlled and anonymous. In Wideband Delphi, experts have more opportunity to discuss assumptions and estimation issues together before revising their estimates. This can be particularly useful in software projects because experts may have different interpretations of the requirements.
-
- How the Delphi Model Works: The process generally works as follows:
- Select Experts: A group of experienced software developers, analysts, project managers, or domain specialists is selected.
- Provide Project Information: Each expert receives information about the proposed software project, including requirements, size, complexity, technology, and constraints.
- Independent Estimation: Each expert independently estimates the required effort, cost, development time, or other required parameter.
- Collect Estimates: A coordinator collects all estimates without allowing one expert to dominate the others.
- Summarize Results: The estimates and reasons for major differences are summarized and shared with the experts, often anonymously.
- Revise Estimates: Experts reconsider the information and submit revised estimates.
- Repeat the Process: The estimation rounds continue until the estimates converge sufficiently or an agreed stopping criterion is reached.
- Final Estimate: The resulting consensus or appropriately combined estimate is used for project planning.
- Advantages
- The Delphi technique reduces the influence of dominant individuals because estimates are generally collected independently and feedback can be anonymous.
- It makes use of the knowledge of multiple experts, is useful when historical project data is limited, and can be applied to cost, effort, schedule, risk, and other estimates.
-
It uses the experience of multiple experts.
-
It reduces dependence on a single estimator.
-
It is useful when sufficient historical project data is unavailable.
-
It is particularly useful for new or complex software projects.
- Limitations
- Its accuracy depends heavily on the quality and experience of the selected experts.
- Several estimation rounds may make the process time-consuming, and consensus does not guarantee that the final estimate will be correct.
-
Quality depends on the knowledge and experience of the experts.
-
Several rounds can make the process time-consuming.
-
Selecting appropriate experts can be difficult.
-
Results can still contain subjective judgment.
-
Poor or incomplete project requirements can produce inaccurate estimates.
-
Consensus does not necessarily guarantee that the final estimate is correct.
Software Reliability Models
-
- Software reliability models attempt to estimate or predict the probability of software operating without failure for a specified period under specified conditions.
- They can use information such as:
- Number of failures
- Failure occurrence times
- Testing time
- Defect discovery/removal
- Operational usage
- Reliability measurements can include MTTF (Mean Time To Failure) and failure rate.
Quality Models
-
- Software quality models organize important characteristics used to evaluate software quality.
- Quality models help developers and organizations systematically evaluate whether software meets required quality objectives.
- Some common characteristics of this model are:
- Functional suitability
- Reliability
- Performance efficiency
- Usability
- Security
- Maintainability
- Compatibility
- Portability
0 Comments