SOFTWARE METRICS

Definition
Areas of application
Problem during implementation
Size metrics
Basic information flow model
Metric analysis: using statistics for Assessment
Flow problems with metric data
• Managers need quantifiable information, not subjective information
 Why Metrics????
Measurement is fundamental to any engineering discipline
Software metrics: broad range of measurements for computer software.
• can be applied on software process, project and software product for continuous improvement.

1. To measure size of s/w

2. To find/predict cost to develop a software
3. Expected bugs and when we can stop testing?
4. Complexity of module, cohesion, coupling, fan-in, fan-out
5. Reliability at time of release
6. Which test technique is more effective?
7. To find “Are we testing hard or smart????”
8. When can we release the s/w.
9. Required for effective management. Managers need quantifiable information, and not subjective information.
10. To indicate quality of product.
11. To assess productivity of people who produce the product.
12. To assess the benefits derived from new s/w engg. Methods and tools
13. To form a baseline for estimation.
14. To help justify requests for new tools or additional training.

Note: Neglect of measurement in s/w engg. Means unclear objectives, unclear costs, not evidence for new technologies etc.
If you want to compare 2 different things, you need to measure.
Measurement helps us distinguish different things.
• Ex: person is taller than other or person is heavier than other.

• Quality is quantified in terms of values after measurement.

• When you can measure what you are speaking about and can express it in
numbers, means you know something about it.
• All engineering disciplines have metrics (such as metrics for weight,
density, wavelength, pressure and temperature) to quantify various
characteristics of their products.
• Let, I am using 10 classes to achieve some solution and somebody
else may use 3 classes and somebody else may use 5 classes; which 1
is better?
• You can’t say if I use lesser no. of classes, I have better design or if I
use too many classes, I have better design.
• Solution: use some measure that should link s/w metrics to goals.
 s/w Metrics:

• Any measurement which relates to a software system, process, or related documentation.

• Allow the software and the software process and s/w project to be quantified.
• Continuous application of measurement based techniques to s/w development process and its products to improve that
process and it’s products.
• SM are all about measurements which in turn involve numbers to make things better, well managed and to improve process of
developing s/w.
• It covers techniques for monitoring and controlling the progress of s/w development.
• Software metrics are important for many reasons, including measuring software performance, planning work items, measuring
productivity, and many other uses
• Software Metrics is a collective term used to describe the very wide range of activities concerned with measurement in software
engineering
• Measurement is the process by which numbers are assigned to attributes of entities in the real world in such a way as to describe
them according to clearly defined unambiguous rules
• measure of software characteristics which are quantifiable or countable,
including measuring software performance, planning work items,
measuring productivity, and many other uses.
Software Requirements Metrics :
1. Function Points
Count number of inputs and output, user interactions, external interfaces, files used.
Assess each for complexity and multiply by a weighting factor.
Used to predict size or cost and to assess project productivity.

2. Number of requirements errors found (to assess quality)

3. Change request frequency

To assess stability of requirements.
 Frequency should decrease over time. If not, requirements analysis may not have been
done properly.
Software Design Metrics
• Number of parameters
• Tries to capture coupling between modules.
• Understanding modules with large number of parameters will require more time and effort.
• Modifying modules with large number of parameters likely to have side effects on other modules.

• Number of modules.
• Number of modules called (estimating complexity of maintenance).
Fan-in: number of modules that call a particular module.
Fan-out: how many other modules it calls.
High fan-in means many modules depend on this module.
High fan-out means module depends on many other modules.
Makes understanding harder and maintenance more time-consuming

• Determine how many independent paths of the module go through the different statements.
- If a module has high cohesion, most of variables will be used by statements in most paths.
- Highest cohesion is when all the independent paths use all the variables in the module.
Programmer Productivity Metrics
Common measures:
• Lines of source code written per programmer month.
• Pages of documentation written per programmer month.
• Test cases written and executed per programmer month.
• Take total number of source code lines delivered and divide by total
time required to complete project.
Object oriented metrics:

1. Class
2. Object
3. Inheritance
4. Polymorphism
5. Abstraction
6. Data binding
3 Metric Types:
1. Direct Measurement
– easy to collect. Eg length of source code, cost, effort, execution speed, memory size, defects reported or duration
of testing process. (These measurement activities involve no other attributes or entities)
2. Indirect/Derived Measurement –
Eg Module defect density = Number of defects/ Module Size. (These are combinations of other measurements)
More difficult to assess & can be measured indirectly only.
Quality, Functionality, Complexity, Reliability, Efficiency, Maintainability etc.
3. Predictive Measurement
– predict effort required to develop software from the measure of its functionality – function point count. (These
measurements are systems consisting of mathematical models together with a set of prediction procedures for
determining unknown parameters and interpreting results)
2 different project teams are working to record errors in a software process.
• Team A: finds 387 errors during s/w process before release.
• Team B: finds 181 errors
Q. Which team do you think is more effective in finding errors??
goal of metrics
• to improve product quality and development-team productivity
• concerned with productivity and quality measures
· measures of SW development output as function of effort and time
· measures of usability
· way to improve any process is to measure specific attributes of the process, develop a set of meaningful
metrics based on these attributes, and then use the metrics to provide indicators that will lead to a strategy
for improvement.

Factors that influence quality:

• people - skills and experience of SW people
• technology - used in development (e.g. CASE)
• product complexity
• process - glue that ties it all together
 Areas of application
