Model Transformations Used in IT Project Initial Phases: Systematic Literature Review

Abstract

The paper emphasizes the critical importance of the initial phase in IT project development to avoid implementation errors. It argues that minimizing these errors can be achieved by developing project artifacts at the early stage using a model-driven engineering-based approach. Model transformation plays a basic role in that context. The goal of this paper is to survey publications in which the authors propose generating initial project elements through model-driven engineering and to analyze the level of model transformations offered in their solutions. As a result, the authors would highlight the necessity of understanding which elements of a project can be obtained through automatic transformations and which still require manual manipulation. This distinction is crucial, as it can significantly influence the efficiency and accuracy of the project’s early phases. In general, identifying the project components that can be reliably generated through model transformations helps streamline the project inception and elaboration process performed before IT product implementation.

1. Introduction

Information technology (IT) has evolved over decades, starting from mechanical computing devices to the nowadays interconnected digital world. IT encompasses hardware, software, networks, and processes that manage and disseminate information [1]. IT project encompasses a wide range of tasks related to information technology, which can include software development, hardware upgrades, network implementations, system integrations, cybersecurity initiatives, cloud infrastructure management, etc. The early foundation of IT began in the 1940s with the invention of computers focusing on hardware [2], where software development emerged as programmers wrote instructions to make these machines perform different kinds of calculations [3]. The domination of mainframe computers used by businesses and governments in the 1960s shifted focus to structuring software development to support business and science applications. Since 1968, when the software crisis was identified at the NATO seminar in Garmisch-Partenkirchen [4], researchers and engineers have been continuously seeking ways to improve the quality of developed digital solutions. This seminar highlighted the increasing complexity and development costs of software, necessitating new approaches and methods to manage and ensure software quality. One of the key approaches to addressing this issue is the use of formal methods [5]. Formal methods offer mathematically based techniques to specify, develop, and verify software systems. The goal of these methods is to ensure higher precision and reliability, which in turn reduces the likelihood of errors and facilitates the early identification and resolution of problems during the development stages [6]. Later initiation of the personal computing era in the 1980s and the appearance of the internet and networking revolution in the 1990s forced a new wave of looking for tools, processes, and methods applicable to the rise in IT transformation into globally connected systems. IT now integrates cloud computing, artificial intelligence, big data, internet of things, etc. The area of software development as a creative IT engine also grew with the web, introducing new fields like web development, cloud-based services, e-commerce platforms, and user-centric applications. The extreme growth of IT solution development and the need for project speed stated new requirements for IT projects. Project programmers face the pressure to deliver results quickly while ensuring that the IT product’s quality meets high standards. The agile manifest proclamation in 2001 [7] addressed the requirement for fast software development. However, an improper balance between speed and quality can lead to delays, increased costs, and a reduction in product quality. Providing qualitative accurate and complete source project data, like project scope, budget, schedule, requirements, risks, etc., and definition of (as formal as possible) transformation rules for obtaining target elements, like software components, can address these issues [8]. So far, the high demand for automation solutions has become a catalyst for designing a new method.

One of the abilities to go in the direction of formalizing (in the sense of providing a sound and precise working background) IT solution development is to use models. Model-driven engineering (MDE) roots lie in efforts to formalize software design with structure programming and Unified Modeling Language (UML) [9] in the late 1980s, providing a visual way to represent the problem domain and its IT solution [10]. The idea of code generation from models aimed to reduce manual code errors thus improving quality and accelerating the development process. Model-Driven Architecture (MDA) was promoted by the Object Management Group (OMG) in 2001 [11], as a peak of MDE adoption and hype becoming a tsunami in the software world. The idea of MDA was promising and offered to separate business logic and application logic from underlying platform technology and to use models for structuring project artifact specification at different levels of abstraction. In other words, MDA promised to provide full automation of software development from a conceptual view of the problem domain to the smallest implementation details in running software solutions.

