「ウォーターフォール型」開発のメリット・デメリット・開発された例

ウォーターフォール型開発とは?システムを開発するスタイル、すなわちソフトウェア開発モデルの代表例。ここでは様々な開発モデルの中でも代表的な開発モデルといえるウォーターフォール型開発の手法とメリット・デメリット、そしてその開発例をご紹介します。

ウォーターフォール型開発とは?

工程を分け、後戻りしない、最もメジャーな開発モデル

ウォーターフォール型は、システム開発を「要件定義」「外部設計」「内部設計」「プログラム設計」「プログラミング」「テスト」と各工程に分けて管理し、工程順に開発する手法です。

「要求定義」…求められるシステムの要件を定義します。
「外部設計」…具体的にどんなシステムで実装するか設計します。
「内部設計」…システムの使い勝手を設計します。
「プログラム設計」…内部設計をもとにプログラムを設計します。
「プログラミング」…プログラム設計をもとにプログラミングします。
「テスト」…作られたプログラムを段階的に統合してテストをしていきます。

まさにその名の通り、滝(ウォーターフォール)が上流から下流へと向かって流れていくように開発を進める手法です。水が逆流しないのと同じように、前の工程へ戻ることなく進めることを前提に定義されています。

ウォーターフォール型の開発例はたくさんあり、現在、最もメジャーな開発手法であるといえるでしょう。


各工程の詳しい内容を見てみましょう。

要件定義

「要件定義」では、求められるシステムの要件を定義します。

1、全体の方針を決める
何のためにシステム開発をするのか明確にし、目標を定めます。

2、業務要件を決める
新しい業務の仕組みや方法をまとめて実現すべき条件を挙げ、システム化する範囲を決めていきます。

3、機能要件を決める
そのシステムやソフトウェアで何をしたいのかをまとめる。
取り扱うデータの種類や量、画面表示や操作方法、処理する内容、出力形式などが該当します。

4、非機能要件を決める
機能面以外のシステム要件をまとめていく。
性能や信頼性、拡張性、運用性、安全性などに関する要件が該当します。


これら4つをまとめた資料は「要件定義書」と呼ばれ、顧客とシステム開発会社の双方が合意した内容をまとめた文書となります。

外部設計

「外部設計」では、ウォーターフォール型で具体的にどんなシステムで実装するか設計します。

1、画面設計をする
画面での入力や出力項目や方法、ボタンの大きさや色、配置場所などを決めて画面レイアウトを行います。また、画面の切り替え方法や表示方法についても設計していきます。

2、帳票設計をする
請求書や領収書など、用途にあった帳票のレイアウトを決めていきます。

3、外部インターフェイス設計をする
外部システムと連絡するインターフェイスを設計します。

4、データ項目を決める
どんなデータを取り扱うのか決めます。

5、データ形式を決める
扱うデータが固定長か可変長か判断します。

6.連絡のタイミングを決める
データのやり取りはいつ、どのくらいの頻度で行うのか決めます。

7、連絡方式の決定
CDなどの外部記憶媒体を用いるのか、ネットワークで伝送するのか決めます。

8、データベース設計をする
抽象化してデータモデルを作成し、データベースによってデータを管理できるようにします。

内部設計

「内部設計」では、システムの使い勝手を設計します。

1、物理データ設計をする
システム内部で利用するファイルやデータベースの項目をレイアウトします。

プログラム設計

「プログラム設計」では、内部設計をもとにプログラムを設計します。

1、クラス設計をする
プログラム全体で主となるクラスを設計します。

2、コード設計をする
システムで用いるコードを設計します。

3、規約を定める
開発規約やコーディング規約などを決定します。

4、テスト仕様書を作る
プログラミング後の単体テストの方法をまとめた単体テスト仕様書を作成します。

プログラミング

「プログラミング」工程では、プログラム設計をもとにプログラミングします。

プログラム設計をもとにコーディング規約に基づいて実装します。

テスト

「テスト」…作られたプログラムを段階的に統合してテストをしていきます。

1、単体テスト
単体テスト仕様書に基づいてテストを行います。
欠陥があった場合は内容をプログラマに伝えて修正し、再テストします。

2、結合テスト
各プログラムを統合して、プログラム間の連携がきちんと行われているか確認します。
この段階でのバグは、連携方法や制御方法に問題があるといえます。

