ICTソリューション総合誌　月刊ビジネスコミュニケーション

ホーム >  要求工学 >  2006年10月号 >  第24回：信頼性要求  1  2  次へ 

概要

前回は非機能要求について紹介したので、今回は非機能要求の中でもとくに重要と考えられる信頼性要求について具体的に何をどのように記述すればいいのかを考えよう。

信頼性要求の定義

以下ではまず、代表的な要求工学やソフトウェア工学の教科書で述べられている非機能要求における信頼性の定義を列挙しよう。

Davis（D）[1]

ソフトウェアの信頼性は、「使用されることが意図された環境でユーザーが受容できる方法でソフトウェアが一貫して振舞うことができる能力である」と定義する。信頼性要求を考える４つのポイントとして、信頼性の数値が持つ意味、ハードウェアとの比較、ソフトウェアのバグ数、故障に対する相対的な影響度を示している。

◎信頼性の数値

システムが99.999％の信頼性を持つということの意味が、関係者によって異なる場合があるので数値の根拠となる単位や定義を明確にしておく必要がある。

システムが誤動作しない確率なのか、メッセージや監視データが消失しない確率なのかといった定義をしておかないと、数値がいくら明確でも信頼性を定義したことにならない。

◎ハードウェア信頼性との相違点

表１に示すようにハードウェアとソフトウェアには違いがあるので、平均故障寿命や平均故障時間間隔を用いるときは注意が必要である。

◎ソフトウェアのバグ数

ソフトウェアの信頼性をバグ密度で計測するのは一般的である。しかし、よく考えるとコード量に対するバグ数なのか、試験項目数に対するバグ数なのか、運用期間に対するバグ数なのかによって差異がある。またこれらのどの指標を用いたソフトウェアの信頼性の定義であっても、残存バグ数について明確に推定することはなかなか難しい問題である。通常は発生バグ数の累積曲線の収束状況をみるわけだが、実際のところ、そこから信頼性について何かを言明することについて難しさを感じることも多いのではないだろうか。

そこで、既知のバグを検査対象ソフトウェアに埋め込んでおき、試験時にどれだけ、既知のバグ数と未知のバグ数を検出したかを比較することで、残存バグ数を次式で推定する方法が考えられている。

残存バグ数＝埋め込みバグ数×検出バグ数／検出された埋め込みバグ数

しかし、この方法でも、どのようなバグを埋め込むのかが問題になるだろう。思いつきやすい単純なバグもあれば、複合条件の組合せに起因する想定しにくく検出しにくいバグもある。またバグを埋め込むことで、本来あったはずのバグを検出できなくなる可能性がある。さらにすべてのバグについて検出するための労力が同じであるという保証もない。

◎相対性的な影響

ソフトウェアの障害が与えるビジネスへの影響の度合いは多様である。全人類や大量の人命に係る被害、人への危害、大小の経済的被害、操作の不便さなど被害の大きさに応じた相対的な信頼性の尺度が必要になるだろう。

Gilb（G）[2]

Gilbは信頼性を性能要求の中で可用性の下位概念として定義している。システムが信頼性を満足しない状態にあるとき、システムは可用性も満足しない状態になると考える。可用性の下位概念には、信頼性のほかに保守性と整合性（integrity）を挙げている。

可用性：

システムが仕事のできる準備ができていること

概要：

可用性はシステムがどれだけ設計された仕事を有効に実行することに利用できるかを図る尺度である。

可用性には、基本品質要求と複合品質要求がある。可用性の基本品質要求の評価尺度は、与えられた仕事に対してシステムが利用できる時間間隔の割合である。これに対して可用性の複合品質要求は信頼性、保守性、整合性が含まれる。

このうち信頼性とその尺度は次のように定義されている。

信頼性：

意図されたシステム性能

概要：

信頼性は、システムが設計された動作のとおりに実行されることの程度を測る尺度である。あるいは間違った結果を提示したり、結果を提示しないなどのように、設計されていないことを実行する程度を測る尺度である。したがって、信頼性の定義はシステムがすべきであることが何かによって変化する。

