Vol.5 No.1 2012

7/84

研究論文:高品質なプロジェクトマネジメントを実現するトレーサビリティ・マトリックスの構築(榮谷ほか)−4−Synthesiology Vol.5 No.1(2012)がなされるという概念である。例えば顧客領域にある要求条件という設計にかかわる情報が、機能領域における機能に対する仕様として写像され、機能を実現するという考え方である。他も同様に各領域を同じ情報が写像され、各領域で最適な形に翻訳されて処理されているのである。また、その情報の写像は双方向に発生すると考えられている。そして、この概念に3.1で抽出した要素を当てはめると次のようになる。顧客領域は顧客の要件等を指すことから、ニーズ、基本要件、要求条件という要素で構成される。機能領域は文字どおり、機能という要素で構成する。また実体領域は設計解、つまり製品自体を示すので、部品および実体という要素で構成される。そして、プロセス領域は生産条件を指すので、成果物、作業、担当という要素が構成することとなる。以上により、開発プロジェクトという組織システムのアーキテクチャが規定された。つまり、開発プロジェクトの構成要素とその関係性を明らかにすることができた。3.3 情報移転のトレースを実現する概念オブジェクト指向で分析し、抽出した要素の関係を、公理的設計の理論に基づいて関連性を整理すると図2のようになる。要求を把握するために、はじめにニーズを把握し、それを基本要件として整理し(図2では簡略化のため、この2項目は省いている)、最後に要求条件として定義する。また要求条件を実現するための機能を実装している実体が必要であり、その実体を作るためには設計内容をまとめた成果物が存在する。そして、成果物を作るための開発作業は、各担当で実行される。ソフトウエア開発プロジェクト内で写像される情報の移転は例えば以下のようなケースが挙げられる。「ユーザーID(以下UIDと記述)とパスワード(以下PWと記述)を入力時にそれぞれの入力桁数チェックする」機能を実現する場合、各機能をどのような部品にどう実装するか設計しなければならない。例えばUIDとPWに対して、それぞれ個別に桁数チェックの機能を部品として実装するのか、それとも桁数チェックは一つの部品として実装し、個々のIDチェックは同じ部品を共用するように実装するのか、どちらかの構造が選択される。それにより部品に対する設計も当然異なる。また、桁数チェック機能を共通化するならば、UIDの体系、PWの体系が明確になるまでそのチェック機能の開発に着手できない。しかし個別に実装するならば片方のID体系が明確になれば、その設計は着手可能である。このように機能や部品、作業という要素が設計情報を必要な形に翻訳し移転し、影響を及ぼしあっており、その情報の移転コストは、プロジェクトの品質にも影響を及ぼす。次にその情報移転コストについて考える。図2の左図は各要素が直線的に相互依存しているのみであるが、右図ではメッシュ構造となっている。メッシュ構造の方が複数の要素と情報をやり取りするため、多義性の例で説明したように情報移転コストもかかると考える。また図2の右図のような場合、例えば作業という要素について、その難易度が高いと情報粘着性も高まるため情報移転コストが増加する。設計書の内容をまとめるにあたって独自の表記法を用いている場合、その表記法では設計情報として表現しきれない内容があるかもしれない。その結果、設計情報が漏図2 理想的なプロジェクトと大規模且つ複雑なプロジェクトのネットワークモデル平易な要素高難易度な要素複雑な関係性シンプルな関係性理想的なプロジェクト大規模且つ複雑なプロジェクト担当(team)作業(activity)成果物(artifact)部品(component)機能(function)要求条件(requirement)

※このページを正しく表示するにはFlashPlayer9以上が必要です