システム統合|第 16 章 (注)

第 16 章情報 (ドキュメント) と構成管理

16.1 文書管理

情報システムプロジェクト関連情報（資料）

概要：あるデータ媒体およびそこに記録されたデータのことを指します。これは永続的で、人間または機械が読み取ることができ、通常は人間が判読できるものを記述するためにのみ使用されます。ソフトウェアエンジニアリングでは、ドキュメントは、アクティビティ、要件、プロセス、または結果を説明、定義、指定、報告、または認証する書面またはグラフィック情報を指すためによく使用されます。
『コンピュータソフトウェア製品開発ドキュメントガイド』では、ソフトウェアプロジェクトドキュメントの具体的な分類を明確にしています。書類をファイルする重要性と品質要件の観点からに分けることができます非正式文档和正式文档。プロジェクトのライフサイクルからに分けることができます开发文档、产品文档、管理文档。

ソフトウェアドキュメントの分類:

開発ドキュメント
製品ドキュメント
文書の管理

ここに画像の説明を挿入します

品質レベル:

最小ドキュメント (レベル 1 ドキュメント) : 開発作業負荷が 1 人未満である開発者所有のプログラムに適しています。ドキュメントには、プログラムのリスト、開発記録、テストデータ、およびプログラムの紹介が含まれている必要があります。
内部ドキュメント (レベル 2 ドキュメント) : 他のユーザーとリソースを共有しないプライベートプログラムで利用できます。レベル 1 のドキュメントで提供される情報に加えて、レベル 2 のドキュメントには、ユーザーがプログラムをインストールして使用する際に役立つ十分なコメントがプログラムリスト内に含まれています。
作業文書 (レベル 3 文書) : 同じユニット内の複数の人が共同開発したプログラム、または他のユニットで使用できるプログラムに適しています。
正式ドキュメント (レベル 4 ドキュメント) : 一般向けに正式にリリースされるソフトウェア製品に適しています。重要な手順または反復的な管理アプリケーションを伴う手順 (給与計算など) にはレベル 4 の文書が必要であり、レベル 4 は GB8567 の関連規定に準拠する必要があります。

情報システム文書の標準管理の主な現れは次のとおりです。

1) 文書作成基準
- 概要: 経営情報システムの文書には、多くの種類のテキスト、グラフィック、表などが含まれます。文書の種類に関係なく、記号の使用、アイコンの意味、記号の使用など、統一された文書標準に従う必要があります。プログラム内のコメント行、文書の作成者や作成日などを示します。たとえば、プログラムの先頭には、プログラム名、プログラムの機能、呼び出し側プログラムと呼び出されるプログラム、プログラマなどを含めるために統一された形式を使用する必要があります。
2) チャートの番号付けルール
- 概要: 経営情報システムの開発プロセスでは多くのチャートが使用されますが、これらのチャートに規則的な番号を付けることで、チャートの検索が容易になります。チャートの番号付けは通常、カテゴリ構造を採用しています。ライフサイクル法の5段階に従えば、右図のような分類採番ルールが与えられます。このルールに従って、チャート番号を使用して、チャートがシステム開発サイクルのどの段階にあるか、どのドキュメントに属しているか、ドキュメントのどの部分であるか、どのチャートであるかを判断できます。
3) 文書ディレクトリの記述基準
- 概要: アーカイブと将来の使用の便宜のために、ドキュメントディレクトリをコンパイルする必要があります。管理情報システムの文書ディレクトリには、文書番号、文書名、フォーマットまたはキャリア、部数、1 部あたりのページ数または部数、保管場所、アーカイブ時間、保管者などが含まれている必要があります。文書の番号付け - 通常は分類構造であり、グラフの番号付けと同様の番号付けルールを使用できます。ドキュメント名は完全で標準化されている必要があります。フォーマットまたはキャリアとは、オリジナルの文書またはレポート、ディスクファイル、ディスクファイルのプリントアウト、大きな図表、オリジナルの重要な文書、CD アーカイブなどを指します。
4) 文書管理システム
- 概要: 情報システム文書をより適切に管理するには、対応する文書管理システムを確立する必要があります。文書管理システムは組織の具体的な状況に応じて決定する必要があり、主に文書作成に関する仕様、文書借用記録の登録制度、文書利用権の管理規定などが挙げられます。文書を確立するための関連標準とは、文書作成標準、図表番号付け規則、および文書ログ作成標準を指します。文書の借用は詳細に記録し、借用者にアクセス権があるかどうかを考慮する必要があります。文書に営業秘密や技術秘密が含まれる場合には、機密保持にも注意する必要があります。プロジェクト関係者が署名および確認した文書は、関連する電子文書と 1 対 1 で対応する必要があり、これらの電子文書も読み取り専用に設定する必要があるという事実に特別な注意を払う必要があります。

