Software Quality Standards - ISO25010 - CAPSTONE PROJECT 2

Software Quality Standards—
How and Why We Applied

ISO 25010
CAPSTONE PROJECT 2
By: Assoc. Prof. Mary Ann F. Aballiar-Vista
source: https://www.monterail.com/blog/software-qa-standards-iso-25010 1
LIFE CYCLE OF INTERNATIONAL ISO STANDARDS FOR
SOFTWARE DEVELOPMENT EVALUATION
source: https://www.iso.org/standard/35733.html 2
LIFE CYCLE OF INTERNATIONAL ISO STANDARDS FOR
SOFTWARE DEVELOPMENT EVALUATION
▪ The Differences Between ISO 25010, ISO 9126, and ISTQB

▪ The previous standard for software quality measurement was ISO/IEC 9126. It
categorized software quality into six characteristics (factors), which were further broken
down into sub characteristics (criteria).
▪ ISO 25010, however, introduced two additional factors, therefore the difference between
the two lies mainly in how they categorize and define those characteristics of software
quality requirements that we call non-functional.
▪ ISTQB, on the other hand, is an internationally accepted software testing certification
and it is generally believed that securing the certification can improve the quality of
testing being performed. The certificate naturally proves the high quality of software
testing, but it’s not exactly a tool you will get to use much in your daily life. The ISO
standard is a much more precise reflection of reality and offers a much better description
of what QA really is.
source: https://www.monterail.com/blog/software-qa-standards-iso-25010
3
ISO/IEC 9126 categorization of software quality
requirements.
Source: Journal Of Object Technology
4
ISO/IEC 25010 categorization of software quality requirements
Source: ISO20500.com
What is Quality and How We Look at The Metrics
▪ Quality may be defined as the non-inferiority or superiority of something; a measure of that

thing being suitable for its intended purpose (fitness for purpose) while satisfying customer
expectations. Simply put, the quality of an application basically boils down to the way it’s
working.
▪ One additional precept that informs our work is: “Anything can be measured, but that does not
mean that everything should be measured.”
▪ A quality app must meet the following requirements:
▪ must work without crashing or producing errors,
▪ must be stable,
▪ all of its functionalities must work, too,
▪ must make all necessary calculations,
▪ must show accurate data,
▪ all users must have appropriate permissions.
▪ Those requirements are all included in ISO 25010.
6
What Does ISO/IEC 25010 Include?
The standard categorizes app functionalities and lists all aspects of the app that
must be verified before the app may be released.
1. FUNCTIONAL SUITABILITY
—i.e. what does the app do? In particular:
a. Functional completeness—is the app in line with the specification? Does it have the
functions it was supposed to have?
b. Functional correctness—does it provide the correct results?
c. Functional appropriateness —does it fulfill its function?
7
2. PERFORMANCE EFFICIENCY
—does the app use an optimal amount of resources?
a. Time behavior—are the response and processing times or throughput rates reasonable?
b. Resource utilization—are the amounts and types of resources used reasonable?
c. 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.
8
3. COMPATIBILITY
—can the app work cross-platform or share data with other products, systems
or components?
a. Co-existence—can the app share a common environment and resources with other
products?
b. Interoperability—can it exchange information and use the information that has been
exchanged?
9
4. USABILITY
—can specific users use the app in specific conditions?
As you know, every app is different and has different users. Like for example an app that was
develop, need to adjust the UI for users of all ages and make it run on all kinds of phones, including feature
phones.
a. Appropriateness recognizability—can users can recognize whether the app is appropriate for their needs?
b. Learnability—is it easy to learn how the app works?
c. Operability—is the app easy to operate and control?
d. User error protection—does the app protect users against making errors?
e. User interface aesthetics—is the user interface pleasing to the eye? (watch out—that’s a very subjective issue!)
f. 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.
10
5. RELIABILITY
—an extremely important issue. Here, we look closer at:
a. Maturity—how stable is the app during everyday use?

b. 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.
c. Fault tolerance—can the app work even when there are some hardware or software faults?
d. 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.
11
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:
a. Confidentiality—is data accessible only to authorized people?