評価尺度：

定義されたシステムが定義された条件の下で、定義された故障種別を経験するまでの平均時間

ISO9126[3]

前回紹介したように、ISO9126ではソフトウェア品質を測定するために機能性、信頼性、使用性、効率性、保守性、移植性からなる６項目の品質属性とその副特性を定義している。

信頼性は、指定された達成水準を維持する特性であり、「ソフトウェアがその性能を、明示された時間、維持できる度合いに関する特性である」と定義される。信頼性の副特性には、次の４項目がある。

・成熟性：

ソフトウェアのフォールト（Fault）により発生する故障（Failure）の頻度に関する属性

・耐障害性（フォールトトレランス）：

ソフトウェアのフォールトや予期しない入力があった場合でも、定められた水準の性能をどの程度維持できるかを表す属性

・回復性：

故障が発生した場合に、性能を回復し、影響するデータを復旧できる能力とそれに必要な労力に関する属性

・適合性：

標準、規約、法規、プロトコルが守られていること

Kotonya と Sonnmerville（KS）[4]

信頼性要求はシステムの実行時の振る舞いに関する制約である。信頼性要求は可用性と故障率という２つの異なる視点で考えることができる。

可用性では、エンドユーザーからの要求に対してシステムがサービスを提供できるかどうかを考える。可用性は、たとえば、「24時間で１分以内」などのように、サービスが利用できない時間の長さで表現される。

故障率では、エンドユーザーが期待するサービスを提供することに、システムがどれだけの頻度で故障するかを考える。故障率は、平均故障寿命MTTF（Mean Time To Failure）で測定される。

Pfleeger（P）[5]

性能テストで最も重要なのはシステムの信頼性、可用性、保守性を保証する品質テストであるとしている。

ソフトウェアの信頼性は、「与えられた時間間隔において、与えられた条件下でシステムが故障なしで操作できる確率である」と定義している。また、ソフトウェアの可用性とは、「システムが与えられた時点で使用どおりに操作できる確率である」と定義している。

平均故障間隔MTBF（Mean Time Between Failure）は平均修復時間MTTR（Mean Time To Repair）と、平均故障寿命を計算することにより、定義する。MTTRは、故障がソフトウェアの要素を修正するために必要な待ち時間の平均である。

MTBF=MTTF＋MTTR

信頼性と可用性に関する次のような定義もある。

・システム信頼性

R=MTBF/（1＋MTBF）

・システム可用性

A=MTBF/（MTBF＋MTTR）

この定義によると、システム信頼性は平均故障間隔が大きくなればなるほど信頼性が１に近くなる。逆に平均故障間隔が小さくなれば信頼性も低下する。平均故障間隔というのは次に同じ故障が発生するまでの平均動作時間なので、頻繁に故障が発生していると信頼性も低くなるし、平均故障間隔も短いわけである。可用性についてもほぼ同じであるが、修復するための時間MTTRを考慮しているということである。

RobertsonとRobertson（RR）[6]

パフォーマンス要件の中に信頼性を含めているが、通常は平均故障間隔MTBFで表すと述べているだけである。

Wiegers（W）[7]

システムの品質特性の中で、信頼性と可用性を示している。

可用性を、「システムが実際に使用できて完全に稼動可能な計画された動作可能時間に関する指標で表す」としている。可用性の計算式を次で定義する。

A=MTTF/（MTTF＋MTTR）

可用性を一般的な形で例示すれば、次のように記述できる。

「システムは、どこのどの時間帯で、少なくとも何％は利用できる必要がある。」

この場合、場所や時間帯ごとに可用性を定義することになる。

---

信頼性を「特定の期間、故障なしでソフトウェアを実行できる可能性」であるとしている。信頼性を測定する方法として、正しく完了する操作の割合と故障発生前にシステムが稼動している時間の平均値（平均故障寿命）を挙げている。正しく完了する操作の割合を失敗確率で表現することもできる。たとえば、次のように記述できるだろう。

「10000回の実行に対して許容される故障は３回までである。」

次のページへ