系統內建項目管理工程師備考資料（口袋應試第二版）19

15.文檔/配置管理

口袋應試：文檔、配置管理一章中，因為每年出題的分數占比不高，是以出題點比較集中。文檔管理中主要是：文檔的種類、文檔的品質等級；配置管理中出題點主要集中在15.2.1這一節，其中包括：配置項狀态、配置項版本号（版本号要會看會區分）、配置庫的概念和類型。其它内容大家根據個人時間和精力去複習即可。

15.1資訊系統項目相關資訊（文檔）及其管理

15.1.1資訊系統項目相關資訊（文檔）

2.資訊系統項目相關資訊（文檔）種類

軟體文檔分為三類：開發文檔、産品文檔、管理文檔。

(1) 開發文檔描述開發過程本身，基本的開發文檔是：

●可行性研究報告和項目任務書；

●需求規格說明

●功能規格說明

●設計規格說明，包括程式和資料規格說明；

●開發計劃

●軟體內建和測試計劃

●品質保證計劃；

●安全和測試資訊。

(2) 産品文檔描述開發過程的産物，基本的産品文檔包括：

●教育訓練手冊；

●參考手冊和使用者指南

●軟體支援手冊

●産品手冊和資訊廣告

(3) 管理文檔記錄項目管理的資訊，例如：

●開發過程的每個階段的進度和進度變更的記錄

●軟體變更情況的記錄

●開發團隊的職責定義。

第二版[email protected]@15.1.1

出題機率：★★★★★

140163、140363、160163、160361、180361

文檔的4個品質等級

文檔的品質可以分為四級：

(1) 最低限度文檔（1級文檔），适合開發工作量低于一個人月的開發者自用程式。 該文檔應包含程式清單、開發記錄、測試資料和程式簡介。

(2) 内部文檔（2級文檔），可用于沒有與其他使用者共享資源的專用程式。除1級文 檔提供的資訊外，2級文檔還包括程式清單内足夠的注釋以幫助使用者安裝和使用程式。

(3) 工作文檔（3級文檔），适合于由同一機關内若千人聯合開發的程式，或可被其 他機關使用的程式。

(4) 正式文檔（4級文檔），适合那些要正式發行供普遍使用的軟體産品。關鍵性程 序或具有重複管理應用性質（如工資計算）的程式需要4級文檔。4級文檔遵守GB 8567 的有關規定。

第二版[email protected]

出題機率：★★

140315

15.1.2資訊系統項目相關資訊（文檔）管理的規則和方法

資訊系統文檔的規範化管理主要展現在文檔書寫規範、圖表編号規則、文檔目錄編 寫标準和文檔管理制度等幾個方面。

1) 文檔書寫規範

2) 圖表編号規則

3)文檔目錄編寫标準

4)文檔管理制度

為了更好地進行資訊系統文檔的管理，應該建立相應的文檔管理制度。特别要注意的是，項目幹系人簽字确認後的文檔要與相關聯的電子文檔 對應，這些電子文檔還應設定為隻讀。

第二版[email protected]

出題機率：★★★

170361、180161、190161

15.2配置管理

15.2.1配置管理的概念

口袋應試：整體看配置管理的題點非常多，建議15.2.1全部熟練掌握

1.配置項

所有配置項都應按照相關規定統一編号，按照相應的模闆生成，并在文檔中的規定 章節（部分）記錄對象的辨別資訊。在引入配置管理工具進行管理後，這些配置項都應 以一定的目錄結構儲存在配置庫中。

在資訊系統的開發流程中需加以控制的配置項可以分為基線配置項和非基線配置 項兩類，例如，基線配置項可能包括所有的設計文檔和源程式等；非基線配置項可能包 括項目的各類計劃和報告等。

