信頼度成長曲線の成り立ちを思い出してみた(後編)

f:id:monex_engineer:20190405093113p:plain

こんにちは。システム開発部の小田切と申します。
前回の記事いかがでしたでしょうか?

私はスマートにモデル化された微分方程式を見ると、ウキウキしてしまう性格なので、 昔を思い出して前回の記事を書いてみました。
微分方程式といわれても難しい方、
そもそも ロジステック曲線、ゴンペルツ曲線って何?という人も多く、
自分にとっては長年慣れ親しんでいた曲線や式を判りやすく書いたつもりでしたが、ご期待に沿えないところがありましたら、すみません。

とはいえ、ここまで書いてしまったので、続きを書かせて下さい。

前回の内容:
結合テストフェーズの場合、良く用いられる図に信頼度成長曲線があり、
モデルとしては、以下の2つが基本と考えられます。

 1)ロジスティック曲線モデル式
こちらのロジスティック曲線モデル式について成り立ちを説明致しました。
f:id:monex_engineer:20190405160601p:plain

2)ゴンペルツ曲線モデル式
後の説明をしやすいように前回提示の式を変形しています。
f:id:monex_engineer:20190405160627p:plain

 

今回は、。。。
ゴンペルツ曲線について説明を致します。
こちらを使っている人の方が多いかもしれません。

ゴンペルツ曲線モデル

ロジステック関数は、1800年代に導出されたと先月説明しましたが、ゴンペルツ関数も同じく1800年代に作られました。こちらは、人の死亡率に関する関数です。

世代間で死亡率が等比級数的変化を示すとした数理モデルとして始まりました。その応用として、発見されるバグ数が等比級数的に変化するとしたモデルとして用いられています。

前回のロジスティック曲線モデルと同様に、式をイメージしやすくするために、発見バグ数をBug、時間をtとして表現してみます。

(考え方によっては、時間tではなくテストケース数とする場合もあるようですが、ここでは時間とします。)

こちらも考え方は単純です。
バグ発見の伸び率 d(Bug)/dt / (Bug) は、時間とともに減衰していくという考えです。

f:id:monex_engineer:20190405160655p:plain[c < 1]

ちなみに、ロジスティックの場合は、

f:id:monex_engineer:20190405160714p:plain でした。

ゴンペルツは、時間と共に変化率が減るという考え。
ロジスティックは、未発見バグ数が検出率に影響するという考えであることがわかります。

左辺を同じバグ発見伸び率にしたので、ゴンペルツとロジスティックの考え方の違いがお判りいただけたでしょうか。

f:id:monex_engineer:20190405160840p:plainと書けるので、

f:id:monex_engineer:20190405160902p:plainとなり、 t をn, n+1, n+2.... と増やすと、

毎回c倍 ( 通常バグの出現率は減っていくので、c < 1 ) されていることが判ります。
上記の式から、ゴンペルツ曲線のイメージを持つには、縦軸の対数をとると判りやすいです。

ゴンペルツモデルのイメージを図にしたものが以下です。

f:id:monex_engineer:20190405091452p:plain

ゴンペルツモデルの式で、tを無限大とすると、f:id:monex_engineer:20190405160934p:plainが1に近づくので、

バグの総数f:id:monex_engineer:20190405160956p:plainは、k に近づきます。

ロジステック曲線も、tを無限大にすると、バグ総数k が出てきましたね。全く異なる概念でできた式が似たような振舞いを示しました。

同じような曲線を描く時のパラメータの違い

最後に、実稼働90日間のテストで、1000件バグが出る場合の想定で、 ロジスティック曲線とゴンペルツ曲線の各パラメータがどのような値になるかを見てみましょう。
(注:実データではなく、パラメータの値を見るためのイメージです。)

k の値(総バグ数)以外は、お互い全く似ていないパラメータで、同じようなグラフが描けています。私は不思議さを感じます。

f:id:monex_engineer:20190405091703p:plain

開発現場によってはテストの中盤以降、実際のバグ検出数を理論式にあてはめ、総バグ件数や収束時期を想定し、ソフトウェアの品質判定の目安とするところがあります。

大元の理論が判ると、実際の適用時にどうするか悩むことや、理論の限界もイメージできるのではないでしょうか。

あまりに簡単な前提で、現実は違うだろうと思う人も多いと思います。その点をイメージして頂きたく、今回2つの理論を紹介してみました。

 

開発フェーズ間(要件定義、基本設計…)での不具合出現件数から、本番リリース後の不具合を推定する理論があります。

