Keywords

1 Introduction

Building an effective DT is a challenging and iterative endeavour [4, 5]. Without a clear process for DT development, it can become exceedingly complicated and may result into not addressing sufficiently essential DT specific system features. Therefore, following a software development life cycle (SDLC) methodology for DT development is essential to ensure the successful creation, deployment, and maintenance of such complex systems to operate in critical environments. Several SDLC models were developed to organize and streamline the software creation processes, each tailored for specific project types. Waterfall, Agile, and Rapid Application Development (RAD) models are among the most widely used models in the industry [11]. Adopting the right SDLC model not only streamlines the development process but also significantly increases the likelihood of delivering a successful and quality product. Therefore, organizations must carefully evaluate their project requirements and choose a SDLC model that aligns with their goals and needs to ensure successful software delivery.

The Agile model relies on an iterative and incremental approach, emphasizing collaboration to create software system that meets evolving customer needs in complex domains. This model enables quick adaptation to changes, ensuring the project remains flexible and responsive [3]. In this paper, we will propose an augmented Agile for DT development, given the complex, dynamic, changing and adaptive nature of DT environments, where they are typically deployed to operate with multitude of diverse and critical systems and technologies. One is more likely to become lost in the implementation of technologies for the DT than to take use of its advantages due to the high cohesiveness of the DT’s supporting technologies. Hence, we must consider the manufacturing and environmental context and specific DT characteristics, to accomplish DT capabilities, such as scalability and interoperability [2].

The paper is organized as follows: related work are provided in Sect. 2, Sect. 3 presents the need for augmenting Agile methodologies for DT development. The proposed approach is described in Sect. 4, Sect. 5 validates the sufficiency of the proposed Agile SDLC, and Sect. 6 presents conclusion and future work.

2 Related Work

There are only a few studies, in the literature, that examine the life-cycle path that guides the detailed development of DT systems. This section explores various methodologies documented in the literature for implementing DT in the healthcare sector.

Laybenbacher et al. [6] devised a strategy for constructing a DT of an immune system, and is structured as a four-stage process. Stage 1: defines a specific application and constructs an appropriate generic template model. Stage 2: personalizes the template model to an individual patient. Stage 3: final immune DT testing and uncertainty quantification. Stage 4: collects individual patient data for ongoing improvement of the immune DT. Alternatively, Karakra [4] proposed a methodology for designing a DT of patient pathways in a hospital. The phases of this methodology are the design phase that has two steps (construction and validation), inclusive of transformation and deployment.

Sinner et al. [10], on the other hand, employed a typical process development cycle for their case study on microbial upstream bioprocessing. The paper used standard process development cycle of five phases: early strain and process characterisation, process design, process transfer, monitoring and control, maintenance and continuous improvement. It emphasised that if the DT and underlying models are regularly adjusted to newly available data, DT can integrate with the whole process development cycles. However, for secure DTs, Satyarthi et al. [8], recommended a Secure Software development Life Cycle (SSDLC) methodology, to create and manage secure software. The proposed SSDLC process, based on SDLC, includes configurable catalogue of security controls. It defines several activities: 1) Requirement analysis and description 2) Designing and Deployment 3) Testing and Maintenance 4) Security requirements identification 5) Security Training and Audits 6) End-product evaluation and Configuration 7) Pre-selection of security objectives 8) Exploration of pre-selected ideas 9) Formation of Simulation based prototype and Data Optimization 10) Real-time asset and component management 11) Virtual verification and validation 12) Iteration based virtual testing and finalizes the product.

From the literature, we observed that limited literature work focused on life cycle methodologies for developing DT. Moreover, proposed SDLCs for developing DT are custom-tailored to meet the specific needs of the respective areas in which they were applied. This indicates the necessity for an adapted, systematic methodology for structuring DT development. The Agile model, known for its iterative, update-centric approach, appears particularly suited for DTs due to their need for regular updates to reflect real-world changes. However, there are certain aspects lacking within the various SDLC phases, hence, an augmented Agile SDLC is proposed.

3 Why Augmented Agile SDLC?

Choosing an augmented SDLC for DT over a traditional one is essential due to the nature of DTs. DTs rely on continuous real-time data to function accurately. The standard practices of agile SDLC may not fully address the complexities of integrating and processing real-time data, synchronised from several sources, continuously updating the DT.

While Agile methods provide a solid foundation for adaptability and customer focused development, however they do not explicitly ensure the requirements of DT that includes real-time data integration, interdisciplinary collaboration, diverse resources interoperability and complex analytics. Thus, an augmented approach to the Agile SDLC to fully address these challenges is needed.

4 Augmented Agile SDLC

