Wylie カレッジ
要求管理計画書
バージョン 2.0
改訂履歴
日付 |
バージョン |
説明 |
作成者 |
---|---|---|---|
1999 年 1 月 8 日 |
1.0 |
初版リリース |
サイモン・ジョーンズ |
1999 年 2 月 10 日 |
2.0 |
計画を拡張 |
サイモン・ジョーンズ |
|
|
|
|
|
|
|
|
目次
要求管理計画書
「Requirements Attributes Guidelines」 では、Wylie カレッジでのすべてのソフトウェア・プロジェクトの要求の管理に使用する属性の確認と説明をします。 さらにこの文書では、開発中に各プロジェクトで記録を付けておく要求追跡可能性についても概説します。
各要求に割り当てられる属性は、ソフトウェア開発の管理と、リリースごとの諸機能の優先順位の設定とに使用されます。
要求追跡可能性の目的は、 開発サイクルの後半になって見つかる不具合の件数を減らすことです。ソフトウェア要求、 設計、テスト・ケースに含まれるすべての製品要求を確実に把握しておけば、製品の品質が改善されます。
本書に示す属性と追跡可能性のガイドラインは、Wylie カレッジのすべてのソフトウェア・プロジェクトの製品要求、ソフトウェア要求、テスト要求に適用されます。
Rational Unified Process と Rational RequisitePro のマニュアル類とに定義されている用語を使用します。
次の参考資料が Wylie カレッジのソフトウェア・プロセス Web サイトにあります (または同サイトからリンクが張ってあります)。
1. 「Wylie カレッジ構成管理計画書」
2. 「Rational Unified Process」
3. 「Wylie カレッジ開発個別定義書」
個々のプロジェクトの「ソフトウェア開発計画書」で規定されます。
要求の属性と追跡可能性の管理には Rational RequisitePro が使用されます。 ほかのインフラストラクチャーの詳細については、Wylie カレッジのソフトウェア・プロセス Web サイトに記してあります。
プロジェクトごとに、次の要求タイプの識別と管理が行われます。
ワーク・プロダクト
|
要求タイプ |
説明 |
---|---|---|
開発構想書 |
製品要求 |
製品の特性、制約事項、品質範囲、その他の製品要求。 |
ユースケース・モデル |
ユースケース |
ユースケース (Rational Rose で文書化) |
テスト計画書 |
テスト・ケース |
システムが期待どおりの動作を示すことをどのようにして確認するかを示すケース。 |
「開発構想書」に規定された製品要求は、 「ユースケース仕様書」と「補足仕様書」とに記したユースケース要求または補足要求のうち、 それぞれに対応する要求までトレースされます。
各製品要求の元をたどっていけば、 1 つ以上のユースケース要求と補足要求に行き着きます。
各製品要求の元をたどっていけば、 1 つ以上のユースケース要求と補足要求に行き着きます。
「ユースケース仕様書」と「補足仕様書」とで規定したユースケース要求は、 「テスト計画書」で規定したテスト・ケースのうち、それぞれに対応するテスト・ケースにまでトレースされます。
各ユースケース要求の元をたどれば、 1 つ以上のシステム・テスト・ケースに行き着きます。
「テスト計画書」に規定されたテスト・ケースの元をたどれば、 個々のテスト・ケースで検証される製品要求 (「開発構想書」) とユースケース要求とに行き着きます。
1 つのテスト・ケースの元をたどれば、1 つ以上の製品要求とユースケース要求に行き着きます。テスト・ケースで派生要求または設計を検証する場合だと、 そのテスト・ケースは、元の製品要求へもユースケース要求へも辿れない場合があります。
ユースケース要求と「補足仕様書」は、 このセクションで規定する属性を使用して管理されます。この属性は、 開発作業の管理、反復コンテンツの決定、ユースケースとその Rose モデルとの関連付けを行うのに便利です。
分析によりユースケースの草案ができた後に設定します。 ユースケースの最初の草案からユースケースの最終的な確認に至るまでユースケースの開発の進捗を常に把握します。
提案済み |
レビューと承認はまだ実行されていないが、確認は済んでいるユースケース。 |
---|---|
承認済み |
設計と実装をさらに進めてもよいという承認を得たユースケース。 |
検証済み |
システム・テストで検証の済んだユースケース。 |
プロジェクト管理者が設定します。 開発リソースをユースケースに割り振ることと、 ユースケースの開発の進捗を監督することとの重要性の観点からユースケースの優先順位を決定します。一般に優先順位を決める基準になるのは、 ユーザーにとって効果のある利点、計画済みのリリース、計画済みの反復、ユースケースの複雑さ (リスク)、ユースケースの実装作業です。
高 |
ユースケースの実装を詳細に監視することと、 リソースが正しく当該タスクに割り当てられることとを確実に行うことに関して、高い優先順位を持つユースケースです。 |
---|---|
中 |
ほかのユースケースに比べて中くらいの優先順位を持つユースケースです。 |
低 |
優先順位の低いユースケースです。このユースケースの実装は重要度が低く、その後の反復またはリリースに回されたりスケジュールが組み直されたりすることがあります。 |
開発チームが設定します。 一部のユースケースはほかに比べて多くの時間とリソースが必要なため、 例えば何チームで何週間かかるか、何名で何週間かかるか、必要なコードの行数、機能ポイントといった項目を見積もることは、 複雑さを判断したり、所定の時間枠の中で何ができて何ができないかの予想を立てたりするのに最良の方法です。 適用範囲を管理するのと、開発の優先順位を決定するのに使用されます。プロジェクト管理者は、この作業量の見積もりを使用して、 プロジェクトのスケジュールを立て、効果が上がるよう各タスクへのリソースの割り当て計画を練ります。
1 日の 就業時間を 7.5 時間と仮定して、人日単位での作業量を見積もります。
作業量の超過、設計の欠陥、多数の不具合、低い品質、低い性能など、 望ましくないことがユースケースに発生する確率を基にして開発チームが設定します。 こうした望ましくないことが発生する原因は、往々にして、 要求事項に対する理解不足、要求の規定のあいまいさ、知識不足、リソース不足、技術面での複雑さ、新しい技術、新しいツール、新しい装置などにあります。
Wylie カレッジのプロジェクトでは、各ユースケースの技術的なリスクが高、中、低に分類されます。
高 |
リスクの影響も大きく、リスクの発生する確率も高い。 |
---|---|
中 |
リスクの影響、リスクの発生する確率のいずれかまたは両方とも低い。 |
低 |
リスクの影響が最小で、かつリスクの発生する確率も低い。 |
ユースケースが実装される開発反復を記録します。 プロジェクトの作成フェーズの間、 いくつかの開発反復にわたって各リリースの開発が実行されることが予想されます。
プロジェクトの管理者は、各ユースケースに割り当てる反復番号を使用して プロジェクト・チームのアクティビティーを計画します。
値は <letter>-<iteration number> という形式で 表されます。<letter> のところには、I、E、C、T のいずれかが入ります。 それぞれ方向づけ (inception)、推敲 (elaboration)、作成 (construction)、移行 (transition) の意味です。 例えば次のようになります。
E-1 |
推敲フェーズ、反復 1 にスケジュールされます。 |
C-1 |
作成フェーズ、反復 1 にスケジュールされます。 |
C-2 |
作成フェーズ、反復 2 にスケジュールされます。 |
C-3 |
作成フェーズ、反復 3 にスケジュールされます。 |
さらに分析、設計、実装を進めるため、個人個人か開発チームかいずれかにユースケースが 割り当てられます。単純なプルダウン・リストを使用することにより、プロジェクト・チームに参加しているだれもが任務をよりよく理解できます。
ユースケース要求に割り当てられる Rose ユースケース・モデルを識別します。
テストの指導者が設定します。 各テスト・ケースの状況が記録されます。
テスト未実施 |
まだテスト・ケースが実行されていません。 |
---|---|
不合格 |
テストは実行されたが不合格に終わりました。 |
条件付き合格 |
テストは完了したが、いくつか問題点が残りました。いくつかアクションが完了した時点で「合格」という状態を割り当てられたテストです。 |
合格 |
テストが正常に完了しました。 |
特定のテスト・ケースの検証が行われるシステム・ビルドが記録されます。
テスト・ケースの実行と検証を行うよう任命された担当者のこと。 この簡単なプルダウン・リストにより、プロジェクト・チームのだれもが、責務をより理解することができます。
テストの実施予定日または実際の実施日。
テストの計画やテストの実行に関連する一切のメモ。
TBD (未定)
「Wylie カレッジ構成管理計画書」を参照してください。
「Wylie カレッジ開発ケース」を参照してください。
これについては、個々のプロジェクトの「ソフトウェア開発計画書」の中で述べます。
これについては、個々のプロジェクトの「ソフトウェア開発計画書」の中で述べます。