レビュー作業の質に着目した
ソフトウェア最終品質の推定
金村 一弘y, 水野 修y, 菊野 亨y, 高木 徳生z, 坂本 啓司zy大阪大学 基礎工学部 情報科学科〒 560-8531 大阪府豊中市待兼山町 1-3
e-mail: kanemura@ics.es.osaka-u.ac.jp

zオムロン株式会社

あらまし :
本研究では, ある企業におけるソフトウェア開発におけるレビュー作業の質がソフトウェアの最終品質に与える影響を分析する. レビュー作業の質を単位レビュー工数当たりに発見, 除去された不具合の総数で測ることにし , メ
トリクス QLYr で表す. 一方, ソフトウェアの最終品質を出荷後 6ヶ月間に発見された不具合の総数で測ることにし , メトリクス Sumf で表す. まず, メトリクス Sumf の値が 0 とそうでないプロジェクトの間でメトリクス QLYrの値に有意な差があることを順位和検定で示す. 次に, メトリクス QLYr の値に基づいてメトリクス Sumf の値が0 になるかど うかを推定するためのロジスティック回帰モデルを構成する. 更に , 実際のプロジェクトデータを利用した適用実験でこの回帰モデルの有効性を示した.
キーワード : ソフトウェアレビュー, ソフトウェア最終品質, 統計的分析

Studies on the E ects of Review Eciency on Field Quality ofSoftware Productyyy

Kazuhiro Kanemura , Osamu Mizuno , Tohru Kikuno ,z and Keishi Sakamotoz

Yasunari Takagi

yDepartment of Informatics and Mathematical Sciences,
Faculty of Engineering Science, Osaka University
1-3 Machikaneyama, Toyonaka, Osaka 560-8531, Japane-mail : kanemura@ics.es.osaka-u.ac.jp

zOMRON Corporation

Abstract: In this paper we present the results of statistical analyses which try to clarify the e ects of review
eciency to the eld quality of software product. We de ne two software metrics QLYr and Sumf as follows: QLYr represents the number of defects that are found and removed per the e ort of review activity. Sumfrepresents the number of defects that are reported during six months after delivery. First, we show that there
exists a signi cant di erence on the values of QLYr between project with Sumf = 0 and project with Sumf > 0.
Then we construct a logistic regression model E (Y jx) which estimates the values of Sumf based on the values
of QLYr . The experimental results using actual project data show the usefulness of the obtained model.
Keywords: software review, software quality, statistical analysis

1 まえがき
社会システムのコンピュータへの依存度が高まるに
つれ , ソフトウェアの開発はより短い開発期間で, しかも少ない人的資源の下で行わねばならなくなっている.
その反面, ソフトウェアに要求される品質は年々高いものとなり, 求められる品質を納期内に達成することが非常に難しくなりつつある.
従来のソフトウェア開発プロセスでは , 設計, コー
ディングに続くテストの工程で不具合の検出とデバッグを行っていた. しかし , 開発プロセスの後工程で発見された不具合を取り除くには多くの工数を必要とするため, テスト工程での作業は開発プロジェクトの致命的な遅れを招くこともあった [4]. 近年, 設計やコーディングといった開発の前工程の中で効果的に不具合を検出, 除去するための手法としてレビュー作業が注目されている [2, 5].
我々は, ある企業におけるレビュー作業の実施状況とその効果について, 次の (1), (2) を示すために統計的な分析を重ねてきた：(1) 適切な量のレビュー作業を実施することによって, 不具合の発見を前倒しできる, (2)レビュー作業を実施することが最終的な品質 (フィールド 品質と呼ぶ) の向上につながる. これらの分析の中で, レビュー作業の工数が設計全体に占める割合に注目し , この割合をある値以上に保つことによって不具合の大半をレビュー作業で発見できることを示した.
近年この企業では , 全てのプロジェクトの平均としてみるとレビュー作業の量は確実に増加傾向にある. しかし , 最終的な品質の向上は期待する程には達成されないという状況が観測されている. このことはレビュー作業の量に注目するだけでは , プロジェクトの最終品質の向上に必ずしもつながらないことを示している.
レビュー作業は, 一般に作業者の能力に依存する部分が多い. 同じ時間のレビュー作業を行った場合でも,作業者によって発見, 除去される不具合の数は大きく異なる. レビュー作業の量を測ったのでは作業に携わる人間の処理能力の差がほとんど 反映されていない.
そこで, 能力の差を考慮した新しい指標の開発が必要となる. レビュー作業において重要なのは作業の内容,つまりどれくらい不具合を発見, 除去できたかという作業の効果である. そうした指標によってレビュー作業の質を評価することが妥当だと思われる.
本研究では, 「単位レビュー工数当たりに発見, 除去された不具合数」で「レビューの質」を計測することを提案する. この「レビューの質」に着目して, プロダクトの最終品質との関係を分析する. 具体的には , レビューの質を測るためのメトリクス QLYr を導入する.
また, プロダクトの最終品質については , 出荷後 6ヶ月間に発見された不具合の総数を計測することを提案する. そのためのメトリクス Sumf を導入する.
統計的な分析としては次の 2 つを示す.

