Context: The Google Play Store allows app developers to respond to user reviews. Existing research shows that response strategies vary considerably. In addition, while responding to reviews can lead to several types of favorable outcomes, not every response leads to success, which we define as increased user ratings.

Background. The software architecture recovery method RELAX produces a concern-based architectural view of a software system graphically and textually from that system's source code. The method has been implemented in software which can recover the architecture of systems whose source code is written in Java. Aims. Our aim was to find out whether the availability of architectural views produced by RELAX can help maintainers who are new to a project in becoming productive with development tasks sooner, and how they felt about working in such an environment. Method. We conducted a user study with nine participants. They were subjected to a controlled experiment in which maintenance success and speed with and without access to RELAX recovery results were compared to each other. Results. We have observed that employing architecture views produced by RELAX helped participants reduce time to get started on maintenance tasks by a factor of 5.38 or more. While most participants were unable to finish their tasks within the allotted time when they did not have recovery results available, all of them finished them successfully when they did. Additionally, participants reported that these views were easy to understand, helped them to learn the system's structure and enabled them to compare different versions of the system. Conclusions. Through the speedup to the start of maintenance experienced by the participants as well as in their formed opinions, RELAX has shown itself to be a valuable help that could provide the basis of further tools that specifically support the development process with a focus on maintenance.

Until recently, communications regarding apps on the iOS App Store have been one-way from users to developers, with developers unable to respond to reviews directly. While studies have shown that responding to reviews improves an app's overall rating and user satisfaction, resource limitations make it so developers can usually only respond to some of the reviews. Although developers' response behavior has been studied, little is known about which features (aspects) of user reviews spur their responses. Motivated by these observations, we investigate a wide range of features that can be extracted from a user review and apply a random forest algorithm and the features it extracts to predict whether developers will respond to that review. We then determine the importance of these features in distinguishing reviews that receive a developer response from those that do not. Through a case study of three popular free-to-download iOS apps, we find that although features such as rating and review length are among the most important features for all apps, each app has its own individual feature importance ranking, indicating that developers assign different feature weights when prioritizing reviews. Our results may help guide research or the development of tools that are more in line with developers' actual response behavior.

Background: Which aspects of an iOS App Store user review motivate developers to respond? Numerous studies have been conducted to extract useful information from reviews, but limited effort has been expended to answer this question.

The stakeholders of a system are legitimately interested in whether and how its architecture reflects their respective concerns at each point of its development and maintenance processes. Having such knowledge available at all times would enable them to continually adjust their systems structure at each juncture and reduce the buildup of technical debt that can be hard to reduce once it has persisted over many iterations. Unfortunately, software systems often lack reliable and current documentation about their architecture. In order to remedy this situation, researchers have conceived a number of architectural recovery methods, some of them concern-oriented. However, the design choices forming the bases of most existing recovery methods make it so none of them have a complete set of desirable qualities for the purpose stated above. Tailoring a recovery to a system is either not possible or only through iterative experiments with numeric parameters. Furthermore, limitations in the scalability of the employed recovery algorithms make it prohibitive to apply the existing techniques to large systems. Finally, since several current recovery methods employ nondeterministic sampling, their inconsistent results do not lend themselves well to tracking a systems course over several versions, as needed by its stakeholders. RELAX (RELiable Architecture EXtraction), a new concern based recovery method that uses text classification, addresses these issues efficiently (1) by assembling the overall recovery result from smaller, independent parts, (2) basing it on an algorithm with linear time complexity and (3) being tailorable to the recovery of a single system or a sequence thereof through the selection of meaningfully named, semantic topics. An intuitive and informative architectural visualization rounds out RELAX's contributions. RELAX is illustrated on a number of existing open-source systems and compared to other recovery methods. Index Terms-software architecture, architectural change, software evolution, open source software, architecture recovery, software development management, software maintenance.

Architecture is the set of principal design decisions about a software system. In practice, new architectural decisions are added and existing ones reversed or modified throughout a system's lifetime. Frequently, these decisions deviate from the architect's well-considered intent, and software systems regularly exhibit increased architectural decay as they evolve. The manifestations of such ill-considered design decisions are seen as “architectural smells”. To date, there has been no in-depth study of the characteristics or trends involving this phenomenon. Instead, when referring to architectural smells and their negative effects, both researchers and practitioners had to rely on folklore and their personal, inherently limited experience. In this paper, we report on the systematic step we have taken in investigating the nature and impact of architectural smells. We have selected a set of representative architectural smells from literature and analyzed their instances in 421 versions from 8 open-source software systems. We have (1) developed algorithms to automatically detect instances of multiple architectural smell types, and (2) analyzed relationships between the detected smells and the lists of issues reported in the systems' respective issue trackers. Our study shows that architectural smells have tangible negative consequences in the form of implementation issues as well as code commits requiring increased maintenance effort throughout a system's lifetime.

From its very inception, the study of software architecture has recognized architectural decay as a regularly occurring phenomenon in long-lived systems. Architectural decay is caused by repeated changes to a system during its lifespan. Despite decay's prevalence, there is a relative dearth of empirical data regarding the nature of architectural changes that may lead to decay, and of developers' understanding of those changes. In this paper, we take a step toward addressing that scarcity by conducting an empirical study of changes found in software architectures spanning several hundred versions of 14 open-source systems. Our study reveals several new findings regarding the frequency of architectural changes in software systems, the common points of departure in a system's architecture during maintenance and evolution, the difference between system-level and component-level architectural change, and the suitability of a system's implementation-level structure as a proxy for its architecture.

The phenomenon called Incremental Development Productivity Decline (IDPD) is presumed to be present in all incremental soft-ware projects to some extent. COCOMO II is a popular parametric cost estimation model that has not yet been adapted to account for the challenges that IDPD poses to cost estimation. Instead, its cost driver and scale factors stay constant throughout the increments of a project. While a simple response could be to make these parameters variable per increment, questions are raised as to whether the existing parameters are enough to predict the behavior of an incrementally developed project even in that case. Individual COCOMO II parameters are evaluated with regard to their development over the course of increments and how they influence IDPD. The reverse is also done. In light of data collected in recent experimental projects, additional new variable parameters that either extend COCOMO II or could stand on their own are proposed.

This research paper expands on a previously introduced phenomenon called Incremental Development Productivity Decline (IDPD) that is presumed to be present in all incremental software projects to some extent. Incremental models are now being used by many organizations in order to reduce development risks. Incremental development has become the most common method of software development. Therefore its characteristics inevitably influence the productivity of projects. Based on their observed IDPD, incrementally developed projects are split into several major IDPD categories. Different ways of measuring productivity are presented and evaluated in order to come to a definition or set of definitions that is suitable to these categories of projects. Data has been collected and analyzed, indicating the degree of IDPD associated with each category. Several hypotheses have undergone preliminary evaluations regarding the existence, stability and category-dependence of IDPD with encouraging results. Further data collection and hypothesis testing is underway.

Which are the consequences of Lehman's Laws of Software Evolution for the productivity of incrementally developed projects? The concept of Incremental Development Productivity Decline (IDPD), which deals with how the productivity of incrementally developed software develops over its increments, is introduced. It is explained how Lehman's Laws of Software Evolution apply to it and how maintenance and reuse are relevant to both. Every Law of Software Evolution is discussed individually from a qualitative standpoint with regard to whether it could be a cause of IDPD. After that discussion, the overall situation is examined in light of how different courses of action cause which laws to apply different degrees of effects.