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

ホーム >  要求工学 >  2012年6月号 > 要求工学手法の再利用

国立大学法人 名古屋大学 情報連携統括本部　情報戦略室　教授
（前NTTデータ フェロー　システム科学研究所長）山本 修一郎

経営工学では、ムリ・ムダ・ムラのないシステムを構築するためのエンジニアリングアプローチのことをメソッドエンジニアリング[1]というのだそうだ。ソフトウェア工学でメソッドエンジニアリングといえば、再利用によるメソッドの組立て方式のことである。本稿では、後者のメソッドエンジニアリングの観点から、本連載第89回で紹介した保証ケースのためのリスク分析手法の構築方法について紹介する。

メソッドエンジニアリング

ソフトウェア開発手法をプロジェクトに対して構築するために、従来からME（Method Engineering）や、SME（Situational Method Engineering）が提案されている[2-4]。

メソッドエンジニアリングでは、メソッドを蓄積するためのリポジトリとしてのメソッドベースを用意しておき、プロジェクトの状況に応じてプロジェクトに適したメソッドを組立てる方法が研究されている（図１）。

組立て対象には、メソッドチャンクとメソッドフラグメントがある[5]。メソッドフラグメントはメタモデルに基づいて具体化される。プロセスとプロダクトに対するメソッドフラグメントがある。メソッドチャンクは、プロセス部とプロダクト部から構成される。メソッドフラグメントでは、プロセスフラグメントとプロダクトフラグメントが多対多関係であるのに対して、メソッドチャンクではプロセスとプロダクトがチャンクの中で１対１関係にある。

メソッドエンジニアリングのための要求定義の研究[6]と、要求定義手法を構築するためのメソッドエンジニアリングの研究[7-8]がある。

◆メソッドベース

SMEでは、あらかじめメソッドベースにメソッドコンポーネントを登録しておき、プロジェクト要求に基づいて、メソッド断片を選択して状況に応じたメソッドを組み立てることになっている。メソッド構築の種類には、メタモデルからメソッドを具体化するパラダイム型、既存のメソッドを縮退、合成、パラメタ値によって変換する拡張型、既存のメソッドを再結合する組立型がある。

たとえば、Open Process Frame-work（OPF）[3]では、メソッドベースとしてOPFリポジトリが提供されている。OPFリポジトリにメソッドコンポーネントが登録されている。メソッドコンポーネントでは、作業生産物や作業などのメタモデルとその内容が定義されている。

OPFの作業生産物として、リスク分析報告、リスク管理計画、リスク監視報告が挙げられているが、要求分析に特化してはいない。また、OPFの作業単位のタスクとしてリスク管理がある。リスク管理タスクの内容として、リスク分析がある。リスク分析作業の内容として、リスクの識別、リスクの分析、リスク対策手順の構築がある。リスク対策手順では、リスクの排除、リスクの緩和、リスクの監視が提示されている。しかし、具体的な手順の内容については明確な説明はなく、技法が列挙されているだけである。たとえば、リスク分類が紹介されているが、具体的な分類方法については説明がない。

したがって、リスク分析の一般手法としては再利用できる可能性はあるけれども、リスク分析手順の具体的な内容については明確ではないので、個別に構築する必要がある。

このように、メソッドベースに必要なメソッドがコンポーネントとして登録されていない場合には、メソッドベースに必要なメソッドを改めて登録するか、メソッドベースに登録せずに直接再利用することになる。後者の方法を採用する方が、メタモデルの定義コストやメソッドベースへの登録コストを削減できるため現実的である。また、メソッドベースをプロジェクトごとに構築するための投資コストが生じることも現実には大きな負担となる。このように、現実的にはメソッドベースを前提としたSMEの導入は困難である。

BOKに基づくメソッドの再利用

筆者が参加しているDEOSプロジェクト（2011 科学技術振興機、White Paper DEOS-FY2011-WP-03J, www.dependable-os.net/ja/ topics/file/White_Paper_V3.0J.pd）では、新たなリスク分析手法を構築する必要があった。以下で紹介するこのプロジェクト事例では、メソッドベースを前提とする代わりに、PMBOKやBABOK、TOGAFなど複数の知識体系（BOK, Body Of Knowledge）を利用することにより、手法を再利用することとした。

以下では、構築対象メソッドの要求抽出、要素メソッドの選択、メソッド定義、構築したメソッドの妥当性確認という一連の再利用プロセスについて述べる。

手法の再利用プロセス

◆リスク分析手法に対する要求抽出

構築すべきリスク分析手法が満たすべき要求条件として以下を抽出した。

（要求1）要求変化に対してディペンダビリティを保証できること

（要求2）要求変化に対して合意形成できること

（要求3）要求変化に対して説明責任を遂行できること

また、DEOSプロジェクトの要求リスク分析手法の構築では、以下の２手法を利用する必要があった。

（要求4）保証ケース記述手法D-Caseを利用すること

（要求5）障害対応シナリオ記述言語D-Scriptを利用すること

（要求6）手法間に一貫性があること

要求１から要求３は、DEOSプロジェクトの要求変更管理方式から導出した[1]。要求４と要求５はDEOSプロジェクトの前提条件であった。要求６は、構築した手法自体に対する一貫性条件である。構築した手法がもし一貫性を満たしていなければ、再構築する必要がある。

◆要素手法の選択と再利用

リスク分析手法を構成する手法を選択するために、システムニーズ、ディペンダビリティ・ニーズ、システムシナリオ、逸脱、システム継続シナリオについての基本的な概念関係を以下のようにして分析した。

まず、システムニーズに対してシステムシナリオを作成する。システムシナリオの逸脱がシステムリスクとなる。逸脱がシステムニーズとディペンダビリティ・ニーズに対する脅威となる。システムシナリオの逸脱への対策を検討することによってサービス継続シナリオを作成する。サービス継続シナリオに基づいてD-Scriptを作成する。D-Caseでは、システムリスクをシステム継続シナリオによって緩和するための証跡を記述してディペンダビリティ・ニーズを達成することを保証できる。このようにして逸脱によって生じる要求変化に対して、D-Caseでディペンダビリティを保証できる。

この結果を示すと図２のようになる。この図はシステムニーズと、システムリスクに関するメタモデルであると考えられる。しかし、このメタモデルはDEOSプロジェクトのために、システムリスクについての概念モデルに基づいて新たに定義したものである。

上述した概念関係分析の結果、以下の手法が必要であることが判明した。

（手法1）要求変化に対してステークホルダ間で合意形成する手法

（手法2）説明責任を遂行するステークホルダを分析する手法

（手法3）システムリスクを分析する手法

続きは本誌でご覧頂けます。→本誌を購入する
ご購入のお申込みは電話（03-3507-0560）でも承っております。