(1) Sumf の値が 0 のプロジェクトとそうでないプロジェクトの間で QLYr の値に有意な差がある. 分析の手法として順位和検定を用いる.
(2) QLYr の値を利用して, そのプロジェクトの Sumfの値が 0 になるかど うかを推定するためのロジスティック回帰モデルが構成できる.

2
2.1

準備
ソフト ウェア開発プロセス

本研究で対象としているソフトウェア開発プロセスは標準的なウォーターフォールモデルである. 図 1に示すように, 開発プロセスは上から順に, 計画, 設計,コーディング , テスト , デバッグ，受け入れテストの工程から構成されている.

この開発プロセスでは , 不具合の発見, 除去はテス
ト , デバッグ工程で行われる. しかし , 開発の後工程で発見された不具合を除去するためには多大なコストがかかることが知られている [1].

この問題を解決するための有効なアプローチとして ,(1) テスト作業の効率化, (2) 早期工程での不具合発見,除去, などが考えられてる. この中でテスト作業の効率化に関しては, テストアイテムの絞り込み, 不要なテストの省略などの方法が提案されており, 実際に適用してかなりの効果を上げている. しかし , この方法では当初の予測を上回る量の不具合が発見された時などには , 結局多大なコストが必要となる. そこで注目されてきたのが (2) に示す, 開発初期段階での不具合の検出, 除去の手法である.

図 1: ウォーターフォールモデル

レビュー活動

2.2

開発の初期段階で不具合を検出, 除去する手法としてよく知られているのがレビュー作業である. レビュー作業は, 設計のある段階やコーディングの終了時に, 少人数 (例えば 2〜3 人) で行われる. 具体的には, 設計ドキュメントと要求仕様書との整合性を調べたり, 設計に基づいた適切な実装が行われているかを調べる.
ソフトウェアの設計工程において作りこまれた不具合の大半を, いわゆる設計レビュー作業の導入によって発見できるということがこれまでの研究によって示されている [2, 5].
我々は 1993 年以来, ある企業の協力の下でソフトウェアプロセスの改善に関する研究を行ってきた. この企業では 8 年ほど前に Software Engineering ProcessGroup(SEPG) が設立され , ソフトウェアプロセス改善を図ってきている. これまでにも幾つかの改善方法を提案してきており, 実際の開発現場でも適用されている.
文献 [7] においては, レビュー作業の量の拡大がソフトウェア最終品質とチームの生産性に与える影響に関する分析が行われている. その中では , レビュー作業の実施率の増加につれてソフトウェアの最終品質 (ここでは, フィールド 不具合の出現に関する品質) が向上するという結果が得られた. しかし , ほとんどレビュー作業をしなくても高い品質を示すプロジェクトが多数存在することもこの分析結果から確認されている. そのため, レビューの量だけでソフトウェアの品質を議論することは難しいと考えられた.
また, この企業では, ここ数年の傾向としてレビューの実施率が向上しているのに最終品質が思うように向上していないということも確認されている. このことからも, レビューの量に注目するだけでは, プロダクトの最終品質を説明することが難しいと思われるようになってきた.

開発規模 SLC は次式によって定義される.

SLC = newSLC +2. レビューの質 QLYr
QLYr は , レビュー作業によって発見, 除去された不具合数をレビューにかかった工数で割ったものとして定義される. この QLYr で行ったレビュー作業の品質を測る. QLYr の定義では次の記号を用いる．

QLYr
Costr

レビューの質 (単位は個 = 人月である. )Sumr

レビュー作業によって発見, 除去された不具合数 (単位は個である. )1. 開発規模 SLC
SLC は, 再利用分も含めて, 設計, コーディングしたソースコード の行数を表す. 但し , コメント行は全て除いて集計する. なお, 再利用分についてはその修正の度合いに応じて行数を計算している. SLC の定義では次の記号を用いる.
開発規模 (単位は Kstep である. )SLC
newSLC 新規に開発したソースコードの行数.
slgSLC 若干の修正を行って再利用したソース

QLYr =;

大幅な修正を行った上で再利用したソースコードの行数.
補正係数.

