Wcre2012 delays slides (1)

•

0 likes•198 views

SAIL_QU

An Empirical Study on Factors
Impacting Bug Fixing Time
Feng Zhang, Foutse Khomh, Ying Zou
and Ahmed E. Hassan

2
New Assign Bug Fixing Verified Resolved
A Typical Process of Bug Fixing

3
Bug Fixing Time
New ResolvedIntroduced

4
Example: delay before change
Reported & Assigned
Oct-2006
Fixing started & Resolved:
Mar-2011
almost
5 years

5
Example: delay after change
Reported & Assigned
Fixing started & ended:
September-2008
Resolved:
February-2011
over
2 years

6
DBC DBF DAC
Intervals during Bug Fixing
DBR
New ResolvedFirst
Response
Bug Fixing
Start
Bug Fixing
End
Assign
DBA
Delay Before ResponseDBR
Delay Before AssignedDBA
Delay Before ChangeDBC
Duration of Bug FixingDBF
Delay After ChangeDAC

7
Benefits of Studying Delays
Locate time-consuming
steps
Understand factors affecting
the delays
Improve the process of
bug fixing

8
Subject Systems
3,883
logs
2,722
bugs
606
bugs
524
bugs
793
logs
638
logs
Mylyn
Eclipse
Platform
PDE

9
Data Sources
Properties of bug
Change history of bug
Properties of file edits
Static metrics
History metrics
Fine grained change types
Bug ID

10
Properties
of Source
Code
Properties
of Code
Change
Properties
of Bug
Report
Title
Summary
Severity of Bug
Operating System
Comments
Size (LOC, NOM)
Complexity (WMC)
Code Churn
Number of Changed Files
Fine Grained Change Types
Metrics from three Dimensions

11
RQ1: Do delays by developers exist during
bug fixing process?
RQ2: Can we characterize delays incurred by
developers before and after fixing bugs?
RQ3: What factors contribute to the delays
most?
Research Questions

12
RQ1: Bug fixing time extracted
from two data sources

13
RQ1: Intervals during
bug fixing process
Delay
Before
Response
Delay
Before
Assign
Delay
Before
Change
Delay
After
Change
Duration
Of
Bug Fixing

14
Enhancement v.s. Defect
364
Delay
Before
Change
56
186
4
Low Severity v.s. High Severity
198
n.s
110
n.s
RQ2: Properties of Bug Report
Delay
After
Change
Delay
Before
Change
Delay
After
Change
Delay
Before
Change
Delay
After
Change
Delay
Before
Change
Delay
After
Change

15
RQ2: Properties of Bug Report
(cont’)
Length of comment
delay before change
delay after change

16
RQ2: Properties of Source Code
Size of Source Code
delay before change (sum)
delay after change (avg/sum/max)
Complexity of Source Code
delay before change (sum)
delay after change (sum/max)

17
Code Churn
delay before change (avg/sum/max)
delay after change (avg/sum/max)
Fine Grained Change Types
delay before change
delay after change
RQ2: Properties of Code Change

18
RQ3: What factors contribute to
the delays most?
Events:
Long DBC : greater than median
Long DAC : greater than median
Analysis Method: (Logistic Regression Model)
Predict the probability of an event’s occurrence.
Combines different factors.
Interpretation by Coefficient:
magnitude describes importance
sign describes direction

19
RQ3: Factors Impacting
Delays Before Change
-0.5
0.4
0.3
0.2
is bug with high severity
max length of comment
sum NOM
sum Code Churn
-0.5 0.5
Coefficient

20
-0.7
0.5
-0.5
max length of comment
is bug
sum WMC
max WMC
is OS Linux
length of description
avg Code Churn
-0.5
-0.3
0.3
0.7
RQ3: Factors Impacting
Delays After Change
-1.0 1.0 Coefficient

21
Top Two Intervals in Bug Fixing Process
delay before and after change
Delay Before Change
level of severity, code churn (most influential factors)
Delay After Change
comments, complexity (most influential factors)
Conclusions

Viewers also liked

An Empirical Study of Goto in C Code from GitHub Repositories

SAIL_QU

Recovering the Behaviour of AJAX Applications

SAIL_QU

Mining Unstructured Software Repositories Using IR Models

SAIL_QU

Early Identification of Future Committers in Open Source Software Projects

SAIL_QU

Studying the Software Development Overhead of Build Systems

SAIL_QU

What are the Characteristics of High-rated Apps

SAIL_QU

An Exploration of Challenges Limiting Pragmatic Software Defect Prediction

SAIL_QU

Automatic Load Test Verification Using Control Charts

SAIL_QU

