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.

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 c omponent 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.

Software release planning is the activity of deciding what is to be implemented, when and by who. It can be divided into two tasks: strategic planning (i.e., the what) and operational (i.e., the when and the who). Replan, the tool that we present in this demo, handles both tasks in an integrated and flexible way, allowing its users (typically software product managers and developer team leaders) to (re)plan the releases dynamically by assigning new features and/or modifying the available resources allocated at each release. A recorded video demo of Replan is available at https://youtu.be/PNK5EUTdqEg.

Continuous software engineering is a new trend that is gaining increasing attention of the research community in the last years. The main idea behind this trend is to tighten the connection between the software engineering lifecycle activities (e.g., development, planning, integration, testing, etc.). While the connection between development and integration (i.e., continuous integration) has been subject of research and is applied in industrial settings, the connection between other activities is still in a very early stage. We are contributing to this research topic by proposing our ideas towards connecting the software development and software release planning activities (i.e., continuous software release planning). In this paper we present our initial findings on this topic, how we envision to address the continuous software release planning, and a research agenda to fulfil our objectives.

Model-Driven Development (MDD) is no longer a novel development paradigm. It has become mature from a research perspective and recent studies show its adoption in industry. Still, some issues remain a challenge. Among them, we are interested in the treatment of non-functional requirements (NFRs) in MDD processes. Very few MDD approaches have been reported to deal with NFRs (and they do it in a limited way). However, it is clear that NFRs need to be considered somehow in the final product of the MDD process. To better understand how NFRs are integrated into the existing MDD approaches, we have initiated the NFR4MDD project, a multi-national empirical study, based on interviews with companies working on MDD projects. Our project aims at surveying the state of the practice for this topic. In this paper, we summarize our research protocol and present the current status of our study. The discussion will focus on the peculiarities of our study's context and organization involving about 20 researchers from 8 European countries.

By 2016 an estimated 95% of all commercial software packages will include Open Source Software (OSS). This extended adoption is yet not avoiding failure rates in OSS projects to be as high as 50%. Inadequate risk management has been identified among the top mistakes to avoid when implementing OSS-based solutions. Understanding, managing and mitigating OSS adoption risks is therefore crucial to avoid potentially significant adverse impact on the business. In this position paper we portray a short report of work in progress on risk management in OSS adoption processes. We present a risk-aware technical decision-making management platform integrated in a business-oriented decision-making framework, which together support placing technical OSS adoption decisions into organizational, business strategy as well as the broader OSS community context. The platform will be validated against a collection of use cases coming from different types of organizations: big companies, SMEs, public administration, consolidated OSS communities and emergent small OSS products.

SUMMARY The process of designing a software architecture using different kinds of components is often challenging. Different designs support some quality attributes while damaging others; therefore, trade‐off analysis is needed to make informed decisions. Moreover, analysis made in theory needs to be complemented with observations in practice, especially when using a particular set of technologies to implement the system. In this paper, we present a particular instance of this problem. We study how the Three‐Layer architectural pattern may be developed using plug‐ins. We compare two extreme alternatives according to several representative scenarios and their impact in some quality attributes. Then, we apply this theoretical knowledge to a case study, the implementation of a plug‐in‐based tool for managing architectural knowledge using Eclipse. We report some unexpected difficulties found that forced us to adapt the theoretical solution into an operative architecture. Copyright © 2012 John Wiley & Sons, Ltd.

Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners' and researchers' daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects' practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.

Researchers from requirements engineering and software architecture had emphasized the importance of NonFunctional Requirements and their influence in the architectural design process. To improve this process we have designed a tool, ArchiTech, which aims to support architects during the design process by suggesting alternative architectural decisions that can improve some types of non-functional requirements in a particular project, and facilitate the reuse of architectural knowledge shared between projects of the same architectural domain (e.g., web-based applications).

The impact of non-functional requirements (NFRs) over software systems has been widely documented. Consequently, cost-effective software production method shall provide means to integrate this type of requirements into the development process. In this vision paper we analyze this assumption over a particular type of software production paradigm: model-driven development (MDD). We report first the current state of MDD approaches with respect to NFRs and remark that, in general, NFRs are not addressed in MDD methods and processes, and we discuss the effects of this situation. Next, we outline a general framework that integrates NFRs into the core of the MDD process and provide a detailed comparison among all the MDD approaches considered. Last, we identify some research issues related to this framework.