1 Problem statement

According to the “State of Agile Report 2020”,Footnote 1 up to 90% of the companies are at least experimenting with Agile. The most important reasons to adopt Agile are better responsiveness to change, the desire to accelerate software delivery, and increased productivity. While 42% of the respondents also consider better software quality as a reason for going Agile, software maintainability is considered by no more than 20% of the respondents. According to the same survey, the success of Agile is prevalently evaluated on business value and customer satisfaction, while defects, their resolution and pass/fail tests are considered by less than 20% of the respondents as success measures. This focus on fast delivery to quickly generate business value and satisfy customers makes Agile projects highly vulnerable to technical debt, leading to low maintainability, rework and delays [32].

In model-driven software engineering (MDSE) models are used as central skeleton for software development by generating code from them via transformations. The drawbacks of agile listed in the previous paragraph are reported as being partially addressed by the use of MDSE. Indeed, according to Liebel et al. [26], quality, reusability, reliability, traceability, and maintainability are the five most positively rated elements by MDSE practitioners in the domain of embedded systems. Also, according to Wortmann et al. [51], in relation to Industry 4.0 where by nature we require flexible tools for studying how to swiftly integrate software in a rapidly evolving and heterogeneous technological environment, the main benefits of modeling languages like the Unified Modeling Language [30] are reducing time & costs and improving sustainability & international competitiveness. These benefits are attributed to the fact that modeling supports digital representation and integration.

This paper explores the specific combination of MERODEFootnote 2 as example of a proven MDSE approach for domain-driven design with the Agile and a value-driven way of working. The interest of combining Agile Software Development (ASD) with MDSE lies in the fact that domain-driven design has proven to be efficient in delivering a well-organized architecture in larger agile projects [45]. Alfraihi et al. [5] show some indicators that Agile MDD has improved the efficiency and the quality of the developed software. A comparative case study by Lano et al. [25] also provides indications of improved efficiency and quality when combining Agile with MDD. We believe that our study is an early step in understanding the impact of integrating Agile development with MDD.

The paper mainly addresses the Research Question (RQ): “How can a MDSE method like MERODE be anchored in an ASD structure for user-centric and value-driven (i.e., agile) development to minimize the technical debt?” To answer the RQ, we build an overall approach based on domain-driven design on the basis of Behavior-Driven Development (BDD) scenarios (associated with specific User Stories (US)) with MERODE as Domain-Specific LanguageFootnote 3 (DSL) while achieving fast release by generating code from the domain model. Agility principles are sustained by the user-centricity inherent to the artifactsFootnote 4 used in the model-driven design (the BDD scenarios) as well as (partially) prioritizing the rapid development of specific (software) features based on US value. The framework we propose is called Agile MERODE; through the use of the method, with respect to ASD and MDSE, the strengths of one approach are used to address the limitations of the other and vice versa.

To intertwine ASD and MDSE, we anchor MERODE into the Scrum development life cycle. Within the classical MERODE method, the requirements analysis is achieved partially through a Unified Modeling Language (UML) use case model [30]; in Agile MERODE, the latter is replaced by USs and BDD scenarios that are user-centric and industry-adopted (thoroughly used in Scrum) agile requirements engineering artifacts. Also, no concrete iterative (or sprint-based) life cycle support is furnished by the traditional MERODE method that is essentially meant to be used in a plan-driven fashion. The use of USs within the requirements analysis of an Agile MERODE project supports the (sprint) planning game similarly as for traditional Scrum-based developments. The planning game [10] can thus be executed in a comparable fashion as for non-MDSE agile projects. The MDSE approach makes the precedence constraints on object construction that govern the architecture more explicit, as a consequence of which the prioritization of feature development will be less purely value-driven compared to non-MDSE projects. US are thus pivot elements in the Agile MERODE method, they are (i) associated with a few BDD scenarios that are the input for the model creation process and (ii) the scope elements for the planning game. The adoption of US in MERODE allows its swift anchoring in the Scrum life cycle. An illustrative running example shows the application of the method, and a more elaborated case study further clarifies the practical application of the planning game into an Agile MERODE-based development project. The approach, in its entirety, allows reducing technical debt by building the architecture in a logical, consistent and complete manner but involves a trade-off with pure value-driven because of architectural design precedence constraints. Agile MERODE contributes to the state of the art by showing how to increase user-centricity in model-driven development, how to align model-driven engineering with the Scrum cycle, and how to reduce the technical debt of agile developments yet remaining focused on value.

The remainder of this paper is structured as follows: Section 2 presents the essentials of the MERODE approach, including the relevant elements of its meta-model. Section 3 presents the research paradigm (design sciences) and the way the developed framework instantiates such a research cycle. Section 4 presents the combined approach of ASD and MDSE into the Agile MERODE approach starting with a presentation of the US and BDD meta-model and its integration with the MERODE meta-model and then turning to the Agile MERODE lifecycle and planning game. Throughout these sections, a small illustrative case study is used. Section 5 depicts Agile MERODE as a software process through a dynamic high-level view and a detailed static one. Section 6 applies Agile MERODE to a larger real-life case study and focuses on the planning game application for sprint content assignment. Section 7 discusses the specifics of the approach in terms of planning tradeoff, heaviness in method application and scalability, as well as the threats to validity. Furthermore, it discusses the approach in the light of related work. Finally, Sect. 8 concludes the paper.

2 Background

2.1 Research gap and novelty of the approach

MDSE is not prescribed as an agile practice. While modeling is a well-established discipline, MDSE still faces a number of challenges. Among these we find current MDSE shortcomings in addressing complex software problems and MDSE tool usability issues [29], as well as the need for making MDSE valuable in the context of ASD [8]. Despite these challenges, combined ASD and MDSE approaches have proven to be successful in several domains [22]. Related work until 2016 has been described in a review of 15 studies published between 2001 and 2016 [3]. Many Agile MDSE approaches report positive impacts of a combined Agile-MDSE approach, such as better quality and productivity while maintaining typical ASD benefits such as faster development rate and better customer satisfaction. The study also reveals that the majority of approaches are MDD-based, meaning that Agile practices such as Scrum are incorporated in the MDD process. While the combination of Agile and MDSE can help to overcome the problems with the individual approaches [24], an exact roadmap on understanding how to exactly integrate ASD and MDSE is still lacking [4].