Leveraging Historical Co-change Information for Requirements Traceability

SAIL_QU

The Impact of Switching to a Rapid Release Cycle on Integration Delay of Addr...

SAIL_QU

Revisiting the Applicability of the Pareto Principle to Core Development Team...

SAIL_QU

Recovering a Balanced Overview of Topics in a Software Domain

SAIL_QU

An Industrial Case Study of Automatically Identifying Performance Regression-...

SAIL_QU

Ghotra icse

SAIL_QU

Automated Detection of Performance Regressions Using Statistical Process Cont...

SAIL_QU

Studying the Evolution of Build Systems

SAIL_QU

Icsm2013 contexts (1)

SAIL_QU

Large-Scale Empirical Studies of Mobile Apps

SAIL_QU

Detecting Interaction Coupling from Task Interaction Histories

SAIL_QU

Empircal Studies of Performance Bugs & Performance Analysis Approaches for La...

SAIL_QU

Viewers also liked (20)

An Empirical Study of Goto in C Code from GitHub Repositories

Recovering the Behaviour of AJAX Applications

Mining Unstructured Software Repositories Using IR Models

Early Identification of Future Committers in Open Source Software Projects

Studying the Software Development Overhead of Build Systems

What are the Characteristics of High-rated Apps

An Exploration of Challenges Limiting Pragmatic Software Defect Prediction

Automatic Load Test Verification Using Control Charts

Leveraging Historical Co-change Information for Requirements Traceability

The Impact of Switching to a Rapid Release Cycle on Integration Delay of Addr...

Revisiting the Applicability of the Pareto Principle to Core Development Team...

Recovering a Balanced Overview of Topics in a Software Domain

An Industrial Case Study of Automatically Identifying Performance Regression-...

Ghotra icse

Automated Detection of Performance Regressions Using Statistical Process Cont...

Studying the Evolution of Build Systems

Icsm2013 contexts (1)

Large-Scale Empirical Studies of Mobile Apps

Detecting Interaction Coupling from Task Interaction Histories

Empircal Studies of Performance Bugs & Performance Analysis Approaches for La...

Similar to Wcre2012 delays slides (1)

MineDB Mineral Resource Evaluation White Paper

Derek Diamond

A tale of bug prediction in software development

Martin Pinzger

Software systems continuously change and developers spent a large portion of their time in keeping track and understanding changes and their effects. Current development tools provide only limited support. Most of all, they track changes in source files only on the level of textual lines lacking semantic and context information on changes. Developers frequently need to reconstruct this information manually which is a time consuming and error prone task. In this talk, I present three techniques to address this problem by extracting detailed syntactical information from changes in various source files. I start with introducing ChangeDistiller, a tool and approach to extract information on source code changes on the level of ASTs. Next, I present the WSDLDiff approach to extract information on changes in web services interface description files. Finally, I present FMDiff, an approach to extract changes from feature models defined with the linux Kconfig language. For each approach I report on cases studies and experiments to highlight the benefits of our techniques. I also point out several research opportunities opened by our techniques and tools, and the detailed data on changes extracted by them.

Analyzing Changes in Software Systems From ChangeDistiller to FMDiff

Martin Pinzger

Scaling to Millions of Simultaneous Connections by Rick Reed from WhatsApp

mustafa sarac

Whatsapp's Architecture

Udaya Kiran

This talk shares experiences from deploying and tuning Flink steam processing applications for very large scale. We share lessons learned from users, contributors, and our own experiments about running demanding streaming jobs at scale. The talk will explain what aspects currently render a job as particularly demanding, show how to configure and tune a large scale Flink job, and outline what the Flink community is working on to make the out-of-the-box for experience as smooth as possible. We will, for example, dive into - analyzing and tuning checkpointing - selecting and configuring state backends - understanding common bottlenecks - understanding and configuring network parameters

Stephan Ewen - Experiences running Flink at Very Large Scale

Ververica

Populating a Release History Database (ICSM 2013 MIP)

Martin Pinzger

This is the story of a great software war. Migrating Big Data legacy systems always involve great pain and sleepless nights. Migrating Big Data systems with Multiple pipelines and machine learning models only adds to the existing complexity. What about migrating legacy systems that protect Microsoft Azure Cloud Backbone from Network Cyber Attacks? That adds pressure and immense responsibility. In this session, we will share our migration story: Migrating a machine learning-based product with thousands of paying customers that process Petabytes of network events a day. We will talk about our migration strategy, how we broke down the system into migrationable parts, tested every piece of every pipeline, validated results, and overcome challenges. Lastly, we share why we picked Azure Databricks as our new modern environment for both Data Engineers and Data Scientists workloads.

