SOFTWARE QUALITY ASSURANCE

SQA, short for software quality assurance, is the process of critically analyzing and
maintaining set requirements for developing reliable products, like software. A well-
designed SQA system incorporates all software development processes, starting from
defining requirements, to coding, testing, and all other processes in between, prior to
release.

Code quality frameworks describe code quality characteristics and their

decomposition. For Enterprise software development, one model stands out:
the ISO/IEC 25010, which was launched in 2011.

In ISO/IEC 2510, software quality is divided in two broad dimensions:

(1) product quality and (2) quality in use.

Product quality decomposition

Product quality relates to the static and dynamic properties of the software
proper. It is divided in 8 characteristics:

1. Functional Suitability
2. Performance Efficiency
3. Compatibility
4. Usability
5. Reliability
6. Security
7. Maintainability
8. Portability

Quality in use decomposition

Quality in use relates to the outcome of human interaction with the software.
It is divided in 5 characteristics:

1. Effectiveness
2. Efficiency
3. Satisfaction
4. Freedom from risk
5. Context coverage

Going one step further with product quality sub-characteristics

The characteristics listed above are pretty high level, but ISO 25010 goes one
step further by defining a set of sub-characteristics.

In the case of functional suitability these are:

1. Functional Completeness: degree to which the set of functions covers all the
specified tasks and user objectives.
2. Functional Correctness: degree to which the functions provides the correct results
with the needed degree of precision.
3. Functional Appropriateness: degree to which the functions facilitate the
accomplishment of specified tasks and objectives.

Performance efficiency

1. Time-behavior: degree to which the response and processing times and throughput
rates of a product or system, when performing its functions, meet requirements.
2. Resource utilization: degree to which the amounts and types of resources used by a
product or system, when performing its functions, meet requirements.
3. Capacity: degree to which the maximum limits of the product or system, parameter
meet requirements.

Usability:

1. Appropriateness recognisability: degree to which users can recognize whether a

product or system is appropriate for their needs.
2. Learnability: degree to which a product or system enables the user to learn how to
use it with effectiveness, efficiency in emergency situations.
3. Operability: degree to which a product or system is easy to operate, control and
appropriate to use.
4. User error protection: degree to which a product or system protects users against
making errors.
5. User interface aesthetics: degree to which a user interface enables pleasing and
satisfying interaction for the user.
6. Accessibility: degree to which a product or system can be used by people with the
widest range of characteristics and capabilities to achieve a specified goal in a
specified context of use.

Reliability

1. Maturity: degree to which a system, product or component meets needs for reliability
under normal operation.
2. Availability: degree to which a product or system is operational and accessible when
required for use.
3. Fault tolerance: degree to which a system, product or component operates as
intended despite the presence of hardware or software faults.
4. Recoverability: degree to which, in the event of an interruption or a failure, a product
or system can recover the data directly affected and re-establish the desired state of
the system.

Security
1. Confidentiality: degree to which the prototype ensures that data are accessible only
to those authorized to have access.
2. Integrity: degree to which a system, product or component prevents unauthorized
access to, or modification of, computer programs or data.
3. Non-repudiation: degree to which actions or events can be proven to have taken
place, so that the events or actions cannot be repudiated later.
4. Accountability: degree to which the actions of an entity can be traced uniquely to the
entity.
5. Authenticity: degree to which the identity of a subject or resource can be proved to
be the one claimed.

Maintainability

1. Modularity: degree to which a system or computer program is composed of discrete

components such that a change to one component has minimal impact on other
components.
2. Reusability: degree to which an asset can be used in more than one system, or in
building other assets.
3. Analyzability: degree of effectiveness and efficiency with which it is possible to
assess the impact on a product or system of an intended change to one or more of
its parts, or to diagnose a product for deficiencies or causes of failures, or to identify
parts to be modified.
4. Modifiability: degree to which a product or system can be effectively and efficiently
modified without introducing defects or degrading existing product quality.
5. Testability: degree of effectiveness and efficiency with which test criteria can be
established for a system, product or component and tests can be performed to
determine whether those criteria have been met.

Portability

1. Adaptability: degree to which a product or system can effectively and efficiently be

adapted for different or evolving hardware, software or other operational or usage
environments.
2. Installability: degree of effectiveness and efficiency in which a product or system
can be successfully installed and/or uninstalled in a specified environment.
3. Replaceability: degree to which a product can replace another specified software
product for the same purpose in the same environment.

Compatibility

1. Coexistence: degree to which a product can perform its required functions efficiently
while sharing a common environment and resources with other products, without
detrimental impact on any other product.
2. Interoperability: degree to which two or more systems, products or components can
exchange information and use the information that has been exchanged.

Quality in use sub-characteristics

Effectiveness: accuracy and completeness with which users achieve specified

goals.

Efficiency: resources expended in relation to the accuracy and completeness

with which users achieve goals.

Satisfaction

1. Usefulness: degree to which a user is satisfied with their perceived achievement of

pragmatic goals, including the results of use and the consequences of use.
2. Trust: degree to which a user or other stakeholder has confidence that a product or
system will behave as intended.
3. Pleasure: degree to which a user obtains pleasure from fulfilling their personal
needs.
4. Comfort: degree to which the user is satisfied with physical comfort.

Freedom from Risk

1. Economic Risk Mitigation: degree to which a product or system mitigates the
potential risk to financial status, efficient operation, commercial property, reputation
or other resources in the intended contexts of use.
2. Health and Safety Risk Mitigation: degree to which a product or system mitigates
the potential risk to people in the intended contexts of use.
3. Environmental Risk Mitigation: degree to which a product or system mitigates the
potential risk to property or the environment in the intended contexts of use.

Context coverage

1. Context Completeness: degree to which a product or system can be used with

effectiveness, efficiency, freedom from risk and satisfaction in all the specified
contexts of use.
2. Flexibility: degree to which a product or system can be used with effectiveness,
efficiency, freedom from risk and satisfaction in contexts beyond those initially
specified in the requirements.

Where ISO 25010 falls short

ISO 25010 is a great addition for enterprise software teams who want a
framework to define software. By breaking down quality characteristics into
sub-characteristics, developers can go on to define software metrics that
make sense for their project.

It does not provide a comprehensive and systematic mapping of sub-

characteristics to software metrics. That’s because individual circumstances
matter a lot: code quality in the context of an online news site is one thing.
Code quality for an automated high-frequency trading software has a
completely different range of consequences; and code quality of embarked
software on airplanes can be a matter of life or death. In sum, the stakes in
each of every development projects are different, and call for different
priorities, metrics, and contingency plans.
References:

1. https://blog.codacy.com/iso-25010-software-quality-model/
2. https://www.researchgate.net/figure/Quality-model-for-external-and-internal-quality-by-ISO-
25010_fig1_276202563