設計上の問題を解決するために

ソフトウェア設計における信頼性評価の役割

ソフトウェアの品質保証プロセスで定義すべき「ソフトウェア信頼性の概念要素」を紹介する。

公開 2009年02月05日 07時30分

更新 2012年09月04日 18時19分

著者

Zohair Chentouf

[TechTarget]

印刷する

　わたしは最近、設計上の問題について判断を迫られた。新しい機能を実装しなければならなくなったが、そのために使えそうなモジュールが2つあり、どちらかを選択する必要があったのだ。

　こうした設計上の判断は、確かな基準による評価に基づいて行わなければならない。チームリーダーたちが設計ミーティングでこの問題を議論するのを聞いたところ、チームリーダーのモジュール選択は分かれていた。彼らの主張の大部分は客観的なもので、いずれもシステム全体のリアルタイム制約や将来の保守性を考慮に入れていた。わたしは最終的にもう1つの基準を加味して、新機能の実装のために2つのモジュールのうち、どちらを採用すべきかを判断した。本稿では、こうしたソフトウェア設計プロセスへの取り組み方を説明する。

　わたしは開発と品質保証の両方のリーダーを務めており、開発業務とテスト業務の橋渡しができる立場にある。設計ミーティングにおいて、変更したいモジュールの品質について多くの情報が得られる機会がある。これは的確な判断を下すのに役立つものだ。

　多くのチームリーダーは、ソフトウェアのキャパシティー上のリアルタイムな制約と長期的な保守性を重視している。これは良い慣行だ。しかし、わたしはもう1つの重要な基準を見いだすことができた。それは「ソフトウェアの信頼性」だ。わたしが信頼性に関する情報を得たのは、常にテストプロセスに携わっているおかげだ。

　ソフトウェアの設計上の問題を解決するためには、ソフトウェアのキャパシティーや保守性、信頼性の評価をどのように総合的に考慮するのかということになる。こうした判断基準の設定の仕方は、ソフトウェア開発の背景に左右されると思う。

　わたしが自分の組織で担当しているソフトウェア開発における目的と制約は、ほかの組織のソフトウェア開発におけるそれらとは異なっている。このため、ほかの職場のソフトウェアアーキテクトは、わたしと同じように「3つの判断基準」を立てることはないだろう。わたしが選択を迫られた2つのモジュールの場合は、それらの特性に加えてキャパシティーと保守性のレベルを考えると、信頼性の方がキャパシティーや保守性よりも重要だった。さらに、2つのモジュールのうち保守性が高かった方は、連携しなければならない環境（サードパーティーのライブラリ）のせいで信頼性が低かった。

　わたしが直面したソフトウェア設計の問題を解決するには、これら3つの基準を踏まえる必要があった。だが、別の問題に取り組む場合には、ソフトウェア品質の別の要素（堅固性など）がかかわってくる。基準が何であれ、設計者はすべての基準に留意しなければならない。わたしは個人的には、基準を頭にたたき込み、おのずと判断に反映されるようにするのではなく、それらを書き留めて適宜参照する方を好む。

　ここからは、ソフトウェアの信頼性評価に話を絞ろう。前述したように、わたしは信頼性に関する情報をソフトウェアの品質保証プロセスで得ることができた。ただし、このプロセスでは、信頼性評価が直接的に行われることはあまりない。ソフトウェア品質管理者は開発の目的と制約に応じ、ソフトウェアの信頼性に関して、以下のような概念要素を定義しなければならない。

障害の深刻度は高いか、低いか
障害の影響はシステム全体に及ぶのか、局所的なものか
障害の発生確率はどれくらいか
復旧の可能性、復旧時間、復旧の度合いは完全なのか、部分的なのか

　これらの概念要素をすべて明確に定義したら、品質管理者は、それらを測定評価することを考慮してソフトウェアの品質保証プロセスを整備し、品質指標を設定しなければならない。最初の2つの項目（障害の深刻度と影響）は、バグ追跡システムで調べられそうだ。そのほかの2つの項目は、システムのログ、使用統計、顧客やβテスターの報告から導き出さなければならないかもしれない。

本稿筆者のゾハイル・チェントウフ氏はカナダのDialexia Communicationsで開発＆品質保証部門のディレクターを務め、シャーブルック大学で電気工学部の非常勤教授でもある。

印刷する