Keywords

1 Introduction

Software evolution aims at keeping software systems of any kind aligned with users’ needs, which are influenced by individual, social, economic, and technological changes. That part of software engineering is receiving more and more attention since software has become a pervasive and key element in modern society [1, 2].

Basic principles and processes of software evolution [3] have been revisited in the light of the high availability of data, reflecting the variety of modern software, and of efficient techniques to mine such data. Indeed, key knowledge to foster short and frequent evolution cycles can be extracted from these data, which is both produced explicitly by users (i.e. user feedback), and resulting from monitoring the context in which the software is executed, as well as the software itself at runtime [1].

As in any other software engineering process, the formulation of methods for data-driven software evolution is of paramount importance. These methods should allow clearly identifying the roles involved, the activities undertaken, the resources involved, and the tools utilized. One of such methods is SUPERSEDE, which has been produced in the context of an H2020 EU project with the same name (www.supersede.eu). The SUPERSEDE method drives the data-driven evolution process in a systematic way. It aims at reconciling generality to accommodate different types of organizations and customisability, as to allow the method to be effectively adopted by an organization that may differ in characteristics as size, business domain and other factors.

The research goal addressed in this paper is to provide a systematic definition of the SUPERSEDE method for data-driven software evolution. We aim at SUPERSEDE acting as a reference method that can be tailored to different situations. Therefore, we adopt Situational Method Engineering (SME) [4] as engineering approach to design the method as a composition of reusable components called method chunks. The research questions that we address in relation to this type of evolution are:

  • RQ1. What are the constituent parts of method chunks for data-driven evolution?

  • RQ2. What are the criteria whose combination allows expressing the context in which these method chunks apply?

  • RQ3. What are the most fundamental method chunks for data-driven evolution?

  • RQ4. How can the different method chunks be combined in order to create organization-specific customizations of the SUPERSEDE data-driven evolution method?

2 Research Method

The formulation of the SUPERSEDE method has followed a 3-stage process:

  • Stage 1: Requirements gathering. We elicited requirements through dedicated workshops with key stakeholders in relation to the topic of software evolution from three companies participating in the SUPERSEDE project (Siemens, SEnerCON and Atos) and created a requirements document [5]. Requirements comprised as-is and to-be goal models, plus the user stories emerging from this to-be model, all of them coming from workshops held at the companies’ site (see protocol in [5]).

  • Stage 2: Elaboration of SUPERSEDE engineering artefacts (models, techniques and tools). In the second stage, we analysed the collected requirements as input to determine the elements composing the SUPERSEDE method. The elaboration and evaluation of these engineering artefacts helped to understand the intricacies of the elements to be integrated in the method.

  • Stage 3: Formulation of the SUPERSEDE method for evolution. In this third stage, we adopted SME as scientific approach in order to organize under a holistic view all the artefacts gathered in the previous stage. Regular meetings allowed the incremental synchronization of the method components. Advances were systematically checked against the result of the first stage (requirements compiled in [5]).

3 Background

3.1 Situational Method Engineering

To formalise the SUPERSEDE method, we apply Situational Method Engineering (SME) [4] principles and techniques. In SME, a method is viewed as a collection of autonomous and interoperable method components that can be selected and assembled in a way to satisfy the particular situation of the project at hand. The definition of method components and their assembly techniques vary from one SME approach to another [4]), but the main objective stays the same: to make the method knowledge modular and reusable for the construction and/or adaptation of situation-specific methods. Most of the assembly techniques support method construction from scratch based on the identified situational context and requirements, other deal with incremental organization’s method adaptation or even method family construction.

In our work, we adopt and adapt the assembly-based and method chunk-based SME approach [6, 7] that supports situation-specific method construction and extension in three steps: method requirements specification, method chunks selection and assembly of the selected chunks (details given in Sect. 6 as needed). Method chunks are reusable method components. A method chunk includes a process (i.e., the guidelines provided by the method chunk) and its related product knowledge (i.e., the formalisation of concepts and artefacts used and produced by the method chunk), and is specified by the situation in which it can be applied (i.e., the required input artefacts) and the intention (i.e. the engineering goal) to be reached. Finally, the reuse context of the method chunk is specified by a set of criteria that can be defined by using a taxonomy like the reuse frame proposed in [8]. We apply an ad hoc method chunk definition approach [9] that creates chunks from experts’ knowledge, based on a method chunk metamodel.

