SRATSの使い方
ソフトウェア信頼度評価ツールSRATSの使い方がようやく分かったのでメモ。
【元ネタ】
信頼度成長曲線 - Wikipedia
SRATS:Software Reliability Assessment Tool on Spreadsheet Software
ソフトウェア信頼度評価ツール - 脱・下流エンジニア (仮)
Mantisのバグ情報から信頼度成長曲線作成ツール - Rubyの魔神 - はてな?Rubyグループ
SRATSは、広島大学の岡村さんが作ったソフトウェア信頼度(SRM)を評価するExcelマクロ。
バグ情報をCSV形式で用意さえすれば、信頼度成長曲線(SRM)を自動生成することができる。
garyoさんから、このツールの存在を教えてもらった。
信頼度成長曲線が必要な理由は、システムのリリース判定の参考資料として使いたいからだ。
つまり、システムは納品しても大丈夫な品質なのか、その意思決定をする時に数値資料として扱いたいからだ。
SRATSの最大の特徴は、SRATSマニュアルにもあるように、ソフトウェアのMTBFまで計算できる点にある。
・Total: 対象とするソフトウェアに潜在する総フォールト数
・FFProb: 現時点でフォールトがすべて除去されている確率
・MTBF: 次のフォールトが発見されるまでの時間
・Be X Life: 次のフォールトが発見される確率が0.9となる時間(その時間までに1つ以上のフォールトが発見される確率が9割)
情報処理試験の知識によれば、下記の公式が成り立つ。
MTBF=平均障害故障間隔(人時/件)
故障率=1/MTBF(件/時間)
HDDや組込み機器では、MTBFやMTBR、稼働率が製品情報として含まれている。
稼動実績からハードディスクドライブ(HDD)の環境別MTBFを割り出す ? SawanoBlog.
例えば、HDDの場合、MTBFが100時間ならば、100台のHDDのうち100時間経つと1個で故障が発生していることになる。
以下、MantisやTestLinkからSRMやMTBFを計算してみたので、その使い方をメモしておく。
僕は、信頼度成長曲線の理論的背景の知識は情報処理試験レベルなのでよく知らないので、あくまでも参考程度にして欲しい。
【使い方1~Mantisからバグ情報を作り、SRATSでSRMを出力する】
Mantisの検索一覧からCSV出力後、下記のgaryoさん作成のRubyスクリプトを使って、CSVを加工する。
Mantisのバグ情報から信頼度成長曲線作成ツール - Rubyの魔神 - はてな?Rubyグループ
そのCSVを開き、累積時間と日別バグ数の表を作る。
注意点は、時間(工数)は累積にすること。
そして、SRATSから、累積時間と日別バグ数のセル範囲を選択して、「Normal SRM」を選択後、Reportボタンを実行する。
すると、上記4種類の数値とSRMのグラフがExcelで出力される。
【使い方2~TestLinkからバグ情報を作り、SRATSでSRMを出力する】
TestLinkCnvMacroのstatisticToSheetから、テスト実施日と失敗数を切り抜く。
Mantisの時と同様に、累積時間と失敗数の表を作る。
そのセル範囲を指定して、SRATSから「Normal SRM」を選択して出力する。
【感想】
SRATSのサンプルでは、MTBFの数値が17.8と出力されて、「該当ソフトウェアは十分な信頼度を達成しているので,追加のテストは必要としない」という結論が出ている。
これでは、システムが稼動する1日を8時間と計算した場合、1ヶ月(160時間)にも満たないから、1ヶ月経つとバグが出る可能性がある。
しかし、Fault-Free Prob.(現時点でフォールトがすべて除去されている確率)は80%以上だったので、品質は確保できたと考えられる。
この結論が組み立てられた詳細な理由が分からないが、他の数値も見比べて、SRMの理論から結論付けられたのだろうと思う。
品質保証部門が社内に存在して、きちんと稼動している会社(特に組込系)では、信頼度成長曲線をリリース判定時の品質チェックに使っていると聞く。
その運用ノウハウを知りたいけれど、おそらく守秘義務としてなかなかオープンにされにくいのだろう。
しかし、昨今はMozillaやEclipseのようにオープンソースのプロジェクトで、BTSデータが公開されているので、それを使って、信頼度成長曲線などのソフトウェア工学の研究ができるようになった流れもある。
また、信頼度成長曲線の見方についても昔から異論がある。
信頼度成長曲線 - Wikipediaにも書かれているように、「収束を見る場合に、横軸に日付を使った場合、テストをしていないからバグが出ないのか、テストをしてもバグが出ないのかの区別がつかないという問題がある。」
信頼度成長曲線そのものが信用できないケースもあるからだ。
しかし、実際の現場ーリーダーならば、開発の現状を知り尽くしているはずなので、信頼度成長曲線の数値に信憑性があるかどうか、リーダー個人で判断できるはずだと思う。
SRATSを使って、どこまでシステムの品質チェックができるか試してみたい。
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか?(2026.04.08)
- PMPとCSM取得者数推移(日本 vs 中国)から読み取れる指針は何か?(2026.02.23)
- 製造業のDXを推進する部門をITコーポレート部門に割り当てるとなぜ失敗するのか(2026.02.04)
- SAFeはScrumと全く異なるアジャイル開発プロセスだ(2026.02.01)
- プ譜でプロジェクトの目的を管理する(2026.01.31)
「ソフトウェア工学」カテゴリの記事
- リプレースとアーキテクチャモダナイゼーシヨンの違いの本質は何なのか?(2026.04.08)
- アーキテクチャモダナイゼーションにおけるAMETチームの役割と責任範囲は何か(2026.03.23)
- アーキテクチャモダナイゼーションとはそもそも何なのか?(2026.03.22)
- 自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か?(2026.02.15)
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)


コメント