Unit No:1

Software Quality Assurance

Fundamentals
By
Dr. Rekha Chouhan
Important Links / Reference Books:
1.Https://www.youtube.com/watch?v=sCuY6xVOBPM
2. Roger S. Pressman, “Software Engineering-A
Practitioner’s Approach”, McGraw Hill pub.2010
3. Software Testing Techniques by Boris Beizer-
DreamTech Pub,2nd Edition
4. Software Testing by Ron Patton, TechMedia Pub
5. Fundamentals of Software Engineering –Rajib Mall,
3rd Edition
6. https://www.youtube.com/watch?v=zSyICkGZ6iM
7.https://www.softwaretestingmaterial.com/selenium
-tutorial/
8. https://www.toolsqa.com/selenium-tutorial/
9. www.guru99.com/software-testing.html
10.
https://www.youtube.com/watch?v=rkieMbKZFeg
11. https://
www.youtube.com/watch?v=0viDDeGLODs
Lecture-1-Introduction to Software Quality Assurance
Agenda:
1. Quality
2. Software Quality
3. Software Quality Assurance(SQA)
4. Software Quality Control (SQC)
5. SQA v/s SQC
What is Quality?

Quality – developed product meets it’s specification

Problems:
• Development organization has requirements exceeding customer's
specifications (added cost of product development)
• Certain quality characteristics can not be specified in
unambiguous terms (i.e. maintainability)
• Even if the product conforms to it’s specifications, users may
not consider it to be a quality product (because users may not be involved in
the development of the requirements)

5
Lecture-1-Introduction to Software Quality Assurance
Agenda:
1. Quality
2. Software Quality
3. Software Quality Assurance(SQA)
4. Software Quality Control (SQC)
5. SQA v/s SQC
Lecture-2-Introduction to Software Quality Assurance
Agenda:
1. Software Quality Control (SQC)
2. SQA v/s SQC
 Quality Definition
• Quality means that a product satisfies the
demands of its specifications
• It also means achieving a high level of customer
satisfaction with the product
• In software systems this is difficult
– customer quality requirements (e.g. efficiency or
reliability) often conflict with developer quality
requirements (e.g. maintainability or reusability)
– software specifications are often incomplete,
inconsistent, or ambiguous
What is Quality?
Quality is defined as the product or services that should be "fit for use and purpose."
Quality is all about meeting the needs and expectations of customers concerning
functionality, design, reliability, durability, and price of the product.

What is Assurance?
Assurance is a positive declaration on a product or service. It is all about the product
which should work well. It provides a guarantee which would work without any problem
according to expectations and requirements.250Prime
What is Quality Assurance?
Quality Assurance is also known as QA Testing. QA is defined as an activity to ensure
that an organization is providing the best product or service to the customers.

Software Quality Assurance seems it is all about evaluation of software based on

functionality, performance, and adaptability; however software quality assurance goes
beyond the quality of the software, it also includes the quality of the process used to
develop, test and release the software.

Software Quality assurance is all about the Software Development lifecycle that includes
requirements management, software design, coding, testing, and release management.

Quality Assurance is the set of activities that defines the procedures and standards to
develop the product.

Quality Assurance is a systematic way of creating an environment to ensure that the

software product being developed meets the quality requirements. This process is
controlled and determined at the managerial level. It is a preventive process whose aim
is to establish the correct methodology and standard to provide a quality environment
to the product being developed. Quality Assurance focuses on process standard,
projects audit, and procedures for development. QA is also known as a set of activities
designed to evaluate the process by which products are manufactured.
QA focused on improving the processes to deliver Quality Products.

What is the Quality Attribute of a software?

The following six characteristics can define the quality of the software:

1. Functionality
Quality of software is defined as how effectively the software interacts with other
components of the system. The software must provide appropriate functions as per
requirement, and these functions must be implemented correctly.

2. Reliability
It is defined as the capability of the software to perform under specific conditions for a
specified duration.

3. Usability
Usability of software is defined as its ease of use. Quality of the software is also
identified as how easily a user can understand the functions of the software and how
much efforts are required to follow the features.

