
ITが当たり前の時代、何か新しいことを始めるときに、あたらしいITシステムが必要となることは不可避です。システムを作っていく、システム開発のプロジェクトをどのように進めていくかは、ビジネスの変革を実現するためにも非常に重要です。
プログラマーが一人でプログラムを書いてシステムを作っていくならば、適当に試行錯誤してもいいですが、大規模システムを開発していく際は、ある程度一定のルールのもとに作業を進めていく必要があります。
特に大規模システム開発においては、きちんとあるタイミングタイミングで物事を固めて、試行錯誤ができるだけ発生しない様、ウォーターフォールで進めることが結果的に成功の要因となると私は思っています。
今の時代はアジャイル開発が普通ではありますが、私は、アジャイル開発は小さなウォーターフォール開発の繰り返しだと思います。
プロジェクト開始時点で、最初から最後まで全体としてどんなタスクを実施しなければならないかの全体俯瞰することが肝となると思いますので、まずは普遍的なウォーターフォール開発の進め方の中で、最低限どのプロジェクトでも忘れてはならないタスクを、過去の経験からピックアップしました。
1.結合テストフェーズのタスク定義

テストについては、きちんとテストの計画を立ててテストのスコープ、Entry Criteria(開始基準)、Exit Criteria(完了基準)を定めた後、テストケースとして予想されるテスト結果を定義したのちに、テストを実施するべきです。闇雲にシステムをモンキーテストしても何がOKで何がNGなのか何もわかりません。また、バグについては有限の時間でバグゼロを目指すのは非現実的であるため、次工程に影響のないバグであれば申し送り扱いとして次工程に進むといったこと自体も、テスト計画として定義しておくことが望ましいです。
結合テストフェーズは、システム内のコンポーネント間やサブシステム間のAPI連携、データ連携をテストする内部結合テストと、外部の別システムとAPI連携、データ連携をテストする外部IF結合テストに分けてテストを実施します。
システム内部における結合テスト
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
1 | 内部結合テスト計画の作成 | テスト全体計画書や各種設計書を基に、テストに関する詳細な計画(テストの目的、範囲、開始基準、完了基準、テスト方法、テスト環境、スケジュール)を立てる。 | 内部結合テスト実施計画書 | テストの目的/範囲、開始基準/完了基準、テスト方法、テスト環境、スケジュール |
2 | 内部結合テスト仕様(テストケース)の作成 | テスト実施計画書、各種設計書等に基づき、システム機能を検証するためのテストケースを作成し、テストデータを準備する。 | 内部結合テスト仕様書 | テスト対象、テストデータ、予想される結果、実施者、実施日時、実施結果、OK/NG判定 |
3 | 内部結合テストの実施 | 個別テスト計画書及びテスト仕様書(テストケース)に従って、テストを行い、テスト結果をテスト結果報告書としてまとめる。 | 内部結合テスト結果報告書 | 実施件数、障害件数、障害内容、申し送り等 |
外部システムとのインタフェース接続テスト
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
4 | 外部IF結合テスト計画の作成 | テスト全体計画書や各種設計書を基に、テストに関する詳細な計画(テストの目的、範囲、開始基準、完了基準、テスト方法、テスト環境、スケジュール)を立てる。 | 外部IF結合テスト実施計画書 | テストの目的/範囲、開始基準/完了基準、テスト方法、テスト環境、スケジュール |
5 | 外部IF結合テスト仕様(テストケース)の作成 | テスト実施計画書、各種設計書等に基づき、システム機能を検証するためのテストケースを作成し、テストデータを準備する。 | 外部IF結合テスト仕様書 | テスト対象、テストデータ、予想される結果、実施者、実施日時、実施結果、OK/NG判定 |
6 | 外部IF結合テストの実施 | 個別テスト計画書及びテスト仕様書(テストケース)に従って、テストを行い、テスト結果をテスト結果報告書としてまとめる。 | 外部IF結合テスト結果報告書 | 実施件数、障害件数、障害内容、申し送り等 |
2.総合テストフェーズのタスク定義

