ソフトウェア・シンポジウム2018 in 札幌

バグ修正時間を考慮したソフトウェア最適リリース問題についての一考察
岡村 寛之
広島大学大学院工学研究科
okamu @ hiroshima-u.ac.jp

住田 大亮
広島大学大学院工学研究科

要旨

土肥 正
広島大学大学院工学研究科
dohi @ hiroshima-u.ac.jp

バグ修正を考慮したソフトウェア信頼性モデルは，これまでにもいくつも議論されている．Schneidewind [10,本稿では，バグ修正難易度を表す指標としてバグ修正

11], Xie ら [13, 12], Gokhale ら [1, 2] は累積修正バグ数を表現する確率モデルを構築している．Xie ら [12] はバグ発見とバグ修正を統合するモデルの構築をしている．
これら，累積バグ発見と累積バグ修正がともに非同次ポアソン過程に従うという特徴をもつ．また，Okamura
and Dohi [7] は上述のすべてのモデルを含むバグ修正モデルフレームワークを提案している．特に，文献 [7]では，バグ発見時刻とバグ修正時間の相関も考慮した一般的なモデルフレームワークを提案している．ここで言うバグ発見時刻と修正時間時間の相関は，テストの早い段階で見つかったバグほど修正時間が短い（あるいは長い），または，テスト終盤で見つかるバグほど修正時間が短い（あるいは長い）と言った関係を定量的に表しており，これは，どのモジュールを先にテストするかなどのテスト戦略と密接に関係している．文献 [7] では，現在までに見つかっていないバグ数だけではなく，現在までに見つかっているが修正されていないバグ数を考慮した信頼性指標の提案を行っている．
本稿では，上述のバグ発見時刻とバグ修正時間の相関を考慮したモデル上でのソフトウェアリリース問題を扱う．ソフトウェア開発において，経済的な観点からソフトウェアテストを終了しソフトウェアのリリースを行う適切なタイミングを決定することは非常に重要である．
これはソフトウェアリリース問題と呼ばれ，古くからソフトウェア信頼性モデルに基づいた数理的なアプローチが数多く行われている．Okumoto and Goel [8] はバグ発見時刻のみを考慮した指数形ソフトウェア信頼性モデ
ルを利用して，テスト費用，テスト期間中のバグ修正費用，リリース後のバグ修正費用の期待値を算出し，その総費用を最小にする最適なリリース時間の決定を行って時間を用いたソフトウェア最適リリース問題の再考を行う．特に，従来のバグ修正時間を考慮したソフトウェア信頼性モデルにおいて，バグ発見時刻と修正時間が独立であるという仮定を修正し，バグ発見時刻と修正時間の相関を表現することができる一般的なモデルフレームワークを取り上げ，そのモデルフレームワークにおけるソフトウェア最適リリース問題について考察する．

1. はじめにソフトウェア信頼性はソフトウェア品質における最も重要な指標の一つである．定量的なソフトウェア信頼性はある期間にバグが発見されない（システム障害が発生しない）確率として定義される．これまでに，定量的なソフトウェア信頼性を評価するための確率モデルとしてソフトウェア信頼性モデル（ソフトウェア信頼度成長モデル）が提案され，ソフトウェア開発管理において様々な側面で利用されている [6, 4, 5, 9]．
従来のソフトウェア信頼性モデルではテスト工程において発見されるバグ数に着目したモデリングとなっている．一方，現在のソフトウェア開発ではオープンソースソフトウェア（OSS: Open Source Software）で見られるように，継続的インテグレーションにより常にソフトウェアが利用できる状態を保持するスタイルが主流となっている．そのような開発形態では，各リリースでそこまでに発見したバグがすべて修正されているとは限らない．つまり，バグ発見だけではなく，バグ発見，バグ特定，バグ修正などのバグに対するライフサイクルを考慮した信頼性評価が必要となる．

75

SEA

ソフトウェア・シンポジウム2018 in 札幌

定から以下の確率関数が得られる．

いる．Okumoto and Goel [8] 以降，様々な要因を取り入れたリリース問題の定式化がなされているが，そのほとP (N (t) = n) =んどがバグ発見時刻だけに着目したものである．つまり，バグ発見後，即座にバグが修正される仮定を考えている．
しかしながら，現実のソフトウェア開発にでは様々なバ=グが存在し，その修正難易度も大きく異なる．一般的に

