Unit-5

Software Quality:
software quality, software quality engineering, defining quality
requirements, quality standards, practices & conventions, ISO
9000, ISO 9001, software quality matrices, managerial and
organization issues, defect prevention, reviews & audits, SEI
capability maturity model, PSP, six sigma
A software quality product refers to software that meets or exceeds
established quality standards and requirements. Software quality is a
measure of the degree to which software is free from defects, errors, and
bugs, and performs as expected in terms of functionality, reliability,
efficiency, maintainability, and usability.

A quality software product is one that is well-designed, well-

documented, thoroughly tested, and meets the needs of its intended
users. It is also one that is easy to use, reliable, scalable, and can be
maintained and upgraded over time.
Example: Consider a functionally correct software product. That is, it
performs all tasks as specified in the SRS document. But, has an almost
unusable user interface. Even though it may be functionally right, we
cannot consider it to be a quality product.
Terminologies associated with Software
Quality
• Portability: A software device is said to be portable, if it can be freely made to work
in various operating system environments, in multiple machines, with other software
products, etc.
• Usability: A software product has better usability if various categories of users can
easily invoke the functions of the product.
• Reusability: A software product has excellent reusability if different modules of the
product can quickly be reused to develop new products.
• Correctness: A software product is correct if various requirements as specified in the
SRS document have been correctly implemented.
• Maintainability: A software product is maintainable if bugs can be easily corrected
as and when they show up, new tasks can be easily added to the product, and the
functionalities of the product can be easily modified, etc.
Software Quality Management System

A quality management system is the principal methods used by

organizations to provide that the products they develop have the desired
quality.
A quality system subsists of the following:
1. Managerial Structure and Individual Responsibilities: A quality
system is the responsibility of the organization as a whole. However, every
organization has a sever quality department to perform various quality
system activities. The quality system of an arrangement should have the
support of the top management. Without help for the quality system at a
high level in a company, only some members of staff will take the quality
system seriously.
Quality System Activities: The quality system activities encompass the
following:
1. Auditing of projects
2. Review of the quality system
3. Development of standards, methods, and guidelines, etc.
4. Production of documents for the top management summarizing the
effectiveness of the quality system in the organization.
Evolution of Quality Management System

• Quality systems have increasingly evolved over the last five decades.
Before World War II, the usual function to produce quality products
was to inspect the finished products to remove defective devices.
Since that time, quality systems of organizations have undergone
through four steps of evolution, as shown in the fig. The first product
inspection task gave method to quality control (QC).
• Quality control target not only on detecting the defective devices and removes them but also on determining
the causes behind the defects. Thus, quality control aims at correcting the reasons for bugs and not just
rejecting the products. The next breakthrough in quality methods was the development of quality assurance
methods.
• The primary premise of modern quality assurance is that if an organization's processes are proper and are
followed rigorously, then the products are obligated to be of good quality. The new quality functions include
guidance for recognizing, defining, analyzing, and improving the production process.
• Total quality management (TQM) advocates that the procedure followed by an organization must be
continuously improved through process measurements. TQM goes stages further than quality assurance and
aims at frequently process improvement. TQM goes beyond documenting steps to optimizing them through a
redesign. A term linked to TQM is Business Process Reengineering (BPR)
• BPR aims at reengineering the method business is carried out in an organization. From the above
conversation, it can be stated that over the years, the quality paradigm has changed from product assurance to
process assurance, as shown in fig.
• Non-functional requirements are the criteria for evaluating how a
software system should perform rather than what it should do. An
example would be a requirement for a web API endpoint response
time to be under 200ms.
• When we say that a software product should be “secure”, “highly-
available”, “portable”, “scalable” and so on, we are talking about
its quality attributes.
• In other words, a software product must have certain quality
attributes to meet certain non-functional requirements.
Software Quality Requirements

ISO/IEC 25010 categorization of software quality requirements

 1. Functional Suitability