3.2 The SUPERSEDE Data-Driven Control Loop for Software Evolution

SUPERSEDE’s data-driven software evolution process takes inspiration from the autonomic control loop proposed for adaptive systems [10]. In SUPERSEDE, the control loop drives also software evolution, considering runtime and context data, and also explicit user’s feedback, which the user might deliver upon having used the software.

The SUPERSEDE process can be characterized by the following steps (see Fig. 1):

Fig. 1.
figure 1

The SUPERSEDE control loop

Full size image

Collect.

Multi-modal feedback gathering techniques allow users to express their feedback as textual comments, emoticons, rating and pictures. Flexible and configurable monitoring components collect a huge volume of data from the context and system usage [11]. These data, of different types, are stored in a big data storage, which maps data to a semantic model at support of analysis [12].

Analyse.

Different types of analysis are tool-supported, for instance, sentiment analysis and extraction of feature requests and bug issues from user textual comments [13], tweet mining to understand perceived quality of experience [14], and combined analysis of end-user feedback and contextual data.

Decide.

Focusing on software evolution tasks, automated reasoning techniques support collaborative-decision making concerning, for instance, the identification of new requirements, and their prioritization with respect to multiple criteria [15].

Act.

Operationalizations of the decisions made are performed at this step. Selected features are included in a release plan that takes into account available resources, deadlines and organization priorities [16]. In addition, this step can be refined during the actual implementation of the next release using a continuous release planning approach [17].

4 Method Chunks Metamodel for SUPERSEDE

In this section, we address RQ1 (What are the constituent parts of method chunks for data-driven evolution). Following the advices in [9], we implement the concept of method chunk using a process-oriented view. We base our work on existing software process modelling approaches, e.g. from SPEM [18]. We build a metamodel articulating the subset of method elements that are relevant for our purposes, namely activities, artefacts, roles and tools, each one yielding a particular class in the metamodel. Then, we link method chunks to these classes.

4.1 SUPERSEDE Method Elements

Activities, artefacts, roles and tools are declared as specializations of an abstract class MethodElement (see Fig. 2), which links every method element to one or more phases of the SUPERSEDE loop, allowing also referencing to external concepts (e.g., a role not needed by the method but referenced for the sake of completeness). We declare a reflexive association class to express relationships among method elements that will be specialized according to the different types of method elements whenever needed. All method elements may present structural relationships (composition and specialization) and each method element may present other particular types, as we detail below.

Fig. 2.
figure 2

Elements of the SUPERSEDE method

Full size image

Activities involve artefacts, tools and roles. In a nutshell, activities are tasks in which one or more Roles are involved, and are carried out with the support of Tools, which receive one or more Artefacts as input and generate other Artefacts as output. Examples of activities are Feedback Collection (linked to the Collect phase), Domain Ontology Definition (Analyse), Requirements Prioritization (Decide) and Release Planning (Act). Structural relationships will be widely used; for instance, Requirements Prioritization will be specialized into several sub-activities, each adopting a particular prioritization strategy (e.g. Requirements Prioritization with AHP). In addition, activities may present several types of temporal relationships; we adopt the proposal in [19] (richer than SPEM when it comes to temporal relationships) with relationships like start-start, end-start, exclusion, etc. (e.g. Release Planning cannot start before Requirements Prioritization has ended). In all the types of process elements, particular relationships are defined by specializing the MEOtherRel class (see Fig. 2) and including integrity constraints to enforce application to the right type.

