Figure - available from: Empirical Software Engineering
This content is subject to copyright. Terms and conditions apply.
Code Churn visualization: (Left) Microsoft’s Azure opts for a chronological plot where different color shades account for lines added, deleted or modified throughout; (Right) GitHub reflects code additions (above) and code deletions (below) along with a common axis in a weekly basis
Source publication
Software Product Lines (SPLs) aim at systematically reusing software assets, and deriving products (a.k.a., variants) out of those assets. However, it is not always possible to handle SPL evolution directly through these reusable assets. Time-to-market pressure, expedited bug fixes, or product specifics lead to the evolution to first happen at the...
Citations
... In the realm of Information Systems, another methodology pertinent to industry-academia collaboration has emerged: Action Design Research (ADR) (Sein et al. 2011;Cronholm and Göbel 2022). There is evidence on the successful use of ADR across various fields (Haj-Bolouri et al. 2018;Cronholm and Göbel 2019), and it is gaining attention in empirical software engineering, as underscored by Ralph et al. (Ralph 2014) and a recent publication by Díaz et al. (Díaz et al. 2022). The integration of ADR into empirical software engineering methodologies offers promising avenues for enhancing collaboration effectiveness and advancing research outcomes. ...
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.
... In this respect, research methodologies such as Action Design Research might help involve practitioners. [42] provides a case in point. ...
Context
Variant-Rich Systems (VRSs), such as Software Product Lines or variants created through clone & own, are created to satisfy different needs while reusing existing assets. The long lifespan of families of variants, and the scale of both the technical side (implementation size) and the organizational side (roles diversity) make their maintenance and evolution a challenge. Visualization tools are a needed companion.
Objective
We aim at mapping the current state of visualization interventions in the area of VRS evolution. We tackle evolution in both the functionality and the variability management architecture. Three research questions are posed: What sort of analysis is being conducted? (Analysis perspective); What sort of visualizations are displayed? (Visualization perspective); What types of research have been reported and how have they been evaluated? (Maturity perspective).
Methods
We performed a systematic mapping study including automated search in digital libraries, expert knowledge, and snowballing.
Results
The study reports on 41 visualization approaches to cope with VRS evolution. Analysis wise, feature identification and location is the most popular scenario, followed by variant integration towards a Software Product Line. As for visualization, nodelink diagram visualization is predominant while researchers have come up with a wealth of ingenious visualization approaches. Finally, maturity wise, almost half of the studies are solution proposals. Most of the studies provide proof-of-concepts, some of them also include public available tools, yet very few face proof-of-value.
Conclusions
This systematic mapping study introduces a comparison framework where to frame future studies. It also points out distinct research gaps worth investigating as well as shortcomings in the evidence about relevance and contextual considerations (e.g., scalability).
Software products have many configurations to meet different environments and diverse needs. Building software with multiple software configurations typically incurs high costs in terms of build time and computing resources. Incremental builds could reuse intermediate artifacts if configuration settings affect only a portion of the build artifacts. The efficiency gains depend on the strategic ordering of the incremental builds as the order influences which build artifacts can be reused. Deriving an efficient order is challenging and an open problem, since it is infeasible to reliably determine the degree of re-use and time savings before an actual build. In this paper, we propose an approach, called BUDDI—BUild Declaration DIstance, for C-based and Make-based projects to derive an efficient order for incremental builds from the static information provided by the build scripts (i.e., Makefile). The core strategy of BUDDI is to measure the distance between the build declarations of configurations and predict the build size of a configuration from the build targets and build commands in each configuration. Since some artifacts could be reused in the subsequent builds if there is a close distance between the build scripts for different configurations. We implemented BUDDI as an automated tool called BuddiPlanner and evaluated it on 20 popular open-source projects, by comparing it to a baseline that randomly selects a build order. The experimental results show that the order created by BuddiPlanner outperforms 96.5% (193/200) of the random build orders in terms of build time and reduces the build time by an average of 305.94s (26%) compared to the random build orders, with a median saving of 64.88s (28%). BuddiPlanner demonstrates its potential to relieve practitioners of excessive build times and computational resource burdens caused by building multiple software configurations.
