構成管理
製品特性と設計の一貫性を維持するためのプロセス

トップレベルの構成管理アクティビティモデル

構成管理（CM）は、製品の性能、機能、物理的特性とその要件、設計、運用情報との一貫性を、製品のライフサイクル全体にわたって確立し維持するための管理プロセスです。[1] [2] CMプロセスは、兵器システム、軍用車両、情報システムなどの複雑なシステムのシステムライフサイクル全体にわたる変更を管理するために、軍事工学組織で広く使用されています。軍事以外では、CMプロセスは、 ITILで定義されているITサービス管理や、道路、橋、運河、ダム、建物などの土木工学やその他の産業工学分野の他のドメインモデルでも使用されています。[3] [4] [5]

導入

システムのライフサイクル全体にわたって適用されるCMは、システムの性能、機能、および物理的特性の可視性と制御を提供します。CMは、システムが意図したとおりに動作し、計画されたライフサイクルをサポートするのに十分な詳細度で識別および文書化されていることを確認します。CMプロセスは、機能の改訂、性能、信頼性、保守性の向上、寿命の延長、コストの削減、リスクと責任の軽減、欠陥の修正といった有益な目的のために、システム情報とシステム変更を秩序正しく管理することを容易にします。CMの実装にかかるコストは比較的低く、コスト回避によって何倍にも回収されます。CMの欠如、または効果的な実装の欠如は、非常に大きなコストを伴い、機器の故障や人命の損失といった壊滅的な結果をもたらす可能性があります。

CMは、システム変更を効果的に管理するために、部品、サブシステム、およびシステム間の機能的関係を重視します。提案された変更が体系的に検討され、悪影響を最小限に抑えているかどうかを検証するのに役立ちます。システムへの変更は、一貫性を確保する標準化された体系的なアプローチを用いて提案、評価、実装され、提案された変更は、システム全体への予想される影響の観点から評価されます。CMは、変更が規定どおりに実行され、アイテムおよびシステムの文書がその実際の構成を反映しているかどうかを検証します。完全なCMプログラムには、コンポーネント、サブシステム、およびシステムベースで、すべてのシステム情報を保存、追跡、および更新するための規定が含まれています。[6]

構造化されたCMプログラムは、アイテムに関するドキュメント（要件、設計、テスト、受入に関するドキュメントなど）が正確であり、アイテムの実際の物理設計と一致していることを保証します。CMがない場合、ドキュメントは存在するものの、アイテム自体と一致していないことがよくあります。このため、エンジニア、請負業者、経営陣は、変更を進める前に、アイテムの実際の状態を反映したドキュメントを作成せざるを得ないことがよくあります。このリバースエンジニアリングプロセスは、人的資源やその他のリソースの面で無駄が多く、CMを使用することで最小限に抑えるか、完全に排除することができます。

歴史

構成管理（CM）は、1950年代に米国国防総省でハードウェア材料品目の技術管理分野として始まり、現在ではほぼすべての業界で標準的な手法となっています。CMプロセスは、1960年代後半に国防総省が「480シリーズ」（MIL-STD-480、MIL-STD-481、MIL-STD-483）と呼ばれる一連の軍事規格を策定した際に、独自の技術分野となりました。これらの規格は1970年代に発行されました。1991年、「480シリーズ」はMIL-STD-973と呼ばれる単一の規格に統合され、その後、標準化団体（SDO）が支援する業界技術規格を優先し、軍事規格の数を減らすという国防総省の目標に基づき、MIL-HDBK-61に置き換えられました。[7]これが、現在ではCMに関して最も広く配布され受け入れられている標準であるANSI–EIA–649 –1998へと発展したものの始まりとなりました。[8]現在では数多くの組織や機関に広く採用されているCM分野の概念には、システムエンジニアリング（SE）、統合ロジスティクスサポート（ILS）、能力成熟度モデル統合（CMMI）、ISO 9000、Prince2プロジェクト管理手法、COBIT、ITIL、製品ライフサイクル管理、アプリケーションライフサイクル管理などがあります。これらの機能やモデルの多くは、CMを従来の技術管理に対する全体論的なアプローチから再定義しました。中にはCMを図書館員の活動に似たものとみなし、変更管理または変更管理を別個の、あるいは独立した分野として切り離す人もいます。

