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

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

導入

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

変更要求管理は、影響を受けるシステムを改善して「顧客のニーズ」を満たすことでメリットをもたらす能力があることから受け入れられてきましたが、変更管理を混乱させ、不必要に複雑にする可能性があることからも批判されてきました。特に情報技術分野では、システムの初期作成よりも、システムのメンテナンス (および変更要求管理) に多くの資金と作業が投入されることがあります。^{[2]大規模な}ERPシステムの初期実装時に組織が行う典型的な投資は、全体の予算の 15 ～ 20 パーセントです。

同様に、Hinley ^[3]は、Lehmanのソフトウェア進化の法則のうち2つを説明しています。

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

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

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

プロセスとその成果

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

活動

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

成果物

プロセスデータダイアグラム (図 1) には、アクティビティのほかに、各アクティビティの成果物、つまりデータも表示されます。これらの成果物または概念については、表 3 で説明します。このコンテキストで最も重要な概念は、変更要求と変更ログエントリです。

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

単に「変更」だけでなく、逸脱と免除も区別することができます。^[7]逸脱とは、アイテムの作成前に、アイテムの要件から逸脱することを許可する（または要求する）ことです。免除は、アイテムの作成中または作成後に行われる点を除いて、基本的に同じです。これら 2 つのアプローチは、最小限の変更要求管理（つまり、目の前の問題に対する実際の解決策ではない）と見なすことができます。

例

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

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

プロセスプラント

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

参照

注釈と参考文献

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

参考文献と参考文献

Crnković I.、Aslkund、U.、Persson-Dahlqvist、A. (2003)。製品データ管理とソフトウェア構成管理の実装と統合。ロンドン：Artech House。
Dennis, A., Wixom, BH & Tegarden, D. (2002).システム分析と設計: UML によるオブジェクト指向アプローチ. ニューヨーク州ホーボーケン: John Wiley & Sons, Inc.
ジョージタウン大学 (nd).データウェアハウス: 用語集。2006 年 4 月 13 日に https://web.archive.org/web/20060423164505/http://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html から取得。
Hinley, DS (1996). ソフトウェア進化管理: プロセス指向の視点.情報とソフトウェア技術, 38 , 723–730.
Huang, GH & Mak, KL (1999). 英国製造業におけるエンジニアリング変更管理の最新実践International Journal of Operations & Production Management, 19 (1), 21–37.
IEEE (1991). Standard Glossary of Software Engineering Terminology (ANSI) . The Institute of Electrical and Electronics Engineers Inc. 2006 年 4 月 13 日に http://www.ee.oulu.fi/research/ouspg/sage/glossary/#reference_6 から取得。2009 年 10 月 21 日にWayback Machineにアーカイブ。
Mäkäräinen, M. (2000).組み込みソフトウェア開発におけるソフトウェア変更管理プロセス。博士論文。エスポー: VTT Publications。オンラインで入手可能: http://www.vtt.fi/inf/pdf/publications/2000/P416.pdf。
マンナン、サム(2012)。『プロセス産業における損失防止』（第 4 版）。オックスフォード:バターワース・ハイネマン。ISBN 978-0-12-397189-0 。
NASA (2005). NASA IV&V 施設メトリクスデータプログラム - 用語集と定義。2006 年 3 月 4 日に https://web.archive.org/web/20060307232014/http://mdp.ivv.nasa.gov/mdp_glossary.html から取得。
ペンシルベニア州立大学図書館 (2004)。CCLマニュアル: 用語と頭字語の用語集。2006 年 4 月 13 日に https://web.archive.org/web/20060615021317/http://www.libraries.psu.edu/tas/cataloging/ccl/glossary.htm から取得。
プリンストン大学 (2003). WordNet 2.0 . 2006 年 4 月 13 日に http://dictionary.reference.com/search?q=release から取得。
ラージリッヒ、V. (1999)。ソフトウェアの変化と進化。 Pavelka, J.、Tel, G. & Bartošek, M. (編)、SOFSEM'99、Lecture Notes in Computer Science 1725、189–202。
Rigby, K. (2003).標準の管理: 用語集. 2006 年 4 月 1 日に https://web.archive.org/web/20060412081603/http://sparc.airtime.co.uk/users/wysywig/gloss.htm から取得。
Scott, JA & Nisse, D. (2001)。ソフトウェア構成管理、ソフトウェアエンジニアリング知識体系ガイド、第 7 章、IEEE Computer Society Press。
Vogl, G. (2004).経営情報システム: 用語集. 2006 年 4 月 13 日に Uganda Martyrs University の Web サイトから取得: https://web.archive.org/web/20060411160145/http://www.321site.com/greg/courses/mis1/glossary.htm.
Weerd, I. van de (2006).メタモデリング手法: コース Method Engineering 05/06 の草稿。2006 年 3 月 1 日に https://bscw.cs.uu.nl/bscw/bscw.cgi/d1009019/Instructions ^{[ permanent dead link ‍ ]} for the process-data diagram.pdf [restricted access] から取得。

[1] クンコビッチとペルソン・ダールクヴィスト (2003)。

[2] デニス、ウィクソム、ティーガーデン (2002)。

[3] ヒンリー（1996年）。

[4] 黄＆馬（1999年）。

[note-5] 実際には、変更要求を取得するために、新しい機能の要件と検出された問題の両方が発生する必要はありません。通常は、2 つのうちの 1 つだけが発生します。これらを順序付けされていないアクティビティとしてモデル化することで、この意味に近づきます。別の方法としては、両方とも変更要求を指す 2 つの別々の「開始点」(つまり、初期状態) を作成することです。

[6] ウィアード（2006年）。

[7] スコット＆ニッセ（2001年）。

[8] マンナン（2012年）。