所有配置項的操作權限應由CMO (配置管理者）嚴格管理，基本原則是：基線配 置項向開發人員開放讀取的權限；非基線配置項向PM、CCB及相關人員開放。

第二版[email protected]

出題機率：★★

160164

2.配置項狀态

配置項的狀态可分為“草稿”、“正式”和“修改”三種。配置項剛建立時，其狀态為“草稿”。配置項通過評審後，其狀态變為“正式”。此後若更改配置項，則其狀态變為“修改”。當配置項修改完畢并重新通過評審時，其狀态又變為“正式”。

第二版[email protected]

出題機率：★★★

150165、160362、190360

3.配置項版本号

配置項的版本号規則與配置項的狀态相關。

(1)處于“草稿”狀态的配置項的版本号格式為O.YZ，YZ 的數字範圍為01～99。

随着草稿的修正，YZ 的取值應遞增。YZ 的初值和增幅由使用者自己把握。

(2)處于“正式”狀态的配置項的版本号格式為X.Y，X 為主版本号，取值範圍為1～9。Y 為次版本号，取值範圍為0～9。

配置項第一次成為“正式”檔案時，版本号為1.0。

(3)處于“修改”狀态的配置項的版本号格式為X.YZ。配置項正在修改時，一般隻增大Z 值，X.Y 值保持不變。當配置項修改完畢，狀态成為“正式”時，将Z 值設定為O，增加X.Y 值。

第二版[email protected]

出題機率：★★★★★

140165、140365、150365、160165、170362

4.配置項版本管理

配置項的版本管理作用于多個配置管理活動之中，如配置辨別、配置控制和配置審計、釋出和傳遞等。在項目開發過程中，絕大部分的配置項都要經過多次的修改才能最 終确定下來。對配置項的任何修改都将産生新的版本。由于我們不能保證新版本一定比 舊版本“好”，是以不能抛棄舊版本。版本管理的目的是按照--定的規則儲存配置項的所 有版本，避免發生版本丢失或混淆等現象，并且可以快速準确地查找到配置項的任何 版本。

第二版[email protected]

出題機率：★★

130365

5．配置基線

配置基線（常簡稱為基線）由一組配置項組成，這些配置項構成-1-個相對穩定的邏 輯實體。基線中的配置項被“當機”了，不能再被任何人随意修改。對基線的變更必須 遵循正式的變更控制程式。

一組擁有唯一辨別号的需求、設計、源代碼文卷以及相應的可執行代碼、構造文卷和使用者文檔構成一條基線。産品的一個測試版本（可能包括需求分析說明書、概要設計 說明書、詳細設計說明書、已編譯的可執行代碼、測試大綱、測試用例、使用手冊等） 是基線的一個例子。

第二版[email protected]

出題機率：★

150363

6。配置庫

配置庫（Configuration Library）存放配置項并記錄與配置項相關的所有資訊，是配置管理的有力工具，利用庫中的資訊可回答許多配置管理的問題

使用配置庫可以幫助配置管理者把資訊系統開發過程的各種工作産品，包括半成品或階段産品和最終産品管理得井井有條，使其不緻管亂、管混、管丢。

配置庫可以分為開發庫、受控庫、産品庫3種類型。

(1)開發庫（Development Library），

也稱為動态庫、程式員庫或工作庫，用于儲存開發人員目前正在開發的配置實體，如：新子產品、文檔、資料元素或進行修改的已有元素。動态中的配置項被置于版本管理之下。動态庫是開發人員的個人工作區，由開發人員自行控制。

(2)受控庫(Controlled Library)，

也稱為主庫，包含目前的基線加上對基線的變更。受控庫中的配置項被置于完全的配置管理之下。在資訊系統開發的某個階段工作結束時，将目前的工作産品存入受控庫。

(3)産品庫（Product Library），

也稱為靜态庫、發行庫、軟體倉庫，包含已釋出使用的各種基線的存檔，被置于完全的配置管理之下。在開發的資訊系統産品完成系統測試之後，作為最終産品存入産品庫内，等待傳遞使用者或現場安裝。

配置庫的建庫模式有兩種：

按配置項類型建庫和按任務建庫。

(1)按配置項的類型分類建庫，

适用于通用軟體的開發組織。在這樣的組織内，産品的繼承性往往較強，工具比較統一，對并行開發有一定的需求。使用這樣的庫結構有利于對配置項的統一管理和控制，同時也能提高編譯和釋出的效率。但由于這樣的庫結構并不是面向各個開發團隊的開發任務的，是以可能會造成開發人員的工作目錄結構過于複雜，帶來一些不必要的麻煩。

(2)按開發任務建立相應的配置庫，

适用于專業軟體的開發組織。在這樣的組織内，使用的開發工具種類繁多，開發模式以線性發展為主，是以就沒有必要把配置項嚴格地分類存儲，人為增加目錄的複雜性。對于研發性的軟體組織來說，采用這種設定政策比較靈活。

第二版[email protected]

出題機率：★★★★★

170162、170163、180162、180362、190162

9。配置管理者

配置管理者（Configuration Management Officer, CMO),負責在項目的整個生命周期中進行配置管理活動，具體有：

●編寫配置管理計劃；

●建立和維護配置管理系統；

●建立和維護配置庫；

●配置項識别；

●建立和管理基線；

●版本管理和配置控制；

●配置狀态報告；

●配置審計；

●釋出管理和傳遞；

●對項目成員進行配置管理教育訓練。

第二版[email protected]

出題機率：★

170160

15.2.3配置辨別

配置辨別（Configuration Identification)也稱配置識别，包括為系統選擇配置項并在 技術文檔中記錄配置項的功能和實體特征。

配置辨別是配置管理者的職能，基本步驟如下

(1)識别需要受控的配置項；

(2)為每個配置項指定唯一性的辨別号

(3)定義每個配置項的重要特征；

(4)确定每個配置項的所有者及其責任；

(5)确定配置項進入配置管理的時間和條件；

(6)建立和控制基線；

