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.
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.
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.
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.
Open Source Software Ecosystems: A Systematic Mapping
Oscar Franco-Bedoya, David Ameller, Dolors Costal, Xavier Franch
Context: Open source software (OSS) and software ecosystems (SECOs) are two consolidated research areas in software engineering. OSS influences the way organizations develop, acquire, use and commercialize software. SECOs have emerged as a paradigm to understand dynamics and heterogeneity in collaborative software development. For this reason, SECOs appear as a valid instrument to analyze OSS systems. However, there are few studies that blend both topics together.
Objective: The purpose of this study is to evaluate the current state of the art in OSS ecosystems (OSSECOs) research, specifically: (a) what the most relevant definitions related to OSSECOs are; (b) what the particularities of this type of SECO are; and (c) how the knowledge about OSSECO is represented.
Method: We conducted a systematic mapping following recommended practices. We applied automatic and manual searches on different sources and used a rigorous method to elicit the keywords from the research questions and selection criteria to retrieve the final papers. As a result, 82 papers were selected and evaluated. Threats to validity were identified and mitigated whenever possible.
Results: The analysis allowed us to answer the research questions. Most notably, we did the following: (a) identified 64 terms related to the OSSECO and arranged them into a taxonomy; (b) built a genealogical tree to understand the genesis of the OSSECO term from related definitions; (c) analyzed the available definitions of SECO in the context of OSS; and (d) classified the existing modelling and analysis techniques of OSSECOs.
Conclusion: As a summary of the systematic mapping, we conclude that existing research on several topics related to OSSECOs is still scarce (e.g., modelling and analysis techniques, quality models, standard definitions, etc.). This situation calls for further investigation efforts on how organizations and OSS communities actually understand OSSECOs.