It’s applicable to whole development life cycle.

1. Most significant area: Cost and size estimation techniques.

There are many proprietary packages on market that will provide estimates of software system size, cost to develop a system and
duration of a development or enhancement project.
These packages are based on estimation models, the best known of these being the Constructive Cost Model (COCOMO), developed
by Barry Boehm, and subsequently updated based on the experiences of many companies and individuals.
Attempt to estimate costs early in the development process:
– Cocomo
– Function Points
2. Controlling s/w development project, process &product through measurement
3. Prediction of quality levels for s/w design, in terms of reliability, maintainability, usability.
Again, there are proprietary models on the market that can assist with this but debate continues about the accuracy of these.
Design quality metrics like cohesion,coupling,complexity, reliability etc concerned with measuring s/w design, which correlates
with quality.
4. To provide quantitative checks on s/w design, requirements, testing and maintenance.
Much research has been carried out, and some organizations have used such techniques to very good effect. 
5. Used to control s/w products, s/w tools, s/w processes which are in place and are subject to enhancement.
 Areas of application
6. Used to provide management information.
This includes information about productivity, quality and process effectiveness. It’s an ongoing activity.
Snapshots of the current situation have their place, but the most valuable information comes when you can see trends in data.
Check Is productivity or quality getting better or worse over time? If so, then why is this happening?
What can management do to improve things?
Statistical analysis is part of it but the information must be presented in a way that managers can make use of, at the right time and for the right
reasons.

Metrics are an important component of quality assurance, management, debugging, performance, and estimating costs, and they’re valuable for
both developers and development team leaders:
• Managers can use software metrics to identify, prioritize, track and communicate any issues to foster better team productivity. This enables
effective management and allows assessment and prioritization of problems within software development projects. The sooner managers can
detect software problems, the easier and less-expensive the troubleshooting process.
• Software development teams can use software metrics to communicate the status of software development projects, pinpoint and address issues,
and monitor, improve on, and better manage their workflow.

7. Benchmarking: extremely popular area of Software Metrics, especially for senior managers.
Using measured quantities to compare your own organization with others
Can compare existing s/w processes.

8. Building Quality models and Performance evaluation models

• Different types of metrics available in s/w industry:
Common software measurements include:
•Bugs per LOC(line of code)
•Code coverage
•Cohesion
•Comment density
•Constructive Cost Model
•Coupling
•Cyclomatic complexity (McCabe's complexity): path coverage
•DSQI (design structure quality index)
•Function Points 
•Number of classes and interfaces
•Number of loc
•Number of lines of customer requirements
•Program execution time
•Program load time
•Program size
• Lead time: quantifies how long it takes for ideas to be developed and delivered as software
• Cycle time: describes how long it takes to change the software system and implement that change in production.
• Production metrics:  attempt to measure how much work is done and determine efficiency of s/w development teams.
• Active days: measure of how much time a software developer contributes code to the software development project. This
does not include planning and administrative tasks. 
• Efficiency: measure the amount of productive code contributed by a software developer.
Amount of churn shows the lack of productive code. So s/w developer with a low churn could have highly efficient code.
• Code churn represents number of LOC that were modified, added or deleted in a specified period of time. If code churn
increases, then it could be a sign that the software development project needs attention.
• Security metrics: These metrics need to be tracked over time to show how s/w development teams are developing security responses.
• Impact: measures effect of any code change on software development project. A code change that affects multiple files
could have more impact than a code change affecting a single file.
Mean time between failures (MTBF) and mean time to recover/repair (MTTR)
Both metrics measure how the software performs in the production environment. Since software failures are almost
unavoidable, these software metrics attempt to quantify how well the software recovers and preserves data.
• Mean time to repair (MTTR): measures time from the security breach discovery to when a working remedy is deployed.
• Size-oriented metrics: focus on size of software and are usually expressed as KLOC. It’s a easy software metric to collect,
but it’s not useful for comparing software projects written in different languages.
Better size metric examples:
Errors per KLOC
Defects per KLOC
Cost per KLOC
• Function-oriented metrics: focus on how much functionality software offers. But functionality cannot be measured
directly. So function-oriented software metrics rely on calculating the function point (FP) — a unit of measurement that
quantifies the business functionality provided by the product.
Function points are also useful for comparing software projects written in different languages.

• Cyclomatic Complexity :
It measures the control flow of a program (if, while, for, etc.) This metric is related to understandability
Mean Time to Recovery refers to average time that a device will take to recover from any failure.

Mean Time to Repair is a measure of how long it takes to get a product or subsystem up and running after a failure.  
Metrics list over
1. process - used to develop the SW
2. project - specific SW development project
3. product - SW produced
• Product is like ‘ready to use solution’ which is built by the company and sold to different customers.
• General e.g.: Purchasing a flat after construction is completed – In this case You can only do minor changes
like paints and interiors.
• Examples: Google products like Gmail, Drive (Free sources) and Oracle products like Databases etc

• Project is ‘taking requirements from customer to build a solution’. The requirements are gathered from a
particular client.
• General e.g.: Purchasing a flat before construction. You can construct it as per your guidelines and
requirement.
• Examples: Banking projects like ICICI, HDFC 
 Categories of metrics(3PS)
1. Product metrics: Describes characteristics of product such as size, complexity,
design, performance, fuctionality,usability,maintainability,efficiency, reliability,
portability, no. of pages of documentation produced etc.
1. Internal algorithmic complexity
2. Complexity of s/w design
3. Size of final program
4. Architectural complexity
5. Data flow complexity
6. No of pages of documentation produced

• Measure of s/w product at any stage of its development, from requirements to

installed system.
2. Process metrics: measures effectiveness and quality of processes that produce s/w products.
Ex:
A. Effort required in process.
B. Time to produce product.
C. Effectiveness of defect removal during development.
D. Number of defects found during testing process, defect rate by module.
E. Maturity of process
F. Error Categorization and Analysis: All errors and defects are categorized by origin, cost to correct
each error and defect is recorded, number of errors and defects in each category is computed.
G. Data is analyzed to find categories that result in highest cost to the organization
H. Type of Methodology
Aim: s/w process improvement
Metrics collected across all projects and over long period of time
We measure effectiveness of s/w process indirectly
1. Errors uncovered before release of s/w
2. Defects reported by end user
3. Human effort expended, calendar time expended, conformance to schedule

To improve any process, rational way is:

• Measure specific attributes of process
• Derive meaningful metrics from these attributes
• Use these metrics to provide indicators
• Indicators lead to a strategy for improvement
3. Project metrics: Describe project characteristics and execution to monitor and control the project.
Used by a project manager and software team to adapt project work flow and technical activities.
EX:
A. Number of s/w developers
B. Staffing pattern over life cycle of s/w
C. Cost,effort,size and schedule of project
D. Productivity
• Purpose: Minimize development schedule by making the necessary adjustments to avoid delays and risks.
• Metrics:
- Effort or time per SE task
- Errors uncovered per review hour
- Scheduled vs. actual milestone dates
- Number of changes and their characteristics
- Distribution of effort on SE tasks

Some metrics belong to multiple categories like quality metric may belong to all 3 categories.
 Problem during
1. Lack of management commitment: 
implementation
Sometimes management is not committed towards using software metrics due to the following reasons
1) Management opposes measurement.
2) Software engineers do not measure and collect data as management does not realize their importance.
3) Management charters a metrics program, but does not assist in deploying the program into practice.

