構成管理を実施する方法

構成管理を実施する方法

CMMIではおよび構成管理のIEEE正式な定義は以下のとおりです。ソフトウェア構成管理ツールとアプリケーション技術を含むソフトウェアエンジニアリング手法、（プロセスまたは方法）で、同社は、ソフトウェア資産の変更を管理するためにそれを使用します。

一般的に言って、構成管理の主な目的は、その上のすべてのドキュメントの種類、コード、数分のバージョン、バグを含む、作業成果物を管理することです。しかし、単に構成管理は、バージョン管理である、として、構成管理は、すべての作業成果物の管理で理解していません。

組織がどのような問題があり、構成管理が欠けている場合は？[8時00以下の説明では、インターネット関連のコンテンツからの抜粋]

1. 知識とプロセス、組織損失の富

激しい現代社会の競争、人々の頻繁な動きは、一元管理の必要な構成管理プロセスとツール、豊富なドキュメントとコード及びその他の知的財産の不在避けられないことならば、必要に応じてプロジェクトマネージャやソフトウェアエンジニアにマシンのそれぞれを保存することが、しばしば職員のハードディスクの故障や出発の、永遠に消え、デジタル資産ソフトウェア組織のでので、必要な構成管理の欠如と無駄に失われました。

2. 私たちは、プロジェクトの進捗に遅れないようすることはできません

現代のソフトウェア工学の以前の欠陥が発見されたと考え、アイデアや小さなリスク、適切な措置の価格を取ります。重要な役割CMM / CMMIは問題が時間内に見つけることができるように、ソフトウェア開発プロセスの可視性を向上させることです。しかし、サポートプロセスとツール、構成管理の欠如に、部門長は、プロジェクトの正確な進捗状況を知ることができない、プロジェクトマネージャーでも、さまざまな開発者の具体的な仕事、大きな任意のプロジェクトの進捗状況を把握していません。問題は、多くの場合、すべてのプロジェクトのマイルストーンが一緒に集中しているとき、それは間違いなく巨大なコストにつながる発生し、その結果は、一部の欠陥や開発サイクルの遅延をしばしば許容されます。すべての質問にのみ最終的な実装、プロジェクトの実施を解決することを期待することができ、したがって、レポートに変えることができない、あなたは、無限のメンテナンスを整理することはできません。

3. 並行開発を達成するための手段の欠如

新バージョンの開発と同時に、必要なメンテナンスの以前のバージョンのために継続する可能性が高いプロジェクトのために、または別の顧客のための特定のバージョンのニーズに：毎日の開発作業では、多くの場合のような並行開発ニーズがあるでしょう同時に変更等をカスタマイズ。パラレルモードでは、別の開発者は、ファイル、並行開発を修正するために編集することができ、競合が発生する可能性があるが、それは開発効率を向上させることができます。構成管理ツールのサポートがなければ、並行開発が変更され、定期的なバグにつながるか、少数の人々は、不必要な廃棄物で、その結果、同じ仕事をすることが多い、唯一の手動操作することにより、非常に困難になります。

4. ソフトウェアの再利用率の低さ

ソフトウェアの再利用は、現代のソフトウェア工学における重要な考え方である、ソフトウェアは、生産効率と製品の品質を向上させるための重要な手段です。ソフトウェア製品の会社は、コードの再利用性が非常に高い貴重な資産であるが、知識ベースを構築する方法を、高品質かつ効率的な製品開発の知識ベースを十分に活用されます、会社に重大な影響を与えます。良い構成管理プロセスが存在しない場合は、ソフトウェアの再利用効率を大幅にそのようなコードの再利用に関しては、低減される必要な変更または改良は、手動の方法を変更することにより、すべてのソフトウェアを再利用するために渡すことができる行う発生します効率が想像できるかのプロジェクト、。またによる通信するために必要な手段の欠如、各開発者独自の方法だけでなく、スタイル書かれたコードにするだけでなく、ラインコーディングとデザインのうち、頻繁に維持することは困難で重複したコードの開発の多くにつながります。

5. 標準化されたテストを実行することができません。

従来の開発モードでは、ために必要な構成管理の欠如だけで人々の主観的な願望をテストし、コントロールを変更、単に特定のテスト要件を作ることができない、接続された醜い開発者を隠し、テストは、多くの場合、運動を通過し、テスト結果どちらの評価が定量化することができない、もちろん、今後の開発作業のためのガイドとして機能することはできません。

