From: リスキルテクノロジー 松田航
新宿本校にて、、、
システム開発の手法はさまざまありますが...
「ウォーターフォールモデル」
...という開発手法がほとんどの開発で採用されています。
古くから開発手法であり
他の手法もあるにもかかわらず、現在でも主流の開発手法です。
ウォーターフォールモデルの進め方、
そしてメリットやデメリットなどについて、
少し詳しく説明しましょう。
ウォーターフォールモデルとは？
上流工程から下流工程までの特徴
ウォーターフォールモデルは
1970年に提唱されたソフトウェア開発手法。
開発を複数の工程に分け
各工程の終了時に成果物を作成することにより、
各工程における品質の確保を図ります。
ウォーターフォールという名は文字通り
「水が流れ落ちる」様に工程が進むことから名付けられており、
上流工程から下流工程まで流れる様に開発が行われます。
ウォーターフォールモデルの各工程については
当ブログでも何度かその名が登場しておりますが、
少し細かく説明しましょう。
(1)要件定義
ウォーターフォールモデルにおける最上流工程。
開発するシステム全体の機能を
ユーザーとの打ち合わせを重ねて具体化し、
開発するシステムの機能、目的、対象範囲を決定します。
システム開発を依頼するということは、
ユーザー側に「業務をもっと円滑にしたい！」など、
業務改善の為に何らかの対策をしたいという目的があるということ。
その目的の認識がズレたまま開発が進むと
下流工程に進むに従い、大きな認識違いが発生します。
どのようなシステムにしたいか？
システム化対象範囲やシステム導入によって業務がどう変わるか？
システムと業務の具体的な分析が必要となるフェーズです。
(2)基本設計
システム開発をするにあたり
要件定義フェーズで決定された事項を具体化するフェーズです。
主な設計内容としては...
・ハードウェア、データベース、ソフトウェアの選定
・データベース設計、テーブル設計
・システム、サブシステムの機能概要の設計
・インプット、アウトプット内容の決定
・データ移行・運用・セキュリティ方針の検討
・外部システムとの連携方法の検討
・システム内部で使用する区分の決定
...などが挙げられます。
データベース設計を行うことから
ある程度データ管理する項目も把握されるため、
画面や帳票などのサンプルを作成し、
ユーザーに見てもらってフィードバックする場合もあります。
(3)詳細設計
基本設計フェーズで決定された事項を
画面単位、帳票単位、プログラム単位など
より詳細に機能分割して設計するフェーズです。
主な設計内容としては...
・画面、帳票のレイアウト及び機能設計
・バッチ処理（自動実行処理）の設計
・メッセージ仕様（画面などに表示する内容）
・データベース設計（表領域、ファイルサイズなど詳細な設計）
・クラス設計などのプログラム設計
・システムで使用するコード設計
・開発規約、コーディング規約などの検討
・単体テスト仕様書の作成
...などが挙げられます。
基本設計では見えていない要件や
基本設計段階ではまだ不完全なものがあれば
詳細設計フェーズで修正を行い、仕様を確定させます。
このフェーズで作成されたドキュメント群を
「詳細設計書」と総称しますが、この詳細設計書をもって、
次の開発フェーズで実際にプログラミングが行われるのです。
(4)製造（プログラミング）
詳細設計書を元に
実際にプログラムをコーディングします。
作成する単位は画面、帳票、バッチプログラム単位ですが、
共通的に使用するプログラムがある場合は、先にそちらを作成します。
ほとんどの場合は製造と、
次のフェーズである単体テストを同時に行うケースが多いです。
(5)単体テスト
作成したプログラムに対し
単体テスト仕様書を元にテストを行います。
簡単なテストの場合はテストスクリプトを作成し
自動テストツールでのテストを行って効率化を図ります。
テスト結果で不具合があった場合は
不具合内容をプログラマに伝えて修正して再テストを実施。
全てのテスト項目が終了したら、
次の結合テストフェーズに移ります。
(6)結合テスト
各プログラムを統合し、
画面遷移やデータの受け渡しなど、
画面・プログラム・サブシステム間の連携が
正しく行われているかどうかを確認します。
具体的には業務フローを元に
実際の業務を想定したテストシナリオを作成し...
最初のインプットから
想定できる結果が正しくアウトプットされるか等のテストを実施。
単体テストでは問題なかったが、
連携方法や制御方法にバグがあった場合は
このフェーズで発見されます。
(7)総合テスト（システムテスト）
実際にユーザーの環境と同じか
それと同等の環境において行うテスト。
主に処理速度や障害発生時の処理、
実際の他システムと連携して正しく動作するかなどをテストします。
(8)運用テスト（受け入れテスト）
総合テストをパスしたシステムを
実際にユーザーに使用してもらい、
要求機能を満たしているか、操作感はどうかなどを確認してもらうフェーズ。
旧システムでインップットした内容が
新システム側でも旧システムと同じアウトプットかなども確認します。
(9)リリース
新システムを本番環境にリリースします。
リリースの方法についてはいくつかの方法がありますが、
以前ブログで書いておりますのでここでは割愛致します。
(10)運用・保守
システムの運用、保守を行うフェーズ。
実際に新システムを使用していて
不具合があった場合は速やかに修正を行ったり、
新しい機能要求が挙がった場合には
追加開発などを行ってシステムの保守を行ったりします。
少し説明が長くなりましたが、
ウォーターフォールモデルは、このような流れで進行するのです。
ウォーターフォールモデルの
メリット・デメリットとは？
ウォーターフォールモデルの
メリットとデメリットをまとめると以下の様になります。
■メリット
・計画を立てやすい
上流工程から要求機能を
詳細に落とし込む手順を踏んでゆくため、
事前に今後必要となる事項を想定しながら開発できる。
・進捗管理のしやすさ
全体を把握した上で
工程別・タスク別に管理可能なことから、
プロジェクト全体や、各開発要員の進捗管理を行いやすい。
・成果物ベースでの開発
ドキュメントなど成果物がある状態で開発を行うため、
どのような開発者でも仕様書を読めば開発する事ができる。
■デメリット
・上流工程でしか要件定義できない
要件定義や基本設計フェーズでは
ユーザーとの仕様検討を行いシステム要件を詰めますが...
仕様検討したのは「過去」の時点のものであるため、
企業のスピード感が早い場合、仕様変更が発生する可能性が高くなります。
・仕様変更時の影響
前工程の成果物をベースに開発を行いますが、
仕様変更や設計ミスなどによる成果物の変更が発生した場合...
プログラムの修正はもとより、
変更内容によってはテストのやり直しなどが発生するケースもあります。
・成果物管理の稼働負荷
成果物ありきで開発が進められるため、
ドキュメントなどの成果物の作成・修正稼働に負荷がかかるのが特徴。
ウォーターフォールモデルには、
この様なメリット、デメリットがあるのです。
ドキュメントによる品質・工程管理
しかしそれは両刃の剣にも成り得る可能性が？
ここで、メリットにもデメリットにも登場した
ウォーターフォールモデルにおける成果物（ドキュメント）管理について、
もう少し詳しくお話ししましょう。
ウォーターフォールモデルは
ドキュメントの作成量が多いことが有名です。
各開発工程の最後には
成果物として設計書やテスト結果報告書など
さまざまなドキュメントをユーザーに提示します。
提示したドキュメントを
ユーザーが承認することによって、
開発側は次の工程に進むことができるのです。
実際には納期が短く、
ドキュメントは後から提出して、
できるだけ早く工程を進めて行くというケースもありますが...
ウォーターフォールモデルは
前工程の成果物ありきで進められるので
ドキュメントがないと先々の工程に進みにくい性質を持ちます。
そして大規模なシステム程
ドキュメント量が膨大な量になる傾向があり、
その作成や管理稼働に大きな負荷がかかってしまうのです。
工程は進んだものの、
後になって要求仕様が変更された場合には
多くのドキュメントを修正する必要があります。
また、ウォーターフォールモデルの特徴として
計画の立てやすさ、進捗管理のしやすさがありますが、
これらの管理資料の作成だけでも、かなりの稼働がかかってしまいます。
代表的な管理資料としては
WBS（Work Breakdown Structure）といい、
開発プロジェクトを細かい作業項目に分割し、
誰が、何を、いつまでに対応するか、進捗率はどうかなど、
開発計画や実績を把握できる資料を作成してプロジェクト管理を行います。
しかし、
作業項目単位で作成する必要があるため
WBSを作成するだけでもかなりの稼働負荷がかかりますし...
ユーザーの都合でスケジュール変更があった場合には、
その変更内容を反映し、スケジュールを組みなおす必要が発生します。
このように、ウォーターフォールモデルでは
ドキュメントによる品質・工程管理が行われますが、
逆にドキュメントに対する稼働負荷が高いという特徴もあるのです。
多くの開発現場で採用される基礎的手法
基礎力を身に付けておけば、他の開発手法でも対応可能
ウォーターフォールモデルは
大規模開発向けの開発手法と言われています。
その理由は、
きちんと何もかも整えた状態で
プロジェクト全体や各開発者の進捗管理ができる為です。
にもかかわらず、
実際には規模の大小を問わず
ほとんどの開発案件で採用され続けている手法。
それは一体なぜなのでしょうか。
理由はいくつかあり、
長年多くの技術者がこの開発モデルを経験し
ノウハウを持っている技術者が多いというのもありますが...
もうひとつ...
「成果物と一緒に費用を請求しやすい」
...という点も挙げられます。
大規模な開発になればなるほど、
開発期間は長期にわたりますので、
全て納品してから請求･･･となると、運転資金が調達できません。
そこで採られる方法が「分割検収」という方法。
全体の見積もり金額から、
要件定義の成果物を納品したら○万円請求、
基本設計～詳細設計までの成果物を納品したら○万円請求...
...というように、フェーズの終了毎に請求を行います。
企業側は開発者に給料を支払わないといけませんので、
資金繰りもしやすいこの手法が採られるケースが多いのです。
しかし、
最近ではユーザーのスピード感は増す傾向にあり、
実際には柔軟に仕様変更を行いたいユーザーが多いのも事実。
既にご説明したとおり、
ウォーターフォールモデルには
柔軟な仕様変更を可能とするスピード感に欠けるというデメリットがあります。
そこで登場したのがアジャイルなど、
ウォーターフォールとは異なる開発手法ですが、
最近ではウォーターフォールとアジャイルを組み合わせるような
ハイブリッド型と呼ばれる開発手法も存在します。
アジャイルやハイブリッド型については
また別の機会にご紹介しますが…
ウォーターフォールモデルは
開発手法の「基礎」とも言えるものですので、
各フェーズで行う作業内容は把握しておきましょう。
他の開発手法を見ても、
開発の進め方は異なりますが、
内容としてはウォーターフォールモデルの
各フェーズを分解・再構築して手順を変えたものが多いです。
ウォーターフォールモデルは、
IT技術者になれば、必ず1度は経験する開発手法。
開発の基礎。しっかり習得しておきましょう。
リスキルテクノロジー
松田
PS
ウォーターフォール型を実践できる
開発演習を含んだコースが多数あります。
コメント