ゴンペルツ曲線や S 字曲線で代表されるソフトウェア信頼度成長モデルはソフトウェアのテスト進捗を視覚的に表現するツールとして知られています.日本では,ゴンペルツ曲線や S 字曲線が特に有名ですが,世界的には非同次ポアソン過程(NHPP: Non-Homogeneous Poisson Process)と呼ばれる確率過程で表現されることが多く,数多くの NHPP モデルが提案されています.
実際,NHPP モデルに代表されるソフトウェア信頼性モデルは 1970 年代に初期のモデルが提案されて以来,多くのソフトウェアフォールトデータへの適合性が検証されています.しかし,実務レベルにおいてソフトウェア信頼性評価に積極的に利用されていない現状があります.この理由として,次にあげる 4 つの要因が考えられます.
1つ目の要因は,実際に記録するデータと確率モデルで使用するデータがかけ離れていることです.実際のソフトウェア開発工程では,テストを実施した日時やテストによって発見された障害をすべてを記録しています.しかし,NHPPモデルをとりまく学術的な分野では抽象的な議論が行われており,使用するデータはフォールトが発見された時間(単位を示さない)とする場合が多く見受けられます.すなわち,現場では 2003/5/5 のような年月日で管理されている記録を,ある基準日時からの累積日時へ変換する作業が必要となります.
2つ目の要因は,実際のデータに適合させるための推定手続きの煩雑さであると考えられます.確率・統計理論に基づいたソフトウェア信頼性評価では,記録したフォールトデータをもとに,モデルパラメータを推定する必要があります.これには最尤法と呼ばれる統計的な推定手法を用います.しかしながら,この作業は数学的には制約のある非線形計画問題を解くことと等価であり,数理に関する専門技術者においても,フォールトデータの種類によっては多くの労力を必要とする厄介な作業です.
3つ目の要因は,いくつかの確率モデルから適切なモデルを矛盾なく選択することが困難な点にあります.過去 30 年間に発表されたソフトウェア信頼性モデルだけでその数は 250 以上にも及びます.開発現場では,多くのモデルを比較した上で最も適合するものを選択することが理想的ですが,この作業はかなりの専門的な知識を必要とします.
最後の要因は,ソフトウェア信頼性モデル用いてどのようにして信頼性評価を行うかという点です.NHPP モデルでは,最終的にソフトウェア信頼度を通じてソフトウェアの品質を定量的に評価します.この物理的な意味は「規定の時刻までに次のフォールトが発見されない確率」ですが,開発者とってはイメージのつかみにくい尺度となっているため,信頼性尺度を出してみたもののどのような管理を行うべきかと言った問題が生じます.
これらの問題を解決し,現場で手軽に利用できる評価技術として発展するためにはツールによる支援が欠かせません.SRATS はそのような背景のもとで開発が開始されました.
SRATSのシステム開発要件は,先に述べた現状から次のように設定されています.
要件 (i) と要件 (ii) は,ともにユーザーインターフェースに対する要件です.研究レベルでは,ソフトウェア信頼性を評価するために市販されている数式処理パッケージ等を使用することが多いのですが,数式処理の利用は数学に対する基礎知識を必要とします.そこで,本ツールでは表計算ソフトウェアであるExcel を基礎とした設計を行います.Excel は高機能な GUI を持つ表計算ソフトウェアであり,統計分野においても多くの使用実績があります.また,入力書式が制限される数式処理パッケージに対して,Excel では柔軟な入力に対応しており,日付の取り扱いにも長けているため入力データの加工が容易になるという長所があります.
要件 (iii) は推定技術に関する技術です.従来から用いられている Newton 法やそれに準じた手法によるパラメータ推定では,初期値の決定に対して経験則や専門的な知識が必要となります.そこで,本ツールでは EM アルゴリズムを用いたパラメータ推定手法を採用しました.これは大域的な収束性をもつという性質から初期値の決定を神経質に行う必要がなくなり,専門的な知識なしにどのようなデータに対しても推定値の算出が可能となります.また,これは他のツールにはない SRATS の大きな特徴になっています.
要件 (iv) はモデルの分類に関する問題です.NHPP モデルは数多く提案されているため,そのすべてを網羅することは不可能です.従って,いくつかの代表的なモデルを選択する必要があります.ここでは,単一フォールトの発見時間分布がモデルの違いを表現することに着目して,フォールトの発見時間が以下の理論分布に従うモデルを扱います.
また,オブジェクト指向の設計により簡単に他のモデルを追加できる構造になっています.
要件 (v) により,既存の評価尺度が算出できるだけでなく,モデル間の比較が容易に行える構造を取り入れる必要があります.SRATS では上述したモデルをすべて評価(位相型分布はオプションで選択)し,比較できる形式できます.またモデル比較のための尺度として AIC,BIC を算出します.
要件 (vi) は,テスト進捗管理に有益な尺度として,障害件数(予測)グラフ,ソフトウェア信頼度関数,MTBF, 障害検出率関数,残存フォールト(障害)数(平均,分布)を出力します.これ以外にもユーザが必要な尺度を算出できるように推定されたモデルパラメータを出力します.