BoneJ2 - refactoring established research software

Research software is often developed with expedience as a core development objective because experimental results, but not the software, are specified and resourced as a project output. While such code can help find answers to specific research questions, it may lack longevity and flexibility to make it reusable. We reimplemented BoneJ, our software for skeletal biology image analysis, to address design limitations that put it at risk of becoming unusable. We improved the quality of BoneJ code by following contemporary best programming practices. These include separation of concerns, dependency management, thorough testing, continuous integration and deployment, source code management, code reviews, issue and task ticketing, and user and developer documentation. The resulting BoneJ2 represents a generational shift in development technology and integrates with the ImageJ2 plugin ecosystem.

A comprehensive study of bloated dependencies in the Maven ecosystem

Build automation tools and package managers have a profound influence on software development. They facilitate the reuse of third-party libraries, support a clear separation between the application’s code and its external dependencies, and automate several software development tasks. However, the wide adoption of these tools introduces new challenges related to dependency management. In this paper, we propose an original study of one such challenge: the emergence of bloated dependencies. Bloated dependencies are libraries that are packaged with the application’s compiled code but that are actually not necessary to build and run the application. They artificially grow the size of the built binary and increase maintenance effort. We propose DepClean, a tool to determine the presence of bloated dependencies in Maven artifacts. We analyze 9,639 Java artifacts hosted on Maven Central, which include a total of 723,444 dependency relationships. Our key result is as follows: 2.7% of the dependencies directly declared are bloated, 15.4% of the inherited dependencies are bloated, and 57% of the transitive dependencies of the studied artifacts are bloated. In other words, it is feasible to reduce the number of dependencies of Maven artifacts to 1/4 of its current count. Our qualitative assessment with 30 notable open-source projects indicates that developers pay attention to their dependencies when they are notified of the problem. They are willing to remove bloated dependencies: 21/26 answered pull requests were accepted and merged by developers, removing 140 dependencies in total: 75 direct and 65 transitive.

The nature of build changes

Build systems are an essential part of modern software projects. As software projects change continuously, it is crucial to understand how the build system changes because neglecting its maintenance can, at best, lead to expensive build breakage, or at worst, introduce user-reported defects due to incorrectly compiled, linked, packaged, or deployed official releases. Recent studies have investigated the (co-)evolution of build configurations and reasons for build breakage; however, the prior analysis focused on a coarse-grained outcome (i.e., either build changing or not). In this paper, we present BuildDiff, an approach to extract detailed build changes from Maven build files and classify them into 143 change types. In a manual evaluation of 400 build-changing commits, we show that BuildDiff can extract and classify build changes with average precision, recall, and f1-scores of 0.97, 0.98, and 0.97, respectively. We then present two studies using the build changes extracted from 144 open source Java projects to study the frequency and time of build changes. The results show that the top-10 most frequent change types account for 51% of the build changes. Among them, changes to version numbers and changes to dependencies of the projects occur most frequently. We also observe frequently co-occurring changes, such as changes to the source code management definitions, and corresponding changes to the dependency management system and the dependency declaration. Furthermore, our results show that build changes frequently occur around release days. In particular, critical changes, such as updates to plugin configuration parts and dependency insertions, are performed before a release day. The contributions of this paper lay in the foundation for future research, such as for analyzing the (co-)evolution of build files with other artifacts, improving effort estimation approaches by incorporating necessary modifications to the build system specification, or automatic repair approaches for configuration code. Furthermore, our detailed change information enables improvements of refactoring approaches for build configurations and improvements of prediction models to identify error-prone build files.

BoneJ2 - refactoring established research software

Research software is often developed with expedience as a core development objective because experimental results, but not the software, are specified and resourced as a project output. While such code can help find answers to specific research questions, it may lack longevity and flexibility to make it reusable. We reimplemented BoneJ, our software for skeletal biology image analysis, to address design limitations that put it at risk of becoming unusable. We improved the quality of BoneJ code by following contemporary best programming practices. These include separation of concerns, dependency management, thorough testing, continuous integration and deployment, source code management, code reviews, issue and task ticketing, and user and developer documentation. The resulting BoneJ2 represents a generational shift in development technology and integrates with the ImageJ2 plugin ecosystem.