• i.e. what does the app do? In particular:
• Functional completeness—is the app in line with the specification? Does it have the functions it was supposed to have?
• Functional correctness—does it provide the correct results?
• Functional appropriateness —does it fulfill its function?
2. Performance efficiency
—does the app use an optimal amount of resources?
Time behavior—are the response and processing times or throughput rates reasonable?
Resource utilization—are the amounts and types of resources used reasonable?
Capacity—are the maximum limits reasonable? 
If the app is supposed to be performant or handle larger amounts of data, we can propose more server power or suggest other solutions based
on available funds. It’s all down to resource optimization. 
3. Compatibility
—can the app work cross-platform or share data with other products, systems or components?
Co-existence—can the app share a common environment and resources with other products?
Interoperability—can it exchange information and use the information that has been exchanged?
4. Usability
• —can specific users use the app in specific conditions?
• As you know, every app is different and has different users. In the case of an app we developed we had to adjust the UI for users of all ages and make it run
on all kinds of phones, including feature phones.
• Appropriateness recognizability—can users can recognize whether the app is appropriate for their needs?
• Learnability—is it easy to learn how the app works?
• Operability—is the app easy to operate and control?
• User error protection—does the app protect users against making errors?
• User interface aesthetics—is the user interface pleasing to the eye? (watch out—that’s a very subjective issue!)
• Accessibility—can the app be used by people of all characteristics and capabilities?
• The last factor is particularly important, as we should keep in mind all sorts of prospective users that might end up using our app. For this purpose, I’d
recommend checking out the Axe accessibility browser tool—a handy extension for verifying apps e.g. against color-blindness. 
5. Reliability
• —an extremely important issue. Here, we look closer at:
• Maturity—how stable is the app during everyday use?
• Availability—can the users use the app when they need to? Remember, some apps really need to work under specific conditions. E.g., when we were
building an app for farriers, it was really important for the app to work offline, because many pastures may be out of the mobile broadband reach.
• Fault tolerance—can the app work even when there are some hardware or software faults?
• Recoverability—in the event of an interruption or a failure, can the app recover the data affected directly and re-establish the system? For a bank or any
other business dealing with large amounts of data, recoverability is of prime importance.
6. Security
• —does the app protect information and data? For EU countries this is additionally connected with GDPR rules, which we
need to be particularly aware of.
• Confidentiality—is data accessible only to authorized people?
• Integrity—does the app prevent unauthorized access to, or modification of, computer programs or data? 
• Non-repudiation—does the app collect information whether specific actions or events have taken place? 
• Accountability—can the actions of an entity can be traced back to that particular entity?
• Authenticity—can you prove the identity of a subject or resource?
• To help apps comply with the above requirements, make sure that the provided databases are secure and compliant
with OAuth 2.0 standards.
7. Maintainability
• will it be possible for the app to be modified or improved in the future, or will it adapt to changes in the environment?
• Modularity—if an app is built with components, does changing one component impact other components? (Which makes any
changes to the app easier and faster.)
• Reusability—can an asset be used in more than one system, or in building other assets? Again, this might be extremely time-
saving when changing or expanding the app.Analyzability—is it easy to analyze any activities in the app that need to be taken
into account? (Again, do not overanalyze. Look at what is important.)
• Modifiability—is the app easy to modify without harming present product quality?Testability—can the app be tested, also
automatically?
• Maintainability should be taken into account at the planning stage of the app development cycle. Therefore, the best practice is
to engage a QA team member at the very beginning of the process. You see, if you take a QA on board to join a set of
developers, you will be able to foresee any possible future requirements and save yourself a lot of effort (and money) down the
line. Also, instead of fixing things on the go, you will be able to build a well-planned, robust app.
8. Portability
• can the software be used in various environments?
• Adaptability—can the app be adapted for different or evolving hardware, software or other operational or usage environments?
• Installability—is key for mobile apps—can they be successfully installed and/or uninstalled in a specified environment?
• Replaceability—can the app replace another software product for the same purpose in the same environment?
• Try Visit the given Link
• https://simplicable.com/new/quality-requirements
ISO 9000 STANDARDS SERIES

• ISO (International Standards Organization) is a group or consortium of 63

countries established to plan and fosters standardization. ISO declared its 9000
series of standards in 1987. It serves as a reference for the contract between
independent parties. The ISO 9000 standard determines the guidelines for
maintaining a quality system. The ISO standard mainly addresses operational
methods and organizational methods such as responsibilities, reporting, etc.
• They are not specific to any one industry and can be applied to organizations
of any size.
• ISO 9000 can help a company satisfy its customers, meet regulatory
requirements, and achieve continual improvement. It should be considered to
be a first step or the base level of a quality system.
ISO 9000 history and revisions: ISO 9000:2000,
2008, and 2015
• The ISO 9000:2015 and ISO 9001:2015 standards are based on seven quality
management principles that senior management can apply to promote
organizational improvement.
• Customer focus
• Understand the needs of existing and future customers
• Align organizational objectives with customer needs and expectations
• Meet customer requirements
• Measure customer satisfaction
• Manage customer relationships
• Aim to exceed customer expectations
• Leadership
• Establish a vision and direction for the organization
• Set challenging goals
• Model organizational values
• Establish trust
• Equip and empower employees
• Recognize employee contributions
• Engagement of people
• Ensure that people’s abilities are used and valued
• Make people accountable
• Enable participation in continual improvement
• Evaluate individual performance
• Enable learning and knowledge sharing
• Enable open discussion of problems and constraints
• Process approach
• Manage activities as processes
• Measure the capability of activities
• Identify linkages between activities
• Prioritize improvement opportunities
• Deploy resources effectively
• Improvement
• Improve organizational performance and capabilities
• Align improvement activities
• Empower people to make improvements
• Measure improvement consistently
• Celebrate improvements
• Evidence-based decision making
• Ensure the accessibility of accurate and reliable data
• Use appropriate methods to analyze data
• Make decisions based on analysis
• Balance data analysis with practical experience
• Relationship management
• Identify and select suppliers to manage costs, optimize resources, and create
value
• Establish relationships considering both the short and long term
• Share expertise, resources, information, and plans with partners
• Collaborate on improvement and development activities
• Recognize supplier successes
Software metrics can be classified into three categories −