これも、興味深いです。だいぶ前に実プロジェクトに適用してみたことがあります。いつかお話しできることがあると良いですね。

今回も長くなってしまいました。また、お会いできることを楽しみにしております。

 

私が昔勉強し、今回参考にした本(微分方程式を最初に見た本)は、以下です。

参考文献:  ソフトウェアの品質評価法(統計的管理へのアプローチ)
三觜 武 著  日科技連出版社 1981年刊

 

田切 貴秀システム開発部 開発グループ エンジニア

マネックスの長所?!

マネックスグループは2011年にトレードステーション社と合併 し、その後様々なプロジェクトを共同で行っています。


今ではマネックスもグローバルな人材が増えていますが、 合併当時はまだまだ海外とのやり取りは少なく、 英語で実施するプロジェクトも数えるほどしかありませんでした。

 

そんな中とある開発とは全く関係のない部署にいた私は、 会社の偉い人によばれ、
偉い人「○○くんさあ、確か英語できたよね?」
私「はい、10年以上つかってないですけど」

偉い人「 トレードステーションの開発プロジェクトにはいってくれる?」
私「えっ!!??」
偉い人「大丈夫、大丈夫、精鋭チームの中でのサポートだから」
というながれで、いきなり開発に携わることになりました。


マネックスの長所、柔軟性。


開発の「か」の字にもかかわりのなかった私の転換点でした。
初めての電話ミーティングでは震えました。


言語の問題もそうですが、 トレードステーション社の本社はフロリダ州。 日本との時差は13時間あります。(冬は14時間)
今でこそ大分体制や環境が整ってきており、 コミュニケーションも取りやすくなっていますが、 当時は時差の関係もあり、 実際に電話等でのミーティングをする時間も限られていました。


できるだけお互いに歩み寄り早朝や夜間のミーティングをセッティングしますが、プロジェクトが佳境にはいると時間が足りません。
テストついでに会社に泊まり込み、 結果について真夜中からミーティングということもありました。


海外のミーティングでは歯に衣を着せませんので、 要件等の認識が違う場合はバンバン攻めてきます。
初めのころは1時間のミーティングで45分間向こうの怒鳴り声をおとなしくきいている、ということもありましたが、 慣れてくるとこちらからも攻めるようになります。


テストの結果について意見が相違する場合など、 夜中の2時に真っ暗なオフィスの中の会議室の電話ミーティングで 英語で怒鳴りあいをするというなかなか貴重な経験もしました。
でもお互いに怒鳴りあっていいたいことをいっているせいか不思議 とわだかまりなく、翌日には普通に話すことができました。


マネックスの長所、喧嘩をしても仲がいい。


今では日本のオフィスにもエンジニアが常駐するようになり、 真夜中のミーティングはほぼなくなりましたが、 今ではいい思い出ですね。


現在トレードステーションとの合併を機に、 私の周りではグローバルな人員が増え、 今では英語で定例ミーティングしている横で、 中国語で問題対応をしていたり、 その横でスペイン語でネットワークの設定の電話をしている社員が いたりします。

また機会があれば、会社間の文化の違いや小話をご紹介できれば、 と思います。
本日のブログでは証券会社では珍しいグローバルな一面をご紹介し ました。

 

マネックスの長所、グローバル。

信頼度成長曲線の成り立ちを思い出してみた(前編)

f:id:monex_engineer:20190318165158j:plain
こんにちは。
最近こちらの会社に参りました、システム開発部の小田切と申します。

私の担当する開発が結合テストフェーズに入りました。

結合テストフェーズでは、横軸にテスト時間、縦軸に累積バグ発見数をとったグラフを作成することがあり、信頼度成長曲線と呼んでいます。S字のカーブを描くことが多いです。

形状について考察した理論があり、以下に挙げる2つが基本のモデルと解釈しています。会社によっては40年も前から、以下のどちらかやその拡張式を用いて、バグの発生状況を推定・評価しているところがあります。しかしながら、学校の授業では行わない内容の為、一部の方にしか知られていない事実もあります。

また、先に結論の式だけを提示されて、難しいと敬遠されることも多いので、昔勉強したその成り立ちを今一度書いてみようと思いました。

 

1) ロジスティック曲線モデル式

f:id:monex_engineer:20190318154218p:plain
もともとは、1800年代に人口増加のモデルとして考案された式

2) ゴンペルツ曲線モデル式

f:id:monex_engineer:20190318154240p:plain
同じくもともとは、1800年代に年齢と死亡率の関係を表した式