In contrast to traditional software development, creating DTs demands unique considerations. Beyond the standard Agile SDLC, the integration of real-time data, modeling and simulation, and interaction with physical assets necessitate specialized knowledge and equipment. The Agile SDLC phases have been tailored with additional techniques, technologies, and practices, aligning with the distinctive characteristics of DT.

In this section, we introduce an augmented Agile SDLC as a methodology for DT development. Figure 1 describes the suggested simplified model: each rectangle represents an Agile SDLC stage: 1- Requirements 2- Design 3- Implementation 4- Testing 5- Deployment. In each stage, blue circles represent common steps of traditional software and DT, black circles represent the traditional software steps, and red circles represent DT steps.

Fig. 1.
figure 1

Agile SDLC simplified model for an iteration.

Full size image

4.1 Requirements Stage

In traditional software development, the requirements for each iteration are taken from the product backlog. DT relies on data to address these requirements, with different sources for this data including physical resources such as sensors, devices or other IoT and mechanical IoT instruments, and historical data that has been previously recorded can be incorporated into the model and utilised for additional analysis [1]. Data collected from this stage for DT should be stored either locally or in a cloud [1].

4.2 Design Stage

In traditional software development, multiple design options for the product architecture are proposed based on the identified requirements. These alternatives are documented within a Design Document Specification (DDS). In DT, the design consists of three steps [7]: (1) identifying the DT classes, (2) incrementally building the DT object-oriented (O-O) hierarchy model for the recommended DT solution, and (3) checking the consistency and refining the DT O-O hierarchy model of the recommended DT solution.

Threat modeling is, also done in the design phase for both DT and the traditional software, defined as a systematic approach used to identify, catalog, and prioritize potential threats, facilitating the development of effective countermeasures against these threats. Once the design for the DT or the traditional software is finalized, Data Flow Diagrams (DFDs) of this design will be created to support threat modeling. A suitable multiple threat modeling tool, such as STRIDE, that aligns with integration into the Secure Development Life Cycle (SSDLC), can be used, making it an integral component of security requirements [9].

4.3 Implementation Stage

The software development process should align with the specifications outlined in the DDS while adhering to established coding standards. Programmers are responsible for creating a Functional Specification (FS) document, which captures all technical-level functions provided by the software. For DT, this phase involves developing the DT models, which may include choosing algorithms and establishing equations. Subsequently, the DT solution is created by producing the software that encompasses the algorithms, equations, inputs, and combines all the components of the DT.

4.4 Testing Stage

The verification and Validation (V&V) process is used for testing purposes [12]. In traditional software development, verification involves self-review, peer-review, online-review, offline-review, and walk through, while validation includes unit testing, integrated testing, system testing, and user acceptance testing.

In DT, verification is employed to verify that the requirements, specifications, and regulations are satisfied, ensuring that DT successfully attains its intended objectives without defects or deficiencies. Formal verification methods, such as reach-ability analysis, model-checking, equivalence-checking, and simulations, are commonly used [12]. Validation evaluates whether DT satisfies the user’s needs, primarily at the end of the development process. Typically, historical data is utilized for sensitivity analysis to evaluate the effects of input changes and physical system changes on outputs.

4.5 Deployment Stage

In traditional software development, after receiving a ‘Pass’ from the testing phase, the product is considered ready for release. The software will either be deployed to production servers or made available for users to install on their machines. In DT, the deployment process for the physical part consists of [2]: (1) preparation for data transmission, (2) provision of an instance of the virtual part of the system, and (3) establishment of a connection between the two parts.

5 Evaluation

To evaluate the adequacy of the proposed augmented Agile SDLC and its additional or modified processes, the model was reviewed by three software engineering experts. These experts were given descriptions of three different healthcare environments within a local small community clinic: the radiology unit, pathology unit, and emergency unit. These departments were selected due to their diverse dynamic behavior, sensitive real-time monitoring, and processing requirements.

The experts were asked to validate the following: 1- The requirements of the selected healthcare environments consistently include the intrinsic features mentioned above. The experts examined the environments against these requirements. 2- The life cycle model contains dedicated processes that produce a system addressing these intrinsic features at various development stages. 3- The life cycle model does not overlook any critical requirements specific to a dynamic complex healthcare environment.

Preliminary results indicate that the proposed augmented Agile SDLC model effectively addresses the identified intrinsic features of the healthcare environments studied, demonstrating its adequacy. However, additional validation is needed to examine larger and more complex healthcare environments.

6 Conclusion

This paper proposes an augmented Agile SDLC methodology for the SDLC of DTs. The Agile SDLC phases have been tailored with additional techniques, technologies, and practices adapted to DTs, addressing the distinctive characteristics and challenges associated with developing DT systems. In future work, we will develop a more complex case study in the healthcare domain, focusing on the emergency department, to validate the proposed model.