SOFTWARE QUALITY

“In the context of software engineering, software quality measures how well the software is
designed (quality of design), and how well the software conforms to that design (quality of
conformance). It is often described as the 'fitness for purpose' of a piece of software.”

Quality software is reasonably defect-free, delivered on time and within budget, meets
requirements and/or expectations, and is maintainable.

ISO 8402-1986 standard defines quality as “the totality of features and characteristics of a
product or service that bears its ability to satisfy stated or implied needs.”

 Software Quality refers to the ability of the software product to perform and
respond according to the users' needs and requirements.
 A software product that does not contain any errors or bugs, i.e., A software
product that is bug-free refers to the quality of the software.
 Good design, Functionality, Consistency, Reliability, and Maintenance are the
factors that lead to good quality software.

SOFTWARE QUALITY ATTRIBUTES

 Portability: A software is claimed to be transportable, if it may be simply created to figure

in several package environments, in several machines, with alternative code merchandise,
etc.
 Usability: A software has smart usability if completely different classes of users (i.e. each
knowledgeable and novice users) will simply invoke the functions of the merchandise.
 Reusability: A software has smart reusability if completely different modules of the
merchandise will simply be reused to develop new merchandise.
 Correctness: A software is correct if completely different needs as laid out in the SRS
document are properly enforced.
 Maintainability: A software is reparable, if errors may be simply corrected as and once
they show up, new functions may be simply added to the merchandise, and therefore the
functionalities of the merchandise may be simply changed, etc
 Reliability. Software is more reliable if it has fewer failures. Since software engineers do
not deliberately plan for their software to fail, reliability depends on the number and type of
mistakes they make. Designers can improve reliability by ensuring the software is easy to
implement and change, by testing it thoroughly, and also by ensuring that if failures occur,
the system can handle them or can recover easily.
 Efficiency. The more efficient software is, the less it uses of CPU-time, memory, disk
space, network bandwidth and other resources. This is important to customers in order to
reduce their costs of running the software, although with today’s powerful computers,
CPU-time, memory and disk usage are less of a concern than in years gone by.
Cost of quality
Cost of quality is one of the most established, effective measures of quantifying and calculating
the business value of testing. To measure this, the project and its budgeted expenses must be
classified into these four categories:

 Prevention costs – This includes cost of training developers on writing secure and
easily maintainable code
 Detection costs – This includes cost of creating test cases, setting up testing
environments, revisiting testing requirements.
 Internal failure costs – This includes costs incurred in fixing defects just before
delivery
 External failure costs – This includes product support costs incurred by delivering
poor quality software

DEFECT, FAULT AND FAILURE

Defect: A defect refers to the situation when the application is not working as per the
requirement and the actual and expected result of the application or software are not in
sync with each other.
 Fault: Sometimes due to certain factors such as Lack of resources or not following
proper steps Fault occurs in software which means that the logic was not incorporated
to handle the errors in the application. This is an undesirable situation, but it mainly
happens due to invalid documented steps or a lack of data definitions.
 Failure: Failure is the accumulation of several defects that ultimately lead to Software
failure and results in the loss of information in critical modules thereby making the
system unresponsive. Generally, such situations happen very rarely because before
releasing a product all possible scenarios and test cases for the code are simulated.
Failure is detected by end-users once they face a particular issue in the software.
 Error: Error is a situation that happens when the Development team or the developer
fails to understand a requirement definition and hence that misunderstanding gets
translated to buggy code. This situation is referred to as an Error and is mainly a term
coined by the developers.
Software Reliability : Introduction

 Software Reliability can be defined as the ability of a software product to perform

consistently and be trustworthy to its users i.e. The software product must perform
as required and should not deviate from its goal.
 Reliability means trustworthy or consistent.
 Reliability of a software product is an important aspect as it shows the actual ability
of the software product.

Reliability Metrics

Reliability metrics are used to quantitatively express the reliability of the software product. The
option of which metric is to be used depends upon the type of system to which it applies & the
requirements of the application domain.
Some reliability metrics which can be used to quantify the reliability of the software product are
as follows:

1. Mean Time to Failure (MTTF)

