【ソフトウェア開発における定量的管理①】指標による定量的管理は健康診断なのか、取り締まりなのか

指標値を定めて行う定量的管理は、達成しなければならないバーを定めて行う未達成事項の取り締まりなのか、もしくは開発プロジェクトの健全性を簡易的に把握しようという健康診断なのか、

どちらの考えも有ってよい。

達成しなければならないバーというのは、開発者にバーを意識して達成させるることで、一定レベルの維持を目指すものである。

健康診断というのは、プロジェクトマネジャー等が、開発が計画通りに進んでいるかを確認し異常や懸念を発見し対応のきっかけにするものである。

この２つの側面を両立できれば良いのであるが、この両立は単純ではない。
理由は以下の通り。
　
達成しなければならないバーというのであれば、開発者、プロマネ、品質管理担当者はそのバーを意識して活動する。
すると、以後の計測値は、そのバーを意識した結果になる。
故に、バーが実は妥当でなかった場合、関係者は、不適切な管理を続けることになる。

健康診断というのであれば、その指標値を開発者が意識した段階で、結果に作為が混入する可能性がでてくる。
作為が入った段階で、それは健康診断ではなくなる。

故に、ソフトウェア開発の定量的管理におては、達成しなければならないバーを定めて行う未達成事項の取り締まりと、開発プロジェクトの健全性を簡易的に把握しようという健康診断は両立は通常できない。

【ソフトウェア信頼度成長モデルとは何なのか】始めに帰って

結局のところ開発現場における信頼度成長モデルとは何のことでどう使うべきものだろうか。

ソフトウェア信頼度成長モデルに関する記述の始めに「ソフトウェア信頼度成長モデル」「ソフトウェア信頼度成長曲線」「バグ成長曲線」等という色々な呼び方を書いた。
また、そもそも成長曲線は寝るものであると考える人もいることも書いた。

厳密な、学問的意味でのソフトウェア信頼度成長モデルのさわりも見てみた。

その上での個人的な感想は・・・・、
学問的意味でのソフトウェア信頼度成長モデルが使えるケースより、民間療法的な使用法の方が「使える」気がする。

上手に線が描けるツールを探すよりも先に、信頼度成長曲線とは何で、どのような前提を満たした上でそれが成り立つのかを知らねばならない。

直感的に理解しやすいだけに誤用は多いであろうが、その場合は「最初は新規機能の確認でバグが多く出て、後ではレグレッションテストを行うから不具合は相対的に少なくなるので寝るんだよ」くらい大きく間違えた方が、変に前提を満たさないのにツールを使って綺麗な曲線を書いて予測するより、「開発に悪影響を与えない」使い方であると思う。

「最初は新規機能の確認でバグが多く出て、後ではレグレッションテストを行うから不具合は相対的に少なくなるので寝るんだよ」のようなあるがままのテスト状況をプロットしていく図の表し方を、「信頼度成長曲線」と区別して「バグ曲線」と呼ぶ人もいる。

「信頼度成長曲線」とは、予定調和で「寝ていたらテストを終わってよい」ということをテスト実施側と検収側が確認する為の形式的儀式という考え方もありだと個人的には思うし、それ以上の使い方は「かなりの上級者向け」であると考える。

【ソフトウェア信頼度成長モデルを少しまじめに考える⑧】信頼度成長モデル評価のための基準

書籍「ソフトウェア品質工学の尺度とモデル」には、「８．４　モデル評価のための基準」として、１９８４年に専門家のグループ(Ianninoら)が考案したという５つの基準を挙げている。
---------------------------------------------------------------------------
１．予測妥当性
２．能力
３．仮定の質
４．適用性
５．簡潔性
---------------------------------------------------------------------------
そして、本書ではその中でも、「予測妥当性、簡潔性、仮定の質」の順で重要であると強調されており、能力と適用性はそれほど重要ではないとされている。

重要な３つについて考えてみる。

○予測妥当性
　　でてきた予測が妥当でないことが明らかなものは、モデルたりえないことは明らかなのでこれは重要であろう。
　　但し、妥当か否かを判定する基準がそもそも定義することが難しいと思われるが。

○簡潔性
　　簡潔性については、この基準が考案されたのが１９８４年ということに注意が必要である。
　　確かに、収集したデータをプロットし、予測値の計算を行うことは当時のコンピュータシステムの環境では容易ではなかったと考えられる。
　　しかし、現在は、当時と比較して格段に高性能なＰＣにより、この簡潔性はそれほど重要ではないと考えてよいのではないだろうか。

