Agile development is essential for efective 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.
Digital Transformation is the transformation of
products, services, and business models based on the needs
of customers and society by responding to changes in
the business environment and utilizing information
technology [
However, because agile development tends to focus on each sprint, it is possible to simultaneously progress the quality estimation and evolve quality requirements.
This paper presents the issues of quality achievement in agile development and concept and design of the quality digital twin.
2.1. Agile development the implementation of functional requirements, the real- Agile software development refers to a group of software ization and evaluation of quality requirements are often neglected. To solve such a problem, we propose a concept of a support system for user-driven high-quality agile development (hereinafter called ”quality digital twin”) by development methodologies based on iterative development to deal with uncertainty and risk, as shown in 1 .
Its important practical activities include short iterations with a certain time window, continuous release (automaapplying the digital twin concept to quality management tion, providing and evaluating working products), user in agile development.
The Quality Digital Twin has the quality state model as
its core, which models the quality of products in the agile
development. The model is based on the quality models
of the ISO/IEC 25010, including product quality models
and quality-in-use model [
Digital transformation can perform high value creation
and development eficiency through rapid repetition of
user-driven idea planning, prototyping, operation, and
evaluation [
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 [
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 suficient for the value they want to achieve, and what and how much is missing.
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
mainly the value demanded by the user, and its resources
are concentrated on creating an executable product to
realize and confirm the value. The quality is achieved
through repeated product evaluations with user
participation at each iteration [
Modeling languages such as use cases in UML may mitigate the above weakness of waterfall development to some extent because they are easy to understand even for non-experts. However, the quality of these models does not directly imply the quality of the system, since they only can define the functionality of the system, not its quality.
In the agile development, on the other hand, user values are defined by the functionality the product should have. Therefore, the development team tends to focus on realizing the functionality, not user values themselves.
To prevent this, the user review is conducted to evaluate the product at the end of each iteration. However, because the user review tends to be subjective, some quality • Model synchronization: Synchronization of the real-world target and the virtual world model from data sensed from the real world one • State estimation and prediction: Estimation and prediction of target internal states from the model (for monitoring) • Controlling: Controlling the real-world target
based on 2) • Modelling and simulation: Future forecasting and planning through simulation and optimization by changing inputs and control parameters • Information display: Display of information about the monitoring of the estimated internal state of the target, the results of future predictions, or the provision of additional information tied to the model.
In waterfall development, quality is estimated using the results of quality assurance activities (often processes)
In agile development, requirements continuously evolve. In other words, the quality digital twin is evaluated in every iteration to accumulate necessary quality requirements for its completion in the product backlog.
Quality decomposition is performed using the framework of Scrum: initiative, epic, and story, depending on the scale of the project. 3 shows an example of quality decomposition. First, user values are defined at the top level as quality-in-use (QiU) requirements, and then decomposed into product quality requirements, functions, architectural design, or non-functional testing. Problems in product quality discovered during development are stored in the backlog as technical liabilities.
Furthermore, we believe that the quality digital twin 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 twin has the potential to provide users for intuitive and quantitative quality estimation in a way that only quality assurance professionals have been able to do (Hypothesis 3).
At the sprint planning, the decomposition of quality requirements to be implemented into stories is performed to put in the sprint backlog. During the execution of a sprint, the results of testing and static analysis are collected. Technical debt identified by the developer is also collected into the product backlog.
The sprint review is based on the collected qualityrelated 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-tounderstand 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
framechart 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 [
Almost the same comparative review can be performed for product quality requirements. By conducting the above sprint review for each QiU requirement, it is possible to evolve the quality requirements, making sure the • Quality in Use [QiU] – Efectiveness (magnitude of value created
for the user) – Eficiency (eficiency of user tasks) – Satisfaction (positive impact on user’s
mind & attitude) – Freedom of risk (avoidance of negative im
pacts) – Usage Coverage (ability to perform appropriately to anticipated/future usage situations) • Product quality characteristics for non-user use (ease of development and maintenance work) [PQ QiU ] – Testability (ease of testing work) – Analyzability (ease of failure analysis) – Modifiability (ease of modification work) – Installability (ease of installation work) – Reusability (ease of reuse)
The product quality characteristics other than the above represent product-specific qualities and are classified as below.
• Quality of the functions that the system has [PQ(Function), PQ(Set of Functions)] – Functional accuracy – Function appropriateness – Time behavior • Quality of a set of functions – Functional completeness – Usability (cognitive ease of use) – Security • Quality of the source code of the system [PQ(Code)]
– Modularity • Characteristics of the system with respect to possible failures [PQ(Failure)] – Maturity (no failures ← few defects) – Fault tolerance (service continuity against
failures) – Availability (service uptime against fail
ures)
– Recoverability (low loss against possible
failures)
addition, there are three patterns for the realization of
quality requirements: assignment to components,
functions, and architecture (structure and design guideline)
[
QiUFunction [with PQ(Function)]* | PQ(Set of Functions)* | PQ(Outside)* | PQ(Failure)* PQ QiU Function [with PQ(Function)]* | PQ(Code)* | Architecture PQ(Function) DQ* PQ(Set of Functions), PQ(outside), PQ(failure) Function [with PQ(Function)]* | DQ* | Architecture
QiU requirements can be deployed into Function and Product quality requirements. The product quality characteristics for non-user use are developed into functions, code quality, and architecture. Architecture is embodied in the components, their relationships and principles of behavior, and design guidelines.
When a system is decomposed into itscomponents, the deployment of product qualityto them also occurs. In this case, product quality can be inherited, not inherited, or assigned among the components. In case of the assignment, a product quality requirement such as time eficiency and reliability, is decomposed into a set of new requirements with diferent goals, each of which assigned to each component. In case of including data components, data quality (DQ) requirements are defined for them.
Quality evaluation in SQuaRE [
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 eficiency of the corresponding quality requirements.
6 shows the meta-model of the quality state model. The
quality state model is realized as a directed acyclic graph
ISO/IEC 25030 Quality Requirements Framework [
Quality Digital Twin supports various deployment degree of support. The following node types are considmethods of quality requirements by using patterns. In ered.
• Quality requirement: QiU, PQQiU, PQ(Set of
Functions), PQ(Outside), PQ(Failure),DQ • Quality implementation: Function [with
PQ(Function)], Architecture • Quality activity: Functional testing, Nonfunctional testing, Static analysis, User review
Quality requirements can be supported by not only quality requirements themselves, but quality implementations and quality activities. Quality implementation can be supported by Functional testing for Function, Nonfunctional testing for Architecture, and Static analysis for Architecture.
In the Quality DT, quality management of agile development 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 recommended for achieving the quality goals. This prevents the agile development from deviating from the quality goals.
7 shows how the quality state model is used in a sprint. At the sprint planning, the results of requirements decomposition are input into it, the results of quality activities are collected during executing the sprint, and at the sprint review, quality evaluation are conducted on the model and then the model is reviewed and, if necessary, reorganized. The detailed usage flow is shown below.
For all quality activities conducted up to this stage, the quality evaluation value of quality node n i , achievement(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 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 in this sprint), and the contribution ij of each node are shown on the links, as shown in 8.
In addition, the user can also check the degree to which 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 review whether the implementation and activities truly support the goal quality requirements and whether their contribution is appropriate.
The system that realizes the quality digital twin consists of three functions: a quality requirement decomposition support function, a quality evaluation function, and a quality dashboard function, as shown in 9.
The followings need to be addressed for each function.
• Quality requirement decomposition function:
The description and decomposition of quality
requirements must be user-driven. It is necessary
to support appropriate decomposition without
dificulty for users.
• Quality evaluation function: It is necessary to
establish a method to link the results of
nonfunctional testing and static analysis to quality
evaluation. For static analysis, we plan to refer
to ISO/IEC 5055 [
We proposed the concept of Quality Digital Twin, which visualizes the quality of products in the agile development, using the quality models of the ISO/IEC 25010. This concept enables the realization of a system that supports 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 model, which is the core of the concept, as well as three issues for the realization of the concept. We plan to conduct prototyping and experiments to demonstrate the efectiveness of the system.