0% found this document useful (0 votes)
7 views

Module 5

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views

Module 5

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 28

Unit 5 : SOFTWARE QUALITY

Unit Structure
Objectives

Introduction

An Overview

The Place of Software Quality in Project Planning

Importance of Software Quality


Defining Software Quality

Software Quality Models


14.2.5 ISO 9126

Product and Process Metrics

Product versus Process Quality Management

Quality Management Systems


Process Capability Models

Techniques to Help Enhance Software Quality

Testing, Software Reliability

Quality Plans

Summary
Exercise

List of Books and References

OBJECTIVES

After going through this chapter, you will be able to know:

 The Place of Software Quality in Project Planning

 Importance of Software Quality, Defining Software Quality,


Software Quality Models, ISO 9126

 Product and Process Metrics What is process and product metrics?


Types of Metrics Advantages and disadvantages of Software Metrics
290
 Product versus Process Quality Management What is product quality and
process quality? Software quality management Quality Management Systems,
Process Capability Models Techniques toHelp Enhance Software Quality

 Testing and type of testing, different techniques of Software Testing, Software


Reliability, Quality Plans

INTRODUCTION

Quality software refers to a software which is reasonably bug or defect


free, is delivered in time and within the specified budget, meets the
requirements and/or expectations, and is maintainable. In the software
engineering context, software quality reflects both functional quality as
well as structural quality.

 Software Functional Quality − It reflects how well it satisfies a


given design, based on the functional requirements or specifications.

 Software Structural Quality − It deals with the handling of non-


functional requirements that support the delivery of the functional
requirements, such as robustness or maintainability, and the degree
to which the software was produced correctly.

 Software Quality Assurance − Software Quality Assurance (SQA)


is a set of activities to ensure the quality in software engineering
processes that ultimately result in quality software products. The
activities establish and evaluate the processes that produce products.
It involves process-focused action.

 Software Quality Control − Software Quality Control (SQC) is a


set of activities to ensure the quality in software products. These
activities focus on determining the defects in the actual products
produced. It involves product-focused action.

The Place of Software Quality in Project Planning


Software quality is a nuanced concept that requires a framework that addresses
functional, structural and the process of the software delivery understand. Measurement
of each aspect is a key tool for understanding whether we are delivering a quality
product and whether our efforts to improve quality are having the intended impact.
However, measurement can be costly. To balancing the effort required to measure
quality versus the benefit, you first need to understand the reasons for measuring
quality. Five of reasons quality is important to measure include:

1. Safety – Poor quality in software can be hazardous to human life and safety.
Quality problems can impact the functionality of the software products. Jon
Quigley discussed the impact of configuration defects that effected safety in
SPaMCAST 346.
2. Cost – Quality issues cost money to fix. Whether you believe that a defect is
100x more costly to fix late in the development cycle or not, doing work
over because it is defective does not deliver more value than doing it right
once.
3. Customer Satisfaction (internal) – Poor quality leads stakeholders to look for
someone else to do your job or perhaps shipping your job and all your
friend’s jobs somewhere else. Recognize that the stakeholders experience as
the software is being developed, tested and implemented is just as critical as
the raw number of defects.
4. Customer Satisfaction (external) – Software products that don’t work, are
hard to use (when they don’t need to be) or are buggy don’t tend not to last
long in the marketplace. Remember that in today’s social media driven world
every complaint that gets online has a ripple effect. Our goal should be to
avoid problems that can be avoided.
5. Future Value – Avoiding quality problems increases the amount of time
available for the next project or the next set of features. Increasing quality
also improves team morale, improved team morale is directly correlated with
increased productivity (which will increase customer satisfaction and reduce
cost).
Importance of Software Quality
The Seven Aspects(importance) of Software Quality
Software engineering is a complex field. Good software engineers are capable of
balancing opposing forces and working within constraints to create great software.
Poor software developers (they really aren’t engineers) are ones who are incapable
of perceiving the trade-offs they are making and the implications of their design
decisions (or lack thereof).
Every software engineer absolutely must know the seven aspects of software
quality:

 Reliability
 Understandability
 Modifiability
 Usability
 Testability
 Portability
 Efficiency

These seven aspects can be measured and judged for any software product. They
apply to embedded systems, websites, mobile apps, video games, open-source
APIs, internal services, and any other sort of software product. These aspects are
entirely business domain independent. A software engineer’s ability can be
292 measured by the quality of the software he creates. Skilled engineers create high-
quality software and source code.
For different projects, the prioritization of the aspects of quality will vary.
Some projects should be focused on reliability, usability, and
understandability, while other projects will place high importance on
testability and efficiency. As a software engineer, you must know which
aspects of quality are most important to your project. You must apply your
best efforts towards the most critical aspects, and not spend excessive time
on less important aspects.
Reliability: Software is reliable if it behaves consistently. The functionality
of a program should be predictable and repeatable. Errors should occur
rarely or not at all. Errors that do occur should be handled gracefully and
proactively. Users should never ask themselves whether the software will
work correctly.

Understandability: The structure, components, and source code must be


understandable. They must be clear. They must be well-organized. They
must behave the way a developer would expect. Anything in the code that
causes developers confusion reveals that the code is lacking in
understandability. High-quality source code always appears simple and
obvious.

