Habréには、CMMIモデルに関する情報がほとんどないことを知って驚いた 。
欧米では、ソフトウェア開発の大量注文は、国際標準への準拠が認定されている企業にのみ長い間信頼されており、多くの場合、CMMIモデルになります。 このモデルの作成者自身は繰り返しますが、これは標準ではなく、組織内のプロセスを改善するための推奨事項の集まりにすぎません。
CMMIとは何ですか？
ウィキペディアには次の定義があります。
Capability Maturity Model Integration（CMMI） -生産性と成熟度の包括的なモデル-さまざまな規模や活動の組織のプロセスを改善するための一連のモデル（方法論）。 CMMIには一連の推奨事項がプラクティスの形式で含まれており、その実装により、モデルの開発者によると、特定のアクティビティ領域の完全な実装に必要な目標を実現できます。
このモデルはどこから来たのですか？
実際には、CMMのみが最初に登場し、CMMIは元のモデルの一貫した開発の結果であり、他の多くのモデルを吸収しました。 1980年代半ば、米国国防総省は、注文のために開発されたソフトウェアの品質を改善するという問題に直面しました。 同意します、あなた自身がアメリカのロケットが偶然あなたの家に向かって飛ぶことはないことを知って、あなたはより穏やかに生きるでしょうか？ さらに、お金は予算であり、予算は通常、ゴムではなく計画されていたため、開発の品質に加えて、請負業者は定められた予算内で注文を完了する必要がありました。
問題は次のように解決されました。防衛省の命令のすべての潜在的な執行者が評価されたモデルを作成することによって。 このモデルを開発するタスクは、ペンシルベニア州ピッツバーグの輝かしい都市にあるカーネギーメロン大学に基づいて作成されたソフトウェアエンジニアリング研究所に委ねられました。
このモデルを作成するために、ソフトウェア開発中に実行される主要なアクティビティとそれらに関連するリスクの分析が実行されました。 特定のリスクを回避または軽減するのに成功したプラクティスと、最悪のプラクティス-品質の問題、期限の遵守の失敗、予算の超過につながる典型的なミスの両方を分析しました。 各主要なアクティビティ（または目標）に対して、モデルは、対応するプロジェクトリスクを除去または大幅に削減できる多数のプラクティスを提供します。 そして、すべての活動は、いわゆるでグループ化されました プロセス領域。 1987年には、将来のモデルのプロトタイプが登場しました。実際には、合計85のプロセスと16の技術的な質問を含むアンケートで、その回答により、評価された企業が5段階の成熟度の1つになりました。
時間が経つにつれて、プロセス領域の数と内容のみが変更されました。 しかし、成熟度の概念は、このモデルで20年以上も変わらないものです。
ちなみに、成熟度レベル...
成熟度レベルは、CMMIモデルに基づく評価の主要な最終指標です。
成熟度の最初のレベルのプロセスは、ランダム性、反応性、予測不能性によって特徴付けられます。 それにもかかわらず、開発のこの段階の組織は、かなり高品質の製品を生産することが非常に多くあります。 同時に、原則として、これらの製品の予算と開発時間を超えています。 これらの組織の高品質な製品は、安定した確立されたプロセスではなく、個人の力強い努力のおかげで生産されています。 そのような人々の退去の場合、成功したプロジェクトを繰り返すことは非常に困難です。 この段階では、組織で行われているプロセスのパフォーマンスを予測することは非常に困難です。 レベル1では、生産プロセス（およびすべてのプロセス）は不定形の実体、ほとんどブラックボックスであるように見えます。プロセスの概念は非常に限定されており、プロジェクトの開発ステータスと作業の現在の進行状況を明確にするために多大な労力が費やされています。
原則として、小規模な企業が独自のプロジェクトや小規模なプロジェクトを開発している場合、これは受け入れられます。 ただし、CMMIモデルは必要ありません。 このモデルは、非常に大きなプロジェクトを開発する際に、その栄光のすべてに現れます。 そのため、成熟度のレベルをさらに上げていきます。
成熟度レベル2は管理可能なレベルです。 この段階では、主なプロセスが説明されていますが、繰り返し使用することができます。 つまり、組織が実施するプロジェクトは要件を満たしています。 プロセスは管理可能であり、計画、実行、測定、および制御されます。 ただし、プロセスには本質的にある程度の反応性があります。 レベル2では、顧客の要件と中間製品が監視され、基本的なプロジェクト管理プラクティスが確立されます。 これらのツールを使用すると、プロジェクトを管理できますが、プロジェクトの断片的なビューを提供します。 実際、生産プロセスは一連のブラックボックスとして表すことができ、プロジェクトの真のビジョンは中間段階にのみ存在します。
成熟度レベル3-特定のレベル。 この場合、プロセスが定義されます。 組織内で確立された標準。 この段階では、プロセスは個々のプロジェクトのレベルではなく、組織全体のレベルで説明されます。 関係と依存関係がより良く開示されているすべてのプロセスのより詳細な説明があり、その知識が管理を改善します。 このレベル-レベル3-では、ブラックボックスの内部が表示されます。 この内部構造は、組織の標準的な生産プロセスが適用される方法を反映しています。
成熟度レベル4は、定量的に制御されるレベルです。 この段階で、以前のレベルのすべての目標が達成されました。 統計的手法やその他の定量的手法を使用する場合、プロセスの品質を制御できるサブプラクティスが選択されています。 この段階と前の段階との最も重要な違いは、プロセスの効率の予測可能性とプロセスの管理能力（効率）です。 レベル4では、特定のプロセスが適切なツールと手法を使用して定量的に制御されます。
成熟度レベル5-プロセスの継続的な改善（最適化）のレベル。 この段階では、ビジネスプロセスの有効性を評価するための正確な特性があります。これにより、既存の手法や手法を開発し、新しい手法や手法を導入することで、ビジネスプロセスを常に効果的に改善できます。
...およびプロセス領域。
プロセス領域は、モデル全体の構成要素です。 CMMIは22のプロセス領域を定義しています。 プロセス領域ごとに、このプロセス領域にCMMIを実装するときに達成しなければならない多くの目標があります。 いくつかの目標はユニークです-それらは特別と呼ばれます。 共通の目標は、いくつかのプロセス領域に適用されます。 目標は実践を通じて達成されます。 目標と同様に、プラクティスは特別なものと一般的なものに分けられます。
そして、各名前の短いトランスクリプトを含むプロセス領域のリストは次のとおりです。
- 要件管理
要件とプロジェクト計画の間の不一致を識別するためのプロジェクト製品または製品コンポーネントの要件の管理。 - プロジェクト計画
プロジェクトの開発を決定する計画の開発と保守。 - プロジェクトの監視と制御（プロジェクトの監視と制御）
計画から重大な逸脱がある場合に是正措置を講じるために、プロジェクト開発段階の理解を提供します。 - サプライヤー契約管理
契約を締結する外部サプライヤーからの商品およびサービスの取得の管理。 - 測定と分析
情報管理のニーズをサポートするために使用される測定機能の開発と維持。 - 商品およびプロセスの品質の評価（保証）（プロセスおよび製品品質保証）
プロセス目標および関連する作業成果物に従ってサポートと管理を提供します。 - 構成管理
構成識別、構成制御、および構成監査の使用の結果としての作業成果物の整合性のインストールおよび保守。 - 要件開発
製品および製品コンポーネントの顧客要件の収集と分析。 - テクニカルソリューション
関連する要件に対するソリューションの開発、設計、および実装。 決定、設計、実装は、製品、製品コンポーネント、およびこれらの製品に関連するプロセスによって表されます。 - 製品統合
コンポーネントから製品を組み立て（マウント）、統合の品質、機能、および製品リリースを確認します。 - 検証
選択した作業成果物が要件を満たしていることを確認します。 - 検証
製品とそのコンポーネントが、意図された環境での意図された使用に対応することのデモンストレーション。 - 組織プロセスに焦点を当てる
組織プロセスおよびプロセス資産の理解を確立および維持し、これらの分野に関連する改善点を特定、計画、および実装します。 - 組織プロセスの説明
使用できる組織プロセスの配列を確立および維持します。 - 組織トレーニング
人々の役割を効果的かつ効率的に果たすために、人々の知識と能力を向上させる。 - プロジェクト統合管理
統合および定義されたプロセスへのすべての関係者のインストールおよびプロジェクト管理と関与。 この領域は、開発チームによるプロジェクトの全体的なビジョンにも影響します。 - リスク管理
潜在的な問題を発生前に特定します。 この点で、リスク低減プロセスは、製品またはプロセス開発のどの段階でも計画および実行できます。 - 統合チーム
作業成果物（作業成果物）の開発のための統合チームの形成と保守。 - 統合サプライヤー管理
新製品の監視、プロジェクト要件を満たすことができる製品のソースの評価、およびこの情報を使用したサプライヤーの選択。 - 意思決定の分析と解決
確立された基準に基づいて代替ソリューションを評価できる構造化アプローチに基づくソリューションの開発。 - 統合のための組織環境
統合された製品およびプロセス開発のためのインフラストラクチャを提供し、統合のために人（スタッフ）を管理する - 組織プロセスのパフォーマンス
標準化された一連の組織プロセスのパフォーマンスの定量的理解を確立および維持し、組織プロジェクトの定量的管理のためのプロセスおよびモデルのパフォーマンスに関する情報を提供します。 - 定量的プロジェクト管理
プロジェクトによって確立された品質とパフォーマンスの目標を達成するために、特定のプロセスを定量的に管理します。 - 組織の革新と展開
測定可能な革新と改善の選択と実装により、組織のプロセスとテクノロジーが改善されます。 - 原因分析と解決
欠陥およびその他の問題の原因を特定し、将来それらが発生しないように対策を講じる
そして、なぜこのモデルが必要なのでしょうか？
CMMIモデルを使用すると、組織はプロセスの有効性を評価し、改善の優先分野を確立し、これらの改善を実装できます。
SMM / CMMIの導入により、プロセスの構造と品質を改善できます（ソフトウェア開発の主な問題は技術的な問題ではなく、管理の問題です）。 。
CMM / CMMIは、プロセスの概念に基づいています。 この概念の採用は、多くの組織が人々の失敗を非難する自然な傾向を避けるのに役立ちます。 従業員を解雇することは解決策ではありません。 過去数十年にわたって、技術に革命的な変化が生じましたが、プロジェクトを成功させるための問題は残っています。 この側面では、技術も問題の解決策ではありません。 このプロセスの価値は、将来のプロジェクトで最高の成果を獲得して活用するのに役立つことです。 この前提に基づいてCMMIが基づいています。
SMM / CMMIはモデルです。 世界の簡略化されたビュー。 SMM / CMMIモデルには、アクティビティのさまざまな側面を提供するプロセスの重要な要素が含まれており、生産プロセスの開発と改善のガイドとして使用できます。 モデルの公式出版物は、プロセスまたはその説明を表していないことを強調しています。 組織の実際のプロセスは、ビジネスの詳細、組織の構造および規模など、多くの要因に依存します。
結果は？
早くまとめます。 それはむしろ、モデルを導入する仕組みを説明していない広告のレビュー記事です。 関心が生じた場合、その構造をより詳細に説明し始めます。 ほとんどの場合、記事は説明コメント付きのSEIからの公式文書の多少無料の翻訳になります。