Management don’t run risk of having too much data and not enough emphasis on s/w metrics that help deliver useful software to customers.

2. Most metrics are indirect: No way to measure property directly. Moreover, Final product does not yet exist
As software is intangible, not possible to measure directly.

3. Measuring too much and too soon: 

In a software project, sometimes excess data is collected in advance, which is difficult to manage and analyze. This results in unsuccessful
implementation of the metrics.

4. Data accuracy : Collecting non-useful data may increase problems

 Collecting incorrect data results leads to wrong decision making, which in turn leads to deviation from software development plan.
Don’t collect unnecessary data. Questions to be answered should be decided in advance and the required data identified.
Collect data when it is generated, not after a project has finished and, if possible, automatically.
5. Measuring the wrong things: 
Establishing metrics is a time consuming process and only those data that provide valuable feedback should be measured in an
effective and efficient manner
1. Do data items collected relate to the key success strategies for business?
2. Are managers able to obtain the information they need to manage projects and people on time?
3.  Is it possible to conclude from data obtained that process changes are working?

6. Establishing a measurement method and consistent units of measurement to be used throughout the life of the project is
crucial
• new system without a structures approach.
There is no standard or definition of software metrics that have value to software development teams. 
Difficult to compare software simply by lines of code or any other metric without a standard definition.
Lack of commonality across software process between organizations makes universal metrics difficult to develop.
• Metrics probably need to be calibrated to particular application domains and development organizations.

7. Implementing s/w metrics in an organization of any size is difficult.

Ex: There was an organization, which used individual productivity, in terms of functionality divided by effort, as major determinant
of salary increase.
There is also an issue with how software metrics are used. If an organization uses productivity metrics that emphasize volume of
code and errors, software developers could avoid tackling tricky problems to keep their LOC up and error counts down.
S/w developers who write a large amount of simple code may have great productivity numbers but not great software
development skills.
If we start measuring performance of individuals. Worst mistake as using measurement in this way is counter-productive, divisive
and developers may rig the data they supply. Employees don’t like upsetting the boss.
8. Software metrics are great for management teams because they offer a quick way to track software development, set
goals and measure performance. But oversimplifying software development can distract software developers from
goals such as delivering useful software and increasing customer satisfaction.

9. Implementing s/w metrics means changing the way in which people work and think.
It’s not an easy option, many metrics programs fail(fear of introducing new system)

10. Analyzing collected data is very difficult.

• Professional statisticians should be consulted if available.
• Data analysis must take local circumstances into account.

11. Some metrics are difficult to apply in practice.

•Tedious to apply manually and impossible to automate.
• SM can’t solve all our problems, but they can enable managers to improve
their processes,project and product, to improve productivity and quality.
• Use of SM does not ensure survival but improves probability of survival.
 Solutions:
Guideline for an appropriate use of software metrics:
1. Link software metrics to goals:
Communicate sets of software metrics to software development teams as goals.
So the focus becomes:
• Reducing the lines of codes
• Reducing the number of bugs reported
• Speeding up the completion of tasks
Focusing on those metrics as targets help software developers reach more important goals such as improving software usefulness and user
experience.

2. Stop using software metrics that do not lead to change.