The Agile Unified Process [6] (AUP) constitutes a lightweight version of the Rational Unified Process (RUP) [21]. The AUP is intended to include agile techniques like test-driven development (TDD), agile modeling, agile change management and database refactoring. Because of the use of the RUP iterative structure (composed of 4 predefined phases themselves made of iterations), the AUP is rather devoted to integrating agile practices in a plan-driven environment than making use of MDSE in an inherently agile lifeycle. The RUP lifecycle is indeed a predefined canvas with overall project steps rather than a neutral (not inducing any predefined number of iterations or project length) sprint-based cycle. As seen in Christou et al. [9], the use of the RUP life cycle also implies that the releases produced at the end of each iteration are not necessarily deployable; the effective roll-out is mostly made in late stages of the project (at earliest within the construction phase). The AUP nevertheless deviates from pure UML-only modeling artefacts. Christou et al. [9] emphasize that “Use cases are not the best for documenting business rules, user interface requirements, constraints, or non-functional requirements”; consequently agile modeling artifacts like US can be introduced in AUP-based projects; often these are nevertheless used conjunctively with Use Cases leading to unnecessary overhead [47].

2.2 MERODE essentials

MERODE applies the principle of a layered architecture and identifies three major layers (see Fig. 1). The bottom layer is the Enterprise Layer (EL), containing two sublayers: the Domain Layer (DL) and Event Handling Layer (EHL). These layers are similar to the layers of the artifact-centric BALSA modeling approach of Hull [19]. The DL consists of the business objects and their associations. Additional logic is given in the Object Life Cycles (OLCs) defining the states a business object can be in, and the business events that cause the transitions between states. The EHL offers an interface to invoke the business events and routes these to the relevant business objects that will handle the event by means of a corresponding operation performing the required state changes. The Information System Services Layer (ISL) offers input and output services to access the EL. Output services allow querying the attributes and states of business objects. Input services capture input data but do not directly invoke operations on business objects. Rather, they achieve the requested input or update of information by triggering one or several business events via the EHL. The business events and their handling in the EHL allow combining the advantages of an event-driven architecture with the advantages of the layered architecture. Finally, the Business Process Layer (BPL) defines the work processes. Activities in the business processes may invoke the output and input services in the ISL to obtain information from the data layer and/or update information in the data layer. While the EL captures behavior on a per business object type basis, the BPL will capture other aspects of behaviour relating to users, task attribution and permissions [41].

Fig. 1
figure 1

MERODE layers: BPL (green), ISL (yellow), EL (blue) with two sublayers: EHL and DL

Full size image
Fig. 2
figure 2

MERODE meta-model (relevant part)

Full size image

Figure 2 shows the relevant parts of the MERODE meta-model. As the method uses a subset of the UML notation, its meta-model is much simpler than the one of UML. The blue box denotes the part corresponding to the DL’s meta-model. It shows how the business object types are related by binary associations or inheritance associations (not shown in the meta-model). Business object types have attributes and operations. Each operation is triggered by exactly one type of business event. Conversely, a single business event may trigger an operation in several business objects, hence the need for an EHL.

The yellow box indicates the meta-model part corresponding to the ISL. The dashed part shows the meta-model elements that connect the ISL to the EL. The green box, finally, shows relevant elements of the BPL, and the connection to the ISL.

A specific aspect of MERODE is that it requires all associations in the UML class diagram to express existence dependency. In this way, the UML class diagram becomes a Directed Acyclic Graph (DAG), according to master-dependent associations. Such DAG can be obtained from a regular UML class diagram by systematically reifying all associations that do not express existence dependency. By transforming the UML class diagram in an Existence Dependency Graph (EDG), ambiguities are resolved, and consistency checking with OLC diagrams (the FSMs) becomes easier [39, 40]. Thanks to this improved formality and correctness, the models from MERODE allow generating Java applications as prototypes of the EL with default Information System (IS) services in the ISL [38]. Alternatively, a web service interface can be generated for the DL and EHL. This allows connecting the prototype application to a business process engine, so as to be able to prototype the IS support for a business process. Currently, such code generation for the BPL is not yet available, though a first proof-of-concept with manual code writing has already been achieved [46].

3 Research paradigm, method and approach

This research follows the paradigm of Design Sciences (DS) [17]; DS aims to build generic solutions for identified issues. The result of DS-based research is some kind of artifact that can be a framework, terminology, a methodology, an engineering tool, software, and so forth. In this paper, an attempt has been made to build a methodology to engineer a software development project through models yet remaining compliant with fundamental agile practices. The built artifact is named Agile MERODE and aims to solve an unresolved issue or a problem considered being in a precarious state. In this research, we define Agile MERODE as a methodology to engineer software on the basis of USs, BDD scenarios, domain models, and transformations in order to increase the overall quality of the software architecture, thus reducing technical debt yet remaining maximally value-driven within a sprint’s content determination. To answer the RQ given in the introduction and, in accordance with the DS research cycles defined by Hevner [16], we communicate an analysis of the Relevance Cycle in Sect. 3.1, the Rigor Cycle in Sect. 3.2 and the Design Cycle in Sect. 3.3.

3.1 Relevance cycle

The Relevance Cycle is concerned with the identification of opportunities/problems in the application domain. In the present context, we identify the problem of (heavy) technical debt induced by the use of pure agile methods. The problem has been identified in practice [18]. MDSE, by its structured and and holistic approach, allows to develop software having a well-organized architecture, thus ensuring a strong basis for optimizing code and minimizing the technical debt. The combination of both approaches, even if it requires some compromise, thus holds the promise of combining the benefits of each.

3.2 Rigor cycle

