構成管理

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

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

はじめに

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

CMは、システムの変更を効果的に制御するために、パーツ、サブシステム、およびシステム間の機能的な関係を強調します。提案された変更が、悪影響を最小限に抑えるために体系的に考慮されていることを確認するのに役立ちます。システムへの変更は、一貫性を保証する標準化された体系的なアプローチを使用して提案、評価、および実装され、提案された変更は、システム全体への予想される影響の観点から評価されます。CMは、変更が規定どおりに実行され、アイテムとシステムのドキュメントが実際の構成を反映していることを確認します。完全なCMプログラムには、コンポーネント、サブシステム、およびシステムベースですべてのシステム情報を保存、追跡、および更新するためのプロビジョニングが含まれています。[6]

構造化されたCMプログラムは、アイテムのドキュメント(要件、設計、テスト、受け入れのドキュメントなど)が正確で、アイテムの実際の物理的なデザインと一致していることを保証します。多くの場合、CMがないと、ドキュメントは存在しますが、アイテム自体と一致していません。このため、エンジニア、請負業者、および管理者は、変更を進める前に、アイテムの実際のステータスを反映したドキュメントを作成することを余儀なくされることがよくあります。このリバースエンジニアリングプロセスは、人的およびその他のリソースの面で無駄であり、CMを使用して最小化または排除できます。

歴史

構成管理は、1950年代に米国国防総省でハードウェア材料アイテムの技術管理分野として始まり、現在では事実上すべての業界で標準的な手法となっています。国防総省が「480シリーズ」と呼ばれる一連の軍用規格(つまり、MIL-STD-480、MIL-STD-481、およびMIL-STD-483)を開発したとき、CMプロセスは1960年代後半に独自の技術分野になりました。その後、1970年代に発行されました。1991年に、「480シリーズ」はMIL–STD–973として知られる単一の規格に統合され、その後、業界の技術を支持して軍用規格の数を減らす一般的なDoD目標に従って、MIL–HDBK–61に置き換えられました。によってサポートされている規格標準化団体(SDO)。[7]これは、CMで最も広く配布され、受け入れられている標準であるANSI–EIA–649 –1998に進化したものの始まりを示しています。[8]現在、多くの組織や機関で広く採用されているCM分野の概念には、システムエンジニアリング(SE)、統合ロジスティクスサポート(ILS)、能力成熟度モデル統合(CMMI)、ISO 9000Prince2プロジェクト管理方法、COBITITIL製品ライフサイクル管理、およびアプリケーションライフサイクル管理これらの機能とモデルの多くは、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つの異なる分野で構成されています。これらの分野は[誰によって?]ベースラインを確立し、標準の変更管理プロセスを実行するためのポリシーと手順として。IEEE12207プロセスIEEE12207.2にもこれらのアクティビティがあり、「リリース管理と配信」が追加されています。 5つの分野は次のとおりです。

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

ソフトウェア

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

SCMプロセスは、変更を追跡する必要性と、最終的に提供されるソフトウェアに、リリースに含まれる予定のすべての計画された拡張機能があることを確認する機能をさらに定義します。健全なSCMプロセスを確実に実装するために、ソフトウェアプロジェクトごとに定義する必要のある4つの手順を特定します。彼らです:

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

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

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

構成管理データベース

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

CMS / CMDBの利点には、根本原因分析、影響分析、変更管理、将来の状態戦略開発のための現在の状態評価などの機能を実行できることが含まれます。一般にITサービス管理(ITSM)システムとして識別されるシステムの例には、FreshService、ServiceNow、およびSamanageが含まれます。

情報保証

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

メンテナンスシステム

構成管理は、最小のコストで最高レベルの保守性を維持することを目的として、複雑な資産のステータスの理解を維持するために使用されます。具体的には、資産(または資産の一部)が計画された寿命の制限を超えたり、品質レベルを下回ったりすることによって運用が中断されないようにすることを目的としています。

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

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

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

構成保守Promise理論は、Mark Burgess [16] [17] [18]によって開発され、リアルタイムの修復と予防保守を実行できるソフトウェアCFEngineの現在のコンピューターシステムに実際に実装されています。

予防保守

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

航空機、船舶、産業機械などの複雑な資産は、サービス可能な多くの異なるコンポーネントに依存しています。この保守性は、多くの場合、コンポーネントが新品から、取り付けられてから、修理されてから、その寿命にわたって使用された使用量、およびその他のいくつかの制限要因によって定義されます。これらの各コンポーネントの寿命がどれほど近いかを理解することは、ソフトウェアの最近の開発まで、労働集約的な記録管理を伴う主要な取り組みでした。

予知保全

多くのタイプのコンポーネントは、電子センサーを使用してデータをキャプチャし、ライブ状態監視を提供します。このデータは、機内または遠隔地でコンピューターによって分析され、現場での経験とモデリングを通じて障害の以前の例に基づいて潜在的な将来の障害を予測するアルゴリズムを使用して、現在の保守性とますます将来の可能性のある状態を評価します。これが「予知保全」の基本です。

CMが運用上の価値を提供するためには、正確でタイムリーなデータの可用性が不可欠であり、これが不足していることが制限要因となることがよくあります。運用データを取得してさまざまなサポート組織に配布すること自体が業界になりつつあります。