Sumr
Costr

3. レビューの量 QT Yr
QT Yr は, レビュー作業にかかった工数をそれ自体と設計工数の和で割ったものとして定義される(単位は％である). この QT Yr によって, レビュー作業を含めた総設計工数に対するレビュー工数の割合を表している. QT Yr の定義では次の記号を用いる．

Costr

レビュー作業にかかった工数 (単位は人月である. )Costd

設計作業にかかった工数 (単位は人月である. )レビューの量 QT Yr は次式によって定義される.

QT Yr =

Costr
2 100(％)
Costr + Costd

4. 不具合密度  は, プロジェクトの各段階 (レビュー, テスト・デバック, 受け入れテスト , 出荷後 6ヶ月での調査)
で発見, 除去された不具合の総数を開発規模で割ったものである.  の定義では次の記号を用いる.



作り込まれた不具合の密度 (単位は個/Kstep である. )Sumt0

テスト・デバッグ作業の工程で発見, 除去された不具合の総数 (単位は個である. )Sumt1

受け入れテスト作業の工程で発見, 除去された不具合の総数 (単位は個である. )コードの行数.

extSLC

レビュー作業にかかった工数 (単位は人月である. )レビューの質 QLYr は次式によって定義される.

ソフト ウェアメト リクス

2.32 slgSLC + 2 extSLC

Sumf

出荷後 6ヶ月間に発見された不具合の総数.

表 2: プロジェクト分類の内訳
PJ#QLY r
1
0.37 Fair
22.25 Good
35.56 Good
42.76 Fair
51.62 Foor

作り込まれた不具合の密度  は次式によって定義される.

=

Sumr + Sumt0 + Sumt1 + Sumf
SLC

3 対象とするプロジェクトデータある企業で実施された, 1992 年から 1997 年までのソフトウェア開発プロジェクトの内，ある一定の条件の下に抽出した 51 件のプロジェクトを対象とする. どのプロジェクトもゼロから新規にソフトウェアを作成していく種類のものではなく, 既存のソフトウェアに修正や変更をし , 新規に作成した部分を追加して開発を行うものである.
3.1

プロジェクト のグループ分け

495051

表 3: 不具合密度  の平均値
ρµ Goodρµ Fair3.2

不具合密度  の差

次に , プロジェクトで作り込んだ不具合の密度  について考える. もし , フィールド 不具合の発生したグループ F air での作り込み不具合密度  の値が , グルー
プ Good に比べ大きい場合, フィールド 不具合が多く発生した原因が , 作り込まれた不具合の数の大小によるのではないかと考えられる. そこで 2 つのグループ
Good と F air の標本に対して, それぞれの母集団の分布の中央値に差があるかど うか, つまり, 2 つの分布にずれがあるかど うかを検定する [3].

20.91
17.07

表 4: 順位和検定の結果

GoodFair

表 1: プロジェクトのグループ分け

GoodFair

Fair
GoodGood

グループ Good とグループ F air の作り込み不具合密
度の平均をそれぞれ Good ; F air と表す. それらの値の比較を表 3に示す. また, 順位和検定の結果を表 4 に示す.

ここでは, メトリクス Sumf の値を利用して 51 件のプロジェクトをフィールド不具合によって 2 つのグルー
プ Good と F air に分ける.
一般的にプロダクトの最終品質は, プロジェクトの特性に応じて許容される度合いが異なる. 今回分析の対象としたプロジェクトの特性としては, フィールド不具合の発生は, たとえ一件であっても望ましくないものがほとんどであった. そこで , メトリクス Sumf の値を利用してプロジェクト群をフィールド 不具合の発生しなかったプロジェクトのグループと発生したプロジェクトのグループに分類した. 前者をグループ Good,後者をグループ F air と呼ぶ. (表 1, 表 2)

Sum f
Sum f = 0
Sum f > 019.62
25.1927.44p30.353
23.8240.1392

表 3に示すように , 作り込み不具合密度の平均値はグ
ループ F air の方が少ない. また表 4に示す検定結果から , p 値が有意水準 (0.05) 以下ではないので, 2 つのグ
ループ Good, F air の不具合密度の平均において「 差がある」とはいえない. つまり, グループ Good と F airの間では不具合密度の平均値に関してさほど差はないと考えることができる.

4 レビュー作業の質
4.1

仮説 :

仮説の定義

2 つのグループ Good と F air の間でレビューの質の値に差がある, つまりQLYrrQLY
Good > F airが成立する.
4.2

4.3

QT Yr の平均値の順位和検定