○仮定の質
　　仮定の質…これを満たすことが非常な難関であることは既に見てきた通りである。
　　３つの重要な基準の中でこれが最も充足することが難しいのではないだろうか。
　　開発の実践において、十分といえる程度に充足するような仮定というものは、そもそも立てることが難しいであろう。
　　そして、統計処理に統計処理を重ねることが「指標としての価値」という点から、個別の開発の当てはめにおいて、十分活用するに足るものであるかということに、細心の注意が必要であると考える。

　　信頼度成長モデルは、一本の線で進むべき道が表示される神の啓示にみえてしまうが、本当にそうであろうか。

　　大雑把な道筋を見せてくれるだけのツールと考えるべきであろう。
　　しかし、統計的に正しいに過ぎないことなど神の啓示であるわけがない。

　　但し、使い方として、「上位管理層」「顧客」に、テストの十分性をアピールするためであれば、それはそれで意味がある。
　　「テストはちゃんとやっているよ」ということを「管理する側に」見える化するには分かりやすい図だといえるからだ。
　　この場合は、５つの基準は、ゆるやかに考えれば良い。
　　そして、「Ｊ－Ｍモデルの曲線と一致するのでテストは十分と考えます」等と言い切れば良い。

　　信頼度成長モデルを何のための活用するのかという目的に合わせた仮定の質を考えればよい。
　　実践上において仮定の質を上げることばかりに注意がいくと、本来何をするために信頼度成長モデルを活用するのかの目的を見失ってしまう。
　　ソフトウェア開発においては、ソフトウェアの開発が目的であって、信頼度成長モデルの厳密な活用が目的ではない。
　　作りたいソフトウェアのスコープからみてＴｏｏ　Ｍｕｃｈな信頼度成長モデルの適用をすべきか否かはよくよく考えるべきである。
　　これは信頼度成長モデルに限らず、仮定に基づく管理全てに言える。

【ソフトウェア信頼度成長モデルを少しまじめに考える⑦】２つ目の仮定：欠陥発見数モデルの基本的な仮定（Goel, 1985）

書籍「ソフトウェア品質工学の尺度とモデル」に挙げられている２つ目の仮定を見てみよう。
---------------------------------------------------------------------------
欠陥発見数モデルの基本的な仮定（Goel, 1985）

１．テストの時間区間は相互に独立である。
２．時間区間内のテスト作業は妥当な程度に一様である。
３．重複しない各時間区間で検出された欠陥数は相互に独立である。

---------------------------------------------------------------------------

「１．テストの時間区間は相互に独立である」
これは、信頼度成長モデルで表そうとする一連のテストの中では、複数の時間区間を入れ替えてテストを行っても結果が変わらないことを示す。別な言い方をすれば、前の時間区間内の作業を前提にして次に続く時間区間のテストが行われてはならない
ことを示す。

「２．時間区間内のテスト作業は妥当な程度に一様である」
これは、なかなか理解が難しい。
中小的に言えば、各々の時間区間における「テスト作業」の進み具合に大きなバラツキが無いことをいうのであるが、そもそも「テスト作業」とは何かの定義が難しい。
テスト作業が２時間の日もあれば、１０時間の日もあることは認めないということでもあるし、ある１日のテストケース消化数が１００個の日もあれば１個の日もあることは認めないと言うことでもある。

ここでいうテスト作業をテストに費やす時間（人時でもおそらく可）と考えれば、「妥当な程度に」というものが曖昧ではあるが、この仮定は充足可能であろう。

しかし、実際の現場では、時間区間内のテスト作業を算出するにあたって、テスト作業にそのテストのための環境設定時間は含むのか含まないのか、欠陥らしきものを発見した場合に再現テストを行った場合の時間は含むのか等、仮定を満たすためには、一々面倒な事象につき定義しておく必要がある。

「３．重複しない各時間区間で検出された欠陥数は相互に独立である」
これは、各時間区間では、他の時間区間では欠陥が発見できないことのみをテストするようにテスト設計しろと言っているわけではない。そのようなことは開発の現場では無理であるから。
理論上は無理ではないにせよ、それは、言いかえると、常に未確認の部分をテストするというのであるから、途中で曲線が寝たと言ってテストを止めてよいかは疑問が残る。
「３．重複しない各時間区間で検出された欠陥数は相互に独立である」は、実際の開発現場においては、同じ原因による欠陥は、最初に発見されたときにのみ挙げ、それ以降は挙げないと解釈すればよいであろう。