b. Integrity—does the app prevent unauthorized access to, or modification of, computer
programs or data?
c. Non-repudiation—does the app collect information whether specific actions or events have
taken place?
d. Accountability—can the actions of an entity can be traced back to that particular entity?
e. Authenticity—can you prove the identity of a subject or resource?
12
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?
a. 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.)
b. 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.
c. 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.)
d. Modifiability—is the app easy to modify without harming present product quality?
e. Testability—can the app be tested, also automatically?
Maintainability should be taken into account at the planning stage of the app
development cycle.
13
8. PORTABILITY
—can the software be used in various environments?
a. Adaptability—can the app be adapted for different or evolving hardware,

software or other operational or usage environments?
b. Installability—is key for mobile apps—can they be successfully installed
and/or uninstalled in a specified environment?
c. Replaceability—can the app replace another software product for the
same purpose in the same environment?
14
How ISO 25010 Standard Helps Us Measure Quality
▪ Software development is a process. And we need to have full control of this process in order to arrive at
satisfactory results—i.e. a working piece of software that meets our requirements and quality goals—and
do so within a reasonable timeframe and budget.
▪ We care deeply about the core functions of the software we make. Therefore, they need to work. And to
check whether they work correctly, we test them in and out, trying to take a fresh approach to the task
of evaluation every single time. The problem is, however, that you miss some things if you repeat the
same procedures every day.
▪ So, in order to systematize the work, all the tasks and bugs related to a given app and to make sure we
didn’t miss anything, after all that is said and done, we will always need to open the ISO 25010 Standard
and go through all of the criterion, asking questions about the elements on the list which make us, sort
of a QA of the QA process.
▪ Obviously, not all of the items on the list are applicable or important, for example—installability is crucial
for mobile apps, but not for the QA process.
▪ In these cases, we look at the ISO/IEC 25010 standard and run a quality check of the application following
those eight quality factors.
How ISO 25010 Standard Helps Us Measure Quality
▪ Software development is a process. And we need to have full control of this process in order to arrive at
satisfactory results—i.e. a working piece of software that meets our requirements and quality goals—and
do so within a reasonable timeframe and budget.
▪ We care deeply about the core functions of the software we make. Therefore, they need to work. And to
check whether they work correctly, we test them in and out, trying to take a fresh approach to the task
of evaluation every single time. The problem is, however, that you miss some things if you repeat the
same procedures every day.
▪ So, in order to systematize the work, all the tasks and bugs related to a given app and to make sure we
didn’t miss anything, after all that is said and done, we will always need to open the ISO 25010 Standard
and go through all of the criterion, asking questions about the elements on the list which make us, sort
of a QA of the QA process.
▪ Obviously, not all of the items on the list are applicable or important, for example—installability is crucial
for mobile apps, but not for the QA process.
▪ In these cases, we look at the ISO/IEC 25010 standard and run a quality check of the application following
those eight quality factors.
Is ISO 25010 Standard Good For Everyone?
▪ Each project is different, so you cannot exactly treat the list as a ready-made plan
of action. First, think about what is important for the client and the user. And
remember to think about it from the very beginning of your work with the client.
▪ Every organization benefits from “best practices” and predictability. Process
standardization and automation of testing saves us considerable time and
money, and helps protect ourselves against common bugs. But predicting
obstacles and errors cannot be added to the product after the product itself is
already built.
REMEMBER!
ISO 25010 is a great framework to define

software metrics important for a particular
project. It is not a comprehensive, detailed
map, but rather a guide you can use,
depending on the circumstances.
Sample Survey Questionnaire
19
Sample Survey Questionnaire
20

Software Quality Standards - ISO25010 - CAPSTONE PROJECT 2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Software Quality Standards - ISO25010 - CAPSTONE PROJECT 2

Uploaded by

Copyright:

Software Quality Standards—

How and Why We Applied

▪ The Differences Between ISO 25010, ISO 9126, and ISTQB

Source: Journal Of Object Technology

▪ Quality may be defined as the non-inferiority or superiority of something; a measure of that

If the app is supposed to be performant or handle larger amounts of data, we can

a. Maturity—how stable is the app during everyday use?

a. Confidentiality—is data accessible only to authorized people?

a. Adaptability—can the app be adapted for different or evolving hardware,

ISO 25010 is a great framework to define

You might also like