3、システムテスト
ユーザーの環境と同等の環境でテストします。
処理速度や他システムとの連携などを確認します。

4、運用テスト
ユーザーに使用してもらい、要件を満たしているか確認してもらいます。

それでは、ウォーターフォール型開発のメリット・デメリットについて詳しくご紹介しましょう。

ウォーターフォール型開発のメリット

計画を立てやすい

前の工程から順に要求を追加していく手法のため、事前に後で必要となる事項を想定しながら開発できます。

「プログラミング」工程の前に「要求定義」と各種「設計」の工程を設けることで、効率よく開発を進め、かける時間と労力を最小限に抑えることができます。

進捗の管理がしやすい

プロジェクトの全体を把握した上で、それぞれの工程に分けて管理します。

そのため、プロジェクト全体や開発要員の進捗の管理がしやすいというメリットも挙げられます。

また、進捗状況はベンダーとクライアントの双方によって明確に把握することができるようになります。よりクライアントの期待に応えられるようになり、スケジュールが遅れる危険を低減することができるでしょう。

成果物ベースで開発できる

各工程で仕上げた成果を明確に文書化し、承認された後で次の工程へと開発を進めていくことになため、ドキュメントなどの成果物が確実にできあがります。

契約の観点から見ると、工程ごとに成果物の承認と請求をセットで設定できます。

また、どのような開発者でも文書よって成果・進捗を確認し、開発を引き継ぎやすくなります。

開発例が豊富

ウォーターフォール型開発には、たくさんの適用事例がある。ほとんどのシステム開発プロジェクトの経験者が使用したことがある手法であるため、細かな説明をしなくても理解してもらうことができるといえます。

いい方を変えれば、ウォーターフォール型でのプロジェクト管理経験が豊富なマネージャーは大勢いるので、プロジェクトマネージャーの確保がしやすいというのもメリットとして挙げられます。

品質が向上する

「要求定義」と各種「設計」が「プログラミング」工程よりも先に終わっているので、品質向上につなげることもできます。

「設計」工程で考えられる欠陥のリスクを全て挙げておくことで、すべてのコンポーネントの統合が完了した後の「テスト」工程でエラー原因を追跡する手間をより省くことができるのです。

ウォーターフォール型開発のデメリット

変更への融通がきかない

「要件定義」や各種「設計」工程では、ユーザーとの仕様検討を行ってシステム要件を詰めて行きますが、ウォーターフォール型は前工程へ後戻りしない前提であるため、その後の変更への融通は利きません。

仕様の変更や設計ミスなどによる成果物の変更が発生した場合には、プログラムの修正に加え、テストのやり直しなどが発生する場合もあります。

成果物作成の負荷が大きい

前工程の成果物をベースに開発を進められるのはメリットの1つですが、ウォーターフォール型は成果物としてのドキュメントがないと次の工程に進みません。

システムの規模が大きいほどドキュメント量は膨大になりやすく、その作成や管理稼働に大きな負荷がかかります。

工程が進んだ後に仕様が変更された場合には、その成果物のドキュメントも修正する必要があります。

WBSの作成負荷が大きい

計画の立てやすさ、進捗管理のしやすさはメリットですが、一方でデメリットとしても捉えられます。

作業項目単位で作成する必要があり、管理資料WBSの作成にも負荷が大きいのです。

さらに、スケジュールの変更があった場合には、スケジュールをもう一度立て直す必要があります。

では次に、ウォーターフォール型開発された例を見てみましょう。

ウォーターフォール型開発された例

ウォーターフォールで開発された例を見てみましょう。

ウォーターフォール型が適する条件

ウォーターフォール型は、大規模システム開発に有効とされています。
大型システムの開発は、たくさんの開発者が分担し、平行して進みます。仕様変更を想定せず、全員があらかじめ決められた方針に沿って、決められた目標に向かって作業を進められるためです。

また、ユーザの要件がはっきりと定まっているシステムの場合にも適しています。
必要な作業を順に進められるウォータフォール型を採用します。

ウォーターフォール型開発された具体例

ウォーターフォール型で開発事例としては、アクセンチュアのMethod1、IBMのADSG、富士通のSDEM90などが挙げられます。