Many industries adopted the idea of MDA to tackle complexity in domains like embedded systems, telecommunications, and enterprise applications [12]. Researchers are working on standardization efforts, where models and metamodels may vary significantly across tools and organizations, leading to interoperability issues. Efforts are put into the development of more robust and efficient model transformation frameworks and enhancing models with additional metadata and constraints to reduce ambiguities. However, challenges such as tool complexity, resistance to change, and lack of skilled professionals have led to the extinction of pure MDA ideas to automate whole the process of IT product development. However, still, the MDE idea to use abstract models throughout the development lifecycle is alive for the generation of single project artifacts, ensuring the speed of IT projects while keeping the high quality of the developed product [13,14]. Model transformation is a core concept of MDE, allowing automatic derivation of target models or artifacts from source models. Since researchers are seeking well-defined methods for IT solution development, models and model transformations became primary artifacts of development automation, ensuring both speed and quality, and are widely used for different activities of IT projects, where project performers need to obtain certain project elements and have the ability to define source elements for it.

A cornerstone of a successful IT project is the project initiation [15], which includes a definition of project goals, timelines, resource planning, feasibility study, requirements analysis, solution design, and prototyping, as well as quality assurance processes. A clearly defined project scope helps avoid ambiguities and misunderstandings, as well as reduces the risk factors that could lead to project delays or cost overruns. It ensures that all parties involved understand and agree on the project’s objectives, deliverables, and solution functionality. Balancing speed and quality is one of the most significant challenges for researchers looking for method development to formalize activities performed and artifacts created during the project’s initial stage, which should be realized before solution implementation. Moreover, the artifacts created during project initialization serve as a guide for all project participants, ensuring a clear and unified understanding of the project’s direction and requirements.

The goal of the research presented in this paper is to survey papers, where the authors propose to present initial project elements with models and to obtain them through formal transformations, as well as to analyze the level of model transformations offered in their solutions. This paper presents the results of a literature survey conducted over the past ten years when a reduction in interest in using model transformation has been observed. Despite this trend, research on the topic continues to be published. The systematic literature survey presented in this paper investigates model transformations successfully applied within different IT project activities. The transformation essence and notations used as source and target models within particular IT project activities are summarized for readers in structured form so that studies related to relevant phase transformations can be found. Also, the achieved results highlight the insufficiency of the solutions for model transformation in the initial stages of IT projects. The paper is structured as follows. The next section discusses related work performed on the analysis of model transformation published in the scientific literature before with the concluded necessity to repeat such survey for the last decade. Section 3 states the focus of the research and describes the methodology applied in the survey presented in this paper. Section 4 presents the survey, which is then discussed in Section 5.

2. Related Work

As mentioned in the introduction, we began discussing automatic code generation in the 1980s [16] and formally started transforming models in 2001 with the emergence of MDA [11]. Since then, researchers have regularly conducted literature surveys on various aspects of model transformation. For instance, a study [17] focuses on Bidirectional Model Transformations and found that there are challenges with classification/taxonomy, model synchronization, specification and verification, semantic issues, consistency, reverse engineering, and formalization issues. Another study [18] examines models at runtime and overcoming inconsistent runtime and design models, causing system misalignment, and found that future research should emphasize robust empirical testing, improved abstraction techniques, and dynamic adaptability in complex environments. There are also broader and more in-depth studies about traceability [19] and progress in automating design and implementation phases, which identify critical gaps in standardization, lifecycle coverage, and validation [20] and point out future efforts—prioritize universal methodologies, improve automation for early stages, emphasize strategies for integrating requirements into the transformation lifecycle, and implement robust validation frameworks to ensure practical adoption. There are studies on some specific cases, such as a study [21] on user interfaces, offering multi-platform solutions and significant design-time automation, or another study [22] on privacy-compliant software reuse in early development phases.

This paper focuses on the applications of model transformation during the early phases of projects, up to implementation. The scope of this paper includes project planning, stakeholder agreements, budgeting, and the decomposition of domains into system features, epics, user stories, and eventually tasks, where these tasks are assigned to developers, making workload estimation crucial. A survey specifically on this topic does not exist. However, there are similar studies like [23] researching and discovering the requirements of a system from users, customers, and other stakeholders (elicitation) and [24] on goal-oriented requirements engineering. These studies, however, have certain limitations, for example, the existing research heavily focuses on isolated phases without establishing seamless workflows across all phases of the lifecycle.