The Rigor Cycle refers to the theories/methods that are used to ground the construction and evaluation of the artifact. The methodology developed in this paper adapts the MERODE method for use in an agile (Scrum-based) context; MERODE as a standalone method was validated in the previous research, and this is therefore taken as a given. Also Scrum is taken as a given, for being the industry standard for ASD [28]. With respect to its classical lifecycle, MERODE was adapted/enhanced in terms of:

  • Requirements gathering and analysis USs coupled with BDD scenarios are used to express requirements with a different level of detail; these artifacts (especially USs) are structural in Scrum because, besides their use for user-centric requirements elicitation, they are used to determine the sprint content. Indeed, USs receive a development priority factor based on their delivered value. They are thus the core artifacts to anchor into the Scrum life cycle. BDD scenarios offer the required details for US design and implementation. These industry-adopted agile modeling artifacts replace requirements elicitation with use cases and workflows traditionally used by MERODE;

  • Life cycle management Agile MERODE has been built to be driven by USs (so these are the main scope elements within the Scrum’s sprint planning (game)). Determining a sprint’s implementation content is made by focusing on the (group of) stories delivering the highest value first. Although Agile MERODE aligns with this, architectural and design constraints do impose some precedence constraints leading to some deviations of the rule; a procedure to cope with this is thus detailed. The Scrum life cycle is the mostly used agile method in practice [28].

3.3 Design cycle

The Design Cycle refers to the construction and the evaluation of the artifact. As explained in the previous section, Agile MERODE has been built as an evolution of the traditional MERODE method. In order to proceed with the construction of the method, we used existing ontologies formalizing the type of elements present in USs [49] and BDD scenarios [44]. Elements constituting these ontologies have then been mapped to elements of the MERODE core ontology [38]. This way, forward engineering rules could be set up ensuring at the same time traceability between the requirements artifacts and the design models. An illustrative example is used to show the applicability and consistency of the framework through its constituting models’ traceability. The evaluation of the planning game constrained by MDSE is done through a case study consisting in the development of a Computer-Aided Software Engineering (CASE) tool to support MERODE or Agile MERODE-based software developments.

Table 1 User stories for the simple shop
Full size table
Table 2 BDD scenarios for US2
Full size table

4 The agile MERODE framework

4.1 Integrating user stories and BDD within MERODE

The aim of this section is to show the mapping between the concepts found in USs and BDD scenarios and the MERODE approach in order to define an integrated framework. As mentioned, USs and BDD are core concepts in ASD. Wautelet et al. [49] proposed a study of the US templates that are most frequently used in practice and unifies them in a consistent ontology. The latter allows to characterize functions of different nature without being overlapping yet exhaustive in the required coverage (so all of the possible USs instances could be associated with one and only one concept). The same approach was followed in [44], and both ontologies were merged to come to unification. While USs correctly depict a user situation, they often fail to give context to the execution of the functionality as well as enough details on how to implement the requirement. USs do nevertheless constitute the ideal communication artifact with customers and other stakeholders and the proper way to define sprints’ content (the life cycle of Scrum) in terms of US to include in the produced release. USs and BDD scenarios are thus perfectly complementary and serve as the pivot onto which we interface with Scrum for MDSE. Implicitly BDD scenarios are always defined in the context of one and only one US. We here use the BDD scenarios (more detailed and specific) for forward engineering to the software architecture. To illustrate the connection between the above meta-model and these Agile concepts, we start from the set of USs for a Simple ShopFootnote 5 represented in Table 1. The MERODE representations of the Simple Shop as well as the prototype Java application generated from these and documented in this section have been placed on a persistent URL.Footnote 6

As previously said, each US has a number of BDD scenarios attached to itself allowing to describe satisfactory scenarios for the testing and thus validation of the US. Example BDD-scenarios for the second US are given in Table 2.

Each of the US and scenarios allows distilling elements in the different layers. As an example, the order US “In order to buy cool PRODUCTs, As a web user, I should be able to add PRODUCTs to CART and checkout” assumes the domain concept of PRODUCT and CART, the business events of add_product_to_cart and checkout of a cart, and IS services with a web interface to add products and checkout. Looking at the individual scenarios, additional model elements can be derived. Scenario 2.2 suggests an attribute “quantity” for the association (class) relating a product and a cart. Scenario 2.3 suggests the need for card information, but from the formulation, we cannot infer that cards and their related info will be stored, so at this point, this information can be part of IS Service invocation and needs not (yet) to be captured as part of the domain layer.

Figure 3 presents the essential elements of a meta-model for BDD templates (extracted from [49] and [44]) that are relevant for this paper. When operationalizing the context part of a BDD scenario (respectively the outcome part), the precondition (respectively postcondition) may refer to the existence or any other particular state of business objects and to values of their attribute, e.g., a product exists, it is on sale, and the available quantity is larger than 5. Besides elements of the domain, also system status or user characteristics may be referenced. The User Behavior part will refer to a user action that invokes an information system service. In the case of an input service, this refers to triggered business events. Table 3 exemplifies this for the first two BDD scenarios for US2. When the “Given” and “Then” part of a BDD scenario are operationalized by formulating a precondition and postcondition, respectively, these Boolean expressions may refer to the states and attributes of Business Object Types (BOTs). The user behavior, on the other hand, can be operationalized as the invocation of an IS Service. These links are shown in Fig. 4 in the purple dashed box. As such, an interactive task in a business process can be further detailed by defining USs for this task and a set of corresponding BDD scenarios. The direct link from the interactive task to an IS Service invocation from Fig. 2 is thus now replaced by many-to-many associations to use cases, instantiated as “TaskOperationalisation” in Fig. 4.

Fig. 3
figure 3

Ontology for USs and BDD templates (extracted from [49] and [44])

Full size image

As MERODE allows generating prototypes from domain models, many elements of BDD scenarios can be verified in just a few clicks once the domain model is specified. Minimal input suffices as, when creating a domain model, the MERODE tool generates default create and end events for each BOT, as well as a default “name” attribute in case no attributes have been specified. Figure 5 shows the domain model for the Simple Shop based on all USs and expressed as UML class diagram.

Figure 6 shows the main screen generated from this domain model, and how the “Given” part of BDD scenario 2.2 can be tested, i.e., viewing the product “Some Random Product”. Figure 7 depicts testing the “When” part of this scenario, i.e., adding the product to the cart, and Fig. 8 shows how the outcome (the “Then” part) can be tested.

4.2 Agile lifecycle support and planning game with agile MERODE

