13.6ソフトウェア構成管理

任意のソフトウェア開発は、要件仕様の問題を特定します、設計プロセスでは、と言うことです反復プロセスであり、設計ミスは、実装プロセスに公開します。また、時間をかけて、顧客の需要は、多かれ少なかれ変化します。したがって、ソフトウェア開発プロセスにおいて、変更（または変更）が必要と不可避の両方です。ただし、変更を適切に制御し、変更を管理しない場合は、混乱を引き起こし、多くの深刻なミスを生成するためにバインドされ、コントロールを失うことも非常に簡単です。
ソフトウェア構成管理はソフトウェアの寿命を通じて変更を管理する一連の活動です。具体的には、活動のこのグループ：①は、変更を特定、②制御を変更する。③変更の適切な実現を確保すること。④変更を報告し、そのような情報を知っておく必要があり人々。
ソフトウェア構成管理は、ソフトウェアのメンテナンスと異なっています。メンテナンスは、ソフトウェアのユーザーの前に発生する予定である、と構成管理ソフトウェアは、プロジェクトの開始時に開始され、退職終了後の活動を追跡し、制御するソフトウェアのセットまで継続されます。
ターゲットソフトウェア構成管理は、より正確に変更を加えると、より簡単に、必要なときに変化するのに要する作業量を削減するために適応させることです。

13.6.1ソフトウェア構成

1.ソフトウェアの設定項目

ソフトウェアプロセスからの出力は3つのカテゴリに分類することができる。①コンピュータプログラム（ソースコードと実行可能プログラム）、②（技術またはユーザーの）文書に記載されたコンピュータプログラムを、③データを（外部のプログラムに含まれるプログラムを、または）。これらの項目は、我々は総称して彼らにソフトウェアを設定、ソフトウェアプロセスで生成されたすべての情報を構成し、これらの項目は、ソフトウェア構成項目です。
ソフトウェア構成項目の数で、ソフトウェア開発プロセス、急速な増加の進展に伴い。残念ながら、前述の様々な理由のために、コンテンツのソフトウェア構成項目は随時変更されることがあります。高品質のソフトウェア製品を開発するために、ソフトウェア開発者にのみ正しく、各ソフトウェア構成項目を確保するために努力しなければならない、とすべてのソフトウェアの設定項目がまったく同じであることを確認する必要があります。
全体のソフトウェアプロセスソフトウェア品質保証活動に適用されるように、品質保証活動をソフトウェア管理を設定することができます変更を管理する専用のソフトウェアです。

2.ベースライン

ベースラインは、それが真剣に変更ダウン制御の合理的な変更を妨げることなく、私たちの中に役立ち、ソフトウェア構成管理の概念です。IEEEは、ベースラインのように定義されます。あなたはさらなる発展のための基礎として使用することができ、それが唯一の正式な変更管理プロセスによって変更することができます仕様や中間製品の正式なレビューを通じて行っています。
要するに、ベースラインは、あるソフトウェアの正式な見直しによる構成アイテム。ソフトウェア構成項目がベースラインになる前に、迅速かつ非公式にそれを変更することができます。ベースラインが確立されたら、あなたはまだ変化を達成することができますが、しかし、それぞれの変更を、評価する実装および検証するために（ルールと呼ばれる）、アプリケーション固有の、正式なプロセスである必要があります。
ソフトウェア構成項目に加えて、多くのソフトウェアエンジニアリングの組織はエディタ、コンパイラや他のCASEツールの特定のバージョン、「固定」のソフトウェア構成の一部としてダウン、つまり、構成管理ソフトウェアツールの下に置かれます。ソフトウェアの設定項目を変更する場合は、これらのツールを使用する必要があるため、さまざまなツールによって生成された結果の異なるバージョンを防ぐために、ソフトウェアツールは、ベースライン、および包括的な構成管理プロセスに含まれるべきです。

13.6.2ソフトウェア構成管理プロセス