6. リリースされたソフトウェアのバージョンの効果的な管理の欠如

そのため、多くの場合、製品リリースShiqueにすべてのコンポーネントのバージョンを確認することができない、または使用者への間違ったバージョンを提供する効果的な管理ツールの欠如、の。特定の顧客の問題が発生するために、それらの使用は、適切なデバッグを行うためにのみ、ユーザのサイトに、バージョンを再現することはできません。ソフトウェア・アプリケーションの特性は、それぞれ異なる顧客は手動でも同じ問題に異なるの複数のコピーを維持するためのさまざまな要件、開発スタッフを持っていますが、別の人によって解決異なる場所で作られているので、そのアプローチではありません同じことを行う、保守プログラムが悪化しています。これらはまた、資源の浪費を意味し、実装の期間を延長します。

唯一の六位に見える、バージョン管理。

7. 過去のデータの蓄積の欠如は、ソフトウェア開発のための過去のデータが存在しません

ソフトウェア開発の歴史欠如は、この結論は、多くの人々を驚かせるかもしれ、ほとんどのソフトウェアプロジェクトの失敗の鍵であるが、それは真実です。ソフトウェア開発の履歴データをスケーリングするためのソフトウェア開発チームの能力のではなく、この規模の反映であるので、我々は、ソフトウェア開発プロセスの明確な理解を持つことができません。優れた構成管理は、履歴データを収集するために、ソフトウェア開発の重要な源です。

8. 効果的に管理し、変更を追跡することはできません

ソフトウェアの顕著な特徴には、構成管理が効果的に記録、追跡および制御用のソフトウェアを変更しないだろう、変更することは容易です。

この8だけでなく、資格の構成管理プロセスであり、

• 知識とプロセス、組織損失の富
• 私たちは、プロジェクトの進捗に遅れないようすることはできません
• 並行開発を達成するための手段の欠如
• ソフトウェアの再利用率の低さ
• 標準化されたテストを実行することができません。
• リリースされたソフトウェアのバージョンの効果的な管理の欠如
• 過去のデータの蓄積の欠如は、ソフトウェア開発のための過去のデータが存在しません
• 効果的に管理し、変更を追跡することはできません

効果的な構成管理を行うために良い構成管理計画を策定するために、ということを強調すべきです。言い換えれば、それはより8ポイントであるこの会社について非常に懸念しているが、各プロジェクトの焦点は異なっています。ドキュメント、コード、ドキュメント、並行して開発またはロールバックするために、バージョン管理、変更管理が最優先です。

多くのコンテンツ構成管理は、コアコンテンツが3ポイントを関与しました。

• 1. いいえドキュメント、コードを記録し、我々は結果の有効性を測定することはできません

例えば、文書が制御さ、すなわちストレージによって見直されるべきです。レビューサマリー制御されていないが、どのようにするとき、どのように品質評価などの評価を実施する方法を知っています。
開発計画は、構成管理ライブラリを参照するコードを提出する9.10を求める9.12ストレージは、我々は、コードが時間通りに提出されていることを知っていますか、その後、ありますか？

• 2. バージョン管理の並列開発やロールバック

バージョンは非常に重要です。製品は、一夜にしていない、真ん中はように、正式な、非公式、パッチバージョンの多くからも、となります。そのため、異なるバージョンの機能に導出、バグは、構成管理を管理するかどうかを、管理する方法を修正する非常に高い値のポイントです。ベースラインのバージョンをマージするいかなる計画、新機能は、コード、バグ修正コードの更新などを増やしていない場合、それはひどい災害の仕事である可能性があります。あまりにも簡単に脱落。

• 3. 変更管理

これは、フォーカスアイテムの構成管理です。プロジェクト、製品開発プロセスの変更は避けられないが、構成管理によって周りに記録されます事を変更します。変更は、それに応じて、範囲の変更は、ワークロードの変化によってもたらされる範囲の変更により、スケジュールの変更をもたらされます。あなたがコントロールしていない場合は、レコードを変更するには、何が100％を顧客の要件にその顧客最終的な配送を確保することを意味しますか？

それでは、どのようにそれを設定開発する予定ですか？

設定プログラムは、会社の特定の状況に応じて、上記製剤の含有量と組み合わせます。計画は、作成方法、ライブラリを設定した詳細が明確に定義されたように、権限を設定する必要があります。ここでは、あなたの参照を与えます：

1. はじめに
   1.1目的
   1.2定義
   1.3参照