The paper [25] reviews the state of model-driven engineering (MDE) practices and challenges through a meta-analysis of 18 studies published between 2015 and 2020. MDE promises automation, abstraction, and adaptability in software development. However, gaps remain between academic proposals and practical adoption, particularly in usability, tool interoperability, and support for early development phases. Moreover, research found that there is inadequate support for defining and validating non-functional requirements like performance and security. Future research should develop methodologies for early-phase MDE applications, emphasizing automation and stakeholder collaboration, and establish universal standards for model transformations and quality assessments to unify practices across tools and domains.

Throughout the development process, we do model in each iteration. It is especially intense during the initial cycles [26]. However, there seems to be a shortage of more rigorous experiments being conducted in real-world settings within existing literature. The majority of research papers showcase experiments that utilize semi-structured interviews or surveys that only display views from people involved with software building procedures and do not truly reflect actual impacts when applying modeling practices within agile methods.

In 2014 and 2015 similar studies [27,28] were conducted, shaped in the form of a roadmap of approaches that map, transform, or otherwise integrate artifacts or models related to the software or system lifecycle. The study focused on the top 50 cited papers within this roadmap, providing a deeper analysis and literature review of these papers. They found that there is a lack of standardization in transformation methods, difficulty in mapping qualitative concepts like goals to concrete system elements, and limited industrial adoption due to fragmentation and scalability issues.

Since then, 10 years have passed, and a similar study is needed, this time focusing on the early phases of a project—up to implementation.

Based on a comprehensive analysis of the existing literature reviews in the area, the authors arrived at the following conclusions:

(1)

Research on model-driven principles usage within IT projects heavily focuses on isolated phases (e.g., design, implementation) without establishing seamless workflows across all phases of the lifecycle;

(2)

Limited studies explicitly address the role of MDE in early phases, such as goal modeling, stakeholder negotiation, and domain analysis;

(3)

A significant portion of proposals lacks rigorous empirical evaluations, relying heavily on proof-of-concept implementations;

(4)

Early-phase models (e.g., goal or requirement models) are seldom explored for dynamic runtime adaptation, limiting their practical utility in evolving systems;

(5)

The lack of standardized transformation languages and metamodels results in fragmented and incompatible approaches;

(6)

Automation primarily targets design and implementation, with minimal tools available for tasks like stakeholder negotiation or workload estimation;

(7)

Insufficient focus on multi-domain and multi-stakeholder scenarios—most approaches are domain-specific or assume homogeneous stakeholder environments, ignoring complexities in multi-domain systems (e.g., cyber-physical systems, smart cities, government platforms, etc.);

(8)

Existing MDE techniques struggle with scalability in large, complex systems, especially during the early-phase artifact generation and validation;

(9)

Traceability means inadequately supporting backward and forward consistency between early-phase models (e.g., goals, requirements) and implementation;

(10)

Theoretical advancements often fail to translate into practical tools that can be adopted in industry, especially for non-technical stakeholders in early phases.

Consequently, the Systematic Literature Review focuses on the usage of model transformations in IT projects during the initial stages of software development last performed in 2014 [27] and up to the modern situation with the rapid technologies and approach changes; it is required to investigate which artifacts are supported by automated transformation (at least potentially) and which are not supported. Moreover, such a literature survey can help to determine whether and which artifacts are more appropriate, guiding the development process that best supports the project’s scope and timeline.

3. Materials and Methods

The research presented in this paper was performed in accordance with the PRISMA 2020 (Preferred Reporting Items for Systematic Reviews and Meta-Analyses) guidelines [29]. The primary objective of this research is to identify existing research on model transformations used in IT projects at the initial stages of the project.

With the model transformation authors mean a process that takes one or more source models as input and produces one or more target models as output by following a set of transformation rules [30]. The conceptual scheme of model transformation within the essence of model-driven engineering is shown in Figure 1.

As the initial stage of the IT project authors specify the activities, which are performed during the IT project life cycle before the implementation of the solution. For example, Figure 2 highlights the corresponding activities that should be performed during the IT project life cycle on the example of Unified Process [31] and SCRUM [32].

So far, under the scope of the research it is stated to perform the analysis of solutions offered for the following activities of the IT project (identifiers A1–A6 are used for project artifacts categorization during the analysis later in the paper):