まず, レビュー作業の量 QT Yr に関して , 先程と同様, グループ Good とグループ F air の平均をそれぞれ
Yr
QT Yr
QTGood , F air と表す. それらを比較した結果を表 7に示す.

QLYr の平均値の順位和検定

表 1に 示す 2 つのグ ル ープ Good, F air に ついて,
QLY
そのレビューの質 QLYr の平均値をそれぞれ Goodr ,r
QLY
F air と表す. それらの値を表 5に示す.

表 7: レビューの量 QT Yr の平均値
QTYr
µ Goodµ QTYrFair

表 5: レビューの質 QLYr 平均値µ QLYr
Goodµ QLYr
Fair

8.41
4.56(h1 )：表 8: 順位和検定の結果

2 つのグループ Good と F air の間でレビューの質の値に差はない, つまりGoodFair

QLYrr
QLY
Good = F airpが成立する.

2 つのグループ Good と F air の間でレビューの質の値に差がある, つまりQLYrr
QLYGood > F airが成立する.

表 6: 順位和検定の結果

GoodFairp

26.58825.706

0.8416

表 8より, p 値 が有意水準 (0.05) 以下ではない. 従って, 2 つのグループ Good と F air の間でレビューの量に関して ,「差がある」とはいえない. つまり, レビューの量が最終品質に影響を与えているとは思われない.
4.4

得られた検定結果を表 6に示す.

0.140

表 7から , 平均値にほとんど 差はないことが分かる.
ここで , 再び順位和検定を用いて分析を行う. その結果を表 8に示す.

この検定において用いた仮説 (h0 ) と対立仮説 (h1 ) を次に示す.

(h0 )：

0.141

考察

4.2より, レビュー作業の質 (つまり QLYr の値) の大小がフィールド 不具合が発生するか否か (つまり,Sumf = 0 かそうでないか) に影響を与えていることが分かった. 一方, 3.2と 4.3の分析より, レビューの量や作り込み不具合数の大小がフィールド 不具合の発生するのか否かに大きな影響を与えないことが分かった.

33.76522.1180.0084

表 6の p 値 が有意水準 (0.05) 以下である. 従って仮説 h0 は棄却され , 対立仮説 h1 が採択される. これによって \2 つのグループ Good と F air の間でレビューの質 QLYr の値に差がある" ということが統計的に示されたことになる.

5

最終品質の推定5.1

推定問題の定義

ここでは , レビューの質が高いプロジェクトで作成されるソフトウェアはその最終品質も高くなるかど うかについて考える. 具体的には, レビューの質 QLYr の値に基づいてそのプロダクトの Sumf の値が 0 になるかど うかを推定する.

2.3の定義より, レビューの質 QLYr は連続変数である. 一方, ソフトウェアの最終品質 F inalQly はフィー
ルド 不具合が発生するかしないかという 2 値変数であり, Sumf = 0 かど うかで評価している.
ここでは , 目的変数が 2 値の場合に最もよく用いられる回帰モデルであるロジスティック回帰モデル [9] を適用する.
5.2

ロジスティック回帰モデル

ロジスティックモデルは次式

eb0 +b1 x1
E (Y jx1 ) =1 + eb0 +b1 x1に基づいている. ここではレビューの質 QLYr を説明
変数 x1 に , フィールド不具合の有無 (Sumf = 0 かそうでないか ) を表した F inalQly を目的変数 Y に対応させたモデルを作成する. 係数 b0 と b1 を表 2の分析データを利用して推定した. その結果次に示すモデル式が得られた.

E (Y jx1 ) =e01:546+0:142x1
1 + e01:546+0:142x1

このモデル式に対する適合度や統計的な有意性について, 次節で検定を行う.
5.3

その結果, p 値 = 0.0173 となった. p 値 が 0.05 以下であることより, モデルは統計的に有意である.
5.4

モデルによる推定

今回作成したモデルに従い, QLYr の値からフィールド 不具合の発生を予測した. 但し , 新規のプロジェクトについて予測するのではなく, モデル作成に利用した51 件のデータに適用した. 予測の結果を表 10に示す.
表中では次の記号を用いる.

 Good :フィールド 不具合が 発生し なかった

(Sumf = 0 となっていた) プロジェクトを表す.

 F air : フィールド 不具合が発生した (Sumf > 0となっていた) プロジェクトを表す.

表 10の予測では , レビューの質の値 QLYr をモデル式に代入してフィールド 不具合が発生する確率 E を計算した. 確率 E が 0.5 以上のものを F air とし , 0.5 未満のものは Good と推定した. 表 10中の数字の単位はプロジェクト数である.
表 10中の実測の Good と F air は , フィールド 不具合が発生しなかったプロジェクトと発生したプロジェクトの実際の数を書いている.

