システム 作りは、以下の手順を踏む、と一般的に言われている。

　　（1） 分析工程 （analysis）
　　（2） 設計工程 （design）
　　（3） 製造工程 （production）
　　（4） 保守工程 （maintenance）

　以上の （一連の） 手順を総括して、SDLC （System Development Life Cycle） とよぶことがある。
　SDLC のそれぞれの工程を 「凍結」 して──前の工程が完了しなければ、次の工程に進むことができない、というふうにみなして [ ただし、純粋な シーケンス （sequential) を前提にしているのではなくて、前工程の終わりのほうと次のはじめのほうが concurrent に進むこともあるが、]──順次前進するので、「waterfall モデル」 ともいうことがある。

　ちなみに、システム を作るための プロセス・モデル は、waterfall モデル のみではない。
　ほかにも、以下の モデル がある^{（* 1）}。

　　（1） 成長 モデル （evolutional model）
　　（2） 螺旋 モデル （spiral model）
　　（3） 花弁 モデル （flower model）
　　（4） 契約 モデル （contract model）
　　（5） パフォーマンス・モデル （performance model)

　成長 モデルは、ソフトウェア の性質を以下の 2つの類型として分類する。

　　（1） P 型
　　（2） E 型

　P 型とは、仕様が当初から固まっていて変更がない性質をいい、E 型とは、仕様が のちになって 変更される性質をいう。「仕様を凍結する」waterfall モデルは、P 型向きであるが、E 型向きではない。E 型 ソフトウェア の作成は、仕様を凍結しないで、変更を是認して「工程を繰り返す」 という点に特徴がある。つまり、フィードバック （feedback） を前提にした やりかた である。したがって、プロジェクト の スケジュール が組みにくい。
　現実の システム 作りでは、製造工程のなかで、仕様変更が多く起こっているにもかかわらず、waterfall モデル が使われている理由は、おそらく、プロジェクト の スケジュール を作成しやすいからであろう──とりわけ、システム 作りを請け負う ソフトウェアハウス にとって、スケジュール の作成および資源 （人員など） の割り当ては最大の配慮事項なので、waterfall モデル を使っている、というのが現状だと思う。

　螺旋 モデル は、waterfall モデル と成長 モデル を融合した やりかた である。
　[ 螺旋モデル ＝ waterfall モデル ＋ 成長 モデル ]。

　花弁 モデル は、ソフトウェア・データベース を構築する点に特徴がある。ソフトウェア・データベース のなかに 「情報 （SDLC の アウトプット）」 を集積して、その データベース を中核に置いて情報を参照・更新しながら、（SDLC の） それぞれの工程を任意に繰り返す。つまり、成長 モデル や螺旋 モデル を導入するための適用 モデル である。
　データベース を中核にして、それぞれの工程が、（データベース のまわりに） 1つずつの花びらのように輪状になって付着しているので、花弁 モデル とよばれている。

　契約 モデル は、発注者と受注者との間で合意される契約を基礎として、システム 作りの過程を管理する やりかた である。すなわち、発注者は、仕様・技術情報 （IT ミックス）・期限を示して、受注者は、成果物を納入する。

　パフォーマンス・モデル の 「パフォーマンス」 というのは、「上演」 という意味である。つまり、パフォーマンス・モデル は、演劇のやりかた を適用している。「練習・実演・反省」 という過程が繰り返される、という考えかたである。OJT （on the job training） とか 「仕事の引継ぎ」 などの技術移転を配慮した考えかたである。

　
　さて、現実の システム 作りでは、上述した モデル をいくつか混成している。たとえば、ソフトウェアハウス であれば、契約 モデル と waterfall モデル と パフォーマンス・モデル を混成している。なぜなら、契約 （請け負い）と プロジェクト 管理と技術移転は、ソフトウェアハウス にとって、仕事が成立するための最大の考慮点だから。
　ただ、悲しい現実として、契約 モデル では、アウトソーシング と称して 「丸投げ」 状態になっていて、プロジェクト 管理と称して、「多量の （too much）」 ドキュメント を作成して、パフォーマンス・モデル では、OJT と称して 「（先輩の） 経験談」 が罷り通っている。「モデル」 とは言うけれど、モデル 作成 （modeling） が技術になっていない。モデル を作るために、エンジニア の裁量が多すぎる。

　
　データベース 設計には、概念設計・論理設計・物理設計がある。
　物理設計が製造工程のなかで扱われることに対して、小生は異論がない。ただ、論点になるのは、概念設計と論理設計が、どの工程で扱われるのか、という点である。ER 手法や意味論 データベース が、「現実の事態」 を対象とした モデル （requirement model） 作成法なので、概念設計は analysis のなかで扱われ、論理設計は design のなかで扱われる、とするのが おおかたの 考えかたであろう。
　analysis 段階では、以下の やりかた が、提示されてきた。

