筆者の１人は何年か前に、リアルタイム構造化分析の手法を大規模航空管制システムの開発に実際に適用するという仕事に２年半にわたってコンサルタントとして携わった。そこで観察した事柄は非常に興味深いと同時にいらだたしいものであった。分析チームの１つは「DFD（データフロー図）チーム」で、これからの仕様記述の枠組みとなる統括的な機能分割を行うために、データフロー図を用いてプロジェクトを開始した。もう一方の「DB（データベース）チーム」と呼ばれる分析チームは、システムがそのジョブを遂行する上でひつような情報に着目して作業を開始し、情報モデル（実体−関連図あるいは意味データモデルとして知られているもの）を作成することを目指した。時間が経ってもDFDチームは、例えばある管制官が１つの航空機についての管制権を他の管制官に引き渡したときに一体どのようなことが起きるのかについての詳細といったその問題領域の基本を理解することに、引き続き悪戦苦闘していた。それとは対照的に、DBチームは、航空管制システムについて確かで深い理解を得ていた。しかし、２つの分析チームの結果は互いに噛み合わず、それどころか互いに矛盾していた。本来ならば、この２つのモデルは何とかして一致させられるべきだった。しかしスケジュールと予算の関係から、きっと設計の初期段階で不一致は解消されるだろうという希望とともに、これらの成果物が矛盾を孕んだまま基本設計に引き継がれてしまった。残念なことに、DBチームはやっかいなトラブルメーカーのように見なされてしまった。結局のところ、関係者の（そして彼らの今までの開発経験に基づく）判断は、分裂した２つの案のうちでメジャーなDFD側の混乱した解決案を買ってしまったのだ。 何年か後に同じ筆者は、連邦政府機関と州政府機関とのプロジェクトにおいても、同様の開発パターンとして観察している。スケジュールの都合と政治力をもっているという理由で、DFDチームが凱旋したのである。DBチームはかなり深いところまでよく理解し分析の核心を掴んでいたのだが、ほとんどの場合それは無視された。そしてまたもや、DBチームとそのリーダーはトラブルメーカーという烙印を押される羽目になったのである。（『オブジェクト指向分析（OOA）第２版』P.コード/E.ヨードン 1991）

こさぼのページ