MTTF is described as the time interval between the two successive failures. An MTTF of 200
mean that one failure can be expected each 200-time units. The time units are entirely dependent
on the system & it can even be stated in the number of transactions. MTTF is consistent for
systems with large transactions.

For example, It is suitable for computer-aided design systems where a designer will work on a
design for several hours as well as for Word-processor systems.

To measure MTTF, we can evidence the failure data for n failures. Let the failures appear at the
time instants t1,t2.....tn.

MTTF can be calculated as

2. Mean Time to Repair (MTTR)

Once failure occurs, some time is required to fix the error. MTTR measures the average time it
takes to track the errors causing the failure and to fix them.

3. Mean Time between Failure (MTBF)

We can merge the MTTF and MTTR metrics to obtain the MTBF metric.

MTBF = MTTF + MTTR

Thus, an MTBF of 300 denotes that once a failure appears, the next failure is expected to appear
only after 300 hours. In this method, the time measurements are real-time, not the execution
time, as in MTTF.

4. Rate of occurrence of failure (ROCOF)

It is the number of failures appearing in a unit time interval. The number of unexpected events
over a specific time of operation. ROCOF is the frequency of occurrence with which an
unexpected role is likely to appear. A ROCOF of 0.02 means that two failures are likely to occur
in each 100 operational time unit steps. It is also called the failure intensity metric.

5. Probability of Failure on Demand (POFOD)

POFOD is described as the probability that the system will fail when a service is requested. It is
the number of system deficiency given several systems inputs.

POFOD is the possibility that the system will fail when a service request is made.

A POFOD of 0.1 means that one out of ten service requests may fail.POFOD is an essential
measure for safety-critical systems. POFOD is relevant for protection systems where services are
demanded occasionally.

6. Availability (AVAIL)

Availability is the probability that the system is applicable for use at a given time. It takes into
account the repair time & the restart time for the system. An availability of 0.995 means that in
every 1000 time units, the system is feasible to be available for 995 of these. The percentage of
time that a system is applicable for use, taking into account planned and unplanned downtime. If
a system is down an average of four hours out of 100 hours of operation, its AVAIL is 96%.
Software Reliability: Software Metrics

 Software metrics are the standards of measurement for a software product for
certain properties and functionalities. Software metrics can be broadly classified
into three categories. These are listed below :

Software Metrics : Software Reliability

1. Process Metrics
o The Process Metric are used for the improvement of the development and
maintenance of a software product. It mainly measures the efficiency of the
software product.
2. Product Metrics
o The Product Metrics are used for demonstrating the software product
characteristics and features, such as the performance and its quality.
3. Project Metrics
o The Project Metrics are used for demonstrating the characteristics of the
whole software project, which includes the total time, total cost, productivity,
and teams.

Software Reliability: Defect Rate

 Defect Rate can be defined as the number of defects detected per unit of the number
of test cycles.

Defect Rate = (No of Defects Detected* 100) / (No of Test Cycles)

Software Reliability: Defect Density

 Defect density is defined as the number of defects that arrive during a specific time
per unit size of software/module.

Defect Density = (Defect Count) / (Size of module or software)

 The defect density is counted per thousand lines of code and is called KLOC.
 The standard for defect density is not fixed. But, one defect per thousand lines of
code is considered good quality for the project.

Software Reliability: Defect Prevention

 Defect Prevention is a plan made out to reduce the number of defects in a software
product by identifying the cause of defects and preventing them from causing other
problems in the software.
 The strategy of defect prevention is to analyze the phases of the software product
where defects have arisen previously and prevent the occurrence of those defects in
the future.
 Defect Prevention causes an increase in productivity and effort reduction.

