ソフト開発監査チェックリスト（９）信頼性/可用性要件管理技術
要件管理チェックリストの最初の２つは信頼性と可用性です
この記事では、ソフト開発監査に使う監査チェックリストの個々の項目についての紹介をしていきます。監査チェックリストは①開発プロセス ②要件管理 ③テスト ④設計と実装 に分かれていて、この記事では②要件管理の中の構成管理の個々の項目について紹介します。（チェックリストそのものは ソフト監査実務・チェックリストその８：開発技術・要件管理（管理全般）の記事に載っていますので、そちらをご覧下さい）
信頼性は装置が故障しない性能なのでその観点でチェックしますに
信頼性と可用性は考え方が似ているので混同し易いのですが、簡単に言うと信頼性とは装置が故障しないで動き続ける性能で、可用性は装置を使い続けられる性能です。こう書いてもやっぱり何かよく判らないですね。例をつかってもう少し具体的に説明しましょう。
信頼性とは例えば、装置が 24時間365日安定して動き続けるとか、ソフトのバグでハングアップしてもそれを検出して自己回復できるか、という様な性能の事を指します。一方で可用性とは、例えば356日連続して運転する場合には、365日の内に1回半日間は定期保守のために通常の利用を止めるので、365日の内で使えるのは 364.5日ですよとか、製品の納品の後10年間は定期的保守サービスがあるので故障しても１日以内に代替品での置き換えが可能というような性能です。
そのような性能について要求仕様書に明確に書いてあるかを確認する項目がチェックリストに並んでいます。それではまず、項目番号がRE- で始まる信頼性についてのチェック項目を紹介していきましょう。
【項目番号：RE-01】
装置や機器の全体として異常状態には、ヒューズが切れたとか基板から煙が出たとかいうハード的な故障も入ってくるのですが、ソフト的な異常状態というと機能の停止も含めてハングアップという言葉で纏められるものが多いです。そして、ハングアップのようなソフトに起因する異常が起きた時に、装置や機器としてどのように振る舞うのか、という基本方針にはその装置や機器が使われる市場や環境によって変わってきます。
異常の状態を維持してオペレータの操作を待つのか、異常状態からの自動復帰を試すのか、どのような方針で異常状態に対応するのか、基本的な方針がまずあって初めてその方針に従った具体的な設計や実装が進められます。ですので、異常状態からの回復からの対応方針は要求仕様書に明確に書かれている事が大切で、そのような点に注意して確認をしていきます。
【項目番号：RE-02】
装置や機器の異常状態からの自己回復機能として一番一般的な物がウォッチドッグによる回復処理です。そしてこのウォッチドッグによる回復処理には、①どうやって異常状態を検出するのか、と②どうやって異常状態から回復するのか、の２つの面でいくつか選択肢があります。
前者はウォッチドックの設計ではハートビート信号と呼びます。ハートビートつまり心音ですね、生きている動物なら必ず活動している心臓の鼓動音が心音ですので、ハートビートが止まったら活動が停止したと判断できます。ウォッチドッグ機能とは、このハートビート信号を常に監視していて、もしハートビートが途絶えたらワンワンと吠えたててもう一度生き返らせてくれる仕組みの事です。
コンピュータシステムでは、色々な信号の中からハートビート信号を作り出して、これを定期的に監視する仕組みを作ります。そしてハートビート信号が途絶えた事を検出したら、予め設定された方法でワンワンと吠えたててシステムの機能の回復を試みます。
ですので、ウォッチドッグの機能を搭載するのなら、ハートビート信号に何を使うのかと、システムの機能の回復のためにどんな方法を使うのかが、具体的に要求仕様書に書かれている必要があります。 そのような点に注意して確認をしていきます。
【項目番号：RE-03】
前項の RE-02 は装置や機器全体としてのウォッチドック機能の仕様についての確認だったのですが、ソフトの規模が大きくなってくると、個々の機能毎にウォッチドッグ機能を搭載するという考え方もでてきます。複数の機能を提供していてそれぞれの機能の独立性が高い場合、１つの機能だけが機能停止に陥っているのなら、その機能のみを再起動するなどして回復させれば、他の機能への影響を最小限に留める事もできます。
そのような考え方から、ソフトウォッチドックの機能を搭載する場合もあるのですが、この場合にも何をハードビート信号にするのか、回復処理としてどんな方法を使うのかが、要求仕様書に書いてある必要があります。そのような点に注意して確認をしていきます。
【項目番号：RE-04】
組み込み系の装置や機器の場合、ソフトの実態である実行プログラムは内蔵するフラッシュメモリやハードディスクに記録されています。そして、電源を入れた時にソフトが装置や機器のメインメモリへと読みだされて必要な機能の提供を始めます。
このフラッシュメモリやハードディスクは、書き換えが可能な媒体ですので何等かのソフトウエアのバグで書き壊されてしまう事もあり得ます。また周囲環境にもよりますが、長時間高温にさらされると記録していた内容が消えてしまう事もあります。そうすると、装置や機器の電源をいれても正常に動作しなくなってしまいます。
その様な事を避けるために、同じソフトを２か所に記録しておき１か所がダメだった時にももう１か所のバックアップから読みだして動作を続ける機能を搭載する事も良くあります。これがファームウエアの２重化ですが、この時には２重化をするソフトの範囲や２重化したソフトの更新の方法などを要求仕様として具体的に書いてある必要があります。どれだけ具体的に書いてあるのか、という点に注意して確認をしていきます。
可用性は装置を使い続けられる機能に注目してチェックします
可用性とは、文字からも読み取れるように用いる事が可能な性能です。 って、これではなんの事かわっぱり判りませんね、では自動車を例に可用性を考えてみましょう。自動車は普通は２年に１回車検が要りますが、この車検に５日間自動車を整備工場に預けると想定しましょう。すると２年間＝365日X2 =730日 の内で5日間は自動車が使えないという事になります。という事は、この自動車を用いる事が可能なのは 730日のうち 725日なので、可用性は725/730 = 99.3 % となります。
つまり可用性とは、故障等で異常な状態が起きない場合にその装置や機器をどの程度用いる事ができるかという性能です。逆の言い方をすれば、装置や機器の正常な機能を維持するために必要な期間を差し引いた時間がどれだけ多いか、という性能ですね。そのような可用性が要求仕様書に具体的に書かれているかを確認するのがこのチェック項目で、項目番号がAV-で始まる4項目です。
【項目番号：AV-01】
可用性を考える時のベースとなるのは、その装置や機器が連続して動作をする時間です。ネットワークの局側設備なら24時間365日の連続稼働が必要ですが、炊飯器なら炊飯１時間に保温3日が上限として、37時間です。可用性を考えるときには、装置が連続して動き続ける必要のある時間を100として、正常に使い続けるために必要な保守等の時間を差し引いた時の実際に動き続けられる時間が何％になるか、という見方をします。ですので、まずはその分母となる連続して動き続ける必要のある時間を確認する事が大切です。これは、要求仕様書に具体的に書いておく必要があり、そのような記述があるかどうかを確認します。
【項目番号：AV-02】
可用性を考える時に次に必要なのが、予め計画された保守のために必要な時間です。自動車でいうと車検にかかる日数ですね。この保守時間を差し引いた時間が、実際に装置や機器を使える時間なので、可用性はこの保守時間でほぼ決まるような物です。
ネットワークのバックボーン設備だと 24時間365日の稼働が必須なので、保守時間は０ですね。そのような設備は保守していても機能が動き続けらえれるように、２重系で作られています。２重系の１系統で運用を続けていれば、もう１系統でを保守していても問題は無いですんえ。
一方で、例えばTVの放送設備等は、最近では24時間連続して放送をするTV局もありますが、一般的には深夜になると放送を終了して数時間放送が無い時間（停波時間と言います）があって、早朝からまた放送が始まります。放送設備の停波時間が１時間だとして、この時間に毎日１回１時間の保守が必要だとすると、実際の放送には影響はないのですが、1日あたりの可用性は 23時間/24時間 と考える事もできます。
このように、可用性を考える時の元の情報となる保守時間も要求仕様書に明記されている必要があるので、その状況を確認します。
【項目番号：AV-03】
前の項目のAV-02は正常な保守の時間についての確認項目ですが、それ以外にも可用性の計算に関係する時間もあります。例えば装置や機器に何かの異常があってハングアップした時に、ウォッチドック機能が働いて再起動による自動復旧が実行されるように作ってある場合を考えましょう。
この再起動に４時間かかるとして、１年に１回そのような自動復旧処理が実行されると仮定すると、１年あたり４時間装置や機器を用いる事のできる時間が減る事になります。ですので、異常状態からの復帰に必要な時間も、可用性を判断する時に必要ですので、要求仕様書の記載の状態を確認します。
【項目番号：AV-04】
可用性を判断する時の考え方にはもう１つあります。それは、同じ装置でもソフトのバージョンアップ等で機能を追加していく事で、長年に渡って使い続ける事が可能な場合があります。販売当初の機能のままでは７年間程度しか使えなかったものが、その後のソフトのバージョンアップであと３年は使えるようになったとすると、使える期間が延びた事になります。
これもある意味で可用性なのですが、このように装置や機器の販売の後で、その機能や性能を拡張して製品の寿命を延ばす事ができるようになっているかどうか、という点も可用性として要求仕様書に改定ある内容を確認する項目になります。
可用性の次は保守性です
可用性の確認の次は保守性についての確認項目について、次の記事で紹介します。