作業:
|
目的
|
|
ステップ | |
入力とする成果物: | 結果となる成果物: |
頻度: この作業は認可済みの変更が必要になるたびにプロジェクト管理者が実行 | |
役割: プロジェクト管理者 | |
ツール メンター: | |
More Information: |
ワークフローの詳細: |
反復の開始時点で作成された反復計画書では、その時点でわかっているもののみを選択できます。これが、必要なすべての機能 (機能要求と機能外要求) の追加および前の反復から持ち越された変更依頼になります。その後、プロジェクト管理者は、その反復のためのリソースとスケジュールを決定できます。障害の許容は、成果物の作成に割り当てられた作業内で暗黙的に、または特定の作業パッケージ内で明示的に、反復計画書に組み込まれます。特定の作業パッケージ内で明示的に組み込む方法をお勧めします。Rational Unified Process には、この方法を可能にするための作業が含まれます。
修正の優先順位は、変更管理責任者によって割り当てられますが、プロジェクト管理者が依然として計画裁量権を行使することができます。ただし、一般的に、障害が発見された反復の期間中にその障害を訂正するよう試みる必要がありますが、反復の開始時点で計画されたリソースによりこれが可能なはずです。反復の最後に、いくつかの未修正の (発見された) 障害が存在することは避けられません (反復は時間限定されているため) が、反復が成功と見なされるためには、これらの未修正の障害の多くが、何らかの理由で重大であったり、優先度の高いものであったりすることはほとんどありません。
ただし、予想外に発生する小さな拡張依頼以外は許容できません。重要な拡張のための変更依頼などが現在の反復で認可されれば、ほとんど確実に、プロジェクト管理者は計画済みの機能の一部を次の反復に延期するか、変更を行うための余剰リソースを見つけるなど、再計画を行わなければなりません。通常、このような拡張依頼は次の反復以降に延期され、通常の反復計画サイクルの一部になります。
変更依頼が検査されたら、プロジェクト管理者は、その種類、優先順位、重要度に基づいて、その依頼をどの反復に組み込むかを決定します。変更依頼が後の反復に延期される場合は、プロジェクト管理者は単に (ソフトウェア 開発計画書で) 今後の反復を再計画します。このため、この時点で変更依頼の影響が理解され、後で予想外の好ましくない結果が発生しないように、早急にリソース獲得作業を開始できます。
プロジェクト管理者は、組織内のどの役職が変更の実装を担当するかを決定します。
変更依頼は、必要な変更の概要によって既に説明になっている必要があります (変更依頼は既に分析、承認されているため)。このステップでは、その説明を、これから実行、作成する内容の明確な記述に洗練します。
プロジェクト管理者は変更依頼の担当者と相談して、変更依頼の作業とその他のリソースの見積りを、確固とした計画見積りに洗練します。担当要員は、この見積りに関与しなければなりません。
変更依頼が現在の反復で実装される場合、プロジェクト管理者は責務を割り当てられた人達と相談して、その作業の開始日と予想期間を設定します。
必要であれば現在の反復計画書を改訂し、将来の反復への影響をソフトウェア開発計画に反映します。再計画の結果として、特にリソース不足または以降の反復への計画済み機能の延期によって現在の反復が影響を受ける場合などは、プロジェクトの状態を新しい計画と一致させるために、プロジェクト管理者は作業: 例外と問題の処理を開始しなければならないことがあります。
実行すべき作業、スケジュール、責務などを定義する作業指示書は、プロジェクト管理者が発行します。作業予算の対象となる作業パッケージ (作業分解構造内) は、作業指示書で識別されます。
Rational Unified Process
|