カレッジ・スポーツ・ページング・システム

ソフトウェア開発計画書

バージョン 1.0

改訂履歴

日付

バージョン

説明

作成者

1999 年 10 月 5 日 1.0 初版 Context Integration

目次

はじめに ページの先頭へ

目的

このソフトウェア開発計画書の目的は、WebNewsOnLine にカレッジ・スポーツ・ページング・サービスを実装するのに必要となるフェーズと反復の点から開発作業を定義することです。

範囲

このソフトウェア開発計画書では、チームがシステムの開発に使用する全体的な計画について説明します。個別の反復の詳細については、反復計画書で説明します。

定義、頭字語、略語

なし

参考資料

  1. CSPS 要求管理計画書
  2. CSPS リスク・リスト
  3. CSPS 開発個別定義書
  4. CSPS 創造的設計の概要

プロジェクトの概要 ページの先頭へ

プロジェクトの目的、範囲、目標

このプロジェクトでは、WebNewsOnLine 用にカスタマイズされたシステムを実装します。これによって、 ページャー、携帯電話、電子メールを介して、加入者に更新されたコンテンツが通知されます。すると、 加入者は、World Wide Web を介してカスタマイズされたコンテンツを閲覧することができます。

仮定と制約

システムは、2000 年の「March Madness」 (NCAA 決勝トーナメント) の時点で利用できなければなりません。

プロジェクトの納入物

プロジェクト期間中に、次の納入物が作成されます。

ソフトウェア開発計画書の考案

この計画は、それぞれ後続のフェーズまたは反復が開始される前に更新されます。それぞれのフェーズの終了日を次に示します。

ソフトウェア開発計画書のスケジュールの図

プロジェクトの組織 ページの先頭へ

組織の構成

方向づけと推敲フェーズのプロジェクト・チームは、次のように組織されます。

組織の構成図

外部インターフェース

プロジェクト・チームは、編集スタッフ、広告スタッフ、フィールド代表スタッフと協力し、要求の収集、 プロトタイプのレビュー、システム内のさまざまな機能のテストを行います。WebNewsOnLine の主な連絡先は、 事業部長のドナ クラムです。

ロールと責務

次の表は、上のプロジェクト図に示したロールとその主な責務を表しています。

ロール 責務
プロジェクト管理者 プロジェクト管理者は、要員の割り当て、優先順位付け、 顧客やユーザーとの相互作業の調整を行い、通常、正しい目標に向けてプロジェクト・チームが結集し続けられるよう努めます。プロジェクト管理者は、 プロジェクト成果物の統合と品質を保証する実践原則の制定も行います。
アーキテクト アーキテクトは、プロジェクトを通して、 技術的作業および成果物の指示と調整を行います。アーキテクトは、ビューの分解、要素のグループ化、主要なグループ間のインターフェースなど、 各アーキテクチャー・ビューの総合的な構造を確立します。したがって、その他のワーカーと比較して、アーキテクトの見解は深く掘り下げたものというより、 広範なものとなります。
ビジネス分析者 ビジネス分析者は、モデル化する組織の概略と範囲を示し、 ビジネス・ユースケース・モデリングの指示と調整を行います。例えば、どのビジネス・アクターとビジネス・ユースケースが存在し、どのように相互に関係しているかを示します。
設計者 設計者はクラスの責務、運用、属性、関係を定義し、 どのようにこれらを実装環境に適合させるかを決定します。さらに、設計者は、 パッケージまたはサブシステムに属するクラスを含め、1 つまたは複数の設計パッケージまたは設計サブシステムの担当になります。
創造的設計者 創造的設計者は、使いやすさの要求を含む Web インターフェースについての要求把握、Web ページのプロトタイプ構築、エンド・ユーザーなど Web インターフェースのその他の利害関係者の使いやすさについてのレビューや使用テスト・セッションへの参加、Web インターフェース の最終的な実装への適切なフィードバックのレビューと提供を行うことにより、Web インターフェースのプロトタイプ作成のほか設計の指示と調整を行います (その他の開発者、すなわち、設計者と実装者により作成されるのと同様)。
テスト担当者 テスト担当者は、テストの設定と実行、テスト実行についての評価とエラーからの回復、テスト結果の評価、特定された障害の記録を含め、テスト実行を担当します。
要求スペシャリスト 要求スペシャリストは、ユースケースの要求面、その他の支援ソフトウェア要求を記述することにより、 一部のシステム機能の仕様を把握します。要求スペシャリストは、ユースケース・パッケージや、そのパッケージの整合性の維持も担当します。

