ガイドライン:
|
ワークフローの一部 |
コメント |
統合および構築管理 | 役割「統合担当者」と「作業: システム統合計画の立案」、「成果物: 統合ビルド計画書」は、通常プロジェクトの初期に導入されます。ほかの統合関連の作業 (「作業: サブシステム統合計画の立案」、「作業: サブシステムの統合」、「作業: システム統合」など) は、統合が開始されるときに導入されます。 |
コンポーネントの実装 | 役割「実装担当者」と「コード レビュー担当者」、およびその作業と成果物は、各反復において実装の開始時に導入されます。 |
決定を、プロジェクト固有のプロセスの一部として、」という見出しで文書化します。
どの成果物をどのように使用するのかを決定します。次に示す表は、どの成果物が必須で、いくつかのケースではどれを使用できるかを表しています。各成果物のカスタマイズ方法、その特定の成果物の利点、または欠点の議論について詳しくは、各成果物の「カスタマイズ」の項を参照してください。
各成果物について、成果物の使用方法を決定します。つまり、必須、重要、任意、使用しない、などです。
成果物 | 目的 |
カスタマイズ (オプション、推奨) |
|
実装モデルは、実行環境においてシステムのビルドと管理に必要な、ソース コード、実行可能ファイル、その他のすべての成果物です。 実装は、コード (ソース、バイナリ、実行可能形式) を含む実装要素と、情報を格納したファイル (起動ファイルや ReadMe ファイルなど) で構成されます。 実装サブシステムは、実装要素とほかの実装サブシステムの集合であり、小さな部分に分解して、実装モデルの構成に使用されます。 |
すべてのソフトウェア プロジェクトは、最低でも何らかのソース コードと実行可能形式を含む実装要素による実装モデルを持っています。 一部のプロジェクトは、サブシステム、ライブラリ、ビジュアル モデルも含みます。 サブシステムは、多数の実装要素を編成する場合に便利です。 |
統合ビルド計画書 | コンポーネントの実装順序、システム統合時に作成するビルド、ビルドの評価方法を定義します。
|
オプションです。 統合作業を計画する必要がある場合には推奨されます。統合作業が大したものでない場合のみ省略します。 |
プロジェクトのニーズに合わせて各成果物をカスタマイズします。カスタマイズに関する考慮事項については、成果物の説明のカスタマイズに関する節、
単体テストを実行する範囲、つまりコード カバレージのレベルを決定します。スケールは非公式なものから 100% のコード カバレージにまでわたります。
単体テストのカバレージのレベルは、多くの場合、コードを手渡す先の統合テスト担当者とシステム テスト担当者のニーズで変わります。ニーズは作業用コードの品質に依存します。コードにあまりにも多数のバグがある場合、ほとんどの統合テスト担当者とシステム テスト担当者は、コードを実装担当者に送り返します。これは開発プロセスが貧弱な証拠であり、これを解決するには、実装担当者が徹底的に単体テストを実施する必要があります。
もちろん、単体テストしたコードにバグが完全にないことは期待できません。ただし、単体テストと品質の間に「健全な」バランスを探し出す必要があります。
単体テストのカバレージのレベルはフェーズが違っても異なることがあります。作成と移行フェーズ中に 100% のコード カバレージを必要とする安全重視プロジェクトであっても、推敲フェーズ中は、通常、そのレベルのものは必要ありません。というのもその段階では部分的にしか実装できていないクラスが多数あるからです。
どの程度までコードをレビューするかを決定します。
コード レビューの利点は次のとおりです。
コード レビューの欠点は次のとおりです。
コードレビューについて詳しくは、「 作業: コードのレビュー」も参照してください。
コードのレビューを行うとプロジェクトに重要な価値が加わります。コード レビューに関するバグ レベルや保守問題の計測を開始しているプロジェクトは例外なく、レビューによって高性能が得られていると確信されます。ただし、このようなことを「開始する」ことが難しい組織も多数あります。これには以下のようにいくつかの理由があります。
コード レビューを最大限に活用するには、以下のことに留意する必要があります。
Rational Unified Process
|