取り決めとは？/ セントラルファイナンス
[ 485] 取り決めモデルの概要
[引用サイト] http://www.ogis-swe.jp/process/am-res/am/artifacts/contractModel.html
|
ときには、開発するのがまったく新しい独立したシステムのことがあります。それは稀にみる幸運です。たいていの開発では、既存のレガシー情報と統合したりインターフェースをとったりする必要があるためです。レガシー情報には、既存のデータベースやファイル、既存システム、あるいは再利用可能な真新しいWebサービスといったものがあります。このページでは、レガシーシステム分析についての概要と、よく発生する問題について紹介します。 レガシーシステムを扱わなければならない場合には、開発上の制約が生じます。たいてい、新しいシステムのニーズに合わせてレガシーシステムを変更することは簡単でないため、柔軟性が低下します。たとえば、新しいシステムで必要な情報すべてをレガシーデータから取得できることは多くありません。既存データには新しい要求が反映されていないからです。同じように、再利用できそうな機能をレガシーシステムが実装していても、「あと一歩」であって、完全に事足りるわけではないことがよくあります。 アジャイルモデリング(AM)には、レガシーシステム分析に直接関係する「取り決めモデル (contract model) はきちんと定義しよう」というプラクティスがあります。システムがある情報源にアクセスする必要がある場合には、開発グループと外部のグループの間で「取り決めモデル」(外部インターフェース仕様と呼ばれることもよくあります)を作成しておくべきだ、というのがこのプラクティスの要点です。取り決めモデルの例には、アプリケーションプログラミングインターフェース(API)の詳細ドキュメント、ファイルレイアウト記述、共有データベースについてのXML DTDや物理データモデルがあります。こういったものを私が取り決めモデルと呼んでいるのは、それが実質的に、情報源の所有者とその情報を利用する外部システムの所有者の間の取り決めになっているためです。所有者がシステムを変更するときには、少なくとも事前に全員に通知しておく必要がありますし、できれば変更について相談するべきです。法的な契約と同様に取り決めモデルも、多くの場合、それなりのリソースをつぎ込んで、正確かつ十分に詳細であるよう作成、維持する必要があります。ただしこのとき、身軽な旅をするというAMの原則に準じて、システムの取り決めモデルの数を最低限にするよう気を付けてください。 たいてい、配置モデルの作成中に、利用しなければならない既存の情報源が見つかります。開発対象のシステムがやり取りする情報源それぞれについて、何らかのレガシーシステム分析を行う必要があります。運がよければ、その情報源に関する正確な文書がすでに存在します。その場合には、システムの所有者と話をし、文書に目を通して、その情報源が自分のニーズを満たしているかどうかを判断するだけで分析作業は済みます。ただしたいていは、文書がまったく、あるいはほとんど存在しないか、まるで最新状態に保たれていないことが判明するでしょう。その場合、新システムの開発者かレガシーシステムの所有者、または両方が時間を割いて、既存の情報源の分析を行い、十分な文書を作成する必要があります。このとき、所有者と緊密に協力し、関連するソースコードを詳細に調べたり、既存のソースコードをリバースエンジニアリングして文書を作成するモデリングツールを使ったり、既存の情報源を調べてどう動くかを判断したりして、既存資産を理解することになるでしょう。これは時間のかかる困難な作業になることも珍しくありません。 |
セントラルファイナンスのサイトです。
