« これが『メタボリズム』だ!!~世界的に注目されたホモ・モーベンスのためのカプセル住居 | トップページ | 情報をデジタルしホモ・モーベンスとなる~愛用のデジタルペンとキンドル »

2010年3月31日 (水)

『成果物間の依存関係のエントロピー増大』~巷で氾濫する間違いだらけの要件管理・構成管理作業の実態2

このブログで以前要件管理や構成管理はソフトウエアアーキテクチャに深く結びついていることを書いた。

要件管理や構成管理は大変重要な作業であるが、原理主義に陥ると悲惨である。

重要なのは要件管理や構成管理が開発を支援する作業であり、ソフトウエアアーキテクチャの分析・設計を効果的に実施するか否かでプロセスや作業量が大きく違ってくる。

アーキテクチャ分析設計では、「開放閉鎖」原則「抽象度安定」原則や「依存環境逆転」原則などを用いて変更開所を局所化することと、クラス間及びサブシステム間依存関係を最小化することがまず重要である。

つまり、アーキテクチャが変更開所を局所化することと、クラス間及びサブシステム間依存関係を最小化することが出来ていないと、まず間違いなく成果物間の依存関係は複雑で管理が大変になっている状態と考えてよい。

言い方を換えれば、『成果物間の依存関係のエントロピー増大』を引き起こす。

アーキテクチャ設計の優れた戦略を採用し、要件管理や構成管理プロセスと合理的な相関関係が図られないと大変マズイ事になる。

ベースライン管理によって成果物の追跡可能性管理は、正当的な要件管理・構成管理を実施していても、ライフサイクルの中流から下流にしたがって大きくエントロピー増大することは避けられない。

なお、『成果物間の依存関係のエントロピー増大』とは、私が常々説明していることである。

もう1つアーキテクチャ分析設計と共に重要なことは要件定義のアプローチである。

要件定義もアーキテクチャ設計や要件管理・構成管理作業と深く結び付く。

特に製造業では「関心の分離」が重要である。

関心の分離は設計時から考えるのでは遅く、要件定義から実施した方が良い。

こちらもただ単にユースケースによる要件定義では、アスペクト指向の用語である「関心の分離」に関わる「ちらばり」「グルコード」「もつれあい」などの問題が避けられない。

1つの原因としてアリストテレスから議論されている「分類」技法の限界で、どうしてもクラスやサブシステムあるいはコンポーンネントに完璧な『同値分割』ができないという問題がある。

もっと具体的に言えば、クラスやサブシステムに対して横断的なものが存在し、1つの箇所に情報隠蔽や実装隠蔽が難しいということである。

この「ちらばり」「グルコード」「もつれあい」などの問題が、要件管理・構成管理作業に大きく影響を与え煩雑にする。

アスペクト指向とオブジェクト指向ではこの問題をどうするかということであるが、ユースケースを用いた要件定義で、ユースケーススライスを用いて関心の分離を実施する。

これはイヴァが提案したアプローチで、一緒に仕事をしたことがある。

こうすることで、拡張性や保守性および再利用性に優れたアーキテクチャ設計を支援すると同時に、要件管理・構成管理作業にも貢献することになる。

USやヨーロッパではアーキテクチャ設計に対する優れた方法論とともに、要件管理や構成管理およびテストについての事が非常に良く研究・実践されている。

重要なことは要件管理・構成管理作業だけをとらえて原理主義にならないことである。

=HSCI Takanari Hashimoto(URL:http://hsc-i.com/)=

|

« これが『メタボリズム』だ!!~世界的に注目されたホモ・モーベンスのためのカプセル住居 | トップページ | 情報をデジタルしホモ・モーベンスとなる~愛用のデジタルペンとキンドル »

「パソコン・インターネット」カテゴリの記事