Modifiability: It should be easy to add or change the behavior of a system.


Flexible systems require changing very few lines of code to alter a behavior.
For the expected dimensions of change, an application should have plugin
points that allow the application to be used with different contextual
elements. Tight coupling to an element that is expected to change is
unacceptable.

Usability: Software products must be simple and easy to use. The common
use cases should be as obvious and clearly presented as possible. Software
should not require excessive configuration. Users should feel empowered by
your software. They should not need internet searches to discover core
application functionality.
Testability: The functionality of software must be verifiable. The process of
testing the software must be easy. Each business use case should be directly
testable. Clear verification metrics must be available. Highly testable
software will ship with a comprehensive automated test suite.

Portability: Portable software is usable in different environments and


contexts. It is highly reusable. Portable software is decoupled from specific
operating systems, types of hardware, and deployment contexts. Extremely
portable software is reusable across projects and problem domains.

Efficiency: Efficient software uses as few physical resources as possible.It


is fast. It is memory efficient. It consumes few CPU cycles. It uses little
battery life. It makes few external service calls. It minimizes the number of
database calls. Efficient software accomplishes as much as possible with
the least number of resources.
you absolutely must know these sevens aspects of software quality. You must
know which of the seven aspects are most important and least important in your
current projects. Your code reviews should reference these aspects. Your design
meetings and discussions should explicitly involve these aspects. You must know
when you are sacrificing one of these dimensions to improve another dimension.
You must cultivate a deep awareness of software quality. It should inform and
guide your designs.
Indeed, nearly all the software practices, patterns, and methodologies that have been
created in recent years are attempts to increase software quality in one or more of
these dimensions. The best practices and methodologies are ones that improve
multiple aspects (SOLID, TDD, XP, DDD). Those are means to an end. You must
know the goal to adequately judge their effectiveness. Quality software is the goal.

Defining Software Quality What is


software quality?
The quality of software can be defined as the ability of the software to function as
per user requirement. When it comes to software products it must satisfy all the
functionalities written down in the SRS document.

Key aspects that conclude software quality include,

 Good design – It’s always important to have a good and aesthetic design to
please users

 Reliability – Be it any software it should be able to perform the


functionality impeccably without issues

 Durability- Durability is a confusing term, In this context, durability means


the ability of the software to work without any issue for a long period of
time.

 Consistency – Software should be able to perform consistently over


platform and devices

 Maintainability – Bugs associated with any software should be able to


capture and fix quickly and news tasks and enhancement must be added
without any trouble

 Value for money – customer and companies who make this app should
feel that the money spent on this app has not fone to waste.

Software Quality ModelsSoftware

Quality Models
Software Quality Models are a standardized way of measuring a softwareproduct.

294
Software quality is the totality of features and characteristics of a product or
a service that bears on its ability to satisfy the given needs. Poor quality of
the software product in sensitive systems may lead to loss of human life,
permanent injury, mission failure, or financial loss. So, the quality of the
project should be maintained at appropriate label. To maintain the quality,
there are different quality models. "A high-quality product is one which has
associated with it a number of quality factors.

Types of Software Quality Models


Below are few quality models from the so-called Quality Management
Gurus.
1. McCall’s Quality model (1977)

Also called as General Electric’s Model. This model was mainly


developed for US military to bridge the gap between users and
developers. It mainly has 3 major representations for defining and
identifying the quality of a software product, namely Product
Revision : This identifies quality factors that influence the ability to
change the software product.

(1) Maintainability : Effort required to locate and fix a fault in the


program within its operating environment.

(2) Flexibility : The ease of making changes required as dictated by


business by changes in the operating environment.
(3) Testability : The ease of testing program to ensure that it is error- free
and meets its specification, i.e, validating the softwarerequirements.

Product Transition : This identifies quality factors that influence the


ability to adapt the software to new environments.

(1) Portability : The effort required to transfer a program from one


environment to another.

(2) Re-usability : The ease of reusing software in a different context.

(3) Interoperability: The effort required to couple the system to another


system.
Product Operations : This identifies quality factors that influence the
extent to which the software fulfills its specification.
(1) Correctness : The extent to which a functionality matches its
specification.

(2) Reliability : The system’s ability not to fail/ the extent to which the
system fails.
(3) Efficiency : Further categorized into execution efficiency and
storage efficiency and generally means the usage of system resources,
example: processor time, memory.

(4) Integrity : The protection of program from unauthorized access.

(5) Usability : The ease of using software.

2. Boehm’s Quality model (1978):


Boehm’s model is similar to the McCall Quality Model in that it also presents a
hierarchical quality model structured around high-level characteristics,
intermediate level characteristics, primitive characteristics – each of which
contributes to the overall quality level.
The high-level characteristics represent basic high-level requirements of actual
use to which evaluation of software quality could be put – the general utility of
software. The high-level characteristics address three main questions that a
buyer of software has:
• As-is utility: How well (easily, reliably, efficiently) can I use it as-is?
• Maintainability: How easy is it to understand, modify and retest?
• Portability: Can I still use it if I change my environment?

The intermediate level characteristic represents Boehm’s 7 quality factors that


together represent the qualities expected from a software system:

 Portability (General utility characteristics): Code possesses the characteristic


