成果物:
|
![]() |
開発成果物に対する変更は、変更依頼 (CR: Change Requests) を通じて提起されます。変更依頼は、障害や拡張依頼など、製品への変更に関連するあらゆるタイプの依頼を文書化し、追跡するために使用します。変更依頼を使用することの利点は、決定事項の記録が残ることと、その評価プロセスによって、変更の影響がプロジェクトのすべての参加者に確実に理解されることです。 |
役割: | 変更管理責任者 |
---|---|
オプション度 / 使用時期: | 必須。必要に応じて何度でも作成します。 |
テンプレートとレポート: |
|
例: | |
UML の表現: | なし |
詳細情報: | |
成果物を入力とする作業: | 成果物を出力とする作業: |
変更の必要性は、ソフトウェア システムの開発において、システムが開発の初期に進展し、その後実際の業務環境における日々の運用の中で使用され、保守されていく過程で不可避的に生じるものです。変更依頼を作成し、管理することにより、システムへの変更が統制のとれた方法で行われることが保証され、変更がシステムに及ぼす影響の予測が可能になります。変更依頼は、拡張依頼や障害など、システムに対するあらゆるタイプの変更の依頼を文書化し、追跡するために使用できます。
拡張依頼は、システム分析者が、将来製品にどのような機能を持たせるかを決定する際に使用します。これらはタイプとしては、利害関係者のニーズについての理解を把握し、組織化する利害関係者の要求に属します。
障害は、納入された使用中の製品に見つかった異常またはエラーの報告です。障害とみなされる事象には、初期のライフサイクル フェーズの間に見つかる不備または欠陥、あるいは、ソフトウェアの内部で切り離して修正する必要のある欠陥 (エラー) の兆候などがあります。ソフトウェアの動作について、妥当とみなすことのできる想定範囲からの逸脱 (操作性の問題など) を障害に含める場合もあります。
障害の発見の目的は、問題の詳細を伝達し、是正措置、解決、追跡の実施を促すことです。変更依頼を使用するのは次の人々です。
プロジェクト:
変更依頼番号:
変更依頼タイプ: (問題または拡張)
表題:
提出日:
提起者:
変更依頼の優先度:
問題の現状の説明:
重大な障害:
障害:
拡張:
新規の要求:
問題が発生した状況:
環境の現状: ハードウェア
オペレーティング システム
コンパイラ
現在の問題の根源:
現在の問題がコストまたはその節減に及ぼす影響:
変更案の説明:
変更案の実装にかかるコスト見積り:
対処:
認可:
不認可:
延期:
変更案の説明:
影響する構成要素:
カテゴリ:
障害修正:
拡張:
新機能:
その他:
変更案の実装にかかるコスト見積り:
実装担当者:
変更の実装にかかる実時間:
分析:
実装:
テスト:
定義 :
影響するコードの行数:
テスト手法:
検査
分析
デモンストレーション
テスト:
テスト プラットフォーム:
テスト ケース:
承認済みの変更:
提起された変更依頼に関して、意思決定を行う際に有用な属性を次に示します。
変更の規模
- 変更が必要な既存の作業の規模
- 追加が必要な新規の作業の規模
代案
- 代案の有無
複雑さ
- 提起された変更の難易度
- この変更を行った結果生じる可能性のある二次的影響
重要度
- 変更依頼を実装しなかった場合の影響
- 作業またはデータの損失の有無
- 拡張依頼かどうか
- 微小な問題かどうか
スケジュール
- 変更が必要な時期
- 実現可能かどうか
影響
- 変更の実施がもたらす結果
- 変更を実施しない場合の結果
コスト
- 変更の実施によってかかるコストや、節約できるコスト
ほかの変更との関係
- この変更に優先したりこの変更を無効にしたりするほかの変更の有無、この変更が別の変更の影響を受ける可能性の有無
テスト
- 変更が正しく行われたかを検証するために実施しなければならない特別なテストの有無
変更管理の実施は多くの場合規定化されており、そうでない場合は、プロジェクトのライフサイクルの早い段階で規定を確立します。ただし、「プロセスの変更」に不可欠な変更依頼は、プロジェクトの進行の間いつでも提起される可能性があります。
障害が発見される主なポイントは、テスト (統合テスト、システム テスト、性能テスト) の実行結果です。ただし障害は、ソフトウェア開発のライフサイクルのどの時点でも発生する可能性があり、ユース ケース、テスト ケース、文書化などの欠落または不完全さの特定も含みます。
プロジェクトの要員の誰もが、変更依頼を提起できることが理想的です。ただし、解決作業に向けて、ソフトウェア プロジェクトのコンテキストから見て適切な方法で変更依頼がレビューされ、承認される必要があります。比較的大規模なチームや形式が重視される環境では、変更依頼を提起する人物の監督者によって承認が行われるのが一般的です。多くの場合、変更依頼の最終的な裁定は、レビュー チームまたは変更管理委員会 (CCB: Change Control Board) によって行われます。
変更管理責任者 は次の事柄を徹底することにより、変更依頼の整合性に責任を持ちます。
障害を正確に識別し、記述し、追跡するために必要な実際のフィールドやデータはさまざまであり、標準、ガイドライン、実装されている変更管理システムによって異なります。
変更依頼をより簡単に管理できる (優先度順にソートする、割り当てと完了の状態を追跡する、など) ように、変更依頼のデータをデータベースまたは変更依頼管理システムに蓄積するのが最もよい方法です。小規模なプロジェクトでは、(個々の属性を 1 列に記述する) スプレッドシートで十分な場合があります。
Rational Unified Process
|