変更管理（エンジニアリング）

システムエンジニアリングにおける変更要求管理プロセスとは、システムへの変更を要求し、達成可能性を判断し、計画し、実装し、評価するプロセスである。その主な目的は、相互に関連する一連の要因に対する変更の処理と追跡可能性をサポートすることである。[ 1 ]

導入

変更要求管理、変更管理、構成管理の間には、かなりの重複と混乱が生じています。以下の定義では、これらの領域はまだ統合されていません。

変更要求管理は、影響を受けるシステムを改善し、「顧客ニーズ」を満たすことでメリットをもたらすことから受け入れられてきましたが、変更管理を混乱させ、不必要に複雑化する可能性があるという批判も受けています。特に情報技術分野では、システムの初期構築よりも、システム保守（および変更要求管理）に多くの資金と労力が費やされるケースがあります。[ 2 ]大規模なERPシステム の初期導入における組織の典型的な投資額は、全体予算の15～20%です。

同様に、ヒンリーは、リーマンのソフトウェア進化の法則のうち2つを次のように説明している。[ 3 ]

  • 継続的変化の法則: 使用されるシステムは変化しなければなりません。さもなければ、自動的に有用性が低下します。
  • 複雑性増大の法則: 変更により、システムの構造はますます複雑になり、それを簡素化するためにより多くのリソースが必要になります。

変更要求管理は、激化する世界的な競争、技術の進歩、要求の厳しい顧客などにより多くの変化に直面している製造業においても非常に重要です。[ 4 ]多くのシステムは使用されるにつれて変化し進化する傾向があるため、これらの業界で生じる問題は、他の多くの業界でもある程度経験されています。

注: 以下のプロセスでは、変更委員会は承認/拒否の決定だけでなく、変更要求をバッチ処理する方法に影響を与える優先順位付けにも責任を負う必要があると考えられます。

プロセスとその成果物

変更要求管理プロセスの記述には、メタモデリング手法が用いられます。図1は、このセクションで説明する プロセスデータ図を示しています。

図1: 変更管理プロセスのプロセスデータモデル

活動

変更要求管理プロセスは、6つの主要なアクティビティで構成されます。それらは、潜在的な変更の特定、変更要求の分析、変更の評価、変更の計画、変更の実装、そして変更のレビューとクローズです。これらのアクティビティは、表1で説明する4つの異なる役割によって実行されます。アクティビティ（または該当する場合はサブアクティビティ）自体については、表2で説明します。

表1: 変更要求管理プロセスの役割の説明
役割説明
お客様顧客とは、発生した問題や新しい機能要件により変更を要求する役割です。顧客は個人または組織エンティティであり、変更の実装を依頼される会社の内外の場合があります。
プロジェクトマネージャープロジェクトマネージャーは、変更要求の対象となっているプロジェクトのオーナーです。場合によっては、変更マネージャーが別途任命され、そのマネージャーがこの役割を担うこともあります。
変更委員会変更委員会は、変更要求を実施するかどうかを決定します。このタスクは、プロジェクトマネージャーが担当する場合もあります。
チェンジビルダー変更ビルダーとは、変更を計画して実装する人です。計画コンポーネントは、プロジェクト マネージャーによって (部分的に) 引き受けられるとも言えます。
表2: 変更要求管理プロセスの活動の説明
活動サブアクティビティ説明
潜在的な変化を特定する新しい機能が必要[ 5 ]顧客は新しい機能を希望し、要件を策定します。
遭遇問題[ 5 ]顧客がシステム内で 問題 (バグなど)に遭遇し、これが問題報告につながります。
変更をリクエストする 顧客は変更要求を作成して変更を提案します。
変更要求を分析する技術的な実現可能性を判断する プロジェクト マネージャーは、提案された変更要求の技術的な実現可能性を判断し、変更の技術的な実現可能性を決定します。
コストと利益を決定する プロジェクトマネージャーは、提案された変更要求のコストと便益を決定し、その結果として変更コストと便益が算出されます。このアクティビティと上記のサブアクティビティは任意の順序で実行でき、互いに独立しているため、順序なしアクティビティとしてモデリングされます。
変化を評価する変更委員会は、変更要求、変更の技術的実現可能性、および変更のコストとベネフィットに基づいて、実施/中止の決定を下します。これは重要なプロセスステップであり、別の役割で実行されるため、独立したアクティビティとしてモデル化されています。Remko Helms（私信）の推奨に従い、サブアクティビティ（これを含むアクティビティは含まない）としてモデル化されています。
計画変更変更の影響を分析する 変更の範囲（つまり、変更が他のどの項目に影響を与えるか）は、「変更影響分析」で決定されます。このアクティビティは、別の実行/中止の決定につながる、あるいは「変更要求の分析」アクティビティの一部を構成するとも考えられます。ここでは、「変更の伝播」アクティビティとの関連性から、変更策定担当者の計画タスクとしてモデル化されています。
計画を作成する 変更計画は、変更の実施のために作成されます。一部のプロセス記述（例：Mäkäräinen, 2000）では、変更を「保存」し、後で一括処理することも可能であることが示されています。このアクティビティは、これを行うための良い機会と言えるでしょう。
変更を実行する変更を実行する 変更は「プログラム」されています。このアクティビティは、変更の伝播と密接な関係があります。変更をシステムの他の部分 (または他のシステム) にも適応させる必要がある場合があるためです。
変更を伝播する 「変更実行」によって生じた変更は、影響を受ける他のシステム部分に伝播する必要があります。このアクティビティと上記のサブアクティビティは相互に高い依存関係にあるため、並行アクティビティとしてモデル化されています。
テストの変更 変更担当者は、構築したものが実際に機能し、変更要求を満たしているかどうかをテストします。図に示されているように、これは上記の2つのサブアクティビティと併せて反復的なプロセスとなる可能性があります。
ドキュメントの更新 適用された変更を反映するためにドキュメントが更新されます。
リリースの変更 適用された変更を反映した新しいシステムリリースが公開されます。
変更を確認して終了する変更を確認する 新しいシステムリリースにおける変更の実装は、プロジェクトマネージャーによって最終検証されます。リリース前に検証する必要があるかもしれませんが、文献の矛盾やダイアグラムの複雑さを考慮し、この方法でモデル化し、この問題を含めることにしました。
変更を閉じる この変更サイクルは完了しました。つまり、変更ログエントリは終了しました。