• Project initiation activities (A1), including project goals, stakeholders, and high-level requirements, as well as project proposal document development;
• Requirements analysis (A2), including gathering detailed user and system requirements and communications with stakeholders through interviews, workshops, and surveys;
• Project feasibility study (A3), evaluating technical, operational, and financial abilities, as well as risk assessment;
• Project planning activities (A4), including the creation of a project plan and backlog, timeline, and budget, as well as assigning roles and responsibilities within the team. This phase of the project includes also a selection of process organization methodology and life cycle model;
• Solution design activities (A5), including a high-level and detailed definition of system architecture;
• Solution prototyping activities (A6), including the development of wireframes, user flows, and technical specifications, as well as optionally, small-scale prototypes, or proof of concept for design ideas validation and gathering feedback from stakeholders.

To provide a focused direction for the research, the five following research questions (RQs) were formulated as follows:

• RQ1: Which artifacts are used in IT projects as a source model in model transformation?
• RQ2: Which notation is used in IT projects for source model in model transformation?
• RQ3: Which artifacts are used in IT projects as a target model in model transformation?
• RQ4: Which notation is used in IT projects for the target model in model transformation?
• RQ5: Are the model transformations enough precise to be supported by the tool?

To address the RQs comprehensively, an initial literature pool is constructed by examining five databases of scientific papers. The following criteria are applied to select the initial pool of studies:

• Databases: Scopus, ACM Digital Library, IEEExplore, Science Direct, and Web of Science;
• Range: 2014–2024 as the year of publication;
• Language: English;
• Subject area: Computer science;
• Paper type: Conference proceedings;
• Search string content applied for title, abstract, or keywords:
  • (“model driven”) AND
  • (“software development” OR “information system” OR “IT project”) AND
  • (“business modeling” OR “functional model” OR requirement OR analysis OR design OR backlog OR planning OR management OR documentation OR “user story”) AND
  • (“model transformation” OR “meta-model”)

The process of paper searching and filtering is shown in Figure 3. Initially, the pool of all papers is created based on searching the information sources according to the search query developed for each database. The total number of papers identified after application of the search string is 894, where papers distribution by databases is shown in Figure 3. Next, duplicates are removed from the pool, in case of the same paper is indexed in several databases. As a result, 719 original papers are found. Then, a full-text assessment is performed for each source in the pool to identify its relevance to the scope of the research. A manual screening process identifies 214 papers mentioning model transformations as used in IT projects. Subsequently, a snowballing technique is applied to identify additional relevant studies that may have been missed due to not being found with the search query. By applying a snowballing technique to the initial studies and 12 previously identified literature reviews discussed in the Related Work Section of this paper, an additional 23 relevant papers are discovered.

Going for in-depth full-text analysis the spreadsheet is created to facilitate subsequent analysis of the transformation essence in the selected 237 papers. Additionally, columns for the definition of project artifacts are used in the spreadsheet, including the identification of project artifacts used as a source model, artifacts used as a target model, and the level of model transformation automation. The investigation of the source and target models allows us to conclude about artifact placement within the project life cycle and application domain. In total, 148 papers are identified as papers presenting a solution on model transformation within the model-driven engineering principles, where 52 papers offer the solution for the project’s initial stages defined as a scope of this research, and the rest 96 papers are found as offering model transformation solutions out of the research scope.

Columns including title, author(s), and publication year for each study are used for paper identification. The statistics of paper dispersion by years are shown in Figure 4. The tendency of papers published year by year for the whole IT project lifecycle is in the direction of decreasing, but the number of papers published on solutions for the application of model transformations to some IT project artifacts before coding is decreasing not so extremal. It is possible to conclude that code generation interest is not so wide as in the first decade of research within the model-driven engineering area.

From a literature review perspective, starting in 2014, it became clear that MDA’s idea about total automation of the software development life cycle from the presentation of the problem domain till running software [33] was a utopia for achieving complete lifecycle coverage [34]. Even if some concrete Conceptual Modeling Programming-based approaches [35] existed, trying to make the MDA in practice idea feasible [36], they did not have the expected impact.

