新しくソフトウェアを開発したい場合や、既存のソフトウェアを修正・更新したい場合は、
プロジェクトと呼ばれる一連の活動や作業の計画を立てる必要があります。
ソフトウェアを開発するためのプロジェクトを結成したとしても、肝心のソフトウェアをどうやって開発するのかが決まっていなければ、プロジェクトを結成した意味がなくなってしまいます。
今回は、ソフトウェアを開発するための手法のひとつであるウォーターフォールモデルの、
- 特徴
- 開発の流れ
- ウォーターフォールモデルを採用するメリット・デメリット
- アジャイル開発との違い
- ウォーターフォールモデルに向いているプロジェクト
について順番に解説を行います。
ウォーターフォールモデルとは？
ウォーターフォールモデルとは、開発の各工程が終了したら次の工程に進み、原則として前の工程には戻らない開発手法です。
「ウォーターフォール」とは滝のことです。
滝は上から下に水が流れ、下に流れてしまった水は上には戻りません。
滝と同じように、次の工程に進んだら前の工程には戻らないという開発の流れのため、ウォーターフォールモデルと呼ばれています。
ウォーターフォールモデルの特徴
ウォーターフォールモデルには、主に4つの特徴があります。
1.段階的な進行
ウォーターフォールモデルでは、開発は段階をふんで行われます。
- 要件定義
- 基本設計
- 詳細設計
- コーディング
- テスト
- 保守・運用
と工程がわかれており、各工程は前の工程の作業が終了したら開始します。
2.進捗は一方向のみ
各工程の作業が終了し、次の工程の作業が開始された場合は、
原則として前の工程の作業に戻ることはありません。
3.工程ごとにドキュメントを作成
要件定義では要件定義書、
基本設計では基本設計書、
詳細設計では詳細設計書、
・・・というように、各工程の作業ごとにドキュメントを作成します。
4.ソフトウェア開発の関係者とのやり取りは初期の段階のみ
ウォーターフォールモデルでは、各工程の作業が終了したら次の工程の作業を開始するという特徴があるため、
ソフトウェア開発を依頼してきた人など、関係者とのやり取りは初期の段階のみとなります。
要件定義の段階でしか関係者とやり取りをしないため、完成したソフトウェアに対して修正・変更を加えたい場合は、
再度ソフトウェア修正・変更のプロジェクトを結成する必要があります。
ウォーターフォールモデルとアジャイル開発の違い
アジャイル開発のメリット・デメリット
失敗を最小限に抑えたい！アジャイル開発とは？
アジャイル開発とは、開発→コーディング→テスト→リリースを繰り返し、ソフトウェアの修正・変更に柔軟に対応できる開発手法です。
ウォーターフォールモデルとアジャイル開発は、どちらもソフトウェア開発の代表的な開発手法ですが、次のような違いがあります。
| 開発手法 | ウォーターフォールモデル | アジャイル開発 |
| 関係者とのやり取り | 初期段階(要件定義)のみ | ひとつひとつ機能を実装後 |
| 開発プロジェクト全体の計画 | 工程ごとの開始・終了、プロジェクト全体の終了時期が分かりやすい | 修正・変更がなくなるまで開発が続くので終了時期が分かりにくい |
| ソフトウェアの修正・変更 | 別のプロジェクトを結成して対応 | その場で対応 |
ウォーターフォールモデルの開発工程
ここからは、ウォーターフォールモデルの開発工程についてひとつずつ解説します。
要件定義
システム開発における要件定義とは？必要な準備から進め方までを初心者向けに解説
要件定義では、「どのような機能のソフトウェアを開発したいのか」を定義し、ドキュメントにまとめます。
定義された要件がまとめられたドキュメントを要件定義書といいます。
- 何ができるのか
- 何ができないのか
- どのような環境で動くのか
をまとめ、要件定義書に記載します。
基本設計
基本設計とは？設計書作成時の進め方や注意点、要件定義や詳細設計との違いもご紹介
基本設計では、「ソフトウェア全体をどのような構造にするのか」を設計し、ドキュメントにまとめます。
ソフトウェアの構造がまとめられたドキュメントをアーキテクチャ設計書といいます。
アーキテクチャとは構造という意味です。つまり、アーキテクチャ設計書とは構造の設計書ということです。
基本設計のことをアーキテクチャ設計という場合もあります。
- ソフトウェア全体の構造
- 画面遷移
をまとめ、アーキテクチャ設計書に記載します。
詳細設計
詳細設計では、「ソフトウェアに実装したい機能の中身」と設計し、ドキュメントにまとめます。
機能ごとの中身についてまとめられたドキュメントを詳細設計書といいます。
- 機能の処理の流れ
- エラーが起きた場合の処理
をまとめ、詳細設計書に記載します。
コーディング
詳細設計書が完成したら、書かれている内容をもとにコーディングを行います。
詳細設計書に書かれている内容をそのままコーディングするイメージです。
詳細設計書に細かく記載するほどコーディングが楽になり、コードミスが減ります。
テスト
コーディングを行って完成したソフトウェアが、作成したドキュメントに書かれている通りに動くかどうか確認します。
機能ごとに行う確認を単体テスト、
機能と機能の繋がりの確認を統合テスト、
ソフトウェア全体の確認をシステムテストといいます。
例えば、
ロボットの「手」「腕」がそれぞれ動くことの確認は単体テスト、
手と腕をひとつに合わせて、「片腕」として動くことの確認は統合テスト、
両手両足、頭、胴体、などロボット全体が動くことの確認はシステムテストとなります。
保守・運用
どれだけ念入りにテストを行ったとしても、ソフトウェアが完成し、実際に使用している最中に、
不具合やバグが発見されてしまうことも少なくありません。
また、このような機能を追加してほしい、という希望をもらうこともあります。
そのような場合は、ソフトウェアに対して修正や機能追加を行います。
ウォーターフォールモデルでは、修正や機能追加を行いたい場合は、
修正・機能追加のプロジェクトを結成することが普通です。
ソフトウェアを問題なく使えるように、ソフトウェア完成後もサポートを行っていくことが保守・運用となります。
ウォーターフォールモデルのメリット
ここからは、ウォーターフォールモデルを採用することのメリットを解説します。
進捗管理の容易さ
ウォーターフォールモデルは、
- 要件定義
- 基本設計
- 詳細設計
- コーディング
- テスト
- 保守・運用
と工程が分かれており、かつ前の工程が終了したら次の工程に進むため、
進捗管理がしやすくなっています。
どの工程をいつまでに終わらせるのか計画を立てて実際の進捗と比べることで、
進捗が進んでいるのか遅れているのか分かりやすくなっています。
進捗が進んでいる場合は、ソフトウェアが完成する予定日を前倒しにしても良いですし、
進捗が送れている場合は、予定日の延期や実装する予定の機能を削ることが必要になります。
品質担保がしやすい
前の工程が終わったら次の工程に進むという原則のため、
その工程で求められている品質まで開発が進んだら、ドキュメントを作成し、次の工程に進む・・・という開発の流れになります。
工程ごとにドキュメントを作成するため、
後から見直した際にドキュメントがあり、品質の担保がしやすくなっています。
効率的なリソース配分
ソフトウェアを開発したい場合、
- いつまでに完成させたいのか
- どれくらい時間を使うことができるのか
の二つから、完成の予定日を決めると思います。
ウォーターフォールモデルを採用した場合は、開発工程が決まっていますので、
どの工程にどれくらい時間をかけられるのか、完成の予定日から逆算し、計画を立てることができます。
関係者とコミュニケーションが取り易い
ウォーターフォールモデルでは、関係者とのやり取りは主に初期段階で行われます。
また、各工程の作業が終了した時、作成したドキュメントを関係者に確認してもらい、フィードバックを受け取ります。
工程の作業が終了するごとに関係者と連絡を取るため、関係者の視点でも進捗が分かりやすいことが特徴です。
ウォーターフォールモデルのデメリット
続いては、ウォーターフォールモデルのデメリットを解説します。
柔軟性が低く、仕様変更が難しい
ウォーターフォールモデルは、要件定義の工程でのみ関係者とやり取りを行い、
ソフトウェアに実装する機能を決定します。
もし、要件定義の工程が終了した後、「やっぱりこの機能が欲しい」「あの機能はいらない」と要望があった場合、対応できません。
要件定義の工程で決まった機能でソフトウェアが開発されるため、後から機能の追加・削除ができないのです。
もし機能の追加・削除を行いたい場合は、新たにプロジェクトを結成して機能の追加・削除を行います。
リリースまでの時間が長い
ウォーターフォールモデルでは、
- 要件定義
- 基本設計
- 詳細設計
- コーディング
- テスト
が終了してから、ソフトウェアがリリースされます。
どのようなソフトウェアになったのか、関係者は開発の最終工程までわからないため、
想像していたソフトウェアと違った・・・となる可能性もあります。
リスクとコストが大きい
ウォーターフォールモデルは、
- 要件定義
- 基本設計
- 詳細設計
- コーディング
- テスト
- 保守・運用
の工程を順番に行います。
開発が始まってからリリースするまでの時間が長いこともあり、多大なコストがかかります。
また、要件定義や基本設計など、開発の初期の工程でミスや間違いがあった場合、
それ以降の工程すべてに影響を及ぼします。
ソフトウェアが完成してからミスや間違いに気が付いても、修正するには莫大なコストと時間がかかります。
ミスや間違いに対するリスクが大きく、開発コストが大きくなってしまうのが特徴です。
ウォーターフォールモデルとアジャイル開発の違いを比較
アジャイル開発のメリット・デメリット
ウォーターフォールモデルはアジャイル開発とどのような違いがあるのでしょうか？
- 開発工程の違い
- チーム構造と役割
- プロジェクト管理
- 受注者との関係
の4つについて、それぞれ解説します。
開発工程の違い
ウォーターフォールモデルでは、要件定義～保守・運用を、
前の工程の作業が終了したら次の工程の作業を開始するという方法で開発を進めます。
アジャイル開発では、設計～テストを行い、受注者のフィードバックを受け、
受注者の要望がある度に設計～テスト、フィードバックを繰り返すという方法で開発を進めます。
チーム構成と役割
ウォーターフォールモデルでは、要件定義、基本設計、詳細設計、コーディング、テスト、と
各工程ごとに別の人が担当します。専門職の分業が一般的です。
要件定義を行った人は、基本設計やコーディングなど、次の工程に作業が移った場合には開発に参加しないことが多いです。
アジャイル開発では、設計、コーディング、テスト、それぞれの専門職が1つのチームを構成します。
要望がある度に、チーム全員で開発を行い、柔軟に担当を変更しながら開発を行います。
設計担当がコーディングやテストに参加することもあります。
プロジェクト管理
ウォーターフォールモデルでは、初期段階にプロジェクト全体の計画を立て、その計画通りに開発を進めます。
初めに立てた計画通りに進行します。
アジャイル開発では、新しい要望があれば計画を変更し、ソフトウェアに変更を加えながら開発を進めます。
要望がある度に計画を変更します。
受注者との関係
ウォーターフォールモデルでは、要件定義の段階に受注者など関係者とやり取りを行い、要望を要件として定義します。
それ以降は、開発の進捗状況の報告は行われますが、開発されたソフトウェアが渡されるのはテスト工程まで終了した後となります。
初期段階のみやり取りを行い、作成したドキュメントを渡しつつ進捗状況の報告を行い、テスト工程の終了後に初めてソフトウェアを渡し、フィードバックを受けます。
アジャイル開発では、一つの機能を実装するごとに関係者とやり取りを行い、ソフトウェアを渡してフィードバックを受けます。
こまめに関係者とやり取りを行うので、関係者の要望通りのソフトウェアを開発することができます。
ウォーターフォールモデルに向いているプロジェクト
ここからは、どのようなプロジェクトでウォーターフォールモデルを採用すればいいのか、解説します。
大規模プロジェクト
大規模なプロジェクトでは、初期段階でおおよその計画を立て、その通りに進行していくことが理想です。
ウォーターフォールモデルでは、工程ごとに「いつまでに終了する」という計画を立て、段階的に進行していくため、進捗管理がしやすくなっています。
要件が明確なプロジェクト
ウォーターフォールモデルは、プロジェクトの初期段階で要件を詳細に定義することを前提としています。
開発が開始した時点で要件の変更が予想されないプロジェクトでは、ウォーターフォールモデルを採用できるでしょう。
命やお金に関わる重要プロジェクト
ウォーターフォールモデルでは、各工程で品質管理が行われ、次の工程に進む前に品質が確認されます。
命を守る医療機器の開発や、大金が動く金融システムなど、品質が重要となるプロジェクトに適しています。
まとめ
ウォーターフォールモデルとは、次の工程に進んだら前の工程には戻らない開発手法です。
- 要件定義
- 基本設計
- 詳細設計
- コーディング
- テスト
- 保守・運用
の工程に分かれており、各工程でドキュメントが作成されます。
全体の計画が立てやすく、品質が重要となるプロジェクトには適していますが、
要件の変更が予想されるプロジェクトでは、他の開発モデルを採用した方が良いかもしれません。
もしソフトウェアの開発を検討している場合は、株式会社Jiteraへ問い合わせを行ってみてください。
メールマガジン登録
