ソフトウェア開発計画書
バージョン 1.0
改訂履歴
日付 |
バージョン |
説明 |
作成者 |
---|---|---|---|
1999 年 1 月 15 日 |
1.0 |
初版 |
リック・ベル |
|
|
|
|
|
|
|
|
|
|
|
|
ソフトウェア開発計画書
このソフトウェア開発計画書の目的は、コンピューター化されたクラス登録システムを Wylie カレッジに実装するのに必要な開発作業を、フェーズと反復の点から定義することです。
このソフトウェア開発計画書では、Wylie カレッジの C- 登録システムを
開発するために Wylie カレッジ情報システムが使用する全体的な計画について説明します。
個別の反復の詳細については、反復計画書で説明します。
本書で述べる計画の概要は、「開発構想書」 (参考資料 [1]) で定義された
製品要求に基づいています。
「用語集」 (参考資料 [4]) を参照してください。
該当する参考資料は次のとおりです。
このソフトウェア開発計画書には、次の情報が含まれています。
プロジェクトの概要 - プロジェクトの目的、範囲、目標について説明します。 また、プロジェクトによって納入できる予定のワーク・プロダクトを定義します。
プロジェクト組織 - プロジェクト・チームの組織構造について説明します。
管理プロセス - 見積もり費用とスケジュールについて説明し、プロジェクトの主なフェーズとマイルストーンを定義し、プロジェクトの監視方法について説明します。
技術プロセス計画書 - メソッド、ツール、それに続く技術を含むソフトウェア開発プロセスの概要を示します。
サポート・プロセス計画書 - 構成管理計画書が含まれます。
このソフトウェア開発計画書では、Wylie カレッジの C- 登録システムを 開発するために Wylie カレッジ情報システムが使用する全体的な計画について説明します。 個別の反復の詳細については、反復計画書で説明します。
本書で述べる計画の概要は、「開発構想書」 (参考資料 [1]) で定義された製品要求に基づいています。
このシステムは、1999 年秋学期の学生登録の主要な手段とすることを目的としています。 履修コース登録は 1999 年 8 月 1 日に始まるので、システムはこの日までに完全に使用できるようになっている必要があります。
プロジェクト中に次のワーク・プロダクトが作成され、保守組織に渡されます。
そのほかにも、プロジェクト開発ケースで述べるワーク・プロダクトが作成されますが、保守組織には渡されません。
ソフトウェア開発計画書は、各反復のフェーズの開始前に改訂されます。
プロジェクト管理者は、この計画書のスケジュールに従って、利害関係者である IT 担当役員にステータス評価を提出します (「開発構想書」 (参考資料 [1]) を参照)。
また、プロジェクト・チームはその他の利害関係者ともやり取りして、関係するワーク・プロダクトについての入力やレビューを求めます。
次の表は、作業分野、アクティビティー、サポート・プロセスのそれぞれに責任を持つ組織単位を示します。
ロール |
責務 |
---|---|
プロジェクト管理者 |
「Rational Unified Process」(参考資料 [6]) に示すとおり、 プロジェクト管理の作業分野全体に責任を持ちます。 拡張されたプロジェクト管理チームを率います。 |
プロセス・エンジニア | 「Rational Unified Process」の環境の作業分野で定義されたとおり、 プロジェクト環境やプロジェクトのチームに対するプロセス関係のサポートの提供に責任を持ちます。 拡張されたプロジェクト管理チームに参加します。 |
構成管理者/変更管理責任者 | プロジェクトの構成管理と、プロジェクトにおける Wylie カレッジの変更要求プロセスの実行に責任を持ちます。 拡張されたプロジェクト管理チームに参加します。 |
システム・エンジニアリング・チーム・リーダー |
主にビジネス・モデリングと要求の作業分野の管理に責任を持つチームを率います。拡張されたプロジェクト管理チームに参加します。 |
ソフトウェア・エンジニアリング・チーム・リーダー |
主に分析と設計分野と実装分野に責任を持ちます。拡張されたプロジェクト管理チームに参加します。 |
テスト・チーム・リーダー |
テスト分野の管理に責任を持つチームを率います。 拡張されたプロジェクト管理チームに参加します。 |
配置チーム・リーダー | エンド・ユーザー環境でのインストール作業とインフラストラクチャーに責任を持つチームを率います。 拡張されたプロジェクト管理チームに参加します。 |
プロジェクトの見積もりは、「履修コース登録システム Cost Model and Analysis Report」 (参考資料 [7]) に基づいています。
履修コース登録システムは、その複雑さとアーキテクチャーの点で、1997 年に Wylie カレッジが構築したオンライン・ライブラリー・システムに似ています。 履修コース登録システムのデータベースは複雑さが 約 25% 増しており、ユースケースの数と複雑さから見て、システム全体では複雑さが約 20% 増しています。 このレポートの時間枠と作業量の見積もりは、プロジェクトの予算とスケジュールの基礎となります。
ワーク・ブレークダウン・ストラクチャーは現在準備中で、この文書の次のバージョンで提供される予定です。
C- 登録システムの開発は、1 つのフェーズ内に複数の反復が発生するフェーズ化手法を使用して行われます。 この計画のフェーズと反復は重複しません。相対的な時間割りの概要を、次の表に示します。
フェーズ |
反復数 |
終了 |
---|---|---|
方向づけフェーズ |
1 |
第 7 週 |
推敲フェーズ |
1 |
第 14 週 |
作成フェーズ |
1 |
第 19 週 |
移行フェーズ |
4 |
第 32 週 |
表 4.2.1 相対的な時間割りの概要
表 4.2.2 は、各フェーズと、そのフェーズの終了をマーク付けする主なマイルストーンを示します。
フェーズ |
説明 |
マイルストーン |
---|---|---|
方向づけフェーズ |
方向づけフェーズでは、 製品要求を開発し、C- 登録システムの開発企画書を確立します。 大まかなソフトウェア開発計画書と共に、主要なユースケースを作成します。 方向づけフェーズの終了に、Wylie カレッジは、 開発企画書に基づいてプロジェクトに出資して続行するかどうかを決定します。 |
フェーズの終了の開発企画書レビュー・マイルストーンは、プロジェクトに対する続行/中止の決定をマークします。 |
推敲フェーズ |
推敲フェーズでは、要求を分析し、アーキテクチャーのプロトタイプを開発します。 推敲フェーズの終了には、リリース 1.0 に選択したすべてのユースケースの分析と設計が終了します。 また、リリース 2.0 の高いリスクのユースケースも分析され設計されます。 アーキテクチャーのプロトタイプによって、リリース 1.0 に必要なアーキテクチャーの実現可能性と性能がテストされます。 |
アーキテクチャー・プロトタイプ・マイルストーンは、 推敲フェーズの終了をマークします。このプロトタイプは、R1.0 リリースを構成する 主なアーキテクチャー上のコンポーネントの検証を示します。 |
作成フェーズ |
作成フェーズ中に、 残りのユースケースが分析され設計されます。リリース 1.0 のベータ・バージョンが 開発され、評価のために配布されます。R1.0 リリースと R2.0 リリースを サポートする実装作業とテスト作業が完了します。 |
初期運用能力のマイルストーン (ベータの終了) は、作成フェーズの終了をマークします。 |
移行フェーズ |
リリース 1.0 のベータ・バージョンが配布され評価されます。 移行フェーズでは、R1.0 リリースと R2.0 リリースの配布を準備します。 円滑にインストールができるよう、ユーザー・トレーニングを含め、 必要なサポートを提供します。 |
R2.0 リリース・マイルストーンは、移行フェーズの終了をマークします。 この時点で、「開発構想書」 (参考資料 [1]) に定義されたすべての機能がインストールされ、ユーザーが使用できる状態になります。 |
表 4.2.2 プロジェクトのフェーズと主なマイルストーン
各フェーズは、セクション 4.3 に述べる開発反復に分けられます。
セクション 4.2.4 で、フェーズ、反復、マイルストーンを示す 大まかなプロジェクト・スケジュールについて説明します。
各フェーズは開発反復から構成され、開発反復でシステムのサブセットが開発されます。一般に、反復によって次のことが可能になります。
次の表は、反復、それに関連するマイルストーン、 扱うリスクを示します。
フェーズ |
反復 |
説明 |
関連するマイルストーン |
扱うリスク |
---|---|---|---|---|
方向づけフェーズ |
予備反復 |
ビジネス・モデル、製品要求、ソフトウェア開発計画書、開発企画書を定義します。 |
開発企画書のレビュー |
ユーザーの要求を前もって明確にします。 現実的なソフトウェア開発計画書と範囲を開発します。 プロジェクトの実現可能性を、ビジネスの観点から判断します。 |
推敲フェーズ |
E1 反復 - アーキテクチャー・プロトタイプの開発 |
すべての高いリスク要求の分析と設計を完了します。アーキテクチャーのプロトタイプを開発します。
|
アーキテクチャー・プロトタイプ |
アーキテクチャーの問題を明らかにする。 技術的なリスクの低減。 ユーザー・レビューの初期プロトタイプ。 |
作成フェーズ |
C1 反復 - R1 ベータの開発 |
R1 ベータ・バージョンを提供するために、R1 の主な要求を実装してテストします。
リリースをベータ・テストできるかどうか、評価します。 |
初期運用能力 (R1 ベータ・コード完了) |
ベータに実装されている、ユーザーとアーキテクチャーの観点から見た主要なすべての機能。
|
移行フェーズ |
T1 反復 - R1 リリースの開発/配置 |
R1 ベータを配置します。 ベータの障害を修正し、ベータからのフィードバックを組み込みます。
残りの R1 要求を実装し、テストします。 R1 リリースのパッケージング、配布、インストール。 残りの低リスクの R2 ユースケースの詳細記述。 |
R1 ベータ・テスト完了
R1 コード完了
R1 製品リリース |
R1 のリリース前のユーザー・フィードバック。
製品は高品質であること。 障害は最小であること。 品質コストの低減。 2 段階のリリースによって障害が最小限に抑えられます。 2 段階のリリースによって、ユーザーが移行しやすくなります。 R1 はユーザー層によって細かくレビューされます。 |
|
T2 反復 - R2 内部 1 の開発 |
R2 内部 1 の要求を設計、実装、テストします。 R1 からの改良点と障害修正を組み込みます。 R2 内部 1 を配置します。 |
R2 内部 1 テスト完了 |
必要であれば、顧客満足を得るために、R2 内部 1 をリリースして R1 の障害に対処します。 |
|
T3 反復 - R2 内部 2 の開発 |
R2 内部 2 要求を設計、実装、テストします。 R2 内部 2 からの改良点と障害修正を組み込みます。 R2 内部 2 を配置します。 |
R2 内部 2 テスト完了 |
R2 内部 1 をユーザー層が非公式にレビューします。
必要であれば、顧客満足を得るために、R2 内部 1 をリリースして R1 の障害に対処します。 |
|
T4 反復 - R2 リリースの開発/配置 |
R2 リリースのパッケージング、配布、インストール。 |
R2 コード完了
R2 製品リリース |
R2 内部 2 をユーザー層が非公式にレビューします。 2 段階のリリースによって、ユーザーが移行しやすくなります。 |
このソフトウェア開発計画書では、C- 登録システムの最初の 2 リリースを扱います。 「開発構想書」 (参考資料 [1]) で定義された主要な機能は、最初の 2 リリースの目標となります。学生登録に必須のすべての機能は、最初のリリース (R1.0) で計画します。
計画されたリリース内容は、プロジェクトの進展に伴って変更されます。 これは、多数のビジネス要因と技術要因によって発生します。変更を組み入れるために、Rational RequisitePro を使用して製品要求を管理し、リリース内容を追跡管理します。 特に、利点、作業量、リスクの各属性は、製品要求の優先順位、ひいては対象リリースを決定するのに使用されます。
2 ~ 4 のメイン・リリースを通じて Wylie カレッジで C- 登録システムが広く使用されることが予想されます。
リリース 1 では、少なくとも、次に挙げる基本的な機能が実現する必要があります。
リリース 2 では次の機能の実現することを推奨します。
リリース 3 の機能は未定です。 このリリースでは従来の機能の強化が実現されることが予想されます。
従来の請求システムとコース・データベース・システムの交換は、2005 年のリリース 4 を目標にしています。
また、ベータ・リリースは R1.0 製品リリースに先行し、R1.0 のすべての主要な機能を含む予定です。 ベータ・リリースは実際のシステムのように配置されますが、従来のレガシー・システムの独立コピーとやり取りする点が異なります。 これは、既存のシステムに混乱が発生するのを避けるためです。選択された学生と教職員のグループは、公式にベータを評価することが求められます。
また、プロジェクトの一環として内部リリースを行いますが、必要な場合は初期リリース後に追加のリリースを行う可能性があります。 内部リリースは、学生と教職員による非公式なレビューを受けることができます。これらの各内部リリースの目標について、以下に簡単に説明します。
リリース 3 の機能は未定です。 このリリースでは従来の機能の強化が実現されることが予想されます。
従来の請求システムとコース・データベース・システムの交換は、2005 年のリリース 4 を目標にしています。
プロジェクトのフェーズ、反復、マイルストーンを示す高いレベルのスケジュールは、「履修コース登録システム High Level Project Schedule」 (参考資料 [5]) に含まれ、次のようになります。
|
セクション 8.1 の組織図に示す IT 関連従業員は、 プロジェクトに割り当てられます。追加の要員が配属されるのは、方向づけフェーズの終了に開発企画書がレビューされ、プロジェクトの続行/中止が決定されてからになります。
テスト組織は、組織図に点線で示すように、 ソフトウェア・エンジニアリング組織からのサポートに依存します。
Wylie カレッジの IT 部門には、 プロジェクトに必要な開発者と設計者が不足しています。Wylie カレッジの採用担当部署では、C++ に数年の経験を持つ上級開発者 1 名、 経験のあるシステム統合担当者 1 名、C++ に少なくとも 1 年の経験を持つ実装担当者/テスト担当者 (初級レベル) 2 名を採用する用意があります。
設計作業の開始に先立ち、 プロジェクト・チームに対して次の技術に関するトレーニングが行われます。
初期見積もりに基づくプロジェクトの予算です。
「履修コース登録システム 反復計画書 #E1」 (参考資料 [11]) を参照してください。
このシステムに対する要求は、「開発構想書」 (参考資料 [1]) と「利害関係者の要望書」 (参考資料 [3]) にまとめてあります。
プロジェクト管理者は、各マイルストーンの予定日を示す大まかなスケジュールを保持します。 このスケジュールは、レポート計画書で述べるステータス評価レポートの一部となります。 ステータス評価レポートは IT 担当役員に提出され、IT 担当役員はこれを使用して、 新しい優先順位を設定または修正アクションを薦めたりします。
大まかなスケジュールは、チーム管理者が保持する詳細なスケジュールから引き出されます。 詳細なスケジュールの行項目は、 個人に割り当てられた作業パッケージです。 作業パッケージを割り当てられた各人は毎週、どこまで終了したかをパーセントでチーム管理者に報告します。
費用はプロジェクト管理者が監視し、ステータス評価レポートによって報告され、評価されます。
すべてのワーク・プロダクトは、適切なレビュー・プロセスを通過する必要があります。 レビューは各ワーク・プロダクトが受け入れ可能な品質であることを確認するために必要で、 「Rational Unified Process」(参考資料 [6]) に記載されたレビュー・ガイドラインとチェックリストを使用します。
また、「Wylie Software Process Website」 (参考資料 [10]) に記載されているように、障害が記録されて追跡され、障害メトリックスが収集されます。
ステータス評価レポートは、少なくとも月に 1 度、プロジェクト管理者が用意します。 このレポートには次の内容が含まれます。
- 更新された費用とスケジュールの見積もり
- メトリックスの概要
「Wylie College Software Process Website」 (参考資料 [10]) に記載されているように、標準のプロジェクト・メトリックスが収集され、ステータス評価レポートに含まれます。
「履修コース登録システム リスク・リスト」 (参考資料 [8]) を参照してください。
スケジュールは、徐々にスタッフがほかのプロジェクトに移行することを示します。 納入後、IT 部門には少なくとも 1 人の開発者がパート・タイムで確保され、 システムの保守を担当します。
実際の費用とスケジュール対予測された費用とスケジュールの比較評価など、明らかになった点をまとめた事後分析レポートが IT 担当役員に提出されます。
「履修コース登録システム 開発書」 (参考資料 [9]) を参照してください。
「Wylie College Software Process Website」 (参考資料 [10]) を参照してください。
該当なし
該当なし
「Wylie Software Process Website」 (参考資料 [10]) を参照してください。
該当なし
該当なし
該当なし