ソフトウェア構成管理ソフトウェアは、品質保証の重要な部分であり、その主なタスクは、変更を制御することでも、様々なソフトウェア構成とロゴのソフトウェアバージョンを担当し、ソフトウェアの構成監査し、任意の変更を報告するソフトウェア構成に起こります。
識別、バージョン管理、変更管理、コンフィグレーション監査およびレポート：具体的には、ソフトウェア構成管理5つのタスクがあります。

1.ターゲットソフトウェア構成を特定します

制御および構成管理ソフトウェアアイテムに、各構成要素は、個別に名付けられ、そしてその組織のオブジェクト指向方法なければなりません。基本的なオブジェクトと集約オブジェクト（オブジェクトは、ソフトウェア構成のフルバージョンのためのメカニズムの代表として収集することができます）：あなたは2つのタイプのオブジェクトを識別することができます。基本的なオブジェクトは、例えば、分析、設計、コーディングやテストプロセスのうち、段落の要求仕様、ソースリストやテストケースのセットのモジュールを「テキストユニット」を作成するためのソフトウェア・エンジニアです。集計対象は、集められ、基本的なオブジェクトや他のオブジェクトのコレクションです。
各オブジェクトには、機能のユニークなセットは、それを識別することができています「達成するために、」名前、説明、リソーステーブルと前記オブジェクト名は明確にオブジェクトを識別する文字列です。
オブジェクトを識別するときのパターン設計ソフトウェア、オブジェクトは、ライフサイクル全体で認識されなければならない進化してきたので、パターンを識別するために設計されたことは明確に、各オブジェクトの異なるバージョンを識別できなければなりません。

2.バージョン管理

共同使用のバージョン管理手順と作成されたソフトウェアエンジニアリングプロセスで構成オブジェクトの異なるバージョンを管理するためのツール。コントロールのバージョンによって、ユーザは、適切なソフトウェアバージョンを選択して設定を指定することができます。この目標を達成する方法は、所望の形状及び所望の特性のセットの記述を指定するためのソフトウェアとコンフィギュレーションの各バージョンアップに関連付けられた属性です。
上記の「属性」は、複雑なシステムの変更に適用される関数の特定のタイプを識別するブール変数文字列とすることができる、唯一の各特定のバージョン番号の簡単な構成オブジェクトに割り当てることができます。
非リリースバージョン、バージョンの変更限り、それぞれのバージョンが上書きすることはできません

3.変更管理

大規模なソフトウェア開発プロジェクトのために、制御されていない変更はすぐに混乱につながります。変更管理手順は人を入れて、自動化ツールは、変更のための制御機構を提供するために組み合わせます。次のように典型的な変動制御プロセスは、 変更要求に最初の後の変動の評価損失および利益技術において、可能性のある副作用、他のシステム機能と構成オブジェクトの全体的な影響と推定されたコストを変更します。評価フォーム「変更報告書」の結果、「変更管理承認者」見直しのためのレポート。人はまた、その状態が変化すると、優先度の最終決定をする人々のグループ、から構成することができるいずれかの方法で制御承認のいわゆる変化します。

各承認された変更が実施される変更点について説明し、「設計変更オーダー」を、生成されます、それは制限や審査および監査の基準に準拠しなければなりません。プロジェクトデータベースプロジェクトを移動する「（チェックアウト）を抽出」から変更されたオブジェクト[オブジェクトのロック、その他は変更することができない]、適切なSQA活動を変更して適用します。最後に、変更されたオブジェクトは、データベースその他は変更することができる[アンロック]に「（チェックイン）を提出」と適切なバージョン管理機構とソフトウェアの次のバージョンを作成します。
「送信」と「抽出」プロセスは、2つの主要な機能の制御の変化を達成するために-アクセス制御や同期制御を。ソフトウェアエンジニアがアクセスし、特定の設定オブジェクトの決定を変更する権利を持っているアクセス制御は互いを上書きすることはありません並列変更を完了するために、2人の異なるソフトウェアエンジニアによって同期制御を確保することができます。

