Risky files: an approach to focus quality improvement effort

Mockus, Audris; Hackbarth, Randy; Palframan, John

doi:10.1145/2491411.2494572

Cited by 7 publications

(5 citation statements)

References 13 publications

(20 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In SCCS, CVS, or SVN, branching and merging are rather tedious activities and tend to be used less often than with the latest generation of VCSs, e.g., Git. Git makes branching and merging both easy and necessary and it is common to see more than 100 branches for a single file [36,39].…”

Section: Methodsmentioning

confidence: 99%

Engineering big data solutions

Mockus

2014

Future of Software Engineering Proceedings

Self Cite

View full text Add to dashboard Cite

Structured and unstructured data in operational support tools have long been prevalent in software engineering. Similar data is now becoming widely available in other domains. Software systems that utilize such operational data (OD) to help with software design and maintenance activities are increasingly being built despite the difficulties of drawing valid conclusions from disparate and low-quality data and the continuing evolution of operational support tools. This paper proposes systematizing approaches to the engineering of OD-based systems. To prioritize and structure research areas we consider historic developments, such as big data hype; synthesize defining features of OD, such as confounded measures and unobserved context; and discuss emerging new applications, such as diverse and large OD collections and extremely short development intervals. To sustain the credibility of OD-based systems more research will be needed to investigate effective existing approaches and to synthesize novel, OD-specific engineering principles.

show abstract

Section: Methodsmentioning

confidence: 99%

Engineering big data solutions

Mockus

2014

Future of Software Engineering Proceedings

Self Cite

View full text Add to dashboard Cite

show abstract

“…The primary data sources in this phase were Version control systems (Git and SVN) and Issue tracking system (JIRA). We started from data integrated over all Avaya projects as described in previous studies [15,16]. The data unifies information from most of version control and issue tracking systems in Avaya, but we still need to select the projects related to the client's communication.…”

Section: Methodsmentioning

confidence: 99%

“…Related files are files that had identical content in the past (based on their version history) [16].…”

Section: Terminologymentioning

confidence: 99%

Forking and coordination in multi-platform development

Duc

Mockus

Hackbarth

et al. 2014

Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement

Self Cite

View full text Add to dashboard Cite

Context]With the proliferation of desktop and mobile platforms the development and maintenance of identical or similar applications on multiple platforms is urgently needed.[Goal] We study a software product deployed to more than 25 software/hardware combinations over 10 years to understand multi-platform development practices.[Method] We use semi structured interviews, project wikis, VCSs and issue tracking systems to understand and quantify these practices.[Results]We find the projects using MR cloning, MR review meeting, cross platform coordinator's role as three primary means of coordination. We find that forking code temporarily relieves the coordination needs and is driven by divergent schedule, market needs, and organizational policy. Based on our qualitative findings we propose quantitative measures of coordination, redundant work, and parallel development.[Conclusions] A model of coordination intensity suggests that it is related to the amount of paralel and redundant work. We hope that this work will provide a basis for quantitative understanding of issues faced in multi-platform software development.

show abstract

“…There have been a number of works on predicting and improving the software quality as well (e.g. [45,75,31,48]). Comparatively, studies about post-deployment quality and dynamics have been less frequent [38,33].…”

Section: Related Workmentioning

confidence: 99%

Deriving a usage-independent software quality metric

Dey¹,

Mockus²

2020

Empir Software Eng

Self Cite

View full text Add to dashboard Cite

Context: The extent of post-release use of software affects the number of faults, thus biasing quality metrics and adversely affecting associated decisions. The proprietary nature of usage data limited deeper exploration of this subject in the past. Objective: To determine how software faults and software use are related and how, based on that, an accurate quality measure can be designed. Method: Via Google Analytics we measure new users, usage intensity, usage frequency, exceptions, and release date and duration for complex proprietary mobile applications for Android and iOS. We utilize Bayesian Network and Random Forest models to explain the interrelationships and to derive the usage independent release quality measure. To increase external validity, we also investigate the interrelationship among various code complexity measures, usage (downloads), and number of issues for 520 NPM packages. We derived a usage-independent quality measure from these analyses, and applied it on 4430 popular NPM packages to construct timelines for comparing the perceived quality (number of issues) and our derived measure of quality during the lifetime of these packages. Results: We found the number of new users to be the primary factor determining the number of exceptions, and found no direct link between the intensity and frequency of software usage and software faults. Crashes increased with the power of 1.02-1.04 of new user for the Android app and power of 1.6 for the iOS app. Release quality expressed as crashes per user was independent of other usage-related predictors, thus serving as a usage independent measure of software quality. Usage also affected quality in NPM, where downloads were strongly associated with numbers of issues, even after taking the other code complexity measures into consideration. Unlike in mobile case where exceptions per user decrease over time, for 45.8% of the NPM packages the number of issues per download increase. Conclusions: We expect our result and our proposed quality measure will help gauge release quality of a software more accurately and inspire further research in this area.

show abstract

Risky files: an approach to focus quality improvement effort

Cited by 7 publications

References 13 publications

Engineering big data solutions

Engineering big data solutions

Forking and coordination in multi-platform development

Deriving a usage-independent software quality metric

Contact Info

Product

Resources

About