16.2 構成管理

技術的および管理的な指示と監視方法を適用して、構成アイテムの機能的および物理的特性を特定して説明し、これらの特性の変更を制御し、変更処理と実装ステータスを記録および報告し、指定された要件への準拠を検証します。

ソフトウェア構成管理は、コンピュータソフトウェアのライフサイクル全体にわたる変更を管理するために使用される一連のアクティビティです。

主な活動：

配合管理計画の策定
- 概要: 構成管理計画は、プロジェクト構成管理作業の実行方法に関するルールです。これは構成管理プロセスの基礎であり、プロジェクトのライフサイクル全体にわたって文書化および管理される必要があります。構成管理委員会は計画を承認する責任があります。
構成ID
- 概要: 構成識別 (構成識別とも呼ばれる) には、システムの構成アイテムを選択し、構成アイテムの機能と物理的特性を技術文書に記録することが含まれます。構成識別は、構成管理者の機能です。
- コンテンツ：
  - (1) 制御する必要がある構成項目を特定します。
  - (2) 各構成アイテムに固有の識別番号を指定します。
  - (3) 各構成アイテムの重要な特性を定義します。
  - (4) 各構成アイテムの所有者と責任を決定します。
  - (5) 構成アイテムが構成管理に入る時期と条件を決定します。
  - (6) ベースラインを確立し、管理する。
  - (7) ドキュメントおよびコンポーネントのリビジョンと製品バージョンとの関係を維持します。
- 注: 構成管理者の責任
構成制御
- 概要: 構成アイテムとベースラインの構成管理と変更管理。次のタスクが含まれます: 変更リクエストの特定と記録、変更の分析と評価、リクエストの承認または拒否、変更された構成アイテムの実装、検証、リリース
- 変更手順:
  1. 変更要求
  2. 変更評価
  3. 評価結果の通知
  4. 変更の実装
  5. 変更の検証と確認
  6. 変更のリリース
  7. 構成リポジトリベースの変更管理
  注: CCB は変更の承認を担当し、PM (プロジェクトマネージャー) は変更の実装を担当します。
ステータスレポートを構成する
- 概要: 構成ステータスレポートは、構成ステータス統計とも呼ばれます。そのタスクは、構成に必要な情報を効果的に記録および管理することです。その目的は、構成アイテムの現在のステータスをタイムリーかつ正確に関係者が理解できるように提供することです。、構成管理作業を強化するため。
- コンテンツ：
  - (1) 各空売り構成アイテムの識別とステータス。構成アイテムが構成制御下に置かれると、その後の進行ごとにそのバージョンとステータスが記録され、保存される必要があります。
  - (2) 各変更依頼の状況と承認された変更の実施状況
  - (3) 各ベースラインの現在および過去のバージョンの状況と各バージョンの比較
  - (4) その他の構成管理プロセスの活動の記録
- 機能: 構成ステータスレポートは、現在のベースライン構成アイテムのステータスを反映することに重点を置き、システム開発活動の進捗状況を管理者に報告する必要があります。構成ステータスレポートは定期的に実施し、可能であれば CASE ツールを通じて自動的に生成する必要があります。
監査の構成
- 概要: 構成監査は、構成監査または構成評価とも呼ばれ、機能構成監査または物理構成監査を含み、それぞれ現在の構成項目の一貫性と整合性を検証するために使用されます。
- 機能: 構成管理の最も基本的な要件を反映して、プロジェクト構成管理ステータスの妥当性を確認します。
- 混乱は許されません:
  - (1) 誤ったバージョンの取扱説明書を納品するなど、ユーザーに不適切な製品が納品されることの防止
  - (2) 初期仕様を満たさない製品の開発や、変更要求に応じた変更の実装の失敗など、実装の不完全な実装を発見する
  - (3) 設定項目間の不一致または非互換性の発見
  - (4) 構成アイテムがベースラインに含まれており、必要な品質管理レビュー後に倉庫に保管されていることを確認します。
  - (5) 記録および文書がトレーサビリティを維持していることを確認する