4. Efficiency
The efficiency of the software is dependent on the architecture and coding practice
followed during development.
5. Maintainability
Maintainability is also one of the significant factors to define the quality of the
software. It refers to identify the fault and fix in the software. It should be stable when
the changes are made.

6. Portability
Portability of the software, defined as how easily a system adapts to changes in the
specifications. Quality of the software is also determined by the portability of the
system how easy it is to install the software and how easy it is to replace a component
of the order in a given environment.

To ensure about a software score well on these quality attribute, we need the following
software Quality Assurance.
Lecture-3-Introduction to Software Quality Assurance
Agenda:
1. Building blocks of SQA / SQA Components
https://www.youtube.com/watch?v=tj2LwVZ6NX4
2. SQA Planning & Standards (ISO 9000, Six Sigma)
https://www.youtube.com/watch?v=Kz_7njsDUMQ
https://www.youtube.com/watch?v=4djhUDZx3yA
https://www.youtube.com/watch?v=ErEqnPDs2Tg

Lecture-4-Agenda:
2. Software Quality Factors
 Quality Management Activities
• Quality assurance
– establishing organizational quality standards and
procedures
• Quality planning
– selecting and modifying applicable quality standards and
procedures for a particular project
• Quality control
– ensuring quality standards and procedures are followed
by development team

Note: Quality management should be separated from project

management to ensure independence.
What are Software Quality Assurance components?
Software Quality Assurance has six classes of components.

1. Pre-project Plan
Pre-project Plan ensures that the resources required for project, schedule, and budget
should be clearly defined. Plan for development and ensuring quality has been
determined.

Components are as:

o Required Resources (Hardware and Human resources)

o Development plan
o Schedules
o Risk evaluation
o Quality plan
2. Project lifecycle component
A project lifecycle usually comprised of two stages:

1. Development Stage

In the Development Stage Component, Software Quality Assurance help to identify the
design and programming errors. Its Components are divided into the following sub -
classes: Reviews, Expert Opinions, and Software Testing.

2. Operation Maintenance Stage

In Operation Maintenance Stage, the Software Quality Assurance components include

the Development lifecycle component along with specialized components whose aim is
to improve the maintenance tasks.
3. Infrastructure error prevention and improvement components
The aim of this component is to the prevention of software faults and minimizes the rate
of errors.

These components are as:

o Procedure and work instructions

o Templates and Checklists
o Staff Training, Retainingand Certification
o Preventive and Corrective Actions
o Configuration Management
o Documentation Control

4. Software Quality Management Components

This class of component consists of controlling development and maintenance activities.
These components establish the managerial control of software development projects.
The management component aims to prevent the project from going over budget and
behind schedule.

The management components include:

o Project Progress Control

o Software Quality Metrics
o Software Quality Costs
5. Standardization, Certification, and SQA assessment
components
Aim of these components is to implement international managerial and professional
standards within the organization. These components help to improve the coordination
among the Organizational Quality Systems and establish standards for the project
process. The component includes:

o Quality management standards

o Project process standard

6. Organizing for Software Quality Assurance ? the human

elements
The main aim of this class of components is to initiate and support the implementation
of Software Quality Assurance components, identify any deviations from the predefined
Software Quality Assurance procedures, methods, and recommended improvements.
The Software Quality Assurance organizational team includes test managers, testers,
SQA unit SQA committee, and SQA forum members.
How many types of Software Quality Assurance Tools?
Various QA tools help with quality assurance. There are different QA tools required for
different purposes. For comprehensive software quality assurance, we will need a
different kind of tool which is also known as QA software.

o Infrastructure
o Release Management
o Source Control
o Code Reviews
o Automates Code Analysis
o Peer Code Reviews
o Testing
o Test management
o Bug and Issue Tracking
o Browser, Device and OS Testing
o Usability Testing
o Load Testing
o Automates Testing and Continuous Integration
o Monitoring and Analytics
o Availability Monitoring
o Business Analytics
o Exception Handling
o Log Monitoring
o Performance Monitoring
o Security Testing and Monitoring
o Customer Support
How to do Quality Assurance?
The whole process of quality assurance has to define the cycle called the PDCA cycle.

Phases of this cycle are as:

o Plan
o Do
o Check
o Act
Plan: The organization should plan and establish the process related objectives and
determine the process that is required to deliver a high-quality end product.
Do: Development and testing of processes and also change in the methods.
Check: Monitoring of processes, modify the methods, and check whether it meets the
predetermined objectives.
Act: Implement actions that are necessary to achieve improvements in the process.
An organization must use Quality Assurance to ensure that the product is designed and
implemented with correct procedures. This will help to reduce problems and errors in the
final product.
What Is Quality Management?
Quality management is the performance of managing various activities and
responsibilities within a system to guarantee that products and services are given, as
well as the means used to produce them, are compatible. It serves to manage and
have an aspired level of quality within the company.
Quality management consists of four essential elements, which cover the following:
Quality Planning – The method of classifying the quality measures related to the
project and determining how to reach them
Quality Improvement – The deliberate setting of a process to enhance the resolution
or safety of the result
Quality Control – The progressive attempt to support a process’s honesty and safety in
delivering an outcome
Quality Assurance – The regular or recommended actions needed to offer enough
security so that a particular service or goods will fasten the defined requirements

Quality management aims to guarantee that all the organization’s stakeholders work
collectively to change the company’s rules, products, services, and experience to
deliver the long-term benefit that arises from client happiness.
Quality Improvement Methods
Quality improvement systems include three elements: product improvement, method
improvement, and people-based improvement. There are various ways of quality management
and methods that can be used. They include Kaizen, Zero Defect Programs, Six Sigma, Quality
Circle, Taguchi Methods, the Toyota Production System, Kansei Engineering, TRIZ, BPR, OQRM,
ISO, and Top-Down & Bottom-Up requests among others.
Why are Standards Important?
• Standards provide encapsulation of best, or at least most
appropriate, practice
• Standards provide a framework around which the quality
assurance process may be implemented
• Standards assist in continuity of work when it’s carried out by
different people throughout the software product lifecycle

Standards should not be avoided. If they are too extensive

for the task at hand, then they should be tailored.

27
 Quality Standards
• Key to effective quality management
• Product standards define the characteristics
exhibited by all components (e.g. programming
style issues)
• Process standards describe how a software process
is to be implemented
• Should encapsulate best practices - this helps avoid
repeating past mistakes
• Provide continuity by giving new team members a
means to understand the organizational priorities
Process Improvement is Continuous Improvement
We can never reach to perfection. The CMM too is evolving and improving. The focus is on
always doing better.

What is CMM ?
CMM stands for Capability Maturity Model.

Focuses on elements of essential practices and processes from various bodies of knowledge.

Describes common sense, efficient, proven ways of doing business (which you should already be
doing) - not a radical new approach.

CMM is a method to evaluate and measure the maturity of the software development process
of an organizations.

CMM measures the maturity of the software development process on a scale of 1 to 5.

CMM v1.0 was developed by the Software Engineering Institute (SEI) at Carnegie Mellon
University in Pittsburgh, USA.
 What is Maturity ?
Definitions vary but mature processes are generally thought to be:
Well defined
Repeatable
Measured
Analyzed
Improved
The CMM helps to solve the maturity problem by defining a set of practices and providing a
general framework for improving them. The CMM focus is on identifying key process areas and
the exemplary practices that may comprise a disciplined software process.
Immature vs Mature Organization:
There are following characteristics of an immature organization:
•Process improvised during project
•Approved processes being ignored
•Reactive, not proactive
•Unrealistic budget and schedule
•Quality sacrificed for schedule
•No objective measure of quality
There are following characteristics of an mature organization:
•Inter-group communication and coordination
•Work accomplished according to plan
•Practices consistent with processes
•Processes updated as necessary
•Well defined roles/responsibilities
•Management formally commits
What is CMMI ?
CMM Integration project was formed to sort out the problem of using multiple CMMs.
CMMI Product Team's mission was to combine three Source Models into a single
improvement framework to be used by the organizations pursuing enterprise-wide
process improvement. These three Source Models are :
•Capability Maturity Model for Software (SW-CMM) - v2.0 Draft C
•Electronic Industries Alliance Interim Standard (EIA/IS) - 731 Systems Engineering
•Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98
CMM Integration:
•- builds an initial set of integrated models.
•- improves best practices from source models based on lessons learned.
•- establishes a framework to enable integration of future models.