このデータの消費者は、相手先ブランド供給(OEM)によって提供されるプログラムの成長に伴い、より多く、複雑になっています。これらは、オペレーターに保証された可用性を提供し、オペレーターが資産を管理することで全体像をより複雑にするように設計されていますが、OEMはその保守性を確保する責任を負います。

標準

構成管理をサポートまたは含む多くの標準[19]には、次のものが含まれます。

  • ANSI / EIA-649-1998構成管理に関する全国コンセンサス規格
  • EIA-649-構成管理に関する2004年の全国コンセンサス標準
  • ANSI EIA-649-C2019構成管理規格
  • ISO 10007品質マネジメントシステム–構成管理のガイドライン
  • 連邦規格1037C
  • GEIA標準836–2002構成管理データ交換と相互運用性
  • ソフトウェアテストドキュメントのIEEE829標準
  • 828-2012システムおよびソフトウェアエンジニアリングにおける構成管理のためのIEEE標準2012. doi10.1109 /IEEESTD.2012.6170935ISBN 978-0-7381-7232-3
  • MIL-STD-973構成管理(2000年9月20日にキャンセル)[20]
  • NATO STANAG4427システムライフサイクル管理における構成管理
  • 構成管理に関するNATOACMP2000ポリシー
  • 構成管理に関するNATOACMP2009ガイダンス[21]
  • NATO ACMP2100構成管理の契約要件
  • CMMI CMMI for Development、バージョン1.2構成管理
  • エンタープライズ構成管理のためのCMII-100ECMII標準[22]
  • 構成管理および関連標準の拡張リスト[23]
  • ITILサービスの資産と構成の管理
  • ISO 20000:1 2011&2018サービス管理システム。
  • ECSS-M-ST-40CRev.1構成と情報管理[24]

ガイドライン

  • IEEE 828-2012 Standard for Configuration Management in Systems and Software Engineering、[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)の約80%の完成した建設を最初に比較することで構成管理の有効性が測定されました。レッドラインの2番目のセグメント、53億ドルの鉄道建設プロジェクト。この調査では、この種のプロジェクトで構成管理を使用することの利点を示す結果が得られました。[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. ^ 「土木工学の歴史と遺産」ASCE2007年2月16日にオリジナルからアーカイブされました2007年8月8日取得
  4. ^ 「土木学会土木工学とは」(PDF)ICE2006年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)国防技術情報センター2001年5月14日取得
  9. ^ アトラシアン。「構成管理データベース(CMDB)のガイド」アトラシアン2021年7月20日取得
  10. ^ Galusha、C。(2001年6月)。「IT資産管理の開始」ITプロフェッショナル3(3):37–40。土井10.1109 /6294.939973
  11. ^ 「ISO19770-1標準:IT資産管理を実装するためのガイド」SHIハブ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。「構成管理入門。;ログイン:発行:2011年4月、第36巻、第2号」(PDF)2012年11月23日取得
  15. ^ ロシュヴィッツ、マーティン(2014年11月14日)。「主要なオープンソース構成マネージャーからの選択」管理ネットワークとセキュリティカンザス州ローレンス:Linux New Media USALLC。
  16. ^ M. Burgess、Cfengine:サイト構成エンジン、USENIXコンピューティングシステム、Vol8、No。31995 [1]
  17. ^ M.バージェス、システム管理の理論について、Science of Computer Programming 49、2003年。p1-46pdf 2011 年7月24日にウェイバックマシンでアーカイブ
  18. ^ M.バージェス、進化する人間とコンピューターのシステムに対する構成可能な免疫、コンピュータープログラミングの科学51 2004、p197-213 pdf 2012 年3月3日にウェイバックマシンでアーカイブ
  19. ^ 「米軍のためのシステムのライフサイクル管理のための標準のNISTIR7339分析」(PDF)米国国立標準技術研究所。2006年8月。
  20. ^ 「ASSIST-QuickSearch-基本プロファイル」2011年9月27日。2011年9月27日のオリジナルからアーカイブ
  21. ^ a b http://nso.nato.int/nso/nsdd/APdetails.html?APNo=2422&LA=EN
  22. ^ 「CMの標準|構成管理研究所」2012年5月2日。2012年5月2日のオリジナルからアーカイブ
  23. ^ 「構成管理標準:CMおよび関連する業界標準の広範なリスト」CMPIC-構成管理プロセス改善センター
  24. ^ 「ECSS-M-ST-40CRev.1–構成および情報管理(2009年3月6日)|宇宙標準化のための欧州協力」ecss.nl。 _
  25. ^ 「IEEE828-2012-システムおよびソフトウェアエンジニアリングの構成管理のためのIEEE標準」Standards.ieee.org
  26. ^ https://www.iso.org/obp/ui/#iso:std:iso:10007:ed-3:v1:en
  27. ^ https://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=202239
  28. ^ https://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=279266
  29. ^ 「防衛獲得ガイドブック[DAG]」2013年2月13日。2013年2月13日のオリジナルからアーカイブ
  30. ^ 「アーカイブされたコピー」(PDF)www.dau.mil2017年1月31日にオリジナル(PDF)からアーカイブされました2022年1月11日取得 {{cite web}}: CS1 maint: archived copy as title (link)
  31. ^ 「構成管理計画」AcqNotes
  32. ^ 輸送管理システムハンドブックのための構成管理連邦高速道路局2012年3月28日取得
  33. ^ 構成管理のケーススタディPACO Technologies、Inc2016年8月26日にオリジナルからアーカイブされました2012年3月28日取得