- 反映する：
  - 機能構成監査（一貫性）
    - 検証: (1) 構成アイテムの開発が正常に完了していること、(2) 構成アイテムが構成識別で指定されているパフォーマンスおよび機能特性を達成していること、(3) 構成アイテムの操作およびサポートに関する文書が完成していることそして要件を満たします
  - 物理構成の監査 (整合性)
    - 確認: (1) 納品される構成アイテムが存在するか、(2) 構成アイテムに必要なアイテムがすべて含まれているか
リリース管理と配信
- 主なタスク: ソフトウェア製品とドキュメントの発行と支払いを効果的に管理し、ソフトウェア製品の存続期間中、コードとドキュメントのマスターコピーを適切に保存します。
- アクティビティ: 保存、コピー、パッケージ化、配信、再構築

設定項目:

概要：
- 構成管理用に設計され、構成管理プロセス中に 1 つのエンティティとして扱われるハードウェア、ソフトウェア、またはその両方の集合。
- 構成項目の特定は構成管理活動の基礎であり、構成管理計画を策定する際の重要な部分です。。ソフトウェア構成項目分類ソフトウェアの開発プロセスは常に変化し続けます。合理的な変更を大きく妨げることなく変更を制御するために、ソフトウェア構成管理では「ソフトウェア構成管理」が導入されています。ベースライン「この概念。この定義によれば、私たちはソフトウェア開発プロセスでは、管理が必要なすべての構成項目は、ベースライン構成項目と非ベースライン構成項目の 2 つのカテゴリに分類されます。たとえば、ベースライン構成アイテムにはすべての設計ドキュメントやソースプログラムなどが含まれる場合があり、非ベースライン構成アイテムにはプロジェクトのさまざまな計画やレポートなどが含まれる場合があります。
内容:
(1) 外部から提供されるソフトウェア製品およびデータ
(2) 特定の社内ソフトウェア作業成果物およびデータ
(3) ソフトウェア製品の作成またはサポートに使用される特定のサポートツール
(4) ベンダー/サプライヤーによって提供されるソフトウェアおよびデータお客様が提供する機器/ソフトウェア
以下が含まれます (レビューおよび検査後に構成管理に入ります)。
- 番組企画提案
- 要件文書
- ソースコード
- 実行可能コード
- テストケース
- ソフトウェアを動作させるために必要な各種データ
知らせ：すべての構成アイテムには、関連する規制に従って統一した番号を付ける必要があります。, 対応するテンプレートに従って生成され、オブジェクトの識別情報がドキュメント内の指定された章 (セクション) に記録されます。構成管理ツールを導入して管理した後、これらの構成アイテムは、特定のディレクトリ構造。
分類：
- ベースライン構成項目
  - 例: ベースライン構成アイテムには、すべての設計ドキュメントやソースプログラムなどが含まれる場合があります。
  - 基本原則: ベースライン構成項目は開発者が閲覧できるように公開されています
- 非ベースライン構成項目
  - 例: 非ベースライン構成アイテムには、プロジェクトのさまざまな計画やレポートなどが含まれる場合があります。
  - 基本原則: ベースライン以外の構成項目は PM、CCB、および関連担当者に公開されています