Difference between CMM and CMMI:

CMM is a reference model of matured practices in a specified discipline like Systems
Engineering CMM, Software CMM, People CMM, Software Acquisition CMM etc. But
they were difficult to integrate as and when needed.
CMMI is the successor of the CMM and evolved as a more matured set of guidelines
and was built combining the best components of individual disciplines of CMM(Software
CMM, People CMM etc). It can be applied to product manufacturing, People
management, Software development etc.
CMM describes about the software engineering alone where as CMM Integrated
describes both software and system engineering. CMMI also incorporates the Integrated
Process and Product Development and the supplier sourcing.
A maturity level is a well-defined evolutionary plateau toward achieving a mature software
process. Each maturity level provides a layer in the foundation for continuous process
improvement.
CMMI models with staged representation, have five maturity levels designated by the numbers 1
through 5. They are −
Initial
Managed
Defined
Quantitatively Managed
Optimizing

CMMI Staged Representation Maturity Levels:

The following image shows the maturity levels in a CMMI staged representation.
 Process Area (PA’s)

A Process Area is a cluster of related practices in an area that, when implemented

collectively, satisfy a set of goals considered important for making significant
improvement in that area. All CMMI process areas are common to both continuous
and staged representations.
The continuous representation enables the organization to choose the focus of its
process improvement efforts by choosing those process areas, or sets of interrelated
process areas, that best benefit the organization and its business objectives. Although
there are some limits on what an organization can choose because of the dependencies
among process areas, the organization has considerable freedom in its selection.

Once you select the process areas, you must also select how much you would like to
improve the processes associated with those process areas (i.e., select the appropriate
capability level). Capability levels, and generic goals and practices, support the
improvement of processes in individual process areas.
Conversely, we will see that the staged representation encourages us to always look at
process areas in the context of the maturity level to which they belong. The process
areas are organized by maturity levels to reinforce this concept. When we use a process
area, we use the entire process area i.e, all goals and all practices.
The CMMI Process Areas (PAs) can be grouped into the following four categories to
understand their interactions and links with one another regardless of their defined
levels:
•Process Management
•Project Management
•Engineering
•Support

Each process area is defined by a set of goals and practices. There are two categories
of goals and practices −
•Generic goals and practices − They are a part of every process area.
•Specific goals and practices − They are specific to a given process area.
A process area is satisfied when the processes of a company cover all of the generic
and specific goals and practices for that process area.
Maturity Levels and Process Areas
Here is a list of all the corresponding process areas defined for a software organization. These
process areas may be different for different organization.
Level Focus Key Process Area Result

5 Continuous Organizational Innovation and Highest

Process Deployment Quality
Optimizing Improvement /
Causal Analysis and Lowest
Resolution Risk

4 Quantitatively Higher
Organizational Process
Quantitatively Managed Performance Quality
Managed / Lower
Quantitative Project Risk
Management

3 Process Medium
Requirements Development
Defined Standardization Quality
Technical Solution /
Medium
Product Integration
Risk
Verification
Validation
Organizational Process Focus
Organizational Process
Definition
Organizational Training
Integrated Project Mgmt (with
IPPD extras)
Risk Management
Decision Analysis and
Resolution
Integrated Teaming (IPPD
only)
Org. Environment for
Integration (IPPD only)
Integrated Supplier
Management (SS only)
2 Basic Project Management Requirements Management Low Quality /
Managed High Risk
Project Planning

Project Monitoring and Control

Supplier Agreement Management

Measurement and Analysis

Process and Product Quality Assurance

Configuration Management

1 Process is informal and   Lowest Quality

Adhoc / Highest Risk
Initial
 Six Sigma