Defect Prevention is basically defined as a measure to ensure that defects that have been
detected so far do not appear or occur again. For facilitating communication simply among
members of the team, planning and devising defect prevention guidelines, etc., the Coordinator
is mainly responsible.
The coordinator is mainly responsible for leading defect prevention efforts, facilitating
meetings, to facilitating communication between team members and management, etc. The DP
board generally has a quarterly plan that sets some goals at the organization level. To achieve
these goals, various methods or activities are generally used and carried out to achieve and
complete these goals.
Methods of Defect Prevention:
For defect prevention, there are different methods that are generally used over a long period of
time. These methods or activities are given below:
1. Software Requirement Analysis:
The main cause of defects in software products is errors in software requirements and
designs. Software requirements and design are both important and should be analyzed in an
efficient way with more focus. Software requirement is basically considered an integral
part of the Software Development Life Cycle (SDLC) . These are the requirements that
basically describe features and functionalities of the target product and also convey
expectations or requirements of users from the software product.
Therefore, it is very much needed to understand software requirements more carefully, If
requirements are not understood well by testers and developers, then there might be a
chance of occurring of issue or defect occurring in the further process. Therefore, it is
essential to analyze and evaluate requirements more appropriately and properly.
2. Review and Inspection:
Review and inspection are both essential and integral parts of software development. They
are considered powerful tools that can be used to identify and remove defects if present
before their occurrence and impact on production. Review and inspection come in different
levels or stages of defect prevention to meet different needs. They are used in all software
development and maintenance methods. There are two types of review, i.e., self-review and
peer-review.
3. Defect Logging and Documentation:
After successful analysis and review, there should be records maintained about defects,
including a simple, complete description of the defect. This record can be further used to
have a better understanding of defects. After gaining knowledge and understanding of the
defect, only then can one take some effective and required measures and actions to resolve
particular defects so that the defect cannot be carried further to the next phase.
4. Root Cause Analysis:
Root cause analysis is basically an analysis of the main cause of a defect. It simply
analyzes what triggered the defect to occur. After analyzing the main cause of the defect,
one can find the best way to simply avoid the occurrence of such types of defects next time.
Software Reliability: Defect Containment

 It is a strategy, an attempt to increase the software quality and reduce the cost of the
software product simultaneously.
 Defect containment is usually reported as a percentage of defects captured in the
phase in which they originate.
 Also, it is a process of displaying the information about the issues and problems that
occurred and were reported for a software system.

Software Review is a systematic inspection of software by one or more individuals who work
together to find and resolve errors and defects in the software during the early stages of the
Software Development Life Cycle (SDLC). Software review is an essential part of the
Software Development Life Cycle (SDLC) that helps software engineers in validating the
quality, functionality, and other vital features and components of the software. It is a whole
process that includes testing the software product, and it makes sure that it meets the
requirements stated by the client.
Usually performed manually, a software review is used to verify various documents like
requirements, system designs, code, test plans, and test cases.
Objectives of Software Review:
The objective of a software review is:

1. To improve the productivity of the development team.

2. To make the testing process time and cost effective.

3. To make the final software with fewer defects.

4. To eliminate the inadequacies.

Process of Software Review:

Types of Software Reviews:
There are mainly 3 types of software reviews:

1. Software Peer Review:

Peer review is the process of assessing the technical content and quality of the product and
it is usually conducted by the author of the work product along with some other
developers.
Peer review is performed in order to examine or resolve the defects in the software, whose
quality is also checked by other members of the team.
Peer Review has the following types:
 (i) Code Review:
Computer source code is examined systematically.

 (ii) Pair Programming:

It is a code review where two developers develop code together on the same platform.

 (iii) Walkthrough:
Members of the development team are guided by the author and other interested parties,
and the participants ask questions and make comments about defects.

 (iv) Technical Review:

A team of highly qualified individuals examines the software product for its client’s use
 and identifies technical defects from specifications and standards.

 (v) Inspection:
In inspection the reviewers follow a well-defined process to find defects.

2. Software Management Review:

Software Management Review evaluates the work status. In this section decisions
regarding downstream activities are taken.

3. Software Audit Review:

Software Audit Review is a type of external review in which one or more critics, who are
not a part of the development team, organize an independent inspection of the software
product and its processes to assess their compliance with stated specifications and
standards. This is done by managerial level people.

Advantages of Software Review:

 Defects can be identified earlier stage of development (especially in formal review).

 Earlier inspection also reduces the maintenance cost of software.

 It can be used to train technical authors.

 It can be used to remove process inadequacies that encourage defects.

Software Measurement: A measurement is a manifestation of the size, quantity, amount, or

dimension of a particular attribute of a product or process. Software measurement is a titrate
impute of a characteristic of a software product or the software process. It is an authority
within software engineering. The software measurement process is defined and governed by
ISO Standard.