Artefacts represent informational resources that are produced, consumed or just used as a working asset by an activity. Examples of artefacts are Feedback Document (produced as output by the Feedback Collection activity), Prioritized List of Requirements (consumed as input by Release Planning) and AHP Matrix (used as working asset by Requirements Prioritization with AHP). Artefacts are declared of a particular category. Examples are: Model (e.g., Integration-Oriented Ontology), File (e.g., Monitoring Data), DataSet (e.g., Project Schedule), Technology (e.g., Event Queue Endpoint) and Expression (e.g., Complex Event Pattern). Categories may be decomposed into subcategories at any level, for instance the Integration-Oriented Ontology belongs to the Ontology subcategory in Model. Artefacts may be related to each other by structural relationships: aggregation (a List of Requirements as aggregation of Requirement) and specialization (Prioritized List of Requirements as specialization of List of Requirements). Other relationships are possible, like constraint (e.g., a Release Plan constrains a Project Schedule) or in-sync, meaning that changes in one artifact imply changes in another (e.g., a Release Plan is in-sync with a Prioritized List of Requirements).

Roles are involved in activities either individually (e.g., Project Owner) or as a set of person (e.g. Set of Developers), which is expressed with an association class (SetOf).

Tools are also used in activities, and they produce and consume artefacts and involve roles. All these associations among the four type of process elements are not independent and some integrity constraints need to be declared (not included here for the sake of brevity), e.g. context Activity inv : self.tool->includesAll(self.input.tool). Relationships among tools include connection (i.e., the result of one tool is used by another). Again this association is related with others through integrity constraints, e.g. if the RePlan tool (which produces a ReleasePlan) is connected to DMGame (which produces a Prioritized List of Requirements), then the corresponding artefacts need to be in-sync.

4.2 Definition of Method Chunks

Every activity in SUPERSEDE begets a method chunk for the catalogue. We consider that the description of the activity is the process part of the chunk, while the output of such activity (i.e., the list of produced artefacts) is the product part. The situation of the method chunk is given by the list of consumed artefacts, while the intention needs to be explicitly given in the form of a goal. We also include the definition of the chunk reuse context, which has been defined in [8] as a taxonomy of criteria (details are given in Sect. 5.2); not all the criteria apply to every chunk. Finally, we extend the definition of method chunks with the Role and Tool attributes representing the corresponding SUPERSEDE method elements and presented in the section above.

Figure 4 shows the metamodel corresponding to the definition of method chunk. For convenience, several derived roles are explicitly declared which can be computed from roles appearing in Fig. 3. Also an associate association class is introduced as derived from the corresponding activity-binding association class appearing in Fig. 3.

Fig. 3.
figure 3

Detail of the SUPERSEDE method elements

Full size image

5 A Catalogue of Method Chunks for SUPERSEDE

In this section, we address RQ2 (What are the criteria whose combination allows expressing the context in which these method chunks apply) and RQ3 (What are the most fundamental method chunks for data-driven evolution). To address RQ3, we present the method chunks of the SUPERSEDE method that we have developed following an ad-hoc approach and applying the method chunk metamodel shown in Fig. 4.

Fig. 4.
figure 4

Metamodel for method chunks

Full size image

5.1 Context Criteria Applicable in the SUPERSEDE Method

As reported in Sects. 3.1 and 4.2, context definition using SME is implemented by the definition of context criteria that capture the factors that may influence in the selection of a method chunk for a particular instantiation of a method. In [8], a proposal is given resulting in two relevant outcomes: (1) a 3-tier context structure in which a few dimensions are decomposed into facets, and the facets into criteria; (2) a concrete proposal of this context structure for the information systems field by 2006.

We have evolved the original proposal by incorporating additional criteria that may be needed in a particular context in order to decide if one particular chunk has to be part of a customization of the SUPERSEDE method. Table 1 presents an excerpt of the result, focusing on the most relevant criteria for chunk selection (i.e., whose values affect a greater number of chunks). Criteria with an (*) are new, mostly related to the data-driven approach adopted in the SUPERSEDE method. Range of values adhere to the original proposal as much as possible; when subjective, value assignment relies in expert criteria. Definition of the relevant criteria follow:

Table 1. Criteria for SUPERSEDE reuse context
Full size table

  • User involvement. Related to the participation of the user in the chunk’s activity. Relevant for activities related to feedback gathering (end-user involvement) but also for technical ones (e.g., involvement of project managers in release planning).

  • Resources required (evolution of Means shortage in [8]). To measure the complexity of an activity with respect to personnel, infrastructure, etc. It affects especially activities that require code development (e.g., new monitoring components).

  • Size (of the project). Size may impact activities whose feasibility depends on the volume of work. A typical example would be prioritization techniques (e.g., AHP comparison) that do not scale well with a large number of requirements.

  • Delivery strategy. The type of delivery impacts the later stages of evolution. Heavyweight prioritization techniques are cumbersome to use with frequent releases, and classical release planning does not apply in continuous delivery contexts.

  • Type of end-user. Some users may be more educated than others from an IT consumer perspective. It may be expected that a technician using the feedback gathering mechanisms will be more accurate than a regular citizen.

  • Accuracy. The level of accuracy sought impacts on the selection and customization of some techniques. For example, as we will see in Sect. 5.3, different prioritization techniques exhibit different accuracy levels.

  • Motivation. In data-driven approaches, one strategy to get more data is to motivate stakeholders to make them willing to participate actively. Not only end-users, but also technical stakeholders may be involved using gamification techniques.

  • Other assumptions. This criterion collects very specific conditions not belonging to the previous types that need to be fulfilled in order to apply the chunk. They may refer to the organization, adopted techniques, involved roles, etc.

5.2 A Catalogue of Method Chunks

We group the chunks into four categories. For all the categories, an initial chunk (Chu-XXX-01) represents an initial deployment activity, which is sometimes decomposed into subactivities. We omit these ones for brevity and present below the rest of chunks and their relationships (see Fig. 5). Being a data-driven approach, the chunks have emerged naturally by following the flow of data across the four phases of the control loop, with every significant data process converted into a process chunk.

Fig. 5.
figure 5

Relationships among SUPERSEDE evolution method chunks.

Full size image

Chunks for Collection.

Data enters the SUPERSEDE process in two different ways. First, end users may provide feedback using multi-modal mechanisms configured at design time but also at runtime (although runtime issues, belonging to the self-adaptation world, are not included in this paper) (Chu-Col-02: Feedback Collection). Second, SUPERSEDE may monitor data without users’ explicit intervention (Chu-Col-03: Monitoring Data Collection). There are three different types of monitored data: quality of service, e.g. response time or availability (Chu-Col-03a: QoS Monitoring); monitoring of social networks as Twitter (Chu-Col-03b: Social Network Monitoring); users’ usage monitoring (Chu-Col-03c: Usage Monitoring). The collected data are sent for analysis following the SUPERSEDE loop.

Chunks for Analysis.

The SUPERSEDE data-driven approach relies on the conceptualization of relevant ideas using a domain ontology defined by a data steward who mediates with domain experts from the organization (Chu-Ana-02: Domain Ontology Definition). This ontology is used as the basis to define the event recognition rules (Chu-Ana-03: Definition of Event Recognition Rules) that will capture needs for evolution as well as the logical definition of data coming from feedback and monitoring (Chu-Ana-04: Source Ontology Extraction). Collected data are processed in a last chunk (Chu-Ana-05: Event and Pattern Detection) that applies the recognition rules to the monitored data coming from Chu-Col-02 and Chu-Col-03 and produces the real needs in the form of events and patterns to be decided upon in the next phase.

Chunks for Decision.

The alerts produced by Chu-Ana-05 are captured by a method chunk that converts them into a list of requirements by means of collaborative editing involving some selected requirements analysts (Chu-Dec-02: Requirements Collaborative Editing). Since they have been produced independently, it may be the case that requirements are overlapping or present other relationships, therefore a consolidation of the list is made right away (Chu-Dec-03: Requirements Similarity Check). This consolidated list is then prioritized involving again the appropriate (or available) set of stakeholders, to generate a prioritized list of requirements (Chu-Dec-04: Requirements Prioritization) to be processed by the enactment method chunks. There are several strategies for prioritizing requirements, and we present here three of them (Chu-Dec-04a, Chu-Dec-04b and Chu-Dec-04c, using AHP, Gamified AHP and Genetic Algorithms, respectively) which differ in some context criteria (see details in next subsection).

Chunks for Enactment.