2. ソフトウェア構成
   2.1ソフトウェアの構成環境
   2.2ソフトウェアの設定項目
   2.3設定管理者

3. ソフトウェア構成管理計画
   3.1ビルドサンプル構成ライブラリ
   3.2 ID管理の構成
   3.3構成のリポジトリコントロール
   点検・評価3.4構成の
   バックアップ構成リポジトリ3.5
   3.6構成管理計画リビジョン
   3.7構成管理計画付属ドキュメント

4. マイルストーン

命名規則付録1文書
1、制御構成ライブラリファイルの命名規則
2、制御不能な構成ライブラリファイルの命名規則
3は、文書ファイルの命名規則提出
付録2ドキュメントのエンコーディングの指定を
付録3つのアカウントと権限管理で
の規定に使用するライブラリを設定するには、付録4
文書の変更を記録

上記は、あなたが計画を実行するためのガイドを設定することができ、構成ディレクトリ計画テンプレート、です。

構成管理計画は、通常、メンバーを投影する構成作業を理解するためには、構成管理の定義を与えられました。例えば：

软件配置管理：SCM（ソフトウェア構成管理の頭字語）と呼ばれる、変更を管理するためのプロジェクトの開発、識別、制御および管理ソフトウェアです。配置管理的使用取决于项目规模和复杂性以及风险水平。大きなソフトウェアは、構成管理がより重要になります。

基线各アーティファクトの（ベースライン）プロジェクトリポジトリバージョン特定の期間の「スナップショット」。それは、この規格に基づいた正式な標準、その後の仕事を提供し、承認がこの標準を変更する必要があります後にのみ。初期ベースラインを確立した後、各変更後、次のベースラインの完了までの差として記録されます。

配置管理员：パートタイムの役割かもしれ構成管理を担当するプロジェクトチームの役割。品質チェックポイントによるレビューや監査を通じて、開発フェーズの後、統一された構成を担当する管理者は、関連文書と承認署名の最新の有効なバージョンを追加または変更します。

配置标识：識別のために、特定の開発プロセスの（構成同定）ソフトウェアプロジェクトのリソース。

配置检查：チェックするソフトウェア構成管理プロセス操作のため（構成監査）。

配置管理的核心是配置项的建立和相应权限设置，需要明确定义配置管理员、PM、产品经理等角色和职责。

一般的に、構成データベースは、制御され、制御されない構成リポジトリー構成リポジトリー2種類に分けることができます。

1. 制御構成リポジトリ

プロジェクト開発の実装プロセスを通じて、構成管理は、異なる段階に分けることができる11の制御設定ディレクトリ、コンフィギュレーションマネージャは唯一増加しているとパーミッションを変更、他のユーザーのみ読み取り専用アクセス。制御構成リポジトリディレクトリは次のとおりです。

00初期設定
01開始の
分析は、02必要
03デザイン
コーディング04
04テスト
06インストール
07概要
08変更
09プロジェクト管理
10環境構成を

設定マニフェストファイルXXXXのプロジェクトが含まれているライブラリの初期設定のルートリスト、ドキュメントは、プロジェクトの開発プロセスの文書が含まれて提出する必要があり、実際の開発プロセスでは、実際の状況に応じて、あなたは、リストに、適宜、変更、追加および削除することができます必要書類は提出しました。

2. 制御されていない設定ディレクトリ

思考の一時的なファイルやプロセスで発生する手続き文書の統合ストレージ管理と開発のための非制御設定ディレクトリの目的、形式と名前には厳格な要件はありません、プロジェクトチームのメンバーではなく、あまりにも多くの設計上の制限そして、制約は、人間本位の原則に沿って、より効果的な個人の能力を再生することができます。

プロジェクトの初期段階では、次の3つのディレクトリを設定することができます。

ディレクトリ名	使用説明
パーソナルワークスペース	私は、各メンバーが独自の個別プロジェクトの作業ディレクトリを持っている、文書の保存プロジェクトメンバーを書かれています
チームワークスペース	ライティングチームメンバーが作成した文書を保存するには、各グループが独自の個別の作業ディレクトリを持っています
地区から提出された書類	文書とコードを送信するための制御されていないと制御構成リポジトリの構成リポジトリとの間のバッファとしてによるレビューの後、確定された、そして、構成管理者から削除され、制御された構成リポジトリーに提出