While the domain-driven spirit of the MERODE approach may suggest that it requires a plan-driven approach, we can proceed in an agile fashion. Indeed, inherently the model-driven architecture of MERODE natively supports incremental development. The key objects can be built up at first, and other dependent ones can be developed later on the basis of the previously developed architecture. Some constraints do exist, but the process remains largely flexible and value-driven. Moreover, each increment can lead to an executable (and deployable) release. The iterative and incremental support thus aligns with the agile principles. As an example, Fig. 9 shows how a minimal model containing just the two BOTs “Product” and “Customer” can already be prototyped. The fast and automated prototypes production—using the Merlin CASE-tool—at an early development stage also benefits close interaction between developers and customers while engineering the requirements; this also aligns with the precepts of agility.

When expanding the model, one nevertheless needs to observe the restriction that iterations and increments are constrained by referential integrity between objects so that sprints cannot address the development of features in any order. MERODE’s concept of existence dependency allows for the automated arrangement of objects according to their dependency. The “Top-Down-Level” identifies the absolute master BOTs that are not depending on any BOT as “level 0” BOTs. From there, BOTs that depend on other BOTs get a level that is one number more than the maximum level number of their masters. As such, looking at the complete domain model in Fig. 10, one can see that ITEMINCART has level 2 because it requires the existence of PRODUCT (level 0) and the existence of CART (level 1), which itself requires the existence of CUSTOMER (level 0).

Table 3 Mapping BDD scenarios to domain model elements and required IS services
Full size table

The levels allow partitioning a domain model into partial models that can be implemented in separate sprints. The levels are indicative for sequencing the sprints according to referential integrity requirements. Figure 10 shows a possible partitioning with their dependencies. Partition 1 contains the BOTs Product and Customer which are required to be realized first, given all other BOTs are referencing them. The realization can be tackled in one or two sprints. As soon as this part of the DL has been implemented, US related to these BOTs can be addressed by implementing the required IS services. In next iterations, additional services can be realized for this same partition, or a next partition can be addressed. In the given example, Partitions 2A and 2B can be addressed in any order. The same goes for partitions 3A and 3B. However, the realization of these partitions will require the realization of partition 2A first, as both partitions 3A and 3B contain a BOT that references the BOT CART. BOT COUPON could have been added to partition 1, but its inclusion in partition 3B shows how realization of certain BOTs and their associated IS services can also be delayed if other parts of a system are considered to have a higher value-based priority.

Fig. 4
figure 4

Linking BDD elements to MERODE meta-model elements

Full size image
Fig. 5
figure 5

UML Class diagram for the Simple Shop

Full size image

Figure 11 depicts the global development process for the Simple Web Shop example. The sequencing arrows show the dependencies, and the parallel gateways indicate tasks that have no mutual dependencies. After developing the DL for partition 1, three different tasks can be added to the backlog and addressed either in parallel or in random sequence. The sprint planning can use value-based prioritization to decide upon the sequencing of the development of services and/or tackling a next DL partition. Each of the “Implement IS Services ...” has been adorned with a loop symbol as also the implementation of a set of IS services can be planned across several sprints. As such, the representation in Fig. 11 is imperfect as many more degrees of freedom are possible as long as the sequencing dictated by the architectural dependencies are respected.

Obviously, this way of identifying of architectural dependencies within the DL assumes a pre-existing global domain model. Creating a complete domain model, in particular for larger projects, may be contradictory to an agile approach. Creating only a partial domain model is better in line with ASD but may induce a technical debt; indeed, within a later sprint, the initial domain model and/or implementation of related services could reveal to be suboptimal and thus require refactoring of an earlier implemented DL partition and its related services. “Just enough modeling” as proposed by Agile ModelingFootnote 7 can help achieving a balance between agility and avoiding costly refactoring.

To summarize, the Agile MERODE life cycle should include a preliminary initial sprint (called sprint 0) where, from a project’s initial US set, a first creation/generation of domain objects is made along the idea of “just enough modeling”. This constitutes the so-called baseline architecture of the project. Besides generating the baseline architecture, sprint 0 also serves for building an initial next sprint planning and, more importantly, determining the sequence constraints that might appear for the USs development into coming sprint(s). After sprint0, the product owner can determine the next increment content (realized in the next sprint) by selecting the USs (functions) on the basis of value if no other function needs to be pre-built; otherwise, the content is selected on the basis of the technical constraint.

5 Agile MERODE process view

To further document the integration of MERODE into the Scrum life cycle, we document, in this section, (i) a dynamic view of the Sprint sequencing with the impact on the produced artifacts (like software architecture, a prototype, sprint constraints, a sprint planning, etc.) in Sect. 5.1 and (ii) a static view of the actions taken within a sprint that we call the process fragment in Sect. 5.2.

Fig. 6
figure 6

Application generated from the domain model

Full size image
Fig. 7
figure 7

Adding a product to the cart

Full size image
Fig. 8
figure 8

Viewing the content of a cart

Full size image
Fig. 9
figure 9

Generating a prototype from a minimal model

Full size image
Fig. 10
figure 10

Domain model with level numbers and possible partitioning

Full size image
Fig. 11
figure 11

Planning game

Full size image

5.1 Agile MERODE process structure

Figure 12 represents a (dynamic) view of the Agile MERODE process’ Sprints. As discussed earlier, the process is initiated with Sprint0 that creates a baseline architecture, overviews USs precedence constraints and generates a first software prototype. Other Sprints devoted to produce executable releases supporting USs through their associated BDD scenario are then performed following the value provided by the features described in the USs and the precedence constraints. The construction of the executable releases requires hand coding the ISL as the default generated information services and user interface are not likely to satisfy the requirements of the end users. Nevertheless, the construction of the executable releases benefits from code generation for the EHL and the EL, which are strictly separated from the ISL and BPL. The MERODE code generator uses a template-driven approach, whereby the templates can be adjusted to the needs of a project. Such adjustments may be the source of template design activities performed in parallel with sprint implementation, as suggested by [14].

Fig. 12
figure 12

General process architecture

Full size image

5.2 Agile MERODE as a process fragment

The i* framework [12] is used to represent the process fragment of Agile MERODE (it is a fragment because it is meant to be integrated in the broader Scrum process). I* was already used in a similar fashion to depict process fragment for other methods integrated or not within Scrum (see [43, 48]). The benefit of i* is its ability to represent the social dependencies between the actors/roles while, at the same time, being static and thus non-sequential. Inherently to the nature of agility, different actions can be taken in different sequences for each of the Sprints: multiple activities can be performed at the same time, some can be omitted, others can be added and the sequence is always dynamically built up on the basis of the development context. Workflow-based notations are inherently more directive in terms of sequence, do not highlight social dependencies and are less tailorable/customizable and thus not capable of representing the flexibility needed in Agile processes. The i* notation better allows to deal with the variability in the activities’ execution and selection. Finally, i* also allows to immediately link the tasks that Help or Hurt the realization of the Agile MERODE process’ goals.