管理プロセス ページの先頭へ

プロジェクトの見積もり

このプロジェクトの方向づけフェーズには、3 週間かかります。後続フェーズの最初の見積もりについては、セクション 2.4 を参照してください。

プロジェクト計画書

このプロジェクトの方向づけフェーズは次のとおりです。

タスク

開始

終了

方向づけ 1999 年 10 月 1 日金曜日 1999 年 10 月 25 日月曜日
方向づけの開始 1999 年 10 月 1 日金曜日 1999 年 10 月 1 日金曜日
方向づけキックオフ 1999 年 10 月 4 日月曜日 1999 年 10 月 6 日水曜日
ContextWISE カートリッジを使用した、特定のプロジェクト技術のプロジェクト計画へのタスクの追加 1999 年 10 月 4 日月曜日 1999 年 10 月 4 日月曜日
変更審査会の召集 1999 年 10 月 4 日月曜日 1999 年 10 月 5 日火曜日
変更管理計画の作成とベースライン化 1999 年 10 月 5 日火曜日 1999 年 10 月 5 日火曜日
サインオフの取得 1999 年 10 月 5 日火曜日 1999 年 10 月 5 日火曜日
方向づけキックオフ会議 1999 年 10 月 5 日火曜日 1999 年 10 月 6 日水曜日
方向づけキックオフ会議の準備 1999 年 10 月 5 日火曜日 1999 年 10 月 6 日水曜日
方向づけキックオフ会議の開催 1999 年 10 月 6 日水曜日 1999 年 10 月 6 日水曜日
方向づけキックオフ完了 1999 年 10 月 6 日水曜日 1999 年 10 月 6 日水曜日
方向づけ納入物 1999 年 10 月 6 日水曜日 1999 年 10 月 14 日木曜日
要求検討会議の開催 1999 年 10 月 6 日水曜日 1999 年 10 月 7 日木曜日
プロジェクト開発構想の作成、レビュー、サインオフ 1999 年 10 月 6 日水曜日 1999 年 10 月 7 日木曜日
暫定的なユースケース・モデル (10 ~ 20% 完了) の作成と改訂管理下への配置 1999 年 10 月 7 日木曜日 1999 年 10 月 11 日月曜日
暫定的なユースケース概要の作成、レビュー、サインオフ 1999 年 10 月 11 日月曜日 1999 年 10 月 12 日火曜日
暫定的な補足仕様書の作成、レビュー、サインオフ 1999 年 10 月 12 日火曜日 1999 年 10 月 12 日火曜日
開発企画書の作成、レビュー、サインオフ 1999 年 10 月 12 日火曜日 1999 年 10 月 12 日火曜日
暫定的なプロジェクト用語集の作成、レビュー、サインオフ 1999 年 10 月 12 日火曜日 1999 年 10 月 12 日火曜日
暫定的な創造的設計概要の作成、レビュー、サインオフ 1999 年 10 月 6 日水曜日 1999 年 10 月 7 日木曜日
暫定的なサイト・マップとユースケース・ナビゲーション・マップの作成、レビュー、サインオフ 1999 年 10 月 7 日木曜日 1999 年 10 月 8 日金曜日
創造的設計コンポーネントの作成、レビュー、サインオフ 1999 年 10 月 8 日金曜日 1999 年 10 月 11 日月曜日
暫定的なコンテンツ計画の作成、レビュー、サインオフ (該当する場合) 1999 年 10 月 6 日水曜日 1999 年 10 月 6 日水曜日
ユーザー・インターフェースのプロトタイプ (オプション) の作成、レビュー、サインオフ 1999 年 10 月 6 日水曜日 1999 年 10 月 6 日水曜日
レポートのプロトタイプ (オプション) の作成、レビュー、サインオフ 1999 年 10 月 12 日火曜日 1999 年 10 月 14 日木曜日
暫定的な代替技術の開発 1999 年 10 月 6 日水曜日 1999 年 10 月 7 日木曜日
適切なコンテキスト権威との連絡 1999 年 10 月 12 日火曜日 1999 年 10 月 13 日水曜日
暫定的な知識伝達計画書とスケジュールの作成、レビュー、サインオフ 1999 年 10 月 13 日水曜日 1999 年 10 月 13 日水曜日
方向づけの提案による仮定の有効化/無効化 1999 年 10 月 13 日水曜日 1999 年 10 月 14 日木曜日
サインオフの取得 1999 年 10 月 14 日木曜日 1999 年 10 月 14 日木曜日
方向づけ納入物の完了 1999 年 10 月 14 日木曜日 1999 年 10 月 14 日木曜日
方向づけのまとめ 1999 年 10 月 14 日木曜日 1999 年 10 月 25 日月曜日
クライアントとの品質チェック会議の開催 1999 年 10 月 14 日木曜日 1999 年 10 月 14 日木曜日
品質保証の遂行 1999 年 10 月 14 日木曜日 1999 年 10 月 15 日金曜日
コンテキストの得られる教訓についての会議の開催 1999 年 10 月 14 日木曜日 1999 年 10 月 14 日木曜日
最初のプロジェクト見積もりの作成、レビュー、サインオフ (+75%、-60%) 1999 年 10 月 14 日木曜日 1999 年 10 月 18 日月曜日
完全なプロジェクト反復納品計画書の作成、レビュー、サインオフ 1999 年 10 月 18 日月曜日 1999 年 10 月 19 日火曜日
推敲フェーズへの提案の作成 1999 年 10 月 14 日木曜日 1999 年 10 月 15 日金曜日
ソフトウェア・プロジェクト・ログの作成 1999 年 10 月 15 日金曜日 1999 年 10 月 15 日金曜日
方向づけチェックポイントの準備 1999 年 10 月 15 日金曜日 1999 年 10 月 18 日月曜日
クライアントのプロジェクト管理者を含むチームの結成、ワーク・リリース・サインオフ・フォームの完成 1999 年 10 月 18 日月曜日 1999 年 10 月 19 日火曜日
推敲フェーズへの提案の提供 1999 年 10 月 19 日火曜日 1999 年 10 月 21 日木曜日
方向づけチェックポイントのレビューと実行するかしないかの決定 1999 年 10 月 21 日木曜日 1999 年 10 月 22 日金曜日
プロジェクト・ホーム・ページから IAN 成果物への適切な納入物の移動 1999 年 10 月 22 日金曜日 1999 年 10 月 25 日月曜日
方向づけの完了 1999 年 10 月 25 日月曜日 1999 年 10 月 25 日月曜日