Consequently, attention to model transformation decreased, with the focus shifting towards advancements in artificial intelligence [37,38]. Nevertheless, model transformations can still be successfully applied for project artifacts in specific phases [25] and integrated with manual refinement of such. Unlike artificial intelligence, which yields varying results each time, the formalization of model transformation rules enables the precise generation of the expected target elements.

In turn, to address research questions, the spreadsheet is also extended with the columns for the corresponding project activities A1–A6 highlighting where the particular artifact is used in the project lifecycle. Additionally, a column for the definition of the transformation type gives a possibility to filter out manual, semi-formal, and formal transformations, and data about the tool supporting the model transformation solutions are collected if they are mentioned in the particular paper.

4. Results

This section presents the main results obtained from this Systematic Literature Review performed according to the research method described in the previous section. In total, 52 primary studies are qualified according to the research questions stated for the survey [39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90]. In these studies, the model transformations are applied to IT project artifacts developed during the project’s initial stages, i.e., before the implementation of the solution. The following subsections are organized according to the research questions stated in the previous section.

4.1. Source Model (RQ1 and RQ2)

The source model is analyzed from the context of the artifacts used in the IT project’s initial stages, as well as the notation used for that artifact presentation.

Table 1. Source models used in model transformations applied in IT project’s initial stages.

Activity	Source Description	Notation	Reference
A1	Business process model, concept model, domain model, problem frames, Goal Model, high-level requirements, text	BPMN, CML, E3, GLR, SBVR, two-hemisphere model	[39,40,43,47,49,52,58,60,62,65,69,71,74,78,81,86,87,89]
A2	Requirements, feature model, user stories, scenarios, non-functional requirements	DSTL, mind maps, requirement trace matrix, SYSML, UML (use-case, class, activity diagrams), text	[41,44,45,46,53,55,56,57,59,67,68,70,72,73,75,80,84,89,90]
A3	-	-	-
A4	User stories	Text	[76,85,88]
A5	Data schemas, high-level architecture, information configuration, system configuration, dynamic models of the system	NoSQL, B specification, UML (class, sequence, component diagrams)	[42,50,54,61,62,63,68,77,79,82,83]
A6	Windows navigation, interface structure	SEF, text	[48,64]

summarizes the mapping of source model items used in model transformations into activities A1–A6, describing the source type, listing the notation used for that model, and giving the reference to the primary study, where the source model of that type is used. No one source model type fits into IT project activities devoted to feasibility study.

The statistics of the notations used in the source models are shown in Figure 5. The figure shows only notations which are mentioned in more than one model transformation solution. It is seen that the mosh used notation for the source model is textual description. Modeling notations used for source model presentation are mostly used diagrams of Unified Modeling Language [9], Business Process Modeling Notation [91], and two-hemisphere models [92].

4.2. Target Model (RQ3 and RQ4)

The target model is analyzed from the context of the artifacts used in the IT project’s initial stages, as well as the notation used for that artifact presentation.

Table 2. Target models used in model transformations applied in the IT project’s initial stages.

Activity	Target Description	Notation	Reference
A1	AI-generated proposal models	Text	[39]
A2	Requirements, such as use cases, user stories, domain models, security models, and dependability models	BPMN, UML (use-case diagrams), frameworks, trace models, custom models, DSL, SYSML, component model, text	[43,47,49,53,56,57,65,66,67,71,75,78,80,87]
A3	Quality Models	ATL framework	[58]
A4	User stories, storyboards (based on meta-model)	UML class diagram, XML	[70,88]
A5	Business logic, architecture components, service contracts, IoT nodes, data architecture, system architecture, application scenarios, security models	Petri nets, UML (use-case, class, sequence, component, deployment diagrams)	[39,40,41,42,43,45,46,50,52,54,55,59,60,61,62,63,68,72,73,74,76,77,79,82,83,84]
A6	Platform-specific IU model, UI design, UI prototype code	IFML, code, UML class diagram	[44,48,64,69,81,85,86,90]

summarizes the mapping of target model items used in model transformations into activities A1–A6 defined as a scope of the research. The table is organized as describing the target type, listing the notation used for that model, and giving the reference to the primary study, where the target model of that type is used.