成果物

プロセスデータ図（図1）には、アクティビティに加えて、各アクティビティの成果物、つまりデータも示されています。これらの成果物または概念は表3で説明されており、この文脈において最も重要な概念は「変更要求」と「変更ログエントリ」です。

いくつかの概念は著者によって定義されています（つまり、参照がありません）。これは、適切な定義が見つからなかったか、あるいは何らかの活動の結果として明らかになったためです。これらの概念にはアスタリスク（「*」）が付けられています。概念の特性はモデルから除外されています。そのほとんどは些細なものであり、そうしないと図がすぐに複雑になりすぎる可能性があるためです。さらに、一部の概念（例：変更要求、システムリリース）は、 Weerd [ 6 ]が提案したバージョン管理アプローチに適していますが、これも図の複雑さの制約により除外されています。

表3: 変更要求管理プロセスの概念の説明
コンセプト説明
要件コンポーネント (またはアイテム、NASA、2005) に必要な機能。
問題報告レベル 1 のヘルプ デスク従業員では解決できない問題を説明するドキュメント。日付、問題を報告した人の連絡先情報、問題の原因、問題の場所と説明、実行したアクションと処置などの項目が含まれますが、これは図には示されていません (Dennis 他、2002)。
変更リクエスト要求された変更とその重要性を記述した文書。問題報告、システム拡張、他のプロジェクト、基盤システムや経営陣の変更などから生じる可能性があり、ここでは「要件」として要約されます（Dennis, et al., 2002）。重要な属性：「実行/中止の決定」、つまり変更を実行するかどうかの決定。
変更ログエントリ*すべての変更（例：プロジェクト）の集合における個別のエントリ。変更要求、変更の技術的実現可能性、変更のコストと便益、変更の影響分析、変更計画、テストレポート、および変更検証で構成されます。プロセスが早期に終了する場合（つまり、変更が実施されない場合）、これらすべてを含める必要はありません。
技術的な実現可能性の変更「提案されたシステム（つまり変更要求）のニーズを満たすことができる信頼性の高いハードウェアとソフトウェア、技術リソースが、組織によって必要な時間内に取得または開発できるかどうか」を示す概念（Vogl、2004）。
コストとメリットの変更変更を実施するために予想される労力と、変更を実施することで得られるメリット（例：コスト削減、収益増加）。経済的実現可能性とも呼ばれます（Vogl, 2004）。
変化の影響分析変化の程度の評価。[ 7 ]
変更計画「何らかの目的を達成したり、何か（つまり変化）を達成したりするための計画、方法、またはデザイン」（ジョージタウン大学、nd）、この場合は変化です。
アイテム「システム、サブシステム、アセンブリ、サブアセンブリ、ユニット、セット、アクセサリ、コンピュータ プログラム、コンピュータ ソフトウェア、または部品を含む、あらゆる製品を表すために使用される非特定の用語」(Rigby、2003)。サブタイプとしてADDED ITEM と CHANGED ITEM (重複) があります。
追加アイテム*説明不要: 新しく作成された ITEM。ITEM のサブタイプ。
変更されたアイテム*説明不要: すでに存在していたが変更された ITEM。ITEM のサブタイプ。
テストレポート「[変更の影響を受ける]システムまたはコンポーネントに対して実行されたテストの実施と結果を記述した文書」(IEEE、1991)。
ドキュメントペンシルベニア州立大学図書館（2004年）の定義によると、文書とは「他の資料（通常は書籍以外のもの）に付随する印刷物であり、主要な資料の説明、使用方法の説明、あるいはガイドとして機能するもの」です。この文脈では、システム（の一部）に関連する限り、デジタル資料や研修資料も文書に含まれます。
システムリリース「販売または公開展示のために発行された商品」（プリンストン大学、2003年）。1つまたは複数の「品目」とそれに付随する「書類」から構成されます。
変更検証変更の実装の結果が以前に確立された要件を満たしているかどうかを判断します (Rigby、2003)。