概要

CM は、システムが長期にわたって整合性を維持できるように、変更を体系的に処理する実践です。CM は、管理、提案された変更の評価、変更の状態の追跡、システムの変更時のシステムおよびサポート ドキュメントのインベントリの維持を行うポリシー、手順、手法、およびツールを実装します。CM プログラムと計画は、複雑なシステムを正常に開発およびサポートするために必要な手順、機能、サービス、ツール、プロセス、およびリソースの開発と実装に対する技術的および管理上の指示を提供します。システム開発中、CM により、プログラム管理は受け入れから運用および保守まで、ライフサイクル全体にわたって要件を追跡できます。要件と設計に変更が生じることは避けられないため、変更は承認され、文書化されて、システムの状態の正確な記録が作成される必要があります。理想的には、CM プロセスはシステムのライフサイクル全体に適用されます。多くの専門家は、手元にある資産をインベントリする資産管理(AM、 ISO/IEC 19770も参照)と混同または混同しています。 CMとAMの主な違いは、前者は財務会計の側面を管理するのではなく、システムがサポートするサービスを管理すること、言い換えれば後者（AM）はIT資産から価値を実現しようとしていることです。[9] [10] [11]

ハードウェア構成アイテムとソフトウェア構成アイテムの両方に対するCMプロセスは、MIL-HDBK-61A [12]およびANSI/EIA-649で規定されている5つの異なる分野で構成されています。標準的な変更管理プロセスの適用に関心のある組織のメンバーは、これらの分野を、ベースラインの設定、変更の管理と制御、進捗の有効性と正確性の監視と評価のためのポリシーと手順として採用します。IEEE 12207プロセス（IEEE 12207.2）にもこれらの活動が含まれており、「リリース管理と配信」が追加されています。 5つの分野は次のとおりです。

  1. CM 計画と管理: 次のような項目を含む CM プログラムをガイドする正式な文書と計画:
    • 人事
    • 責任とリソース
    • トレーニング要件
    • 手順とツールの定義を含む管理会議ガイドライン
    • ベースラインプロセス
    • 構成制御と構成ステータスのアカウンティング
    • 命名規則
    • 監査とレビュー
    • 下請け業者/ベンダーのCM要件
  2. 構成識別（CI）：ベースラインの設定と維持から成り、システムまたはサブシステムのアーキテクチャ、コンポーネント、およびあらゆる開発を任意の時点で定義します。これは、システムのあらゆる部分への変更を識別、文書化し、設計、開発、テスト、そして最終的な納品まで追跡するための基礎となります。CIは、システムとその構成アイテム（CI）のライフサイクル（開発、運用、展開、運用サポート）全体を通して、廃棄に至るまで、構成ステータス・アカウンティング（CSA）の最終的な最新基準を段階的に確立し、維持します。
  3. 構成管理：すべての変更要求および変更提案の評価、ならびにそれらの承認または不承認が含まれます。システムの設計、ハードウェア、ファームウェア、ソフトウェア、およびドキュメントへの変更を管理するプロセスが含まれます。
  4. 構成ステータス管理：構成アイテム（ハードウェア、ソフトウェア、ファームウェアなど）の説明と、設計および製造中のベースラインからの逸脱をすべて記録および報告するプロセスが含まれます。問題が疑われる場合、ベースライン構成の検証と承認済み変更を迅速に判断できます。
  5. 構成検証および監査：定められた性能要件、商用および適切な軍事規格、機能ベースライン、割り当てベースライン、および製品ベースラインへの準拠を評価することを目的とした、ハードウェアおよびソフトウェアの独立したレビュー。構成監査では、システムおよびサブシステムの構成文書が、アーキテクチャベースラインへの承認前に、機能的および物理的な性能特性に準拠していることを確認します。

ソフトウェア