∞
∑

m=n

バグ修正では，バグの原因の特定，プログラムの修正，=修正箇所のテスト（回帰テスト）が行われ，再現性の低

P (N (t) = n|M = m)P (M = m)

m=n
∞ (∑)
mω m −ωF (t)n (1 − F (t))m−nenm!

(ωF (t))n −ωF (t)
e.
n!

(1)

いバグでは原因特定に時間を要することがある．バグ発

上記の確率関数より，累積バグ数の確率過程 N (t) は平

見だけに着目したソフトウェアリリース問題ではこのよ

均値関数 E[N (t)] = ωF (t) の NHPP となる．ソフト

うなバグの修正難易度にかかわらず一律のバグ修正費用

ウェア信頼性モデルが与えられた時，テスト時刻 t からを課すことが多く，バグ修正がリリース時間に与える影t + u でバグが発見される確率（ソフトウェア信頼度）は響について明らかになっていない．そこで，本稿では，

R(u|t) = exp (−ω(F (t + u) − F (t)))

バグ修正時間を考慮したモデルにおけるソフトウェア最適リリース問題を再考する．特に，一般的なバグ修正時(2)で与えられる．

間を考慮したモデルフレームワーク [7] におけるソフト

2.2. バグ発見時刻と修正時間を考慮したモデル

ウェアリリース問題を再定義し，バグ修正時間ならびにバグ発見時刻とバグ修正時間の相関が最適なリリース時

文献 [7] では，次で紹介するバグ発見だけではなく修刻に与える影響について調べ，経済的な観点からどのよ正時間を考慮したモデルを提案している．まず，修正時うなテスト戦略が良いかについて議論する．

間を扱うために以下の仮定を設定する．

2. ソフトウェア信頼性モデル• テスト前にソフトウェア内に潜在するバグ数 M は，平均 ω のポアソン分布に従う．

2.1. バグ発見時刻によるソフトウェア信頼性モデル• M 個のバグの発見時刻 X および修正時間（発見から修正完了までの時間）S は独立かつ同一に分布する二変量確率変数 {(X1 , S1 ) · · · , (XM , SM )} で表され，その同時分布関数を F (x, s) とする．

従来のソフトウェア信頼性モデル（ソフトウェア信頼度成長モデル）は，開発工程における累積バグ発見数を確率過程で表現し，現時点での残存バグ数や将来のバグ発見に関する評価・予測を行うモデルである．非同次ポア

先のバグ発見時刻に対するモデルとの本質的な違いは，

ソン過程（NHPP: non-homogeneous Poisson process）

バグ発見時刻と修正時間が二変量分布で表現されているに基づくソフトウェア信頼性モデルは以下の仮定から構点にある．つまり，バグ修正時間がバグが発見される時築される．

刻に依存することを許容している．これは，テストの早い段階で見つかったバグほど修正時間が短い（あるいは• テスト前にソフトウェア内に潜在するバグ数 M は，平均 ω のポアソン分布に従う．

長い），または，テスト終盤で見つかるバグほど修正時間が短い（あるいは長い）と言った相関関係を表すこと• M 個のバグの発見時刻は独立かつ同一に分布する確率変数 {X1 , · · · , XM } で表され，その累積分布関数を F (t) とする．になる．
文献 [7] では二変量分布 F (x, s) から次の分布を考えている．

いま，時刻 t = 0 でテストを開始したとき，時刻 t まで

• FU C (t): あるバグが時刻 t までにバグが発見されたが修正されていない確率の累積バグ発見数を {N (t), t ≥ 0} とすると，上記の仮• FC (t): あるバグが時間 t までにバグが発見・修正される確率

76

SEA

ソフトウェア・シンポジウム2018 in 札幌• FD (t) = FU C (t) + FC (t): あるバグが時間 t までに発見される確率• c2 ： テスト工程において発見されたバグを修正するための単位個数当たりの費用

これらは同時密度関数 f (x, s) = ∂ 2 F (x, s)/∂x∂s を用• c3 ： リリース後の運用工程において発見されたバグを修正するための単位個数当たりの費用