The statistics of the notations used in the target models are shown in Figure 6. The figure shows only notations which are mentioned in more than one model transformation solution. It is seen that the mosh used notations for the generated target model are different types of UML diagrams and UI prototype code. As seen in Table 2, most papers focus on the generation of software architecture components.

4.3. Transformation Essence and Tools (RQ5)

Model transformations convert models from one representation to another at the different stages of software development. The most typical model transformations are Model-To-Model (M2M) transformations and Model-to-Code (M2C) transformations. M2M transformations can be applied as a refinement of an existing model adding more specific detail, or otherwise as extracting high-level concepts from a detailed model. Most cases of such model transformation work as a converting model from one domain to another, for example, transforming a Business Process Model into some architecture model or transformation of models at the same level of abstraction. M2C transformations allow the generation of executable code or configuration files from models. The focus of this Systematic Literature Review is M2M transformations within the framework of Model Driven Development, where the definition of the precise transformation rules and the existence of source and target meta-models are the primary elements of the transformation approaches offered in the paper.

It is seen in Table 1 and Table 2 that source and target models are in some cases the same in model transformations. It means that the model received as a target in one type of transformation can serve as a source for another type of transformation thus organizing the transformation chains [60]. The transformation solutions offered in the primary studies are mapped on the IT project activities A1–A7 according to source and target artifact position. Figure 7 shows all the identified transformations between stated IT project activities. Numbers in circles show how many studies offer the transformation from artifacts of one project activity into artifacts of another project activity and transformations on the same level. It is seen that most studies offer model transformations concentrated on the generation of the components at the level of solution design, which are mostly code generation solutions. The transformations are less presented on the artifacts developed during project initiation, planning, and feasibility study.

Figure 7 presents that only one solution offers the transformations from artifacts of project initiations (A1) into artifacts on the same stage of the project (A1), as well as only one solution offers transformation into elements of a feasibility study (A3). The same area was almost uncovered with a wide set of model transformations are artifacts of Project planning (A4).

Figure 8 gives a detailed depiction of all the smaller artifacts offered in the transformations, which are the focus of this paper:

• A1 → A1 [88] is the only transformation from a Proposal Document Model into an AI-generated proposal model;
• A1 → A2 [43,47,49,65,71,78,89] is the transformations from variations in the Business Process Model into requirements presented as a use-case diagram, etc.;
• A2 → A4 [70] is the only transformation from UI requirements into Storyboard;
• A4 → A4 [87] is the transformation of semiformal user stories expressed as text into structured user stories of the storyboard;
• A1 → A3 [58] is the only transformation of the Goal Model into the elements of the Quality Model.

It is seen that several solutions for transformation are offered for obtaining the elements of the Proposal Document Model, and variations in the Business Process Model can be obtained from some other artifacts. And elements of the Business Process Model itself serve as a source for further transformation into elements used within the Planning stage of IT projects. In general, hypothetically, the creation of the unified model transformation chain is possible, as far as the transitions among these activities are covered. The transformation between the block of the Business Process Model variations and UI elements is dotted as the transformations among these elements are possible and are offered as A1–A6 transformations [69,81,86,90].

Figure 8. Detailed depiction of all the smaller artifacts (A1–A4) used in the initial stages of the IT project.

Figure 8. Detailed depiction of all the smaller artifacts (A1–A4) used in the initial stages of the IT project.

The model transformation solutions presented in the primary studies are analyzed from the perspective of its automation by tool. If the transformation is supported by a tool, it is fixed in the studies’ data. Different Eclipse Modeling Framework [93] plug-ins are the most frequently used to implement the model transformations, as well a wide spectrum of authors individually developed tools are mentioned with names of that tool and also without names. The analysis of the primary studies shows that the implementations of the tool to support the transformations are realized for individual issues and experiments and are not developed as tools usable outside of the tool vendor’s laboratory. The authors plan to summarize data obtained about tools used for model transformation as a separate publication, where to discuss tools interoperability for transformation chains.

5. Discussion and Conclusions

