［1-1］要件確認

お客様がどのようなシステムを作りたいのかを確認します。
要件確認ではお客様が主になり、開発者は内容のヒアリングを行います。
この時点で「開発スケジュール」と「見積もり金額」を提出します。
金額については、各フェーズで想定外の仕様変更が発生した場合、再見積もりとなる場合があります。

［1-2］運用確認

［1-1］で挙がった作りたいシステムの内容が、実際の仕事の流れに沿っているかを確認します。ここから先は開発者が主になって進めていきます。
［1-1］の時点でお客様が既にシステムの内容を詳細に検討済みの場合は省略することが多いのですが、［1-1］の内容が曖昧だった場合などはこのフェーズを設けます。
システム開発では、お客様自身が、作りたいシステムを明確にできていないケースもよくあります。その場合には、「ユースケース図」と呼ばれる簡単な図を使い、仕事全体の流れとシステムの流れを図解で比較し、足りない機能や要らない機能を明確にしていきます。

［1-3］条件定義

上記で固まった内容を開発会社が資料化し、お互いの認識にズレがないかを確認します。
ここではシステム内部の作りよりも、実際の運用手順などの確認が主となります。
このフェーズで、実際に利用するサーバーや開発言語なども決定していきます。

［1-4］概要設計

実際に作るシステムの画面イメージやどんな動きをするかなど、お客様が完成図を理解できるレベルの資料を作り、実際にできあがるシステムに認識のズレがないことを確認します。
［1-3］まではお客様向けの資料をお作りしますが、ここから先は開発者寄りの資料になってきます。
この概要設計の資料内容は、お客様向け・開発者向け、半々ぐらいの比率です。

［1-5］詳細設計

実際のプログラムの流れ、データベースの設計などを行います。
ここでは完全に開発者向けの資料が作られます。
内容としては、プログラムをほぼそのまま、日本語で記述したようなものです。
詳細設計が終わった段階で設計フェーズが完了し、次の開発フェーズに移ります。

［3-1］単体試験

各機能単位での試験を行います。
1画面ごとのテストとなることが多いです。

例えば会員登録機能があった場合、

• ・会員情報入力画面
• ・会員情報確認画面
• ・会員情報完了画面

の3画面がありますが、この3画面それぞれを1つずつテストします。

［3-2］結合試験

単体試験が終わると、次は機能ごとの試験を行います。
上記の会員登録機能であれば、入力した会員情報が正しく登録されるか、登録された会員情報を利用する別画面に正しく反映されるか、といった試験となります。

［3-3］総合試験

システム全体での試験を行います。
ここでは部分的な試験ではなく、システム全体として正常に動作しているのかを確認することが主な目的となります。

［3-4］受け入れ試験

運用に即した利用ができるかを「お客様」に試験していただきます。
この試験でOKが出た時点でシステム開発は完了となります。

各試験はそれぞれに試験仕様書を作成し、それを元に試験を行いますが、開発者にとってはこのフェーズが最もストレスが多くなります。
例えば単体試験・結合試験が完了し、総合試験でバグが発覚したとします。
その内容が本来単体試験で見つかるべきものであれば、単体試験の試験方法が問題となり、結果単体試験仕様書の見直し、再試験を求められるためです。