3. Some software metrics have no value when it comes to indicating software quality or team workflow.
Management and software development teams need to work on software metrics that drive progress towards goals and provide verifiable,
consistent indicators of progress.
4. Small and quality set of metrics should be chosen, large set of metrics should be avoided as it is very confusing to understand large set of
metrics.
5. Metrics should also be uniform and everybody in team should agree with it.
6. After defining the metrics the next step is to track metrics. Since tracking is a constant activity so its always nice to automate the tracking
part. Report test metrics to stakeholders so that they have clear picture of project progress.
This is why software development platforms that automatically measure and track metrics are important.
 Against:
• Collecting metrics is too hard ... it’s too time consuming ... it’s too political ... they can be used against
individuals ... it won’t prove anything
For:
• In order to characterize, evaluate, predict and improve the process and product a metric baseline is
essential.

Software metrics should have several important characteristics:

1. Simple and computable
2. Consistent and unambiguous (objective)
3. Use consistent units of measurement
4. Independent of programming languages
5. Easy to calibrate and adaptable
6. Easy and cost-effective to obtain
7. Able to be validated for accuracy and reliability
8. Relevant to the development of high-quality software products
2 important Size metrics
1. Lines Of Code (LOC) or 1000 Lines Of Code KLOC
2. 5 Function points(input, output, inquires, external logical files , internal logical files)
Already covered in topic: s/w planning.
Other Size Oriented Metrics
• Size of the software produced
• Effort measured in person months
• Errors/KLOC
• Defects/KLOC
• Cost/LOC
• Documentation Pages/KLOC
• LOC per person-months
• Error per person-months

• LOC is programmer & language dependent

Application models
1. COCOMO
2. COCOMO II
3. PUTNAM RESOURCE ALLOCATION MODEL etc
Computing Functions Points
• Number of user inputs – Distinct input from user
• Number of user outputs – Reports, screens, error messages, etc
• Number of user inquiries – On line input that generates some result
• Number of files – Logical file (database)
• Number of external interfaces – Data files/connections as interface to other systems

Other:
• Errors per FP
• Defects per FP
• Cost per FP
• Pages of documentation per FP
• FP per person month
Size Metrics
1. Size in terms of LOC
2. 5 Function points

Design Metrics
• Design quality metrics concerned with measuring the cohesion, coupling, or complexity of a design are supposed to correlate with
quality.
1. Cohesion
2. Coupling
3. Complexity: Complexity = Length * (Fan-in * Fan-out)^2 – Length is any measure of program size such as LOC

Coupling Metrics
4. Fan-in
5. Fan-out

Analysis Metrics
• Attempt to estimate costs early in the development process:
1. Cocomo
2. Function Points
General design principal is to promote Low Coupling and High Cohesion. Divide software system into multiple independent modules where each
module works independently
1. Coupling: measure of degree of interdependence between s/w modules.
• good software will have low coupling.
little interaction between two modules: loosely coupled modules.
Low coupling increases encapsulation , which makes classes easier to Understand and Change.
Easy to Reuse as it has less associated ‘baggage’ to be considered.
high degree of interaction b/w the modules: tightly coupled means much dependence on other modules.
It result in a maintenance problem that can result in faults in system.
Coupling is the indication of the relationships between modules.
number of references both in and out of different types (global data, protected variables etc).
For low coupled modules, changing something major in one class should not affect the other.
High coupling would make it difficult to change and maintain your code.
Types of Coupling:
1. Content Coupling: One module refers to or changes the internals of another module(1 module modifies or relies on internal workings of
another module (e.g. accessing local data of another module).  worst form of coupling and should be avoided.
2. Common Coupling: Two modules share the same global data data.
3. Control Coupling: Data from one module is used to direct the order of instruction execution in another(one module controlling the logic of
another, by passing it information on what to do ). Example- sort function that takes comparison function as an argument.
4. Data Coupling: Two modules communicate via a variable or array that is passed directly as a parameter between the two modules.
2. Cohesion: measures of how strongly the elements within a module are functionally related.

It’s internal glue that keeps the module together. A good software design will have high cohesion.
Cohesion is the indication of the relationship within module.

Cohesion shows the module’s relative functional strength.

Coupling shows the relative independence among the modules.
Cohesion is Intra – Module Concept.
Coupling is Inter – Module Concept.

It’s kind of natural extension of data hiding 

Cohesion from a metric point of view is measured by comparing the use of variables within a class.
If two methods use the same variable this will act to decrement the cohesion rating.
If one method uses a variable that the other does not this increases the cohesion measure.

Low cohesion means module does a great variety of actions - it is broad, unfocused on what it should do.
High cohesion means module is focused on what it should be doing, i.e. only methods relating to intention of class.
Types of Cohesion
1) Functional: Every essential element for a single computation is contained in the component. It performs
task and functions. It is an ideal situation.
2) Sequential :An element outputs some data that becomes input for other element, i.e., data flow between
the parts.
3) Communicational: Two elements operate on the same input data or contribute towards the same output
data. Example- update record in database and send it to the printer.
4) Procedural: Elements of procedural cohesion ensure the order of execution. Ex- calculate student GPA,
print student record, calculate cumulative GPA, print cumulative GPA.
5) Temporal :elements are related by their timing involved. A module connected with temporal cohesion
means all the tasks must be executed in same time-span. This cohesion contains the code for initializing
all the parts of the system.
6) Logical: Elements are logically related and not functionally. Ex- A component reads inputs from tape, disk,
and network. All the code for these functions is in the same component. Operations are related, but the
functions are significantly different.
 IF(Information Flow) METRICS