portability to the extent that it can be operated easily and well on computer
configurations other than its current one.

 Reliability (As-is utility characteristics): Code possesses the characteristic


reliability to the extent that it can be expected to perform its intended functions
satisfactorily.

 Efficiency (As-is utility characteristics): Code possesses the characteristic


efficiency to the extent that it fulfills its purpose without waste of resources.

 Usability (As-is utility characteristics, Human Engineering): Code possesses


the characteristic usability to the extent that it is reliable, efficient and human-
engineered.

 Testability (Maintainability characteristics): Code possesses the


characteristic testability to the extent that it facilitates the establishment of
verification criteria and supports evaluation of its performance.

 Understandability (Maintainability characteristics): Code possesses the


characteristic understandability to the extent that its purpose is clear to the
inspector.

296
 Flexibility (Maintainability characteristics, Modifiability): Code possesses
the characteristic modifiability to the extent that it facilitates the
incorporation of changes once the nature of the desired change has been
determined.

The lowest level structure of the characteristics hierarchy in Boehm’s model


is the primitive characteristics metrics hierarchy. The primitive characteristics
provide the foundation for defining qualities metrics – which was one of the goals
when Boehm constructed his quality model. Consequently, the model presents one
more metrics supposedly measuringa given primitive characteristic.

Though Boehm’s and McCall’s models might appear very similar, the difference
is that McCall’s model primarily focuses on the precise measurement of the high-
level characteristics “As-is utility”, whereas Boehm’s quality model is based on a
wider range of characteristics with an extended and detailed focus on primarily
maintainability.

3. Dromey’s Quality model(1995):


Dromey has built a quality evaluation framework that analyzes the quality of
software components through the measurement of tangible quality properties.
Each artifact produced in the software life cycle can be associated with a
quality evaluation model. Dromey gives the following examples of what he
means by software components for each of the different models:

 Variables, functions, statements, etc. can be considered components of the


Implementation model.

 A requirement can be considered a component of the requirements model.

 A module can be considered a component of the design model; According to


Dromey, all these components possess intrinsic properties that can be
classified into four categories:

 Correctness: Evaluates if some basic principles are violated.

 Internal: Measure how well a component has been deployed according to its
intended use.

 Contextual: Deals with the external influences by and on the use of a


component.

 Descriptive: Measure the descriptiveness of a component (for example, does


it have a meaningful name.) Dromey proposes a product-based quality model
that recognizes that quality evaluation differs for each product and that a
more dynamic idea for modeling the process is needed to be wide enough to
apply for different systems. Dromey is focusing on the relationship between
the quality attributes and the sub-attributes, as well as attempting to connect
software product properties with software quality attributes.
This quality model presented by R. Geoff Dromey is most recent model which
is also similar to McCall’s and Boehm’s model. Dromey proposes a product-
based quality model that recognizes that quality evaluation differs for each
product and that a more dynamic idea for modeling the process is needed to be
wide enough to apply for different systems. Dromey focuses on the
relationship between the quality attributes and the sub-attributes, as well as
attempts to connect software product properties with software quality
attributes.
1) Product properties that influence quality.
2) High level quality attributes.
3) Means of linking the product properties with the quality attributes.
Dromey’s Quality Model is further structured around a 5-step
process:
1) Choose a set of high-level quality attributes necessary for the
evaluation.
2) List components/modules in your system.
3) Identify quality-carrying properties for the components/modules
(qualities of the component that have the most impact on the product properties
from the list above).
4) Determine how each property effects the quality attributes.
5) Evaluate the model and identify weaknesses.
4. ISO IEC 9126 Model
As, many software quality models were proposed, the confusion happened,
and new standard model was required. Thus, ISO/IEC JTC1 began to develop
the required consensus and encourage standardization world-wide. The ISO
9126 is part of the ISO 9000 standard, and it is the most important standard for
quality assurance. The first considerations originated in 1978, and in the year
1985 the development of ISO/IEC 9126 was started.
In this model, for software development companies, the totality of software
product quality attributes was classified in a hierarchical tree structure of
characteristics and sub characteristics. And the highest level of this structure
consists of the quality characteristics and the lowest level consists of the
software quality criteria. This model specified six characteristics including
Functionality, the Reliability, Usability, Efficiency, Maintainability, and the
Portability; all of which are further divided into 21 sub characteristics. All
these sub characteristics are manifested externally when the software is used
as part of a computer system, and thus are the result of internal software
attributes. All the defined characteristics are applicable to every kind of
software, including computer programs and data contained in firmware and
provide consistent terminology for software product quality. And they also
provide a framework for making trade-offs between software product
capabilities.

298
5. FURPS Model -This model categorizes requirements into functional
and non-functional requirements. The term FURPS is an acronym for
Functional requirement(F) which relies on expected input and output,
and in non functional requirements (U) stands for Usability which
includes human factors, aesthetic, documentation of user material of
training, (R) stands for reliability(frequency and severity of failure,
time among failure), (P) stands for Performance that includes
functional requirements, and finally (S) stands for supportability that
includes backup, requirement of design and implementation etc.

6. Ghezzi Model -This model states that the internal qualities of a


software help the software developers to attain a collaborative result
both in terms of external and internal qualities of a software. The
overall qualities can be accuracy, flexibility, integrity, maintainability,
portability, reliability, re-usability and usability.

