neego.net －システム開発(各工程)

最終更新日：08.09.07

システム開発(各工程)

ここでの登場者は、利用者と開発者とします。
利用者は、開発専門会社がシステム開発を請け負う場合はお客様、社内開発の場合は利用部門です。
社内開発の場合は、コンペや契約、契約の見直しは省略となります。

	工程	利用者	開発者	概要	インプット	アウトプット
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	プロジェクト終了	○	○	・プロジェクトの終了宣言と、保守体制の確認をします。・当プロジェクトの反省会を行います。	・検収書	・プロジェクト完了報告書