ソフトウェア構成項目は、ベースライン、唯一の非公式のアプリケーション変更管理になる前に。構成オブジェクトの開発者は、それが合理的な変更を行うことができます（限り、変更はシステムに影響を与えない範囲で作業範囲外の開発者を必要とします）。オブジェクトは、正式な技術的なレビューと承認経由したら、それはベースラインを作成します。ベースラインへのソフトウェア構成項目たら、プロジェクトレベルの変更管理を実装するために始めました。今、変更は、他のソフトウェア構成アイテムに影響を与える場合、（変更は「ローカル」である場合）、プロジェクトマネージャーの承認を得なければならない開発者を変更するために、制御の変更も承認者の承認を得なければなりません。いくつかのケースでは、あなたが正式な変更要求、変更の報告や設計変更オーダーを省略することができ、しかし、各トラックやレビューの変化と、すべての変更を評価する必要があります。

4.設定監査
通常、次の措置の両方から取られ、必要な変更の適切な実現を確保するために、：①正式な技術的検討、②ソフトウェアの構成監査。
フォーマル技術レビュー（13.5.2項を参照）を構成オブジェクトの技術的な正確さに焦点が変更されます。査読は、他のソフトウェア構成項目との整合性を判断し、欠落または副作用をチェックするためにオブジェクトを調べます。

通常、変更日かどうかを示す、設定項目に顕著行われた変更をマークするかどうかを、ソフトウェアエンジニアリング基準を変更する際に従うかどうか、例えば（構成オブジェクトを評価するために、レビュープロセスで考慮されていない機能により、ソフトウェアの構成監査そして、顕著な変化を、記録手順と報告変化の変化）に追従し、正式な技術審査を補完するかどうかを、関連するすべてのソフトウェア構成アイテムを更新することが適切であるかどうか、によって変更。

5.ステータスレポート
設定のステータスレポートを書くには、ソフトウェア構成管理のタスクは、それが次の質問に答えている：①何が起こったのか？②それをやった人は問題？③とき、それは起こるのですか？④他にどのようなものに影響を与えるのだろうか？
設定のステータス変更は、大規模なソフトウェア開発プロジェクトの成功に大きな影響を与えます。大勢の人が一緒に仕事をすると、人は他の人がやっているのか分からないかもしれません。二人の開発者は、同じソフトウェアの設定項目を変更するために、競合するアイデアに従うことを試みるかもしれません。ソフトウェアエンジニアリングチームは、旧式のハードウェアの仕様に基づいてソフトウェアを開発するための作業指示書のいくつかの人月がかかることがあり、提案された変更を認識して、深刻な副作用の人々を持っていますあなたは進行中の変更を知らないかもしれません。これらの問題を解消する手助けするために、すべての利害関係者間のコミュニケーションを改善することによって、コンフィギュレーションステータスレポート。

13.7能力成熟度モデル

防衛資金によるカーネギーメロン大学の米国エネルギー省（能力成熟度モデル、CMM）の下で1980年代後半に設立された能力成熟度モデルソフトウェア工学研究所は、組織のソフトウェアプロセス成熟度のためのソフトウェアを評価する能力でありますモデル。最初は、このモデルの設立の主な目的は、大規模なソフトウェアプロジェクトの入札活動の基盤の総合的かつ客観的評価を提供するために、このモデルが適用されてきたと同時に、後に開発、ソフトウェア組織の改善活動の中に多くのプロセスを。

長年にわたり、多くのソフトウェア開発組織を悩ませてきたソフトウェアの危機。多くの人々は、新しいソフトウェア開発技術を使用して、ソフトウェアの生産性やソフトウェアの品質問題で問題を解決しようとするが、その効果は非常に満足のいくものではありません。これらの事実は、重要な問題は、不十分なソフトウェアプロセスの管理で発見するために、さらなる調査のソフトウェアプロセスを促しました。これは、不規則な混沌とした管理の下、高度な技術とツールがその原因な役割を果たしていることができないことが判明します。成長している認識は、ソフトウェアプロセスの管理は、ソフトウェアプロセスの管理において重要な役割は、もはや無視することができ、ソフトウェアの危機の突破口を削除することはありません改善、があります。

