![[PukiWiki]](image/wadanyan.png "[PukiWiki]")
| Mon | Tue | Wed | Thu | Fri | |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | 全体MT | TKG班MT | |||
| 3 | ソフトウェア工学特論 | 3年演習 | マルチメディア | マルチメディア | |
| 4 | ソフトウェア工学特論 | 3年演習 | |||
| 5 |
4つのパターンで不具合管理プロセスが運用されていて，全てのパターンで効率的に運用されることが期待されている．
プロセスを円滑に進めるためには，主に2つが重要である．
1つ目は，RT間では適切な不具合報告がなされているかどうかである．
2つ目は，TF間では当該不具合の修正に適切な修正者に割り当てられているのかである．
適切な修正者に割り当てるためには割当者が修正者のことを熟知していることが必要である．そのため熟知しているかどうかをいままでの開発プロセスにおいて共同作業をした回数を評価の指標として使用する．
不具合管理プロセスにはR=T=F，R=T≠F，R≠T=F，R≠T≠Fの4つのパターンがあり，それぞれパターン1，パターン2，パターン3，パターン4と呼称する．
上記のパターンが不具合修正時間に影響を与えることが先行研究で示されており，パターン4が他のパターンよりも修正時間が長い結果になっていた．
しかし，修正時間が最も長いパターン4に他のパターンと同程度の修正時間が短い集団が存在していた．
そこでパターン4で2つの集団が存在する理由があり，その理由を解明することで不具合管理プロセスをより効率化できると考えた．
本研究は，パターン4において修正時間が長い集団の修正時間を短くすることを目指す．
修正時間を短くするためには円滑な不具合管理プロセスが必要であり、それを実現するための必要な要因を調査する．
パターン4の修正時間に関わる要因を調査することで一つあたりの修正時間を削減し，より多くの不具合を修正することを可能とする．
パターン1,2は発見した不具合を報告する必要がない．そのため報告が適切に行われているかが関係していない．
パターン1,3は報告された修正を他の開発者に割り当てることが行われない．そのため割り当てが適切に行われているかが修正時間に影響がない．
パターン4において報告が適切に行われているか、と適切な割り当てができているかの2つの要因が修正時間に関わっている．
RT間においては適切に不具合の概要が伝わっているのかが大切
→概要を正確に伝えるためには報告するべき箇所を理解している必要がある
→報告するべき点を理解するには多くの報告を経験する必要がある
→報告に慣れている開発者が報告した場合と慣れていない開発者が報告した場合とで差があるのではないか
→報告回数に注目
TF間においては適切な修正者に割り当てることができてるかが大切→TF間の開発者間の関係性に注目
報告.pdf
