# Digital Twins in Software Engineering--A Systematic Literature Review and Vision
## 4 Results
### RQ3: How Can a DT Be Built in the Context of the Software Industry?
However, data insights from the usage of the application will come from the software itself. Apart from establishing the core of the data persistence and how to analyze it to achieve the established goals, there is a need to define the methodology to build DTs. [PERSON] et al. [135] include model engineering for DTs with different steps: requirement definition, model construction verification/validation and accreditation (VV&A), model application, model reuse, and model maintenance are their metrics to focus on building the right DT. Applying MBSE practices comes from the origin of DTs linked to PLM and knowledge-rich enterprises. [PERSON] offers a different approach to mingling systems engineering and information technology called the double helix model in [134]. The article also argues that modeling is not well-suited to deal with the dynamics of DTs for software and merges MBSE (model-based system engineering) with IT DevOps, with three stages: design, deploy, and operate. In this context, it eliminates the need to track the changes over the product lifecycle for product data management. For deployment, [PERSON] et al. [130] speak about ModDevOps and TwinOps to standardize deployment and evolution. [PERSON] et al. [203] use MDD (model-driven development) to synchronize different elements in the value creation chain. [PERSON] et al. [165] introduce a specific framework for digital value-chain twins. A structured approach to building DT solutions depends on the domain, so the methodology and phases to be covered will be specific for this solution. To fight uncertainty, one remarkable characteristic of the DT design is its capacity to distinguish different cycles and take the learnings from previous ones, following MAPE-K principles. This topic is touched on by [PERSON] et al. [134], [PERSON] et al. [160], and [PERSON] [149]. Another capacity is mining process data to incorporate the information into the DT, as analyzed by [PERSON] et al. [167]. In our approach, the learnings are ingested via collaboration from the multi-agent system and knowledge graph. Agents can develop their knowledge during their lifecycle. Once a DT automates a decision (for instance, assuming a digital automation pattern, as with [PERSON] et al. [205]), assigning responsibilities or perceiving bias may be challenging. The more autonomy is given to DTs, the more significant the concern about the audit type of decisions they can take. A coding bias could be problematic and provoke failures in the decisions. Some articles focused on validating the level of trust in their results are [120; 122; 131; 143; 171; 173]. On the other hand, DTs can be used to validate the decisions made by decision-making algorithms. [PERSON] et al. [157] discuss ethical by-design principles and share the ideas in a framework. Several types of technical debt in DTs are explored by [PERSON] [147]. This is important to understand, since the cost of their implementation and maintenance could be impacted by how fast the technical debt is accumulated. Assuming a digital control pattern, it is possible to consider a non-fully automated solution that can iterate towards more autonomy after the validation of the results towards maturity metrics. [PERSON] et al. [171] establish a maturity model based on DT value, function, and reliability dimensions. [PERSON] et al. [135] also cover metrics for every step of the defined build method with specific dimensions. As stated, the DevOps approach of [PERSON] et al. [134] seems to be more aligned with software engineering. Consequently, a general maturity model could offer a view of the overall situation of implemented DTs. To enable this approach, the layered architecture contains entry points for users to interact with the DT. The data from lakehouses and the knowledge graph can be retro-propagated, so there are ways to enable more analysis with diverse types of information. This is useful to set up models and adapt from every iteration.