ウォーターフォール型のシステム開発における各工程でよくでる言葉をまとめてみました。
も参照してください。
目次
- ウォーターフォールモデル (Waterfall Model)とは
- ウォーターフォールモデルの各工程の名称
- 要件定義 (Requirement Definition、RD)
- 基本設計 (Basic Design、BD)
- 詳細設計 (Detail Design、DD)
- 開発 (Development、コーディング、プログラミング、Coding、Programming)
- 単体テスト (Unit Test、UT、Part Test、PT)
- 統合テスト (Integration Test、IT、統合試験、System Integration Test)
- UAT (User Acceptance Test, 受け入れテスト)
- 本番稼動 (Production、Run、カットオーバー、Cut Over または C/O)
- 移行 (マイグレーション、Migration、Transfer)
- 運用 (Operation)
- 保守 (Maintenance)
ウォーターフォールモデル (Waterfall Model)とは
まず、ウォーターフォールモデルについて。
これは読んで字のごとし、滝の流れ (ウォーターフォール) のように流れに従って開発する手法のこと。
Wikipedaには以下のように定義されていました。
プロジェクトによって工程の定義に差はあるが、開発プロジェクトを時系列に、「要求定義」「外部設計（概要設計）」「内部設計（詳細設計）」「開発（プログラミング）」「テスト」「運用」などの作業工程（局面、フェーズ）にトップダウンで分割する。線表（ガントチャート）を使用してこれらの工程を一度で終わらせる計画を立て進捗管理をする。原則として前工程が完了しないと次工程に進まない（設計中にプログラミングを開始するなどの並行作業は行わない）事で、前工程の成果物の品質を確保し、前工程への後戻り（手戻り）を最小限にする。ウォーターフォール・モデルの利点は、工程の進捗管理がしやすいことである。
ウォーターフォール・モデルの例には、IBMによるADSG（Application Development Standardization Guide、アプリケーション開発標準化ガイド）などがある。
なお「ウォーターフォール・モデルは古く、スパイラルモデルは新しい」と単純化して語られる場合もあるが、大規模開発ではスパイラルモデルだけでは収束せず破綻するケースが大半のため、現在でもウォーターフォール・モデルとスパイラルモデル等は、組み合わされて使用されている。
ウォーターフォール・モデルが採用される裏には、次のようなスパイラルモデルの問題が解決できないという理由もある。
- 要件を変更したときの見積もりや契約の方法が確立されていない
- 各工程の頻繁なリリースによるバージョン管理が難しい
- テストの自動化に関するノウハウが蓄積されていない
https://ja.wikipedia.org/wiki/ウォーターフォール・モデル
ウォーターフォールモデルには、局面 (工程) が存在するために、別名、局面化開発手法とも呼ばれることがあります。
または、システム開発ライフサイクル (SDLC, System Development Life Cycle) とも呼ばれます。
各工程は次の通りです。
- 「要求定義」
- 「基本設計設計（外部設計）」
- 「詳細設計（内部設計）」
- 「開発（プログラミング）」
- 「テスト」
- 「運用」
ウォーターフォールモデルは、おそらく1970年代に確立した手法ですが、今もまだ、システム開発、SI (システムインテグレーション) 開発の主流です。
システム開発の手法としては、ウォーターフォールモデル以外には、スパイラル、アジャイル、クリーンルーム、RAD (プロトタイピング)、エクストリーム・プログラミング (XP) 等々、山のようにあります。
ウォーターフォールモデルの各工程の名称
ウォーターフォールモデルにおけるシステム開発ライフサイクルの概念図は以下の通りです。
ウォーターフォールモデルでは時間軸と共に開発工程は流れていきます。
形がV字型の形で書くことが多いため、V字モデルと呼ばれることもあります。
V字モデルでは、テストの粒度の視点で
要件定義が受け入れテストに、基本設計が統合テストに、詳細設計が単体テストに、それぞれ対応しています。
つまり、要件定義で定義したことを受け入れテストで行い、より細かな詳細設計レベルで定義した内容は受け入れテストで行うことではありません。
要件定義 (Requirement Definition、RD)
あるシステムにおける、顧客が実現したいもの (要件) について定義する工程。
基本設計 (Basic Design、BD)
機能設計、外部設計、External Design、Base Design、FD (FunctionDesign) とも呼びます。
要件定義を元に、開発担当からの視点で基本的な設計 (外部設計) を行う工程です。
詳細設計 (Detail Design、DD)
内部設計、Internal Design とも呼びます。
基本設計を元に、具体的な処理方式 (ロジックや内部的なデータ構造等) を設計する工程です。
なお、詳細設計を元に、プログラム設計 PD (Program Design) という、プログラムの構造を定義 (クラス図など) する工程を設けることもあります。
開発 (Development、コーディング、プログラミング、Coding、Programming)
システムを開発する工程です。いわゆるプログラミングです。
単に M (Make) と呼ばれることもあります。
単体テスト (Unit Test、UT、Part Test、PT)
単体のプログラムを試験する工程です。
本当に単体の試験をする工程を UT1、ある程度のモジュールを組み合わせて結合チックな試験をする工程を UT2 として区別することもあります。
試験項目書は PCL (Program Checklist) または MCL (Make Checklist) と呼ばれることもあります。
統合テスト (Integration Test、IT、統合試験、System Integration Test)
システムテスト、System Test、ST、プロダクトテスト、Product Test、PTと呼ばれることもあります。
あるいは、まれに LT (Link Test) と呼ばれることもあります。
統合テストは、SI1(IT1) と SI2(IT2) と分けて実施することもあります。
UAT (User Acceptance Test, 受け入れテスト)
また、統合テストの後で、受け入れテスト(UAT、User Acceptance Test、ユーザ受け入れテスト、検収テスト) または、受入試験 RT (Receive Test) と言って、納品された開発物一式を、お客さんが試験する工程を設けることもあります。
受け入れテスト(UAT)は、システム開発を開発ベンダーに外注して納品された時に、発注者の本来の目的や意図通りに稼働するかどうかを検証することです。 この検証はシステムの発注者が実施します。 また、受け入れテストは「受け入れ試験」「受け入れ検収」「検収テスト」「ユーザー受け入れテスト」とも、呼ばれます。
なお、テスト中に発生した不具合を修正することを、デバグ (DeBug、DB) と呼ぶこともあります。
本番稼動 (Production、Run、カットオーバー、Cut Over または C/O)
システムが稼働することです。
移行 (マイグレーション、Migration、Transfer)
システムを移行することです。
運用 (Operation)
システムを運用することです。
保守 (Maintenance)
システムを保守することです。
コメント
[…] BD, UT, IT, ST, UATとは？ウォーターフォールモデル型のシステム開発における… […]
[…] BD, UT, IT, ST, UATとは？ウォーターフォールモデル型のシステム開発における… […]