The prioritized list of requirements is processed by a release planning activity (Chu-Ena-02: Release Planning) that considers also the list of available resources as input, and then produces a release plan.

To ensure the correctness and adequacy of the aforementioned method chunks, we checked them against the requirements posed by the three companies mentioned in the introduction [5] ensuring that the catalogue of method chunks satisfied their needs. Furthermore, we conducted regular meetings to check that the different method chunks matched well with each other.

5.3 Example: Requirements Prioritization

For the sake of illustration, in this subsection we present a method chunk in detail, namely the chunk for requirements prioritization, together with a summary of its three current specializations.

Requirements prioritization elaborates on a set of requirements produced by a previous activity (Chu-Dec-03, which needs to be finished before starting this one), and applies a set of weighted criteria to the information elicited from several stakeholders, as to provide a list of prioritized requirements that serves as input of the release planning activities. The SUPERSEDE method applies a gamification approach to prioritization, and a software tool called DMGame has been developed with this purpose. Three types of stakeholders collaborate around this tool: a Supervisor supervising the process, a Negotiator mediating in conflicts and the Decision Providers that provide the necessary information for prioritizing. It is worth remarking that this chunk has not context criteria applicable, meaning that it will be instantiated in any possible situation. We expect this to be the usual situation in abstract method chunks, leaving the criteria to the specializations as shown below.

We have built three different specializations for this abstract chunk until now. Two of them are based on the AHP method, a third one on genetic algorithms. As a specialization, the information is inherited, thus only new information needs to be added. In the case of these three specializations, only the context is concerned. The context criteria that affect the selection of the specialization are shown in Table 3, with the values that apply to every specialization (Table 2).

Table 2. Method chunk for requirements prioritization (DM: Decision-Making)
Full size table

As a short summary, AHP-based methods require more user involvement and thus more resources and also suffer from limitations on the number of requirements to handle and from the assumptions needed to ensure the accuracy of the method (which is higher than the case of genetic algorithms). Although not critical, there are some differences also in the type of end-users and the delivery strategy. Concerning the two AHP methods, the main difference among them is the higher motivation required for AHP.

6 Steps for Adopting SUPERSEDE: A Situational Approach

It is not sufficient to transform a method into a collection of method chunks to make it situational. Hence, in this section we address RQ4 (How can the different method chunks be combined in order to create a customization of the SUPERSEDE data-driven evolution method tailored to a particular context). To address this RQ, we need to provide guidance for creating situation-specific SUPERSEDE methods and allowing companies to tailor SUPERSEDE to their needs. For that, we follow the generic three-step assembly process mentioned in Sect. 3, that we specialise for SUPERSEDE as follows (see Fig. 6). The formalization of the process is just outlined; it cannot be developed in full due to space reasons.

Fig. 6.
figure 6

The three-step assembly process for the SUPERSEDE method tailoring.

Full size image

Method Requirements Specification.

The first step consists in defining functional and contextual method requirements. Functional requirements capture a set of engineering intentions that shall be fulfilled by the new method, while the contextual ones reflect the situation of the project at hand in terms of assessed criteria from the reuse context.

We propose to use i* goal models [20] and domain knowledge to extract method intentions and to assess context criteria. Indeed, a goal model interconnects the main actors via goal dependencies and allows to derive method intentions from these goals. We recommend, to construct first the as-is goal model reflecting the current situation of the organization. Then, the envisioned situation is designed as a to-be goal model. For the to-be situation, we propose to link intentional elements to relevant context information that allow identifying context criteria and, therefore, to derive not only method intentions but also contextual requirements. The result of this step can be stated then as a set of method requirements, namely contextual goals, P = {cgk} where every method requirement is a pair cgk = (gk, Ck) of a goal and a set of conditions of the form Ck = {(ci, vi)}, being ci a contextual criterion and vi a valid value for such criterion. Note that Ck is a correspondence, allowing thus different values for a criterion.

Method Chunks Selection.