• System consist of components. Components are fitted together that influence complexity of a system.
• If component has to do numerous discrete tasks, means it lacks cohesion.
• Strongly cohesive module implements functionality that’s related to 1 feature of solution and require little or no interaction
with other modules. It may be viewed as glue that keeps module together.
• Coupling is measured by no. of interconnections b/w modules. It increases as no. of calls b/w module increases, or amount of
shared data increases.
• If it passes information to, and/or accept information from many other components within system, it’s said to be highly
coupled.
• Components that are highly coupled and lack cohesion tend to be less reliable and less maintainable (than those that are
loosely coupled and that are cohesive).
• with other modules.

(module)

Cohesion: Degree to which

elements of module belong
together. It measures strength of
relationship b/w pieces of
functionality within a given
module.
• Cohesion (internal interaction)
• Coupling (external interaction)

 cohesion refers to the degree to which the elements inside a module belong together.

it is a measure of the strength of relationship between the methods and data of a class.
(relationship between the class’s methods and data themselves).
• Low cohesion is associated with undesirable traits such as being difficult to maintain, test, reuse, or even
understand.
• Modules with high cohesion tend to be preferable, because high cohesion is associated with several desirable
traits of software including robustness, reliability, reusability, and understandability.

coupling is the degree of interdependence between software modules; a measure of how closely connected two
routines or modules are; the strength of the relationships between modules.

Low coupling
high cohesion.
 Basic information flow model
•• Information
  Flow metrics are applied to Components of system design.