Software Measurement Principles:

The software measurement process can be characterized by five activities-

1. Formulation: The derivation of software measures and metrics appropriate for the
representation of the software that is being considered.
2. Collection: The mechanism used to accumulate data required to derive the formulated
metrics.
3. Analysis: The computation of metrics and the application of mathematical tools.
4. Interpretation: The evaluation of metrics resulting in insight into the quality of the
representation.
5. Feedback: Recommendation derived from the interpretation of product metrics transmitted
to the software team.
Need for Software Measurement:

Software is measured to:

 Create the quality of the current product or process.
 Anticipate future qualities of the product or process.
 Enhance the quality of a product or process.
 Regulate the state of the project in relation to budget and schedule.

Classification of Software Measurement:

There are 2 types of software measurement:

1. Direct Measurement: In direct measurement, the product, process, or thing is measured
directly using a standard scale.
2. Indirect Measurement: In indirect measurement, the quantity or quality to be measured is
measured using related parameters, i.e., by use of a reference.

SOFTWARE INSPECTION
The term software inspection was developed by IBM in the early 1970s, when it was noticed
that the testing was not sufficient to attain high-quality software for large applications.

Software inspection is a process in which other developers or team members review the code
written by a developer to identify potential errors or areas for improvement. This process can
help improve the overall quality of the software by identifying and resolving faults early in the
development process.

There are several ways that software inspection can improve software quality:

1. Identifying and resolving defects early: By identifying and resolving defects early in the
development process, inspection can prevent costly rework and delays later in the project.
2. Enhancing code readability: Inspection can help improve the readability of the code,
making it easier for other developers to understand and maintain.
3. Improving team collaboration: Inspection can help improve team collaboration by
encouraging developers to share their ideas and knowledge.
4. Enhancing code maintainability: Inspection can help identify areas where code is
difficult to maintain and suggest improvements to make it more maintainable.
5. Improving code efficiency: Inspection can help identify areas where code is inefficient
and suggest improvements to make it more efficient.
6. Enhancing security: Inspection can help identify security vulnerabilities in the code and
suggest improvements to make the software more secure.
7. Improving the overall quality of the software: By identifying and resolving defects early
in the development process, inspection can help improve the overall quality of the software
and ensure that it meets the needs of its users.
Inspection is an important aspect of software quality assurance and can help ensure that the
software functions correctly and meets the needs of its users. It is an efficient way to detect
errors and defects early in the development process, and can save time and resources by
preventing costly rework or delays later in the project.
Inspection is used to determine the defects in the code and remove it efficiently. This prevents
defects and enhances the quality of testing to remove defects. This software inspection method
achieved the highest level for efficiently removing defects and improving software quality.

There are some factors that generate the high quality software:
 Phrases quality design inspection and Code inspections: This factor refers to formal
oversight that follows protocols such as training. Participants, material distributed for
inspection. Both moderators and recorders are present to analyze defect statistics.
 Phrase quality assurance : This factor refers to an active software quality assurance
group, which joins a group of software developments to support them in the development
of high quality software.
 Formal Testing :It throws the test process under certain conditions
 For an application, a test plan was created.
 Are complete specifications so that test cases can be made without significant
gaps.
 Vast library control tools are used.
 Test coverage analysis tools are used.

Software Inspection Process: The inspection process was developed in the mid-1970s, later
extended and revised. The process must have an entry criterion that determines whether the
inspection process is ready to begin. This prevents incomplete products from entering the
inspection process. Entry criteria can be interstitial with items such as “The Spell-Document
Check”.
There are some of the stages in the software inspection process such as-
 Planning: The moderator plan the inspection.
 Overview Meeting: The background of the work product is described by the author.
 Preparation: The examination of the work product is done by inspector to identify the
possible defects.
 Inspection Meeting: The reader reads the work product part by part during this meeting
and the inspectors the faults of each part.
 Rework: After the inspection meeting, the writer changes the work product according to
the work plans.
 Follow Up: The changes done by the author are checked to make sure that everything is
correct.