所有配置项的操作权限应由 CMO（配置管理员）严格管理
バージョンナンバー
- ルール
構成アイテムのバージョン番号規則は、構成アイテムのステータスに関連しています。
(1) 「ドラフト」状態の構成アイテムのバージョン番号形式は 0.YZ であり、YZ の数値範囲は 01 ～ 99 です。。草案が修正されるにつれて、YZ の価値は増加するはずです。YZの初期値と増加量はユーザー自身が制御します。
(2) 「公式」状態の構成アイテムのバージョン番号形式は XY で、X がメインのバージョン番号で、値の範囲は 1 ～ 9 です。Y はマイナーバージョン番号で、値の範囲は 0 ～ 9 です。
構成アイテムが初めて「公式」ファイルになるとき、バージョン番号は 1.0 です。
構成アイテムのアップグレードが比較的小規模な場合、変更された部分を構成アイテムの添付ファイルにすることができます。添付ファイルのバージョンは 1.0、.1.1、... です。アタッチメントの変化がある程度蓄積すると、設定アイテムのY値を適切に増加させることができ、Y値がある程度増加すると、X値も適切に増加します。構成アイテムのアップグレードが比較的大きい場合、X 値を直接増加させることができます。
(3) 「変更済み」状態の構成アイテムのバージョン番号の形式は X.YZ です。構成アイテムを変更する場合、通常は Z 値のみが増加し、XY 値は変更されません。設定項目が変更され、ステータスが「正式」になった場合は、Z 値を 0 に設定し、XY 値を増加させます。
- ステータスの種類:
  - 下書き
    - 基準: 構成アイテムが最初に作成されたとき、そのステータスは「ドラフト」です。
    - バージョン番号: バージョン番号の形式は 0.YZ です。YZ の数値範囲は 01 ～ 99 です。ドラフトが改訂されると、YZ の値は増加します。YZ の初期値と増分はユーザーによって制御されます。
  - フォーマル
    - 根拠: 構成アイテムがレビューに合格すると、そのステータスは「正式」に変更され、構成アイテムが変更されて再度レビューに合格すると、そのステータスは「正式」に変更されます。
    - バージョン番号: バージョン番号の形式は XY です。X はメインのバージョン番号で、値の範囲は 1 ～ 9 です。Y はマイナーバージョン番号で、値の範囲は 0 ～ 9 です。
  - 改訂
    - 根拠: 構成アイテムが変更されると、そのステータスは「変更済み」に変わります。
    - バージョン番号: バージョンの形式は X.YZ です。構成アイテムを変更する場合、通常は Z 値を増やし、XY 値を変更しないことを意味します。設定項目が変更され、ステータスが「正式」になった場合、Z 値を 0 に設定し、XY 値を増加させます
- 図
バージョン管理: 構成アイテムのバージョン管理は、構成の識別、構成の制御と構成の監査、リリースと配信などの複数の構成管理アクティビティで使用されます。プロジェクトの開発プロセス中、ほとんどの構成項目は最終的に完成するまでに何度も変更する必要があります。ユーザーと構成アイテムの変更により、新しいバージョンが生成されます。新しいバージョンが古いバージョンよりも「優れている」という保証はできないため、古いバージョンを放棄することはできません。バージョン管理の目的は、バージョンの損失や混乱を避けるために特定のルールに従って構成アイテムのすべてのバージョンを保存し、構成アイテムの任意のバージョンを迅速かつ正確に見つけることです。
構成ベースライン
- 概要：
構成ベースライン (ベースラインと呼ばれることが多い) は、比較的安定した論理エンティティを形成する一連の構成項目で構成されます。ベースラインの構成項目は「凍結」されており、誰でも自由に変更することはできません。ベースラインへの変更は、正式な変更管理手順に従う必要があります。
一意に識別された一連の要件、設計、ソースコードドキュメント、および対応する実行可能コード、構築ドキュメント、およびユーザードキュメントがベースラインを形成します。製品のテストバージョン (要件分析仕様、概要設計仕様、詳細設計仕様、コンパイルされた実行可能コード、テスト概要、テストケース、ユーザーマニュアルなどが含まれる場合があります) はベースラインの一例です。
ベースラインは通常、開発プロセスのマイルストーンに対応しており、製品には複数のベースラインを設定することも、1 つのベースラインのみを設定することもできます。外部顧客に提供されるベースラインは一般にリリースベースラインと呼ばれ、内部開発に使用されるベースラインは一般に構築ベースラインと呼ばれます。
ベースラインごとに、ベースラインを確立するイベント、制御される構成項目、ベースラインの確立と変更の手順、ベースラインへの変更を承認するために必要な権限を定義します。プロジェクトの実装中は、各ベースラインを構成管理に含める必要があり、これらのベースラインの更新は、正式な変更管理手順を使用してのみ行うことができます。
- ベースライン (リリースベースライン) を作成する主な手順:
  - CCB認可の取得
  - 構築またはリリースのベースラインを作成する
  - ドキュメンテーション
  - ベースラインを利用可能にする