Six Sigma is the process of improving the quality of the output by identifying and eliminating the
cause of defects and reduce variability in manufacturing and business processes. The maturity of
a manufacturing process can be defined by a sigma rating indicating its percentage of defect-free
products it creates. A six sigma method is one in which 99.99966% of all the opportunities to
produce some features of a component are statistically expected to be free of defects (3.4
defective features per million opportunities).
Six Sigma stands for 6 standard deviations (6σ) between avarage and acceptable limits. LSL and
USL stand for “Lower Specification Limit” and “Upper Specification Limit” respectively.
Specification Limits are derived from the customer requirements, and they specify the minimum
and maximum acceptable limits of a process.
 History of Six Sigma
Six-Sigma is a set of methods and tools for process improvement. It was
introduced by Engineer Sir Bill Smith while working at Motorola in
1986. In the 1980s, Motorola was developing Quasar televisions which
were famous, but the time there was lots of defects which came up on
that due to picture quality and sound variations.
Six Sigma is a quality management methodology used to help
businesses improve current processes, products or services by
discovering and eliminating defects.
By using the same raw material, machinery and workforce a Japanese
form took over Quasar television production, and within a few months,
they produce Quasar TV's sets which have fewer errors. This was
obtained by improving management techniques.
Six Sigma was adopted by Bob Galvin, the CEO of Motorola in 1986
and registered as a Motorola Trademark on December 28, 1993, then it
became a quality leader.
Characteristics of Six Sigma

The Characteristics of Six Sigma are as follows:

Statistical Quality Control: Six Sigma is derived from the Greek Letter σ (Sigma) from the Greek
alphabet, which is used to denote Standard Deviation in statistics. Standard Deviation is used to
measure variance, which is an essential tool for measuring non-conformance as far as the
quality of output is concerned.

Methodical Approach: The Six Sigma is not a merely quality improvement strategy in theory, as
it features a well defined systematic approach of application in DMAIC and DMADV which can be
used to improve the quality of production. DMAIC is an acronym for Design-Measure- Analyze-
Improve-Control. The alternative method DMADV stands for Design-Measure- Analyze-Design-
Verify.

Fact and Data-Based Approach: The statistical and methodical aspect of Six Sigma shows the
scientific basis of the technique. This accentuates essential elements of the Six Sigma that is a
fact and data-based.

Project and Objective-Based Focus: The Six Sigma process is implemented for an organization's
project tailored to its specification and requirements. The process is flexed to suits the
requirements and conditions in which the projects are operating to get the best results.

Customer Focus: The customer focus is fundamental to the Six Sigma approach. The quality
improvement and control standards are based on specific customer requirements.
Teamwork Approach to Quality Management: The Six Sigma process requires organizations to
get organized when it comes to controlling and improving quality. Six Sigma involving a lot of
training depending on the role of an individual in the Quality Management team.
 Six Sigma Methodologies
Six Sigma projects follow two project methodologies:
1. DMAIC
2. DMADV

DMAIC
It specifies a data-driven quality strategy for improving processes. This methodology is used to
enhance an existing business process.
The DMAIC project methodology has five phases:
1.Define: It covers the process mapping and flow-charting, project charter development,
problem-solving tools, and so-called 7-M tools.
2.Measure: It includes the principles of measurement, continuous and discrete data, and scales of
measurement, an overview of the principle of variations and repeatability and reproducibility
(RR) studies for continuous and discrete data.
3.Analyze: It covers establishing a process baseline, how to determine process improvement
goals, knowledge discovery, including descriptive and exploratory data analysis and data mining
tools, the basic principle of Statistical Process Control (SPC), specialized control charts, process
capability analysis, correlation and regression analysis, analysis of categorical data, and non-
parametric statistical methods.
4.Improve: It covers project management, risk assessment, process simulation, and design of
experiments (DOE), robust design concepts, and process optimization.
5.Control: It covers process control planning, using SPC for operational control and PRE-
Control.
What is the difference between Quality Control and
Quality Assurance?
Quality Control is to examine the product or service and check for the result. Quality
assurance is to explore the processes which led to the end-product.

Here are the following differences:

Quality Assurance Quality Control

Quality Assurance prevents defects. Quality Control provides identification of

defects.

Quality Assurance is process oriented. Quality control is product oriented.

Quality Assurance is proactive in the Quality Control is a reactive.

process and protective.

Quality Assurance is a managerial tool. Quality Control is a corrective tool.