7. IEEE Model –It is a standard which defines various specifications for


software maintenance, thus providing a quality model. This model
gives a variety of measurement techniques for various qualitative
factors like efficiency, functionality, maintainability, portability,
reliability and usability.

8. SATC's Model -SATC is an acronym for Software Assurance


Technology Centre. Its objective is to improve software quality by
defining metrics program which helps to meet the basic needs with
least expenditure. This model tests a quality model by evaluating the
results of the metrics used, and also on the basis of discussions based
on the project. This model defines set of goals and process attributes
based on the structure of ISO 9126-1 quality model.

9. Capability Maturity Model -One of the most important quality


models of software quality maintenance. The model lays down a
very simple approach to define the quality standards. It has five levels
namely – initial, repeatable, defined, managed, optimizing.

At the initial level, the company is quite small, and it solely depends on an
individual how he handles the company. The repeatable level states that at
least the basic requirements or techniques have been established and the
organization has attained a certain level of success. By the next level thatis
, defined, the company has already established a set of standards for smooth
functioning of a software project/process. At the managed level, an
organization monitors its own activities through a data collection and
analysis. At the fifth level that is the optimizing level, constant improvement
of the prevailing process becomes a priority, a lot of innovative approach is
applied towards the qualitative enhancement.

14.2.5 ISO 9126


The ISO 9126 software is an international standard software quality model
that helps in creating a solid framework for assessing software. This standard
way of assessing software can be segregated in four different
ways. These are used to address subjects of different nature. This software is
profoundly used in a widespread way to embrace various models and metrics.
The recommended features describe externally when software is found to be a
result of attributes of internal attributes of software.
The following ways by which a standard software quality model can be
calculated are as follows:
1. Quality Model.
2. External Metrics.
3. Internal Metrics.
4. Quality in use Metrics.

Like every software, ISO 926 software model has distinct qualities. These are
laid on following basis:

1.Functionality
It is a key aspect of any product or service. It is due to this the software can
fulfill a task and keep to its purpose. It is defined as a software product that
helps to meet the needs of the clients. A functionality of software is dependent
on its complexity. For example: an ATM machine. This is further divided in
other categories are as follows:

 Suitability.
 Accuracy.
 Interoperability.
 Security.
 Functional compliance.

2. Reliability
This characteristic determines the capability of software to sustain its use
when put under different circumstances.

3. Usability

The usability of software is highly dependent on the functional uses of software.


For example: ATM machine is used to withdraw cash. According to the
usability of an ATM, the ATM is not affected or influenced by any amounts
entered by the user. This is further divided into other sub-categories, and these
are as follows:

 Maturity.
 Fault Tolerance.
 Recoverability.
 Reliability Compliance.

300
4. Efficiency
This feature of the model is more concerned by resources of the
system when used for providing a desired functionality. This type of
feature is defined by amount of disk space, memory, and network. This
is further divided into other sub-categories, and these are as follows:
 Understandability.
 Learner ability.
 Operability.
 Attractiveness.
 Usability Compliance.

5. Maintainability
This property of maintainability of the software model is used to
recognize and fix a defect accordingly. The model is inspected for the
faults, and these can be identified easily. In accordance with this the
cause and effect of maintainability of software is a concern. This is
further divided into other sub-categories, and these are as follows:

 Analyzability.
 Resource Utilization.
 Stability.
 Testability.
 Changeability.

6. Portability
According to this feature, capable software should easily adapt to the
environmental changes frequently as possible. The designing of an
object and the practices of its implementation are highly dependent on
this feature. This standard method is further divided in few categories:

 Adaptability.
 Install ability.
 Co-existence.
 Replaceability.
 Portability compliance.

Product and Process Metrics What is process


and product metrics?
Product metrics − Describes the characteristics of the product such as size,
complexity, design features, performance, and quality level. Process metrics
− These characteristics can be used to improve the development and
maintenance activities of the software.
Software Metrics
A software metric is a measure of software characteristics which are
measurable or countable. Software metrics are valuable for many reasons,
including measuring software performance, planning work items,
measuring productivity, and many other uses.
Within the software development process, many metrics are that are all
connected. Software metrics are like the four functions of management:
Planning, Organization, Control, or Improvement.
Classification of Software Metrics
Software metrics can be classified into two types as follows:
1. Product Metrics: These are the measures of various characteristics of
the software product. The two important software characteristics are:
1. Size and complexity of software.
2. Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
3. Process Metrics: These are the measures of various characteristics of the
software development process. For example, the efficiency of fault detection.
They are used to measure the characteristics of methods, techniques, and
tools that are used for developing software.

Figure 14.1 classification of software metrics

300
Types of Metrics
Internal metrics: Internal metrics are the metrics used for measuring
properties that are viewed to be of greater importance to a software
developer. For example, Lines of Code (LOC) measure.

External metrics: External metrics are the metrics used for measuring
properties that are viewed to be of greater importance to the user, e.g.,
portability, reliability, functionality, usability, etc.

Hybrid metrics: Hybrid metrics are the metrics that combine product,
process, and resource metrics. For example, cost per FP where FP stands for
Function Point Metric.