For component A, we define 3 measures:
fan-in and fan-out metrics : define complexity of a module.
1. ‘FAN IN’ is simply a count of number of other Components that can call, or pass control, to Component A.
2. ‘FANOUT’ is number of Components that are called by Component A.
3. This is derived from the first two by using the following formula.
We will call this measure INFORMATION FLOW index of Component A, abbreviated as IF(A).
IF(A) = [FAN IN(A) x FAN OUT (

Fig. shows a fragment of such a design:

M
 Flow Metrics counts the number of local information flows entering (fan-in) and exiting (fan-out) each procedure.
These components need to be looked at in terms of FAN-IN and FAN-OUT to see how to reduce complexity level.
• If the complexity can’t be reduced, then at least make sure that component is thoroughly tested.
1. Fan-out of a module : number of its immediately subordinate modules. 
• number of functions that are called by function X.
A high value for fan-out suggests that the overall complexity of X may be high because of the complexity of the control logic needed
to coordinate the called components.
higher the fan-out of an object, the poorer is the overall system design.
2. Fan-in of a module : number of its immediately superordinate (i.e., parent or boss) modules. 
• number of functions that call another function (say X).
High fan-in means that X is tightly coupled to the rest of the design and changes to X will have extensive knock-on effects.

High FAN-IN and FAN-OUT values indicate components that lacks cohesion.
• High fan-in (number of calling functions) suggests high coupling because of module dependencies. High change impact (e.g., ripple effects)
• High fan-out (number of calls) suggests high coupling because of control complexity. High complexity, this is indicative of a high degree of
class interdependency. 
The approach based on calls relationship, it ignores data dependencies.
• Informational fan-in/fan-out takes into account: –
• Number of local data flows + number of global data structures updated + updated procedure parameters and procedures called from
within a module.

Fan-in

Component A

Fan-out
Following is step-by-step guide to derive IF metrics:
1. Note level of each component in system design.
2. For each component, count no. of calls to that component-i-e FAN IN of that component.
Some organizations allow more than one Component at highest level in design, so for Components at
highest level, assign a FAN IN of one.
3. For each Component, count number of calls from Component.
For Component that call no other, assign a FAN OUT value of one.
4. Calculate IF value for each Component using the above formula.
5. Sum IF value for all Components within each level which is called as the LEVEL SUM.
6. Sum IF values for the total system design which is called SYSTEM SUM.
7. For each level, rank the Component in that level according to FAN IN, FAN OUT and IF values.
Three histograms or line plots should be prepared for each level.
8. Plot the LEVEL SUM values for each level using a histogram or line plot.

IF metrics are relative indicators. Means value of 1 system may be higher than other system but this does not mean that
one system is worse. Nor does high metric value guarantee that component will be unreliable and unmaintainable. It’s only
that it will probably be less reliable and maintainable than it’s fellows(means it’s potentially going to cost significant
amounts of money to fix and enhance).
So, strength of IF metrics is not in numbers themselves but in “how the information is used”.
 More Sophisticated Information Flow Model
Only difference b/w simple and sophisticated IF models lies in definition of FAN-IN and FAN-OUT.
• For component A let:
A=number of components that call A.
B=number of parameters passed to A from components higher in hierarchy.
C=number of parameters passed to A from components lower in hierarchy.
D=number of data elements read by component A.
So, FAN IN(A)=A+B+C+D

E=Number of components called by A.

F=number of parameters passed from A to components higher in hierarchy.
G=number of parameters passed from A to components lower in hierarchy.
H=number of data elements written to by A.
So, FAN OUT(A)=E+F+G+H
REST IS SAME
 Metric analysis: using statistics for Assessment

• Wide range of techniques: use to assess internal attributes of software product.

• Using these techniques, analyse data to make deductions about quality of s/w product
and determine if it’s sufficiently good to be released to customers.
• data can be expressed in numerical form. We need to use statistics to understand numbers,
to make decisions and then to produce evidence to support those deductions.
• Expressing data in pie charts and histograms, using methods like regression and correlation
can reveal a lot about software.
• Need to be careful while applying any kind of statistics.
 Using statistics for Assessment
Purpose of applying statistics to metric data: To gain knowledge.
• Choice of statistics: determined by audience for whom statistics are intended.
• To provide an evaluation of s/w product for project managers:
use simple descriptive statistics.

• To point out areas of high and low software quality and make comparisons with other projects/or predefined
target values:
use simple graphs and tables.

• Use metric data collected from different projects to define and refine criteria on which assessments are made.

• Statistical packages/Tools: easy to use, generate graph and diagrams automatically.

• But still need to understand assumptions on which a particular technique is based. If these are ignored then
conclusions are likely to be erroneous.
Statistical Techniques:
• Summary statistics such as mean, median, max. and min.
• Graphical representations such as histograms, pie charts and box plots.
• Principal component analysis to reduce no. of variables being analysed.
• Regression and correlation analysis for uncovering relationships in data.
• Reliability models for predicting future reliability.
 Flow problems with metric data
Most statistical methods and tests make no. of assumptions about data being analysed.
1. Normal Distribution
2. Outliers
3. Measurement Scale
4. Multicollinearity
1. Normal Distribution
• Many statistical techniques are based on assumption: “data under analysis is drawn from a normally distributed
population”.
• Frequency distribution for normal data has a bell shaped curve.
• Many types of physical measurement data follow this kind of distribution but this is often not the case for s/w metrics.

2. Outliers
It is data point which is outside the normal range of values of given population.
A. In non-s/w data, outliers are often due to errors in measurements.so they are removed from data set and subsequently
ignored.
B. In s/w metrics data, outliers are often most interesting data points.
Ex: if we are measuring component size, it’s not uncommon to have single s/w component, which is 10 to 20 times larger
than any other component.
It’s precisely these large components, which may give rise to problems in maintainability and so they should certainly not be
removed from data set.

3. Measurement Scale
Scale on which metrics are defined will generally determine which statistics can be meaningfully applied.
Most physical measures are ratio, e.g: length, mass, voltage, pressure.
But for s/w metric data, this is not a case. To decide which scale a particular metric is defined on, we need to go back to
actual definition of metric and reason about relationship imposed by attribute being measured.
4. Multicollinearity
• Many multivariate(involve 2 or more variables) techniques such as multivariate regression require that
variables(i.e metrics) are independent of each other, means they do not correlate with 1-another.
• But, most s/w metrics are correlated with size. It doesn’t mean that these metrics all measure size-they measure
many different attributes like number of decisions, but these attributes tend to be highly correlated with size.
• Solution: use either FA(Factor Analysis) or PCA to reduce set of metrics to smaller set of independent
components.
• FA require data to be normally distributed, this is rarely going to be true in s/w metrics data. But PCA is robust
technique as it relies on no distributional assumption.
• PCA is applied to data in order to reduce no. of measures used and to simplify correlation patterns.
• It solve these problems by reducing dimensionality represented by these many related variables to smaller set of
principal components while retaining most of variation from original variables.
• These new principal components are uncorrelated and can act as substitute for original variables with little loss of
information.
 Common pool of data:

We often compare metrics from 1 s/w product with typical values observed in many other products.
This require creating a common pool of data from previous projects.

When establishing common pool, aware of foll. 3 points:

• The selection of projects should be representative and not all come from a single application domain or
development styles.
• No single very large project should be allowed to dominate pool.
• For some projects, certain metrics may not have been collected, we should ensure this is not a source of bias.
 Pattern of Successful Applications:
Mature metrics can help to predict expected no. of latent bugs, help us to decide how much testing is enough and how
much design effort, cost, elapsed time.
Here’s what it takes to have a success:
1. Any metric is better then none.
Use simplest possible metric like weight, then implement token counting and function counting as next step. Worry about
fancy metrics later.
2. Automation is essential.
Any metrics project that relies on having developers fill out long questionnaire or manually calculate metric values is
doomed. They never work.
3. Empiricism is better then theory: we must use empirical, statistical data for guidance.
4. Use multifactor rather then single metrics.
All successful metrics programs use combination of several different metrics with weights calculated by regression analysis.
5. Don’t confuse productivity metrics with complexity metrics.
Productivity is characteristics of developers and testers. Complexity is characteristics of programs.
It’s not easy to tell them apart. Examples of productivity metrics incorrectly used in lieu of complexity metrics are: no. of
shots it take to get clean compilation, % of components that passed testing on 1st attempt, no. of test cases required to find
1st bug.
Automated or not, successful metrics program needs developer cooperation.
If complexity and productivity are mixed up, be prepared for either or both to be sabotaged to uselessness.
6. Let them mature.
It takes a lot of projects and a long time for metrics to mature to point where they are trustworthy. If typical
project takes 12 months, then it takes 10 to 15 projects over 2 to 3 year period before metrics are any use at
all.
7. Maintain them.
Metrics based on past history lose their utility after sometime. Weights given to metrics in predictor equations
have to be revised and continually reevaluated to ensure that they continue to predict what they are intended
to predict.
8. Let them die.
Importance assign to metrics changes with time.
• Encapsulation : Lack of cohesion
• Inheritance: Fan in – multiple inheritance
OO Metrics: Distinguishing Characteristics
• The following characteristics require that special OO metrics be
developed:
- Encapsulation — Concentrate on classes rather than functions
- Information hiding — An information hiding metric will provide an indication
of quality
- Inheritance — A pivotal indication of complexity
- Abstraction — Metrics need to measure a class at different levels of
abstraction and from different viewpoints
• Conclusion: the class is the fundamental unit of measurement
OO Project Metrics
• Number of Scenario Scripts (Use Cases):
- Number of use-cases is directly proportional the number of classes needed to meet
requirements
- A strong indicator of program size
• Number of Key Classes (Class Diagram):
- A key class focuses directly on the problem domain
- NOT likely to be implemented via reuse
- Typically 20-40% of all classes are key, the rest support infrastructure (e.g. GUI,
communications, databases)
• Number of Subsystems (Package Diagram):
- Provides insight into resource allocation, scheduling for parallel development and overall
integration effort
OO Analysis and Design Metrics
• Related to Analysis and Design Principles
• Complexity:
c , c ,..., c
- Weighted Methods per Class (WMC): Assume that n methods nwith cyclomatic
1 2
complexity are defined for a class C:
WMC   ci

- Depth of the Inheritance Tree (DIT): The maximum length from a leaf to the
root of the tree. Large DIT leads to greater design complexity but promotes
reuse
- Number of Children (NOC): Total number of children for each class. Large NOC
may dilute abstraction and increase testing
Further OOA&D Metrics
• Coupling:
- Coupling between Object Classes (COB): Total number of collaborations listed for each class
in CRC cards. Keep COB low because high values complicate modification and testing
- Response For a Class (RFC): Set of methods potentially executed in response to a message
received by a class. High RFC implies test and design complexity
• Cohesion:
- Lack of Cohesion in Methods (LCOM): Number of methods in a class that access one or more
of the same attributes. High LCOM means tightly coupled methods
OO Testability Metrics
• Encapsulation:
- Percent Public and Protected (PAP): Percentage of attributes that are public. Public attributes
can be inherited and accessed externally. High PAP means more side effects
- Public Access to Data members (PAD): Number of classes that access another classes
attributes. Violates encapsulation
• Inheritance:
- Number of Root Classes (NRC): Count of distinct class hierarchies. Must all be tested
separately
- Fan In (FIN): The number of superclasses associated with a class. FIN > 1 indicates multiple
inheritance. Must be avoided
- Number of Children (NOC) and Depth of Inheritance Tree (DIT): Superclasses need to be
retested for each subclass
DRE  E /( E  D)
object-oriented metrics suite

Object-oriented Description
metric

Weighted methods This is the number of methods in each class, weighted by the complexity of
per class (WMC) each method. Therefore, a simple method may have a complexity of 1, and a
large and complex method a much higher value. The larger the value for this
metric, the more complex the object class. Complex objects are more likely to
be difficult to understand. They may not be logically cohesive, so cannot be
reused effectively as superclasses in an inheritance tree.

Depth of This represents the number of discrete levels in the inheritance tree where
inheritance tree subclasses inherit attributes and operations (methods) from superclasses. The
(DIT) deeper the inheritance tree, the more complex the design. Many object classes
may have to be understood to understand the object classes at the leaves of
the tree.

Number of children This is a measure of the number of immediate subclasses in a class. It

(NOC) measures the breadth of a class hierarchy, whereas DIT measures its depth. A
high value for NOC may indicate greater reuse. It may mean that more effort
should be made in validating base classes because of the number of
subclasses that depend on them.

Chapter 24 Quality management 63

•   If hardwork is directly proportional to success, isn't it ironic that
labourers aren't as successful as investors?
• Hard work is generally a necessary but not sufficient factor for
success. 
• Furthermore, results, actual productivity, depends on factors
beyond hard work. If one laborer produces twice as many hand-made
bricks as another, doesn’t that one deserve twice as much? Even if
they both put in the same measure of work? Factors like skill, ideas,
smart decisions, knowledge, experience, tools, and technique make a
big difference.
Software project planning

1. Size estimation
It’s difficult area of project planning.
Other engineering disciplines have advantages that bridge, road can be
seen or touched, they are concrete. s/w is abstract so difficult to
identify size of system.
SIZE METRICS: 2 units to measure size
2. LOC
3. Function count
 1. LOC
• Simple metric that can be counted(simply a count of number of lines).
• LOC include declaration, executable statements but exclude comments and blank lines.
• Comments to include or not???
• There is fundamental reason for including comments in program. As quality of comments affects
maintenance cost.
• But, inclusion of comments and blank lines in count may encourage developers to introduce many
such lines in project development in order to create illusion of high productivity.

DISADV:
• Measuring system by no. of LOC is rather like measuring building by no. of bricks involved in
construction. Buildings are described in terms of facilities, no. and size of rooms and their total area
in sq. feet or meters.
• LOC is language dependent
• Major problem with LOC measure is that its not consistent as some lines are more difficult to code
than others.
 2. Function Count
• Alan Albrecht while working for IBM, recognized problem in size measurement in the
1970s, and developed a technique ( called Function Point Analysis), solution to size
measurement problem.
• When dealing with customers, manufacturers talk in terms of functions available(e.g: digital
tuning(function count based)), not in terms of components(e.g: integrated circuits(LOC based)).
• So, FPA(function point analysis) is solution to size measurement problem.
• It measures functionality from user point of view i.e on basis of what user request and
receives in return.
• Deals with functionality being delivered, not with LOC.
• Measuring size in this way has advantage that size using FPA is independent of technology
used to deliver functions.
• Ex:2 identical counting system, 1 written in 4GL and other in assembler would have same
function count.
Function points
• A productivity measure, empirically justified
• Motivation: define and measure the amount of value (or functionality)
produced per unit time
• Principle: determine complexity of an application as its function point
• Size of project may vary depending upon function points

Ch. 8 71
The principle of Albrecht’s function point analysis(FPA) is that a system
is decomposed into 5 functional units.
• Inputs : information entering the system
• Outputs : information leaving the system
• Inquiries : requests for instant access to information
• Internal logical files : information held within system
• External interface files : information held by other system that is
used by the system being analyzed.
5 functional units are divided in two categories:
(i) Data function types
1. ILF
2. EIF
• Internal Logical Files (ILF): User identifiable group of logical related data or
control information maintained within system.
• External Interface files (EIF): User identifiable group of logically related data or
control information referenced by system, but maintained within another
system.
(ii) Transactional function types
1. EI
2. EO
3. EQ
• External Input (EI): An EI processes data or control information that comes from outside system.
• The EI is an elementary process, which is the smallest unit of activity that is meaningful to end user in the
business.
• those items provided by the user that describe distinct application-oriented data (such as file names and menu
selections)

• External Output (EO): An EO is an elementary process that generate data or control

information to be sent outside system. those items provided to the user that generate
distinct application-oriented data (such as reports and messages)

• External Inquiry (EQ): An EQ is an elementary process that is made up to an input-

output combination that results in data retrieval.
Function point definition
• Average weighted sum of 5 characteristic factors

Item Weight
Number of inputs 4
Number of outputs 5
Number of inquiries 4
Number of files 10
Number of interfaces 7
Special features
• Function point approach is independent of language, tools, or methodologies
used for implementation; i.e. they do not take into consideration programming
languages, dbms, processing hardware or any other db technology.
• Function points can be estimated from requirement specification or design
specification, thus making it possible to estimate development efforts in early
phases of development.
• Function points are directly linked to the statement of requirements; any change
of requirements can easily be followed by a re-estimate.
• Function points are based on system user’s external view of system, non-
technical users of software system have a better understanding of what
function points are measuring.
 Counting Function Points
• 5 function points are ranked acc. to their complexity
1. LOW
2. AVERAGE
3. HIGH
Organizations that use FP methods develop criteria to find whether particular
entry is low, avg. or high.
After classifying each of 5 FP, UFP(unadjusted function points) are
calculated using predefined weights for each function type as given in table.

In
In
• Weighting factors are identified for all functional units and multiplied with functional units
accordingly.
• Unadjusted Function Point (UFP) :
• i=5 Function point( row,Z)
• j=3 ranks(low,avg,high),column, W

Final number of function points is arrived by multiplying UFP by an adjustment factor that’s determined by considering 14
aspects of processing complexity given in following table:
• FP = UFP * CAF
• Where CAF is complexity adjustment factor and is equal to [0.65 +0.01 x ΣFi].
• The Fi(i=1 to 14) are the degree of influence and are based on responses to
questions noted in following table:
 FunctionPoints

Compute CAF as sum of 14 characteristics on a six point scale (0 = no influence to 5 = strong influence).
1. Data Communications
2. Distributed Function
3. Performance
4. Heavily Used Configuration
5. Transaction Rate
6. On-line Data Entry
7. End-user Efficiency
8. On-line Update
9. Complex Processing
10. Re-usability
11. Installation Ease
12. Operational Ease
13. Multiple Sites
14. Facilitate Change
Technical Complexity Factors:

1. Data Communication
2. Distributed Data Processing
3. Performance Criteria
4. Heavily Utilized Hardware
5. High Transaction Rates
6. Online Data Entry
7. Online Updating
8. End-user Efficiency
9. Complex Computations
10. Reusability
11. Ease of Installation
12. Ease of Operation
13. Portability
14. Maintainability
 Uses of FP
1. To monitor levels of productivity, for example, no. of function points achieved per work hour
expended.
2. Software development Cost estimation.

These metrics are controversial and are not universally acceptable. There are standards
issued by the International Functions Point User Group (IFPUG, covering the Albrecht
method) and the United Kingdom Function Point User Group (UFPGU, covering the MK11
method). An ISO standard for function point method is also being developed.
• FP method continues to be refined.
Example: SafeHome Functionality
Test Sensor
Password
Zone Setting Sensors
Sensors
Zone Inquiry

User Sensor Inquiry SafeHome

SafeHome Messages
User
System
System Sensor Status User
User
Panic Button
(De)activate (De)activate

Monitor
Monitor
Password, Alarm Alert and
and
Sensors, etc. Response
Response
System
System
System
System
Config
ConfigData
Data
Example: SafeHome FP Calc
weighting factor
measurement parameter count simple avg. complex
number of user inputs 3 X 3 4 6 = 9

number of user outputs 2 X 4 5 7 = 8

number of user inquiries 2 X 3 4 6 = 6
number of files 1 X 7 10 15 = 7

number of ext.interfaces 4 X 5 7 10 = 22
count-total 52
complexity multiplier[0.65  0.01  Fi ]  [0.65  0.46] 1.11
function points 58
For average ƩFi =14*3
4: significant data communication
5: critical performance
2: moderately reusable
0: no multiple installation
Rest factors=average=3