ソフトウェア構成管理（SCM）プロセスは、実務家からソフトウェアプロジェクトにおける変更管理の最善のソリューションと見なされています。SCMは、ソフトウェアの機能的および物理的属性を様々な時点で特定し、特定された属性への変更を体系的に管理することで、ソフトウェア開発ライフサイクル全体を通じてソフトウェアの整合性とトレーサビリティを維持します。

SCMプロセスでは、変更の追跡の必要性と、最終的に納品されるソフトウェアにリリースに含まれる予定のすべての機能強化が含まれていることを検証する能力も定義されています。また、健全なSCMプロセスを確実に実装するために、各ソフトウェアプロジェクトで定義する必要がある4つの手順も特定されています。それらは以下のとおりです。

  1. 構成識別
  2. 構成管理
  3. 構成ステータスのアカウンティング
  4. 構成監査

これらの用語と定義は標準ごとに異なりますが、本質的には同じです。

  • 構成識別とは、構成アイテムのあらゆる側面を定義する属性を特定するプロセスです。構成アイテムとは、エンドユーザー向けの製品（ハードウェアおよび／またはソフトウェア）です。これらの属性は構成ドキュメントに記録され、ベースライン化されます。属性をベースライン化することで、これらの属性が変更された場合に、正式な構成変更管理プロセスが実行されるようになります。
  • 構成変更管理は、構成項目の属性を変更し、それらを再ベースライン化するために必要な一連のプロセスと承認段階です。
  • 構成ステータス アカウンティングは、各構成項目に関連付けられた構成ベースラインをいつでも記録およびレポートする機能です。
  • 構成監査は、機能構成監査と物理構成監査に分けられます。これらは、納品時または変更実施時に実施されます。機能構成監査では、構成アイテムの機能およびパフォーマンス属性が達成されていることを確認します。一方、物理構成監査では、構成アイテムが詳細設計文書の要件に従ってインストールされていることを確認します。

構成管理データベース

ITILは、構成管理における業界のベストプラクティスを実現する手段として、構成管理システム（CMS）または構成管理データベース（CMDB）の使用を規定しています。CMDBは、構成アイテム（CI）とそれらの依存関係を追跡するために使用されます。CIは、企業内で追跡および管理する価値のあるもの（コンピュータ、ソフトウェア、ソフトウェアライセンス、ラック、ネットワークデバイス、ストレージ、さらにはそれらのアイテム内のコンポーネントなど）を表します。CMSは、CMDBの 統合コレクションの管理に役立ちます。

CMS/CMDB の利点には、根本原因分析、影響分析、変更管理、将来の状態戦略開発のための現在の状態評価などの機能を実行できることが含まれます。

構成管理（CM）は、ITIL固有のITSMプロセスであり、 ITシステム内の個々のCI（構成オブジェクト）をすべて追跡します。CIは、単一のサーバーのような単純なものから、IT部門全体のような複雑なものまで多岐にわたります。大規模な組織では、CMプロセスを監督・管理するために構成マネージャーが任命されることがあります。ITILバージョン3では、このプロセスはサービス資産および構成管理に名称が変更されました。

情報保証

情報保証の場合、CMは、情報システムのライフサイクル全体にわたるハードウェア、ソフトウェア、ファームウェア、ドキュメント、テスト、テストフィクスチャ、テスト文書への変更を制御することを通じて、セキュリティ機能と保証を管理することと定義できます。[13] [より適切な出典が必要]情報保証のためのCMは、セキュア構成管理（SCM）と呼ばれることもあり、ITプラットフォームと製品およびその環境のパフォーマンス、機能、および物理的特性に依存して、システム構成の状態を測定するために使用される適切なセキュリティ機能と保証を決定します。たとえば、組織のインターネット境界の一部として機能するネットワークファイアウォールと、内部のローカルネットワークファイアウォールとして機能する ネットワークファイアウォールでは、構成要件が異なる場合があります。

メンテナンスシステム

構成管理は、複雑な資産の状態を把握し、最高レベルの保守性を最低コストで維持するために使用されます。具体的には、資産（または資産の一部）が計画寿命を超過したり、品質レベルを下回ったりすることで業務が中断されないようにすることを目的としています。

