開発成果物に対する変更は、変更依頼 (CR: Change Requests) を通じて提起されます。変更依頼は、障害や拡張依頼など、製品への変更に関連するあらゆるタイプの依頼を文書化し、追跡するために使用します。変更依頼を使用することの利点は、決定事項の記録が残ることと、その評価プロセスによって、変更の影響がプロジェクトのすべての参加者に確実に理解されることです。 
役割:  変更管理責任者  
オプション度 / 使用時期:  必須。必要に応じて何度でも作成します。
テンプレートとレポート: 
 
例:   
UML の表現:  なし
詳細情報:   
成果物を入力とする作業:    成果物を出力とする作業:   

目的 ページの先頭へ

変更の必要性は、ソフトウェア システムの開発において、システムが開発の初期に進展し、その後実際の業務環境における日々の運用の中で使用され、保守されていく過程で不可避的に生じるものです。変更依頼を作成し、管理することにより、システムへの変更が統制のとれた方法で行われることが保証され、変更がシステムに及ぼす影響の予測が可能になります。変更依頼は、拡張依頼や障害など、システムに対するあらゆるタイプの変更の依頼を文書化し、追跡するために使用できます。

拡張依頼は、システム分析者が、将来製品にどのような機能を持たせるかを決定する際に使用します。これらはタイプとしては、利害関係者のニーズについての理解を把握し、組織化する利害関係者の要求に属します。

障害は、納入された使用中の製品に見つかった異常またはエラーの報告です。障害とみなされる事象には、初期のライフサイクル フェーズの間に見つかる不備または欠陥、あるいは、ソフトウェアの内部で切り離して修正する必要のある欠陥 (エラー) の兆候などがあります。ソフトウェアの動作について、妥当とみなすことのできる想定範囲からの逸脱 (操作性の問題など) を障害に含める場合もあります。

障害の発見の目的は、問題の詳細を伝達し、是正措置、解決、追跡の実施を促すことです。変更依頼を使用するのは次の人々です。

  • 分析者は変更依頼を使用して、上位レベルの要求に対する重要な変更を定義し、特に拡張依頼として識別された変更依頼からの要求を特定します。
  • 管理者は変更依頼を使用して、作業の割り当てを管理します。
  • テスト担当者は変更依頼を使用して、ソフトウェア テストの間に見つかったエラー (障害)、不備、品質上の問題を記述します。
  • 実装担当者は障害の変更依頼を使用して、エラーを分析し、エラーの根底にある欠陥または原因を見つけ出して変更依頼を解決します。
  • ../workers/wk_tstanl.htm -- このハイパーリンクは、生成されたこの Web サイト内に存在しませんテスト分析者は変更依頼を使用して、解決された変更依頼を検証するために必要なテストを計画し、一連の障害を分析することによってテスト作業を評価し、ソフトウェアおよびソフトウェア工学的プロセスの品質に見られる傾向を把握します。

概要 ページの先頭

サンプルの変更依頼フォーム

  1. ID

  • プロジェクト:
  • 変更依頼番号:
  • 変更依頼タイプ: (問題または拡張)
  • 表題:
  • 提出日:
  • 提起者:
  • 変更依頼の優先度:
  1. 問題の現状

  • 問題の現状の説明:
  • 重大な障害:
  • 障害:
  • 拡張:
  • 新規の要求:
  • 問題が発生した状況:
  • 環境の現状: ハードウェア
  • オペレーティング システム
  • コンパイラ
  • 現在の問題の根源:
  • 現在の問題がコストまたはその節減に及ぼす影響:
  1. 提起される変更 (提起者)

  • 変更案の説明:
  • 変更案の実装にかかるコスト見積り:
  1. 提起される変更 (変更のレビュー チーム)

  • 対処:
  • 認可:
  • 不認可:
  • 延期:
  • 変更案の説明:
  • 影響する構成要素:
  • カテゴリ:
  • 障害修正:
  • 拡張:
  • 新機能:
  • その他:
  1. 解決

  • 変更案の実装にかかるコスト見積り:
  • 実装担当者:
  • 変更の実装にかかる実時間:
  • 分析:
  • 実装:
  • テスト:
  • 定義 :
  • 影響するコードの行数:
  1. 評価

  • テスト手法:
  • 検査
  • 分析
  • デモンストレーション
  • テスト:
  • テスト プラットフォーム:
  • テスト ケース:
  1. 変更のレビュー チームの解散

  • 承認済みの変更:

プロパティ ページの先頭へ

提起された変更依頼に関して、意思決定を行う際に有用な属性を次に示します。

変更の規模

  • 変更が必要な既存の作業の規模
  • 追加が必要な新規の作業の規模

代案

  • 代案の有無

複雑さ

  • 提起された変更の難易度
  • この変更を行った結果生じる可能性のある二次的影響

重要度

  • 変更依頼を実装しなかった場合の影響
    • 作業またはデータの損失の有無
    • 拡張依頼かどうか
    • 微小な問題かどうか

スケジュール

  • 変更が必要な時期
  • 実現可能かどうか

影響

  • 変更の実施がもたらす結果
  • 変更を実施しない場合の結果

コスト

  • 変更の実施によってかかるコストや、節約できるコスト

ほかの変更との関係

  • この変更に優先したりこの変更を無効にしたりするほかの変更の有無、この変更が別の変更の影響を受ける可能性の有無

テスト

  • 変更が正しく行われたかを検証するために実施しなければならない特別なテストの有無

タイミング ページの先頭へ

変更管理の実施は多くの場合規定化されており、そうでない場合は、プロジェクトのライフサイクルの早い段階で規定を確立します。ただし、「プロセスの変更」に不可欠な変更依頼は、プロジェクトの進行の間いつでも提起される可能性があります。

障害が発見される主なポイントは、テスト (統合テスト、システム テスト、性能テスト) の実行結果です。ただし障害は、ソフトウェア開発のライフサイクルのどの時点でも発生する可能性があり、ユース ケース、テスト ケース、文書化などの欠落または不完全さの特定も含みます。

責務 ページの先頭へ

プロジェクトの要員の誰もが、変更依頼を提起できることが理想的です。ただし、解決作業に向けて、ソフトウェア プロジェクトのコンテキストから見て適切な方法で変更依頼がレビューされ、承認される必要があります。比較的大規模なチームや形式が重視される環境では、変更依頼を提起する人物の監督者によって承認が行われるのが一般的です。多くの場合、変更依頼の最終的な裁定は、レビュー チームまたは変更管理委員会 (CCB: Change Control Board) によって行われます。

変更管理責任者 は次の事柄を徹底することにより、変更依頼の整合性に責任を持ちます。

  • 変更に対するニーズがどのように発見されたかについての想定または背景知識を含めて、変更を識別し、記述するためのすべての情報が十分に提供されており、正確である
  • 以前に識別された変更が形を変えただけのものではない、という意味で依頼がほかの依頼と重複しない

カスタマイズ ページの先頭へ

障害を正確に識別し、記述し、追跡するために必要な実際のフィールドやデータはさまざまであり、標準、ガイドライン、実装されている変更管理システムによって異なります。

変更依頼をより簡単に管理できる (優先度順にソートする、割り当てと完了の状態を追跡する、など) ように、変更依頼のデータをデータベースまたは変更依頼管理システムに蓄積するのが最もよい方法です。小規模なプロジェクトでは、(個々の属性を 1 列に記述する) スプレッドシートで十分な場合があります。



Rational Unified Process   2003.06.15