1. Product metrics − Describes the characteristics of the product such as size, complexity, design features, performance, and
quality level.
2. Process metrics − These characteristics can be used to improve the development and maintenance activities of the
software.
3. Project metrics − This metrics describe the project characteristics and execution. Examples include the number of
software developers, the staffing pattern over the life cycle of the software, cost, schedule, and productivity.

• Some metrics belong to multiple categories. For example, the in-process quality metrics of a project are both process
metrics and project metrics.
• Software quality metrics are a subset of software metrics that focus on the quality aspects of the product, process, and
project. These are more closely associated with process and product metrics than with project metrics.

Software quality metrics can be further divided into three categories −

• Product quality metrics
• In-process quality metrics
• Maintenance quality metrics
1. Product Quality Metrics: This metrics include the following −
1. Mean Time to Failure
2. Defect Density
3. Customer Problems
4. Customer Satisfaction
• Mean Time to Failure
It is the time between failures. This metric is mostly used with safety critical systems such as the airline traffic control systems, avionics, and weapons.
• Defect Density
It measures the defects relative to the software size expressed as lines of code or function point, etc. i.e., it measures code quality per unit. This metric is used in m
commercial software systems.
• Customer Problems
It measures the problems that customers encounter when using the product. It contains the customer’s perspective towards the problem space of the software, wh
includes the non-defect oriented problems together with the defect problems.

The problems metric is usually expressed in terms of Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented problems) for a time period + Total number of license months of the software during
the period Where,
Number of license-month of the software = Number of install license of the software × Number of months in the calculation period
PUM is usually calculated for each month after the software is released to the market, and also for monthly averages by year.

• Customer Satisfaction
Customer satisfaction is often measured by customer survey data through the five-point scale −
1. Very satisfied
2. Satisfied
3. Neutral
4. Dissatisfied
5. Very dissatisfied
Satisfaction with the overall quality of the product and its specific dimensions is usually obtained through various methods of customer surveys. Based on the five-po
scale data, several metrics with slight variations can be constructed and used, depending on the purpose of analysis. For example −
Percent of completely satisfied customers
Percent of satisfied customers
Percent of dis-satisfied customers
Percent of non-satisfied customers
2. In-process Quality Metrics:
In-process quality metrics deals with the tracking of defect arrival during formal machine testing for some organizations. This metric includes −

• Defect density during machine testing

• Defect arrival pattern during machine testing
• Phase-based defect removal pattern
• Defect removal effectiveness
• Defect density during machine testing

Defect rate during formal machine testing (testing after code is integrated into the system library) is correlated with the defect rate in the field. Higher defect rates
found during testing is an indicator that the software has experienced higher error injection during its development process, unless the higher testing defect rate is
due to an extraordinary testing effort.
This simple metric of defects per KLOC or function point is a good indicator of quality, while the software is still being tested. It is especially useful to monitor
subsequent releases of a product in the same development organization.

Defect arrival pattern during machine testing

The overall defect density during testing will provide only the summary of the defects. The pattern of defect arrivals gives more information about different quality
levels in the field. It includes the following −

The defect arrivals or defects reported during the testing phase by time interval (e.g., week). Here all of which will not be valid defects.

The pattern of valid defect arrivals when problem determination is done on the reported problems. This is the true defect pattern.
The pattern of defect backlog overtime. This metric is needed because development organizations cannot investigate and fix all the reported problems immediately.
This is a workload statement as well as a quality statement. If the defect backlog is large at the end of the development cycle and a lot of fixes have yet to be
integrated into the system, the stability of the system (hence its quality) will be affected. Retesting (regression test) is needed to ensure that targeted product quality
levels are reached.

3. Maintenance metrics are measurements that give you insight into how everything and everyone is operating at your facility. They quantify the daily
activity of maintenance, and in doing so, paint a picture of how people and assets are working.
 Defect Prevention Methods And Techniques

A simple equation equivalent can be:

QA= QC (defect identification) + Defect prevention
Defect Prevention
Defect Prevention is a crucial step or activity in any software development process and as can be seen from the below
diagram is pretty much half of our testing tasks:
The following are the defect prevention responsibilities for testers in each of the below stages:
1) Requirement Specification Review:
After understanding customer’s requirements prepare your requirement’s gist.
A review is important at this step- the First level of review should be within the team, followed by another level of external
review (by a dev or BA or client) to make sure that all the perspectives are in sync.
2) Design Review:
Design stage can be considered a strategy stage of sorts and going through it will ensure that the QA team understands the
pros and cons of each strategy.
This kind of critical walkthrough will help unearth any problems with the said strategies and fix them before going further.
This can be considered a feasibility study for the strategy (or strategies).
3) Code Review:
There is not a lot for testers to directly get involved in this phase, but the review does go on here too. Developers carry out
code inspections, walkthroughs and reviews before they unit and integration test the application.
Defect Prevention Methods and Techniques:
Some traditional and common methods that have been in use since a long time for defect prevention are listed below;
1) Review and Inspection: This method includes the review by an individual team member (self-checking), peer reviews and
inspection of all work products.
2) Walkthrough: This is more or less like a review but it’s mostly related to comparing the system to the prototype which will
give a better idea regarding the correctness and/or the look-and-feel of the system.
3) Defect Logging and Documentation: This method provides some key information, arguments/parameters that can be used to
support analyzing defects.
4) Root Cause Analysis: Root cause analysis includes two major approaches:

I) Pareto Analysis:
Pareto analysis is a formal and simple technique which helps prioritize the order of problem resolution for maximum impact.
It states that 80% of the problem arises due to 20% reasons.
Therefore, the problems once identified are prioritized according to frequency and a detailed statistics based analysis is
performed as to find which 20% of the reasons attributed to the 80% problems.
II) Fishbone Analysis:
Also known as Ishikawa Analysis this method is a more visual root cause analysis technique.
There are no statistics involved as this method is based on team-wide brainstorming.
The following diagram helps understand this better.
The problem is first written on the rightmost side and on the horizontal line that passes through it, the various causes are listed.
The branch that has the most cause-subclause bones (or lines/branches) is the problem that is most serious and that is to be
worked towards elimination. This technique is also sometimes called cause and effect analysis.
What is Capability Maturity Model?
The Software Engineering Institute (SEI) Capability Maturity Model (CMM) specifies an increasing series of levels of a
software development organization. The higher the level, the better the software development process, hence reaching each
level is an expensive and time-consuming process
1. Level One :Initial - The software process is characterized as inconsistent, and occasionally even chaotic. Defined processes and standard
practices that exist are abandoned during a crisis. Success of the organization majorly depends on an individual effort, talent, and
heroics. The heroes eventually move on to other organizations taking their wealth of knowledge or lessons learnt with them.

2. Level Two: Repeatable - 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.
Program management is a key characteristic of a level two organization.

3. Level Three: Defined - The software process for both management and engineering activities are documented, standardized, and
integrated into a standard software process for the entire organization and all projects across the organization use an approved, tailored
version of the organization's standard software process for developing,testing and maintaining the application.

4. Level Four: Managed - 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. At this maturity level, the performance
of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable.

5. Level Five: Optimizing - The Key characteristic of this level is focusing on continually improving process performance through both
incremental and innovative technological improvements. At this level, changes to the process are to improve the process performance
and at the same time maintaining statistical probability to achieve the established quantitative process-improvement objectives.
Personal Software Process (PSP)
The SEI CMM which is reference model for raising the maturity levels of software and predicts the most expected outcome from the next
project undertaken by the organizations does not tell software developers about how to analyze, design, code, test and document the software
products, but expects that the developers use effectual practices. The Personal Software Process realized that the process of individual use is
completely different from that required by the team.

Personal Software Process (PSP) is the skeleton or the structure that assist the engineers in finding a way to measure and improve the way of
working to a great extend. It helps them in developing their respective skills at a personal level and the way of doing planning, estimations
against the plans.

Objectives of PSP :
The aim of PSP is to give software engineers with the regulated methods for the betterment of personal software development processes.
The PSP helps software engineers to:
1. Improve their approximating and planning skills.
2. Make promises that can be fulfilled.
3. Manage the standards of their projects.
4. Reduce the number of faults and imperfections in their work.
Time measurement:
Personal Software Process recommend that the developers should structure the way to spend the time.The developer must measure and count
the time they spend on different activities during the development.
PSP Planning :
The engineers should plan the project before developing because without planning a high effort may be wasted on unimportant activities which may lead to
a poor and unsatisfactory quality of the result.
Levels of Personal Software Process :
Personal Software Process (PSP) has four levels-
1. PSP 0 –
The first level of Personal Software Process, PSP 0 includes Personal measurement , basic size measures, coding standards.
2. PSP 1 –
This level includes the planning of time and scheduling .
3. PSP 2 –
This level introduces the personal quality management ,design and code reviews.
4. PSP 3 –
The last level of the Personal Software Process is for the Personal process evolution.