フェーズ計画書

システムの開発は、1 つのフェーズ内に複数の反復が発生するフェーズ化手法を使用して行われます。フェーズと相対的な予定表を次の表に示します。

フェーズ 反復数 開始 終了
方向づけフェーズ 1 第 1 週 第 4 週
推敲フェーズ 1 第 5 週 第 11 週
作成フェーズ 3 第 12 週 第 27 週
移行フェーズ 1 第 28 週 第 31 週

各フェーズの終了時に記されたマイルストーンを次の表に示します。

説明 マイルストーン
方向づけフェーズ 方向づけフェーズでは、製品要求を開発し、 プロジェクトの開発企画書を作成します。大まかなプロジェクト計画書と共に、 主要なユースケースを作成します。この方向づけフェーズの最後には、開発企画書に基づいて、 資金を割り当ててプロジェクトを進めるかどうかを決定します。フェーズ最後の開発企画書レビューのマイルストーンには、プロジェクトの許可/不許可の決定が記されています。
推敲フェーズ 推敲フェーズでは、要求を分析し、 アーキテクチャー・プロトタイプを開発します。推敲フェーズの完了時には、 リリース 1.0 に選択したすべてのユースケースの分析と設計が終了します。また、 リリース 2.0 の高いリスクのユースケースも分析され設計されます。アーキテクチャー・プロトタイプによって、 リリース 1.0 に必要なアーキテクチャーの実現可能性と性能がテストされます。アーキテクチャー・プロトタイプのマイルストーンは 推敲フェーズの最後に記されます。このプロトタイプは、R1.0 リリースを構成する 主なアーキテクチャー上のコンポーネントの検証を示します。
作成フェーズ 作成フェーズ中に、 残りのユースケースが分析され設計されます。リリース 1.0 のベータ・バージョンが 開発され、評価のために配布されます。R1.0 リリースと R2.0 リリースを サポートする実装作業とテスト作業が完了します。R2.0 の操作機能マイルストーンが、 作成フェーズの最後に記されます。リリース 2.0 のソフトウェアは、パッケージ化の準備が整います。
移行フェーズ 移行フェーズでは、R1.0 リリースと R2.0 リリースの配布を準備します。 円滑にインストールができるよう、ユーザー・トレーニングを含め、 必要なサポートを提供します。R2.0 リリースのマイルストーンは、 移行フェーズの最後に記されます。この時点で、開発構想書に定義されたすべての機能がインストールされ、ユーザーが利用できるようになります。