今回は、上記の式がどのような仮定で出てきたかの説明をしていきたいと思います。

終結果の式だけでそれぞれのパラメータを変化させると、どのように変化するかを示すサイトなどもありますが、それぞれの式が導出される微分方程式とセットにしてイメージしておく方が、より良い対応ができると思います。どのような考えで、不具合検出に対応しているかも説明したいと思います。

紙面の長さの関係から、今回はまず、ロジステック曲線モデルについて説明していきます。

ロジスティック曲線モデル

ロジスティック方程式は、1800年代に生物の個体数の変化の様子を表す数理モデルとして始まったのですが、応用として累積バグの変化の様子を表すモデルとして用いられています。


 最初に挙げた式では関数として判りやすいように、変数が発見バグ数 , 時間が となっていますが、今後は、式をイメージしやすくするため、発見バグ数を Bug 、時間を として表現してみます。


考えは単純です。バグの総数を 個(定数)として、
バグ発生の伸び率 d(Bug)/dt / (Bug) は、
未発見のバグ k - Bug に比例するとする考えです。

 バグ発生の伸び率とは、バグの時間当たりの発見率 d(Bug)/dtを、現在発見のBug数で割ったものと定義します。

比例定数を w とすると、
 f:id:monex_engineer:20190318155601p:plain

と、すごく簡単な式になっている事が判ります。
なんと、バグ発生の伸び率がバグ数の一次式で減少しているだけの式です。

α= k * w とおいて、この微分方程式を解くと、最初に挙げた

f:id:monex_engineer:20190318155800p:plain

が得られます。上記の式をよく見ると、 

を無限大にするとm * exp(-α*t) が 0 に近づくことで、分母が1になり、Bug (発見バグ数)が、k (バグ総数)に近づいていくことが判ります。

f:id:monex_engineer:20190318153111p:plain


先ほどの方程式は、
f:id:monex_engineer:20190318155933p:plain

とも書けます。この式では、バグ発見の増加率 d(Bug)/dt は、Bugの発見数に比例する項と、発見バグ数が大きくなるほど増加率を減らす項 1 - Bug/k の積に比例すると読めます。初めの頃は、Bug/kが0に近いため、Bugに比例した発見率となり、発見バグ数が k に近づくと、d(Bug)/dtは、0に近づき、Bug=k で遂に0となり、これ以上 Bugが増加しないこともイメージできます。

 
 mは先ほどの微分方程式の初期条件を与えることで決まります。しかしながら、 t=0 とすると、Bug=k / (1+m) となり、0にはなりません。テスト開始時に既にBugが発見されている事に数式上はなっていますね。

テスト前から既知のバグがあるとわかってテストを始めるのは、実態と合っているような気もしたり。。。。


さて、考えのもととなった微分方程式を見て、信頼度成長曲線のひとつのロジスティック曲線モデルが少し身近になった気がしたでしょうか。

私は信頼度成長曲線を開発で用いた後、しばらくして、元の微分方程式を見ました。こんな簡単なモデルであの難しそうな式がでたのかと驚き、かつロジスティック曲線への親しみがわいた気になりました。ゴンペルツ曲線も同じです。

ここまで書いて、昔々、私が大学生の授業で受けた教授の言葉を思い出しました。

『日本の教科書には、光は直進性があるので、影は光源と反対側にできます。』
と記述することが多いが、
アメリカの教科書には、影は光源と反対側にできています。従って、光には直進性があることが判ります。』と書かれている。

アメリカの方がより良い説明だと思う。
(昔のことで国名の記憶があやふやですが、イギリスかもしれません。)

 

与えられた理論をそのまま使用するのではなく、現象・事実から理論が生まれていることを再認識しようということですね。

皆さんも、与えられたものの起源を振返らず、こういうものだと信じていることがありませんか?チコちゃんにも叱られてしまいます。
今の環境は、開発を行っていても、今までが何となくということを振り返ることのできる会社と思っています。
これを読んでなるほどと思った方、うちに来ませんか?

次回はゴンペルツ曲線について、その元となった考えを説明したいと思います。導出方法がロジステック曲線モデルとは違った概念で、これもまた興味深いです。

 

私が昔勉強し、今回参考にした本(微分方程式の出ていた本)は、以下です。
改めてみると1981年発行でした。

参考文献:
 ソフトウェアの品質評価法(統計的管理へのアプローチ)
 三觜 武 著  日科技連出版社 1981年刊

ということで、顔写真も私の80年代の写真を使用してみました。 

 

田切 貴秀システム開発部 開発グループ エンジニア