Each developer is responsible for Quality The testing team is responsible for Quality
Assurance. Control.

Verification is an example of QA. Validation is an example of QC.

The focus of QA is to prevent defects in the The focus of QC is to identify deficiencies in the
developing software by paying attention to developed software by paying attention to
processes. testing processes.
Quality Assurance vs Quality Control

Quality Assurance
Software quality assurance is (also known as QA) a sequence of tasks to prevent defects and
ensure that the techniques, methods, approaches, and processes are designed for a specific
application must be implemented correctly. This is an ongoing process within the development of
a software system.
The development of units of an application is checked under the quality assurance specifications
in the sequence of their development.
Quality assurance test ensures the development of high-quality software because of its main
focus on the high-quality processes, good quality management system and periodic conformance
audit during the development of software. It is a managerial tool includes planned and systematic
activities and documentation to prevent problems related to quality.
The responsibility of quality assurance is not of any specific team, but it is a responsibility of
each member of the development team.

Quality assurance prevents defects.

Quality assurance is process oriented.
Quality assurance is proactive in a process and preventive in nature.
Quality assurance is a managerial tool.
Each developer is responsible for quality assurance.
Quality Control

Quality Control also known as QC is a sequence of tasks to ensure the quality of
software by identifying defects and correction of defects in the developed software. It
is a reactive process, and the main purpose of this process is to correct all types of
defects before releasing the software. The process is done by eliminating sources of
problems (which cause to low the quality) through the corrective tools so that software
can meet customer's requirements and high quality.
The responsibility of quality control is of a specific team which is known as a testing
team that tests the defects of software by validation and corrective tools.

1.Quality Control provides identification of defects.

2.Quality Control is product oriented.
3.Quality Control is a corrective tool.
4.Testing team is responsible for Quality control.
5.Quality Control is a reactive process.
What is Quality Control?
Quality Control popularly abbreviated as QC is a software engineering process
used to ensure quality in a product. It does not deal with the processed used
to create a product. Instead, it examines the quality of the end product and the
outcome.
The main aim of Quality Control is to check whether the product meets the
specification and requirement of the customer. If an issue is identified.
Difference between Quality Assurance and Quality Control
Points Quality Assurance Quality Control

Definition QA is a group of activities which ensures QC is a group of activities to detect the

that the quality of processes which is used defects in the developed software.
during the development of the software
always be maintained.

Focus The focus of QA is to prevent defects in The focus of QC is to identify defects in

the developing software by paying the developed software by paying attention
attention to processes. to testing processes.

How Establishment of the high-quality Detecting and eliminating the quality

management system and periodic audits problem elements by using testing
for conformance of the operations of the techniques and tools in the developed
developing software. software.

What QA ensures prevention of quality problem QC ensures identification and elimination of

elements by using systematic activities defects by using processes and techniques
including documentation. to achieve and maintain high quality of the
software.

Orientation QA is process oriented. QC is product oriented.

Type of process QA is a proactive process. It concerns to QC is a reactive process because it concerns

improve development so; defects do not to identify defects after the development of
arise in the testing period. product and before its release.

Responsibility Each and every member of the Only the specific testing team is responsible
development team is responsible for QA for QC

Example Verification is the example of QA Validation is the example of QC

What are the activities of Quality Control and Quality
Analysis?
These are the following activities of quality control and quality analysis:

Quality Assurance Activities Quality Control Activities

Quality Assurance activity works on the quality audit. Quality control activities involve
walkthrough.

The define the process is one of the activities of quality Quality control involves testing.
assurance

Tool identification and selection. Quality control involves

inspection.

Quality Assurance activity involves training of Quality Quality control requires

Standards and processes. checkpoint review.

All the activities are concerned for QA and QC of any product, not for Software.

In the case of software

o QA will act as SQA (Software quality assurance)

o QC will act as Software Testing
Sr. Software Quality Assurance Software Testing
No.

1. Software Quality Assurance is about engineering Software Testing is to test a product

process that ensures quality. for problems before the product goes
live.

2. It involves activities related to the implementation of It involves operation concerning