問題への能力成熟度モデルの基本的な考え方は、私たちが不適切に起因するソフトウェアプロセスを管理する方法によって引き起こされるので、新しいソフトウェア技術の使用は、自動的にソフトウェアの生産性と品質を向上しません。能力成熟度モデルは、通常、成熟したソフトウェアプロセスを確立するために、ソフトウェア開発組織を支援します。より多くのソフトウェアプロジェクトは、時間とコスト超過、それに苦しむように改善されたソフトウェアプロセスは、より良い品質のソフトウェアを開発します。

ソフトウェアプロセスは活動、技術や様々なツールが含まれ、それは実際に経営を含んでもソフトウェア開発の技術的な側面の両方を含んでいます。CMMの戦略は、ソフトウェアプロセスの管理を改善するための試みですが、技術の改善は避けられない結果です。
ロール内のCMMソフトウェアプロセス改善は、現在のプロセスの成熟度を決定することによって、ソフトウェアの組織を導くために主であるとの問題は、プロセス改善、プロセスの改善ので、明確な方向性や戦略に重要な役割を果たして識別します。ソフトウェアプロセス能力を段階的に改善されるように、プロセスの改善に着目し、プロセス改善活動の一貫性の方向と戦略を実行することにより、ソフトウェア組織は、定常的かつ効果的にそのソフトウェアプロセスを改善することができるであろう。

ソフトウェアプロセスを改善し、一晩継続的に小さなステップではなく、完全な革命の漸進的なプロセスで完了し改善するため。進化を5つの段階を注文すると、これらの段階をソートする障害からソフトウェアへのCMMプロセスは、五層は、レベルを向上させるために形成されています。これらの5つの成熟度レベルは、これらのレベルはまた、仕事が優先するソフトウェアの組織で行われるべきで向上させることができ、ソフトウェアの組織のソフトウェアプロセス成熟度を測定するための順序尺度を定義し、そのソフトウェアプロセス能力を評価します。成熟度レベルが適切に定義されたプラットフォーム、成熟したソフトウェアの編成を進めるための方法です、各成熟度レベルは、より高いレベルを提供するために、ソフトウェアプロセスを改善していきます。

CMMは、5つの成熟度レベルのソフトウェアプロセスの異なるレベル間の特性説明大きな変化をします。秩序、規律を目的と成熟したソフトウェアプロセスにソフトウェアプロセスの無秩序、混沌とした進化から達成するためのソフトウェアメカニズムを反映して、「レベル5」から「レベル1」から、通過する必要があります途中のプロセス改善活動。各成熟度レベルは、そのプロセスを改善するための方法の方法に沿ってソフトウェア組織は、成熟度レベルは、ソフトウェアプロセスのレベルの進化前の目標であること。一歩前進であります

CMMの成熟の各レベルは、プロセス改善の目標、機構は、成熟の次のレベルへの電流のレベルから進化これらの目標を達成するためのソフトウェア・プロセスのセットを含み、各フレームの成熟度レベルの次のレベルに到達するために、ソフトウェアプロセスの体が改善され、ある程度最適化するだけでなく、性能が向上しているプロセスになりますされている、ソフトウェアプロセスをさらに向上させるように増加成熟度レベルで、政府機関の改善活動のプロセスは、より大きな成果を達成しますそして、最適化。CMMは、サポートソフトウェア組織上記の方法は、彼らのソフトウェアプロセス活動の改善です。