Model transformation has been a cornerstone of software engineering and system modeling for decades, providing a structured approach to automating the conversion of abstract models into more concrete representations [94]. With the advent of artificial intelligence technologies, it is reasonable to question whether traditional model transformation techniques will remain relevant. Recent advancements in IT product development within cloud computing, DevOps, and applications of artificial intellect algorithms have spurred renewed interest in the usage of abstract models and model transformations to increase the speed of IT projects while keeping the high quality of the developed product. The new wave of model transformation application to IT projects experienced now is integrated with agile workflows making it more flexible and user-friendly. Concepts like low-code/no-code platforms [95], domain-specific languages (DSL) [96], and model-based system engineering (MBSE) [97] are driving MDE’s resurgence, especially in industries like automotive, aerospace, and Internet of Things (IoT). MDE is evolving to meet contemporary challenges, blending with emerging technologies and methodologies to enable faster and more reliable system development in a highly complex, digital-first world. Model transformation relies on formally defined rules and mappings, which ensure predictable and repeatable outcomes. While artificial intelligence can assist in generating or refining these rules, its stochastic nature often precludes the deterministic behavior required in critical systems [98]. Moreover, models generated or transformed through predefined rules are often more interpretable than those produced by artificial intelligence systems. Platforms like GitLab and Atlassian integrate model management moving model transformations to the cloud. Tools like JetBrains MPS and Xtext enable the rapid development of domain-specific languages [99,100].

The focus of this paper is the survey of scientific papers published in the last ten years and devoted to the solutions for initial activities of IT projects, where the primary artifacts are models and their transformations at the different levels of automation. Model-driven engineering (MDE) focuses on using high-level abstractions, or models, as primary artifacts in the engineering process. Central to MDE is the concept of model transformation, where source models are converted into target models using well-defined rules. The choice of notations for these models significantly impacts the clarity, expressiveness, and success of the transformation process. As far as source models in MDE represent high-level system specifications, requirements, or designs the most used standardized notations for source models is UML, as well as custom domain-specific languages, are used as well. Still, quite widely textual specification of requirements is used in the efforts to automate the initial stage of software development. Target models representing implementations, configurations, and deployments are presented in the form of code representations, data schemas, XML/XMI, and different kinds of modeling frameworks. Notations like UML and DSLs are suitable for capturing domain-specific semantics for source models, while XML ensures universal expressiveness for target models. Standardized notations enable interoperability and tool support and should be compatible with automation tools. The continued utility of model transformation requires the development of the model transformation tool industry and possibly integration of artificial intelligence in such tools for analysis of project artifact patterns and generation of initial transformation rules, which further can be refined and validated by domain experts. The main challenges in model transformation tools development are diversity of notations, tools interoperability, and the development of robust tools able to handle a variety of source and target models’ notations.

While model transformations are widely applied in developing software architecture and UI prototypes, their use in the early stages of IT projects, such as project initialization, planning, and feasibility studies, remains limited. The target models used for solution components are often well-defined and formalized. The structure of these models makes them suitable for source model transformation into lower-level representations. Moreover, model transformation in this level of IT project creates artifacts that are closer to the final product, such as system architecture or functional prototype. Thus, these artifacts directly contribute to the development process, making transformations more impactful and justifiable in terms of resource investment. In the initial stages of the project, models are often informal, high-level, and incomplete. Artifacts like high-level requirements, project planning within work packages, effort estimation, and feasibility reports lack the formal structure needed for their automation. These models frequently focus on qualitative aspects, which are challenging to represent and transform programmatically. Also, during the initial stages of the project a lot of decision-making, exploration of alternatives, and human communication is needed. This makes it difficult to define transformation rules for semi-structured models that dominate in planning and feasibility studies. There is a lack of standards for representing and transforming such early-phase artifacts. So far, the benefits of model transformations are perceived as less tangible during project initialization.

To recap, the results of the literature research consolidated in this paper identify areas within projects where model transformations have been successfully applied, e.g., business process modeling, generation of solution design and software components, UI prototypes, testing, and areas where they have not been utilized. As it is concluded in the Results Section, the weakest place in IT projects is its initial stage, where mistakes made exactly in the initial stage of the project cause the most project expenses. Overall, this analysis provides an opportunity to address these aspects further. One of the promising ideas is linking a model-based methodology with the development of an IT Project Management Plan and Project Scope Definition. A conceptual characterization of source and target models, together with their associated model transformation rules, is an interesting and attractive problem to solve in future research.