Project metrics: 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. Also understand that these
metrics are used to decrease the development costs, time efforts and risks.
The project quality can also be improved. As quality improves, the number
of errors and time, as well as cost required, is also reduced.

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 bedone 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
qualityduring 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.
Product versus Process Quality Management What is product
quality and process quality?
Product Quality: Means that the product is according to the specifications
gathered by Businesss Analyst AND is bug free.Process Quality: Means the
process abopted by the company to test the application should be defined well
enough that it covers all the aspect of the application
Product:
In the context of software engineering, Product includes any software
manufactured based on the customer’s request. This can be a problem- solving
software or computer based system. It can also be said that this is the result of a
project.
Process:
Process is a set of sequence steps that have to be followed to create a project.
The main purpose of a process is to improve the quality of the project. The
process serves as a template that can be used through the creation of its examples
and is used to direct the project.
The main difference between a process and a product is that the process is a set
of steps that guide the project to achieve a convenient product. while on the other
hand, the product is the result of a project that is manufactured by a wide variety
of people.

Software

Software

Software Software
Figure 14.2 Process and product quality

300
It is general, that the quality of the development process directly affects
the quality of delivered products. The quality of the product can be
measured, and the process is improved until the proper quality level is
achieved. Figure 14.3. illustrates the process of quality assessment based on
this approach.

Figure 14.3 Process based quality assessment


In manufacturing systems there is a clear relationship between production
process and product quality. However, quality of software is highly
influenced by the experience of software engineers. In addition, it is difficult
to measure software quality attributes, such as maintainability, reliability,
usability, etc., and to tell how process characteristics influence these
attributes. However, experience has shown that process quality has a
significant influence on the quality of the software.

Process quality management includes the following activities:


1. Defining process standards.

2. Monitoring the development process.


3. Reporting the software.

Quality Management Systems


Software quality management (SQM) is a management process that aims
to develop and manage the quality of software in such a way so as to best
ensure that the product meets the quality standards expected by the customer
while also meeting any necessary regulatory and developer requirements, if
any. Software quality managers require software to be tested before it is
released to the market, and they do this using a cyclical process-based
quality assessment to reveal and fix bugs before release. Their job is not
only to ensure their software is in good shape for the consumer but also to
encourage a culture of quality throughout the enterprise

Quality management activities

Software quality management activities are generally split up into three core
components: quality assurance, quality planning, and quality control.
Some like software engineer and author Ian Sommerville don't use the term
"quality control" (as quality control is often viewed as more a
manufacturing term than a software development term), rather, linking its
associated concepts with the concept of quality assurance. However, the three
core components otherwise remain the same.

Quality assurance
Software quality assurance sets up an organized and logical set of organizational
processes and deciding on that software development standards — based on
industry best practices — that should be paired with those organizational
processes, software developers stand a better chance of producing higher quality
software. However, linking quality attributes such as "maintainability" and
"reliability" to processes is more difficult in software development due to its
creative design elements versus the mechanical processes of manufacturing.
Additionally, "process standardization can sometimes stifle creativity, which
leads to poorer rather than better quality software."
This stage can include:

 encouraging documentation process standards, such as the creationof


well-defined engineering documents using standard templates
 mentoring how to conduct standard processes, such as qualityreviews
 performing in-process test data recording procedures
 identifying standards, if any, that should be used in software
development processes

Quality planning
Quality planning works at a more granular, project-based level, defining the
quality attributes to be associated with the output of the project and how those
attributes should be assessed. Additionally, any existing organizational standards
may also be assigned to the project at this phase. Attributes such as "robustness,"
"accessibility," and "modularity" may be assigned to the software development
project. While this may be a more formalized, integral process, those using a
more agile method of quality management may place less emphasis on strict
planning structures.[3] The quality plan may also address intended market,
critical release dates, quality goals, expected risks, and risk management policy.

Quality control
The quality control team tests and reviews software at its various stages to
ensure quality assurance processes and standards at both the organizational and
project level are being followed. Some like Sommerville link these
responsibilities to quality assurance rather than call it quality control. These
checks are optimally separate from the development team to lend more of an
objective view of the product to be tested. However, project managers on the
development side must also assist, helping to promote as part of this phase a
"culture that provides support without blame when errors are discovered." In
software development firms implementing a more agile quality approach,
these

306
activities may be less formal; however, a switch to agile methods from a
more formal quality management structure may create problems if
management procedures aren't appropriately adapted.

Activities include:

 release testing of software, including proper documentation of the


testing process
 examination of software and associated documentation for non-
conformance with standards
 follow-up review of software to ensure any required changes
detailed in previous testing are addressed
 application of software measurement and metrics for assessment

Process Capability Models


Process Capability Modeling

L. Bauer Published 2002Computer Science Every production process is


subject to variations that limit our ability to produce a defect-free product.
Process capability models (PCMs) are used to quantify likely process
variations, which can then be included during the analysis of a product
design. PCMs facilitate the flowback of capability information from
manufacturing/sourcing to design and are an essential element of Design for
Six Sigma (DFSS). This paper discusses how process capability can be
measured and modeled, how models can be organized and saved, and how
models can be retrieved, evaluated, and applied

Capability Maturity Model (CMM) is a methodology used to develop,


refine maturity of an organization’s software development process. It is
developed by SIE in mid 1980. It is a process improvement approach.

To assess an organization against a scale of 5 process maturity levels. It


