=Paper=
{{Paper
|id=Vol-2800/paper-08
|storemode=property
|title=Retrofitting Quality (short paper)
|pdfUrl=https://ceur-ws.org/Vol-2800/paper-08.pdf
|volume=Vol-2800
|authors=Raúl Martinez
|dblpUrl=https://dblp.org/rec/conf/apsec/Martinez20
}}
==Retrofitting Quality (short paper)==
https://ceur-ws.org/Vol-2800/paper-08.pdf
Retrofitting Quality
Raul Martinez
Subcomité de Calidad en Tecnología de la Información
IRAM
Buenos Aires, Argentina
rmartinez582@gmail.com
Abstract—This short paper proposes a simple and A. Corrective maintenance
practical way to improve quality while system/software
During normal execution of the system/software
product is in production, combining theoretical points of view
product incidents are reported by user community.
of quality models and information extracted from the
operation, change requests logs and user feedback like
Following, some common instances of this problem are
incidents, required/requested modifications, and detected enumerated.
reactions from users. Such information can be used to • Errors classified as functional by the maintenance
enhance the existing models, or to create a new one, and organization; these errors could hide suitability,
therefore to improve the quality of the system/software correctness, appropriateness problems.
products.
• Security problems.
SQuaRE [1][2] framework, which models quality as a set
of quality characteristics valuable for users, is a widely • Poor system/software product performance.
accepted technique and will be used as reference in this paper.
• User operation errors reported to helpdesks could
Keywords— SQuaRE, Quality Models, Quality in be signals of usability problems or learnability
Production Environments, Quality Maintenance problems.
Error statistics of specific software modules could be used
I. INTRODUCTION as a source of internal/external quality problems. Products
The goal of SQuaRE quality modelling process is to components with more defects usually spot quality
represent quality before the system/product exists, as a set problems.
of characteristics and sub characteristics to which users can
assign importance and value, providing helpful clues for B. Enhancements
development prioritization, requirements trade-off and • Pure functional enhancements containing new
monitoring. quality characteristics or modification to existent
products.
In this proposal, modelling, originally a mental process,
is enhanced with the actual data obtained from the execution • New requirements related with improvements of
of the system/product in the production environment. the quality of the product.
Citing Lehman [6], E-type software systems that solve a • Communities’ boards, helpdesk, and other user-
problem or implement a computer application in the real developer communicational and organizational
world will be perceived as of declining quality unless tools that can be used for quality enhancement
rigorously maintained and adapted to a changing discovery.
operational environment.
The aim of the proposed basic process is the application
of SQuaRE quality models as an ordered reference III. CLASSIFICATION PROCESS
framework to organize and optimize this job of preserving The following basic process is proposed to utilize the
the system/product good quality perception of the user. SQuaRE model as a categorization framework for quality
maintenance incidents.
A. Classification
II. POTENTIAL SOURCES OF DATA FOR ELICITATION OF
QUALITY PROBLEMS Most of maintenance requirements are classified into
two categories: incidents and enhancements, but others
There are many different situations during maintenance of a could exist.
system/software product where the quality could be
compromised. Two common sources of data for quality Each incident / enhancement can be mapped to a
maintenance opportunities are proposed, but the idea could characteristic / sub-characteristic / measures of the
be easily extended to other sources. SQuaRE model, allowing a clear classification of the
quality problem.
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
• Incidents users’ expected values.
Time behaviour values are classical examples
Incidents imply that some user expectations are not of this situation. Target values are evaluated
being met and should be included, or result in unexpected and changed in the model.
values and should be corrected.
Incidents will be analysed to detect quality events and IV. EXPECTED OUTPUTS
characteristics affected. These characteristics could be A. Primary result
related to Data Quality, Product Quality or Quality in Use
An updated model with new and/or revised characteristics
models.
/ sub-characteristics / measures, illustrating user
A detected quality incident could affect a characteristic, requirements for quality.
sub-characteristic, or measure. Response should be This updated model and its correspondent implementation
analysed, a trade-off with other needs solved and, if on the system/software product will be useful for
necessary, the model or models updated, and changes diminishing the perception of declining quality.
reflected on the system/software product.
• Enhancements V. SPECIAL SITUATIONS
Enhancements and new requirements will be analysed A. Reflections of requirements on the existent models
looking for quality improvements.
Not necessarily incidents and enhancements reflect directly
Existing characteristics and/or sub-characteristics / on a unique characteristic / sub-characteristic / measure of
measures could be affected, or new ones added. These the existent or generic SQuaRE model.
characteristics could be related to Data Quality, Product New enhancements could include different characteristic /
Quality or Quality in Use models. sub-characteristic of the standard model and an incident or
This situation implies that users believe that certain enhancement might be reflected in more than one
capacities will be useful if included. characteristic / sub-characteristic in Data Quality, Product
Quality or Quality in Use models.
The required quality should be analysed and a trade-off
with other needs solved and, if necessary, the model or
models updated. B. Explicit model does not exist
B. Correction and improvement of the model In this case generic models proposed by SQuaRE [1] [2]
[3] [4] [5], Data Quality, Product Quality, Quality in Use
The previous classification could uncover failures of
could be used as a metamodel to create the specific
the system/software quality model if an explicit model
exists. instances of quality models for system/software product
project, enabling a more precise communication about
Some common situations can be: quality between user and developer organization.
• The incident / enhancement cannot be
categorized in the model because the VI. CONCLUSION
characteristic was not considered in the
original model of the project but exist in Returning to Lehman’s reference, system/software product
SQuaRE. This is an important case; it means evolution is intrinsic to software, not necessarily a
that certain characteristic that user expects is developer’s fault.
not offered or is offered with insufficient or SQuaRE models can be used as a practical tool to reflect
less than the expected performance in the those evolving quality needs of users in an ordered and
product. Characteristic is evaluated and added visible way.
to the model. These models can be created or updated/enhanced along
the whole system/product life cycle, maintaining visibility
• The incident/enhancement can be categorized
within a characteristic, but no sub- of quality enclosed in the system/software product and
characteristic covers the preserving as previously mentioned the system/product
incident/enhancement. In this case, good quality perception of the user.
characteristics have been detected during
modelling process but certain sub-
REFERENCES
characteristics, valuable to the user, are
missing. [1] ISO/IEC 25000:2014 Systems and software engineering — Systems
and software Quality Requirements and Evaluation (SQuaRE) —
Example: Interaction Capability detected but Guide to SQuaRE
Learnability not considered. Sub-
[2] ISO/IEC 25010:2011. ISO/IEC 25010:2011 Systems and Software
characteristic is evaluated and added to the engineering System and software quality models
model. [3] SO/IEC 25023:2016 Systems and software engineering — Systems
and software Quality Requirements and Evaluation (SQuaRE) —
• The incident/enhancement can be fully Measurement of system and software product quality
classified because the characteristic / sub- [4] ISO/IEC 25022:2016 Systems and software engineering — Systems
characteristic exists, but actual measures are and software quality requirements and evaluation (SQuaRE) —
out of range from the proposed on the model. Measurement of quality in use
Values obtained for the measures differ from
[5] ISO/IEC 25024:2015 Systems and software engineering — Systems
and software Quality Requirements and Evaluation (SQuaRE) —
Measurement of data quality
[6] M. M. Lehman, Laws of Software Evolution Revisited, EWSPT '96,
1996