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