Advantages of Software Inspection:

 Helps in the early removal of major defects.
 This inspection enables a numeric quality assessment of any technical document.
 Software inspection helps in process improvement.
 It helps in staff training on the job.
 Software inspection helps in gradual productivity improvement.
 Early identification and resolution of defects: Software inspection allows developers to
identify and resolve defects early in the development process, which can save time and
resources by preventing costly rework or delays later in the project.
 Improved code quality: Software inspection can help improve the overall quality of the
code by identifying areas for improvement and suggesting changes to make the code more
readable, maintainable, and efficient.
 Enhanced team collaboration: Software inspection can encourage developers to share their
ideas and knowledge, and can help improve team collaboration and communication.
 Increased code maintainability: Software inspection can help identify areas where code is
difficult to maintain and suggest improvements to make it more maintainable.
 Enhanced security: Software inspection can help identify security vulnerabilities in the
code and suggest improvements to make the software more secure.
 Cost-effective: Software inspection is relatively low cost and time-efficient, as it can be
done by the team members themselves.
 Increased accountability: Software inspection can help hold developers and teams
accountable for the quality of their code, by providing metrics and feedback.
 Provides a comprehensive view of the code: Software inspection can provide an in-depth
view of the code, which can help to identify both functional and non-functional
requirements of the software.
Size Oriented Metrics

LOC Metrics
It is one of the earliest and simpler metrics for calculating the size of the computer program. It is
generally used in calculating and comparing the productivity of programmers. These metrics are
derived by normalizing the quality and productivity measures by considering the size of the
product as a metric.

Following are the points regarding LOC measures:

1. In size-oriented metrics, LOC is considered to be the normalization value.

2. It is an older method that was developed when FORTRAN and COBOL programming
were very popular.
3. Productivity is defined as KLOC / EFFORT, where effort is measured in person-months.
4. Size-oriented metrics depend on the programming language used.
5. As productivity depends on KLOC, so assembly language code will have more
productivity.
6. LOC measure requires a level of detail which may not be practically achievable.
7. The more expressive is the programming language, the lower is the productivity.
8. LOC method of measurement does not apply to projects that deal with visual (GUI-
based) programming. As already explained, Graphical User Interfaces (GUIs) use forms
basically. LOC metric is not applicable here.
9. It requires that all organizations must use the same method for counting LOC. This is so
because some organizations use only executable statements, some useful comments, and
some do not. Thus, the standard needs to be established.
10. These metrics are not universally accepted.

Based on the LOC/KLOC count of software, many other metrics can be computed:

a. Errors/KLOC.
b. $/ KLOC.
c. Defects/KLOC.
d. Pages of documentation/KLOC.
e. Errors/PM.
f. Productivity = KLOC/PM (effort is measured in person-months).
g. $/ Page of documentation.

Advantages of LOC
 1. Simple to measure

Disadvantage of LOC

1. It is defined on the code. For example, it cannot measure the size of the specification.
2. It characterizes only one specific view of size, namely length, it takes no account of
functionality or complexity
3. Bad software design may cause an excessive line of code
4. It is language dependent
5. Users cannot easily understand it

Halstead's Software Metrics

According to Halstead's "A computer program is an implementation of an algorithm considered

to be a collection of tokens which can be classified as either operators or operand."

Token Count

In these metrics, a computer program is considered to be a collection of tokens, which may be

classified as either operators or operands. All software science metrics can be defined in terms of
these basic symbols. These symbols are called as a token.

The basic measures are

n1 = count of unique operators.

n2 = count of unique operands.
N1 = count of total occurrences of operators.
N2 = count of total occurrence of operands.

In terms of the total tokens used, the size of the program can be expressed as N = N1 + N2.

Halstead metrics are:

Program Volume (V)

The unit of measurement of volume is the standard unit for size "bits." It is the actual size of a
program if a uniform binary encoding for the vocabulary is used.

V=N*log2n

Program Level (L)

The value of L ranges between zero and one, with L=1 representing a program written at the
highest possible level (i.e., with minimum size).

L=V*/V

Program Difficulty

The difficulty level or error-proneness (D) of the program is proportional to the number of the
unique operator in the program.

D= (n1/2) * (N2/n2)

Programming Effort (E)

The unit of measurement of E is elementary mental discriminations.