　　（1） トップダウン 手法^{（* 2）}
　　　　 　事業モデル （Enterprise Business Model）

　　（2） ボトムアップ 手法^{（* 3）}
　　　　　 DFD （Yourdon 法、DeMarco 法、Gane/Sarson 法など）
　　　　　 decomposition （Jackson 法、Warnier/Orr 法など）

　これらの手法が特徴とする点は、「構造化概念 （structured analysis）」 である。しかも、「function」 を──「関数」 という意味ではなくて、「プロセス の作用」 という意味で使っているが──記述する やりかた である。そして、プロセス の構造化が、事業のやりかた を記述するためには、やりやすい、と思い込まれた （oversimplification） のであろう。

　1つの構造として、1つの階のなかで （leveling） 扱われる モノ は、同じ範疇の モノ （整合的） でなければならない。
　1つの アプリケーション を対象にして、1つの構造の階を整合的に作成するということが、どれほど、むずかしいことか、という点を、DFD を信奉する人たちは知らないのではないか──実際、小生は、過去 20年間、「まともに作成された」 DFD を、一度も、目にしたことがない。
　上述した構造化手法は、いずれも、1960年代および 1970年代に提示された手法である。その時代では、コンピュータ を、事業のなかで、いかに使うか、ということが論点になっていた。それらの手法が、analysis を大切にして、エンジニア の頭のなかで考えられている構造を 「可視化」 した点──だれでもが、1つの計画資料を共有する、ということ──は、高く評価できる。しかし、それらの手法は、「設計の作法 （作図記法）」 であって、「設計の技術 （抽象化手順）」 ではない。抽象化の手順自体を──つまり、モノ [ プロセス、funciton ] を認知する判断規準と、（モノ と モノ との間に成立する） 関係 [ 構造化、階層化 ] を生成する判断規準を──それらの手法は提示していない。

　1970年代には、ER 手法 （チェン氏） と セット・アット・ア・タイム 法 （コッド 氏） が提示された。ER 手法は概念設計のなかで扱われ、セット・アット・ア・タイム 法は データベース 設計論として扱われている。いずれの手法も、「モノ」 と 「関係」 を前提にした考えかたであるが、ER 手法は、モノ を 「entity （主体集合）」 として考え、関係を 「relationship （関連）」 として考える点が特徴であり、セット・アット・ア・タイム 法は、モノ を （atomic な） 「属性集合」 として考え、関係を 「relation （関数）」 として考える点が特徴である。ER 手法では、主体集合を生成する判断規準として identifier が使われ、セット・アット・ア・タイム 法では、tuple を形成する判断規準として　primary-key が使われる。いずれも、モノ を認知する判断規準を提示している。ただ、論点になるのは、identifier あるいは　primary-key として、どのような データ を使うか、という点である。

　コッド 正規形では、tuple の整合性を検証する規準として、「関数的依存関係 （functional dependency）」 が使われる。チェン ER では、しかじかの性質 （attribute） が、かくかくの主体に帰属するかどうか、という点を判断する規準はない。数理 モデル （コッド 正規形） は、認知基準も検証規準も提示できたが、関数を使ったがゆえに、（現実の データ を対象にした際に生じる） 「半順序」 が問題点になった。いっぽう、意味論 モデル （チェン ER） は、現実の事態を記述する際に、認知の規準を導入したが、（関連を記述するためには、現実の事態を対象としているので、） 関連を認知する規準を提示できなかった。

　チェン ER が、「現実の事態を記述する」 意味論の技法として、概念設計のなかで使われるとすれば、上述した構造化手法に対して、アンチ・テーゼ となる。すなわち、（システム 作りのなかで、データベース 作りを主体にして考えるなら） チェン ER を作図してから （analysis 段階）、コッド 正規形 （design 段階） を作成する、という手順になる。ちなみに、逆の手順 （コッド 正規形 → チェン ER） は成立しない。

　コッド 氏は、意味論を毛嫌いしていたそうである （小生も、意味論を毛嫌いしている）。数理 モデル を信奉する コッド 氏が、意味論を毛嫌いした理由は、おそらく、「（意味論では） 構造を検証する規準がない」 という点を嫌がったのではないでしょうか。およそ、モデル というなら、以下の 2点を実現していなければならない。