軍隊では、この種の活動はしばしば「任務準備」として分類され、どの資産がどの種類の任務に利用可能かを定義することを目的としています。典型的な例としては、航空母艦に搭載されている航空機に地上支援用の爆弾が装備されているか、防御用のミサイルが装備されているかが挙げられます。

オペレーティングシステムの構成管理

構成管理はOS構成ファイルの維持に使用できます。[14]これらのシステムの多くは、構成の定義と維持にインフラストラクチャ・アズ・コードを利用しています。[15]

構成保守のPromise理論はマーク・バージェスによって開発され[16] [17] [18]、CFEngineというソフトウェアで今日のコンピュータシステムに実用的に実装され、リアルタイム修復と予防保守を実行できるようになりました。

予防保守

資産とその主要コンポーネントの「現状」を理解することは、保守、修理、オーバーホール、および企業資産管理システムで使用される予防保守の重要な要素です。

航空機、船舶、産業機械などの複雑な資産は、様々な部品の保守性に依存しています。この保守性は、部品の新品時、取り付け時、修理時の使用頻度、耐用年数全体にわたる使用頻度、その他様々な制約要因によって定義されることが多いです。近年のソフトウェア開発までは、これらの部品の寿命がどの程度近づいているかを把握することは、膨大な記録管理を伴う大変な作業でした。

予測メンテナンス

多くの種類のコンポーネントは、電子センサーを使用してデータを収集し、リアルタイムの状態監視を提供します。このデータは、車載または遠隔地のコンピュータによって分析され、現場での経験とモデリングに基づく過去の故障事例に基づいて将来の潜在的な故障を予測するアルゴリズムを用いて、現在の保守性を評価し、さらに将来の状態の可能性も評価します。これが「予知保全」の基礎です。

CMが運用上の価値を提供するには、正確かつタイムリーなデータの入手が不可欠であり、これが不足すると、しばしば制約要因となります。運用データを収集し、様々なサポート組織に配信することは、それ自体が一つの産業になりつつあります。

OEM（相手先ブランド供給メーカー）が提供するプログラムの拡大に伴い、このデータの利用者はますます増加し、複雑化しています。これらのプログラムは、事業者に可用性を保証することを目的として設計されており、事業者が資産を管理する一方で、OEMがその保守性を確保する責任を負うという複雑な状況を生み出しています。

標準

構成管理をサポートまたは含む標準は数多くあり、[19]次のようなものがあります。

  • ANSI/EIA-649-1998 構成管理に関する国家コンセンサス規格
  • EIA-649-A 2004 構成管理に関する国家コンセンサス規格
  • SAE EIA-649-C 2019 グローバルコンセンサス構成管理規格
  • ISO 10007品質マネジメントシステム – 構成管理のガイドライン
  • 連邦規格1037C
  • GEIA規格836–2002 構成管理データ交換および相互運用性
  • ソフトウェアテストドキュメントのIEEE 829標準
  • システムおよびソフトウェアエンジニアリングにおける構成管理のIEEE標準。 2012年。doi : 10.1109/IEEESTD.2012.6170935。ISBN 978-0-7381-7232-3。
  • MIL-STD-973 構成管理（2000年9月20日に廃止）[20]
  • NATO STANAG 4427 システムライフサイクル管理における構成管理を含む
  • NATO ACMP 2000 構成管理に関するポリシー
  • NATO ACMP 2009 構成管理に関するガイダンス[21]
  • NATO ACMP 2100 構成管理契約要件
  • CMMI開発のためのCMMI バージョン1.2 構成管理
  • CMII-100E エンタープライズ構成管理のための CMII 標準[22]
  • 構成管理および関連標準の拡張リスト[23]
  • ITIL サービス資産および構成管理
  • ISO 20000:1 2011& 2018 サービス管理システム。
  • ECSS-M-ST-40C Rev.1 構成および情報管理[24]

