Paper accepted in IEEE Transactions on Software Engineering (TSE)

Dealing with Non-Functional Requirements in Model-Driven Development: A Survey

David Ameller, Xavier Franch, Cristina Gómez, Silverio Martínez-Fernández, João Araújo, Stefan Biffl, Jordi Cabot, Vittorio Cortellessa, Daniel Méndez Fernández, Ana Moreira, Henry Muccini, Antonio Vallecillo, Manuel Wimmer, Vasco Amaral, Wolfgang Böhm, Hugo Bruneliere, Loli Burgueño, Miguel Goulão, Sabine Teufl, Luca Berardinelli

Abstract—Context: Managing Non-Functional Requirements (NFRs) in software projects is challenging, and projects that adopt Model-Driven Development (MDD) are no exception. Although several methods and techniques have been proposed to face this challenge, there is still little evidence on how NFRs are handled in MDD by practitioners. Knowing more about the state of the practice may help researchers to steer their research and practitioners to improve their daily work. Objective: In this paper, we present our findings from an interview-based survey conducted with practitioners working in 18 different companies from 6 European countries. From a practitioner’s point of view, the paper shows what barriers and benefits the management of NFRs as part of the MDD process can bring to companies, how NFRs are supported by MDD approaches, and which strategies are followed when (some) types of NFRs are not supported by MDD approaches. Results: Our study shows that practitioners perceive MDD adoption as a complex process with little to no tool support for NFRs, reporting productivity and maintainability as the types of NFRs expected to be supported when MDD is adopted. But in general, companies adapt MDD to deal with NFRs. When NFRs are not supported, the generated code is sometimes changed manually, thus compromising the maintainability of the software developed. However, the interviewed practitioners claim that the benefits of using MDD outweight the extra effort required by these manual adaptations. Conclusion: Overall, the results indicate that it is important for practitioners to handle NFRs in MDD, but further research is necessary in order to lower the barrier for supporting a broad spectrum of NFRs with MDD. Still, much conceptual and tool implementation work seems to be necessary to lower the barrier of integrating the broad spectrum of NFRs in practice.

Paper accepted in Science of Computer Programming Journal

Non-Functional Requirements in Model-Driven Development of Service-Oriented Architectures
David Ameller, Xavier Burgués, Dolors Costal, Carles Farré, and Xavier Franch

Any software development process needs to consider non-functional requirements (NFR) in order to deliver a system that complies with its stakeholders’ expectations. In a previous mapping study about model-driven development (MDD) for service-oriented architectures (SOA) we found a limited number of approaches managing NFR. The present work aims at analysing in detail the state of the art in the management of NFR in MDD processes which produce SOA. We have conducted a systematic literature review following a rigorous protocol. We have taken as initial point the mapping study mentioned above and have used the subset of the 31 papers from this study (clustered into 15 approaches) that referred to NFR. We have analysed them qualitatively in order to answer six research questions. We have built a Software Engineering theory to formalize this analysis. As result we highlight that most of approaches focus exclusively on security and reliability and we observe that NFR are expressed mainly as annotations of functional models represented in UML. From our perspective, existing research on the topic of this study is still scarce and without any evidence of transferability to industry. This situation suggests the need for further investigation efforts in order to produce validated MDD methods capable of generating SOA satisfying NFR stated by stakeholders.

Paper accepted in Fundamenta Informaticae Journal

Quality-Aware Architectural Model Transformations in Adaptive Mashups User Interfaces
Javier Criado, Silverio Martínez-Fernández, David Ameller, Luis Iribarne, Nicolás Padilla, Andreas Jedlitschka