Deals with the what processes should be implemented & not so much with
the how processes should be implemented. Each maturity level comprises a
predefined set of process areas called KDA (Key Process Area), these KDA
– Goals, Commitment, Ability, measurement, verification.

Levels of Capability Maturity Model (CMM) are as following below.

1. Level One : Initial – Work is performed informally. A software


development organization at this level is characterized by AD HOC
activities (organization is not planned.).

2. Level Two : Repeatable – Work is planned and tracked. This level of


software development organization has a basic and consistent project
management processes to TRACK COST, SCHEDULE, AND
FUNCTIONALITY. The process is in place to repeat the earlier successes
on projects with similar applications.
3. Level Three : Defined – Work is well defined. At this level the software
process for both management and engineering activities are DEFINED AND
DOCUMENTED.

4. Level Four : Managed – Work is quantitatively controlled.

 Software Quality management – Management can effectively control the


software development effort using precise measurements. At this level,
organization set a quantitative quality goal for both software process and
software maintenance.

 Quantitative Process Management – At this maturity level, the


performance of processes is controlled using statistical and other quantitative
techniques, and is quantitatively predictable.

5. Level Five : Optimizing – Work is Based Upon ContinuousImprovement.


The key characteristic of this level is focusing on CONTINUOUSLY
IMPROVING PROCESS performance.

Key features are:


 Process change management 

 Technology change management 

 Defect prevention

Techniques to Help Enhance Software Quality


Seven Ways to Improve Software Quality Which Will Not Break the Bank

The project management lifecycle is not complete without quality assurance and
businesses are shifting their focus to build a high-quality product. If you are
somehow related to an application or software, then you are surely looking out for
ways to ensure the quality of your product without breaking the bank. Exceptional
software quality practices promise cost-effectiveness and enhance the performance
of the product being delivered.

It is recommended to start implementing testing strategies at the initial stage as


bugs can be easily identified and fixed. Bug identification in the later stage of the
project may result in a complication that will eventually out-turn in more cost
and time. To ensure that their testing goes in theright direction, consider using
defect tracking software from the start ofthe testing. If issues are highlighted and
solved in the initial stage, then it is a win-win situation and efficiency of the
results is also increased. Issues can be exacerbated if they are not identified timely,
and an expensive exercise would be carried out to fix the damage.

Instead of spending unnecessary time and resources on the project to fix the
software issues one should shift maximum focus on the quality of the

308
software from the start. Below mentioned are seven points which one should
consider increasing software quality and follow an assured approach through
the development.

1. Test Often and Early


Early testing is paramount for a successful quality product and this
aspect neither can be ignored nor delayed. If testing is carried out often
and in the early phase, then issues and bugs won’t snowball into larger
complications. If an issue becomes complex, then it means it will set
off to be more expensive and can’t be ironed out easily.
Testers need to be involved at earliest so that they remain at top of
all issues and cater to issues timely. Adopt an early automation
approach from basic UI tests and then accelerate it as the project
stabilizes.
2. Implement Quality Controls
Testers and developers should work in partnership from the start and
monitor quality controls as it ensures that set standards are being
met. This is an ongoing process that starts from the beginning and is
carried out until the product is delivered. Testers and developers
should work shoulder to shoulder to develop software strategy and
deal with bugs in a structured way.
3. Promote Innovation
As much it is appreciated to follow important testing structures along
with quality metrics, it is also endorsed to think out of the box. A great
way to promote innovation is to automate the monotonous processes
and that sufficient time can be saved and used wisely.
4. Incorporate Management Tools
Effective quality management tools can help the team to build a
sustainable business. Stakeholders are only concerned about their
product and its quality as they expect companies to do whatever it
takes to meet the quality standards. With the right tools, transparency
is increased, and employees do not get drained while performing day
to day operations. Defect tracking software, issue tracking tool, project
management software, and test automation tools are among the few
which every software testing company should have.
5. Employee Training
Technology is evolving day by day and to cope up with the
advancements, it is important to embrace the change and train your
team accordingly. Professional training should be promoted, and
employees should be encouraged to opt for certifications to work in
their best capacity. As tools and techniques upgrade with each passing
day, employees should upgrade their skill set in a similar manner.
6. Error Management and Analysis
An organized approach should be adapted to track the issues and manage
the risk. For successful software development, a risk register plays a vital
role and so does defect tracking software. These tools help to keep
everyone informed regarding the risks and defects in the systems so
everyone can play their part in proposing a convenient solution and
resolving ambiguities.

7. Review, Revise and Remember


A high-quality product is not a coincidence, and it can’t happen overnight.
It goes through a repeated process of review, revise, and remember which
are explained as follows.

Review: Testers constantly review the code and ensure that set quality standards
are being met.

Revise: To study the software process and understand which aspects worked for
the project and which require more improvement. Analyze if innovation can
transcend and changes can be made.

Remember: While delivering a quality product, note down what worked for you
and what areas didn’t align. List down all positives and negatives of a successful
project.

Final Thoughts

The success of your software product highly depends on the way you deal with it
from the initial phase and how intelligently you manage the issues encountered.
It is imperative that your team knows what they are working on and what is
expected from them to be delivered. The testing team should come up with a
clear plan to start with the entire process.