(7) 維護文檔群組件的修訂與産品版本之間的關系。

第二版[email protected]

出題機率：★★★

130364、150164

15.2.4配置控制

7.基于配置庫的變更控制

現以某軟體産品更新為例，簡述其流程。

(1)将待更新的基線（假設版本号為V2.1）從産品庫中取出，放入受控庫。

(2)程式員将欲修改的代碼段從受控庫中檢出(cheek out)，放入自己的開發庫中進行修改。

(3)程式員将開發庫中修改好的代碼段檢入（Check in）受控庫。Cheek in後，代碼的“鎖定”被解除，其他程式員可以Check out該段代碼了。

(4)軟體産品的更新修改工作全部完成後，将受控庫中的新基線存入産品庫中（軟體産品的版本号更新為V2.2，舊的V2.1版并不删除，繼續在産品庫中儲存）。

第二版[email protected]

出題機率：★

160366

15.2.6配置審計

配置審計(Configuration Audit）也稱配置稽核或配置評價，包括功能配置審計和實體配置審計，分别用以驗證目前配置項的一緻性和完整性。

1。功能配置審計

功能配置審計(Functional Configuration Audit)是審計配置項的一緻性（配置項的實際功效是否與其需求一緻），具體驗證以下幾個方面。

(1)配置項的開發已圓滿完成。

(2)配置項已達到配置辨別中規定的性能和功能特征。

(3)配置項的操作和支援文檔已完成并且是符合要求的。

2。實體配置審計

實體配置審計(Physical Conflguration Audit)是審計配置項的完整性（配置項的實體存在是否與預期一緻），具體驗證如下幾個方面。

(1)要傳遞的配置項是否存在。

(2)配置項中是否包含了所有必需的項目。

第二版[email protected]

出題機率：★

180314

15.2.7釋出管理和傳遞

釋出管理和傳遞活動的主要任務是：有效控制軟體産品和文檔的發行和傳遞，在軟 件産品的生存期内妥善儲存代碼和文檔的母拷貝。

1. 存儲

2。 複制

3. 打包

4. 傳遞

5. 重建

第二版[email protected]

出題機率：★

190361

●更多的備考複習資料，可以檢視我的部落格：跬步郎的部落格  。

以下内容為第一版内容，僅供參考

為了確定軟體的實作滿足需求需要的基本文檔

1、軟體需求規格說明書：必須清楚、準确地描述軟體的每一個基本需求（功能、性能、設計限制和屬性）和外部界面。

2、軟體設計說明書：包括軟體概要設計說明和軟體詳細設計說明兩部分。

3、軟體驗證與确認計劃：必須描述所采用的軟體驗證和确認方法

4、軟體驗證和确認報告：描述軟體驗證與确認計劃的執行結果。

5、使用者文檔(例如手冊、指南等)必須指明成功運作該軟體所需要的資料、控制指令以及運作條件等；必須指明所有的出錯資訊、含義及其修改方法，還必須描述将使用者發現的錯誤或問題通知項目承辦機關(或軟體開發機關)或項目委托機關的方法。

出題機率：★★

140128、150113

配置管理過程構造小組應該包括如下成員

1、小組負責人。其對整個構造過程負責。主要職責是協調與其他部門或與上級主管的關系， 監督工作程序，協調小組内部關系。

2、技術支援專家。其負責在技術、裝置方面為本組提供支援和服務，并負責本組同其他部門就技術問題進行聯絡，如了解相關項目情況、開發環境和開發人員狀況等。

3、配置管理技術專家。其對配置管理過程的構造和配置管理工具十分熟悉。主要任務是指導配置管理過程的構造，幫助制訂配置管理規章，負責對開發人員進行配置管理工具的教育訓練。通常由配置管理工具提供商或專門的配置管理顧問機構的人員擔當此任。

4、配置管理系統使用者代表。他們是從将來要在實際的項目開發過程中使用該系統、遵循該過程的開發人員中挑選出來的。他們負責從構造初期了解配置管理系統和規程，根據開發經驗協助制訂、修改配置管理規程，并在試驗項目中擔任部分開發角色。這部分成員應包括軟體開發項目經理、設計人員、編碼、測試和構造、釋出人員。該項目小組成立後，将按後述步驟開展配置管理過程的構造工作。

[email protected]

出題機率：★

140364

建立基線的目的及其在項目實施中的應用

配置項的識别是配置管理活動的基礎，也是制定配置管理計劃的重要内容。軟體配置項分類軟體的開發過程是一個不斷變化着的過程，為了在不嚴重阻礙合理變化的情況下來控制變化，軟體配置管理引入了“基線”這一概念。根據這個定義，我們在軟體的開發流程中把所有需加以控制的配置項分為基線配置項和非基線配置項兩類，例如，基線配置項可能包括所有的設計文檔和源程式等；非基線配置項可能包括項目的各類計劃和報告等。

[email protected]

出題機率：★

140370