ガイドライン

  • IEEE 828-2012 システムおよびソフトウェアエンジニアリングにおける構成管理の標準、[25]発行日:2012-03-16
  • ISO 10007:2017 品質マネジメント – 構成管理のガイドライン[26]
  • NATO ACMP-2009 – 構成管理に関するガイダンス[21]
  • ANSI/EIA-632-1998 システムエンジニアリングのプロセス
  • ANSI/EIA-649-1998 構成管理に関する国家コンセンサス規格
  • GEIA-HB-649 – 構成管理の実装ガイド
  • EIA-836 構成管理データ交換および相互運用性に関するコンセンサス標準
  • MIL-HDBK-61B 構成管理ガイダンス、[27] 2020年4月7日
  • MIL-STD-3046 構成管理、[28] 2013年3月6日制定、2015年6月1日廃止
  • 国防調達ガイドブック[29] 4.3.7 SEプロセスのCMの要素、5.1.7ライフサイクルサポートのCMの属性
  • システムエンジニアリングの基礎、第10章構成管理[30]
  • 構成管理計画米国国防総省調達文書[31]

工事

近年では（いつから？）、構成管理は、しばしば非常に複雑で、膨大な詳細や変更事項を文書化する必要がある大規模な建設プロジェクトにも適用されるようになりました。連邦道路局などの建設機関は、インフラプロジェクトに構成管理を活用しています。[32]建設現場向けの構成管理ツールの中には、変更指示書や情報提供依頼書（RFI）を文書化し、プロジェクトがスケジュール通りに予算内で完了することを保証するものがあります。これらのプログラムは、インフラ完成後の保守や改修を支援するための情報も保存できます。そのようなアプリケーションの1つであるCCSNetは、連邦運輸局（FTA）の資金提供を受けたケーススタディでテストされました。このケーススタディでは、ロサンゼルス郡都市圏交通局（LACMTA）が53億ドル規模の鉄道建設プロジェクトであるレッドラインの第1区間と第2区間の約80%完成段階を比較することで、構成管理の有効性を測定しました。この研究では、この種のプロジェクトにおいて構成管理を活用することのメリットを示す結果が得られました。[33]

参照

ウィキメディア コモンズには、構成管理に関連するメディアがあります。