総合テストフェーズは、Vモデルで言うところの基本設計の仕様を機能レベルで確認するアプリケーション総合と、主にシステムのインフラストラクチャを中心に非機能要件に対する仕様を確認する性能テストや障害テストを実施します。
アプリケーション総合テスト
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
1 | 総合テスト計画の作成 | テスト全体計画書や各種設計書を基に、テストに関する詳細な計画(テストの目的、範囲、開始基準、完了基準、テスト方法、テスト環境、スケジュール)を立てる。 | 総合テスト実施計画書 | テストの目的/範囲、開始基準/完了基準、テスト方法、テスト環境、スケジュール |
2 | 総合テスト仕様(テストケース)の作成 | テスト実施計画書、各種設計書等に基づき、システム機能を検証するためのテストケースを作成し、テストデータを準備する。 | 総合テスト仕様書 | テスト対象、テストデータ、予想される結果、実施者、実施日時、実施結果、OK/NG判定 |
3 | 総合テストの実施 | 個別テスト計画書及びテスト仕様書(テストケース)に従って、テストを行い、テスト結果をテスト結果報告書としてまとめる。 | 総合テスト結果報告書 | 実施件数、障害件数、障害内容、申し送り等 |
性能/障害テスト関連
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
4 | 性能/障害テスト計画の作成 | テスト全体計画書や各種設計書を基に、テストに関する詳細な計画(テストの目的、範囲、開始基準、完了基準、テスト方法、テスト環境、スケジュール)を立てる。 | 性能/障害テスト実施計画書 | テストの目的/範囲、開始基準/完了基準、テスト方法、テスト環境、スケジュール |
5 | 性能/障害テスト仕様(テストケース)の作成 | テスト実施計画書、各種設計書等に基づき、システム機能を検証するためのテストケースを作成し、テストデータを準備する。 | 性能/障害テスト仕様書 | テスト対象、テストデータ、予想される結果、実施者、実施日時、実施結果、OK/NG判定 |
6 | 性能/障害テストの実施 | 個別テスト計画書及びテスト仕様書(テストケース)に従って、テストを行い、テスト結果をテスト結果報告書としてまとめる。 | 性能/障害テスト結果報告書 | 実施件数、障害件数、障害内容、申し送り等 |
3.受入れテストフェーズのタスク定義

受入テストでは、Vモデルで言うところの要件定義の内容を実ユーザの代表者に業務フローを通じて確認してもらいます。
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
1 | 受入れテスト計画の作成 | テスト全体計画書や各種設計書を基に、テストに関する詳細な計画(テストの目的、範囲、開始基準、完了基準、テスト方法、テスト環境、スケジュール)を立てる。 | 受入れテスト実施計画書 | テストの目的/範囲、開始基準/完了基準、テスト方法、テスト環境、スケジュール |
2 | 受入れテスト仕様(テストケース)の作成 | テスト実施計画書、各種設計書等に基づき、システム機能を検証するためのテストケースを作成し、テストデータを準備する。 | 受入れテスト仕様書 | テスト対象、テストデータ、予想される結果、実施者、実施日時、実施結果、OK/NG判定 |
3 | 受入れテストの実施 | 個別テスト計画書及びテスト仕様書(テストケース)に従って、テストを行い、テスト結果をテスト結果報告書としてまとめる。 | 受入れテスト結果報告書 | 実施件数、障害件数、障害内容、申し送り等 |
4.本番リリース準備フェーズのタスク定義

本番サービスインするために、本番のデータ移行、本番のシステム切り替え、本番運用業者への最終引継ぎを実施します。
# | タスク | 説明(タスク) | 成果物 | 説明(成果物) |
---|---|---|---|---|
1 | データ移行(本番) | 現行システムからデータを移行し、移行後のデータの検証を行う。 | 移行結果報告書 | 実施件数、障害件数、障害内容、申し送り等、OK/NG判定 |
2 | システム切替(本番)/td> | 本番稼動開始のために、新システムに切替し、切替後の検証を実施する。 新システムの安定稼動確認後に、移行計画に従って現行システムを停止する。 | システム切替結果報告書 | 実施件数、障害件数、障害内容、申し送り等、OK/NG判定 |
3 | 運用保守業者への引継ぎ | 設計・開発受託者からシステム運用受託者へ設計書や資源等の引継ぎを行う。 | 引継ぎ結果報告書 | 実施件数、障害件数、障害内容、申し送り等、OK/NG判定 |
0 件のコメント :
コメントを投稿