%%%%%%%%%%%%%%%%%%%%%%% file typeinst.tex %%%%%%%%%%%%%%%%%%%%%%%%%
%
% This is the LaTeX source for the instructions to authors using
% the LaTeX document class 'llncs.cls' for contributions to
% the Lecture Notes in Computer Sciences series.
% http://www.springer.com/lncs       Springer Heidelberg 2006/05/04
% 
% It may be used as a template for your own input - copy it
% to a new file with a new name and use it as the basis
% for your article.
%
% NB: the document class 'llncs' has its own and detailed documentation, see
% ftp://ftp.springer.de/data/pubftp/pub/tex/latex/llncs/latex2e/llncsdoc.pdf
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\documentclass[runningheads,a4paper]{llncs}
\usepackage{multicol}

\usepackage{amssymb}
\setcounter{tocdepth}{3}
\usepackage{graphicx}

\usepackage{url}
\urldef{\mailsa}\path|{akinori-i, masao, matumoto}@is.naist.jp|
\newcommand{\keywords}[1]{\par\addvspace\baselineskip
\noindent\keywordname\enspace\ignorespaces#1}

\newcommand{\secref}[1]{Section \ref{#1}}
\newcommand{\figref}[1]{Figure \ref{#1}}
\newcommand{\tabref}[1]{Table \ref{#1}}


\begin{document}

\mainmatter  % start of an individual contribution

% first the title is needed
\title{Differences of Time between Modification and Re-modification: An Analysis of a Bug Tracking System
}

% a short form should be given in case it is too long for the running head
\titlerunning{Lecture Notes in Computer Science: Authors' Instructions}

% the name(s) of the author(s) follow(s) next
%
% NB: Chinese authors should write their first names(s) in front of
% their surnames. This ensures that the names appear correctly in
% the running heads and the author index.
%
\author{Akinori Ihara\and Masao Ohira\and Ken--ichi Matsumoto}
%
\authorrunning{Lecture Notes in Computer Science: Authors' Instructions}
% (feature abused for this document to repeat the title also on left hand pages)

% the affiliations are given next; don't give your e-mail address
% unless you accept that it will be published
\institute{Graduate School of Information Science, Nara Institute of Science and Technology\\
8916-5, Takayama, Ikoma, Nara, JAPAN 630-0192\\
\mailsa\\
%\mailsb\\
%\mailsc\\
%\url{http://www.springer.com/lncs}
}

%
% NB: a more complex sample for affiliations and the mapping to the
% corresponding authors can be found in the file "llncs.dem"
% (search for the string "\mainmatter" where a contribution starts).
% "llncs.dem" accompanies the document class "llncs.cls".
%

\toctitle{Lecture Notes in Computer Science}
\tocauthor{Authors' Instructions}
\maketitle


\begin{abstract}
Managers of open source projects need to understand time to resolve bugs, which are reported into a bug tracking system on a daily basis, to make a release plan. 
Hewett et al. proposed an empirical approach to predicting time required to repair bugs. 
However, the predictive model did not distinguish between time to modify a firstly-reported bug and time to re-modify a bug. 
In this paper, toward predicting time to resolve bugs with accuracy, we identify such the differences of time between bug modifications and re-modifications.
We have conducted a case study using Firefox project data. 
As a result of this case study, we have confirmed that time to resolve a firstly reported bug was shorter than time to re-modify a bug.
% in spite of the number of assigned developers.

\keywords{open source software development, bug tracking system, time to resolve bugs, bug modification process, Firefox}
\end{abstract}

%---------------------------------------------------------------------------------------------------------------
\section{INTRODUCTION}
\label{sec:introduction}
%近年，数多くのユーザが利用するOSSも増加し，定期的なリリースを行うOSSが増加している．
%そのため，運営者はリリース計画を立てるために，不具合の修正に要する時間を正確に把握する必要がある．
%Hewettらは過去の不具合修正履歴を用いて，不具合修正プロセスを状態遷移図のように表わし，不具合の遷移に要する時間から滞留時間の予測の提案を行っている．
%しかし，
%提案されている修正時間の予測モデルは
%報告直後の初期修正に要する時間（初期修正時間）と再修正に要する時間（再修正時間）
%を区別していない
%再修正は
%初期修正に比べて修正すべき問題が明確であることから，
%再修正時間は初期修正時間よりも短くなると考える．
%本研究では
%不具合修正に要する時間を正確に予測するために，
%不具合が報告されてから初めて修正されるまでの時間（初期修正時間）と
%再修正の間に要する時間（再修正時間）の違いを明らかにする．
%初期修正時間は不具合報告後不具合と認められる時刻から修正が解決する時刻	までとする．
%再修正時間は再修正が決定される時刻から修正が解決されるまでとする．
%不具合修正は担当者が何度も変更されると，不具合を修正するために要する時間が長くなる\cite{}．
%そのため，それぞれの修正時間は担当者が変更された回数別に計測し，変更回数別に修正に要する時間を比較する．

As open source software with a large number of users increases, it is required to release a new feature or a bug fix on regular basis.
Therefore, managers of OSS projects need to understand time to resolve bugs which are reported into a bug tracking system on a daily basis, in order to make a release plan.
Hewett et al.\cite{Hewett2009} proposed an empirical approach to predicting time for repairing bugs. 
The study presented a bug modification process using a bug tracking system as a state transition diagram and predicted time spent for transition to each state. 
However, the predictive model did not distinguish between time to modify a firstly-reported bug and time to re-modify a bug. 
Time required for re-modifying a bug would be shorter than time required for modifying a firstly reported bug,
%%% ↑突然すぎる↑バグの再修正％％％
since a problem in source codes must be more clear, compared to the modification of a firstly reported bug which may contain unknown problems.
It will also take a longer time to resolve bugs, if developers in charge of bug modifications frequently change.
In this paper, toward predicting time to resolve bugs with accuracy, we identify such the differences of time between bug modifications and re-modifications.
We have conducted a case study using Firefox project data.


%---------------------------------------------------------------------------------------------------------------
\section{RELATED WORK}
\label{sec:related work}
%不具合修正プロセスの向上を目的とした研究は多く存在する\cite{Jeong2009}\cite{Ihara2009}\cite{}．
%我々は不具合修正プロセス中の状態遷移に要する時間に着目した研究を行ってきた．
%OSS開発における運営者らが不具合修正中で長い時間を要している作業を把握するために，我々は分析手法を提案した\cite{Ihara2009}．
%不具合修正プロセスを状態遷移図のように表し，各状態の遷移に要する時間を導出することで不具合修正プロセスのどの作業に長い時間を要しているかを明らかにすることが可能である．
%ApacheプロジェクトとMozilla Firefoxプロジェクトで発見された不具合を対象として，
%分析を行った結果，不具合報告後，修正に対応開始から修正されるまで，
%修正後の確認作業に長い時間を要していることが明らかとなった．
%この結果のみでは再修正と修正時間の長さの違いを把握することはできない．本研究ではこの長さの違いについて分析を行う．

There are many studies on bug modification processes with bug tracking systems in open source projects\cite{Herraiz2008}\cite{Jeong2009}\cite{Ihara2009}\cite{Mockus2002}.
Focusing on time to resolve bugs in the bug modification process, 
we have proposed an analysis method to understand a factor which results in prolonging the bug modification process\cite{Ihara2009}.
This analysis method represents a bug modification process as a state transition diagram and calculates the amount of time required to transit between states.
We have conducted two case studies of the reported bugs in Apache and Mozilla projects.
As a result of our analysis, we have found that the both projects needed long time to resolve bugs in the modification phase and verification phase.
However, we could not achieve a clear understanding on the differences of time between bug modifications and re-modifications.


%=========================================================
%\begin{figure}[t]
% \centering
% \includegraphics[width=\linewidth]{Fig/BugFixProcess_all.eps}
% \caption{A bug modification process in Mozilla Firefox}
% \label{fig:BugFixProcess_all}
%\end{figure}
%=========================================================
%\subsection{Prediction of time to resolve bugs}


%テスト計画の見積もりを行うためには不具合修正に要する時間を予測必要がある．
%Hewettらは不具合の重要度や優先度，バグの混入場所，検出時期，などから不具合修正に要する時間を教師あり学習アルゴリズムを用いた不具合の滞留時間予測モデルの構築手法の提案を行っている．
%彼らも我々と同様に初期修正と再修正を区別していない．
%本研究では正確な修正時間の予測を行うために，初期修正と再修正に要する時間の違いを分析する．




%=========================================================
\begin{figure}[t]
 \centering
 \includegraphics[width=1.0\linewidth]{Fig/BugFixProcess.eps}
 \caption{A bug modification process\cite{Jeong2009}}
 \label{fig:BugFixProcess}
\end{figure}
%=========================================================
%---------------------------------------------------------------------------------------------------------------
\section{BUG MODIFICATION PROCESS}
\label{sec:bug modification process}
%This section describes a bug modification process using a bug tracking system in a common open source project and then define several terms used in the paper.

\subsection{Bug Modification Process with a Bug \\Tracking System}
Most open source projects use bug tracking systems to unify management of bugs found and reported by developers and users in their projects. 
A bug tracking system helps open source project's managers to know the progress of bug modifications, 
to avoid leaving unmodified bugs and so forth. 
Popular bug tracking systems include Bugzilla, Mantis, RedMine, Trac and so on. 

\figref{fig:BugFixProcess} represents a bug modification process using a bug tracking system. 
Although a bug modification process using a bug tracking system slightly differs among individual bug tracking systems, 
it substantially can be represented as a state transition diagram in \figref{fig:BugFixProcess}.

%\tabref{table:BugState} shows possible states of a bug in the modification process. By calculating the amount of time required to transit between states and the amount of bugs passing through any two states, we can perform a fine-grained analysis to find out the bottleneck in the modification process.
%=========================================================
%\begin{table*}[th!]
% \caption{States of a bug in a modification process with a bug tracking system}
% \begin{center}
%  \begin{tabular}{|l|l|}
%  \hline
%   state & description \\
%  \hline
%   UNCONFIRMED & Developers and/or users send a report on a found bug into a bug tracking system.\\
%   NEW & Developers check a bug report and then accept a bug.\\
%   ASSIGNED & A bug is assigned to developers.\\
%   RESOLVED & Developers resolve a bug.\\
%   REOPENED & If a bug fix was not enough, re-modifications are requested to developers.\\
%   VERIFIED & Developers verify whether a bug fix is correct or not.\\
%   \hline
%  \end{tabular}
% \end{center}
% \label{table:BugState}
%\end{table*}
%=========================================================

\subsection{Modification Work}
%不具合修正の担当者が決定してから修正解決するまでの修正作業は\figref{fig:BugFixProcess}に記述されていない．本節では初期修正と再修正の修正作業違いを以下に説明する．
%初期修正における修正作業の流れは以下のとおりである．
%First，不具合が発生した原因（報告されたバグ票）を理解する．
%Second,バグの発生箇所を理解する．
%報告の内容には，不具合が混入しているシステムが記載される．
%しかし，多くのソフトウェアでは複数のシステムが連携しているため，開発者一人では修正できないことも多くある．
%そして，モジュールの依存関係などから不具合を含むソースコードを編集することで他のソースコードへの影響範囲も考える必要がある．Third,不具合の修正が行われる．

%不具合報告直後はこのような修正過程で行われると思われる．
%しかしながら，再修正の場合，不具合が発生した原因の理解や不具合の発生箇所の理解に要する時間は短縮されると考える．
%一度修正を行い再修正を行う場合，以前の修正によって不具合が発生していることが多く\cite{Sliwerski2005}，
%以前の修正内容を分析することで，発生原因や発生箇所を特定することが容易であると考える．
%以上の理由から本研究では，不具合の修正時間は過去の修正履歴の有無に影響を受けると考える．

This section describes differences of the modification work flow between modification of a firstly reported bug  and re-modification of a bug.
\figref{fig:BugFixProcess} shows the bug modification work flow. 
The modification work flow for a firstly reported bug is as follows.
First, developers understand contents of bug reports.
Second, developers understand a source code containing bugs.
System names containing bugs are written in many bug reports.
One developer often faces with the difficulty in modifying bugs by oneself, because most software systems work with other systems.
Furthermore, developers need to consider the influence of their modifications on other source codes, due to such as the dependency of software modules.
%developers having several knowledge need to collaborate.
% Last, they modificate bugs.
% The first bug modification was conducted these modification process.
% However, 
In contrast, re-modifying bugs would be finished by a shorter time, because analyzing the prior modification helps developers identify the reason and/or location of bugs.
% Because, if developers analyze previous modification, they can understand factors and source codes containing bugs of most bugs in most cases.
For the reasons mentioned above, we consider that time to resolve is affected by the presence or absence of the history of modifications. 







%---------------------------------------------------------------------------------------------------------------
\section{ANALYSIS METHOD}
\label{sec:analysis method}
%不具合修正時間を正確に予測するためにはバグ報告直後の修正時間と再修正に要する時間を区別して予測する必要があると考える．このセクションは報告直後の修正に要する時間と再修正に要する時間の違いを確認するための分析手法を説明する．

%始めに，初期修正時間と再修正時間の計算方法を説明する．
%初期修正時間は不具合報告直後の修正が開始から修正が解決されるまでの時間とする．

%%%↑↑↑最初の定義とちがうがな．．．


%しかし，修正プロセスの中には\figref{fig:BugFixProcess}担当者やNewの状態に遷移せずに
%解決する不具合も存在する．
%そのため，
%本研究では報告後，``RESOLVED''に遷移する以前に，
%``NEW''に遷移した後，``RESOLVED''に遷移した不具合のみを対象とする．

%次に，再修正時間は再修正の決定直後から修正が解決されるまでとする．
%つまり，\figref{fig:BugFixProcess}において``REOPENED''から``RESOLEVED''に遷移する時間とする．
%不具合の中には数回の再修正を行う不具合も存在する．
%そのような場合，それぞれの再修正に要した時間を測定する．
%例えば，一つの不具合に対し再修正が2回行われれば，2つの再修正時間を取得する．

%修正時間中に修正担当者の変更によって滞留時間が異なることが明らかにされている\cite{Jeong2009}．
%そのため，修正に要する時間は修正担当者の変更回数によって異なると考える．
%本研究では初期修正時間と再修正時間はそれぞれ修正担当者の修正回数ごとに導出する．

% In order to predict time to resolve bugs precisely, we think developers need to distinguish between time to resolve the first bug modification and time to resolve the bug re-modification.
This section describes a method for identifying the differences of time between bug modifications and re-modifications.
%\subsection{Analysis}
At first, we describe a method to calculate time to modify a firstly reported bug and time to re-modify a bug.
Time to modify a firstly reported bug is defined by the mean time from acceptance of the bug ({\bf new}) to resolution of the bug ({\bf resolved}).
% Time to re-modify a bug is defined by time from decision of re-modification of the bug to resolution of the bug.
% However, as presented in \figref{fig:BugFixProcess}, there are direct transiting bugs from ``unconfirmed'' to ``resolved''.
% In this case, we can't get the beginning time of action for resolving the bug. 
% Therefore, in this study, target date is only bugs transitting to state ``resolved'' after state ``new''. 
% In addition, time to resolve the first bug modification is the mean time to resolve bugs from state ``new'' to state ``resolved''.
% Next, time to resolve the bug re-modification is from the deciding the bug re-modification to finish of the first bug resolution.
In contrast, time to re-modify a bug is defined by time from the decision of re-modification of the bug ({\bf reopen}) to resolution of the bug ({\bf resolved}).
% In \figref{fig:BugFixProcess}, time to resolve the bug re-modification is the mean time to resolve bugs from  state ``reopened'' to state ``resolved''.
Some reported bugs are often needed to be re-modified several times.
In this case, we calculate time for each re-modification of bugs.
For example, if a bug are re-modified twice, we count time for the two re-modifications
Therefore, time required to re-modify a bug depends on the number of changes of developers in charge \cite{Jeong2009}.
% In addition, the more number of assigned developers are, the longer the mean time to resolve bugs are\cite{Jeong2009}. 
In this paper, time to modify a firstly reported bug and time to re-modify a bug are respectively calculated by the number of modifications of each developer in charge.
% the first bug modification and time to resolve the bug re-modification calculates the time every the number of assigned developers.


%\subsection{Procedure}
%\subsubsection{Process definition and data acquisition}
%A bug modification process must be defined before using the analysis method, because it slightly varies depending on the type of bug tracking systems and management policies in open source projects. For instance, in the Mozilla Firefox project, there are other paths from ``bug accepted'' to ``bug resolved'' (e.g., a direct path from ``bug accepted'' to ``bug resolved'', a path from ``bug assigned'' to ``bug accepted'', and so on). 

%After defining a bug modification process in a targeted open source project, history data of a bug tracking system is collected. The history data includes when bug states are changed by whom.

%\subsubsection{Creating state transition diagrams}
%Using collected history data of a bug tracking system, a state transition diagram is created. The diagram has two roles to understand a bug modification process: a common state transition diagram with state transition probabilities and a diagram focusing on time to transit from one state to another state. The detail of the diagram will be introduced in the case study.


%\subsubsection{再修正される不具合において，アサイン回数による滞留時間の違い}
%\subsubsection{Analysis based on modification phases}
%As described in \secref{sec:Three phases}, the analysis method divides a bug modification process into the three phases: untreated phase, modification phase, and verification phase. Calculating and analyzing the amount of time spent in each phase helps managers/leaders in open source projects to identify the longest phase in the bug modification process and then to take measures to improve the current bug modification process in own projects.

%\subsubsection{Analysis based on state transition diagrams}
%As presented in \figref{fig:BugFixProcess} and \tabref{table:BugState}, a bug is modified through several states in the bug modification process. Since previous studies did not reveal elapsed days spent to transit between any two states and the number of bugs passed through any paths, the bottleneck in a bug modification process using a bug tracking system could not be identified. 

%Our state transition diagrams allow managers/leaders to perform fine-grained analysis of the modification process and to monitor the progress of bug modifications in their own projects. In the future work, we would like to provide a means for monitoring the bug modification progress in real-time.


%---------------------------------------------------------------------------------------------------------------
\section{CASE STUDY}
\label{sec:case study}
%This section describes a case study which has been conducted to confirm the usefulness of the analysis method mentioned in \secref{sec:analysis method}. In the case study, the analysis method was applied to bug modification processes in two open source projects: Apache HTTP Sever project and Mozilla Firefox project.


\subsection{Target Projects and Data}
In the Mozilla Firefox project, Bugzilla is used to manage reported bugs.
The Mozilla Firefox project has been developing a web browser product with a rapidly increasing share. The product is very popular due to the extensibility of functions (i.e., add-ons). The project has been using Bugzilla since 2001. In the case study, history data of Bugzilla in Firefox version 1.0, 2.0, and 3.0 had been examined.
In this paper, we analyzed 10,917 bug reports. Their bug reports is closed bugs from 2003 to 2008. 
%そのバグ報告の中で，再修正として対象とする不具合数は434件，初期修正として対象とする不具合数は969件である．
In the bug reports, the number of re-modified bugs were 434 and the number of firstly reported bugs were 969.


\subsection{Result}
%\tabref{FirstResolveTime},\tabref{ReResolveTime}にそれぞれ修正担当者変更回数別の初期修正時間と再修正時間を示す．
%修正担当者の変更回数0回は報告者が修正する場合，修正担当者が変更されない場合である．

%%%変更回数0って表にある？？？？？？？？？

%\tabref{FirstResolveTime}，\tabref{ReResolveTime}より，担当者変更回数が0回から2回までは
%初期修正時間が再修正時間よりも短いことが分かった．また，修正担当者の変更を1回以上行った不具合数は初期修正が969件中426件(約44\%)，再修正が434件中107件(約25\%)であった．

%次に，修正担当者の変更回数別に初期修正時間と再修正時間の2つの母集団に差が生じているかを確認ために有意差検定を行う．初期修正時間と再修正時間共に母集団の要素数が異なり，共に正規分布でないことから，マン・ホイットニーのU検定を行った．マン・ホイットニーのU検定はノンパラメトリックな統計学的検定として知られている．独立な2組の標本の有意差検定として用いられる．

%検定の結果，担当者変更回数が0回と1回の時，有意水準5\%で
%初期修正時間と再修正時間に有意差があると言える．
%しかし，修正担当者変更回数が2回以上は有意水準5\%で
%初期修正時間と再修正時間に有意差がないことが分かった．

\tabref{ReResolveTime} respectively shows time to modify a firstly-reported bug and time to re-modify a bug, by the number of changes of assigned developers.
If an assigned developers never changed,  the number of changes of assigned developers is shown as zero.
% It is the case that developer modificating bugs doesn't change other developser.
Time to modify firstly modified bugs with zero, once and twice assigned developers is longer than time to re-modify bugs with zero, once and twice assigned developers.
In addition, the number of firstly modified bugs excepting zero assigned developers is 426 of 969 (44\%). The number of re-modified bugs excepting zero assigned developers is 107 of 434 (25\%).

Next, we confirmed the significant difference of the number of modifications between the two kinds of the modification works, using Mann-Whitney U test\footnote{The data with this study has element counts of the population and each data set is not normally-distributed. Mann-Whitney U test is used when two samples are self-dependence. }. 
% every the number of assigned developers, we give official approval significant difference in two works. 
% Test method uses Mann-Whitney U test. 
In this case study, the significance level of a test is 5\%.
\tabref{table:BasicStatistics} shows the test result.
In case of zero and once assigned developer, there is significantly different between the two kinds of the modification works.
However, In case of over two times assigned developers, there is no significance different between two works.

%=========================================================
%\begin{table}
%\caption{Statics of Apache and Firefox}
%\begin{center}
%\begin{tabular}{|l|r|}
%\hline
%\multicolumn{1}{|c|}{} & \multicolumn{1}{|c|}{Firefox}\\
%\hline
%period (from)	&	2003/01/01\\
%period (to) 	&	2008/12/31\\
%\hline
%closed bugs [analysis target]	& 10917\\
%機能追加 request			    & 10742\\
%\hline
%total number of reported bugs			& 69023\\
%\hline
%\end{tabular}
%\end{center}
%\label{table:BasicStatistics}
%\end{table}
% =========================================================


%=========================================================
\begin{table}
    \caption{Time to firstly-modify and re-modify bugs}
    \begin{center}
      \hspace*{-2em}   
      \begin{tabular}{l|r|r|r|r|r|r|r|r|r|r|r|r}
\hline
    &&\multicolumn{5}{|c|}{firstly-modified bugs}&&\multicolumn{5}{|c}{re-modified bugs}\\
\hline
   number of &&\multicolumn{1}{l|}{zero} & \multicolumn{1}{l|}{once} &  \multicolumn{1}{l|}{twice} & \multicolumn{1}{l|}{third} & \multicolumn{1}{l|}{more than} && \multicolumn{1}{l|}{zero} & \multicolumn{1}{l|}{once} &  \multicolumn{1}{l|}{twice} & \multicolumn{1}{l|}{third} & \multicolumn{1}{l}{more than}\\
    \multicolumn{1}{l|}{assigned developers} & & \multicolumn{1}{l|}{assigned} &  &  & \multicolumn{1}{l|}{times} & \multicolumn{1}{l|}{four times} && \multicolumn{1}{l|}{assigned} &  &  & \multicolumn{1}{l|}{times} & \multicolumn{1}{l}{four times} \\
  \hline
   median(days) && 11.0 &  24.3 &  82.7 & 129.3 & 429.2&& 0.6  & 8.2 & 75.7 & 163.2 & 227.4\\    
   average(days) && 78.2 & 113.2 & 197.3 & 363.5 & 331.2  && 28.6 & 94.8 & 298.8 & 201.8 & 286.6\\
   variance(days) && 167.4 & 227.5 & 348.0 & 439.3 & 212.1&& 98.8 & 170.9 & 627.9 & 160.6 & 210.1 \\
  \hline
   number of bugs   &&  543 &   353 &    47 &    19 & 7  && 386  &  74 &   20 &     8 & 5\\
  \hline
     \end{tabular}
     \end{center}
    \label{ReResolveTime}
\end{table}
%=========================================================

%=========================================================
\begin{table}
\caption{Mann-Whitney U test}
\begin{center}
\begin{tabular}{l|l|l|l|l|l|l}
\hline
   number of &&\multicolumn{1}{l|}{zero} & \multicolumn{1}{l|}{once} &  \multicolumn{1}{l|}{twice} & \multicolumn{1}{l|}{third} & \multicolumn{1}{l}{more than} \\
    \multicolumn{1}{l|}{assigned developers} & & \multicolumn{1}{l|}{assigned} &  &  & \multicolumn{1}{l|}{times} & \multicolumn{1}{l}{four times}  \\
\hline
p-value && 2.2$\mathrm{e}$-16 & 0.02 & 0.72 & 0.40 & 0.83\\ 
\hline
\end{tabular}
\end{center}
\label{table:BasicStatistics}
\end{table}
%=========================================================

%---------------------------------------------------------------------------------------------------------------
\section{DISCUSSIONS}
\label{sec:discussions}

%\section{DISCUSSIONS}
%\label{sec:discussions}
%ケーススタディの結果に基づき，このセクションは不具合修正時間予測モデル構築に向けて修正プロセスによる滞留時間の違いの分析の必要性を議論する．
Based on the results of our case study, this section discusses the necessity of analysis on the differences of the mean time to resolve bugs due to kinds of bug modification process toward building a predictive model of bug resolution time.


%分析の結果，不具合修正担当者の変更回数に関わらず，再修正時間は初期修正時間よりも短い．
%また，各修正担当者変更回数の不具合数と中央値の結果より，
%初期修正における修正担当者の変更する割合は再修正よりも多い．
%また，
%再修正の修正担当者変更回数は初期修正よりも少ない．
%そのため不具合の内容の理解や不具合の発生箇所の理解を行う時間が少なく，再修正時間は初期修正時間よりも短くなったと考えられる．
As a result of this study, we observed that time to modify firstly reported bugs was shorter than time to re-modify a bug in spite of the number of assigned developers.
We also found that the number of assigned developers in modifying firstly reported bugs was larger than that in re-modifying bugs.
In addition, the number of assigned developers in re-modifications is less than that in modifications of firstly reported bugs.
Therefore, we think that time to understand bug reports and source codes with bugs is less required in re-modifying bugs.

%本研究では初期修正時間と再修正時間は各担当者変更回数が0回と1回のときにのみ有意水準5\%で有意差があると確認できた．しかし，3回以上の修正時間では有意差がないという結果となった．
%本研究で用いたマン・ホイットニーのU検定は母集団の分散が大きく異なると誤った有意性を求めてしまうことがある．\tabref{FirstResolveTime}，\tabref{ReResolveTime}の平均値と標準偏差から担当者の変更回数が多くなるにつれ初期修正時間と再修正時間の標準偏差の差が大きくなっており，不具合数も少ないため有意差がないという結果になった可能性がある．
%いずれにしても，多くの不具合は初期修正時間よりも再修正時間の方が短いという結果が得られているため，不具合の修正時間の予測は初期修正と再修正を区別して行う必要があると考える．

%本研究では修正時間は修正を行った担当者のスキルや不具合の優先度，重要度の違いについては分析していない．
%我々は修正の担当者のスキルが高ければ修正に要する時間は短縮されると考える．
%また，重要度や優先度が高い不具合が発生すれば，低い不具合よりも優先して修正を行うと考えられる．
%今後は不具合の特徴や修正者のスキルによる，初期修正時間と再修正時間の違いを分析していく必要があると考えている．

In this paper, we did not analyze time to resolve bugs, considering  every developer's skills and priority and/or severity of bugs. If a developer has high skill, time to resolve bugs would be shorten in nature.
Also, if high severity bugs are reported, developers would modify such the bugs by priority.
In the future, we would analyze time to resolve bugs, considering such the skills and priority and/or severity of bugs. 

%修正担当者が変更されると不具合の内容の理解，不具合の発生箇所の理解を再度行う必要があるため，不具合短縮のためには以前に修正に関わった開発者との情報共有を円滑に行うことで短縮できるのではないかと考える．


%Based on the results of our case study, this section discusses the usefulness of the analysis method.

%\subsection{Analysis Based on Modification Phases}
%Since the past studies on the mean time to resolve bugs \cite{Herraiz2008, Mockus2002, Wang2007} only analyzed the total amount of time from ``bug reported'' to ``bug verified'', they could not identify which phase has the modification delay. By dividing the bug modification process into the three semantic phases, our analysis method allowed us to figure out that elapsed days in the modification and verification phase had an effect on the prolongation of the mean time to resolve bugs in the Apache and Mozilla projects. 

%We could also find that there were bugs elapsed over three months in the untreated phase (i.e., 24.4\% of Apache's bugs and 5.4\% of Firefox's bugs in the untreated phase). From these results, we consider that the analysis method would help managers/leaders of open source projects to gain understandings of the bottleneck of the bug modification process and of a precise picture of the process in their own projects.

%\subsection{Analysis Based on State Transition \\Diagrams}
%In order to reduce the mean time to resolve bugs, managers/leaders of open source projects firstly need to identify and understand the bottleneck of a bug modification process in their own projects. As a result of applying the analysis method to the bug modification processes in the Apache and Firefox projects, we have confirmed that the analysis method could identify the bottlenecks of the modification processes in the two projects: from ``bug resolved'' to ``bug verified'' and from ``bug accepted'' to ``bug resolved''. 

%Although elapsed days from ``bug resolved'' to ``bug verified'' were the longest transitions between any two states, we could not confirm the reason (e.g., bugs were closely-inspected in the period? or quality assurance members were late to get round to the verification?). We need to further analyze those reasons to provide a support for reducing the mean time to resolve bugs.

%We could also find that there were the three major patterns of elapsed days from ``bug reported'' to ``bug resolved'' as follows.

%\begin{itemize}
%\item[(a)] from ``bug reported'' to ``bug resolved''
%\item[(b)] from ``bug accepted'' to ``bug resolved''
%\item[(c)] from ``bug assigned'' to ``bug resolved''
%\end{itemize}

%We expected that the pattern (a) should be the fastest path because developers could modify bugs before reporting bugs. However, the pattern (b) and (c) were faster than the pattern (a) in both of the Apache and Firefox projects. This indicates that bug assignments are critically important for reducing the mean time to resolve bugs. In this way, we could obtain the appropriate path for efficient modifications by using the analysis method.

%We also found that there were different bottlenecks between Apache and Firefox. While the third longest state transition in Apache project was from ``bug assigned'' to ``bug resolved'', the third longest state transition in the Firefox project was from ``bug accepted to ``bug assigned''. In this fashion, the analysis method helped us to find bottlenecks of bug modification processes according to characteristics of individual projects. 

%From these results described above, we can conclude that the analysis method is useful for managers/leaders of open source projects to gain understandings of the bottleneck of the bug modification process and of a precise picture of the process in their own projects, toward improving the bug modification process and shortening the mean time to resolve bugs.

%\subsection{Threats to Validity}
%In this paper, we defined the start of the modification phase as the time of ``bug accepted'' or ``discussion started''. But the actual start time of modifications by developers can be earlier than the time when developers report bugs. In the future, we need to precisely define the start time of the modifications by using CVS commit logs.

%The current analysis method does not take account of looped paths and self loops in the state transitions. In \figref{fig:Apache_TransitionProbability} and \figref{fig:Firefox_TransitionProbability}, represented transition probabilities might be derived based on calculations of looped paths and self loops. We have to consider how many times a bug transits to the same state.

%---------------------------------------------------------------------------------------------------------------
\section{CONCLUSION AND FUTURE WORK}
\label{sec:future work}

%本稿で，我々は不具合修正に要する時間を正確に予測するために，修正時間と再修正に要する時間との違いについて分析を行った．Mozilla Firefoxのデータを用いて，我々は修正時間と再修正に要する時間の違いを確認するためにケーススタディを行った．

%Firefoxのプロジェクトデータを用いてケーススタディの結果から修正時間よりも再修正に要する時間の方が長いことが分かった．

%今後は，修正に要する時間だけでなく，修正後の確認作業も再修正後の確認とは異なっていると考える．その後，不具合修正に要する時間を性格に予測するために，修正プロセス履歴による修正時間の違いについてさらに分析を行い不具合修正予測モデルの作成を行いたいと考えている，
In this paper, toward predicting time to resolve bugs with accuracy, we identify such the differences of time between bug modifications and re-modifications.
We have conducted a case study using Firefox project data. 
As a result of this case study, we have confirmed that time to resolve a firstly reported bug was shorter than time to re-modify a bug.

We think that the verification work also different between time for a first bug modification and time for re-modification of a bug.
Finally, we would like to build a predictive model of bug resolution time,  analyzing differences of time to resolve bugs modification considering bug modification processes.


%In this paper, we proposed an analysis method which represents a bug modification process using a bug tracking system as a state transition diagram and then calculates the amount of time required to transit between states. 
%Using Firefox and Apache project data, we also conducted a case study to evaluate the usefulness of our analysis method.

%From a case study using Firefox and Apache project data, we have confirmed the usefulness of the method as follows. 
%\begin{itemize}
%\item The method helped to identify the phase to be reduced by dividing the bug modification process into the three phases.
%\item The method could find out the bottleneck of a bug modification process by representing it as a state transit diagram consisting of fine grained sub processes.
%\item The method could extract the difference of modification processes between Firefox and Apache.
%\item As empirical findings, the method could identify that verifying resolved bugs were the most time-consuming task in both of the Apache and Firefox projects . 
%\end{itemize}

%The results of our case study suggested that the analysis method could provide managers/leaders of OSS projects with useful information as demonstrated in \secref{sec:case study}, toward improving the bug modification process and shortening the mean time to resolve bugs.

%In this paper, however, we did not show the relationships between the states of bugs and  the attributes of bugs (e.g., severity, priority, and so on). In the future, the analysis method should be improved to provide useful insights on such the relationships.

\section{ACKNOWLEDGEMENT}
This research is being conducted as a part of the Next Generation IT Program and Grant-in-aid for Young Scientists (B), 20700028, 2009 
by the Ministry of Education, Culture, Sports, Science and Technology, Japan.


\begin{thebibliography}{10}

%\bibitem{Bassin1998}
%K.~A. Bassin, T.~Kratschmer, and P.~Santhanam.
%\newblock Evaluating software development objectively.
%\newblock {\em IEEE Software}, 15(6):66--74, 1998.

%\bibitem{Bettenburg2008}
%N.~Bettenburg, S.~Just, A.~Schr\"{o}ter, C.~Weiss, R.~Premraj, and
%  T.~Zimmermann.
%\newblock What makes a good bug report?
%\newblock In {\em Proceedings of the 16th ACM SIGSOFT International Symposium
%  on Foundations of software engineering(FSE'08)}, pages 308--318, 2008.

%\bibitem{Bhandari1993}
%I.~Bhandari, M.~Halliday, E.~Tarver, D.~Brown, J.~Chaar, and R.~Chillarege.
%\newblock A case study of software process improvement during development.
%\newblock {\em IEEE Transactions on Software Engineering}, 19(12):1157--1170,
 % 1993.

%\bibitem{Bugzilla}
%Bugzilla.
%\newblock http://www.bugzilla.org/.

%\bibitem{Card1998}
%D.~N. Card.
%\newblock Learning from our mistakes with defect causal analysis.
%\newblock {\em IEEE Software}, 15(1):56--63, 1998.

%\vfill\eject

%\bibitem{Chillarege1992}
%R.~Chillarege, I.~Bhandari, J.~Chaar, M.~Halliday, D.~Moebus, B.~Ray, and M.-Y.
%  Wong.
%\newblock Orthogonal defect classification-a concept for in-process
%  measurements.
%\newblock {\em IEEE Transactions on Software Engineering}, 18(11):943--956,
%  1992.

%\bibitem{Godfrey2000}
%M.~W. Godfrey and Q.~Tu.
%\newblock Evolution in open source software: A case study.
%\newblock In {\em Proceedings of the International Conference on Software
%  Maintenance(ICSM'00)}, pages 131--142, 2000.

\bibitem{Herraiz2008}
I.~Herraiz, D.~M. German, J.~M. Gonzalez-Barahona, and G.~Robles.
\newblock Towards a simplification of the bug report form in eclipse.
\newblock In {\em Proceedings of the 2008 international working conference on
  Mining software repositories (MSR'08)}, pages 145--148, 2008.
  
\bibitem{Hewett2009}
Hewett.~R, and Kijsanayothin.~P.
\newblock On modeling software defect repair time.
\newblock {\em Empirical Softw. Engg.}, pages 165--186, 2009.

\bibitem{Jeong2009}
Jeong.~G, Kim.~S, and Zimmermann.~T.
\newblock Improving bug triage with bug tossing graphs.
\newblock In {\em Proceedings of the 7th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering on European Software Engineering Conference and Foundations of Software Engineering Symposium }, pages 135--144, 2009.
 
\bibitem{Ihara2009}
Ihara.~A, Ohira.~M, and Matsumoto.~K.
\newblock An analysis method for improving a bug modification process in open source software development.
\newblock In {\em Proceedings of the Joint international and Annual ERCIM Workshops on Principles of Software Evolution (IWPSE) and Software Evolution (EVOL) Workshops }, pages 111--120, 2009.
  

%\bibitem{Kim2006}
%S.~Kim, K.~Pan, and E.~E.~J. Whitehead, Jr.
%\newblock Memories of bug fixes.
%\newblock In {\em Proceedings of the 14th ACM SIGSOFT international symposium
%  on Foundations of software engineering(FSE'06)}, pages 35--45, 2006.

%\bibitem{Kim2006b}
%S.~Kim and E.~J. Whitehead, Jr.
%\newblock How long did it take to fix bugs?
%\newblock In {\em Proceedings of the 2006 international workshop on Mining
%  software repositories(MSR'06)}, pages 173--174, 2006.

%\bibitem{Kim2006a}
%S.~Kim, T.~Zimmermann, K.~Pan, and E.~J.~J. Whitehead.
%\newblock Automatic identification of bug-introducing changes.
%\newblock In {\em Proceedings of the 21st IEEE/ACM International Conference on
%  Automated Software Engineering(ASE'06)}, pages 81--90, 2006.

%\bibitem{Mantis}
%Mantis.
%\newblock http://www.mantisbt.org/.

%\bibitem{Mays1990}
%R.~G. Mays, C.~L. Jones, G.~J. Holloway, and D.~P. Studinski.
%\newblock Experiences with defect prevention.
%\newblock {\em IBM Systems Journal}, 29(1):4--32, 1990.


%\bibitem{Michail2005}
%A.~Michail and T.~Xie.
%\newblock Helping users avoid bugs in gui applications.
%\newblock In {\em Proceedings of the 27th international conference on Software
%  engineering(ICSE'05)}, pages 107--116, 2005.

\bibitem{Mockus2002}
A.~Mockus, R.~T. Fielding, and J.~D. Herbsleb.
\newblock Two case studies of open source software development: Apache and
  mozilla.
\newblock {\em ACM Transactions on Software Engineering and Methodology},
  11(3):309--346, 2002.

%\bibitem{Nakajo1991}
%T.~Nakajo and H.~Kume.
%\newblock A case history analysis of software error cause-effect relationships.
%\newblock {\em IEEE Transactions on Software Engineering}, 17(8):830--838,
%  1991.

%\bibitem{RedMine}
%RedMine.
%\newblock http://www.redmine.org/.

%\bibitem{Sliwerski2005}
%J.~\'{S}liwerski, T.~Zimmermann, and A.~Zeller.
%\newblock When do changes induce fixes?
%\newblock In {\em Proceedings of the 2005 international workshop on Mining
%  software repositories (MSR'05)}, pages 1--5, 2005.

%\bibitem{Trac}
%Trac.
%\newblock http://trac.edgewall.org/.

%\bibitem{Wang2007}
%Y.~Wang, D.~Guo, and H.~Shi.
%\newblock Measuring the evolution of open source software systems with their
%  communities.
%\newblock {\em SIGSOFT Softw. Eng. Notes}, 32(6):7, 2007.

%\bibitem{Yilmaz2007}6
%C.~Yilmaz and C.~Williams.
%\newblock An automated model-based debugging approach.
%\newblock In {\em Proceedings of the twenty-second IEEE/ACM international%
%  conference on Automated software engineering}, pages 174--183, 2007.

\end{thebibliography}
\end{document}