Fig. 13
figure 13

Agile MERODE process fragment

Full size image

Figure 13 illustrates the Agile MERODE process fragment through an i* Strategic Rationale Diagram. It distinguishes five roles involved in the software development, more specifically:

  • The End User Role is played by individuals that will be the users of the to-be software. The main Goal of the end user is to Provide Requirements and, as a means to the end of the goal, the End User performs the Task Build Individual User Stories. Involving End Users into this task Helps fulfilling the Softgoal of User Centricity. The Product Owner thus depends on the End User to collect the User Stories;

  • The Product Owner Role is played by individuals in the development team. The main Goals of the product owner is to Gather Requirements and Ensure Project Development. As a means to the end of the first goal, it performs the Task Build/Structure User Story Set. To achieve the end of the second goal, the product owner performs the Task Manage Sprints. The latter task is very important for the success of Agile MERODE since, for its fulfillment, it needs the realization of the tasks Determine User Stories Value and Evaluate (User Story) Precedence Constraints. The first task Helps the realization of the Softgoal High Value Creation with Quick Access, while the second Hurts it. These two tasks need to be realized to, in turn, realize the main task Suggest Features to Implement in the Next Sprint; these features are contained in the USs offering the highest value that are not facing any remaining precedence constraint anymore;

  • The Test Engineer Role is played by individuals in the development team. The main Goal of the test engineer is to Validate Features. As a means to the end of this goal, it performs the Task Build BDD Scenarios out of User Stories which Helps the realization of the Softgoal User Centricity. The test engineer further transmits the BDD Scenarios Resource to the end user of which it depends on to fulfill the task Validate BDD Scenarios.

  • The Software Architect Role is played by individuals in the development team. The main Goal of the software architect is to Design Software. As a means to the end of the latter goal, it performs the Task Structure Software Architecture. The latter task is very important for the success of Agile MERODE since it needs, to be fulfilled, the realization of the tasks Generate Baseline-Architecture and Refine Software Architecture. The two former tasks Help the realization of the Softgoal High Value Creation with Quick Access. Indeed, it is further decomposed in the tasks Generate Domain Model and Generate User Interface allowing fast development of value-supporting software. Both generation tasks may involve the development of adjusted code generation templates. The generation of user interfaces may further benefit from the incorporating the FENIkS extension [34], which allows for defining a presentation model that captures UI requirements, and from which user interfaces can be generated accordingly. Generate Baseline Architecture from BDD Scenarios requires, to be achieved, the Project User Stories (with BDD Scenarios) Backlog Resource that should be furnished by the product owner role (social dependency).

  • The Developer Role is played by individuals in the development team. The main Goal of the developer is to Implement Features. As a means to the end of this goal, it performs the Task Implement User Story Support through BDD Scenario Realization. Achieving the latter task requires the Software Architecture Resource furnished by the software architect role.

6 Case study

Agile MERODE has been applied to the development of the CASE tool—called Merlin—aimed to support the MERODE or Agile MERODE methods’ practitioners (students in business engineering at KU Leuven or professionals enrolled in the Master of Science in Enterprise Architecture at the IC Institute) when developing software in a model-driven fashion. In this project, that we use here as case study, the (development) team was structured following the precepts of Scrum. More specifically, a Product Owner (PO)—specialist in MERODE and coordinating all the demands and feedback coming from the user base—was reporting user requirements to the development team. The latter team was composed of one person being a user interface specialist (so designing these) but acting also as project coordinator and scrum master as well as 2 developers (pure coders). As can be seen in the rest of this section, version 1 had 13 sprints, while version 2 had 4 sprints; the total duration of the project was about 18 months for a total effort of approximately 600 hours. Purely technically speaking, the size of the project was 10.2 MB and involved 1.387 Files in 342 Folders.Footnote 8 The tool’s first goal was to furnish a usable and bug-free environment to practitioners; it was developed using a combination of the React framework (Javascript) and Node.js. Master-level students studying MERODE and using the tool for the term assignment together with the method specialists served as a user-base for defining the requirements of Merlin but also to determine the value associated with the functionalities expressed in USs. As for classical Scrum-based developments, the PO served here as interface between the user base and the development team.

Agile MERODE’s transformation rules from BDD scenarios (each of them associated with a specific US) to the software architecture, as defined previously in the illustrative example, have been applied on the case study leading to a base architecture. Since this forward engineering follows well-defined rules and partially benefits of the experience accumulated with the use of “non-agile” MERODE, we focus here on the scoping analysis and development sequence part of the project. Indeed, we want to study how the project has been divided into valuable features and how this value was evaluated at “Scrum planning game” time. This incorporation in the Scrum life cycle is perceived as a key component of agility and allows demonstrating the feasibility, advantages and drawbacks of the approach.

The development project has been split in two major versions. The main purpose was to align with the academic calendar that constrained the access to the user-base. Indeed, the first version was aligned with the second semester of the academic year 2018–2019 (so during the months February to May 2019) so that for each sprint an executable release could be produced and used by the user-base working on their term assignment (so implicitly tested and co-created with these users). A major version was made after a set of functions had been developed, and the semester came to an end. Each sprint took from 2 to 4 weeks. This first major version was presented as a fully integrated development that could work as a consistent whole and was viable as a standalone product for user support in development. A second version, improving on the first one, was developed after the summer break (so from October to December 2019); this second version essentially concerned refinements of version 1 with no major feature addition and is thus less interesting “planning-game wise”. A documentFootnote 9 presenting sample user stories from the MERLIN development project and explains how they were prioritized has been placed on a persistent URL.Footnote 10

Fig. 14
figure 14

Merlin version 1 sprints

Full size image