「変更」だけでなく、逸脱と免除も区別することができます。[ 8 ]逸脱とは、ある項目の作成前に、その要件から逸脱することを承認（または要求）することです。免除は本質的に同じですが、項目の作成中または作成後に行われます。これら2つのアプローチは、最小限の変更要求管理（つまり、目の前の問題に対する真の解決策ではない）と見なすことができます。

例

変更要求管理プロセスの実際の良い例は、ソフトウェア開発に見ることができます。多くの場合、ユーザーはソフトウェア プログラムのバグを報告したり、新しい機能を希望したりし、これが変更要求につながります。次に、製品ソフトウェア会社は、この変更を実装するための技術的および経済的な実現可能性を検討し、その結果、変更が実際に実現されるかどうかを決定します。実際にそうなる場合、たとえばファンクション ポイントを使用して、変更を計画する必要があります。変更を実際に実行すると、ソフトウェア コードが作成または変更され、この変更が伝播すると、おそらく他のコード フラグメントも変更されます。最初のテスト結果が満足のいくものになったら、ドキュメントを最新の状態にして、ソフトウェアと一緒にリリースできます。最後に、プロジェクト マネージャーが変更を確認し、変更ログのこのエントリを閉じます。

図2: 自動車業界向けの変更要求の例
図2: 自動車業界向けの変更要求の例

ここで扱われているような変更要求管理のもう一つの典型的な領域は、製造分野です。たとえば、車の設計と製造を考えてみましょう。たとえば、長距離を走行した後に車のエアバッグに空気が自動的に充填されることがわかった場合、これは間違いなく顧客からの苦情（またはできればテスト段階での問題報告）につながります。次に、これらは変更要求を生み出します（右の図 2 を参照）。これはおそらく変更を正当化するでしょう。それでも、おそらくは単純化されたコストと利益の分析を行う必要があり、その後で変更要求を承認することができます。車の設計と製造スケジュールへの影響の分析に続いて、変更の実装計画を作成できます。この計画に従って、変更は実際に実現され、その後、車の新しいバージョンは、できれば一般にリリースされる前に徹底的にテストされます。

プロセスプラント

複雑なプロセスは小さな変更に対しても非常に敏感であるため、工業プロセスプラントに対する変更を適切に管理することが安全にとって非常に重要であると認識されています。文書化されておらず、適切にリスク評価されていない変更は、災害の原因となります。その顕著な例がフリックスボロー爆発であり、原子炉トレインのあるステージをバイパスするという即席の変更が事故の原因となりました。この変更は適切に検討、文書化、およびリスク評価されていなかったため、格納容器の破損イベントが特定されませんでした。[ 9 ]米国では、OSHAが変更をどのように行い、文書化するかについて規制を定めています。主な要件は、提案された変更を複数の専門分野にわたるチームで徹底的に検討し、できるだけ多くの観点を使用して危険を見逃す可能性を最小限に抑えることです。この文脈では、変更要求管理は変更管理、またはMOCとして知られています。これは、プロセス安全管理のセクション1910.119(l)の多くのコンポーネントの1つにすぎません。

参照

注釈と参考文献

  1. ^クンコビッチとペルソン・ダールクヴィスト (2003)。
  2. ^デニス、ウィクソム、ティーガーデン (2002)。
  3. ^ヒンリー 1996 .
  4. ^黄＆マック 1999 .
  5. ^ a b実際には、変更要求を発行するために、新機能の要件と問題の検出の両方が発生する必要はありません。通常はどちらか一方のみが該当します。これらを順序付けされていないアクティビティとしてモデル化することで、この意味に近づきます。代替案としては、変更要求を指す2つの別々の「開始点」（つまり初期状態）を作成する方法があります。
  6. ^ウィアード (2006).
  7. ^ラジリッヒ 1999 .
  8. ^スコット＆ニッセ（2001年）。
  9. ^マンナン（2012年）。

参考文献と参考文献

「 https://en.wikipedia.org/w/index.php?title=Change_management_(engineering)&oldid=1323467240」より取得