目的
  • コンポーネントの実行時の振る舞いを理解する
  • 異常な振る舞いと必要な修正アクションを特定する
役割: 実装担当者
頻度: この作業は一般に、実装要素の作成または変更中に複数回実行されます。
手順
入力とする成果物: 結果となる成果物:
詳細情報:
ツール メンター:

ワークフローの詳細:

必要な実行シナリオの決定 ページの先頭へ

目的: 必要な実行時の振る舞いを促す実行経路を特定する

実行時の振る舞いの観察と分析がソフトウェアの振る舞いに対する必要な洞察を提供する場合、アプリケーションのどの実行経路を探求するのが重要か、また、ソフトウェアの実行時の振る舞いを理解する上で最も適切な実行経路について考慮する必要があります。

一般に、最も有用な探求シナリオは、エンドユーザーが通常使用する実行経路のすべてまたは一部を反映させることです。したがって、可能な限り、開発中のソフトウェアの代表的なエンドユーザーなどの領域の専門家に質問するか協議することにより、シナリオを特定することが便利です。

ユース ケースは、有用なシナリオを特定し、探索可能な一連の貴重な成果物を提供します。開発者として、これらの中で最も身近なものは、使用可能な場合は最初に扱うユース ケースの実現になると考えられます。ユース ケースの実現がない場合は、エンド ユーザーが、ユース ケース仕様書中のさまざまなイベント フローを通じてナビゲートする経路のテキスト記述を提供する、使用可能なすべてのユース ケース シナリオを特定します。最後に、ユース ケース イベント フローを参考にして、見込みのあるシナリオ候補を特定可能な情報を提供できます。この最後の方法の成功率は、ユース ケース アクターまたはほかの領域専門家を代表する人に問い合わせることにより向上します。

実行時分析の有用なシナリオを特定する際に、テスト担当者に相談することも役に立ちます。テスト担当者は、仮の領域専門家に進化させるテスト作業を通じて、領域に対する洞察と経験を持ち合わせていることがよくあります。多くの場合、ソフトウェアの実行時の振る舞いを観察するための刺激は、テスト作業そのものの結果から発生します。

この作業が報告された欠陥により活発になる場合、主な焦点はそれを管理された環境で再現することになります。問題が発生した際にログとして記録された情報に基づき、欠陥を確実に発生させるために、潜在的な候補として多数のテスト ケースを特定しなければなりません。一部のテストの微調整や新規テストの作成が必要になる場合がありますが、欠陥の再現は必須のステップであり、最も困難な場合は欠陥を修正するよりも安定的に発生させる方が時間を要することに注意しなければなりません。

実行時観察用の実装コンポーネントの準備 ページの先頭へ

目的: コンポーネントを実行可能にする適切な状態の準備を確認する

コンポーネントの実行が正しい結果を出力するためには、実装、コンパイル、リンクにおけるエラーの副産物として異常な結果が起こらないように、コンポーネントの適切な準備に注意を払わなければなりません。

スタブされたコンポーネントを利用して、実行時の観察が適切な時間内に終了できるようにしたり、コンポーネントがまだ実装されていないほかのコンポーネントに依存する状況で観察できるようにしたりする必要がよく生じます。

また、コンポーネントの実行に必要なフレームワークまたはサポートするツールを準備しなければなりません。このことは、コンポーネントの実行をサポートするドライバまたはハーネス コードの作成を意味する場合があります。また、コンポーネントを調整して、外部のサポート ツールがコンポーネントの振る舞いを観察し、可能であれば制御できるようにすることを意味する場合もあります。

実行に向けた環境の準備 ページの先頭へ

目的: 対象となる環境の事前セットアップが適切に完了していることを確認する

実行時分析を行う対象環境について、対応しなければならないすべての要求と制約を考慮することは重要です。コンポーネントが最終的に動作する必要がある、意図された 1 つ以上の導入環境をシミュレートしなければならない場合があります。また、開発者のコンピュータ上で実行時の振る舞いを観察するだけで十分な場合もあります。

いずれにしても、実行時観察用の対象環境を適切にセットアップし、後続の分析を無効化する可能性がある「不良部分」の混入によって実行が浪費さないようにすることが重要です。

もう 1 つの考慮事項は、再現が困難な環境上の制約または例外条件を生成するツールの使用です。こうしたツールは、これらの条件下の実行時の振る舞いで発生する障害または以上を分離するのに有益です。

コンポーネントの実行と振る舞いの観察結果の捕捉 ページの先頭へ

目的: コンポーネントの実行時の振る舞いと観察し、捕捉する

コンポーネントとそれを観察する環境の両方の準備が整ったら、選択したシナリオに沿ってコンポーネントの実行を開始できます。使用するテクニックとツールにより、このステップをほとんど無人で実行したり、シナリオの進捗に従って進行中の注意を提供 (または要求) したりする場合があります。

振る舞いの観察結果のレビューと最初の発見の分離 ページの先頭へ

目的: コンポーネントの実行時の振る舞いにおける障害と異常を特定する

観察するシナリオの各ステップまたは最後のいずれかで、予期される振る舞いに対する障害または異常を探します。異常な振る舞いに関連すると思われるすべての観察結果または抱く印象を記録します。

発見の分析と根本的な原因の理解 ページの先頭へ

目的: 任意の障害と異常の根本原因を理解する

発見したことを確認し、各障害の基礎にある欠陥または根本的な原因の調査を開始します。

対応策の特定と通知 ページの先頭へ

目的: さらなる調査または修正アクションを提案する

発見したことをすべてレビューし終えると、いっそうの調査が必要だと感じる推測事項のリストがあり、場合によっては特定の修正アクションを提案することも考えられます。これらの項目について自らすぐに対応するのでなければ、提案を適切な形式で記録し、提案を承認または実施可能なチームにメンバーに通知します。

結果の評価 ページの先頭ヘ

目的: 作業が適切に完了し、結果の成果物が受け入れられるものであると確認する

作業が完了したら、作業が十分な価値を持つことを検証するのは良い習慣です。行った作業が適切な品質であるか評価し、後でその作業を入力として使用するチーム メンバーに十分有用であるほどに完全であることを確認しなければなりません。可能であれば、RUP で提供されるチェックリストを利用して、品質と完全性が「十分適切」であることを検証します。

行った作業を下流の作業実行時に入力として使用する人々が、一時的作業のレビューに参加してもらうようにします。これはそれらの人々の懸念事項に対処するためのアクションを実行できる時間があるうちに行います。また、重要な入力成果物に対して作業を評価し、それらについて十分かつ正確に対応または考慮したことを確認しなければなりません。この点に基づいて、入力成果物の作者に作業結果をレビューしてもらうことが有益な場合があります。

RUP は反復プロセスであり、多くの場合、成果物は時間の経過と共に発展することを覚えておいてください。そのため、すぐ後に続く下流作業で一部しか使われない、またはまったく使われない成果物を完全に作成することはたいてい必要がないばかり、多くの場合、逆効果です。これは、成果物が使われる前に、成果物を取り巻く状況が変化し、成果物の作成時の前提条件が正しくないと判明して、作業を再度行わなければならなくなり、それまでの作業が無駄になる可能性が高いからです。.

また、内容自体の価値の損害に対するプレゼンテーションにおいて、あまりに多くのサイクルを費やすことも避けます。プレゼンテーションがプロジェクトの提出物として重要性と経済的価値を持つプロジェクト環境では、成果物の表現性を向上させるために、管理的つまり部下のリソースを用いて作業を実行することを検討するとよいでしょう。



Rational Unified Process   2003.06.15