統計的検定

表 10: 予測と実測の比較

モデルの適合度と統計的有意性に関する検定結果をそれぞれ表 9 に示す.

Good
Fair

Good41

Fair

1333

23.5%
97.1%

表 9: モデルの適合度
59.26
49p0.150

 モデルの適合度
モデルの適合度の判断はデビアンスと呼ばれる統計量を用いて行う. 一般にデビアンスが自由度とほぼ同じ値をとると適合度は良いとされる. 一方,p 値 については 0.05 以下になると適合度が悪いと判断される.
表 9より, デビアンスの値と自由度の値があまり離れておらず , p 値 が 0.05 以下でないことより, 適合度はまずまず良好である.

 モデルの有意性

モデルの有意性検定は , 仮説 H0 : b0 = b1 = 0 に対する尤度比検定によって行う.

5.5

考察

表 10より, 予測の精度はそれほど高くないことが分かる. 詳細に見ると, F air と予測された 46 件のプロジェクトのうち 13 件は実際には Good であった. しかし , 開発中のプロジェクトに対してフィールド 不具合発生の危険を警告するという目的を考えた場合, この予測誤りは大きな問題ではない.
最も注意すべき点は, Good と予測されたにもかかわらず , 実際には F air となったプロジェクトである. この状況は極力避けなければならない. 今回の分析においては , 51 件のプロジェクトの中でただ 1 件のみがこれに該当していた.

6 まとめ
今回の分析を通して, ソフトウェアの最終品質の向上にレビュー作業が重要な役割を果たすことが分かった. しかもレビュー作業の量よりも質のほうが最終品質に与える影響は強い. 直観的には「質の高いレビューを実施したプロジェクトほど , フィールド 不具合が発生しにくい」ということになる.
しかし , 今回の結果はあくまでもデータを提供して頂いた企業の, あるプロジェクト群についての分析結果である. 異なる企業や, 種類の全く異なるプロジェクトについては必ずしも今回の分析結果が当てはまるとは言えない.
更に , ソフトウェアの最終品質に影響を与え得る因子はレビュー以外にも無数に考えられる. レビューの質は, あくまでそれらの一つに過ぎない. このような点に関しては十分に留意しておかなければならない.
今後の課題としては , (1) どれくらいのレビューの質が確保されれば次の工程へ移行すべきか, (2) 質の高いレビュー作業が生産性やその他のコストに対してどのような影響を与えるのか , といった問題に対して統計的な手法で解を見つけることがある.

参考文献[1] 藤野喜一, 花田収悦： ソフトウェア生産技術,
電子情報通信学会 (1985).
[2] M. E. Fagan: \Advances in software inspections," IEEE Trans. on Software Engineering, Vol.12,No.7, pp.744{751 (1986).
[3] 石村貞夫： 統計解析のはなし , 東京図書 (1989).
[4] W. S. Humphrey: Managing the Software Process, Addison Wesley, Reading, MA (1989).
[5] R. G. Ebenau and S. H. Strauss: Software Inspection Process, McGraw-Hill (1993).
[6] M. C. Paulk, C. V. Weber, S. M. Garcia, M. B.
Chrissis and M. Bush: \Key practice of the capability maturity model, version 1.1, " Technical Report CMU/SEI-93-TR-25, Software Engineering Institute (1993).
[7] Y. Takagi, T. Tanaka, N. Niihara, K. Sakamoto,S. Kusumoto and T. Kikuno: \Analysis of review's e ectiveness based on software metrics, "Proc. of 6th Int'l Symposium on Software Reliability Engineering(ISSRE'95), pp.34{39 (1995).
[8] T. Tanaka, K. Sakamoto, S. Kusumoto and T.
Kikuno: \Improvement of software process byprocess visualization and bene t estimation, "Proc. of 17th Int'l Conference on Software Engineering(ICSE'95), pp.123{132 (1995).

[9] 丹後俊郎, 山岡和枝, 高木晴良： ロジスティック
回帰分析 朝倉書店 (1996).
[10] O. Mizuno, T. Kikuno, K. Inagaki, Y. Takagi
and K. Sakamoto: \Analyzing e ects of cost estimation accuracy on quality and productivity," Proc. of 20th Int'l Conference on Software Engineering(ICSE'98), pp.410{419 (1998).
[11] O. Mizuno and T. Kikuno: \Empirical evaluation of review process improvement activities
with respect to post-release failure, " Empirical Studies on Software Development Engineering(ICSE'99 Workshop), pp.50-53 (1999).