ウォーターフォールモデル

開発

ウォーターフォールモデルとは?

 状態:-  閲覧数:2,144  投稿日:2011-07-09  更新日:2017-10-08  
英語表記
・Waterfall Model

1970年に提唱されたソフトウェア開発手法
・システムの開発手順を示すモデルの一つ
・古くからある開発手法で適用事例が多い
・ソフトウエア工学において、基本になる考え方
・ソフトウェア開発方法論の1つで、最も基本的、一般的な開発モデル
・ソフトウェア工学では非常に古くからある、もっともポピュラーな開発モデル

大規模システムで採用されることが多い
・ある程度規模が多いシステム開発において採用されることが多い
・メインフレームを中心とした大規模システムの開発では、標準的なアプローチとして多くの技術者に受け入れられてきた

工程を時系列に分割して管理する
・段取りをきちんと踏んだ開発モデル
・システム開発全体を工程(フェーズ)に分割して管理
・作業工程を分割し、分割した工程を順序だてて実施する
・システム開発における各工程を順番に進めていく開発手法
・システム開発プロジェクトを工程別に管理する開発手法・工程管理手法
・開発を複数の工程に分け、各工程の終了時に成果物を作成することにより、各工程における品質の確保を図る
・開発作業をいくつかの工程に分け、各工程での成果をドキュメントにまとめて明確にしてから次の工程へ進む
・プロジェクト全体をいくつかの工程に分割し、各工程での成果物(仕様書や設計書などのドキュメント)を明確に定義し、その成果物に基づいて後工程の作業を順次行っていく開発モデル
・線表(ガントチャート)を使用してこれらの工程を一度で終わらせる計画を立て進捗管理をする

前工程が完了してから後工程を開始する
・各開発フェーズにおいて、一つ手前のフェーズで作成した成果物(アウトプット)が、次フェーズの入力物(インプット)になる
・開発フェーズの完了をもって次のフェーズに着手していく
・各工程が終了したら緻密なチェックを行ってから次の工程に進む
・原則として途中で工程をさかのぼることはない

前のフェーズのアウトプットに不備があった場合
・次フェーズを満足に遂行することはできない
・必ず前のフェーズに戻って、仕様検討や設計をやり直すことになる
・原則として前工程が完了しないと次工程に進まない(設計中にプログラミングを開始するなどの並行作業は行わない)ことで、前工程の成果物の品質を確保し、前工程への後戻り(手戻り)を最小限にする

上流から下流へと一方向に進む水の流れのようにソフトウエアの開発を進めることからこの名称がある
・その名の通り水が上流から下流へ流れる様子を、そのままシステム開発のモデルに名づけたもの
・開発の手順を複数の工程に分割し、滝の水が上から下に落ちるように、上位の工程から順に開発を進めていく手法のこと
・文字通り「水が流れ落ちる」様に工程が進むことから名付けられており、上流工程から下流工程まで流れる様に開発が行われる
・水が上流から下流に戻ることなく流れていくように、ウォーターフォールモデルでも原則的に各工程は戻ることなく進んでいることを前提に定義されている



開発工程区分 /導入メリット / 導入デメリット

 閲覧数:466 投稿日:2017-09-30 更新日:2017-10-09 

開発工程区分


一般的には、要件定義、基本設計、詳細設計、プログラム開発、テスト、運用、保守の順に開発工程を区分する
・システムの要件定義から設計、製造、テストまで、各開発フェーズを段階的に進めていく開発モデルを指す

各工程の呼び方はプロジェクトにより異なる
・プロジェクトごとにどの用語がどのフェーズに該当するのか良く確認する必要がある

システム開発の時系列工程分割例A
・1.要件定義
・2.外部設計
・3.内部設計
・4.製造・実装
・5.単体テスト
・6.結合テスト
・7.総合テスト
・8.ユーザーテスト
・9.本番移行
・10.運用・保守

システム開発の時系列工程分割例B
・1.要求定義
・2.外部設計(概要設計)
・3.内部設計(詳細設計)
・4.開発(プログラミング)
・5.テスト
・6.運用

システム開発の時系列工程分割例C
・1.要件定義(要求分析)
・2.外部設計(基本設計)
・3.内部設計(機能設計)
・4.詳細設計(プログラム設計)
・5.プログラミング(製造、実装、コーディング)
・6.テスト


導入メリット


工程の進捗管理がしやすい
・システムの全容を早い段階で明確にできる
・開発の進ちょく状況を把握しやすく、プロジェクト管理に向く

ユーザーのニーズをシステムに具現化し、かつ全体の整合性を保ちやすい
・仕様書が確実に残る
・処理性能を満たすための設計作業を確実に盛り込める


導入デメリット


開発期間は長くなる
・工程ごとにドキュメントを作成したり、各工程を別々のチームが担当することが多いので成果を引き継ぐ作業が発生する
・このため一般に、スパイラルアプローチに比べて開発期間は長くなる