Benefits and Challenges of Adopting SAFe - An Empirical Survey

During the last two decades, turbulent business environments tempted firms to adopt agile methods to cope with the ever-changing customer demands. The success of agile methods in small and co-located teams inspired companies to apply them to large-scale endeavors. Agile scaling frameworks, such as the Scaled Agile Framework (SAFe), have been proposed by practitioners to scale agile practices to large projects and enterprises. Companies are increasingly taking these frameworks into use. However, the number of quantitative empirical studies assessing the benefits and challenges of adopting the agile scaling frameworks is still limited. This paper starts filling in this gap by presenting the results from a survey of 100 industry participants around the world on their perception of the benefits and challenges of adopting the SAFe framework. Our results show that the SAFe adoption improves transparency, as well as collaboration and dependency management between agile teams. The most commonly mentioned challenges of the SAFe adoption are organizational politics, difficulties in establishing an agile mindset, change resistance, and team formation challenges.

Managing Dependencies in Large-Scale Agile

Delivering results iteratively and frequently in large-scale agile requires efficient management of dependencies. We conducted semi-structured interviews and virtual observations in a large-scale project during the Covid-19 pandemic to better understand large-scale dependency management. All employees in the case were working from home. During our data collection and analysis, we identified 22 coordination mechanisms. These mechanisms could be categorized as synchronization activities, boundary-spanning activities and artifacts, and coordinator roles. By using a dependency taxonomy, we analyzed how the mechanisms managed five different types of dependencies. We discuss three essential mechanisms for coordination in our case. First, setting Objectives and Key Results (OKRs) in regular workshops increased transparency and predictability across teams. Second, ad-hoc communication, mainly happening on Slack because of the distributed setting, was essential in managing dependencies. Third, the Product Owner was a coordinator role that managed both inter-team and intra-team dependencies.

Construction the structure of the automation system project

The article considers the features of the automated system of tenant service (ASOO) project building. It has been noted that the Vaadin is one of the platforms for creating web applications that provide convenient tools to support the interaction of software and hardware of the system and user interface. Among the main advantages of the framework, firstly, is the ability to create the user interface using only Java programming language, without JavaScript, HTML and CSS using. Vaadin programs run on the server and run automatically as well as securely. Building on a well-prepared Java ecosystem, the framework works with any development environment, tools and libraries. Secondly, it is a wide range of options for creating a user interface with minimal writing of program code: Form Inputs, Visualization & Interaction, Layouts, Pro Components. In addition, the framework API provides the ability to automatically and securely organize two-way communication between client and server, use Java Bean Validation, its own validators, and perform data conversions during data validation. The Apache Maven framework, which builds a project based on POM files, has been used as a means of automating work with software projects. A set of Spring Boot utilities has been used to automate the setup process, as well as speed up the process of creating and deploying the application. The use of Spring Boot is due to the following options: the ability to create a standalone application based on Spring; simplification of dependency management in the project through the use of starter-packages (for example, spring-boot-starter-data-jpa) and automatic configuration of the application based on the selected starter-package; built-in support for servlet container; no need to generate code and configure XML. MySQL relational database management system could be used as a database, as this open source technology has a wide range of functionality that can be used when developing dynamic web pages.

Towards Automatic Updates of Software Dependencies based on Artificial Intelligence

Software reusability encourages developers to heavily rely on a variety of third-party libraries and packages, resulting in dependent software products. Often ignored by developers due to the risk of breakage but dependent software have to adopt security and performance updates in their external dependencies. Existing work advocates a shift towards Automatic updation of dependent software code to implement update dependencies. Emerging automatic dependency management tools notify the availability of new updates, detect their impacts on dependent software and identify potential breakages or other vulnerabilities. However, support for automatic source code refactoring to fix potential breaking changes (to the best of my current knowledge) is missing from these tools. This paper presents a prototyping tool, DepRefactor, that assist in the programmed refactoring of software code caused by automatic updating of their dependencies. To measure the accuracy and effectiveness of DepRefactor, we test it on various students project developed in C#.