=Paper=
{{Paper
|id=Vol-3356/paper6
|storemode=property
|title=Concept of Quality Digital Twin in Agile Development
|pdfUrl=https://ceur-ws.org/Vol-3356/paper-06.pdf
|volume=Vol-3356
|authors=Tsuyoshi Nakajima,Alessandro Simonetta
|dblpUrl=https://dblp.org/rec/conf/apsec/NakajimaS22
}}
==Concept of Quality Digital Twin in Agile Development==
https://ceur-ws.org/Vol-3356/paper-06.pdf
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.