仕様の変更や修正が発生した場合
・工程を逆戻りすることが難しいため、期間と費用が多くかかってしまうことがある

システム開発全体のスケジュールを圧迫する一番の要因


・前工程へ後戻りすると大きな影響が出る
・前のフェーズのアウトプットに不備があった場合
・次フェーズを満足に遂行することはできないため、前のフェーズに戻って、仕様検討や設計をやり直すことになる

1.要件定義(要求分析)

 閲覧数:397 投稿日:2017-09-30 更新日:2017-10-09 

ウォーターフォールモデルにおける最上流工程


ユーザーの要求やシステムの要件を定義
・顧客がシステム化したいビジネスモデルの全体像を、要件定義書へ記述
・開発するシステム全体の機能をユーザーとの打ち合わせを重ねて具体化し、開発するシステムの機能、目的、対象範囲を決定する
・システム開発全体の根本的な仕様は、要件定義フェーズで決定され、それ以降の開発フェーズにおいても元を辿ればこの要件定義に基づいた開発を行う


2.外部設計(基本設計)

 閲覧数:396 投稿日:2017-10-04 更新日:2017-10-10 

概要設計


システムの使い勝手や他システムとのやり取りを設計
・システム開発をするに辺り、要件定義フェーズで決定された事項を具体化するフェーズ
・データベース設計を行うことからある程度データ管理する項目も把握されるため、画面や帳票などのサンプルを作成し、ユーザーに見てもらってフィードバックする場合もある

主な設計内容
・ハードウェア、データベース、ソフトウェアの選定
・データベース設計、テーブル設計
・システム、サブシステムの機能概要の設計
・インプット、アウトプット内容の決定
・データ移行・運用・セキュリティ方針の検討
・外部システムとの連携方法の検討
・システム内部で使用する区分の決定




3.内部設計(詳細設計)

 閲覧数:385 投稿日:2017-10-05 更新日:2017-10-11 

機能設計(プログラム設計)


外部設計を具体的にどうシステムで実装するか設計
・基本設計フェーズで決定された事項を、画面単位・帳票単位・プログラム単位など、より詳細に機能分割して設計するフェーズ
・基本設計では見えていない要件や基本設計段階ではまだ不完全なものがあれば、詳細設計フェーズで修正を行い仕様を確定さる

主な設計内容
・画面、帳票のレイアウト及び機能設計
・バッチ処理(自動実行処理)の設計
・メッセージ仕様(画面などに表示する内容)
・データベース設計(表領域、ファイルサイズなど詳細な設計)
・クラス設計などのプログラム設計
・システムで使用するコード設計
・開発規約、コーディング規約などの検討
・単体テスト仕様書の作成


詳細設計書


このフェーズで作成されたドキュメント群
・次の開発フェーズで実際にプログラミングを行われる際、使用する

4.製造・実装

 閲覧数:376 投稿日:2017-10-07 更新日:2017-10-12 

開発(プログラミング)


内部設計を元にプログラミングやパラメータ設定等を行う
・詳細設計書を元に実際にプログラムをコーディングを行う

5.テスト

 閲覧数:391 投稿日:2017-10-08 更新日:2017-10-16 

単体テスト


英語表記
・Unit Test

作成したプログラムの動作をテストする
・作成したプログラムに対し、単体テスト仕様書を元にテストを行う
・テスト結果で不具合があった場合は、不具合内容をプログラマへ伝えて修正。再テストを実施
・全てのテスト項目が終了したら、次の結合テストフェーズへ移る


結合テスト


英語表記
・Integration Test
・Joint Test

単体テスト済のプログラム同士を結合して動作テスト
外部システムと結合して動作テスト
・各プログラムを統合し、画面遷移やデータの受け渡しなど、画面・プログラム・サブシステム間の連携が正しく行われているかどうかを確認する
・具体的には、業務フローを元に実際の業務を想定したテストシナリオを作成し、最初のインプットから想定できる結果が正しくアウトプットされるか等のテストを実施
・単体テストでは問題なかったが、連携方法や制御方法にバグがあった場合は、このフェーズで発見される


総合テスト


英語表記
・Product Test
・System Test

片仮名表記
・システムテスト

システム全体を対象に動作テスト
・開発担当者が実施する本番リハーサールのような位置付け
・実際にユーザーの環境と同じかそれと同等の環境において行うテスト
・本番以降に発生しうる処理パターンを一通り網羅して一気通貫でテストする
・主に処理速度や障害発生時の処理、実際の他システムと連携して正しく動作するかなどをテストする


ユーザーテスト


総合テストが完了し、システム開発者側ですべてが問題ないと判断された後、顧客(エンドユーザー)側で行うテスト
・総合テストをパスしたシステムを実際にユーザーに使用してもらい、要求機能を満たしているか、操作感はどうかなどを確認してもらうフェーズ





ロケール

エンタープライズシステム

コメント投稿(ログインが必要)