　　（1） 無矛盾性 （構造のなかで、A ∧ ¬A が起こらない、ということ）
　　（2） 完全性 （構造は、いくつかの選ばれた前提から導出される、ということ）

　チェン ER 手法が 「作図の作法」 であって、「作図の技術」 ではない、と非難される理由も──少なくとも、小生は、そう非難する一人であるが──、モデル としての 「完全性」 がないからである。
　完全性を証明するには、無矛盾ならば モデル が存在することを証明すればよい。モデル とは、Σ を T の文の集合としたら、T が Σ のなかの任意の文 φ に関して、φ は、T のなかで、真・偽のいかなる可能性に対しても、恒真 （トートロジー） であるような解釈が成立すれば、T は Σ の モデル である、という。その意味で、セット・アット・ア・タイム 法は モデル である。

　以上をまとめれば、analysis とよばれている やりかた が、いずれも、「技術」 ではない、ということである。したがって、これらを ダイアグラム の記述作法とよぶことは良いが、モデル とよぶことには、小生は合点がいかない。
　もし、それらの手法が、ダイアグラム の記述作法だとすれば、事業をやっている当人が作成すれば、（事業を知らない SE が作図することに比べれば） マシ な アウトプット が出るでしょうね。もし、契約 モデル を前提にしているというなら、エンドユーザ が仕様を ダイアグラム 形式で提示するのは当然ではないか。でも、エンドユーザ はやらない。
　では、どうして、エンドユーザ が ダイアグラム を作成しないのか。おそらく、そんな 「お絵描き」 を作成するために、仕事を離れて、労力を 「浪費」 するのが嫌だから、でしょうね。なぜなら、エンドユーザ にとっては、仕事を効果的・効率的に進めるための 「情報」^{（* 4）}があれば良いのであって、事業の構造など関心がないから。

　もし、現実の事態 （事業） を対象にしないで、「情報」 を対象にしたら、仕事自体の有用性を判断できない、というのであれば、「情報」 を使う目的を調べれば、（仕事のなかで使う情報と事業の目的とを対比すれば） 仕事の有用性を判断できる、と言っておきましょう。

　なお、小生は、job-analysis とか conceptual design に対して関心がない、という点を正直に述べておきます。

　
[ 注釈 ]

^{（* 1）}
　　これらの モデル の一覧は、以下の事典を参考にして、まとめた。
　　「コンピュータ ソフトウエア 事典」、廣瀬 健・高橋延匡・土居範久 編、丸善、平成２年

　　それぞれの モデル の詳細については、以下の文献を参照されたい。
　　- Lehman, M.M. and L.A. Belady, "Program Evolution", Academic Press, 1985.
　　- Boehm, B.W., "A Spiral Model of Software Development and Enhancement", IEEE Comuter, 1986.
　　- Dawson, M., "ISTAR--An Integrated Project Support Environment", ACM, 1987.
　　- Marks, P., "What is Leonard?", Technical Report 141-86, MCC, 1986.

^{（* 2）}
　ここでいう トップダウン 手法というのは、構造を作成する際、トップダウン のやりかたで作成する、という意味ではない。というのは、DFD も　decomposition も トップダウン 手法で作成することができるから。ここでいう トップダウン という意味は、意思決定の過程を、「戦略 （strategy）・戦術 （tactics）・業務 （operational）」 という 3 階層として考えれば、CSF （Critical Success Factor） を考慮して、戦略の観点から作成する、という意味である。いっぽう、DFD も decomposition も、operational な領域を対象にしている。
　ちなみに、ここでいう ビジネスモデル というのは、Enterprise Business Model であって、1990年代の半ば頃から注目されている ビジネス・メソッド （ビジネスモデル と一般にはよばれている） とは違う。

^{（* 3）}
　以下の文献を参照されたい。
　　- Yourdon, E., and L.L. Constantine, "Structured Design", Yourdon Press, 1975.
　　- Jackson, M.A., "Principles of Program Design", Academic Press, 1975.
　　- DeMarco, T., "Structured Analysis and System Specification", Yourdon Press, 1979.
　　- Gane, C., and Sarson, T., "Structured System Analysis", Prentice-Hall, 1979.

　ちなみに、小生は、ビジネスモデル 手法として、Holland 式を学習して、DFD では、Gane/Sarson 法を、decomposition では、Warinier/Orr を徹底的に教育された。それぞれの手法の文献も、丁寧に読んだ。したがって、それらの手法について、理論も技術も習得している。
　しかし、それらの手法を、いまでは、信用していない。
　なお、オブジェクト 指向を前提にした UML の記法については、ウェッブ 上に、数多くの情報が提示されているので、参照されたい。