Mashup user interfaces provides their functionality through the combination of different services. The integration of such services can be solved by using reusable and third-party components. Furthermore, these interfaces must be adapted to user preferences, context changes, user interactions and component availability. Model transformation is a useful mechanism to address this adaptation but normally these operations only focus on the functional requirements. In this sense, quality attributes should be included in the adaptation process to obtain the best adapted mashup user interface. This paper proposes a generic quality-aware transformation process to support the adaptation of software architectures. The transformation process has been applied in ENIA, a geographic information system, by constructing a specific quality model for the adaptation of mashup user interfaces. This model is taken into account for evaluating the different transformation alternatives and choosing the one that maximizes the quality assessments. The approach has been validated by a set of adaptation scenarios that are intended to maximize different quality factors and therefore apply distinct combinations of metrics.

Paper accepted in CAiSE’18

A Situational Approach for the Definition and Tailoring of a Data-Driven Software Evolution Method
Xavier Franch, Jolita Ralyté, Anna Perini, Alberto Abelló, David Ameller, Jesús Gorroñogoitia, Sergi Nadal, Marc Oriol, Norbert Seyff, Alberto Siena, Angelo Susi

Successful software evolution heavily depends on the selection of the right features to be included in the next release. Such selection is difficult, and companies often report bad experiences about user acceptance. To overcome this challenge, there is an increasing number of approaches that propose intensive use of data to drive evolution. This trend has motivated the SUPERSEDE method, which proposes the collection and analysis of user feedback and monitoring data as the baseline to elicit and prioritize requirements, which are then used to plan the next release. However, every company may be interested in tailoring this method depending on factors like project size, scope, etc. In order to provide a systematic approach, we propose the use of Situational Method Engineering to describe SUPERSEDE and guide its tailoring to a particular context.

“Llavor” project granted

Reactive Plan: A Tool for Continuous Software Release Planning
Responsible Scientist: Carles Farré
Entrepreneur Scientist: David Ameller

Software engineering has always aimed to identify separate engineering activities and assign different responsibilities to each of them as a way to produce a clear path to produce or maintain software products. An extreme example is the (deprecated) waterfall development process that required the current activity to be completely finished in order to start the following one. However, this process has been proved inadequate in most cases due to the instability of the software requirements. To tackle this problem, several iterative software development processes emerged in the last fifteen years (e.g., Agile, XP, etc.), which still keep the activities apart but is organized into smaller iterations that facilitate the incorporation of changes in the initial activities.

Continuous software engineering is going one step beyond by establishing strong connections between software engineering activities. The objective of this continuity is to accelerate and increase the efficiency of the software engineering process; for example, continuous integration is one of the best established continuous approaches in which the development and deployment activities are keep linked and synchronized. In this sense, continuous engineering can be also related to DevOps, a movement that encourages the collaboration between development, operations and testing. Given its complexity, continuous software engineering requires advanced tool support that help to maintain the link between the connected activities. For instance, Jenkins is a very popular tool that supports continuous integration. The need for such tool is the main motivation of the Reactive Plan tool.

Our solution, Reactive Plan, focuses on the reinforcement of the connection between software development and release planning activities. Software development is the task of producing the implementation of the software (e.g., writing the source code) while release planning is deciding what is to be implemented, when and by whom. In order to fully support the continuous planning of releases, the Reactive Plan tool will: 1) monitor the real progress of the ongoing release (by connecting with developer tools like JIRA or Slack); and 2) re-plan the current release when necessary (e.g., some activity is delayed or a developer takes a sick leave).

We are in TRL 1, basic principles observed, because we currently have the preliminary idea of the product and the release planning algorithm, but it is worth noting that this algorithm is not yet ready to be used with the continuous engineering ideas. In fact, the grant will be dedicated to the design and implementation of a prototype of the Reactive Plan tool. In particular, the developer will have to adapt our algorithm and integrate it with at least one of the commonly used developer tools (i.e., JIRA, Slack, etc.). Therefore, with this grant we expect to move from TRL 1 to TRL 3, experimental proof of concept. The money of the grant will be mainly allocated to hiring technical staff for the TRL transition and to subcontracting a market analysis to help in the marketization of the solution.