反復の目標

フェーズ 反復 説明 関連するマイルストーン 扱うリスク
方向づけ 予備反復 ビジネス・モデル、製品要求、プロジェクト計画書、開発企画書を定義する。 開発企画書のレビュー ユーザーの要求を前もって明確にします。

現実的なプロジェクトの計画と範囲を作成する。

ビジネスの観点から、プロジェクトの実現可能性を判断する。

推敲フェーズ アーキテクチャー・プロトタイプの開発 すべてのユースケースについて、分析と設計を完了する。 アーキテクチャー・プロトタイプを開発する。 アーキテクチャー・プロトタイプ アーキテクチャーの問題を明らかにする。

技術的なリスクの低減。

ユーザー・レビューの初期プロトタイプ。

作成フェーズ C1 反復 - ベータの開発 ユースケースを実装およびテストし、ベータ・バージョンを提供する。 ベータ ベータに実装されている、ユーザーとアーキテクチャーの観点から見た主要なすべての機能。

ソフトウェア・リリース前のユーザー・フィードバック。

  C2 反復 - 最初のリリースの開発 残りのユースケースを実装およびテストし、ベータからの障害を修正し、ベータからのフィードバックを取り込む。

最初のシステムを開発する。

ソフトウェア ユーザー・コミュニティーが十分にレビューしたソフトウェア。

製品は高品質であること。

障害は最小であること。

品質コストの低減。

  C3 反復 - 完全なリリースの開発 最初のリリースからの改良点と障害修正を組み込む。

完全なシステムを開発する。

ソフトウェア 迅速なリリースにより、顧客満足度に対処する。

完全なリリースによりシステムに提供されるすべての主要機能。

移行フェーズ ソフトウェア・リリース リリースのパッケージング、販売、インストール。 ソフトウェア・リリース  

リリース