CMMの能力成熟度は、組織がソフトウェアプロセスの欠陥を識別するために、引き続きソフトウェアの開発を導くために5つの段階で定義されており、改善するために何をすべきかを指摘したが、それは、これらの改善を行うための具体策を提供していませんされています。
ローからハイに5つの能力成熟度レベルがある：（また、レベル3とも呼ばれる）（また、ステージ2としても知られる）反復（また、レベル1ともいう）の初期段階、規定されたレベル、（管理レベルを有しますまた、グレード4）、また5としても知られている最適化レベル（）として知られています。ここでの機能の5つのレベルがあります。

1.初期レベル

ソフトウェアプロセスの特性が乱れ、そして時には混沌です。ほとんど何も定義されたプロセスの結果ではありません（つまり、プロセスモデルが確定していない）、プロジェクトの成功は、個々の開発者の能力に完全に依存します。

これは、ソフトウェアの組織、事実上無音ソフトウェアエンジニアリング管理システムの最低の成熟度レベルであり、そのソフトウェアプロセスは非常に予測できないとプロジェクトチームのスタッフに完全に依存し、人々は、プロセスが変更された変更されました。プロジェクトができる経験豊富な経営者や開発者の優秀なチームが、が負担することが発生した場合は、このプロジェクトが成功することがあります。しかし、より一般的な状況は、健全な管理と慎重な計画、予算超過と後期配達状況の欠如は、多くの場合、結果として、アクションのほとんどは、むしろ完全に事前に計画されたタスクよりも、危機に対処するだけで発生しています。
要するに、成熟度レベル1のソフトウェアの組織で、工程能力は予測不可能である、それは不安定なソフトウェアプロセスと製品の品質であるだけで個々の作業機関への職員の能力ではなく、ソフトウェアを処理する能力に基づいて予測することができます。

2.反復

確立するために、ソフトウェアの機関の基本的なプロジェクト管理プロセスを（プロセスモデル）は、コスト、スケジュール、機能性と品質を追跡することができます。必要なプロセス仕様を確立しているソフトウェアプロジェクトが再び成功するために同様のアプリケーションを経験しているように、新しいプロジェクトの計画と管理のプロセスは、類似プロジェクトにおける過去の経験に基づいています。2の目標レベルを達成することは政府機関がこれまでに行われ、以前のプロジェクトを成功にソフトウェアプロジェクトのソフトウェアエンジニアリングの実践を複製することができるようにプロジェクト管理プロセスは、安定しています。

成熟度レベル2のソフトウェア組織は、このプロジェクトのためのソフトウェアは、基本的なソフトウェア管理制御システムを確立するために行われました。以前のプロジェクトの観察と分析を通じて、それは進行中のプロジェクトのための制約を提示することができます。プロジェクトリーダーのトラッキングソフトウェア製品の開発コストと機能と製品の品質だけでなく、進捗状況と制約を満たすために問題を特定に対処する必要があります。これは、原則的ソフトウェア要件を行う必要があり、その整合性が制御されています。私たちは、これらの基準の厳格な実施を確保するために、プロジェクトの基準、およびソフトウェアの組織を開発しました。クライアントと請負業者とのプロジェクトチームは、安定した、管理しやすい職場環境を確立しています。

成熟度レベル2組織のソフトウェアプロセス能力は、のように要約することができる計画とプロジェクト追跡ソフトウェアが安定して、再現性のプロジェクトは規律管理プロセスの前に成功した実践のための環境を提供してきました。ソフトウェアプロジェクトの活動は、プロジェクト管理システム、計画の実施の効果的な制御下で現実的なプロジェクトに基づいて、以前のガイドラインに沿ったものです。

3.定義されたレベル