In the second step, the method requirements are used to select method chunks by matching them with method chunk components. The selection query is the model P above which is compared against the catalogue (C, R) of method chunks, C = {mck}, and their relationships, R = {(mc1i, mc2i, tri)}, being mc1i and mc2i two method chunks and tri a type of relationship valid for them. For the selection process, we consider only as relevant information of method chunks the intention and the context, mck = (intk, contk), where contk has a similar structure than Ck above.

The matching among P and (C, R) can then be defined as a set of selected method chunks SMC = {smck} where each smck = (intk, contk) fulfils several conditions: (1) the intention of the chunk satisfies some functional requirement gk of the query, intk ⇒ gk; (2) the context criteria of such functional requirements are satisfied by the chunk, contk ⇒ Ck; (3) the intention of the chunk does not violate any other functional requirement of the query, ¬(intk ⇒ ¬gi). Please note that we do not consider relationships in the step, but in the next one.

Ideally, the selected method chunks should cover all functional method requirements and satisfy the context conditions. In case some functional requirement is not satisfied, other method sources will be explored and formalised as method chunks to fill the gap (see next step). On the contrary, if there are several method chunks satisfying the same requirement (i.e. producing the same outputs in different ways) two possibilities are to be considered: (1) selecting only one of these chunks, so the decision is taken by the method engineer, or (2) postpone the decision to method enactment time (see next step).

Method Chunks Assembly.

The last step consists in assembling the selected method chunks into a coherent method. In the case of SUPERSEDE, that will mainly consist in defining the order of chunks execution based on their input and output artefacts and complete missing elements by ad hoc (eventually non-reusable) chunks.

Let M be the method corresponding to the SUPERSEDE instantiation under construction, M = mek}, being mek an instance of the MethodElement abstract class introduced in Fig. 2. The rules to be applied are:

  1. 1.

    Connect the selected method chunks according to the relationships in R: ∀(m1, m2) ∈ SMC: (m1, m2, t) ∈ R ⇒ (m1, m2, t) ∈ M. The inclusion in M takes care of including and connecting artefacts, roles and tools as specified in the metamodel.

  2. 2.

    For those contextual goals {cgk} in P not covered by any method chunk in SMC, explore other method sources and formalise them as method chunks to fill the gap, applying the steps above as required.

  3. 3.

    For those contextual goals {cgk} in P covered by more than one method chunk in SMC, providing arguments for the inclusion in M of either only one of them (if they are exclusive) or a subset (if they are complementary).

7 Example

We present an illustrative example of the application of the SUPERSEDE method to the SIEMENS project use case, which concerns the development and evolution of a smart-city platform (Eco Sys. Platform).

Method Requirements Specification.

A SIEMENS department has adopted the SUPERSEDE method as shown in Fig. 7, which depicts an excerpt of the i* to-be goal-oriented model for this use case (see [5] for the full version). The Project Manager relies on the SUPERSEDE method for achieving key goals that will allow improving the way the department evolves and maintains the Eco Sys. Platform, in relation to feedback analysis, collaborative decision-making and release planning. The Development Team relies on SUPERSEDE method to improve collaborative decision-making. Eco Sys. Platform requires SUPERSEDE to ensure privacy compliance. The goal diagram of SUPERSEDE actor models the goals that the method has been delegated to achieve, which are refined using decomposition (just hinted in the figure).

Fig. 7.
figure 7

To-be contextual goal model with information of two projects (simplified example)

Full size image

The SIEMENS department can perform different, and possibly simultaneous projects. Each project is characterised by specific values of context properties (depicted as a simple list of item in the rectangular shapes in Fig. 7) which need to be mapped to contextual criteria (Table 1). For instance, in Project1, which concerns the implementation of a small set of new requirements to improve the platform reliability, privacy compliance is not critical, while in Project2, which deal with a larger set of requirements related to the management of usage logs, privacy compliance is highly relevant. The analysis of the resulting contextual goal model will lead to the identification of a set of method requirements, such as cg 1.1  = (G1.1, C 1.1 ), where C 1.1  = {(user involvement, high) (size, small) (accuracy, high) (motivation, high)}, and cg 1.2  = (G3, C 1.2 ) where C 1.2  = {(privacy, sensible)} for the SUPERSEDE method configuration in Project1. Similarly, for Project2, method requirements include cg 2.1  = (G1.1, C 2.1 ), where C 2.1  = {(user involvement, medium) (size, medium) (accuracy, fair) (motivation, medium)}, and cg 2.2  = (G3, C 2.2 ) where C 2.2  = {(privacy, very sensible)}.

