An Empirical Study of Cohesion and Coupling: Balancing Optimisation and Disruption

Search based software engineering has been extensively applied to the problem of finding improved modular structures that maximise cohesion and minimise coupling. However, there has, hitherto, been no longitudinal study of developers’ implementations, over a series of sequential releases. Moreover, results validating whether developers respect the fitness functions are scarce, and the potentially disruptive effect of search-based remodularisation is usually overlooked. We present an empirical study of 233 sequential releases of 10 different systems; the largest empirical study reported in the literature so far, and the first longitudinal study. Our results provide evidence that developers do, indeed, respect the fitness functions used to optimise cohesion/coupling (they are statistically significantly better than arbitrary choices with p << 0.01), yet they also leave considerable room for further improvement (cohesion/coupling can be improved by 25% on average). However, we also report that optimising the structure is highly disruptive (on average more than 57% of the structure must change), while our results reveal that developers tend to avoid such disruption. Therefore, we introduce and evaluate a multi-objective evolutionary approach that minimises disruption while maximising cohesion/coupling improvement. This allows developers to balance reticence to disrupt existing modular structure, against their competing need to improve cohesion and coupling. The multi-objective approach is able to find modular structures that improve the cohesion of developers’ implementations by 22.52%, while causing an acceptably low level of disruption (within that already tolerated by developers)

A Longitudinal Study of Identifying and Paying Down Architectural Debt

Architectural debt is a form of technical debt that derives from the gap between the architectural design of the system as it "should be" compared to "as it is". We measured architecture debt in two ways: 1) in terms of system-wide coupling measures, and 2) in terms of the number and severity of architectural flaws. In recent work it was shown that the amount of architectural debt has a huge impact on software maintainability and evolution. Consequently, detecting and reducing the debt is expected to make software more amenable to change. This paper reports on a longitudinal study of a healthcare communications product created by Brightsquid Secure Communications Corp. This start-up company is facing the typical trade-off problem of desiring responsiveness to change requests, but wanting to avoid the ever-increasing effort that the accumulation of quick-and-dirty changes eventually incurs. In the first stage of the study, we analyzed the status of the "before" system, which indicated the impacts of change requests. This initial study motivated a more in-depth analysis of architectural debt. The results of this analysis were used to motivate a comprehensive refactoring of the software system. The third phase of the study was a follow-on architectural debt analysis which quantified the improvements made. Using this quantitative evidence, augmented by qualitative evidence gathered from in-depth interviews with Brightsquid's architects, we present lessons learned about the costs and benefits of paying down architecture debt in practice.Comment: Submitted to ICSE-SEIP 201

The Dynamics of Vehicular Networks in Urban Environments

Vehicular Ad hoc NETworks (VANETs) have emerged as a platform to support intelligent inter-vehicle communication and improve traffic safety and performance. The road-constrained, high mobility of vehicles, their unbounded power source, and the emergence of roadside wireless infrastructures make VANETs a challenging research topic. A key to the development of protocols for inter-vehicle communication and services lies in the knowledge of the topological characteristics of the VANET communication graph. This paper explores the dynamics of VANETs in urban environments and investigates the impact of these findings in the design of VANET routing protocols. Using both real and realistic mobility traces, we study the networking shape of VANETs under different transmission and market penetration ranges. Given that a number of RSUs have to be deployed for disseminating information to vehicles in an urban area, we also study their impact on vehicular connectivity. Through extensive simulations we investigate the performance of VANET routing protocols by exploiting the knowledge of VANET graphs analysis.Comment: Revised our testbed with even more realistic mobility traces. Used the location of real Wi-Fi hotspots to simulate RSUs in our study. Used a larger, real mobility trace set, from taxis in Shanghai. Examine the implications of our findings in the design of VANET routing protocols by implementing in ns-3 two routing protocols (GPCR & VADD). Updated the bibliography section with new research work

Reconfigurability Function Deployment in Software Development

In the forthcoming highly dynamic and complex business environment high-speed and cost-effective development of software applications for targeting a precise, unique and momentary set of requirements (no more-no less) associated to a customized business case will bring sig-nificant benefits both for producers and users. This requires a life cycle change-oriented ap-proach in software development. In this respect, designing software with intrinsic evolutionary resources for reconfiguration represents the sound approach. A methodology for concurrent deployment of reconfigurability characteristics in software applications is introduced in this paper. Its potential is exemplified in a case study dealing with web-based software tools to support systematic product innovation projects.Reconfigurability, Software Development, Innovation, TRIZ, RAD

Exploring the Impact of Socio-Technical Core-Periphery Structures in Open Source Software Development

In this paper we apply the social network concept of core-periphery structure to the sociotechnical structure of a software development team. We propose a socio-technical pattern that can be used to locate emerging coordination problems in Open Source projects. With the help of our tool and method called TESNA, we demonstrate a method to monitor the socio-technical core-periphery movement in Open Source projects. We then study the impact of different core-periphery movements on Open Source projects. We conclude that a steady core-periphery shift towards the core is beneficial to the project, whereas shifts away from the core are clearly not good. Furthermore, oscillatory shifts towards and away from the core can be considered as an indication of the instability of the project. Such an analysis can provide developers with a good insight into the health of an Open Source project. Researchers can gain from the pattern theory, and from the method we use to study the core-periphery movements

What to Fix? Distinguishing between design and non-design rules in automated tools

Technical debt---design shortcuts taken to optimize for delivery speed---is a critical part of long-term software costs. Consequently, automatically detecting technical debt is a high priority for software practitioners. Software quality tool vendors have responded to this need by positioning their tools to detect and manage technical debt. While these tools bundle a number of rules, it is hard for users to understand which rules identify design issues, as opposed to syntactic quality. This is important, since previous studies have revealed the most significant technical debt is related to design issues. Other research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classify 466 software quality rules from three industry tools---CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either not design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on Software Architecture 2017 (Gothenburg, SE