うまく実行するための構成管理は簡単なことではないが、通常動作させるためにいくつかの構成管理ツールが必要です。業界の多くは、通常、構成管理ツールのために使用され、国内および外国あります。異なる、ない同程度の強力な、我々は自分自身に応じて選別する必要があります。共通プラットフォームのサポート：

• SVN

  中小開発チームのために、ほぼすべてのオペレーティングシステムをサポートし、より人気のあるオープンソースの構成管理ツール。

• CVS

  これは、ほぼすべてのオペレーティングシステムをサポートしています。開発チームのさまざまなレベルのために、より高い動作性能。

• PVCS

  Javaベースのソフトウェア開発自体は、共通のプラットフォームをサポートすることができます。唯一、小規模なプロジェクトチームに適したエンタープライズアプリケーションに適していないファイル共有システム、高いCPU、メモリ、およびネットワーク要件、一般的にパフォーマンスを、使用してサーバー。

• VSS - Microsoftツール

  唯一のWindowsオペレーティングシステムをサポートしています。比較的、数人の小さなチームに適した、シンプルな、単一少量のデータで、パフォーマンスが許容されています。

• テレロジックCMシナジー

  テレロジックDOORS、Telelogic社CMシナジーと、すべての主要なコンポーネントをカバーするTelelogic社タウ複雑なソフトウェア開発：要件管理、変更管理と可視化ソフトウェア工学。より高価。

• ClearCaseの

  IBMの非常に細心の巨大なツール。サーバーマルチプロセス・メカニズム、ファイルシステムの複数のバージョンを使用することはMVFSが、パフォーマンスに大きな悪影響を及ぼしています。大規模な開発チームのためのエンタープライズクラスの、総合的な開発の構成管理ツールとして。より高価。

• ホタル - 国内の会社です

  Javaベースのソフトウェア開発自体は共通のプラットフォーム上で使用することができ、プラットフォーム間では、Windows、Linux、Solaris版、HP-UX、AIXおよびその他の携帯にも非常に便利です。Serverは、パフォーマンスは、包括的な開発の構成管理は、小さなチームに適用することができ、エンタープライズクラスとして、優れており、マルチスレッドアプリケーションサーバーを使用しています。

• その他。

FAQ交流讨论

• 1. 組織がどのように行うVSS上のコード？我々は、フレームワーク、そこにプロジェクトの枠組みを持っているので。それは一緒に入れていますか？またはオープンマインド？

これは、ベースラインと分岐管理モードの詳細で、支店の統合の異なる点で、そのバージョンを行きます。これは、与えられたプログラムを支援するために、同社のシステムアーキテクトです。これは、外国人の構成管理システム・レベルのエンジニア、同社の製品、大きな牛のプロジェクトの開発です。彼らは、ベースライン時に、独自の商品企画を行うことができます。

プロジェクトは、一般的なブランチを必要としない、単純な管理、すなわちドキュメント、コード、バージョン管理を行うことができます。しかし、より多くのプロジェクト、製品、より多くの、プラットフォームは、コストを節約し、管理を減らすための良い方法です。

2. プロジェクトマネージャや構成管理を理解する必要がありますか？

プロジェクトマネージャーは、プロジェクトのより良い管理順に管理をコンフィギュレーションする方法を知っている必要があります。限り、通常の構成管理会社がでなければならないとして、そうでなければ、コードそれ今日の08.9ヶ月のバージョンを見つけることができますか？実際には、構成管理ツールは、当該プロジェクト参加者のために使用するのは簡単です、我々は文書を入れて、コードがライン上でチェックイン、チェックアウトを覚えて渡さ。

限り、プロジェクトマネージャは意識的に、文書内のコードをチェックして、バージョンは人手が行うプロジェクトポイントの次の段階に焦点を当て、その後、毎日行わないための基本的な要件です。泣いてそうしないと、問題が遅すぎます。問題、およびその構成リポジトリのオフサイトのバックアップがあります。

3. 構成管理

多くの小規模なプロジェクトチームでは、パートタイムの管理者が設定するために、あるいは、開発、テストを個別に管理し、QAスタッフが自分の仕事をチェックする必要があります。

大企業の構成管理と品質管理は、事務所を任命している必要があります。バージョンは、一方で、ベースラインは、一つのことです。

4. 乙のDO構成管理に参加する方法

パーティーには、十分なライブラリ、またはあまりにも疲れて自分のマイルストーンを監視し、あまりにも多くの制御せずに、構成管理のために推定します。