Method Chunks Selection.

These method requirements drive the selection of method chunks. For instance, requirements cg 1.1 matches to the method chunk Chu-Dec-04 (for the goal part, G1.1), while for the selection of the method variant we need to match C1.1 with context criteria (see Table 3), resulting in the selection of the AHP variant (Chu-Dec-04a). Analogously, requirement cg 1.2 will lead to the identification of method chunks Chu-Col-2 (because privacy is not very sensible), Chu-Col-03a, and Chu-Col-03c. On its turn, for Project 2 the genetic algorithm-based prioritization technique Chu-Dec-04c will be selected, due to the increasing number of requirements). Concerning data collection, the analysis of context condition C 1.2 leads to exclude the use of both Chu-Col-02 and one specialization of Chu-Col-03, Chu-Col-03b, because neither feedback gathering nor usage monitoring are considered appropriate when privacy is a highly relevant issue (which is explicitly stated in the corresponding chunks). In both projects, Chu-Ena-02 (Release Planning) is selected due to the Release Planned goal.

Table 3. Context criteria for the three specializations of requirements prioritization.
Full size table

Method Chunks Assembly.

On the one hand, the selected method chunks are now assembled taking into account execution order (see Fig. 6) and input/output artefacts. This will create the assembly (Chu-Dec-04a, Chu-Ena-02) in Project1 and (Chu-Dec-04c, Chu-Ena-02) in Project2. However, collection chunks cannot be assembled because the analysis chunks have not been selected. The reason is that the goal model does not include information enough as to realize that these chunks are needed. Therefore, they need to be selected in this phase and assembled correspondingly, e.g. (Chu-Col-02, Chu-Ana-05) in Project1. Figure 8 presents the resulting SUPERSEDE Method for Project1, with the main method chunks, the input-output artefacts and the roles involved (for the sake of brevity, method chunks required at design time are not depicted, namely, Chu-Ana-02, Chu-Ana-03 and Chu-Ana-04).

Fig. 8.
figure 8

Excerpt of the SUPERSEDE Method for Project

Full size image

8 Conclusions and Future Work

In this paper, we have provided a systematic definition of the SUPERSEDE method for data-driven software evolution oriented towards its customization in particular contexts. We have defined a metamodel for method chunks built upon activities, artefacts, roles and tools (RQ1), then we have defined a set of context criteria to describe the context in which every chunk can be selected (RQ2), we have presented a catalogue of method chunks for SUPERSEDE-based software evolution compliant to such metamodel (RQ3) and we have presented an SME-based process to guide the definition of a tailoring of the SUPERSEDE method in a particular context (RQ4).

It is worth mentioning that the answer to RQ4 is a methodological contribution beyond the application to the SUPERSEDE method. It represents an evolution to recent SME works that we have undertaken [21, 22] given the inclusion of context criteria as part of the method requirements. The full development of the, e.g. the applicability of previously proposed context goal modelling approaches that support contextual annotations [23], is future work. Other aspects could be thought to be integrated in this extension of SME, as for instance adding existing guidelines for building methods based on metamodels from the literature about Domain Specific Modeling [24].

A point of discussion is the possible complexity of the method. As in any SME-based approach, we assume that a method engineer would lead the customization of the method with the help of key stakeholders, e.g. a requirements engineer for the construction of the goal model. We plan also to develop tool support as to assist the method engineer, e.g. by suggesting the missing chunks in the third step of the assembly

Future work spreads along several directions. First, we plan to conduct an exhaustive validation of the SUPERSEDE evolution method, which is partly required also due to the novelty of the topic and limitations that are inherent to data-driven decision support. Second, we aim at formalizing the method described in Sect. 6. Last, we aim at extending the catalogue of chunks for software evolution with adaptation and configuration artefacts obtaining then a holistic view of data-driven software engineering.