ソフトウェア工学3 ディペンダブルプロセス(dependable software processes)
前回
信頼性を得るための技術
・冗長性(redundancy)
– クリティカルな部品やサブシステムを複数利用可能状態にしておく( バックアップサーバ,多重系,RAIDなど)。一つがダウンしても別のものが使える。
・多様性(diversity)
– 同一の機能を別の方法(別のチームが開発するなどして作りが違うなど)で提供する。
– 異なるOS上での同一目的サーバの構築など
-検証を2チームにするなどの多様性の考え方もある。
※冗長性も多様性もいずれもシステム全体の複雑性を増す。
ディペンタブルプロセス(dependable software processes)
故障をできるだけ削減することが目的。
明確に定義された開発作業を「繰り返し」行えることが重要。
– 属人性を排除する
– 誰でも同じように開発
検証技術の適用
– プロセスの様々な段階でV&Vを行う
– 検証に十分なコスト(時間・人)をかける
ディペンダブルプロセスの性質
・文書化できる・されている(documentable)
– プロセスモデル,作業の目的,入出力が明確に定義されている
・標準化されている(standardized)
– 標準的な開発プロセスが決められている
・監査できる(auditable)
– 第三者によるプロセスの理解や点検,改善提案ができる
・冗長化・多様化されている(diverse)
– 冗長・多様な手段による検証作業を含む
・頑健である(robust)
– 個々の作業の失敗を回復できる
チェックする枠組みとしてCMMIやISO9000シリーズがある。
検証においては故障回避,故障検知・除去を体系的に取り入れた開発作業を行う。
リスク駆動(risk driven)要求工学
獲得されたリスクを低減する方向でシステムの要求を定義する。
安全性にクリティカルなシステム,セキュリティにクリティカルなシステムに適用する。
以下4つのステップを行う。
①リスクの同定(risk identification)
クリティカルシステムのリスクを獲得し、リスクの分類をする。サービス被害、人的被害、金銭的被害など・・。
②リスクの分析(risk analysis and classification)
リスクがどのくらいの確率・頻度で起き、リスクによりどういった障害・事故・暴露が引き起こされるかでリスクを評価する。
障害の影響と障害の可能性の2軸で評価し、リスクの重大さを分類する。
– 耐えられない(intolerable)リスク
– 可能な限り低くすべき(as low as
reasonably practical)リスク
– 許容範囲(acceptable)
③リスクの分割(risk decomposition)
個々のリスクを引き起こす要因を分析する。
故障木分析(Fault Tree Analysis)を作成するとよい。
④上記をもとにリスク低減のための見積もりと仕様化。