The Pill for Your Migration Hell

Databricks

Verilog HDL Verification

dennis gookyi

Dissertation Defense

Sung Kim

Manitoba Hydro has developed a number of FME workbenches that allow it to automate a variety of QA\QC checks when receiving lidar data from external sources. These checks are necessary to ensure that lidar data meets specifications before it is accepted for use wihtin Manitoba Hydro. These workbenches allow for a standardized, efficient, and methodical approach to reviewing large amounts of data, and aid in quickly highlighting potential issues with the data.

$Using FME to Automate Lidar QA\QC Processes$ $Using FME to Automate Lidar QA\QC Processes$

Using FME to Automate Lidar QA\QC Processes

Safe Software

Space Rovers and Surgical Robots: System Architecture Lessons from Mars

Real-Time Innovations (RTI)

The Use of Development History in Software Refactoring Using a Multi-Objectiv...

Ali Ouni

10135 a 11

Bố Su

Kustom Impact Analyser

stephaneberger

KIA

JeromeCardon

2LA Kustom Impact Analyser

FredericLagrange

Using Developer Information as a Prediction Factor

Tim Menzies

Process mining with Disco (Eng)

Dafna Levy

EMC Documentum Compliance Manager Migration Revisited — What a Difference Two...

BlueFish

More from SAIL_QU

In-app advertisements have become a major revenue for app developers in the mobile app economy. Ad libraries play an integral part in this ecosystem as app developers integrate these libraries into their apps to display ads. However, little is known about how app developers integrate these libraries with their apps and how these libraries have evolved over time. In this thesis, we study the ad library integration practices and the evolution of such libraries. To understand the integration practices of ad libraries, we manually study apps and derive a set of rules to automatically identify four strategies for integrating multiple ad libraries. We observe that integrating multiple ad libraries commonly occurs in apps with a large number of downloads and ones in categories with a high percentage of apps that display ads. We also observe that app developers prefer to manage their own integrations instead of using off the shelf features of ad libraries for integrating multiple ad libraries. To study the evolution of ad libraries, we conduct a longitudinal study of the 8 most popular ad libraries. In particular, we look at their evolution in terms of size, the main drivers for releasing a new ad library version, and their architecture. We observe that ad libraries are continuously evolving with a median release interval of 34 days. Some ad libraries have grown exponentially in size (e.g., Facebook Audience Network ad library), while other libraries have worked to reduce their size. To study the main drivers for releasing an ad library version, we manually study the release notes of the eight studied ad libraries. We observe that ad library developers continuously update their ad libraries to support a wider range of Android versions (i.e., to ensure that more devices can use the libraries without errors). Finally, we derive a reference architecture for ad libraries and study how the studied ad libraries diverged from this architecture during our study period. Our findings can assist ad library developers to understand the challenges for developing ad libraries and the desired features of these libraries.

Studying the Integration Practices and the Evolution of Ad Libraries in the G...

SAIL_QU

Studying the Dialogue Between Users and Developers of Free Apps in the Google...

SAIL_QU

Improving the testing efficiency of selenium-based load tests

SAIL_QU

Studying User-Developer Interactions Through the Distribution and Reviewing M...

SAIL_QU

Studying online distribution platforms for games through the mining of data f...

SAIL_QU

Understanding the Factors for Fast Answers in Technical Q&A Websites: An Empi...

SAIL_QU

Investigating the Challenges in Selenium Usage and Improving the Testing Effi...

SAIL_QU

Mining Development Knowledge to Understand and Support Software Logging Pract...

SAIL_QU

Which Log Level Should Developers Choose For a New Logging Statement?

SAIL_QU

Towards Just-in-Time Suggestions for Log Changes

SAIL_QU

The Impact of Task Granularity on Co-evolution Analyses

SAIL_QU

A Framework for Evaluating the Results of the SZZ Approach for Identifying Bu...

SAIL_QU

How are Discussions Associated with Bug Reworking? An Empirical Study on Open...

SAIL_QU

A Study of the Relation of Mobile Device Attributes with the User-Perceived Q...

SAIL_QU

A Large-Scale Study of the Impact of Feature Selection Techniques on Defect C...

SAIL_QU

Studying the Dialogue Between Users and Developers of Free Apps in the Google...

SAIL_QU

What Do Programmers Know about Software Energy Consumption?

SAIL_QU

Threshold for Size and Complexity Metrics: A Case Study from the Perspective ...

SAIL_QU

Revisiting the Experimental Design Choices for Approaches for the Automated R...

SAIL_QU

Measuring Program Comprehension: A Large-Scale Field Study with Professionals

SAIL_QU

More from SAIL_QU (20)