ウォーターフォールに関する世界観です。
「平成18年度 イメージ&クレバー方式でよくわかる栢木先生の基本情報技術者教室 (情報処理技術者試験)」と「真図解 基本情報技術者 2006年春―初歩から学べて合格できる」を参考に執筆しました。
ウォーターフォールモデルは、古くからソフトウェア開発で行われてきた、もっともポピュラーな開発手法。
以下の各工程（フェーズ）を順に進めていく。
| 工程 | 説明 |
|---|---|
| １．要求定義 | システムに必要とされている機能の定義。 開発のために人員・予算を計画する。 |
| ２．外部設計 | システムの外部の姿の設計。 ユーザーインターフェースを決める。 |
| ３．内部設計 | システムの内部の姿の設計。 詳しいシステムの実装方法を決める。 |
| ４．プログラム設計 | プログラムのAPI（インターフェース）の設計。 プログラムをモジュールに分割してAPIを決める。 |
| ５．プログラミング | プログラムの実装。 コーディング（コードの記述）を行う。 |
| ６．テスト | 単独テスト、結合テスト、運用テスト。 段階的にプログラムがきちんと動作するかテストする。 |
| ７．運用・保守 | システム稼働とサポート。 顧客にシステムを使ってもらい、運用・保守する。 |
基本的に、外部的な設計（ユーザーインターフェースなど）をしてから内部の詳細を設計する。
また、全体の設計をした上でサブシステムをプログラム単位に分割する。
さらに個々のモジュールに分割し、モジュールのインターフェースを決める。
そして、コーディングを行い、最終的にテストを行う。
ウォーターフォールのデメリットとして、以下のような問題がある。
・最後の工程になるまで、システムの完成像を見ることができない。
・後々の工程になってから、前の工程に戻ってやり直すことができないため、変更が入った時に対応が難しい。
（平成18年度 イメージ&クレバー方式でよくわかる栢木先生の基本情報技術者教室 (情報処理技術者試験)を参考に執筆しました。）
（一部の記述で放送大学「情報学へのとびら ('16)」を参考にしました。）
実際のソフトウェア開発では、顧客となる会社のシステムの開発を、IT企業が請け負う形で、受託して開発します。
顧客が抱えている業務上の問題を、ソフトウェアの開発によって解決するのが、システム開発の目的です。
顧客の問題に対する要求がどのようなものであるかを定義し、要求に対してどのようなシステムを開発するべきかという「仕様」を決めるのが、要求定義の段階です。
そして、この決められた仕様について、IT企業のエンジニアは役割分担をしてシステムの開発を行います。
システムの開発には、「上流工程」と「下流工程」があります。
上流工程は、ソフトウェア開発の流れの上流にある工程のことで、ソフトウェアの全体の設計を決め、プロジェクト全体の工程を早い段階で決定する工程です。
下流工程は、開発の下流にある工程のことで、実際のソフトウェアのコーディングを行い、ソフトウェアを実際に実装して動くものにする工程のことです。
一般的に、上流工程をベテランのシステムエンジニアが担当し、下流工程を若手のプログラマが担当します。
また、重要なのはテストの工程です。プログラミングを行うよりも、テストのほうを重点的に行う場合もあります。特にゲームなどの開発では、どのようにゲームを操作してもバグが出ないよう、人間の手で入念にテストを行います。
このようなシステム開発ですが、すべてを同じ会社が行うとは限りません。大手の大企業の仕事を、「下請け」という形で小さなソフトウェア会社が部分的に委託した形で請け負うことがあるからです。
また、ソフトウェア開発の種類にはさまざまなものがあります。WebサイトやWebアプリケーションのようなホームページ制作やデザインに近いシステム開発から、工場のライン処理のような生産現場のためのシステムを作る生産システム開発のようなものもあります。
僕が思うに、ソフトウェアを開発するということは、すなわち「システムを設計すること」だと思います。
そして、このシステムは、小規模なものから大規模なものまで、たくさんの規模と種類があります。
もっとも大きなもので言えば、以下の書籍に書かれている、MITアテナプロジェクトのように、大学や研究機関のすべての教職員や学生が使うような、とても規模の大きなソフトウェア開発プロジェクトがあります。
ですが、規模の小さいものであれば、フリーソフトやオープンソースソフトウェアの開発のように、インターネット上で無料かつオープンに開発される、「個人の自由開発」のようなものまで含まれます。
このようなソフトウェアをシステムと呼び、システムを作る際の内部の決まり事の決定を「設計」といいます。
プログラムの開発においては、何よりも増してこの「設計」が重要です。設計しなければ、プログラムを実際に書くこと、すなわち「実装」することができないからです。
ウォーターフォールモデル以外にも、設計と実装の方法はあります。
ウォーターフォールでは、全体を上から下に滝が流れるように順序立てて計画しますが、元の工程に戻ることが原則できないため、急な変更に対応できません。
アジャイルのような開発モデルでは、繰り返し反復しながら開発することで、効果的にプログラムを開発します。
アジャイルの類似例として、Lispによる「プロトタイプを仕様代わりに実装する」という、ラピッドプロトタイピングという手法があります。以下の書籍が参考になります。
しかしながら、どのようにソフトウェアを開発するのであっても、設計は重要です。設計するということはソフトウェアの仕様と仕組みを決定するということであり、よく「プログラムコードを書いている時間よりもどうやってプログラムを実現するかを考える時間のほうが長い」と言われます。そのように、プログラムの内部構成を決め、システムを設計するということは非常に重要です。
2023.05.16
システム開発について言えることとして、高度なものを作ろうとしすぎると破綻する、ということが言えます。
たとえば、かつてのAppleの次世代OSであるCoplandや、MicrosoftによるWindows Vistaに搭載される予定だったWinFSなどが挙げられます。
高度なシステムの実現を目指して、多大な時間と労力が費やされたとしても、それが必ずしも成功するとは限りません。
その理由は、僕は「開発にかかる時間と手間を正確に予測するのは難しい」からだと思います。
机上の空論で、「このような素晴らしいものを作ります」ということは簡単ですが、その計画に対して果たしてどれだけの時間と労力がかかるのか、ということを、計画を実現する前の段階で予測することが難しいのです。
システム開発には、常にそのような「時間と労力を正確に予測する難しさ」が付きまとうと言えます。
実際のところ、机上の空論で高度なシステムの開発の計画を立てて、実際に開発を長い間行ったものの、開発が難航し、結果実現することができずに開発が中断されるようなことがあれば、はっきり言って金と時間と労力の無駄でしかありません。
なので、システムを開発する際には、高度なものを作ろうとしすぎないことです。UNIX哲学が語るように、シンプルこそが一番良いのです。
2023.06.12
以下の書籍が参考になります。
以下の記事が詳しくて参考になります。
アジャイル開発についてはアジャイルを参照のこと。
ユニットテストについてはユニットテストを参照のこと。
オブジェクト指向モデリングについてはオブジェクト指向モデリングを参照のこと。
Dockerも参照のこと。
会社でのシステム開発によく用いられる開発スタイル。
「要求定義」「外部設計」「内部設計」「プログラミング」「単体テスト」「結合テスト」「総合テスト」「運用テスト」「運用」となる。
途中で前のフェーズに戻ることができないという欠点がある。
ソフトウェア開発で最もよく用いられる、ポピュラーで古典的な開発モデル。