構成ライブラリ
- 概要: 構成アイテムを保存し、構成アイテムに関連するすべての情報を記録することは、構成管理のための強力なツールです。
- 分類：
  - 開発ライブラリ: ダイナミックライブラリ、プログラマライブラリ、または作業ライブラリとも呼ばれ、新しいモジュール、ドキュメント、データ要素、または変更された既存の要素など、開発者が現在開発している構成エンティティを保存するために使用されます。動的構成アイテムはバージョン管理下に置かれます。ダイナミックライブラリは開発者の個人的なワークスペースであり、開発者によって制御されます。ライブラリ内の情報は頻繁に変更される可能性がありますが、開発ライブラリのユーザーが必要と判断する限り、通常はプロジェクトの他の部分に影響を与えないため、その構成を制御する必要はありません。
  - 制御ライブラリ: マスターライブラリとも呼ばれ、現在のベースラインとベースラインへの変更が含まれます。制御されたライブラリ内の構成アイテムは、完全な構成管理下に置かれます。情報システム開発の特定の段階が終了すると、現在の作業成果物は管理されたライブラリに保管されます。
  - 製品ライブラリ: 静的ライブラリ、リリースライブラリ、ソフトウェアウェアハウスとも呼ばれ、リリースおよび使用されているさまざまなベースラインのアーカイブが含まれており、完全な構成管理下に置かれます。開発された情報システム製品は、システムテストを完了した後、最終製品として製品ライブラリに保管され、ユーザーへの納品や現場での設置を待ちます。
- データベース作成モード:
  - 構成項目タイプ別のデータベース構築: 一般的なソフトウェア開発組織に適した、構成項目タイプ分類ごとにデータベースを構築します。このような組織では、多くの場合、製品は高度に統合され、ツールは比較的統一されており、並行開発がある程度必要になります。このようなライブラリ構造を利用することで、構成要素の一元管理や制御に有利となり、コンパイルやリリースの効率も向上します。しかし、このようなライブラリ構造は各開発チームの開発タスクを指向していないため、開発者の作業ディレクトリ構造が複雑になり、無用なトラブルを引き起こす可能性があります。
  - タスクに基づいたデータベース構築: 開発タスクに基づいて、対応する構成ライブラリを確立します。これは、専門的なソフトウェア開発組織に適しています。このような組織では、多種多様な開発ツールが使用され、開発モデルは主にリニア開発であるため、構成項目を厳密に分類して保存したり、ディレクトリを人為的に複雑にする必要はありません。研究開発ソフトウェア組織の場合、この設定戦略はより柔軟です。
構成制御ボード (CCB)
- 概要: 構成管理委員会 (CCB) は、承認された変更の実装を評価、承認、および監督する責任を負います。CCB はプロジェクトレベルで設立され、そのメンバーにはプロジェクトマネージャー、ユーザー代表、製品マネージャー、開発エンジニア、テストエンジニア、品質管理担当者、構成管理者などが含まれます。CCB は常設の施設である必要はなく、業務の必要に応じて設立することができます。例えば、変更内容や変更要求に応じて異なる CCB を設立することもできます。小規模なプロジェクトの場合、CCB は 1 つだけ設置することもできます。個人でも、パートタイムの人でも。通常、CCB は構成変更を制御するだけでなく、構成管理計画の承認、ベースライン確立の承認、製品リリースの承認など、その他の構成管理タスクも担当します。
- CCB は、変更申請の評価を組織し、以下を決定する責任があります。
  - (1) 変更によるプロジェクトへの影響
  - (2) 変更内容は必要か？
  - (3) 変更の範囲は十分に検討されているか
  - (4) 変更の実施計画が実現可能かどうか
  - (5) 変更作業負荷の見積もりは妥当ですか?
構成マネージャー (CMO)
- 概要: 構成ライブラリへの操作権限をプロジェクトの各メンバーに割り当てる責任を負い、プロジェクトのライフサイクル全体を通じて構成管理活動を実行する責任を負います。
- 具体配置内容：
  - (1) 構成管理計画を作成する
  - (2) 構成管理システムの確立と維持
  - (3) 構成ライブラリの確立と保守
  - (4) 構成項目の特定
  - (5) ベースラインの確立と管理
  - (6) バージョン管理と構成管理
  - (7) 構成状況レポート
  - (8) 構成監査
  - (9) リリース管理と配信
  - (10) プロジェクトメンバーへの構成管理トレーニングの実施