processes, procedures and standard Example: Audit verification of product Example:
Training. Review Testing.

3. Software Quality Assurance is Process focused. Software testing is product focused.

4. Software Quality Assurance used preventive Software testing used the corrective
technique. technique.

5. Software Quality Assurance is based on a proactive Software testing is a reactive

measure. measure.

6. The software quality assurance applied to all the The scope of software testing applies
products that will be created by the organization. to a particular product being tested.
What are the differences between Software Quality
Assurance and Software Testing?
What are the types of Quality Assurance Function?
There are five types of Quality Assurance Function.

1. Technology Transfer This function involves getting a project design document

as well as trial and error data and its evaluation. The documents are distributed,
checked, and approved.
2. Validation For the entire system, validation master plan is prepared. Resource
planning for execution of a validation plan is done.
3. Documentation This function controls the distribution and archiving of
documents. Any change in document is adopting the proper change control
procedures.
4. Quality assurance function also involves assuring the quality of products.
5. It also involves quality improvement plans.

WRAP UP:

Quality Assurance focuses on the developed product is fit for use. For any organization,
processes and standard should be followed. It concentrates mainly on the quality of the
product/service that we provide to the customers during or after implementation of the
software.
Software Quality Factors
There are some characteristic common to all these “but’s”:

■ All the software projects satisfactorily fulfilled the basic

requirements for correct calculations

■ All the software projects suffered from poor performance

in important areas such as maintenance, reliability, software
reuse, or training.

■ The cause for the poor performance of the developed

software projects in these areas was the lack of predefined
requirements to cover these important aspects of the
software’s functionality.
We need what is called
software quality factors
that is included in
requirements document
There are different software quality
factors and models.
The classic software quality factory
model is
McCall software quality
factor
 Software quality factors

Product operation factors

Product revision factors

Product transition factors

• Correctness
• Reliability
• Efficiency
• Integrity
• Usability
 Product operation factors
• Correctness: extent to which a program
fulfills its specification.
• Reliability: ability not to fail.
• Efficiency: use of resources execution and
storage.
• Integrity: protection of the program from
unauthorized access.
• Usability: ease of use of the software.
104
• Maintainability
• Flexibility
• Testability
 Product revision factors
• Maintainability: effort required to locate
and fix a fault in a program.
• Flexibility: ease of making changes
required by changes in operating
environment.
• Testability: ease of testing the program
to ensure that it is error-free and meets
its specification.
106
• Portability
• Reusability
• Interoperability
 Product transition factors
• Portability: Effort required to transfer a
program from one environment to
another system.
• Reusability: ease of re-using software in
a different context.
• Interoperability: effort required to
couple a system to another system.

108
Software quality factors
Criteria for evaluation of software quality

Examples:
• Flight software that flies on a single mission
satellite will not be concerned with portability but
may be very concerned with reliability.
• A software system that remains on the ground
may be concerned with portability and not very
concerned by reliability.

111
How Does McCall factors improve quality

• McCall quality factors could be used as a

reference when preparing requirements
document. Most, if not all, of those
factors should be covered explicitly in
the software requirements document.
• Measuring those factors tell us where
we need improvement. We can use
quality metrics
 Software quality factors in requirements
document

Correctness
• Employees salaries should not be late (Wrong)
• Employees salaries should be calculated accurately and must be ready
five days before the end of the month (Correct)

Reliability
• The system should be working as much time as possible (Wrong)
• The system should not be in failure status during working hours (9 to 4).
Total time of failure status should not exceed 20 minutes per month.
(Correct)
 Software quality factors in requirements
document

Efficiency
• The GPS application should use as little as possible of mobile phone
battery (Wrong)
• The GPS application should not use more than 10% of battery power in
two hours time (Correct)

Integrity
• Students should be allowed to access their final marks(Wrong)
• Students should be allowed to view their final marks. They should not be
able to make any changes (Correct)
 Software quality factors in requirements
document

Usability
• The billing system should be easy to use (Wrong)
• Billing staff should be able to learn the most important five functions of
the billing system in 3 working hours.
Software Quality Metrics