この時点で、2 つのリリースが計画されます。1 つ目のリリースは「March Madness」 (NCAA 決勝トーナメント) に間に合うよう完成させる必要があり、 その範囲は推敲フェーズで決定されます。残りのすべての機能は後続のリリースに含まれます (必要な場合)。

プロジェクトのスケジュール

暫定的なプロジェクト・スケジュールは、セクション 2.4 を参照してください。更新された計画は、 セクション 2.4 で指定された日に有効になります。

プロジェクトのリソース配置

  1. 要員配置計画書
  2. このプロジェクトの要員は、Context Integration により配備されており、セクション 3.1 に名前を記しています。

  3. リソース獲得計画書
  4. 該当なし。

  5. トレーニング計画書
  6. このプロジェクトに割り当てられたスタッフは、この時点で適切なスキルを有しています。方向づけフェーズにおいて知識伝達計画を作成し、 スタッフが移行フェーズに続いてシステムをサポートするのに必要なスキルを獲得できるようにします。

予算

方向づけフェーズの予算は、$150,000.00 です。推敲フェーズの予算は、方向づけフェーズの中で設定されます。

反復計画書

この文書には、方向づけの反復計画書が含まれます。後続のフェーズの反復計画書は、前のフェーズまたは反復の終了時に提出されます。

プロジェクトの監視と管理

  1. 要求管理計画書
  2. 参照 [1] を参照してください。

  3. スケジュール管理計画書
  4. プロジェクト・ステータス・レポートは 1 週間ごとに発行されます。 ここには、プロジェクトが順調に進むよう、マイルストーンの追跡詳細が含まれます。スケジュールの変更は、 プロジェクトのスポンサーまでエスカレーションされ、スポンサーは、完了日を維持するため範囲を変更するかどうかの判断をします。

  5. 予算管理計画書
  6. プロジェクト・ステータス・レポートは 1 週間ごとに発行されます。 ここには、プロジェクトが順調に進むよう、マイルストーンの追跡詳細が含まれます。スケジュールの変更は、 プロジェクトのスポンサーまでエスカレーションされ、スポンサーは、完了日を維持するため範囲を変更するかどうかの判断をします。

  7. 品質管理計画書
  8. 各サブシステムの設計と実装ごとに、正式なレビューが実施されます。これにより、レビューされているオブジェクトが確実に指定の要求を満たすことができます。

  9. レポート計画書
  10. 週次のプロジェクト・ステータス・レポートが発行されます。フェーズと反復の概要レポートも、適宜発行されます。

  11. 測定計画書
  12. プロジェクトの進捗状況の追跡には労力と時間がかかります。プロジェクト管理者は、計画と実績のレポートを使用して、進捗状況を測定します。

  13. リスク管理計画書
  14. 参照 [2] を参照してください。

  15. 終了計画書
  16. プロジェクトの終了時に、得られた教訓についての会議を行い、新しい技術、ツール、メソッドを把握します。プロジェクトの納入物は、 将来の参照用に、ナレッジ・マネージメント・リポジトリーに保存します。

技術プロセス計画書 ページの先頭へ

開発個別定義書

参照 [3] を参照してください。

メソッド、ツール、技術

RUP における標準のガイドラインが使用されます。

インフラストラクチャー計画書

プロジェクトは、適切なサーバーがあり、すでにソフトウェアがインストールされている Context Solution Center で開発されます。

製品検収計画書

未作成。

サポート・プロセス計画書 ページの先頭へ

構成管理計画書

参照 [3] を参照してください。

評価計画書

未作成。

文書作成計画書

作成される文書は、参照 [3] に一覧表示されています。

品質保証計画書

参照 [3] を参照してください。

問題解決計画書

未作成。

下請け業者管理計画書

利用不可。下請け業者は使用しません。

プロセス改良計画書

各フェーズの完了時に、得られる教訓についてのセッションを行い、プロセスに対する改良点を把握します。

© Copyright IBM Corp. 1987, 2005. All Rights Reserved.