構成管理システム
- 概要：構成管理システムは、構成管理を行うためのソフトウェアシステムであり、構成管理の内容を決定し、標準化された構成管理ソフトウェアを提供することにより、情報システム開発プロセスの品質管理を強化し、情報システム開発プロセスの制御性を高めることを目的としています。構成項目 (さまざまな文書、データ、手順を含む) が完全、明確、一貫性があり、追跡可能であること、および構成項目の状態が制御可能であることを確認します。
- 効果
変更管理プロセスを含む構成管理システムをプロジェクト全体に適用すると、次の目的が達成されます。
(1) ベースラインに対する変更を一貫して特定して提案し、これらの変更の価値と有効性を評価する方法を確立します。
(2) それぞれの変更の影響を考慮してプロジェクトを改善する機会を提供する
(3) 承認および拒否されたすべての変更を一貫した方法でプロジェクトの関係者に伝える方法をプロジェクト管理チームに提供する。
(4) 変更制御プロセス全体における構成管理アクションの一部は次のとおりです。
A. 構成識別項目: 製品構成の決定と検証、製品や文書のマーキング、変更の管理、情報開示の維持の基礎となります。
B. 構成ステータス: 構成アイテムの適切なデータが送信された場合、この情報は記録および報告される必要があります。この情報には、承認された構成識別子のリスト、提案された変更のステータス、承認された変更の実行ステータスが含まれます。
C. 構成の検証と監査: 構成の検証と構成の監査により、プロジェクトの構成アイテムが構成され、対応する変更が正しく記録、評価、承認、追跡、および実行されていることを確認します。これにより、構成ファイルで指定された機能が満たされることが保証されます。

建設チーム:

メンバーが含まれます:
- チームリーダー: 彼は建設プロセス全体の責任者です。他部門や上司との関係を調整し、業務プロセスを監督し、グループ内の関係を調整することが主な責任です。
- 技術サポート専門家: グループに技術や設備に関するサポートやサービスを提供する責任を負い、関連するプロジェクトの状況、開発環境、開発者の状況の把握など、技術的な問題についてグループと他部門との連絡を担当します。、など。
- 構成管理テクノロジーの専門家: 構成管理プロセスの構造と構成管理ツールに精通している人。主な任務は、構成管理プロセスの構造を指導し、構成管理規則の策定を支援し、構成管理ツールに関する開発者のトレーニングを担当することです。この責任は通常、構成管理ツールのプロバイダーまたは専門の構成管理コンサルタント会社の担当者によって実行されます。
- 構成管理システム利用者代表者：システムを利用する開発者の中から選出され、将来実際のプロジェクト開発プロセスをフォローします。彼らは、構築の初期段階から構成管理システムと手順を理解し、開発経験に基づいて構成管理手順の策定と変更を支援し、パイロットプロジェクトで部分的な開発役割を引き受ける責任を負います。このメンバーグループには、ソフトウェア開発プロジェクトマネージャー、デザイナー、コーディング、テストと構築、およびリリース担当者が含まれる必要があります。プロジェクトチーム設立後は、以下の手順で構成管理プロセスの構築を実施します。
構成管理アクティビティにおける各役割の権限は次のとおりです。
構成管理方法:
- マニュアル
- 自律型ツール:
  - CVS
    SVN
    GIT
    Microsoft vss
    Microsoft vss merant
    pvcs
    ca ccc/havest
    perforcereasonalclearcase

関連手順

構成ライブラリベースの変更制御:

伝説

構成ライブラリの分類:

開発ライブラリ

概要: 開発ライブラリは、ダイナミックライブラリ、プログラマライブラリ、またはワークライブラリとも呼ばれ、開発者が現在開発中の構成エンティティを保存するために使用されます。

注: 開発ライブラリは構成管理を必要としないため、構成管理者の制御は必要ありません。

管理されたライブラリ

概要: 現在のベースラインとベースラインへの変更が含まれます。

製品ライブラリ

概要: さまざまな公開されたベースラインが含まれています。

プロセス：

あるソフトウェア製品のアップグレードを例として、プロセスを簡単に説明します。
(1) アップグレードするベースライン (バージョン番号が V2.1 であると仮定します) を製品ライブラリから取り出し、管理ライブラリに入れます。
(2) プログラマは、変更するコードセグメントを管理ライブラリからチェックアウトし、それを変更のために自分の開発ライブラリに入れます。コードがチェックアウトされると、同じコード部分を同時に 1 人のプログラマのみが変更できるようにするために「ロック」されます。A がコードを変更している場合、B はチェックアウトできません。
(3> プログラマは、開発ライブラリ内の変更されたコードセグメントを管理ライブラリにチェックインします。チェックイン後、コードの「ロック」が解除され、他のプログラマがコードをチェックアウトできるようになります。 (4) すべてのアップグレードが完了し
たらソフトウェア製品の修正作業が完了すると、管理ライブラリ内の新しいベースラインが製品ライブラリに保存されます（ソフトウェア製品のバージョン番号は V2.2 に更新され、古いバージョンの V2.1 は削除されません）製品ライブラリに保存され続けます)。

前の記事:第 15 章、調達管理
次の記事:第 17 章、変更管理