開発手法について「ウォーターフォール」概要

ここで言う開発手法はプロジェクトの進め方についてです。

個人の開発でわざわざ触れるような話ではないと思うのですが、折角なので少しだけ。

細かく見ていくと沢山の手法がありますが代表的な2つの手法について

それぞれ概要、顧客目線でのメリット・デメリット、開発者目線でのメリット・デメリットなんかをまとめます。

かなり主観入るのでご指摘あればコメントお願いします。

[概要]：

以下のフェーズを上から順に実施していき、水が上から下に落ちるように逆流はあり得ないという理想的な思想。

・要件定義：

　要件のヒアリング（顧客が何をしたいのか）と仕様の策定（ヒアリングした要件をどのように実装するのか）を議論するフェーズ

後戻りが出来ないウォーターフォールモデルではこのフェーズで「やりたい事」を全て聞き出せていないと後で大変なことになる。

・基本設計：

　システムの大枠の構造を決める設計フェーズ、UI設計やデータフローとかもこのフェーズで決めてしまう。

ワイヤーフレーム等の絵が出てくるのでヒアリングの漏れとかもここでキャッチしたい。

ここでの定義がふわっとしていて漏れや誤り等があると詳細設計で大変なことになる。

最悪開発フェーズまで気づかずに炎上する。

後がないので少しでも怪しい言動があればしっかり突っ込んで「本当は何をしたいのか」をしっかり絵に起こす

「デザイン」を基本設計とするか詳細設計とするかは人によって意見分かれそう。

・詳細設計：

　システムの詳細を決める、データベースのテーブル設計やプログラムで使用する外部ライブラリ等の調査や策定なんかもここでやる。

調査するよりコーディングした方が早くねとか思うときがあるけど挫けない。

ここでの調査が甘いと開発フェーズが大変なことになる。

・開発：

　環境構築を開発に含むのか詳細設計に含むのかは意見分かれそうだけどウォーターフォールモデルではどのフェーズで遅れが出ても最終的に行きつくテストフェーズに全てのしわ寄せがいくのでやれることがあるならとっととくやるべきだと思う。

詳細設計が完全に終わってなくても開発はフライング気味に始めていいんじゃねと思う派です。

・テスト：

　　単体テスト：開発者が行うテスト（プログラムのメソッドや関数もしくはクラスやモジュール単位でのテスト）（場合によっては開発フェーズに含まれるのかもしれません。）

　結合テスト：Web系であればフロントエンド、バックエンドアプリを開発用のサーバにデプロイして行う。

　ユーザーテスト：顧客が行う（受け入れテスト）

要件と設計のズレに気づかずにここまで来てしまうと大変なことになる。

顧客からすると受入テストで初めて実際のアプリに触れるので「あれ？」と思われたら地獄の始まり。

ウォーターフォールでは逆流は出来ないので歪みは誰かが被るしかない、現場によっては醜い罪の擦り付け合いが始まる

思ったより長くなったので記事分けます。

次回はウォータフォールのメリットデメリット。