参考文献

  1. ^ 「MIL-HDBK-61A、「軍事ハンドブック：構成管理ガイダンス」」。国防総省。2001年2月7日。2012年3月20日時点のオリジナルよりアーカイブ。 2012年3月24日閲覧。
  2. ^ 「ANSI/EIA-649B、「構成管理に関する国家コンセンサス規格」」。TechAmerica。2011年4月1日。2012年8月1日時点のオリジナルよりアーカイブ。 2012年3月24日閲覧。
  3. ^ 「土木工学の歴史と遺産」ASCE . 2007年2月16日時点のオリジナルよりアーカイブ。2007年8月8日閲覧。
  4. ^ 「土木技術者協会 土木工学とは何か」（PDF）ICE . 2006年9月23日時点のオリジナル（PDF）からアーカイブ。 2007年9月22日閲覧。
  5. ^ 「構成管理と連邦運輸局（FTA）の国家教訓プログラム」連邦運輸局。2012年9月7日時点のオリジナルよりアーカイブ。 2007年9月22日閲覧。
  6. ^ 「システムエンジニアリングの基礎」（PDF） 。国防調達大学出版局。2001年1月。 2006年2月11日時点のオリジナル（PDF）からアーカイブ。 2012年3月25日閲覧。
  7. ^ 「覚書、仕様、標準 – 新しいビジネスのやり方」国防長官、1994年6月29日。2013年10月21日時点のオリジナルよりアーカイブ。 2012年3月23日閲覧。
  8. ^ 「構成管理コンプライアンス検証：批判的レビューおよび技術評価（CR/TA）レポート」（PDF）。国防技術情報センター。2022年10月9日時点のオリジナルよりアーカイブ（PDF） 。 2001年5月14日閲覧。
  9. ^ Atlassian. 「構成管理データベース（CMDB）ガイド」. Atlassian . 2021年7月20日閲覧。
  10. ^ Galusha, C. (2001年6月). 「IT資産管理入門」. IT Professional . 3 (3): 37– 40. Bibcode :2001ITPro...3c..37G. doi :10.1109/6294.939973.
  11. ^ 「ISO 19770-1規格：IT資産管理の実装ガイド」SHI Hub 2018年1月30日2021年7月20日閲覧。
  12. ^ 「軍事ハンドブック：構成管理ガイダンス」（PDF）。米国国防総省。p. iii–iv 。2016年7月21日閲覧。4 . CMライフサイクル管理および計画 [...] 5. 構成識別 [...] 6. 構成制御 [...] 7. 構成ステータスアカウンティング [...] 8. 構成検証および監査 [...] 9. データ管理 [...]
  13. ^ 国家情報システムセキュリティ用語集
  14. ^ C. Lueninghoener. 「構成管理入門. ;login: 発行: 2011年4月、第36巻、第2号」(PDF) 。 2022年10月9日時点のオリジナルよりアーカイブ(PDF) 。 2012年11月23日閲覧。
  15. ^ Loschwitz, Martin (2014年11月14日). 「主要なオープンソース構成マネージャの選択」. Admin Network & Security . ローレンス、カンザス州: Linux New Media USA LLC.
  16. ^ M. Burgess, Cfengine: サイト構成エンジン, USENIX Computing systems, Vol8, No. 3 1995 [1]
  17. ^ M. Burgess, システム管理理論について, Science of Computer Programming 49, 2003. p1-46 pdf 2011年7月24日アーカイブ, Wayback Machine
  18. ^ M. Burgess, 進化する人間-コンピュータシステムのための設定可能な免疫力, Science of Computer Programming 51 2004, p197-213 pdf 2012年3月3日アーカイブ, Wayback Machine
  19. ^ 「NISTIR 7339 米陸軍システムライフサイクル管理基準の分析」(PDF) 。米国国立標準技術研究所。2006年8月。 2016年12月21日時点のオリジナル(PDF)からアーカイブ。 2015年11月25日閲覧。
  20. ^ “ASSIST-QuickSearch - Basic Profile”. 2011年9月27日. オリジナルより2011年9月27日時点のアーカイブ。
  21. ^ ab [2] [リンク切れ]
  22. ^ “Standards for CM | Institute of Configuration Management”. 2012年5月2日. オリジナルより2012年5月2日時点のアーカイブ。
  23. ^ 「構成管理標準：CMおよび関連業界標準の広範なリスト」。CMPIC - 構成管理プロセス改善センター。
  24. ^ "ECSS-M-ST-40C Rev.1 – 構成および情報管理（2009年3月6日）| 欧州宇宙標準化協力". ecss.nl .
  25. ^ 「IEEE 828-2012 - システムおよびソフトウェアエンジニアリングにおける構成管理のIEEE標準」。IEEE。
  26. ^ 「ISO 10007:2017(en) 品質管理 - 構成管理のガイドライン」. iso.org . 2023年11月29日閲覧。
  27. ^ 「ASSIST-QuickSearch Document Details」. Quicksearch.dla.mil . 2022年8月28日閲覧。
  28. ^ 「ASSIST-QuickSearch Document Details」. Quicksearch.dla.mil . 2022年8月28日閲覧。
  29. ^ “Defense Acquisition Guidebook [DAG]”. 2013年2月13日. オリジナルより2013年2月13日時点のアーカイブ。
  30. ^ 「アーカイブコピー」（PDF）www.dau.mil . 2017年1月31日時点のオリジナル（PDF）からアーカイブ。2022年1月11日閲覧。{{cite web}}: CS1 maint: archived copy as title (link)
  31. ^ 「構成管理計画」AcqNotes。
  32. ^ 「運輸管理システムの構成管理ハンドブック」連邦道路局. 2012年3月28日閲覧。
  33. ^ 「構成管理のケーススタディ」PACO Technologies, Inc. 2016年8月26日時点のオリジナルよりアーカイブ。2012年3月28日閲覧。
Retrieved from "https://en.wikipedia.org/w/index.php?title=Configuration_management&oldid=1328843020"