いると∫ t ∫ t−x
FU C (t) =f (x, s)dsdx,00∫ t∫ ∞FC (t) =f (x, s)dsdx,一般的に，バグ修正費用はテスト工程よりもリリース後(3)の運用工程の方が高いため c3 > c2 を仮定する．現在時
刻 t までに発見されたバグの個数を N (t) とし，ソフト(4)ウェアのサポート打ち切り時刻を TLC とする．このと0t−x∫ t∫ ∞FD (t) =f (x, s)dsdx
0き，時刻 T でソフトウェアをリリースしたときの総期(5)待費用を C(T ) とすると，0となる．いま，ND (t) ならびに NC (t) を時刻 t までに発C(T ) = c1 T + c2 E[N (T )] + c3 (E[N (TLC ) − E[N (T )]).
(7)となる． E[N (t)] は時刻 t までに発見されたバグ総数の期待値であり，バグ発見時刻分布 F (t) および初期バグ数の期待値 ω を用いると，式 (7) は見されたバグの総数ならびに修正されたバグの総数とす
ると，初期バグ数 M がポアソン分布に従うため ND (t)と NC (t) の同時確率はP (ND (t) = d, NC (t) = c)d−c=C(T ) = c1 T + c2 ωF (T ) + c3 ω{F (TLC ) − FD (T )}. (8)c

(ωFU C (t))(ωFC (t)) −ωFD (t)e(d − c)!c!

(6)となる．このとき，ソフトウェア最適リリース問題は総として記述できる．上述の周辺分布 P (ND (t) = d),期待費用 C(T ) を最小化するリリース時刻 T ∗ を求める

P (NC (t) = c) はともに平均 E[ND (t)] = ωFD (t),E[NC (t)] = ωFC (t) のポアソン分布となる．つまり，文献 [7] のモデルフレームワークはバグ発見過程，バグ修正過程がともに NHPP となるモデルをすべて包括している．実際，既存の文献 [10, 11, 13, 12] のモデルがこのモデルフレームワークのサブクラスとなっている．
文献 [7] では，ソフトウェア信頼度（ある区間でバグが見つかる確率）以外の信頼性尺度として，ある時刻までに発見されたバグがすべて修正されている確率を算出している．これは，例えば OSS を流用したソフトウェアを開発する場合に従来のソフトウェア信頼度よりも有益な尺度となることが示唆されている．また，文献 [7]ではさらに，効率的なモデルパラメータの推定アルゴリズムについて言及している．

問題として，次のように定式化される．

min0≤T ≤TLC

C(T ).

(9)3.2. バグ修正時間を考慮したソフトウェア最適リリース問題
本稿では，2.2 で紹介したバグ修正時間を考慮したモデルに基づいてソフトウェア最適リリース問題を考える．
いま，Okumoto and Goel [8] と同様に以下の費用を仮定する．ただし，テスト工程ならびに運用段階におけるバグ修正費用が単一バグ当たりの費用ではなく，修正時間に比例したコストに変更している．

• c1 : テスト工程に要する単位時間当たりの費用．

3. ソフトウェア最適リリース問題• c′2 : テスト工程において発見されたバグを修正するために必要な単位時間当たりの費用．

3.1. 従来のソフトウェア最適リリース問題• c′3 : 運用段階において発見されたバグを修正するために必要な単位時間当たりの費用．
いま，ソフトウェアの利用期間を TLC とすると，時刻 T

Okumoto and Goel [8] は次に示すテスト費用を考慮したソフトウェア最適リリース問題を定義している．

でソフトウェアをリリースするときの総期待費用 C(T )は以下のように定式化される．

• c1 ： テスト工程における単位時間当たりのテスト費用

C(T ) = c1 T + c′2 W (T ) + c′3 (W (TL ) − W (T )) . (10)

77

SEA

ソフトウェア・シンポジウム2018 in 札幌

ここで，W (T ) は時刻 T までに発見されたすべてのバ

表 1. 最適リリース時刻と最小総期待費用．

グを修正するのに必要な期待累積修正時間を表す．いま，{(X1 , S1 ) . . . , (XND (T ) , SND (T ) )} を時刻 T までに発見されたバグの発見時刻と修正時間の列とすると，時刻
T までに発見された ND (T ) 個のバグに対する修正時間
S1 , . . . , SND (T ) の和となるため

ND (T )∑W (T ) = E Si 
i=1=∞∑

E[S|X = x]fD (x)dx

C(T ∗ )

1.0
0.5
0.0
-0.5
-1.0

495.4
477.3
455.3
427.5
389.9

1095.6
1077.41055.31027.0988.0

ここで，FD (x) = P (X ≤ x), FC (x) = P (S ≤ s) はバ0k=0∫ T∫ ∞グ発見時刻ならびに修正時間の周辺分布関数，F (x, s) =sf (x, s)dsdx.
0T∗∫ TP (ND (T ) = k)k=ωαP (X ≤ x, S ≤ s) は同時分布関数を表す．また，F D (t) =1−FD (t), F C (t) = 1−FC (t) である．さらに −1 ≤ α ≤1 は相関の強さを表すパラメータであり，α < 0 の時は負の相関（早い段階で見つかったバグほど修正時間が長い），α = 0 の時は無相関（テストの初期と終盤で発見されたバグの修正時間が同じ），α > 0 の時は正の相関（早い段階で見つかったバグほど修正時間が短い）となる．FGM コピュラによりバグ発見時刻と修正時間の相関を表現するとき期待累積修正時間は(11)0となる．ここで fD (x) はバグ発見時刻に対する周辺密度関数であり，さらに，∫∞

E[S|X = x] =0sf (x, s)ds
fD (x)(12)である．
特別な場合として，バグ発見時刻 X とバグ修正時間

S が独立な場合，つまり，テストの初期と終盤で発見されたバグの修正時間が同じ場合は
W (T ) = E[ND (T )]E[S] = ωFD (T )E[S]W (T ) = ωFD (T )E[S])(∫αF D (T ) ∞× 1−
FC (s)F C (s)ds
E[S]0(13)となる．つまり，単一のバグ修正費用を c′2 E[S] ならびにc′3 E[S] とした Okumoto and Goel [8] によるソフトウェとなる．さらに，簡単のためバグ発見時刻と修正時間をともにパラメータ βD , βC の指数分布とすると()
ωα
W (T ) =(1 − e−βD T ) 1 − e−βD T
βC2

アリリース問題に帰着される．換言すると，Okumotoand Goel [8] によるリリース問題の定式化では「テストの初期と終盤で発見されたバグの修正時間が同じ」であることを暗に仮定している．また，ここで提案した上記の定式化は Okumoto and Goel [8] による問題の数理的な一般化となっている．
以上の準備のもと，バグ修正時間を考慮したソフトウェア最適リリース問題は総期待費用 C(T ) を最小化する時刻 T を見つける問題として定式化される．
min0≤T ≤TLC

C(T ).

(17)となる．
表 1 は c1 = 1.0, c′2 = 0.01, c′3 = 0.2, ω = 100.0,

βd = 0.01, βc = 0.002, TLC = 720.0 とし，パラメータα を -1 から 1 まで変化させた時の最適リリース時刻 T ∗と最小総期待費用 C(T ∗ ) を示している．パラメータ c1 ,c′2 , c′3 の設定では基本的なテスト費用 c1 に対する比率が重要であるため，c1 = 1 と設定し，c′2 , c′3 は基本的なテスト費用の 1%, 20% として相対的に設定している．
この表からバグ発見時刻と修正時間に正の相関がある
場合，独立な場合と比較して最適なリリース時刻が長くなり総費用も高くなることがわかる．反対に負の相関がある場合，最適リリース時刻が短くなり総費用が低くなる．この結果は，バグ発見時刻と修正時間に正の相関がある場合，テスト終盤で修正時間の長いバグが発見され(14)4. 数値例
ここでは，バグ発見時刻と修正時間を相関を表現するために以下に示す FGM コピュラ [3] を用いる．

()
F (x, s) = FD (x)FC (x) 1 + αF D (x)F C (s) .

(16)

(15)

78

SEAソフトウェア・シンポジウム2018 in 札幌

る傾向があるため，リリース後のバグ修正費用を抑える

homogeneous continuous time markov chain. Software Quality Journal, Vol. 12, No. 3, pp. 211–230,
2004.

ためにリリースの延長を考慮する必要があることを示唆している．また，正の相関がある場合はリリースを延長したとしても全体の費用を抑えることにはつながらない[2] S. S. Gokhale, M. R. Lyu, and K. S. Trivedi. Incorporating fault debugging activities into software
reliability models: A simulation approach. IEEE
Transactions on Reliability, Vol. 55, pp. 281–292,
2006.

こともわかる．つまり，全体のテスト関係の費用を抑えるためにはテスト初期において修正に時間のかかるバグを発見する方が良いと言うこともわかる．ここでは，c1 ,c′2 , c′3 に相対的な費用を設定しているため，α = 1 とα = −1 の場合の費用の差は 1095.6 - 988.0 = 107.6 であり，全体費用の 10 % 程度ではあるが，プロジェクトの規模が大きればなるほど基本的なテスト費用として設定した単位時間あたりのテスト費用（1 日当たりのテスト費用） c1 が大きくなるため，負の相関を示すようなテスト戦略を行うことによって，絶対的な費用としてはかなり多くの費用が低減できることもわかる．

[3] H. Joe. Dependence Modeling with Copulas. CRCPress, 2014.
[4] M. R. Lyu, editor. Handbook of Software Reliability Engineering. McGraw-Hill, New York, 1996.
[5] J. D. Musa. Software Reliability Engineering.
McGraw-Hill, New York, 1999.

5. まとめと今後の課題[6] J. D. Musa, A. Iannino, and K. Okumoto. Software Reliability, Measurement, Prediction, Application. McGraw-Hill, New York, 1987.

本稿では，バグ修正時間を考慮したソフトウェア信頼性モデルの一般的なモデルフレームワークを利用し，ソフトウェアリリース問題の定式化ならびに，バグ発見時[7] H. Okamura and T. Dohi. A generalized bivariate
modeling framework of fault detection and correction processes. In Proceedings of the 26th International Symposium on Software Reliability Engineering (ISSRE 2017), pp. 35–45. IEEE CPS,2017.

刻とバグ修正時間の相関が費用とリリースに与える影響について分析した．文献 [7] ではいくつかのオープンソースプロジェクトのデータからバグ発見時刻とバグ修正時間における相関を分析し，いくつかのプロジェク
トで（強い相関ではないが）相関があることを確認している．

[8] K. Okumoto and L. Goel. Optimum release time
for software systems based on reliability and costcriteria. Journal of Systems and Software, Vol. 1,
pp. 315–318, 1980.

本稿の数値例における結果では，テスト初期において修正時間のかかるバグを発見することが経済的な観点から重要であることがわかった．また，リリースに対する意思決定においてはバグ発見時刻とバグ修正時間の傾向を見ることも重要であることがあることも示された．こ[9] H. Pham. Software Reliability. Springer, Singapore, 2000.の指標は恐らくこれまでリリースに対して，あまり意識されていない指標であると考えられる．

[10] N. F. Schneidewind. Analysis of error processes
in computer software. Proceedings of the International Conference on Reliable Software, Vol. 10,
pp. 337–346, 1975.

今後は，ソフトウェア品質評価やテスト進捗などから得られる指標に加えて，ここで議論したバグ発見時刻とバグ修正時間の相関も考慮したリリース判定に対する意
思決定スキームについて議論する予定である．

[11] N. F. Schneidewind. Modelling the fault correction process. In Proceedings of The 12th International Symposium on Software Reliability Engineering, pp. 185–190. IEEE Computer Society
Press, 2001.

参考文献[1] S. S. Gokhale, M. R. Lyu, and K. S. Trivedi. Analysis of software fault removal policies using a non-79

SEA

ソフトウェア・シンポジウム2018 in 札幌[12] M. Xie, Q. P. Hu, Y. P. Wu, and S. H. Ng. A studyof the modeling and analysis of software faultdetection and fault-correction processes. Quality
and Reliability Engineering International, Vol. 23,
pp. 459–470, 2007.
[13] M. Xie and M. Zhao. The schneidewind software
reliability model revisited. In Proceedngs of the
3rd International Symposium on Software Reliability Engineering, pp. 184–192. IEEE Computer
Society Press, 1992.

80

SEA