Abstract Context Nowadays software-development organizations are urged to exploit their data for empowering their decision-making processes. Such data may be used to monitor the status of meaningful software indicators (e.g., software quality, productivity and on-time delivery) that are relevant for their decision-making processes. Forecasting the values of such indicators may provide evidence of a potentially high risk or opportunity that could help to anticipate actions accordingly. Most of the existing forecasting proposals in software engineering use open-source data rather than data from industrial projects. Therefore, there is a lack of evidence on how these proposals fit the particular needs of a software-development organization and how they can be automated into the organization’s infrastructure. Objective To enable software indicators´ forecasting in a software-development organization (Modeliosoft). Method We designed an industry-academia collaboration based on Action Design Research (ADR) to address Modeliosoft’s forecasting challenges. Results A tool-supported method called FOSI (Forecasting Of Software Indicators) for enabling forecasting in Modeliosoft. We obtained positive results regarding its suitability and technical feasibility in a pilot project of the organization. In addition, we provide details and reflections on the potential usefulness of the method for addressing similar field problems. Conclusions The procedures and results detailed in this paper are valuable to: 1) address Modeliosoft’s forecasting challenges 2) inspire other software-development organizations on how to deal with similar problems and even reuse some procedures and software support tools resulted from this work, 3) promote the win-win benefits of industry-academia collaborations.

The significant momentum and importance of Mining Software Repositories (MSR) in Software Engineering (SE) has fostered new opportunities and challenges for extensive empirical research. However, MSR researchers seem to struggle to characterize the empirical methods they use into the existing empirical SE body of knowledge. This is especially the case of MSR experiments. To provide evidence on the special characteristics of MSR experiments and their differences with experiments traditionally acknowledged in SE so far, we elicited the hallmarks that differentiate an experiment from other types of empirical studies and characterized the hallmarks and types of experiments in MSR. We analyzed MSR literature obtained from a small-scale systematic mapping study to assess the use of the term experiment in MSR. We found that 19% of the papers claiming to be an experiment are indeed not an experiment at all but also observational studies, so they use the term in a misleading way. From the remaining 81% of the papers, only one of them refers to a genuine controlled experiment while the others stand for experiments with limited control. MSR researchers tend to overlook such limitations, compromising the interpretation of the results of their studies. We provide recommendations and insights to support the improvement of MSR experiments.

Context: Several empirical studies investigated the benefits and drawbacks of acquiring a Software Reference Architecture (SRA) to construct a family of software systems with similar architectural needs. However, these empirical results have not been synthesized by any study yet. Such synthesized evidence is essential to make informed decisions whether or not to adopt an SRA in an organization. Goal: To aggregate existing empirically- grounded evidence about the benefits and drawbacks of SRAs, aiming at supporting organizations' decision making on their adoption. Method: To identify primary studies in the technical literature through a systematic literature review, and then, use the Structured Synthesis Method (SSM) to aggregate qualitative and quantitative evidence through the use of diagrammatic models. Results: From the five identified primary studies, five SRA benefits have considerably increased their belief value after aggregation: interoperability of software systems, reduced development costs, improved communication among stakeholders, reduced risk, and reduced time- to-market. Also, one drawback of SRAs has increased its belief value: the required learning curve for developers. Conclusions: The aggregated results consolidate knowledge and confidence on some of the studied SRA effects. The commonly reported effects showed a clear increment of their belief and pointed out to broader generalization. The effects that did not show any belief increment are important to detect areas requiring further evidence to reach a higher degree of consolidation. Practitioners might benefit from these results to support the decision of adopting an SRA in practice.

Context: Software reference architectures (SRA) have emerged as an approach to systematically reuse architectural knowledge and software elements in the development of software systems. Over the last years, research has been conducted to uncover the artifacts that SRAs provide in order to build software systems. However, empirical studies have not focused on providing industrial evidence about such artifacts. Aim: This paper investigates which artifacts constitute an SRA, how SRAs are designed, the potential reuse of SRA's artifacts, and how they are used in practice. Method: The study consists of a case study made in collaboration with a multinational consulting company that designs SRAs for diverse client organizations. A total of nine European client organizations that use an SRA participated in the study. We analyzed available documentation and contacted 28 practitioners. Results: In the nine analyzed projects, we observed that the artifacts that constitute an SRA are mainly software elements, guidelines and documentation. The design and implementation of SRAs are influenced by the reuse of artifacts from previous software system development and experiences, and the reuse of an SRA across different business domains may be possible when they are platform-oriented. Regarding SRAs usage, we observed that conformance checking is seldom performed. Conclusions: This study reports artifacts of SRAs as stated by practitioners in order to help software architects and scientists in the inception, design, and application of SRAs.

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.

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.

Goal- and agent-oriented models have become a consolidated type of artifact in various software and knowledge engineering activities. Several languages exist for representing such type of models but there is a lack of associated methodologies for guiding their construction up to the necessary level of detail. In this paper we present RiSD, a method for building Strategic Dependency (SD) models in the i* notation. RiSD is defined in a prescriptive way to reduce uncertainness when constructing the model. RiSD tackles three fundamental issues: (1) it tends to reduce the average size of the resulting models; (2) it defines some traceability relationships among model elements; (3) it provides some lexical and syntactical conventions. As a result, we may say that RiSD supports the construction process of goal- and agent-oriented models whilst increasing their understanding.