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.
• Measurability makes comparison
 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.
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.
• 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
Software Requirements Metrics :
1. Function Points
Count number of inputs and output, user interactions, external interfaces.
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. Encapsulation
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??
Goals 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.
Metrics collected across all projects and over long period of time

1. Product Metrics - measure of various characteristics of product

such as size, complexity
2. Process Metrics - measure of various characteristics of s/w
development process(measure characteristics of methods,
techniques and tools that are used for developing s/w).
3. Project Metrics - metrics used by the project manager to check
the project's progress.
 Categories of metrics(3PS)
1. Product metrics: these are measure of various characteristics of product such as
size, complexity, quality, design, performance, functionality, 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(LOC count and function points count)
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.
• These metrics can be computed for different stages of SDLC.
2. Process metrics:
measure of various characteristics of s/w development process.
measures effectiveness and quality of processes that produce s/w products.
They are used to measure characteristics of methods, techniques and tools that are used for developing s/w.
Ex:
A. Effort required in process.
B. Time to produce end product by given process.
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
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.
Project Metrics
• are the metrics used by the project manager to check the project's
progress.
• Data from the past projects are used to collect various metrics, like time
and cost; these estimates are used as a base of new software.
• Note that as the project proceeds, the project manager will check its
progress from time-to-time and will compare the effort, cost, and time
with the original effort, cost and time.
• Project quality can also be improved, these metrics are used to decrease
the development costs, time efforts and risks. As quality improves, the
number of errors and time, as well as cost required, is also reduced.
 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 .
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.Data collected during the measurement process should be such that it can be
used to enhance the process, project, or product.
Collecting incorrect data results leads to wrong decision making, which in turn leads to deviation from software development plan.
Don’t collect unnecessary data.
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.

12. Lack of communication and training: Inadequate training and lack of communication results in poor understanding of
software metrics and measurement of unreliable data. In addition, communicating metrics data in an ineffective manner
results in misinterpretation of data.
.
13. Measuring too little, too late: Measuring too less, provides information, which is
of little or no importance for the software engineers. Thus, software engineers tend
to offer resistance in establishing metrics. Similarly, if data is collected too late, the
requested data item may result in unnecessary delay in software project as project
managers and software engineers do not get the data they need on time.

Implementing and executing software metrics is a cumbersome task

Also, there exist many issues which prevent the successful implementation and
execution of software metrics.

Software engineers should be adequately trained and measured data should be

properly communicated to them.
Software metrics should be defined precisely so that they work effectively.
• 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.
 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
Advantage of Software Metrics
• Comparative study of various design methodology of software systems.
• For analysis, comparison, and critical study of different programming language concerning their
characteristics.
• In comparing and evaluating the capabilities and productivity of people involved in software development.
• In the preparation of software quality specifications.
• In the verification of compliance of software systems requirements and specifications.
• In making inference about the effort to be put in the design and development of the software systems.
• In getting an idea about the complexity of the code.
• In taking decisions regarding further division of a complex module is to be done or not.
• In guiding resource manager for their proper utilization.
• In comparison and making design tradeoffs between software development and maintenance cost.
• In providing feedback to software managers about the progress and quality during various phases of the
software development life cycle.
• In the allocation of testing resources for testing the code.
Disadvantage of Software Metrics

• The application of software metrics is not always easy, and in some cases, it
is difficult and costly.
• The verification and justification of software metrics are based on
historical/empirical data whose validity is difficult to verify.
• These are useful for managing software products but not for evaluating the
performance of the technical staff.
• The definition and derivation of Software metrics are usually based on
assuming which are not standardized and may depend upon tools available
and working environment.
• Most of the predictive models rely on estimates of certain variables which
are often not known precisely.
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
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
 42 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
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.
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
 Basic information flow model
•

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.
 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
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 1 st attempt, no. of test cases required to
find 1st bug.
Automated or not, successful metrics program needs developer cooperation.
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 , c2 ,..., cnwith cyclomatic
- Weighted Methods per Class (WMC): Assume that 1n methods
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 78

• 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.
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