iTexico and Improving's nearshore delivery model for software quality assurance
and collaborative, results-driven approach is designed around the success of
your project. We’ll make use of the right technologies and tools for your
strategic goals and work closely with your in-house team to ensure a timely
delivery.

Testing and Software Reliability


Software testing can be stated as the process of verifying and validating that
software or application is bug-free, meets the technical requirements as guided
by its design and development, and meets the user requirements effectively and
efficiently with handling all the exceptional and boundary cases.

The process of software testing aims not only at finding faults in the existing
software but also at finding measures to improve the software in terms of
efficiency, accuracy, and usability. It mainly aims at measuring the specification,
functionality, and performance of a software program or application.

308
Software testing can be divided into two steps:
1. Verification: it refers to the set of tasks that ensure that software
correctly implements a specific function.
2. Validation: it refers to a different set of tasks that ensure that the
software that has been built is traceable to customer requirements.

Verification: “Are we building the product, right?”


Validation: “Are we building the right product?”

What are different types of software testing?


Software Testing can be broadly classified into two types:

1. Manual Testing: Manual testing includes testing software manually,


i.e., without using any automated tool or any script. In this type, the
tester takes over the role of an end-user and tests the software to
identify any unexpected behavior or bug. There are different stages for
manual testing such as unit testing, integration testing, system testing,
and user acceptance testing.
Testers use test plans, test cases, or test scenarios to test software to
ensure the completeness of testing. Manual testing also includes
exploratory testing, as testers explore the software to identify errors in
it.

2. Automation Testing: Automation testing, which is also known as


Test Automation, is when the tester writes scripts and uses another
software to test the product. This process involves the automation of a
manual process. Automation Testing is used to re-run the test
scenarios that were performed manually, quickly, and repeatedly.

Apart from regression testing, automation testing is also used to test


the application from a load, performance, and stress point of view. It
increases the test coverage, improves accuracy, and saves time and
money in comparison to manual testing.

What are the different techniques of Software Testing?


Software techniques can be majorly classified into three categories:
1. Black Box Testing: The technique of testing in which the tester
doesn’t have access to the source code of the software and is
conducted at the software interface without concern with the internal
logical structure of the software is known as black-box testing.

2. White-Box Testing: The technique of testing in which the tester is


aware of the internal workings of the product, has access to its
source code, and is conducted by making sure that all internal
operations are performed according to the specifications is known as
white box testing.
Black Box Testing White Box Testing

Internal workings of an application Knowledge of the internal workings


are not required. is a must.

Also known as closed box/data- Also known as clear box/structural


driven testing. testing.

Normally done by Testers and


End users, testers, and developers.
developers.

This can only be done by a trial and Data domains and internal
error method. boundaries can be better tested.

Table 14.1 Comparison between black box and white box testing

3. Gray Box testing


Gray box testing is a combination of white box and Black box testing. It
can be performed by a person who knew both coding and testing. And if
the single person performs white box, as well as black-box testing for the
application, is known as Gray box testing.
What are different levels of software testing?
Software level testing can be majorly classified into 4 levels:
1. Unit Testing: A level of the software testing process where individual
units/components of a software/system are tested. The purpose is to
validate that each unit of the software performs as designed.
2. Integration Testing: A level of the software testing process where
individual units are combined and tested as a group. The purpose of this
level of testing is to expose faults in the interaction between integrated
units.
3. System Testing: A level of the software testing process where a complete,
integrated system/software is tested. The purpose of this test is to evaluate
the system’s compliance with the specified requirements.
4. Acceptance Testing: A level of the software testing process where a
system is tested for acceptability. The purpose of this test is to evaluate the
system’s compliance with the business requirements and assess whether
it is acceptable for delivery

312
Unit Testing

Integration Testing

System Testing

Acceptance Testing

Figure14.4 Different levels of software testing

Software Reliability
Software Reliability means Operational reliability. It is described as the
ability of a system or component to perform its required functions under static
conditions for a specific period.

Software reliability is also defined as the probability that a software system


fulfills its assigned task in a given environment for a predefined number of
input cases, assuming that the hardware and the input are freeof error.
Software Reliability is an essential connect of software quality, composed
with functionality, usability, performance, serviceability, capability, install
ability, maintainability, and documentation. Software Reliability is hard to
achieve because the complexity of software turn to be high. While any system
with a high degree of complexity, containing software, will be hard to reach a
certain level of reliability, system developers tend to push complexity into the
software layer, with the speedy growth of system size and ease of doing so by
upgrading the software.

For example, large next-generation aircraft will have over 1 million source
lines of software on-board; next-generation air traffic control systems will
contain between one and two million lines; the upcoming International Space
Station will have over two million lines on-board and over 10 million lines of
ground support software; several significant life- critical defense systems will
have over 5 million source lines of software. While the complexity of
software is inversely associated with software reliability, it is directly related
to other vital factors in software quality, especially functionality, capability,
etc.
A good software reliability engineering program, introduced early in the
development cycle, will mitigate these problems by: Preparing program
management in advance for the testing effort and allowing them to plan both
schedule and budget to cover the required testing.
Continuous review of requirements throughout the life cycle, particularly for
handling of exception conditions. If requirements are incomplete there will be no
testing of the exception conditions.