The sprints of the first major version could essentially all be planned on the basis of value even if precedence constraints did exist; this will be illustrated in the rest of this paragraph. For readability purpose, we do not get to the level of the individual US but aggregate the discussion at the level of the US themeFootnote 11 as summarized in Fig. 14. Sprint (1) was concerned with the building of a base environment in which the core functions of the application could be developed and was thus seen as preliminary programming work that had to be done independently of the traditional value frame and was not deployed to the entire user base. The next sprint (2) was the first one that concerned a core function of Merlin; its content was, at planning game time after sprint (1), driven by value (only). The PO indeed gave the building of the editor for the EDG (as seen earlier it is basically a refinement of the UML class diagram) as main priority to start up using the tool, USs related to this were thus grouped in a theme and developed. After that, the next sprint (3) concerned building a basic environment for the edition of Object Event Tables (OET); it was also driven by (highest) value as determined by the PO after sprint (2). After sprint (4) involved the development of the Inspection of Objects feature (so group of USs around this theme); this needed the EDG to be developed as precedence constraint, but it appeared that it was already developed so no constraints needed to be respected for the sprint content to be purely value-driven (after sprint (3)). Sprint (5) focused on user experience and existing functionalities refinement on the basis of new requests from the user base as setup by the PO; this sprint was raised by specific feedback from the user-base and is thus driven by immediate user value. Sprint (6) focused on further developments related to the OET; this needed the basis of the OET to be developed as pre-condition, but it appeared that it was already developed so no constraints needed to be respected and sprint (6) content is driven by the highest perceived value at the end of sprint (5). Sprint (7) was devoted to some bug fixing as the user-base pointed out several elements that needed to be fixed/improved for a smooth modeling experience; this was thus driven by immediate user value. Sprint (8) concerned the exporting of Finished State Machines (FSM) diagrams to ensure backward compatibility. This allows using Merlin models for code generation, which is one of the most highly valued features of this tool; thus sprint (8) was purely driven by user value as defined by the PO at the end of sprint (7). Sprint (9) concerned the edition of Finished State Charts. Sprint (9) had sprint (8) as precedence constraint but the since the content of sprint (8) was judged more valuable ex ante, the two sprints were basically value-driven. Sprint (10) was the last main function of the version and concerned the functionalities on multiple propagation constraints. Finally, sprint (11) concerned the exporting of images, sprint (12) the styling and documentation and sprint (13) some bug fixing. These three last sprints did not concern core functionalities but were rather driven by the user-base feedback and late requests so driven by immediate value (and co-created with users).

As mentioned, a few months after version 1 was released, new developments with the same setting were performed to improve the quality, usability and functions of the Merlin CASE tool. No precedence constraints had to be respected, and the model-driven transformation process could be executed. These improvements did not impact the software architecture of the previous version but can rather be seen as a global add-on and refinement of the developed features. Requirements for these improvements (the list is given in Fig. 15) have been collected on the basis of user feedback obtained during the longer window of operation of version 1, and these stories were nevertheless perceived as of equal value and developed in an almost sequential manner. So, although the transformation process has been applied, agility was not a key component for version 2 due to the nature of the developments that were made.

Fig. 15
figure 15

Merlin version 2 functions

Full size image

Figure 16 summarizes the software architecture of the Merlin CASE-tool after version 2; the matching with the sequence of the sprints is given through the numbers. We can highlight an important finding from the sprint execution sequence that was established for version 1. In the end, all of the sprints (but the first one where a base environment for the tool was developed) have been driven by the highest user value for the next release when a sprint ended. Indeed, even if precedence constraints did exist, they have never concretely constrained the development sequence since the features that needed to be build first always had a higher user value than the ones they were constraining. We cannot establish a pattern on the basis of this single case study only, but it could appear that, in many cases, the precedence constraints induced by the model-driven development way of working are not constraining the final (sprint-based) development sequence (because the features that need to be developed ex ante tend to be more valuable for the users). This hypothesis, which is an important finding from the case study, should be further studied and will be the subject of future work.

Fig. 16
figure 16

The Merlin Software Architecture: the numbers correspond to the number of the sprint in which the architectural component has been developed

Full size image

7 Discussion, threats to the validity and related work

7.1 Impact of agile MERODE on the technical debt and communication improvements

This section briefly discusses how the technical debt is minimized through the application of the Agile MERODE process. The use and quality of the models is a key issue for producing qualitative software through an MDSE approach. This principle holds for the use of MDSE within an agile or non-agile fashion. For instance, the MERODE approach strongly focuses on the quality of the created domain model. The method has been grounded in process algebra, thus resulting in extensive quality checks as presented in the following papers [11, 15, 39, 40]. We therefore consider the use of the MERODE approach per se as one element that contributes to the minimization of Technical Debt by its powerful quality checks on the domain model. The second contributing element is the domain-driven nature of the MERODE approach. We propose to strengthen the combination of Agile with the domain-driven approach by the use of a preliminary sprint (the so-called Sprint0) where, out of a project’s initial US set, a first creation/generation of domain objects is made along the idea of “just enough modeling”. The extent to which this initial domain model covers a sufficiently large portion of the final domain model is a strong instrument to avoid Technical Debt as much as possible. Moreover, MERODE’s principle of existence dependency helps to clearly outline technical constraints to be considered when performing the value-based prioritization of USs during sprint planning.

Benefits in terms of communication generated by our framework can be approached from different perspectives. First, when compared to a classical Scrum process, Agile MERODE and its intrinsic MDD allow fast (generated/no-code) prototyping. Thanks to this, workable interfaces can be delivered and validated early on in the software development. Second, when compared to a classical MERODE-based development, the inclusion in the Scrum life cycle allows (i) the adoption of USs, which is a requirement artifact allowing an easy communication with the end users, and (ii) a sprint-based approach generating user-feedback early on and continuously through the development allowing to optimize communication on requirements, expectations, domain-specific elements, etc.

7.2 Flexibility in planning

The (model-driven) approach from MERODE inherently leads to constraints in the technical development (complete coding) of the software which are inherent to any coding: whatever module using the service of another requires the latter to be created first, thus implying that a specific sequence in building and coding the objects of the object-oriented application needs to be respected. This obviously impacts the iterative (sprint) scheduling of software functional aspects. The selection of USs for the next sprint is thus constrained and cannot be realized in a totally neutral value-driven perspective. The benefit of the MERODE approach is that the layers and the clearly identified dependencies in the domain model provide clarity in what the technical dependencies are thus helping the sprint planner taking well-informed decisions. The approach, in its entirety, thus allows to reduce the technical debt by building the architecture in a logical, consistent and complete manner. In order to avoid technical debt, the MERODE life cycle thus always requires a compromise to the pure agile planning based on value. All in all, using the MERODE approach implies making a trade-off in the value-driven approach to get a clean software architecture for the software application delivered as ultimate project output.

