トピック

ワークフローの実行方法の決定 ページの先頭へ

実装ルールのワークフローに関して、以下の決定を行う必要があります。

  • ワークフローの実行方法を決定します。これは、「実装: ワークフロー」を見て行います。ダイアグラムとそのガード条件、およびガイドラインについて学びます。どのワークフローが、どのような順序で実行の詳細を記述するのかを決定します。
  • 実装ワークフローのどの部分によって実行の詳細が記述されるのかを決定します。以下に、互いに比較的独立して導入できるいくつかの部分を示します。

ワークフローの一部

コメント

統合および構築管理 役割「統合担当者」と「作業: システム統合計画の立案」、「成果物: 統合ビルド計画書」は、通常プロジェクトの初期に導入されます。ほかの統合関連の作業 (「作業: サブシステム統合計画の立案」、「作業: サブシステムの統合」、「作業: システム統合」など) は、統合が開始されるときに導入されます。
コンポーネントの実装 役割「実装担当者」と「コード レビュー担当者」、およびその作業と成果物は、各反復において実装の開始時に導入されます。

  • プロジェクトのライフサイクルのどの時期に、ワークフローのそれぞれの部分を導入するのかを決定します。実装ルール全体の導入を、推敲フェーズまで待てることもあります。反復フェーズで発生するすべてのプロトタイプ作成は通常、調査であり、推敲および作成フェーズでは、完全な実装ワークフローで必要とされるほど厳密 (たとえば成果物とレビューに関して) ではありません。

決定を、プロジェクト固有のプロセスの一部として、」という見出しで文書化します。

成果物の使用方法の決定 ページの先頭へ

どの成果物をどのように使用するのかを決定します。次に示す表は、どの成果物が必須で、いくつかのケースではどれを使用できるかを表しています。各成果物のカスタマイズ方法、その特定の成果物の利点、または欠点の議論について詳しくは、各成果物の「カスタマイズ」の項を参照してください。

各成果物について、成果物の使用方法を決定します。つまり、必須、重要、任意、使用しない、などです。

成果物 目的

カスタマイズ (オプション、推奨)

実装モデル

(実装サブシステム実装要素)

実装モデルは、実行環境においてシステムのビルドと管理に必要な、ソース コード、実行可能ファイル、その他のすべての成果物です。

実装は、コード (ソース、バイナリ、実行可能形式) を含む実装要素と、情報を格納したファイル (起動ファイルや ReadMe ファイルなど) で構成されます。

実装サブシステムは、実装要素とほかの実装サブシステムの集合であり、小さな部分に分解して、実装モデルの構成に使用されます。

すべてのソフトウェア プロジェクトは、最低でも何らかのソース コードと実行可能形式を含む実装要素による実装モデルを持っています。

一部のプロジェクトは、サブシステム、ライブラリ、ビジュアル モデルも含みます。

サブシステムは、多数の実装要素を編成する場合に便利です。

統合ビルド計画書 コンポーネントの実装順序、システム統合時に作成するビルド、ビルドの評価方法を定義します。

オプションです。

統合作業を計画する必要がある場合には推奨されます。統合作業が大したものでない場合のみ省略します。


プロジェクトのニーズに合わせて各成果物をカスタマイズします。カスタマイズに関する考慮事項については、成果物の説明のカスタマイズに関する節、

単体テスト カバレージの決定 ページの先頭へ

単体テストを実行する範囲、つまりコード カバレージのレベルを決定します。スケールは非公式なものから 100% のコード カバレージにまでわたります。

単体テストのカバレージのレベルは、多くの場合、コードを手渡す先の統合テスト担当者とシステム テスト担当者のニーズで変わります。ニーズは作業用コードの品質に依存します。コードにあまりにも多数のバグがある場合、ほとんどの統合テスト担当者とシステム テスト担当者は、コードを実装担当者に送り返します。これは開発プロセスが貧弱な証拠であり、これを解決するには、実装担当者が徹底的に単体テストを実施する必要があります。

もちろん、単体テストしたコードにバグが完全にないことは期待できません。ただし、単体テストと品質の間に「健全な」バランスを探し出す必要があります。

単体テストのカバレージのレベルはフェーズが違っても異なることがあります。作成と移行フェーズ中に 100% のコード カバレージを必要とする安全重視プロジェクトであっても、推敲フェーズ中は、通常、そのレベルのものは必要ありません。というのもその段階では部分的にしか実装できていないクラスが多数あるからです。

コード レビュー方法の決定 ページの先頭へ

どの程度までコードをレビューするかを決定します。

コード レビューの利点は次のとおりです。

  • プロジェクトに共通のコーディング スタイルを推進、または推奨します。コード レビューはプロジェクト メンバーをプログラミング ガイドラインに従わせる効率的な方法です。これを保証するためには、全ソース コード ファイルをレビューするよりもすべての作成者と実装担当者からの結果をレビューすることの方が重要となります。
  • 自動テストでは発見できないエラーの探索ができます。コード レビューではテスト以外でエラーを捕捉します。
  • 個人間での知識共有、および経験を積んだ個人から経験の少ない個人への知識の移転ができます。

コード レビューの欠点は次のとおりです。

  • 時間と資源がかかります。
  • 適切に行われなければ、非効率的になります。コード レビューは「単に行う必要があるから」行うもので、自動テストを効率的に補うものだとみなされる危険性があります。

コードレビューについて詳しくは、「 作業: コードのレビュー」も参照してください。

コードのレビューを行うとプロジェクトに重要な価値が加わります。コード レビューに関するバグ レベルや保守問題の計測を開始しているプロジェクトは例外なく、レビューによって高性能が得られていると確信されます。ただし、このようなことを「開始する」ことが難しい組織も多数あります。これには以下のようにいくつかの理由があります。

  • コード レビューが実際に効果的であることを検証する十分なデータが集まっていない
  • 多くのデータを集めすぎる
  • 実装担当者が自分のコードを守りすぎる
  • レビューが形式主義に陥っている
  • レビューの管理に作業がかかりすぎる

コード レビューを最大限に活用するには、以下のことに留意する必要があります。

  • 適切なデータだけを集める
  • レビューのパフォーマンスを測定し、結果を明示する
  • レビューを「むだのない」方法で行う


Rational Unified Process   2003.06.15