システムの開発手法として最も有名な「ウォーターフォールモデル」。
古くからある手法ですが、
現在でも採用している企業が多い開発手法です。
ではウォーターフォールモデルとはどのような開発手法なのか
見ていきましょう。
またメリット・デメリットについても解説していきます。
目次
ウォーターフォールモデル
ウォーターフォールモデルとは、
1970年に提唱されたシステムやソフトウェア開発手法です。
簡単に言うと「開発を複数の行程に分割し、1つずつ終わらしてから、次の行程に進む手法」になります。
上の図を見てもらえたらわかると思いますが、通常、開発行程を7つに分けます。
・要求定義
・基本設計
・詳細設計
・実装
・単体テスト
・結合テスト
・総合テスト
・導入
ウォーターフォールモデルは1つずつしっかり終わらせてから、
次の行程に進むのが特徴です。
例えば、「要求定義」を終わらせる前に「基本設計」に進むことはありません。
水が高いところから低いところに流れ落ちるように、
最初の工程から最後の工程に向かって順番に終わらせていくことが、
「ウォーターフォールモデル」の名前の由来になります。
ウォーターフォールモデルの開発行程
それでは開発行程について詳しく解説していきます。
要求定義
要求定義とは顧客から作ってほしいソフトウェアやシステムの要望を
聞きだすことです。
開発するシステムなどの機能、目的などを決定します。
例えば顧客情報を管理するシステムを依頼された時、
「氏名」「年齢」「住所」など、なにをデータベースに記録するのか必要な要求をまとめます。
目的の認識がズレたまま、要求定義を終わらせてしまうと、
後に響いてくるので非常に重要な役割になります。
一般的にはSE(システムエンジニア)が担当する工程です。
基本設計
顧客からの要望をまとめた要求定義を、実際にプログラミングをして、
システムにするにはどうすればいいのかをまとめたものが基本設計書です。
この工程もSE(システムエンジニア)が担当します。
詳細設計
基本設計をより具体的にしたものが詳細設計になります。
基本設計ではざっくりとしたシステムの全体像しか見えてきません。
その為、プログラマーは「基本設計書」と「詳細設計書」どちらも確認し、実装を行います。
実際にプログラムコードを記載している場合もあります。
ここまでの行程がSEの役割になります。
実装(プログラミング)
基本設計書・詳細設計書を元に
実際にプログラムをコーディングします。
今まではシステムの仕様を決める行程でしたが、
「実装」は実際に作成する行程です。
またここから後はプログラマーの役割になります。
単体テスト
実装を行った後にバグがないかチェックする工程です。
バグ(不具合)が残っていたら、不具合修正を行い再びテストを行います。
実装(プログラミング)と同時に行うことも珍しくありません。
結合テスト
ばらばらだった機能をまとめて、テストを行います。
通常、システムを作成していくときに全体を同時に作ることはありません。
例えば、顧客データを記録して本社に送信する機能を持つシステムの場合、
データを記録する機能と送信する機能を別々に作成します。
単体テストだとデータを記録する機能、
送信する機能をそれぞれテストしていきます。
その2つの機能を同時に使って行うものが結合テストです。
総合テスト
通常の単体テスト・結合テストは自社で行うテストですが、
総合テストは現地に行っておこないます。
本番環境で正しく稼働するのかチェックしていきます。
ここまで来ると、もうすぐシステムは完成します。
導入
全てのテストが終わり、実際にシステムを稼働していきます。
ここまでが一般的なプログラマー・SEの仕事内容です。
ウォーターフォールモデルのメリット・デメリット
ウォーターフォールモデルはいいことばかりではありません。
行程を遡っての変更ができないなどのデメリットも存在します。
ウォーターフォールモデルのメリット・デメリットについて、
詳しく知りたい方はこちらをご覧ください。
ウォーターフォールモデルのメリット・デメリットを解説します！
まとめ
いかがだったでしょうか。
今回はウォーターフォールモデルについて解説しました。
上流工程から下流行程に進む開発手法は、
これからも多くのIT企業で使われることが予想されます。
是非覚えておきましょう。