ソフトウェアの組織が定義した完全なソフトウェアプロセス（プロセスモデル）を、ソフトウェアプロセスを文書化し、標準化されています。使用しているすべてのプロジェクトチームは、文書化ソフトウェアを開発し、維持するためのプロセスを経て承認されました。これは、第二段階のすべての機能が含まれています。
ソフトウェア組織の成熟度レベル3では、ソフトウェアプロセスエンジニアリング活動のプロセスに従事する固定基が存在します。必要な場合には、プロセス・チームは、ソフトウェアプロジェクトの特定のインスタンスのためのプロセスを得るために、プロセスモデルのインスタンス化のプロセス活動の利点を活用し、操作にプロセスを入れて、ソフトウェアエンジニアリングプロジェクトの効果的な練習を行うことができます。一方、チームはまた、ソフトウェアプロセス改善活動組織のプロセスを進めることができます。組織内のソフトウェアは、すべてのプロジェクトリーダーやプロジェクト開発者が着手に必要なタスクを完了するための知識とスキルを持っていることを保証するために、研修プログラムを実施します。

レベルのソフトウェアプロセス能力成熟度の3団体は、ように要約することができるアクティブな管理やエンジニアリング活動が安定しているかどうか。ソフトウェア開発コストとスケジュールだけでなく、製品の機能や品質管理下にあり、およびソフトウェア製品のトレーサビリティの品質。この機能は、活動の共通理解に基づいて、ソフトウェア組織のプロセスモデルが定義されている、スタッフと責任を持っています。

4.マネージクラス

ソフトウェア代理店ソフトウェアプロセス（プロセスモデルとプロセスインスタンス）およびソフトウェア製品は、すべてのプロジェクト活動が測定に重要なプロセスであり、定量的品質目標を確立しています。使用されるコレクションの代理店ソフトウェア製品とプロセス指標や測定方法は、定量的に理解し、制御するソフトウェアプロセスとソフトウェア製品を、プロジェクト評価プロセスの品質と製品の品質のための基礎を築いたことができます。これは、第三段階のすべての機能が含まれています。

プロセス能力成熟度レベル4のソフトウェア機構は、測定可能なソフトウェアプロセス、測定の範囲内で動作するソフトウェアプロセスとして要約することができます。プロセス能力のこのレベルは、ソフトウェアプロセスと製品の品質機関が対策の定量範囲の傾向が偏りを補正するために適時に発生したときに撮影することができ、かつ高品質のソフトウェア製品であることが期待できる予測できます。

最適化の段階

ソフトウェア組織は、ソフトウェアプロセスの継続的な改善に焦点を当てました。このレベルは、ソフトウェアのメカニズムであることは、ソフトウェアプロセス要素に弱いリンクを識別し、それらを改善するための十分な手段を持っている能力を持って、目標として制度的欠陥を防止します。あなたがソフトウェアプロセスの有効性に関する統計情報を取得することができ、そのような体では、これらのデータの使用は、新技術/便益分析のコストにすることができ、採用できるソフトウェアエンジニアリングの実践で最高の新しい技術を最適化することができます。これは、四段目のすべての機能が含まれています。

この機構は、欠陥のこのタイプが再度発生防止のために、プロセス・インスタンスのパフォーマンスを分析し、決定することにより、欠陥の原因とすることができるソフトウェアである。なることができるレッスンを得るプロセスの任意のインスタンスの分析を通じて学習しました他のプロジェクトの例のプロセスを最適化するように、プロセスモデルに従って、その効果的なメカニズムを最適化するためのソフトウェア。新しいアイデアや技術の使用は、それらをテストすることながら、そのようなソフトウェアは、ソフトウェアプロセスを改善し、最適化するために続行し、フィードバック情報の定量的プロセスの実施形態によって得ることができます。

成熟度レベル5での組織のソフトウェアプロセス能力は、のように要約することができるソフトウェアプロセスが最適化されています。継続的に使用される新しい技術やプロセス改善手法の将来や援助を実現するために、そのプロセス能力、既存のプロセス・インスタンスの継続的な改善と最適化の両方を改善するためのソフトウェア組織のこのレベル。
いくつかの統計は、それは完全な成熟度レベルは3年に約18ヶ月かかります強化を示しているが、最高レベル1からレベル2に、時には3年あるいは5年かかります。現在までにどのように困難なソフトウェアの組織は、体系的な方法を植え付けるために混沌とアクションの受動的な方法にまだあることを示しています。