The inclusion of such constraints in sprint-based planning is a known problem in approaches combining ASD and MDSE. Shafiee et al. [37] identify that, for the development of product configuration systems, based on so-called Product Variant Master models [20], precedence constraints do appear because of dependent features also influencing the sprint planning. In Agile MERODE, the planning game is nevertheless not comparable with the approach of the AUP. As said earlier in the paper, by following the RUP template inducing a clear segmentation in phases, AUP implicitly leads to a plan-driven iterative planning from the beginning of the project without the aim of producing a deployable release at the end of each sprint. Even if releases only partially address the solution space, releases of each sprint of Agile MERODE are made to be deployable.

7.3 Heaviness and scalability in the method application

The application of the Agile MERODE method involves the characterization (tagging) of elements constituting the US and BDD scenarios. Even though this may be seen as a time investment from requirement engineers, the process in fact allows (i) to sort the requirements and make them more consistent and (ii) to spare a lot of design time.

Sorting the US is a natural process made in the agile development. The process is often made in the form of User Story Mapping (USM) [31], leading to grouping a set of US under a major feature contained in a so-called Epic US. Tsilionis et al. [42] have compared the process of building a Rationale Tree (which is a visual representation of US elements defined in [50]) with the ability to structure a set of US with USM through a controlled experiment. This experiment is relevant here because part of the work to build the visual model implies making the same kind of tagging of US elements as implied by the application of Agile MERODE. Tsilionis et al. [42] conclude that while a USM is easier to build-up, the evaluation of the US nature and structuring leads to discovering missing requirements and increasing the consistency of the entire US set. This ends up being very useful in the overall approach, and also, implicitly will reduce the technical debt if missing base requirements can be identified early on. As seen in the paper, when appropriately evaluated, the nature of the US and BDD scenarios’ constituting elements lead to an easy process of forward engineering to a software architecture that can largely be automated through the use of the CASE-tool. Such automation is only possible through the use of MDSE and is thus generally not used in ASD while it leads to a significant design-time reduction.

Finally, we could question the scalability of the approach. As such, the larger the case, the more dealing with technical debt becomes an issue and the more the approach makes sense when compared to a classical ASD one.

7.4 Integration of MERODE within other agile methods and practices

As seen, Agile MERODE integrates the MERODE approach within the Scrum development life cycle. One could raise the question of how to integrate MERODE with other agile methods and/or practices. Basically, we can distinguish two ways of integrating ASD with MDSE. On the one hand, we can perform a structural integration of a MDSE-based method within an existing agile life cycle to anchor the practices of MDSE into ASD. This is precisely what we did to build Agile MERODE: we started from the Scrum lifecycle and anchored MERODE’s MDSE practices to user stories and BDD scenarios (natural requirements engineering artefacts of Scrum). This way we now dispose of the sprint-based life cycle of Scrum enriched with new models and concrete support to build a neat software architecture. On the other hand, a myriad of agile practices are reported on in literature (see, for example, [23] for a literature review and an adoption approach). These practices are prescribed by some agile methods but can also be adopted independently of any agile method.Footnote 12 It is indeed not because a development team adopts an agile method that every prescribed practice should necessarily be included and, also, an agile practice can be adopted independently of the method prescribing it. Each known agile practice can thus be adopted within MERODE or Agile MERODE developments to increase the overall level of agility. Such an ad hoc adoption is, however, not a lifecycle adaptation exercise (as described formerly) but rather the punctual change of a method’s application context to include a chosen practice(s). Most agile practices do indeed not have a structural impact on the software development process itself but rather impose contextual constraints on the way to operate (e.g., develop in pairs, be on the same site of the customer, etc.).

eXtreme Programming (XP) [7] is one of the earliest agile methods; its (structural) agile life cycle is much less advanced than the one from Scrum. Adapting MERODE to XP would thus rather lead to ad hoc agile practices adoption within the MERODE method’s application context than generically restructuring MERODE around an advanced agile life cycle. As an example, pair programming, one of the core prescribed XP agile practices, can be integrated in a MERODE development project. Similarly, an artefact like the KANBAN board [1] can be adopted as a practice in an Agile MERODE development (which is classically done within Scrum developments). Several practices can thus be adopted in an ad hoc fashion if required. All in all, Agile MERODE integrates the Scrum life cycle because it is an advanced and widely validated life cycle leading a structured approach of agility in MDSE developments. It seems the best choice compared to less complete or less often used agile methods. Agility nevertheless remains a non-finite concept. The panel of agile practices at disposal and prescribed by various methods is broad, and new adoptions can be made to MERODE or Agile MERODE. The aim was to provide a basis for a structured approach to agility in MDSE that can be further customized to integrate more agile practices as required by the development context.

7.5 Threats to validity

7.5.1 Construct validity

A threat to the construct validity is that the modeling constructs are incorrectly interpreted by the modelers or any other practitioner aiming to put Agile MERODE into use. This includes the risk of using the concepts of the framework in another way than intended. In the present case, the application was done by the creators of the method so it does not constitute a serious issue. Nevertheless, to deal with such issues within the application of the method by others, specific guidelines can be integrated within the Merlin CASE tool providing help for the relevant concepts within the functions of the supporting tool.

7.5.2 Internal validity

The internal validity concerns the knowledge acquisition process and more precisely the objectivity of the views gathered. The knowledge acquisition holds no threat to validity for the authors being MERODE expert on the one hand and Scrum expert on the other hand. The issue of objectivity could on the other hand pose a threat, given the authors potential bias in favor of the method. The threat has been mitigated by careful analysis of other approaches and by the having the case study analysis performed by the author who was not involved in the project. Additional case studies where the method is applied by practitioners who were not involved in the method’s development could provide additional robustness to the validity of the method.

7.5.3 External validity

