作業:
|
目的 1 回の反復の詳細計画を作成する。以下の作業を行う。
|
|
手順 | |
入力とする成果物: | 結果となる成果物: |
頻度: 反復ごとに 1 回 | |
役割: プロジェクト管理者 | |
ツール メンター: |
ワークフローの詳細: |
反復自体は、実行可能ファイルの作成のみに焦点を絞った時間限定型作業です。最後の移行用反復以外、反復はすべて中間生産物で、リスクを軽減し、製品提供の成功を目指してプロジェクトを推進するために作成されています。実行可能な納品可能物の作成は、ほとんど連続した統合作業になりますが、プロジェクトの技術的リスクに早めに対処でき、付随するリスクも減少します。
反復作業では、既存の成果物に対するある程度の再作業がつきもので、再作業に対する態度もそれに付随して変化します。言い換えると、高品質な製品を提供するには、次のようなある程度の再作業が必要になります。中間段階の製品を構築し、製品アーキテクチャの適合性を早めに何度も評価することで、最終製品の品質が高まる一方で変更費用は少なくすみ、適応も容易になります。
目的 | 反復中に検討するユース ケースのセットまたはシナリオのセットを選択する。 反復中に処理する必要がある機能外要求セットを選択する。 |
ガイドライン: 反復計画書 |
反復範囲は次の 4 つの要因に左右されます。
反復に関する最初の計画では、反復のための時間をあらかじめ予定し、その時間を埋めるだけの十分な作業が選択されています。ただしプロジェクト管理者は、反復計画が作成されている時点では、リソースの制約やそのほかの戦術的な考慮事項を追求するための自由裁量をある程度許容しています。スケジュールに合わせるために前回の反復の範囲を縮小した結果、前回の反復のために計画された作業が完了しなかった場合、通常、当然のことながら、その作業の優先順位は高くなります。
反復を完了させるには、実行している間、分別あるアプローチをもって作業範囲を適用可能な最大限の要員レベルまで稼動させる必要があります。たとえば、要員を 2 倍に増やすことができるとしても、それにより 2 倍の反復を完了することは通常、不可能です。効率よく適用できるおよその要員数は、ソフトウェア全体のサイズとアーキテクチャ、およびこれらを備えた COCOMO II ([BOE00] を参照) などの見積もりモデルにより決定します。
反復の実行は、時間限定で管理されます。つまり、発見され、修正されていない障害については、範囲と品質を積極的に管理し、終了日に間に合わせます。
推敲中に行う反復では、次の 3 つの要因から目的を定義しています。
反復を定義する最大の要因はリスクです。リスクはできるだけ早く緩和させるかまたは除去する必要があります。これは推敲フェーズで特に該当します。推敲フェーズではほとんどのリスクが緩和されますが、残るリスクもあり、新しいリスクが発見されることもあって、作成フェーズになっても依然として中心となる要素です。ただし、推敲フェーズの目標はアーキテクチャのベースライン化にあるため、アーキテクチャが開発すべきソフトウェアの全容を包括しているかなど、ほかにも考慮する対象があります (カバレージ)。アーキテクチャは、チーム編成、開発コード量の見積りなどの計画の際にも使用されるため、これは重要です。
リスクに焦点をあてることは重要ですが、システムの最大の使命は何かを頭に入れておくべきです。難問をすべて解決していくことはよいことですが、基本機能を犠牲にしてまで達成されるべきではありません。関連するリスクがないように見えても、システムの重要な機能やサービスが実際に包括されている (重要性) かどうかを確認します。
リスク リストから最も影響のありそうなリスクについて、開発チームがリスクと「直面する」ようなユース ケースのシナリオを識別します。
例
- 「データベース D が OS である Y 上で正常に動作すること」のような統合上のリスクがある場合、わずかでもデータベースとのやりとりを含むシナリオを確実に入れます。
- 「航空機の軌跡を計算する時間」のような性能リスクがある場合、少なくとも最も明白で頻繁に発生するケースについて、この計算を含むシナリオを確実に 1 つ用意します。
重要性に関しては、システムが用意する最も基本的な機能またはサービスを確実に入れます。システムが提供する最も一般的で、最も頻繁に使用するサービスまたは機能形態を表すユース ケースからシナリオを選択します。「成果物: ソフトウェア アーキテクチャ説明書」は優先順位をつけたユース ケースのセットまたはユース ケースのサブフローの一部を表すもので、この作業を推進するのに使用します。この文書は「役割: ソフトウェア アーキテクト」がアーキテクチャ的に重要なユース ケースやシナリオを反映するために選択します。
例
- 電話交換機の場合には、初期の反復では、単純な電話局同士の呼び出しができる必要があります。これは、エラー処理サブシステムで、オペレータの設定に関する複雑な障害モードを解決するよりも、はるかに重要です。
カバレージについては、推敲フェーズの終了段階に向けて、重要でもリスクが多い訳でもありませんが、開発が必要な分野に絡むシナリオを入れます。
多くの場合、複数の問題を同時に扱う、長い一貫したシナリオを複数作成する方が経済的です。
シナリオをあまりにも「分厚く」してしまう危険性が高くなります。つまり、あまりにも多数の異なる側面、派生ケースやエラー ケースをカバーしようと試みるからです (「ガイドライン: 反復計画書」を参照)。
推敲フェーズでは、担当者またはプログラムにまつわるリスクがあることにも留意します。チーム カルチャー、訓練、ツールの選択、新技術といったものがこれにあたり、単に反復を繰り返せばこのようなリスクは軽減されていきます。
例
- クライアント ワークステーション上に、加入者のレコードを 1 つ作成します。これはサーバー上のデータベースに格納するもので、ユーザーとの対話処理はありますが、全フィールドを入力しなくてもよく、エラーは検出されないと仮定します。
統合上のリスク (データベース ソフトウェアと通信ソフトウェア) および統合問題 (2 つの異なるプラットホームを処理) を持たせた重要な機能を組み合わせます。また、設計者には新しい GUI の設計ツールに慣れさせます。最終的には、フィードバックを得るためにエンドユーザーにデモンストレーション可能なプロトタイプを作成します。- 20,000 人の加入者まで作成可能にし、1 加入者レコードへ 200 ms 以下でアクセスできるようにします。
主要な性能問題 (データまたは量と応答時間) に対処します。この問題に対処できない場合は、アーキテクチャに劇的な影響をもたらすことがあります。- 加入者の住所変更を元に戻します。
設計者にすべての「元に戻す」機能の設計について考えさせる単純な機能です。これは納得のいくコストで何を「元に戻す」ことができるかについて、エンドユーザーに投げ返すきっかけとなる場合があります。- サプライ チェーン マネジメントに関係するすべてのユース ケースを終了します。
推敲フェーズの目標は、要求の獲得を完了することでもあります。これは、セットごとに完了されなければならない場合もあります。
プロジェクトが作成フェーズに移行すると、リスクは中心となる推進力として残ります。新しく思いがけないリスクが見つかった場合は特にそうです。しかし、ユース ケースの完了は推進力のきっかけとなります。反復は機能ごとに計画可能なので、複数の反復において完全にテストされるよう、最も重要な反復から先に完了するように設定します。作成フェーズの終わりにかけて、全部のユース ケースをエラーに強くすることが主たる目標となります。
例
- エラーが起きるケースを含めて、呼び出し中継処理の変形パターンをすべて実装します。
これは関連機能の集まりです。推敲フェーズ中に実装されるものもあり、その後の開発を通じてプロトタイプの役割を果たす場合があります。- 夜間サービスを除くすべての電話交換手機能を完成させます。
これは別の機能セットです。- コンピュータ 2 台構成で 1 時間当たり 5,000 トランザクションを達成します。
前回の反復で実際に達成された数字 (毎時 2357 トランザクションのみ) と比較して、必要な性能の向上を図ります。- GIS (Geographical Information System) の新版を統合します。
これはアーキテクチャ上ではわずかな変更かもしれませんが、探知されている障害により必要になったものです。- レベル 1 とレベル 2 の障害をすべて修正します。
前回の反復中に探知された障害で、すぐには修正せずに遅らせていたものを修正します。.
製品の、現在の段階を終了することが主目標です。反復の目的はどのバグを修正するか、性能または使いやすさにおいて、どのような改善点が含まれたかという観点で設定されています。作成フェーズの終了 (IOC のマイルストーンまたは「ベータ」版) に間に合わせるために機能をあきらめた (または動作不可能とした) 場合、これまでの時点で達成された内容に影響を与えない限り、この段階で完了させるか、動作可能とします。
例
- ベータ テストを行っている顧客サイトで見つかった重大度 1 の障害をすべて修正します。
品質の観点での目標は市場での信用につながる場合があります。- データの不整合による起動時の故障をすべて取り除きます。
品質の観点における、もう 1 つの目標です。- 毎分 2,000 トランザクションを達成します。
性能のチューニングを行いますが、データ構造の変更、キャッシュ処理、よりスマートなアルゴリズムの採用といった、ある種の最適化を含みます。- サイズの異なるダイアログ ボックスの数を 30% 削減します。
見た目の雑然さを減らして、使いやすさを改善します。- ドイツ語版と日本語版を作成します。
ベータ版は、時間がないのと作業の重複を削減するために、英語の顧客向けのみ作成されています。
反復ごとに、実行可能ファイルがリリースされます。このリリースは (最終の移行向け反復を除き) 通常、製品品質ではありませんが、評価は可能です。
方向づけ段階の反復は、一般的に製品の概念を探り、プロジェクト資金の承認に必要なサポートの作成に焦点がおかれます。その結果、この反復によるリリースは一般に概念を証明するための動作可能なプロトタイプですが、薄いユーザー インターフェイスの下には本物の実装コー ドはありません。この評価基準は、ユーザーからの承認と、質的な基準を志向したものです。
方向づけ段階で中心となる技術的ハードルを克服しないと、製品向けの資金を提供できない場合もあります。この場合、評価基準にはこの問題が反映されている必要があります。
方向づけフェーズのための評価基準を参照してください。
推敲フェーズの反復では、安定したアーキテクチャの作成に焦点がおかれています。この結果、推敲フェーズの評価基準はアーキテクチャの安定性の評価に範囲を絞る必要があります。利用できる尺度は次のとおりです。
中心となる目標は、作成フェーズでの変更がシステム中に波及していき、膨大な再作業の必要が生じないようにすることです。
推敲フェーズのための評価基準を参照してください。
作成フェーズと移行フェーズの反復は、破損、バグ密度、故障発見率といった、従来のソフトウェア テストと変更管理フローに沿って測定します。この反復における中心作業は、エラーを見つけ出して修正することです。
エラーは何種類かの方法で発見されます。検査とコード レビュー、機能テスト、性能テストおよび負荷テストです。それぞれのテクニックには得意分野があって、特定の種類のバグを発見できます。これらのテクニックの詳細は、Rational Unified Process Test の作業分野で説明されています。
作成フェーズのための評価基準および移行フェーズのための評価基準を参照してください。
反復の目標に基づいて、反復中に実行する作業セットを選択する必要があります。通常、各反復では、次のようにソフトウェア ライフサイクルの全作業を部分的に通過していきます。
これらの作業の遂行レベルは、反復およびプロジェクトのフェーズの状況に応じて異なります。個々の作業分野 (要求、分析 / 設計、テストなど) により汎用的な作業を定義し、次にこれがプロセス構成を経て実際の組織へと当てはめられていきます。
開発すべきシナリオまたは本格的なユース ケース (これに加えて修正すべきバグ) を選択して簡単なスケッチができあがったら、何が影響を受ける成果物なのかを探す必要があります。
次に作業分野から関連する作業を抽出し、計画内に配置します。反復ごとに行われる作業もあれば (ここでの例)、クラスごと、ユース ケースごと、サブシステムごとに行う必要のある作業もあります (例)。この作業と明らかに従属関係にある作業を結び付け、見積り工数を割り当てます。このプロセス向けに説明されている作業のほとんどは 1 人または非常に少人数のグループで、数時間から数日で達成できるくらいに小さなものです。
反復中にすべてをこなす十分な時間がないことがわかる場合もあります。反復を延長する (最終納品時期を遅らせるか、あるいは反復の数を減らす) よりは、反復での成果目標を減らします。どのフェーズにいるのかによって、シナリオを単純にするか、機能を削減するか、機能を使用不可に設定します。
反復で行う作業セットが決まると、プロジェクト チームの各メンバーに作業を割り当てる必要があります。利用可能な要員のリソースと反復の範囲に応じて、作業は個人またはチームで実行できます。レビューと点検作業は本来、チーム作業で行うものです。ユース ケースの作成やクラスの設計と実装などのそのほかの作業は、(経験の浅いチーム メンバーにメンターとしてベテランのチーム メンバーを付ける場合を除いて) 個人ベースの作業となります。
通常は、次のような個々の作業成果はチームで担当したとしても、個人の責任となります。
他のメンバーと接点がない状態で作業すると、一貫性を保証するのがほとんど不可能になります。
Rational Unified Process
|