システムインテグレーションプロジェクトマネジメントエンジニア（ソフト試験中級）——第20章 ドキュメントと構成管理ノートの共有

• 序文

  ソフト テストにスムーズに合格できるように、いくつかのメモをみんなと共有してください。

• カーテン アドレス:第 20 章 ドキュメントと構成管理 - カーテン

• 概要

  • ビッグデータ

    

• 1 バージョン管理

  • 分類

    • 1. 開発資料

      • 開発プロセス自体を説明する
      • 実現可能性調査レポートおよびプロジェクト概要、要件仕様、機能仕様、プログラムおよびデータ仕様を含む設計仕様、開発計画、ソフトウェア統合およびテスト計画、品質保証計画、安全性およびテスト情報

    • 2. 製品ドキュメント

      • 開発プロセスの製品について説明する
      • トレーニング マニュアル、リファレンス マニュアルおよびユーザー ガイド、ソフトウェア サポート マニュアル、製品マニュアルおよび情報広告

    • 3. 書類の管理

      • プロジェクト管理のための記録情報
      • 開発プロセスの各段階における進捗状況と進捗状況の変更の記録、ソフトウェアの変更の記録、開発チームの責任の定義

  • グレーディング

    • レベル 1 の最低限のドキュメント

      • 開発作業量が1人月未満の開発者向けの自己利用プログラムに適しています。

    • レベル 2 の内部文書

      • 他のユーザーとリソースを共有しない専用プログラムに使用可能

    • レベル 3 の作業ドキュメント

      • 同じ組織内の複数の人が共同開発したプログラム、または他の組織で使用できるプログラムに適しています。

    • レベル 4 の正式な文書

      • 一般向けに正式にリリースされたソフトウェア製品に適しています

  • ルールメソッド

    • 1. 文書作成仕様書

      • 記号の使用、アイコンの意味、プログラム内でのコメント行の使用、文書の作成者と作成日の表示など、統一された記述基準に従う必要があります。

    • 2. チャートの番号付けルール

      • これらのチャートには、チャートの検索を容易にするために定期的に番号が付けられています。

        

    • 3. 文書目録作成基準

    • 4. 文書管理システム

      • 対応する文書管理システムを確立する必要がある