E=V/L=D*V

Estimated Program Length

According to Halstead, The first Hypothesis of software science is that the length of a well-
structured program is a function only of the number of unique operators and operands.

N=N1+N2

And estimated program length is denoted by N^

N^ = n1log2n1 + n2log2n2

The following alternate expressions have been published to estimate program length:

o NJ = log2 (n1!) + log2 (n2!)

o NB = n1 * log2n2 + n2 * log2n1
o NC = n1 * sort(n1) + n2 * sort(n2)
o NS = (n * log2n) / 2

Potential Minimum Volume

The potential minimum volume V* is defined as the volume of the most short program in which
a problem can be coded.

V* = (2 + n2*) * log2 (2 + n2*)

Here, n2* is the count of unique input and output parameters

 Size of Vocabulary (n)

The size of the vocabulary of a program, which consists of the number of unique tokens used to
build a program, is defined as:

n=n1+n2

Where

n=vocabulary of a program
n1=number of unique operators
n2=number of unique operands

Language Level - Shows the algorithm implementation program language level. The same
algorithm demands additional effort if it is written in a low-level program language. For
example, it is easier to program in Pascal than in Assembler.

L' = V / D / D
lambda = L * V* = L2 * V

Language levels

Language Language level λ Variance σ

PL/1 1.53 0.92

ALGOL 1.21 0.74

FORTRAN 1.14 0.81

CDC Assembly 0.88 0.42

PASCAL 2.54 -

APL 2.42 -

C 0.857 0.445

Counting rules for C language

1. Comments are not considered.

2. The identifier and function declarations are not considered
3. All the variables and constants are considered operands.
 4. Global variables used in different modules of the same program are counted as multiple
occurrences of the same variable.
5. Local variables with the same name in different functions are counted as unique
operands.
6. Functions calls are considered as operators.
7. All looping statements e.g., do {...} while ( ), while ( ) {...}, for ( ) {...}, all control
statements e.g., if ( ) {...}, if ( ) {...} else {...}, etc. are considered as operators.
8. In control construct switch ( ) {case:...}, switch as well as all the case statements are
considered as operators.
9. The reserve words like return, default, continue, break, sizeof, etc., are considered as
operators.
10. All the brackets, commas, and terminators are considered as operators.
11. GOTO is counted as an operator, and the label is counted as an operand.
12. The unary and binary occurrence of "+" and "-" are dealt with separately. Similarly "*"
(multiplication operator) are dealt separately.
13. In the array variables such as "array-name [index]" "array-name" and "index" are
considered as operands and [ ] is considered an operator.
14. In the structure variables such as "struct-name, member-name" or "struct-name ->
member-name," struct-name, member-name are considered as operands and '.', '->' are
taken as operators. Some names of member elements in different structure variables are
counted as unique operands.
15. All the hash directive is ignored.

Example: Consider the sorting program as shown in fig: List out the operators and operands and
also calculate the value of software science measure like n, N, V, E, λ, etc.

Solution: The list of operators and operands is given in the table

Operators Occurrences Operands Occurrences

int 4 SORT 1

() 5 x 7

, 4 n 3
[] 7 i 8

if 2 j 7

< 2 save 3

; 11 im1 3

for 2 2 2

= 6 1 3

- 1 0 1

<= 2 - -

++ 2 - -

return 2 - -

{} 3 - -

n1=14 N1=53 n2=10 N2=38

Here N1=53 and N2=38. The program length N=N1+N2=53+38=91

Vocabulary of the program n=n1+n2=14+10=24

Volume V= N * log2N=91 x log2 24=417 bits.

The estimate program length N of the program

= 14 log214+10 log2)10
= 14 * 3.81+10 * 3.32
= 53.34+33.2=86.45

Conceptually unique input and output parameters are represented by n2*.

n2*=3 {x: array holding the integer to be sorted. This is used as both input and output}

{N: the size of the array to be sorted}

The Potential Volume V*=5log25=11.6

Since L=V*/V
We may use another formula

V^=V x L^= 417 x 0.038=15.67

E^=V/L^=D^ x V

Therefore, 10974 elementary mental discrimination is required to construct the program.

This is probably a reasonable time to produce the program, which is very simple.