開発ドキュメントには、開発プロセス自体が記述されており、次の 8 つの側面が含まれます。

実現可能性調査レポートとプロジェクトのミッションステートメント

要求仕様

機能仕様

プログラム仕様やデータ仕様などの設計仕様

開発計画

ソフトウェアの統合とテストの計画

品質保証計画

安全性と試験に関する情報

製品ドキュメントは開発プロセスの製品について説明しており、基本的に次の 4 つの側面が含まれています。

トレーニングマニュアル

リファレンスマニュアルとユーザーガイド

ソフトウェアサポートマニュアル

製品パンフレットや情報広告

管理文書にはプロジェクト管理のための情報が記録されています

開発プロセスの各段階における進捗状況と進捗状況の変化の記録

ソフトウェア変更の記録

開発チームの責任の定義

プロジェクト計画、プロジェクトフェーズレポート

構成管理計画

最小限のドキュメント (レベル 1 ドキュメント)。開発ワークロードが 1 人月未満の開発者に適しています。プログラムリスト、開発記録、テストデータ、プログラム紹介が含まれます。

内部ドキュメント (レベル 2 ドキュメント)。他のユーザーとリソースを共有しない専用プログラムで利用できます。レベル 1 のドキュメントで提供される情報に加えて、レベル 2 のドキュメントには、ユーザーがプログラムをインストールして使用する際に役立つ十分なコメントがプログラム リスト内に含まれています。

作業文書 (レベル 3 文書)。同じユニット内の複数の人が共同開発したプログラム、または他のユニットで使用できるプログラムに適しています。

正式なドキュメント (レベル 4 ドキュメント)。一般向けに正式にリリースされるソフトウェア製品に適しています。

構成管理計画の作成、構成の識別、構成制御、構成ステータスのレポート、構成の監査、リリース管理および配信

外部から提供されるソフトウェア製品およびデータ

指定された内部ソフトウェア作業成果物およびデータ

ソフトウェア製品の作成またはサポートに使用される指定されたサポート ツール

サプライヤー/サプライヤーが提供するソフトウェアと顧客が提供する機器/ソフトウェア

番組企画提案

要件文書

設計ドキュメント

ソースコード

実行可能コード

テストケース

ソフトウェアを動作させるために必要な各種データ

すべての構成アイテムの操作権限は構成管理者によって管理され、ベースライン構成アイテムは開発者向けの読み取り専用権限で開発されます。非ベースライン構成アイテムは PM、CCB、および関連担当者によって開発されます。

構成項目の状態は「草案」、「正式」、「修正」の3種類に分類できます。

「ドラフト」ステータスの設定項目のバージョン番号の形式は 0.YZ で、YZ の番号範囲は 01 ～ 99 です。

「公式」状態の構成アイテムのバージョン番号形式は X.Y です。X はメインのバージョン番号で、値の範囲は 1 ～ 9 です。 Y はマイナー バージョン番号で、値の範囲は 0 ～ 9 です。

構成アイテムが初めて「公式」ファイルになるとき、バージョン番号は 1.0 です。

「変更済み」状態の構成アイテムのバージョン番号形式は X.YZ です。構成アイテムを変更する場合、通常は Z 値のみが増加し、X.Y 値は変更されません。設定項目が変更され、ステータスが「正式」になった場合は、Z 値を 0 に設定し、X.Y 値を増加させます。

ベースラインは通常、開発プロセスのマイルストーンに対応します

外部顧客に提供されるベースラインは一般にリリース ベースラインと呼ばれ、内部開発に使用されるベースラインは一般に構築ベースラインと呼ばれます。

ベースラインを確立するイベント

制御された構成アイテム

ベースラインの確立および変更の手順

ベースラインへの変更を承認するために必要な権限

各ベースラインが定義するもの

ベースラインは開発作業の固定点とスナップショットを提供します

新しいプロジェクトは、ベースラインによって提供される固定ポイントで作成できます。新しいプロジェクトは、元のプロジェクト (メイン ブランチ上) に対する後続の変更から分離された、別個のブランチとして機能します。

ベースラインは、アップデートが不安定または信頼できないと判断された場合に変更をキャンセルする方法をチームに提供します。

ベースライン化を使用すると、特定のリリースに基づいて構成を再確立し、報告されたバグを再現できます。

ベースラインを確立する利点

開発ライブラリ

管理されたライブラリ

製品ライブラリ

データベースを構築する

構成変更の評価、承認、および承認された変更の実装の監督を担当します。

CCB はプロジェクト レベルで設立され、そのメンバーにはプロジェクト マネージャー、ユーザー代表、製品マネージャー、開発エンジニア、テスト エンジニア、品質管理担当者、構成管理者などが含まれます。

CCB は、構成変更を制御する代わりに、ベースラインの承認や構成管理計画の承認など、より多くの構成管理タスクを担当します。

構成管理計画を作成する

構成管理システムを確立および維持する

構成ライブラリの作成と保守

構成項目の識別

ベースラインの確立と管理

バージョン管理と構成制御

ステータスレポートを構成する

監査の構成

リリース管理と配信

プロジェクトメンバーに構成管理トレーニングを提供する

構成管理に使用されるソフトウェア システムです。

ソフトウェア構成管理計画が作成され、関連担当者によってレビューおよび確認されていることを確認します。

管理対象のプロジェクト成果物を特定し、適切な担当者がこれらのプロジェクト成果物を確実に入手できるように、関連する管理戦略を策定する必要があります。

プロジェクト製品が管​​理された制限内で確実に変更されるように、管理戦略を策定する必要があります。

関連するグループや個人がソフトウェア ベースラインのステータスと内容をタイムリーに理解できるように、適切なツールと方法を採用する必要があります。

構成管理アクティビティ。主なアクティビティには、構成の識別、構成の制御、構成ステータスのレポート、構成の監査、リリース管理および配信が含まれます。

これらの活動を実施するための規範とプロセス

活動実施スケジュール

これらの活動の実行に責任を負う人々または組織、および他の組織との関係

構成管理計画には何が含まれますか?

制御する必要がある構成項目を特定する

各構成アイテムに一意の識別番号を指定します

各構成アイテムの重要な特性を定義する

各構成アイテムの所有者とその責任を決定する

構成アイテムが構成管理に入る時期と条件を決定する

ベースラインの確立と管理

ドキュメントおよびコンポーネントのリビジョンと製品バージョンとの関係を維持する

構成項目の識別は構成管理者の責任であり、次の手順を含める必要があります。

変更要求

変更評価

評価結果の通知

変更の実装

変更の検証と確認

変更リリース

構成リポジトリベースの変更管理

制御される各構成アイテムの ID とステータス

各変更依頼の状況と承認された変更の実施状況

各ベースラインの現在および過去のバージョンのステータスとバージョンの比較

その他の構成管理プロセスのアクティビティの記録

ステータスレポートに含まれる内容の構成

効果

機能構成の監査

物理構成の監査

ストレージ

コピー

パック

届ける

復興