[第 14 章] ドキュメントと構成管理
1章関連
1.1 試験関連
概ね、午前中の総合試験で1～2点
事例分析20回、受験しただけで21回
2 情報システムプロジェクトの文書化とその管理
2.1 ソフトウェア文書の分類
| タイプ | 効果 | ドキュメントタイプ |
|---|---|---|
| 開発ドキュメント | 描述开发过程本身 |
フィージビリティ スタディ レポートとプロジェクト概要、要件仕様、機能仕様、プログラムとデータの仕様を含む設計仕様、開発計画、ソフトウェア統合とテスト計画、品質保証計画、安全性とテスト情報 |
| 製品資料 | 描述开发过程的产物 |
トレーニング マニュアル、リファレンス マニュアルとユーザー ガイド、ソフトウェア サポート マニュアル、製品マニュアルと情報広告 |
| ドキュメントを管理する | 记录项目管理的信息 |
開発プロセスの各段階における進捗と進捗の変化の記録、ソフトウェア変更の記録、開発チームの責任の定義、プロジェクト計画、プロジェクト フェーズ レポート、構成管理計画 |
2.2 ドキュメントの品質評価
| 文書の分類 | 適用範囲 |
|---|---|
| 最低限のドキュメント (レベル 1) | 開発に適した工作量低于一个人月開発者独自のプログラム。このドキュメントには、プログラム リスト、開発記録、テスト データ、およびプログラム概要が含まれている必要があります。 |
| 内部文書 (レベル 2) | 利用可能な没有与其他用户共享资源専用のプログラムレベル 2 ドキュメント【无共享资源】には、ユーザーがプログラムをインストールして使用するのを支援するために、プログラム リスト内に十分な注意事項も含まれています。 |
| 作業文書 (レベル 3) | 適用可能な由同一单位内若干人联合开发手順、または他のユニットで使用できる手順。 |
| 正式な文書化 (レベル 4 | 正式发行供普遍使用的ソフトウェア製品をご希望の方へ |
2.3 文書仕様管理
★3. 文書の標準化された管理: ①文档书写规范、②图表编号规则、③文档目录编写标准、④文档管理制度
(1) 文書の記述基準: 記号の使用、アイコンの意味、プログラム内のコメント行の使用、文書の作成者
と(2)図表の
採番規則: 図表の検索を容易にする規則的な方法でこれらの図表に番号を付ける;
(3) 文書目録編集基準;
(4) 文書管理システム: 対応する文書管理システムを確立する必要があります
3 構成管理
構成管理を計画するのが早ければ早いほど良い!
例 1: 構成と変更管理のない R&D ドキュメントは一貫性がなくなる (全員が取得するドキュメントは一貫性がない) 例 2: 構成と変更管理のないコードは無秩序になる可能性
がある (多くの人が同じ部分を維持する)コード混乱)
★1. 構成管理には、構成管理計画の策定、構成の識別、構成の管理、構成ステータスの報告、構成の監査、
リリース管理、および配信という 6 つの主要な活動が含まれます。
★2. 典型的な構成項目には、プロジェクト計画書、要求文書、設計文書、ソースコード、実行コード、テストケース、およびソフトウェアを実行するために必要な各種データが含まれます 3. 情報の開発プロセスで管理する必要がある構成
★項目ベースライン構成アイテムと非ベースライン構成アイテムの 2 種類に分けられるベースライン構成
アイテムには、すべての設計文書やソース プログラムなどが含まれる場合があります
非ベースライン構成アイテムには、プロジェクトのさまざまな計画やレポートが含まれる場合があります。
すべての構成アイテムの操作権限は、CMO（Configuration Manager）によって厳密に管理される必要があります 基本原則：ベースライン構成アイテムは開発者に公開され、非ベースライン構成アイテムはPM、CCBおよび関係者に公開されます。
| ベースライン タイプ | ベースラインに含まれるもの | 経営理念 |
|---|---|---|
| ベースライン構成アイテム | すべての設計ドキュメントとソース コード | 開発者に読み取りアクセスを開く |
| ベースライン以外の構成アイテム | プロジェクトの各種企画・報告 | PM、CCB、および関係者に公開 |
| 例証する | すべての構成アイテムの操作権限は、CMO (Configuration Manager) によって厳密に管理されます。 |
3.1 構成アイテムのステータス
★4. 構成アイテムのステータス: 草稿、正式、修改3 種類。
構成アイテムが最初に作成されたとき、そのステータスは「ドラフト」です。構成アイテムが審査を通過すると、そのステータスは「正式」になります。
その後、構成アイテムが変更されると、そのステータスは「変更済み」に変わります。
構成アイテムが修正され、再審査に合格すると、そのステータスは「正式」に変更されます。
3.2 構成アイテムのバージョン番号
①「ドラフト」状態のバージョン番号の形式は で0.YZ、YZ の番号範囲は 01～99 です。ドラフトが改訂されると、YZ の値がインクリメントされます。YZ の初期値と増分はユーザーが決定します (例: 0.1、0.5、0.99 )
② 「公式」状態でのバージョン番号の形式はX.Y、X はメインのバージョン番号で、値の範囲は 1 ～ 9. Y はマイナー バージョン番号で、値の範囲は 0 ～ 9 です。構成アイテムが最初に「公式」ドキュメントになると、バージョン番号は 1.0 になります。（例：1.1、1.5、2.3） ③「変更
」状態のバージョン番号のフォーマットは です。構成アイテムが変更されている場合、通常は Z 値のみが増加し、XY 値は変更されません。構成アイテムが変更され、ステータスが「公式」になったら、Z 値を 0 に設定し、XY 値を増やします。(例: 1.15、1.16 )X.YZ
★6. 構成アイテムのバージョン管理は、構成の識別、構成の制御と構成の監査、リリースと配信など、複数の構成管理活動で使用されます。プロジェクトの開発プロセス中、ほとんどの構成項目は、最終決定する前にいくつかの改訂を経る必要があります。構成アイテムを変更すると、新しいバージョンが生成されます。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，バージョンの損失や混乱を回避し、構成アイテムの任意のバージョンを迅速かつ正確に見つけます。
7. 構成ベースライン (多くの場合、単にベースラインと呼ばれる) は、比較的安定した論理エンティティを形成する一連の構成アイテムで構成されます。ベースラインの構成アイテムは「凍結」されており、誰も変更できません。ベースラインへの変更は、正式な変更管理手順に従う必要があります。
★8. 一意に識別された一連の要件、設計、ソース コード ファイル、および対応する実行可能コード、構築ファイル、およびユーザー ドキュメントがベースラインを構成します。产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、己编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子.
★9. 通常、ベースラインは開発プロセスのマイルストーンに対応します。製品には 1 つ多个基线または 1 つしかありません一个基线。
◆ 外部顧客に提供するベースライン: 发行基线(リリース)
◆ 社内開発に提供するベースライン: 构造基线(ビルド)
★10. 各ベースラインの定義内容: 建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限. これらのベースラインの更新は、正式な変更管理手順を使用してのみ行う必要があります。
3.3 開発ライブラリ、管理ライブラリ、製品ライブラリ
| 構成ライブラリ | 説明 | 修正原理 |
|---|---|---|
| 開発ライブラリ | 动态库、程序员库或工作库forとも呼ばれる保存开发人员当前正在开发的配置实体動的ライブラリは开发人员的个人工作区，由开发人员自行控制. ライブラリ内の情報は、より頻繁に変更される可能性があります |
任意に変更できます` |
| 管理されたライブラリ | を含むメイン ライブラリとも呼ばれます当前的基线加上对基线的变更。制御されたリポジトリ内の構成アイテムは、完全な構成管理下に置かれます。情報システムで開発された某个阶段工作结束时，将当前的工作产品存入受控库 |
変更可能、変更手続きが必要 |
| 製品ライブラリ | 静态库、发行库、软件仓库使用のためにリリースされたさまざまなベースラインを含むアーカイブとも呼ばれ、完全な構成管理下に置かれます。開発した情報システム製品がシステムテストを完了した後、最终产品存入产品库内，等待交付用户或现场安装 |
基本的には変更しませんが、どうしても変更したい場合は変更手続きが必要です |
3.4 構成ライブラリのデータベース構築モード
構成ライブラリの構築には、by 配置项类型building と by 任务building の 2 つのモードがあります。
| データベース構築方法 | 適用範囲 | 長所と短所 |
|---|---|---|
| 構成アイテムの種類 | 通用ソフトウェア開発組織 |
製品の継承は強く、ツールは比較的統一されており、並行開発に対する一定の需要があります。このようなライブラリ構造を使用すると、構成アイテムを一元的に管理および制御でき、コンパイルおよびリリースの効率も向上します。 |
| 開発タスク | 专业ソフトウェア開発組織 |
使用される開発ツールには多くの種類があり、開発モデルは主に線形開発に基づいているため、ディレクトリの複雑さを人為的に増やすために構成アイテムを厳密に分類して格納する必要はありません。研究開発ソフトウェア組織の場合、この設定戦略を採用する方がより柔軟です |
| 例証する | ◆ 構成ライブラリの構築に使用するツール: ; また、次の方法でもライブラリを構築VSS、CVSできます手工方式 |
|
| 構成ライブラリ |  |
3.5 権限設定
構成ライブラリの権限設定は、主にライブラリに格納されている構成アイテムを誰が「閲覧」できるか、「取得」できるか、「変更」できるか、「破棄」できるかという問題を解決するためのものです。構成管理者は、プロジェクト メンバーごとに構成ライブラリへの操作権限を割り当てる責任があります。
ライブラリの権限設定を構成する
管理されたライブラリのアクセス許可の設定
製品ライブラリのアクセス許可の構成
練習問題【実技・21ケース】
一般的に言えば、品質管理者は ( ) 権限を持つべきではありません。
A. 製品ライブラリ コードの許可を確認する
B. 製品ライブラリ ドキュメントの許可を確認する
C. 管理ライブラリ コードの許可を確認する
D. 管理ライブラリ ドキュメントの許可を確認する
3.6 構成管理委員会、構成管理者
★14. 構成変更に対する承認された変更の実施を評価、承認、監督する責任を負う構成管理委員会 (CCB)。
メンバーには、プロジェクト マネージャー、ユーザー代表、プロダクト マネージャー、開発エンジニア、テスト エンジニア、品質管理担当者、構成管理者などを含めることができます。CCB は恒久的な組織である必要はなく、作業のニーズに応じて形成できます。たとえば、変更内容と変更要求に応じて異なる CCB を形成できます。小的项目CCB可以只有一个人，甚至只是兼职人员.
一般に、CCB は構成の変更を制御するだけでなく、次のような構成管理タスクも実行します配置管理计划审批、基线设立审批、产品发布审批等。
15. 構成管理者は、プロジェクト ライフ サイクル全体の構成管理活動に責任を負います。具体的には、①、编写配置管理计划②構成管理システムの確立と維持、③ 建立和维护配置库、④構成アイテムの特定、⑤ベースラインの確立と管理、⑥ 版本管理和配置控制、⑦構成ステータス レポート、 ⑧構成監査、⑨リリース管理・納品、⑩プロジェクトメンバーの構成管理培训.
16. ソフトウェア構成管理は、贯穿整个软件生命周期プロジェクトの製品の完全性を確立および維持するプロセスです。
17. ソフトウェア構成の整合性は、プロジェクトのライフ サイクル全体で管理されます。ソフトウェア品質保証担当者は、さまざまなソフトウェア ベンチマークとソフトウェア構成管理作業を定期的に確認する必要があります。ソフトウェア ベンチマークの状況と内容を、関連するグループや
★個人にタイムリーに通知できるようにする配置管理计划由配置管理员制定，配置控制委员会负责审批18。
19. 構成管理計画の主な内容は次のとおりです。
① 構成の識別、構成の管理、構成ステータスの報告、構成の監査、リリース管理、および配信を含む構成管理活動。
②これらの活動を実施するための規範と手順。
③これらの活動の実施スケジュール。
④ これらの活動を実施する責任を負う者または組織、および他の組織との関係。
★20. 構成識別は構成管理者の機能であり、基本的な手順は次のとおりです
。
② 構成要素ごとに一意の識別番号を指定します。
③ 各構成アイテムの重要な特性を定義します。
④ 各構成アイテムの所有者とその責任を決定します。
⑤ 構成品目が構成管理に入る時期と条件を決定する。
⑥ ベースラインを確立し、管理する。
⑦ ドキュメントやコンポーネントの改訂と製品のバージョンとの関係を維持する。
★21. 構成管理とは、構成アイテムとベースラインの変更管理を指し、変更要求の識別と記録、変更の分析と評価、申請の承認または拒否、変更された構成アイテムの実装、検証、およびリリースのタスクを含みます。
変更プロセス: ①变更申请、②变更评估、③通告评估结果、④变更实施、⑤变更验证与确认、⑥变更的发布、⑦基于配置库的变更控制
CCB は、変更申請の評価を整理し、次の内容を決定する責任があります。 ④変更の実施計画が実現可能かどうか、⑤変更作業量の見積もりが妥当かどうか。
3.7 ソフトウェア製品のアップグレード プロセス
①バージョンアップするベースライン（バージョンはV2.1と仮定）产品库を取り出し、 に入れます受控库。
②プログラマーは修正したいコード部分をチェック受控库アウト（Checkout）し、自分の开发库修正用ファイルに入れます。コードがチェックアウトされる
と、コードは「ロック」されて、同じコード片を同時に 1 人のプログラマーだけが変更できるようになります。A がコードを変更している場合、B はチェックアウトできません。
③プログラマーは开发库修正したコード部分をチェックインします（チェックイン）受控库。チェックイン後、コードの「ロック」が解除され、他のプログラマーがコードをチェックアウトできるようになります。
④ソフトウェア製品のバージョンアップ・リビジョン完了後、受控库データベース内の新ベースラインがデータベースに格納されます产品库（ソフトウェア製品のバージョン番号はV2.2に更新され、旧バージョンのV2.1は更新されません）。は削除され、引き続き製品ライブラリに保存されます)。
★23. 構成状況報告書の内容:
①管理されている各構成品目の識別と状況
②各変更申請の状況と承認された変更の実施状況。
③各ベースラインの現在と過去のバージョンの状況と各バージョンの比較。
④ その他の構成管理プロセス活動の記録。
3.8 構成監査
24.構成監査は、構成監査または構成評価とも呼ばれ、現在の構成項目の一貫性と完全性功能配置审计和物理配置审计を検証するためのものです。★25.構成監査の機能：①取扱説明書の誤版など、ユーザーに不適切な製品を提出することを防止する。②当初の仕様を満たしていない開発や変更要求に応じた変更が実施されていないなど、実施の不備が判明した場合。③構成アイテム間の不一致または非互換の現象を見つけます。④必要な品質管理レビューを経て、構成アイテムがベースラインに含まれ、ライブラリに格納されていることを確認します。⑤記録・文書がトレーサビリティを維持していることを確認する。★26.機能構成監査とは、構成要素（構成要素の実際の機能がその要件と一致しているかどうか）を監査し、以下を検証することです：①構成要素の開発が正常に完了したこと。②構成品目は、構成識別で指定された性能および機能特性に達しています。③構成アイテムの操作およびサポート文書が完成し、要件を満たしていること。★27.物理構成監査とは、構成品目の監査（構成品目の物理的存在が期待と一致しているかどうか）を監査し、以下を検証することです。②構成品目に必要な品目がすべて含まれているか。28. リリース管理と配信:一致性完整性①存储、②复制、③打包、④交付、⑤重建
3.9 ドキュメント管理および構成管理ツール:
1. 一般的に使用される有償ソフトウェア構成管理ツールには、
①RationalClearCase、②Perforce、③CACCC、④HavestMerantPVCS、⑤MicrosoftVSS、CVS
2. 一般的に使用されるオープン ソースおよびフリー ソフトウェア構成管理ツールには、①SVN、②GIT、③CVS があります。
3.10 リリース管理と配信
4つの練習問題
【例1-16上】ベースラインは、プロジェクト構成管理の基盤です。( ) はベースライン定義の一部ではありません。
A. ベースラインを確立するイベント B. ベースラインの識別 C. 管理対象アイテム D. ベースラインの変更を承認する権限
【例2-16上】プロジェクト構成アイテムには、ベースライン構成アイテムと非ベースライン構成アイテムがあり、 ( ) は通常、非ベースライン構成アイテムに属します。
A. 詳細設計 B. 概略設計 C. 進捗計画 D. ソースコード
【例3-16上】ソフトウェアプロジェクトの「要件仕様」が初めて正式にリリースされたときのバージョン番号は V1.0 でした。バージョン番号は () にする必要があります。
A.V1.11 B.V1.2 C.V2.0 D.V2.1
【例4-16上】構成アイテムには、ドラフト、正式リリース、修正中の 3 つの状態があります。次の記述のうち、誤っているのはどれですか ( )。
A. 構成アイテムのステータスは、最初に確立されたときは「ドラフト」であり、審査を通過すると、ステータスは「正式リリース」に変更されます B. 構成アイテムのステータスが「正式リリース」に変更された後、必要に応じてステータスが変更され
ます
C. すでに リリースされた構成アイテムは Jia の変更承認を通過しており、この時点でステータスが「変更中」に変更されているD.変更管理プロセスを
通過した構成アイテム変更管理プロセスの承認は、変更が完了した後にリリースすることができ、そのステータスは再び「正式リリース」に変更されます
【例5-16下】あるプロジェクトのスコープ ベンチマークが変更され、(62)の同意を得て要件仕様が変更された場合、構成アイテムのステータスは (63) から変更する必要があります。
(62) A. プロジェクト マネージャー B. テクニカル リーダー C. 構成管理者 D. 変更管理委員会
(63) A. 「ドラフト」が「変更中」に変更 B. 「正式リリース」が「変更中」に変更
C. 「チェックイン」が変更D.「チェックアウト」が「チェックイン」に変わります
【例6-17下】ソフトウェア製品の構成アイテムの現在のステータスをタイムリーかつ正確に取得し、ソフトウェア開発活動の進捗状況を理解するために、ソフトウェア会社はプロジェクト チームに構成ステータス レポートを発行するよう要求します。これには ( ) が含まれている必要があります。
①各変更要求の概要: 変更要求番号、申請日、申請者、ステータス、リリース バージョン、変更終了日
②ベースライン ライブラリ ステータス: ライブラリの識別、特定の日付までのライブラリ内の構成アイテムの推定数、実際の構成アイテムの数、および旧バージョン 差分説明
③リリース情報：リリースバージョン、リリース予定時期、実際のリリース時期、説明
④バックアップ情報：バックアップ日時、メディア、バックアップ保存場所
⑤構成管理ツールの状態 ⑥機器
障害情報：障害番号、デバイス番号、申請日、申請者、障害の説明、ステータス。
A.①②③⑤ B.②③④⑥ C.①②③④ D.②③④⑤
【例7-17上】以下のソフトウェアのバージョン管理に関する記述のうち、正しいものは()です。
A. ソフトウェア開発者が構成ライブラリのソース ファイルを変更する
B. 管理ライブラリは、現在のベースラインを管理し、ベースラインの変更を制御するために使用される
C. バージョン管理とリリースは、CCB によって実行される
D. ソフトウェア バージョンがアップグレードされた後、新しいベースライン製品ライブラリとバージョン番号が更新され、古いバージョンが削除される可能性がある
【例8-18上】ソフトウェア開発プロジェクトがテストされると、要件の調整が必要であることが判明する 要件仕様書などの関連ドキュメントの変更が含まれる概略設計、詳細設計、コード ( )の変更管理が必要です。
A. ナレッジ ベース B. 構成ベース C. 製品ベース D. データベース
【例9-18下】ソフトウェア構成管理の説明。間違っているのは () です。
A. 構成管理委員会のメンバーはフルタイムの人員でなければなりません
B. 構成ライブラリには、動的ライブラリ (開発ライブラリ)、管理ライブラリ (メイン ライブラリ)、および静的ライブラリ (製品ライブラリ) が含まれます C. 一般的に使用される
構成管理ツールには、AVN、 GIT など
D. 構成アイテムのステータスは、ドラフト、正式、および変更に分けられます。
【例10-18下】プロジェクト構成アイテムとベースラインの変更管理では、() が構成管理者の主な仕事です。
A. 変更によって影響を受ける関連する構成アイテムと関連するベースラインを決定する
B. 変更アプリケーションの解決の変更によって影響を受ける各利害関係者に通知する
C. 構成アイテムの変更を整理し、対応するドキュメントまたはプログラムに変更情報を記録するコード
D.変更された構成アイテムをベースラインに組み込み、変更と結果を関係者に通知します.
【例11-19上】構成管理作業では、構成アイテムの所有者とその責任を決定し、構成アイテムの時間と条件を決定します.構成管理に入ります。
A. 構成ステータス レポート B. 構成監査 C. 構成管理 D. 構成識別
【例12-19上】構成管理ボード (CCB) に関して、正しいものは () です。
A. CCB は構成ライブラリの操作権限を割り当てる責任がある
B. CCB は構成管理計画を策定する責任がある
C. CCB は恒久的施設でなければならない
D. CCB はパートタイムの従業員であっても
【例13-20下】よい 構成管理に関する記述は正しい().
A. 構成アイテムのバージョン番号は 0.91 であり、構成アイテムのステータスは「公式」です
B. 構成バージョン管理の目的は、構成アイテムの最新バージョンを維持し、バージョンの混乱を避けるためにすべての古いバージョンを削除することです
C. A 製品は 1 つのベースラインしか持つことができないため、ベースラインへの変更は正式な変更管理手順に従う必要がありますD. 開発ライブラリ内の情報は頻繁に変更される可能性があるため、開発
者自身が管理できます。
【例14-20下】構成管理者は ( ) を含めません。
A. ベースラインの確立と承認 B. バージョン管理と構成管理 C. 構成ライブラリの確立と保守 D. 構成ステータス レポート
【例15-21上】ソフトウェア製品の統合テスト段階では、問題が見つかった場合、ソース コードを変更する必要があります。今回は、プログラマーがコードを変更します。セクションは () からチェックアウトされ、変更のために独自の () に配置されます。コードは、コードの同じセクションを 1 人のプログラマーのみが変更できるようにすることが保証されています。
A. 製品ライブラリ、開発ライブラリ B. 管理ライブラリ、開発ライブラリ C. 製品ライブラリ、管理ライブラリ D. 管理ライブラリ、製品ライブラリ
【例16-21下】A、B 2 人の開発者が、情報システムの同じソフトウェア コンポーネント (同じコード セグメント) を変更するために、B が () から変更予定のコード セグメントをチェックアウトしようとすると、ロックされた状態で表示されます. 構成ライブラリの変更管理に基づいて、コード セグメントが変更されていることがわかります。この時点でエンジニア A の () で変更されました。
A. 開発ライブラリ、管理ライブラリ B. 管理ライブラリ、開発ライブラリ C. 管理ライブラリ、製品ライブラリ D. 製品ライブラリ、開発ライブラリ
【例17-22上】構成管理では、() は CCB 変更に属しません。
A. 実施計画の変更の実現可能性 B. 作業負荷の変更の合理性 C. 変更がプロジェクトに与える影響 D. 変更情報の記録の正確さ
参考回答