116
Metrics Collection
• Software measurement - the process of deriving a numeric value
for some attribute of a software product or a software process. Comparison of
these values to each other and to STD’s allows drawing conclusions about the
quality of software products or the process.

• The focus of the metrics collecting programs is usually on collecting metrics on

program defects and the V&V process.

• Metrics can be either Control Metrics or Predictor Metrics

• Most of the “Ilities” can not be measured directly unless there’s historical data.
Instead tangible software product attributes are measured and the “Ility” factors are
derived using predefined relationships between measurable and synthetic attributes.

• The boundary conditions for all measurements should be established in advance

and then revised once a large databank of historical data has been established

117
 Software Measurement and Metrics
• Software measurement is concerned with
deriving a numeric value for an attribute of a
software product or process
• This allows for object comparisons bewteen
techniques or processes
• The systematic use of measurement is
essential to process improvement programs
 Software Metric
• Any type of measurement that relates to a
software system, process, or document
– LOC, person-months, function points
• Metrics allow for the quantification of the
software or a software process
• May be used to predict product attributes or
to control the software process
 Metrics Assumptions
• The software property of interest can be measured
• There is a known relationship between what we want
to measure and what we want to know
• The relationship has been formalized and validated
• It may be difficult to relate what can be measured to
desirable quality attributes
The Process of Product Measurement

1. Decide what data is to be collected

2. Assess critical (core) components first
3. Measuring component characteristics might require automated tools
4. Look for consistently (unusually only works in a factory) high or low values
5. Analysis of anomalous components should reveal if the quality of product is
compromised

121
Predictor and Control Metrics

Examples of Predictor Analysis:

• Code Reuse: SLOC = ELOC = Ported Code
• Nesting Depth: ND > 5 = Low Readability
• Risk Analysis: # STR P1 > 0 at SAT = Low Product Reliability

Examples of Control Analysis:

• STR aging: Old STRs = Low Productivity
• Requirements Volatility: High Volatility = Scope Creep
122
Software Product Metrics
There are two categories of software product metrics:
1. Dynamic metrics – this metrics is collected by measuring elements
during program’s execution. This metrics help to asses efficiency and
reliability of a software product. The parameters collected can be
easily measured (i.e. execution time, mean time between failures)

2. Static metrics – this metrics is collected by measuring parameters of

the end products of the software development. This metrics help to
asses the complexity, understandability, and maintainability of a
software product. The SLOC size and ND are the most reliable
predictors of understandability, complexity, and maintainability.

123
The Ilities

The specific metrics that are relevant

depend on the on the project, the goals of
the SQA, and the type of SW that is being
developed.

124
Examples of Software Metric

125
Examples of OO Software Metric

126
Defect Prevention
Defect Prevention – establishment of practices that lower the reliance
on defect detection techniques to find majority of the bugs

• Lessons learned – learning from other peoples experiences and sharing own
experiences with the other projects
• Managing With Metrics – collecting the metrics, understanding it, and making
changes to the product or process based on analysis. Metrics must be standardized to
be effective.
• Risk Analysis – identifying potential risks and opportunities early in the program
and tracking them to realization.
• Build freeze – no changes are made to the code during formal tests.
• Unit-level testing guidelines – test plans and procedures for each UT
• Baseline acceptance criteria – establishment of closure criteria in advance (i.e. no
P1 STRs at FAT TRR)

127
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 free of error.
Software Reliability is an essential connect of software quality, composed with functionality,
usability, performance, serviceability, capability, installability, 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.
 Reliability Metrics
Reliability metrics are used to quantitatively expressed 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 (MTBR)
We can merge MTTF & MTTR metrics to get the MTBF metric.
                  MTBF = MTTF + MTTR
Thus, an MTBF of 300 denoted that once the 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 unexpected
role is likely to appear. A ROCOF of 0.02 mean 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 Metrics for Reliability

The Metrics are used to improve the reliability of the system by identifying the areas of
requirements.
Different Types of Software Metrics are:-

Reliability Metrics
Requirements Reliability Metrics
Requirements denote what features the software must include. It specifies the functionality that
must be contained in the software. The requirements must be written such that is no
misconception between the developer & the client. The requirements must include valid
structure to avoid the loss of valuable data.