SoHaR software reliability engineers are experienced in all the stages and tasks
required in a comprehensive software reliability program. We can support or
lead tasks such as:
1) Reliability Allocation

2) Defining and Analyzing Operational Profiles


3) Test Preparation and Plan

4) Software Reliability Models


1. Reliability Allocation:-

Reliability allocation is the task of defining the necessary reliability of a


software item. The item may be part of an integrated hardware/software
system, may be a relatively independent software application, or, more and
more rarely, a standalone software program. In either of these cases our
goal is to bring system reliability within either a strict constraint required
by a customer or an internally perceived readiness level or optimize
reliability within schedule and cost constraints.

SoHaR will assist your organization in the following tasks:

Derive software reliability requirements from overall system reliability


requirements.

When possible, depending on lifecycle stage and historical data,


estimate schedule and cost dependence on software reliability goals.

Optimize reliability/schedule/cost based on your constraints and your


customer's requirements,

2. Defining and Analyzing Operational Profiles:-

The reliability of software, much more so than the reliability of hardware,


is strongly tied to the operational usage of an application. A software fault
may lead to system failure only if that fault is encountered during
operational usage. If a fault is not accessed in a specific operational mode,
it will not cause failures at all. It will cause failure more often if it is in
code that is part of an often used "operation" (An operation is defined as a
major logical task, usually repeated multiple times within an hour of
application usage). Therefore, in software reliability engineering we
focus on the
314
operational profile of the software which weighs the occurrence
probabilities of each operation. Unless safety requirements indicate a
modification of this approach, we will prioritize our testing according
to this profile.
SoHaR will work with your system and software engineers to
complete the following tasks required to generate a useable
operational profile:
Determine the operational modes (high traffic, low traffic, high
maintenance, remote use, local use etc).
Determine operation initiators (components that initiate the operations
in the system).
Determine and group "Operations" so that the list includes only
operations that are significantly different from each other (and
therefore may present different faults).
Determine occurrence rates for the different operations.
Construct the operational profile based on the individual operation
probabilities of occurrence.
3. Test Preparation and Plan:-

Test preparation is a crucial step in the implementation of an effective


software reliability program. A test plan that is based on the
operational profile on the one hand, and subject to the reliability
allocation constraints on the other, will be effective at bringing the
program to its reliability goals in the least amount of time and cost.
Software Reliability Engineering is concerned not only with feature
and regression test, but also with load test and performance test. All
these should be planned based on the activities outlined above.

The reliability program will inform and often determine the following
test preparation activities:

Assessing the number of new test cases required for the current
release.

New test case allocation among the systems (if multi-system).

New test case allocation for each system among its new operations.

Specifying new test cases


Adding the new test cases to the test cases from previous releases.

4. Software Reliability Models:-


Software reliability engineering is often identified with reliability
models, in particular reliability growth models. These, when applied
correctly, are successful at providing guidance to management
decisions such as:
Test schedule
Test resource allocationTime
to market
Maintenance resource allocation
Quality Plans
Quality planning is the process of developing a quality plan for a project. The
quality plan defines the quality requirements of software and describes how these
are to be assessed. The quality plan selects those organizational standards that are
appropriate to a particular product and development process. Quality plan has the
following parts:
1. Introduction of product.
2. Product plans.
3. Quality goals.
4. Risks and risk management.
The quality plan defines the most important quality attributes for the software and
includes a definition of the quality assessment process. Table
14.2. shows generally used software quality attributes that can beconsidered
during the quality planning process

Table 14.2 Software quality attributes

SUMMARY

In this software quality chapter, you learned about The Place of Software
Quality in Project Planning, Importance of Software Quality, Defining
Software Quality, Software Quality Models, ISO 9126, Product and
Process Metrics, Product versus Process Quality Management, Quality
Management Systems, Process Capability Models, Techniques to Help
Enhance Software Quality, Testing and its types, Software Reliability,
Quality Plans etc. Still, you had a doubt go through references and
bibliography

EXERCISE

 Explain place of Software Quality in Project Planning


 Write about Importance of Software Quality
316
o Explain in detail Software Quality Models and it’s types.
o What is process and product metrics?
o Write short notes on software metrics
o Write about types of software metrics
o What are the advantages and disadvantages of software metrics?
o Explain in detail Product versus Process Quality Management
o Write short notes on Quality Management Systems
o Explain in detail Process Capability Models
o Write about Techniques to Help Enhance Software Quality
o Explain different levels of software testing
o Compare black box testing and white box testing
o Explain software testing and it’s types in detail
 Explain different levels of software testing
o What are the Quality Plans?
o Explain Software Reliability

14.5 LIST OF BOOKS AND REFERENCES

1. Software Project Management Bob Hughes, Mike Cotterell, Rajib


Mall TMH 6 th 2018
2. Project Management and Tools & Technologies – An overview
Shailesh Mehta SPD 1st 2017
3. Software Project Management Walker Royce Pearson 2005
4. https://smartbear.com
5. https://www.tutorialspoint.com
6. https://www.professionalqa.com
7. http://moodle.autolab.uni-pannon.hu
8. https://en.wikipedia.org
9. https://www.semanticscholar.org
10. https://www.itexico.com
11. https://www.geeksforgeeks.org
12. https://www.javatpoint.com


317

You might also like