13.8まとめ

コンテンツと管理の側面を含むソフトウェア工学技術は、密接に統合された技術や製品管理です。唯一の科学と厳格な管理に、高度な技術的方法と優れたソフトウェアツールは、実際の電力を再生することができます。そのため、効果的な管理は、大規模なソフトウェアプロジェクトの成功の鍵です。
ソフトウェアプロジェクトマネジメント計画書プロジェクトが始まり、最初の計画活動が推定されています。すべての最初のプロジェクトの作業負荷と期限を推定するために、我々は、ソフトウェアの規模を予測する必要があります。

コード技術のラインの技術と機能の点で主に使用されているソフトウェア技術の大きさを測定します。両方の技術は、長所と短所は、プロジェクトの特性及びこれら二つの技術、適切な技術の選択とプログラムの親しみで働く人々に基づくべきであります。

ソフトウェアによっては、静的単一変数モデル、動的な多変数モデルとCOCOMO2モデルのためのプロジェクトの作業を完了するために必要な大きさ、一般的に使用される推定モデルを推定することができます。実際の値の推定値が近づくようにするために、一般に同時に上記3つのモデルのうちの少なくとも2です。異なるモデルとの連携を比較することで得られる推定値の使用は、より正確な推定値を得ることが可能です。コスト推定モデルは、一般的に推定開発期間が通常の開発時間となるように、式はまた、ソフトウェア開発時間を提供見積もり、経験は、通常の開発時間の75％にする方法の開発時間の使用の増加を軽減するために、開発者にそれをアップ示されています。

管理者は、プロジェクトの進捗状況を監視し、プロジェクト全体を制御するために、十分に詳細なスケジュールを開発しなければなりません。一般的にスケジュールガントチャートとプロジェクトのネットワークを開発するためのツールを使用し、これら2つのツールを開発し、プロジェクトの進捗状況を監督する長所と短所、ガントチャートとプロジェクトネットワークスケジュールの通常組み合わせて使用しています。
高品質とプロジェクトチームの合理的な組織構造の開発者は、ソフトウェアプロジェクトの成功の鍵です。典型的な組織構造のプログラマの民主主義グループ、プログラマーやプログラマーの三種類の近代的なセットのメイングループ、機会のアプリケーションは、これらの3つが同じ組織ではありません。

ソフトウェア品質保証ソフトウェアは、プロセスの各ステップが実行されているアクティブです。ソフトウェアの品質保証対策が実施された試験（一般テストと呼ばれる）とプログラム正しさの証明に基づいて、（も見直しとも呼ばれる）非執行のテストに基づいています。ソフトウェアのレビューは、その利点は、エラーが比較的低いコスト修正するためにソフトウェアのエラーを検出して排除することができ、最も重要なソフトウェアの品質保証活動の一つです。
ソフトウェア構成管理活動は全体のソフトウェア保護プロセスに適用され、変更管理ソフトウェアの生涯を通じて活動のセットです。より正確に変更を加えると、より簡単に適応し、ソフトウェアを変更する必要があるで過ごし、この目的のために作業負荷を軽減することができますソフトウェア構成管理を対象とします。

能力成熟度モデル（CMM）は、ソフトウェアプロセスを改善するための効果的な戦略です。問題は、不適切に起因するソフトウェアプロセスを管理する方法があるので、自動的にソフトウェアの生産性やソフトウェアの品質を改善しない新技術の使用は、ソフトウェアプロセスの管理を改善するために多大な努力をしなければならないので、基本的な考え方は、あります。実際には、ソフトウェアプロセスの改善を達成することができないため、CMMは増分徐々に変化を導入するために、それは明らかに成熟の5つのレベルを定義し、ソフトウェア開発組織が高いに小さな一連のステップを用いて改善することができます成熟度レベル。