各工程
| No. | 工程 | 利用者 | 開発者 | 概要 | インプット | アウトプット |
|---|---|---|---|---|---|---|
| 1 | 開発範囲(概要)の決定 | ○ | ・開発対象の範囲を決めます。 ・開発を外注する場合、RFPを自社で作成するか、コンサルティング会社に作成を依頼するのか のどちらかになります。 ・システム構築の目的、対象の業務名と業務内容、納期、予算、技術要件、教育体制、保守 要件などの要求するポイントや会社概要をまとめます。 |
・開発要望書 | 社外開発:・RFP 社内開発:・開発範囲定義書 |
|
| 2 | コンペ | ○ | ・何社かの開発会社に提案書の作成を依頼します。 ・開発会社が多い場合には、提案書を書類選考し3社程度にしぼってから、プレゼンテーションを 行うのが一般的です。 |
・RFP | ・提案書 | |
| 3 | 契約 | ○ | ○ | ・業者を決定し、契約を行います。 | ・提案書 | ・契約書 |
| 4 | プロジェクト計画 | ○ | ○ | ・利用者、開発者双方で、プロジェクトのスケジュールや方針について定義し、合意します。 | ・提案書 | ・プロジェクト計画書 |
| 5 | キック・オフ・ミーティング | ○ | ○ | ・プロジェクト・メンバ全員を集め、プロジェクトの開始を宣言します。 ・各メンバの紹介や役割を全員が認識し、プロジェクトの計画通り進める事を約束します。 ・直近の工程である要件定義に関する詳細スケジュールも、ミーティング前に、利用者と開発者 のリーダー同士で取り決めておきます。 |
・開発要望書 ・プロジェクト計画書 |
・キック・オフ資料 |
| 6 | 要件定義 | ○ | ○ | ・各業務を実施する為に、どのような機能が必要なのか、それは誰がいつどのような流れで使用
するのかを定義します。 ・全体が確認する為に、外部設計ほど細か過ぎず定義するのが重要ですが、あまり大まか過ぎる と外部設計で苦労することになります。 |
・提案書 ・詳細な開発要望書 ・既存機能の画面・帳票レイアウト ・プロジェクト計画書 |
・要件定義書 ・更新版プロジェクト計画書 |
| 7 | 契約金額の見直し | ○ | ○ | ・要件定義書で定義された要件に基づき、外部設計以降の契約金額を見直します。 ・これ以降、要件定義に記述された機能以外を要求する場合は、契約範囲外とし、金額や 日程計画を別途に取り扱われます。 |
・契約書 ・プロジェクト計画書 ・要件定義書 |
・外部設計以降の契約書 ・更新版プロジェクト計画書 |
| 8 | 外部設計 | ○ | ○ | ・要件定義書を元に、利用者が目にする「もの」を設計し、確定します。 ・「もの」には、画面レイアウト・仕様、帳票レイアウト・仕様、利用者の運用形態によっては テーブルやファイル仕様も含めます。 ・テーブルやファイル仕様は、内部設計を終了しないと確定版は完成しない為、中間のもの となります。 |
・要件定義書 ・プロジェクト計画書 |
・外部設計書 ・更新版プロジェクト計画書 |
| 9 | 内部設計 | ○ | ・外部設計書を元に、利用者が目にしないプログラム仕様を設計します。 ・一般的に外部設計書に記述されている仕様と重複しないものを定義します。 ・イベント仕様、テーブル・ファイルの参照・更新仕様等を定義します。 ・テーブルやファイル仕様はここで完成します。 |
・外部設計書 ・プロジェクト計画書 |
・内部設計書 ・更新版プロジェクト計画書 |
|
| 10 | 移行設計 | ○ | ○ | ・移行対象のデータを特定し、用意する担当者が誰で、いつまでに用意するのかを決めます。 ・開発者側がデータを加工しながら用意する場合、加工元のデータを確認し、移行用のプログラム の仕様を決めます。 |
・内部設計書 ・現行システムのデータ ・プロジェクト計画書 |
・移行データ一覧 ・移行プログラム仕様書 ・更新版プロジェクト計画書 |
| 11 | テスト計画 | ○ | ○ | ・単体テスト、結合テスト、システム・テストのそれぞれのカバー範囲を明確にし、漏れ・無駄が
無いようにし、各工程の担当者と日程を詳細に計画します。 ・各工程でのテスト内容を決めます。 ・障害が発生した時の運用のルールを定義します。 |
・外部設計書 ・内部設計書 ・要件定義書 ・プロジェクト計画書 |
・テスト計画書 ・単体テスト仕様書 ・結合テスト仕様書 ・テスト・シナリオ ・更新版プロジェクト計画書 |
| 12 | プログラム製造 | ○ | ・外部設計書と内部設計書を元に、プログラムを製造します。 ・プログラマーは、自身が製造したプログラムのテストも、この工程に含めます。 ・利用されるプログラムから製造する場合はドライバを、利用するプログラムから製造する場合 はスタブを製造して動作確認を行うことが一般的です。 | ・外部設計書 ・内部設計書 ・プロジェクト計画書 |
・プログラム ・更新版プロジェクト計画書 |
|
| 13 | 稼働準備 | ○ | ・テストに必要なハードウェアやデータを準備します。 ・利用者への教育を行います。 ・利用者の取引先に、本システムの稼働が影響する場合、案内を作成・送付します。 |
・既存システムで利用しているデータ ・システム・テスト済みプログラム ・プロジェクト計画書 |
・テスト・データ ・操作マニュアル ・運用マニュアル ・取引先への案内文 ・更新版プロジェクト計画書 |
|
| 14 | 単体テスト | ○ | ・プログラマとは別の担当者が単体テスト仕様書に基づきテストを実施し、その結果を記録
します。 ・バグが完全に無くなるまで、プログラム製造と単体テストを繰り返します。 ・利用される・するの関係にあるプログラム間の結合テストは、この工程でテストを行います。 |
・単体テスト仕様書 ・テスト・データ ・プロジェクト計画書 |
・単体テスト結果報告書 ・単体テスト結果 ・更新版プロジェクト計画書 |
|
| 15 | 移行プログラム作成 | ○ | ・移行データを作成するプログラムを製造します。 ・システムが稼働までの間だけ利用されるプログラムである為、一般的には、簡易言語で作成される ことが多いです。 |
・移行プログラム仕様書 ・プロジェクト計画書 |
・移行プログラム ・更新版プロジェクト計画書 |
|
| 16 | 結合テスト | ○ | ・業務内の流れに沿って、機能間のつながりがあるものの動作を確認します。 ・外部システムがある場合は、この工程でテストします。 |
・単体テスト済みプログラム ・結合テスト仕様書 ・テスト・データ ・プロジェクト計画書 |
・結合テスト結果報告書 ・結合テスト結果 ・更新版プロジェクト計画書 |
|
| 17 | 移行テスト | ○ | ・移行プログラムを利用して移行テストを実施します。 ・移行対象データに漏れがないが、項目のセット状態や全体の件数・金額等を確認します。 |
・移行プログラム ・テスト用の移行元データ ・プロジェクト計画書 |
・テスト用の移行データ ・更新版プロジェクト計画書 |
|
| 18 | システム・テスト | ○ | ○ | ・システム全体を、時間の流れに沿って、多岐にわたって、動作確認します。 ・一般的に、パフォーマンス・テストや負荷テスト、障害テストはこの工程で行います。 |
・結合テスト済みプログラム ・テスト・シナリオ ・テスト・データ ・プロジェクト計画書 |
・シナリオ・テスト結果報告書 ・シナリオ・テスト結果 ・更新版プロジェクト計画書 |
| 19 | 利用者受入テスト | ○ | ○ | ・システム全体を、時間の流れに沿って、多岐にわたって、動作確認します。 ・パフォーマンス・テストや負荷テストもこの工程で行います。 |
・システム・テスト済みプログラム ・テスト・シナリオ ・テスト・データ ・プロジェクト計画書 |
・利用者受入テスト結果報告書 ・利用者受入テスト結果 ・更新版プロジェクト計画書 |
| 20 | 移行実施 | ○ | ○ | ・並行稼働する為に、手入力や移行プログラムを利用して、全てのデータを用意します。 ・本番直前でも実施する場合もあります。 |
・調整前のマスタ・データ ・現行システムのデータ ・移行プログラム ・プロジェクト計画書 |
・調整後のマスタ・データ
・移行プログラムで用意されたデータ ・更新版プロジェクト計画書 |
| 21 | 並行稼働 | ○ | ・現行システムと同じデータを新システムで動作させ、動作および帳票が同じ様に出力されるか確認
する。 ・規模が大きい場合やリアル・タイム性が要求される場合は、この工程は実質的に実施することが できない為、省略される事も、ままある。 |
・プログラム一式 ・並行稼働用の元データ ・プロジェクト計画書 |
・並行稼働した結果 ・検収書 ・更新版プロジェクト計画書 |
|
| 22 | 本稼働 | ○ | ・並行稼働の動作が正常であることを確認し、本稼働を開始します。 | ・プログラム一式 ・本稼働用の元データ |
||
| 23 | プロジェクト終了 | ○ | ○ | ・プロジェクトの終了宣言と、保守体制の確認をします。 ・当プロジェクトの反省会を行います。 |
・検収書 ・プロジェクト計画書 |
・プロジェクト完了報告書 |
(2011.03.06訂正)
(2010.12.11訂正)
(2008.09.07)