Concept of Quality Digital Twin in Agile Development Tsuyoshi Nakajima1 , Alessandro Simonetta2 1 Shibaura Institute of Technology, 3-7-5 Toyosu, Koto-ku, Tokyo, 135-848, Japan 2 Department of Enterprise Engineering University of Rome Tor Vergata, Rome, Italy Abstract Agile development is essential for effective digital transformation. However, since agile development tends to focus on functional implementation, the realization of true user value (quality in a broad sense) is often neglected. To support realization of true user value in agile, this paper proposes the concept of a quality digital twin, a quality representation of the target system synchronized at each iteration. The agile development focuses on the quality of target product itself more than that of processes and intermediate products, and therefore SQuaRE quality model can be much more applicable to the agile. It uses the SQuaRE quality framework for defining quality requirements, and engineering and evaluating the system. This concept enables the realization of a support system for user-driven, high-quality agile development. Its feasibility is demonstrated by showing system / data structure and usage of the quality digital twin. Keywords Agile, digital twin, quality management, SQuaRE 1. Introduction each sprint, it is possible to simultaneously progress the quality estimation and evolve quality requirements. Digital Transformation is the transformation of prod- This paper presents the issues of quality achievement ucts, services, and business models based on the needs in agile development and concept and design of the qual- of customers and society by responding to changes in ity digital twin. the business environment and utilizing information tech- nology [1]. Digital Transformation can perform high value creation and development efficiency by repeating 2. AGILE DEVELOPMENT AND the planning, prototyping, operation, and evaluation of ITS ISSUES ideas quickly, with the user taking the initiative. Agile development is one of the foundations required for this. 2.1. Agile development However, because agile development tends to focus on the implementation of functional requirements, the real- Agile software development refers to a group of software ization and evaluation of quality requirements are often development methodologies based on iterative develop- neglected. To solve such a problem, we propose a concept ment to deal with uncertainty and risk, as shown in 1 . of a support system for user-driven high-quality agile Its important practical activities include short iterations development (hereinafter called ”quality digital twin”) by with a certain time window, continuous release (automa- applying the digital twin concept to quality management tion, providing and evaluating working products), user in agile development. participation, and test-first and refactoring. Agile de- The Quality Digital Twin has the quality state model as velopment is effective when the problem to be solved is its core, which models the quality of products in the agile complex (i.e., its requirements are vague and/or changing, development. The model is based on the quality models and the solution is unknown), and is adjusted by repeat- of the ISO/IEC 25010, including product quality models edly investigating, understanding, and dealing with the and quality-in-use model [2]. By considering user value problem [3]. This paper addresses Scrum, which is a with the quality-in-use model, refining and implement- lightweight process framework for agile development, ing quality requirements/functions/architecture, and it- and the most widely used one [4]. erating testing including non-functional testing, static analysis, and quality evaluation based on user reviews in 2.2. Issues to user-driven agile development 4 th International Workshop on Experience with SQuaRE Series and its Future Direction, December 06, 2022, Tokyo, Japan Digital transformation can perform high value creation Envelope-Open tsnaka@shibaura-it.ac.jp (T. Nakajima); and development efficiency through rapid repetition of alessandro.simonetta@gmail.com (A. Simonetta) user-driven idea planning, prototyping, operation, and Orcid 0000-0002-9721-4763 (T. Nakajima); 0000-0003-2002-9815 (A. Simonetta) evaluation [1]. Therefore, agile development is one of the © 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). necessity foundations for this. However, user involve- CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) ment is often limited to input of requirements and eval- aspects that the users are not directly benefited from is often neglected to confirm. Agile development itself does not have the support to overcome these problems and achieve quality in a comprehensive and balanced manner. 3. QUALITY DIGITAL TWIN CONCEPT Figure 1: Agile development 3.1. Digital twin A digital twin (DT) is a living, intelligent and evolving uation and review of deliverables at each development model, being the virtual counterpart of a physical entity cycle, and users rarely are involved in decision-making or process for practical purpose, such as monitoring and in managing the projects. As a result, agile development control, future prediction and planning, and conceptual tends to derail from creating the value that users expect design and development [7]. for the cost [5]. From the results of the literature review [7] [8] [9], we We believe that one of the reasons why users cannot found that DT consists of all or a partial combination of be involved in development decisions is that there is no the following five functions as shown in 2 (Generic form quantitative and intuitive way to determine whether the of DT). current quality of the target product is sufficient for the value they want to achieve, and what and how much is missing. 2.3. Quality management of agile development In the waterfall development, the quality of the target product is defined, decomposing it into quality activities and their goals for intermediate products in each develop- Figure 2: Generic form of Digital Twin ment phase. The project tries to achieve them to assure the quality of the target product indirectly. In contrast, in the agile development, the quality to be achieved is • Model synchronization: Synchronization of the mainly the value demanded by the user, and its resources real-world target and the virtual world model are concentrated on creating an executable product to from data sensed from the real world one realize and confirm the value. The quality is achieved • State estimation and prediction: Estimation and through repeated product evaluations with user partici- prediction of target internal states from the model pation at each iteration [6]. From a quality management (for monitoring) perspective, agile development, compared to the water- • Controlling: Controlling the real-world target fall, has the advantage that its quality goals are business- based on 2) oriented and the way to check their achievement is direct. • Modelling and simulation: Future forecasting and Modeling languages such as use cases in UML may planning through simulation and optimization by mitigate the above weakness of waterfall development changing inputs and control parameters to some extent because they are easy to understand even • Information display: Display of information for non-experts. However, the quality of these models about the monitoring of the estimated internal does not directly imply the quality of the system, since state of the target, the results of future predic- they only can define the functionality of the system, not tions, or the provision of additional information its quality. tied to the model. In the agile development, on the other hand, user val- ues are defined by the functionality the product should 3.2. Application of DT concept to quality have. Therefore, the development team tends to focus on realizing the functionality, not user values themselves. management in agile development To prevent this, the user review is conducted to evaluate and three hypotheses the product at the end of each iteration. However, be- In waterfall development, quality is estimated using the cause the user review tends to be subjective, some quality results of quality assurance activities (often processes) such as testing and reviews of intermediate deliverables. 4. Considerations on application In contrast, agile development does not produce inter- mediate deliverables, but instead produces a workable to agile development product in a short cycle, making it possible to measure 4.1. Plan it; Do + Evaluation quality data directly on the product. Based on this, we hypothesized that the ISO/IEC 25000 (SQuaRE) series of We take the approach of only rough support for decom- product-focused quality models and quality estimation position of quality requirements in sprint planning, and using these models would be easily applicable to agile evaluating the adequacy of the decomposition and cor- development (Hypothesis 1). recting it during sprint evaluation. This is because the The quality of the software in the real-world is not agile development does not fit with time-consuming long- directly visible, but is estimated through quality mea- term and complete planning and requirements definition. surement and evaluation. The SQuaRE quality models and the results of quality measurement and evaluation using the models (their data repository is called quality state model) can be regarded as a virtual world model for the invisible quality of real-world software products. The iteration cycles of agile enables model synchroniza- tion between them. From these considerations, we have another hypothesis (Hypothesis 2) that the quality state model can be applied to quality management in agile development. Based on these hypotheses, we propose Quality Digital Twin (Quality DT), a quality management support system using the quality state model. Comparing to the generic form of DT, the following concept of Quality DT was drawn: 1. Model synchronization: Definition a of quality-in- use requirements (at the start of the development), Figure 3: Quality decomposition using agile framework story development for quality requirements (at the start of each iteration), and then quality eval- In agile development, requirements continuously uation based on testing, static analysis and user evolve. In other words, the quality digital twin is evalu- reviews (at the end of the iteration). ated in every iteration to accumulate necessary quality 2. State estimation and prediction: Monitoring of requirements for its completion in the product backlog. current quality and its deviation from the goal Quality decomposition is performed using the frame- 3. Controlling: no counterpart work of Scrum: initiative, epic, and story, depending on 4. Modelling and simulation: What-of analysis for the scale of the project. 3 shows an example of quality Quality Management, including development (it- decomposition. First, user values are defined at the top erations and each sprint) planning level as quality-in-use (QiU) requirements, and then de- 5. Information display: Visualization of estimation composed into product quality requirements, functions, and prediction of quality and risks architectural design, or non-functional testing. Problems in product quality discovered during development are Furthermore, we believe that the quality digital twin stored in the backlog as technical liabilities. would allow users to not only provide input and feedback to the agile development but also take the initiative in decision making on it. This is because the quality digital 4.2. Quality requirements in agile twin has the potential to provide users for intuitive and development quantitative quality estimation in a way that only quality At the sprint planning, the decomposition of quality re- assurance professionals have been able to do (Hypothesis quirements to be implemented into stories is performed 3). to put in the sprint backlog. During the execution of a sprint, the results of testing and static analysis are col- lected. Technical debt identified by the developer is also collected into the product backlog. The sprint review is based on the collected quality- related data to determine the current quality. In this case, based on the decomposition at the time of planning, the results of testing and static analysis are automatically degree to which the targeted quality have been achieved. calculated in terms of their “contribution” to the quality Concerning product quality, we can see the balance of characteristics/sub-characteristics. its achievement. During a sprint review, the quality dashboard displays the quality evaluation results in a visual and easy-to- understand manner for the users to intuitively monitor 5. QUALITY STATE MODEL AND the quality. The qualitydashboard shows the relationship ITS APPLICATION between quality requirements, quality realization, and quality activities, provides the ability to edit it ( 8 ), and This section presents ideas for the organization and use of monitors the status of product quality. 4 shows an image the quality state model, which is a central part of Quality of the quality status monitoring function. The achieve- DT. ment percentage of all the QiU requirements is displayed in the left-hand side of 4, in which QiU requirements are 5.1. SQuaRE quality models listed in order of their importance (three sizes of length: most important, important, and normal). In the right pie The ISO/IEC 25000 (SQuaRE) series provides a frame- chart in 4, the angle of the arc represents the relative work for quality related to systems and software products. importance of each quality characteristic to the product, ISO/IEC 25010 [10] defines both the quality-in-use and and the length of the radius represents the achievement product quality model for systems and software products, of product quality. For example, the figure shows usabil- while ISO/IEC 25012 [11] defines the data quality model. ity is the most important quality of the target product, Quality-in-use represents the influence on stakehold- and its achievement level is about 70 ers when the target entity is used under a certain context of use, while product quality and data quality are the capability of the target product and data themselves, re- spectively to satisfy both stated and implies needs. 5.2. Interpretation of the SQuaRE quality models in the quality state model In-use quality The quality state model is built on the above three qual- ity models of SQuaRE, but to capture the decomposition relationships between quality requirements, the follow- ing interpretations of the models and their properties are Figure 4: Image of quality status monitoring in quality dash- added. board The Quality-in-Use (QiU) model targets use during operation. In contrast, the ease of work during develop- During the sprint review, user reviews the correspon- ment and maintenance is partly in the Product Quality dence between the quality requirements and the quality- (PQ) model. In this paper, these are positioned as quality related data collected and their contribution to the re- models PQQiU that considers their influence on work quirements. For QiU requirements, the following points under a specific context of use. will be checked: • Quality in Use [QiU] • Do the functions and PQ requirements decom- – Effectiveness (magnitude of value created posed from a QiU requirement truly contribute? for the user) Is the defined contribution level appropriate for – Efficiency (efficiency of user tasks) it ? – Satisfaction (positive impact on user’s • Is non-functional testing necessary to support the mind & attitude) QiU requirement? – Freedom of risk (avoidance of negative im- • Is this QiU requirement really necessary? Should pacts) it be changed to express what we need more – Usage Coverage (ability to perform appro- clearly? priately to anticipated/future usage situa- tions) Almost the same comparative review can be performed for product quality requirements. By conducting the • Product quality characteristics for non-user use above sprint review for each QiU requirement, it is possi- (ease of development and maintenance work) [PQ ble to evolve the quality requirements, making sure the QiU ] – Testability (ease of testing work) addition, there are three patterns for the realization of – Analyzability (ease of failure analysis) quality requirements: assignment to components, func- – Modifiability (ease of modification work) tions, and architecture (structure and design guideline) – Installability (ease of installation work) [14]. When A, B, and C are quality nodes (in 6), the rule – Reusability (ease of reuse) A→B | C means that A can be deployed into either B or C. QiUFunction [with PQ(Function)]* | PQ(Set of Func- 5.3. True product quality tions)* | PQ(Outside)* | PQ(Failure)* � PQ QiU Func- The product quality characteristics other than the above tion [with PQ(Function)]* | PQ(Code)* | Architecture � represent product-specific qualities and are classified as PQ(Function) DQ* � PQ(Set of Functions), PQ(outside), below. PQ(failure) Function [with PQ(Function)]* | DQ* | Architecture • Quality of the functions that the system has QiU requirements can be deployed into Function and [PQ(Function), PQ(Set of Functions)] Product quality requirements. The product quality char- – Functional accuracy acteristics for non-user use are developed into functions, – Function appropriateness code quality, and architecture. Architecture is embodied – Time behavior in the components, their relationships and principles of behavior, and design guidelines. • Quality of a set of functions When a system is decomposed into itscomponents, – Functional completeness the deployment of product qualityto them also occurs. – Usability (cognitive ease of use) In this case, product quality can be inherited, not in- herited, or assigned among the components. In case of – Security the assignment, a product quality requirement such as • Quality of the source code of the system time efficiency and reliability, is decomposed into a set [PQ(Code)] of new requirements with different goals, each of which – Modularity assigned to each component. In case of including data • Characteristics of the system with respect to pos- components, data quality (DQ) requirements are defined sible failures [PQ(Failure)] for them. – Maturity (no failures ← few defects) – Fault tolerance (service continuity against 5.5. Quality evaluation of the SQuaRE failures) quality model – Availability (service uptime against fail- Quality evaluation in SQuaRE [15] selects important qual- ures) ity characteristics and sub-characteristics, and defines – Recoverability (low loss against possible information needs for the target to measure them using failures) quality measures, as shown in 5 . The quality measure • Relationship with outside of system [PQ(Out- quantifies the results of testing, user reviews, or static side)] analysis of the target entity into one single value. The – Capacity satisfiability value of the quality measure is mapped to a predefined quality rating level to obtain a quality rating value. – Interoperability Quality DT considers non-functional testing, static – Coexistence analysis, and user reviews conducted in each iteration – Adaptability of agile development as quality activities, and integrates – Accessibility the results of these activities to evaluate the achievement – Resource efficiency of the corresponding quality requirements. 5.4. Deployment of quality requirements 5.6. Design of the quality state model in the SQuaRE quality requirements 6 shows the meta-model of the quality state model. The framework quality state model is realized as a directed acyclic graph ISO/IEC 25030 Quality Requirements Framework [12], in which higher-level requirements are related to lower- [13] guides the flow of deployment of quality require- level realizations by the link ”supports”. A support link ments through decomposition of the system. has an attribute of “contribution,” which indicates the Quality Digital Twin supports various deployment degree of support. The following node types are consid- methods of quality requirements by using patterns. In ered. 5.7. Quality evaluation of the SQuaRE quality model In the Quality DT, quality management of agile devel- opment is considered as a process of correctly evolving the quality state model. In other words, while iteratively developing the product, quality requirements (and their relationships) are gradually established, and at the same time, the degree of achievement of quality requirements is measured from the results of quality activities in the agile development, and corrective activities are recom- Figure 5: Quality evaluation and measurement methods mended for achieving the quality goals. This prevents the agile development from deviating from the quality goals. • Quality requirement: QiU, PQQiU, PQ(Set of 7 shows how the quality state model is used in a sprint. Functions), PQ(Outside), PQ(Failure),DQ At the sprint planning, the results of requirements de- composition are input into it, the results of quality activ- • Quality implementation: Function [with ities are collected during executing the sprint, and at the PQ(Function)], Architecture sprint review, quality evaluation are conducted on the • Quality activity: Functional testing, Non- model and then the model is reviewed and, if necessary, functional testing, Static analysis, User review reorganized. The detailed usage flow is shown below. Figure 7: Relationship between sprint and quality state model 1. At sprint planning Supports relationships are ten- tatively established at the time of quality require- ment decomposition. In sprint planning, users, product owners and developers cooperate to de- compose a quality requirement into other quality requirements, quality implementations and qual- ity activities, guided by the rules in 4.2. In the case of explicit decomposition, a new node is added to the quality state model and automatically gener- ates a supports link to the decomposed element. The decomposition should be rough at this point Figure 6: Metamodel of quality state model because supports links can be always reviewed to reconnect later. 2. During sprint implementation The results of the Quality requirements can be supported by not only quality activities are recorded. quality requirements themselves, but quality implemen- 3. At sprint review The supports relationship is re- tations and quality activities. Quality implementation viewed at the sprint review. In the sprint review, can be supported by Functional testing for Function, Non- users, product owners and developers cooperate functional testing for Architecture, and Static analysis to evaluate the results of quality activities con- for Architecture. ducted during the sprint. Prior to the review, the results of User review, Non-functional testing and Static analysis of QiU are evaluated. 4. Functional testing: success 1/ failure 0 5. Non-functional testing, Static analysis: achieve- ment score [0,1] 6. User review: achievement/non-achievement of specified quality requirements [0,1] For all quality activities conducted up to this stage, the quality evaluation value of quality node n i , achieve- ment(n i ), is calculated using the following formula. where support(n i ) = n i1 , n i2 , ... , n im is the total set of nodes supporting node n i , and contribution ij is Figure 9: Relationship between sprint and quality state model the contribution of node n ij to n i . In the evaluation review of n i , the contents and quality evaluation values of n i , all nodes supporting n i support(n i ) (including the quality implementations and quality activities conducted 6. Conclusion in this sprint), and the contribution ij of each node are shown on the links, as shown in 8. We proposed the concept of Quality Digital Twin, which visualizes the quality of products in the agile develop- ment, using the quality models of the ISO/IEC 25010. This concept enables the realization of a system that sup- ports user-driven, high-quality agile development. The feasibility of the concept is demonstrated by showing an example of the structure and usage of the quality state Figure 8: Review of a quality node and its supporting nodes model, which is the core of the concept, as well as three issues for the realization of the concept. We plan to con- duct prototyping and experiments to demonstrate the In addition, the user can also check the degree to which effectiveness of the system. quality requirements have been met and the progress made since the last time. By checking the correspondence and contribution of the supporting nodes, it is possible to References review whether the implementation and activities truly support the goal quality requirements and whether their [1] G. Vial, Understanding digital transformation: contribution is appropriate. A review and a research agenda, The Journal of Strategic Information Systems 28 (2019) 118–144. URL: https://www.sciencedirect.com/ 5.8. Challenges in realizing Quality DT science/article/pii/S0963868717302196. doi:https: The system that realizes the quality digital twin consists //doi.org/10.1016/j.jsis.2019.01.003 , sI: of three functions: a quality requirement decomposition Review issue. support function, a quality evaluation function, and a [2] T. Komiyama, A. Motoei, Establishing international quality dashboard function, as shown in 9. standards for systems and software quality require- The followings need to be addressed for each function. ments and evaluation, IWESQ@APSEC (2020). [3] S. McConnell, More effective Agile: A roadmap for • Quality requirement decomposition function: software leaders., Construx Press, 2019. The description and decomposition of quality re- [4] B. Meyer, The Ugly, the Hype and the Good: an quirements must be user-driven. It is necessary assessment of the agile approach; Agile, Springer, to support appropriate decomposition without Cham, 2014. difficulty for users. [5] C. Ebert, H. C. Duarte, Digital transformation, IEEE • Quality evaluation function: It is necessary to Software 35 (2018) 16 21. establish a method to link the results of non- [6] K. Kautz, Participatory design activities and agile functional testing and static analysis to quality software development, IFIP WG 8.2/8.6 Interna- evaluation. For static analysis, we plan to refer tional Working Conference (2010) 303–316. to ISO/IEC 5055 [16]. [7] B. R. Barricelli, E. Casiraghi, D. Fogli, A survey • Quality dashboard function: what information on digital twin: definitions, characteristics, applica- and how needed to displayed to help users take the lead in quality management. tions, and design implications, IEEE access (????) 167653–167671. [8] K. Y. H. Lim, P. Zheng, C.-H. Chen, A state-of-the- art survey of Digital Twin: techniques, engineering product lifecycle management and business inno- vation perspectives, Journal of Intelligent Manu- facturing 31 (2020) 1313–1337. [9] F. Tao, et al. , Digital twin in industry: State-of-the- art, IEEE Transactions on Industrial Informatics 15.4 (2018) 2405–2415. [10] ISO/IEC 25010:2011 ”Systems and software engi- neering — Systems and software Quality Require- ments and Evaluation (SQuaRE) — System and soft- ware quality models.”, 2011. [11] ISO/IEC 25012:2008 Software engineering — Soft- ware product Quality Requirements and Evaluation (SQuaRE) — Data quality model, 2008. [12] ISO/IEC 25030:2019 Systems and software engineer- ing — Systems and software quality requirements and evaluation (SQuaRE) — Quality requirements framework, 2019. [13] T. Nakajima, T. Komiyama, Applying Quality Re- quirements Framework to an IoT System and its Evaluation, International Journal on Advances in Internet Technology 12 (2019). [14] P. Clements, et al., Documenting software architec- tures: views and beyond (2nd edition), Addison- Wesley Professional, 2010. [15] T. Nakajima, About the Framework of Quality Eval- uation Using SQuaRE, APSEC (2020). [16] ISO/IEC 5055 Information technology—Software measurement—Software quality measurement— Automated source code quality measures, 2021.