The external validity is threatened by the incapability of applying the Agile MERODE method in other circumstances. The process has until now only been applied by the same set of people considered as experts in model-driven development and agility. Previous knowledge with techniques like US writing and mapping, BDD, UML and other techniques and notations can have a significant impact on the ability to apply the method. Experiments on the ability to perform US-based analysis and mapping (see [42]) by novice modelers and MERODE-based model-driven development [36] both showing the ability of novice modelers to apply the theoretical foundations with proper guidance. Also, MERODE is mainly applied in data-intensive domains, where the domain model is an essential part of the system to build. This does not preclude computationally intensive services using this data, but the design and modeling of such services are not supported by the MERODE method, since it only offers UML class diagrams and UML state charts as most essential models for the domain layer and relies on BPMN for the process layer. The use of an event-driven architecture when defining transformations for the EHL would allow to deal with reactive systems; more investigation is nevertheless necessary for defining an exact process to approach such systems in an agile fashion.

7.6 Related work

Overall, when comparing Agile MERODE to the related work reviewed in Alfraihi et al. [3] and published in more recent papers, the main distinctive factors are (1) that, in contrast to the dominantly MDD-based character of pre-2016 methods [3], Scrum is taken as a basis, and MDSE principles are incorporated via the combination with MERODE and (2) the explicit attention for how to deal with architectural constraints.

Table 4 provides an overview of the Agile and MDD practices used in [3] to compare the different approaches, together with the number of occurrences in the reviewed studies. The additional columns extend this overview with the proposals by Essebaa and Chantit [13], by Romano et al. [33], by Alam [2] and by the approach presented in this paper.

Table 4 Evaluation and comparison of agile MERODE with respect to other frameworks
Full size table

In terms of Agile practices, Agile MERODE addresses test-driven development through the use of BDD. Pair development is possible even if the practice adoption does not depend on the process itself but is rather a matter of internal organization of the development team working on a sprint. We consequently see it as not immediately related to the process as we have defined it. Continuous integration is essentially possible if the deployment constraints are treated upfront within the release development during the sprint. Agile MERODE could be supplemented in this way, but it is not included as such in the process as described in the paper; we indeed only focus here on the development teams’ activities. Because of the combination with MDD, it is assumed that the need for refactoring is drastically reduced, and in case refactoring is needed, this should be addressed by means of redesigned code generation templates, thus being part of the MDD practices rather than the Agile practices. The remaining practices are addressed by the fact that Agile MERODE incorporates the Scrum practices.

In terms of MDD practices, MERODE generates code automatically from the domain model, which was created from a manual analysis of the US and BDD. The automatic (partial) creation of domain models from US and BDD as in [52] could be investigated in future work. The class diagram and state charts comply to UML modeling, but the OET is a MERODE-specific modeling techniques, here labeled as “Domain Specific”. Models are not directly executable, except for the BPMN models that define the process layer. Model-to-model transformations are not used by default. The addition of UI-design models in MERODE has been explored by Ruiz et al. [34] and makes use of model-to-model transformations for the generation of an Abstract User Interface. While we did not discuss the addition of model-based testing, this has already been explored in the context of MERODE [27]. Finally, XML modeling and round-trip engineering are not used by Agile MERODE.

Essebaa and Chantit [13] propose a combination of MDA, Scrum and the V-life cycle to improve the process of individual sprints and generating tests using model-based testing principles. The description of the approach mostly focuses on the MDD practices. As the authors build on Scrum, it can be assumed that most agile practices are incorporated in the approach, although this is not explicitly described. The authors also do not provide indications on how to address the architectural constraints in the planning of sprints. In Romano et al. [33], a framework and method for Agile and Collaborative Model-Driven Development framework for web applications (Web-ACMDD) is presented. While the description of Web-ACMDD provides an overall flow and a UML activity diagram describing the steps, the method is at an early stage of development. The actual incorporation of Scrum activities nor MDD practices is described in detail. On the other hand, the authors propose a UML profile to allow for the agile modeling of web applications. Here too, architectural constraints are not discussed. In contrast to our proposal, their sprint 0 does not advise to create a domain model. Portions of the domain model are created during the individual sprints. Besides domain class models and USs, this approach also includes models for Human Machine Interface.

Finally, the agile concern-driven development (CDD) process [2] is a reuse-focused development process in which an application is built incrementally by reusing existing building blocks. The framework builds on CORE, a framework inspired by separation of concerns, software product lines, goal modeling and aspect orientation. In the initial sprint, goal-oriented modeling languages are used to hatch out high-level requirements, upon which an iterative process develops the application by reusing concerns. The authors suggest that some reusable concerns such as concerns related to security, e.g., authentication or authorization, could be identified and reused early during the requirement phase, thus facilitating addressing architectural concerns. While the Sprint 0 advices the exploration of the domain by means of goal modeling, the creation of a conceptual domain model usable for code generation is not part of the approach.

8 Conclusion

At this stage, we can get back to the RQ stated in the introduction (How can a MDSE method like MERODE be anchored in an ASD structure for user-centric and value-driven (i.e., agile) development to minimize the technical debt?). To answer this RQ, we have developed the Agile MERODE framework. In terms of user centricity, it uses US and BDD scenarios as artifacts for the collecting and representing requirements. For flexible value-driven iterative development, the framework is anchored in the (industry-adopted) Scrum life cycle. The framework allows to reduce technical debt through the generation of a well-organized architecture on the basis of the (high-level) requirements elements found in the BDD scenarios related to US. A significant amount of time can also be saved through automatic generation of the software architecture.

The model-driven approach enables the automatic generation of a partial software architecture. Nevertheless, the software architecture implies a number of precedence constraints on the sequence in which USs are developed (e.g., in order to address USs related to behavioral modeling, we need the USs related to data modeling to have been implemented already). This did not appear to be an important issue at project time. Indeed, sprints do contain consistent developments in terms of common theme in the USs supported and the parts depending on other parts are often perceived by the user-base and the PO as less valuable than the ones that do not present such precedence constraints. Thanks to that, the pure value-driven way of working could be respected within the development of the Merlin tool. Future work involves the realization of more case studies in various domains to further test this hypothesis as well as further developments of the Merlin CASE tool to better support the sprint-based way of working through a custom interface; an expert opinion has also been collected and will be fully documented.