• 2 構成管理

  • サイクル

    • プロジェクトのライフサイクル全体をカバーします

  • アクティビティ

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

  • コンテンツ

    • プロジェクト計画書、要件書、設計書、ソースコード、実行コード、テストケース、ソフトウェアを実行するために必要な各種データ

  • 注意点

    • テスト報告書、議事録、作業記録は一度作成すると修正が困難なため、設定項目の内容には含まれません。

  • 運営権限

    • 管理
      • 構成マネージャー (CMO) によって厳密に管理されます
    • 原則として
      • ベースライン構成項目
        • ソフトウェア開発者へのオープンな読み取りアクセス
        • すべての設計ドキュメントとソースコードが含まれています
      • 非ベースライン構成項目
        • PM、変更管理委員会 CCB、および関連担当者が参加可能
        • プロジェクトの各種企画やレポートなどを掲載。

  • 設定項目のステータス

    

    • チップ
      • 構成アイテムが最初に作成されたとき、そのステータスは「ドラフト」です。
      • 構成アイテムが審査に合格すると、そのステータスは「正式」になります。
      • その後、設定項目を変更するとステータスが「変更済み」になります。
      • 構成アイテムが変更され、再審査に合格すると、そのステータスは再び「正式」になります。

    • 下書き

      • 0.YZ
      • YZ の数値範囲は 01 ～ 99 です。ドラフトが改訂されると、YZ の値が増加する必要があります。
      • YZの初期値と増加量はユーザーが決定します

    • 丁寧

      • XY
      • X はメインのバージョン番号で、値の範囲は 1 ～ 9 です。Y はマイナー バージョン番号で、値の範囲は 0 ～ 9 です。

    • 改訂

      • X.YZ
      • 構成アイテムを変更する場合、通常は Z 値のみが増加し、XY 値は変更されません。
      • 設定項目が変更され、ステータスが「正式」になったら、Z 値を 0 に設定し、XY 値を増加させます

  • バージョン管理

    • 構成アイテムの作成、構成アイテムの変更、構成アイテムのレビューなど、複数の構成管理アクティビティに作用します。
    • プロジェクトの開発プロセス中、ほとんどの構成項目は最終的に完成するまでに複数のリビジョンを経る必要があります。
    • 構成項目を変更すると、新しいバージョンが生成されます
    • 新しいバージョンが古いバージョンよりも必ずしも「優れている」とは保証できないため、古いバージョンを破棄することはできません
    • 目的は、特定のルールに従って構成アイテムのすべてのバージョンを保存し、バージョンの損失や混乱を回避し、構成アイテムの任意のバージョンを迅速かつ正確に見つけることです。

  • ベースライン

    • 意味

      • 比較的安定した論理エンティティを形成する一連の構成アイテムで構成されます。ベースラインの構成項目は「凍結」されており、誰も変更できなくなります
      • ベースラインへの変更は、正式な変更管理手順に従う必要があります
      • 作業成果物の所有者は、ベースラインを確立する前に、製品に迅速かつ非公式に変更を加えることができます。ベースラインが確立された後は、変更を評価および検証するための正式なプロセスを通じて変更が管理されます。

    • 構成

      • 比較的安定した論理エンティティを形成する一連の構成アイテムで構成されます。
      • ベースラインの構成項目は凍結されており、誰も変更できません。
      • ベースラインは開発プロセスのマイルストーンに対応し、製品には複数のベースラインを持つことも、1 つのベースラインのみを持つこともできます。
      • 顧客にトータルな価値を与えるベースラインをリリースベースライン「リリース」と呼び、
      • 社内開発で使用するベースラインを構築ベースライン「ビルド」と呼びます。
      • 構成アイテムは変更できます。プロジェクトの開発プロセス中、ほとんどの構成アイテムは最終的に完成するまでに複数回の変更が必要です。必要なのは、バージョン管理管理を適切に行うことだけです。

    • 例

      • 一意に識別された一連の要件、設計、ソース コード ファイル、および対応する実行可能コード、構築ファイル、およびユーザー ドキュメントがベースラインを形成します。
      • 製品のテスト バージョン (要件分析仕様、一般設計仕様、詳細設計仕様、コンパイルされた実行可能コード、テスト概要、テスト ケース、ユーザー マニュアルなどが含まれる場合があります) はベースラインの一例です。

    • コンテンツ

      • ベースライン化されたイベント、制御された構成項目、ベースラインの確立と変更の手順、ベースラインの変更を承認するために必要な権限

  • 分類

    • 1. 開発ライブラリ

      • ダイナミック ライブラリ、プログラマ ライブラリ、または作業ライブラリとも呼ばれ、開発者が現在開発している一致するエンティティを保存するために使用され、ダイナミック内の構成アイテムはバージョン管理下に置かれます。
      • 開発者自身の制御下にある、開発者の個人的なワークスペース。ライブラリ内の情報はより頻繁に変更される可能性があります

    • 2. 管理ライブラリ

      • マスター リポジトリとも呼ばれ、現在のベースラインとベースラインへの変更が含まれます。
      • 管理されたリポジトリ内の構成アイテムは完全な構成管理下に置かれます
      • 情報システム開発のフェーズの終了時に、現在の作業成果物は管理されたリポジトリに保管されます。

    • 3. 製品ライブラリ

      • 静的ライブラリ、リリース ライブラリ、ソフトウェア リポジトリとも呼ばれ、使用のためにリリースされたさまざまなベースラインのアーカイブが含まれ、完全な構成管理下に置かれます。
      • 開発した情報システム製品は、システムテストを完了した後、最終製品として製品ライブラリに保管され、ユーザーへの納品や現場での設置を待ちます。

  • データベース構築モード

    • 設定項目の種類

      • 一般ソフトウェアの開発組織
      • 製品の継承は強力であることが多く、ツールは比較的統合されており、並行開発に対する一定の需要があります。
      • 構成アイテムの一元管理や制御に役立ち、コンパイルやリリースの効率も向上します。
      • 各開発チームの開発タスク用ではないため、開発者の作業ディレクトリ構造が複雑になり、無用なトラブルが発生する可能性があります。

    • 開発タスク

      • プロフェッショナル向けソフトウェアの開発組織
      • 使用する開発ツールの種類が多く、開発モデルは主にリニア開発に基づいているため、構成アイテムを厳密に分類して保存する必要がなく、ディレクトリの複雑さが人為的に増加します。
      • 研究開発ソフトウェア組織の場合、この設定戦略を採用する方がより柔軟です。

    • 道具

      • ソフトウェア
        • VSS CVS
      • マニュアル

  • 権限

    • 運営権限

      

    • 管理されたライブラリ

      

    • 製品ライブラリ

      

  • ID認識を設定する

    • 1. 制御する必要がある構成項目を特定する
    • 2. 各構成アイテムに一意の識別番号を指定します
    • 3. 各構成アイテムの重要な特性を定義する
    • 4. 各構成アイテムの所有者とその責任を特定する
    • 5. 構成アイテムが構成管理に入る時期と条件を決定する
    • 6. ベースラインを確立して管理する
    • 7. ドキュメントおよびコンポーネントのリビジョンと製品バージョンとの関係を維持する

  • 管理者の責任を構成する

    • 1. 構成管理計画を作成する
    • 2. 構成管理システムの確立と維持
    • 3. 構成ライブラリを確立および維持する
    • 4. 構成項目の識別
    • 5. ベースラインの確立と管理
    • 6. バージョン管理と構成制御
    • 7. 構成ステータスレポート
    • 8. 構成の監査
    • 9. リリース管理と配信
    • 10. プロジェクトメンバー向けに構成管理トレーニングを実施する

  • 構成管理計画

    • 1. 構成管理活動。対象となる主な活動には、構成の識別、構成制御、構成ステータスレポート、構成監査、リリース管理および配信が含まれます。
    • 2. 活動を実施するための仕様と手順
    • 3. 活動実施スケジュール
    • 4. これらの活動を実行する責任のある個人または組織、および他の組織との関係

  • 構成ステータスレポート

    • 意味

      • 構成ステータス統計とも呼ばれるそのタスクは、構成管理に必要な情報を効果的に記録および報告することであり、その目的は、構成アイテムの現在のステータスをタイムリーかつ正確に関係者が理解できるように提供し、構成を強化することです。管理。システム開発活動の進捗状況を管理者に報告するために、現在のベースライン構成項目のステータスを反映することに重点を置く必要があります。

    • コンテンツ

      • 1. 制御される各構成アイテムの識別とステータス。構成アイテムが構成管理下に置かれると、その後の各開発のバージョンとステータスが記録され、保存される必要があります。
      • 2. 各変更依頼の状況と承認された変更の実施状況
      • 3. 各ベースラインの現在および過去のバージョンのステータスとバージョンの比較
      • 4. その他の構成管理プロセス活動の記録

  • 構成制御

    • 1. アプリケーションの変更

      • プロジェクトマネージャーなどの関係者が変更申請書に記入

    • 2. 評価倉庫を変更する

      • CCB は変更を受け入れるかどうかを決定し、その決定を関係者に通知します。

    • 3. 評価結果の通知

    • 4. 実装の変更

      • プロジェクト マネージャーは、関連する構成アイテムの変更を整理し、変更情報を対応するドキュメントまたはプログラム コードに記録します。

    • 5. 変更の検証と確認

      • プロジェクト マネージャーは、変更された構成アイテムをテストまたは検証する担当者を指名します。

    • 6. 変更の公表

      • 構成管理者は、変更内容と結果を関係者に通知し、記録を作成します。

    • 7. 構成ライブラリに基づく変更制御

      

      • ①アップグレード対象のベースラインを製品ライブラリから取り出し、管理ライブラリに入れます。
      • ②プログラマは、管理ライブラリから修正対象のコードセグメントをチェックアウト（チェックアウト）し、自身の開発ライブラリに入れて修正します。コードがチェックアウトされると、コードの同じ部分を同時に 1 人のプログラマのみが変更できるようにするために「ロック」されます。A がコードを変更している場合、B はチェックアウトできません。
      • ③ プログラマは、開発ライブラリ内の変更されたコードセグメントを管理ライブラリにチェックイン（チェックイン）します。チェックイン後、コードの「ロック」が解除され、他のプログラマがコード セグメントをチェックアウトできるようになります。
      • ④ ソフトウェア製品のアップグレードと修正がすべて完了したら、管理ライブラリ内の新しいベースラインを製品ライブラリに保存します

  • 構成監査

    • 目的

      • 1. 誤ったバージョンの取扱説明書を納品するなど、ユーザーへの不適合な製品の提供を防止します。
      • 2. 当初の仕様を満たしていない開発や、変更要求通りに実装されていない変更など、実装の不完全な箇所が発見された場合
      • 3. 構成アイテム間の不一致または非互換性を見つけます。
      • 4. 構成アイテムがベースラインに含まれており、必要な品質管理レビュー後にライブラリに保存されていることを確認します。
      • 5. 追跡可能性のために記録と文書が維持されていることを確認する

    • 分類

      • 機能構成監査の一貫性
        • 1. 構成アイテムの開発は正常に完了しました
        • 2. 構成アイテムが規定の性能および機能固有の特性を達成していること
        • 3. 構成アイテムの操作およびサポート文書が完成し、要件を満たしている
      • 物理構成監査の整合性
        • 1. 各ビルドの構成項目は対応する技術文書に準拠します。
        • 2. 設定項目は、設定ステータスレポートの情報に対応します。

  • リリース管理と配信

    • 内容: 保存、コピー、パッケージ化、配信、再構築