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 的有關規定。
出題概率：★★
140315
15.1.2信息系統項目相關信息（文檔）管理的規則和方法
信息系統文檔的規範化管理主要體現在文檔書寫規範、圖表編號規則、文檔目錄編 寫標準和文檔管理制度等幾個方面。
1) 文檔書寫規範
2) 圖表編號規則
3)文檔目錄編寫標準
4)文檔管理制度
爲了更好地進行信息系統文檔的管理，應該建立相應的文檔管理制度。特別要注意的是，項目干係人簽字確認後的文檔要與相關聯的電子文檔 對應，這些電子文檔還應設置爲只讀。
出題概率：★★★
170361、180161、190161
15.2配置管理
15.2.1配置管理的概念
口袋應試：整體看配置管理的題點非常多，建議15.2.1全部熟練掌握
1.配置項
所有配置項都應按照相關規定統一編號，按照相應的模板生成，並在文檔中的規定 章節（部分）記錄對象的標識信息。在引入配置管理工具進行管理後，這些配置項都應 以一定的目錄結構保存在配置庫中。
在信息系統的開發流程中需加以控制的配置項可以分爲基線配置項和非基線配置 項兩類，例如，基線配置項可能包括所有的設計文檔和源程序等；非基線配置項可能包 括項目的各類計劃和報告等。
所有配置項的操作權限應由CMO (配置管理員）嚴格管理，基本原則是：基線配 置項向開發人員開放讀取的權限；非基線配置項向PM、CCB及相關人員開放。
出題概率：★★
160164
2.配置項狀態
配置項的狀態可分爲“草稿”、“正式”和“修改”三種。配置項剛建立時，其狀態爲“草稿”。配置項通過評審後，其狀態變爲“正式”。此後若更改配置項，則其狀態變爲“修改”。當配置項修改完畢並重新通過評審時，其狀態又變爲“正式”。
出題概率：★★★
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 值。
出題概率：★★★★★
140165、140365、150365、160165、170362
4.配置項版本管理
配置項的版本管理作用於多個配置管理活動之中，如配置標識、配置控制和配置審計、發佈和交付等。在項目開發過程中，絕大部分的配置項都要經過多次的修改才能最 終確定下來。對配置項的任何修改都將產生新的版本。由於我們不能保證新版本一定比 舊版本“好”，所以不能拋棄舊版本。版本管理的目的是按照--定的規則保存配置項的所 有版本，避免發生版本丟失或混淆等現象，並且可以快速準確地查找到配置項的任何 版本。
出題概率：★★
130365
5．配置基線
配置基線（常簡稱爲基線）由一組配置項組成，這些配置項構成-1-個相對穩定的邏 輯實體。基線中的配置項被“凍結”了，不能再被任何人隨意修改。對基線的變更必須 遵循正式的變更控制程序。
一組擁有唯一標識號的需求、設計、源代碼文卷以及相應的可執行代碼、構造文卷和用戶文檔構成一條基線。產品的一個測試版本（可能包括需求分析說明書、概要設計 說明書、詳細設計說明書、已編譯的可執行代碼、測試大綱、測試用例、使用手冊等） 是基線的一個例子。
出題概率：★
150363
6。配置庫
配置庫（Configuration Library）存放配置項並記錄與配置項相關的所有信息，是配置管理的有力工具，利用庫中的信息可回答許多配置管理的問題
使用配置庫可以幫助配置管理員把信息系統開發過程的各種工作產品，包括半成品或階段產品和最終產品管理得井井有條，使其不致管亂、管混、管丟。
配置庫可以分爲開發庫、受控庫、產品庫3種類型。
(1)開發庫（Development Library），
也稱爲動態庫、程序員庫或工作庫，用於保存開發人員當前正在開發的配置實體，如：新模塊、文檔、數據元素或進行修改的已有元素。動態中的配置項被置於版本管理之下。動態庫是開發人員的個人工作區，由開發人員自行控制。
(2)受控庫(Controlled Library)，
也稱爲主庫，包含當前的基線加上對基線的變更。受控庫中的配置項被置於完全的配置管理之下。在信息系統開發的某個階段工作結束時，將當前的工作產品存入受控庫。
(3)產品庫（Product Library），
也稱爲靜態庫、發行庫、軟件倉庫，包含已發佈使用的各種基線的存檔，被置於完全的配置管理之下。在開發的信息系統產品完成系統測試之後，作爲最終產品存入產品庫內，等待交付用戶或現場安裝。
配置庫的建庫模式有兩種：
按配置項類型建庫和按任務建庫。
(1)按配置項的類型分類建庫，
適用於通用軟件的開發組織。在這樣的組織內，產品的繼承性往往較強，工具比較統一，對並行開發有一定的需求。使用這樣的庫結構有利於對配置項的統一管理和控制，同時也能提高編譯和發佈的效率。但由於這樣的庫結構並不是面向各個開發團隊的開發任務的，所以可能會造成開發人員的工作目錄結構過於複雜，帶來一些不必要的麻煩。
(2)按開發任務建立相應的配置庫，
適用於專業軟件的開發組織。在這樣的組織內，使用的開發工具種類繁多，開發模式以線性發展爲主，所以就沒有必要把配置項嚴格地分類存儲，人爲增加目錄的複雜性。對於研發性的軟件組織來說，採用這種設置策略比較靈活。
出題概率：★★★★★
170162、170163、180162、180362、190162
9。配置管理員
配置管理員（Configuration Management Officer, CMO),負責在項目的整個生命週期中進行配置管理活動，具體有：
●編寫配置管理計劃；
●建立和維護配置管理系統；
●建立和維護配置庫；
●配置項識別；
●建立和管理基線；
●版本管理和配置控制；
●配置狀態報告；
●配置審計；
●發佈管理和交付；
●對項目成員進行配置管理培訓。
出題概率：★
170160
15.2.3配置標識
配置標識（Configuration Identification)也稱配置識別，包括爲系統選擇配置項並在 技術文檔中記錄配置項的功能和物理特徵。
配置標識是配置管理員的職能，基本步驟如下
(1)識別需要受控的配置項；
(2)爲每個配置項指定唯一性的標識號
(3)定義每個配置項的重要特徵；
(4)確定每個配置項的所有者及其責任；
(5)確定配置項進入配置管理的時間和條件；
(6)建立和控制基線；
(7) 維護文檔和組件的修訂與產品版本之間的關係。
出題概率：★★★
130364、150164
15.2.4配置控制
7.基於配置庫的變更控制
現以某軟件產品升級爲例，簡述其流程。
(1)將待升級的基線（假設版本號爲V2.1）從產品庫中取出，放入受控庫。
(2)程序員將欲修改的代碼段從受控庫中檢出(cheek out)，放入自己的開發庫中進行修改。
(3)程序員將開發庫中修改好的代碼段檢入（Check in）受控庫。Cheek in後，代碼的“鎖定”被解除，其他程序員可以Check out該段代碼了。
(4)軟件產品的升級修改工作全部完成後，將受控庫中的新基線存入產品庫中（軟件產品的版本號更新爲V2.2，舊的V2.1版並不刪除，繼續在產品庫中保存）。
出題概率：★
160366
15.2.6配置審計
配置審計(Configuration Audit）也稱配置審覈或配置評價，包括功能配置審計和物理配置審計，分別用以驗證當前配置項的一致性和完整性。
1。功能配置審計
功能配置審計(Functional Configuration Audit)是審計配置項的一致性（配置項的實際功效是否與其需求一致），具體驗證以下幾個方面。
(1)配置項的開發已圓滿完成。
(2)配置項已達到配置標識中規定的性能和功能特徵。
(3)配置項的操作和支持文檔已完成並且是符合要求的。
2。物理配置審計
物理配置審計(Physical Conflguration Audit)是審計配置項的完整性（配置項的物理存在是否與預期一致），具體驗證如下幾個方面。
(1)要交付的配置項是否存在。
(2)配置項中是否包含了所有必需的項目。
出題概率：★
180314
15.2.7發佈管理和交付
發佈管理和交付活動的主要任務是：有效控制軟件產品和文檔的發行和交付，在軟 件產品的生存期內妥善保存代碼和文檔的母拷貝。
1. 存儲
2。 複製
3. 打包
4. 交付
5. 重建
出題概率：★
190361
●更多的備考複習資料，可以查看我的博客：跬步郎的博客 。
以下內容爲第一版內容，僅供參考
爲了確保軟件的實現滿足需求需要的基本文檔
1、軟件需求規格說明書：必須清楚、準確地描述軟件的每一個基本需求（功能、性能、設計約束和屬性）和外部界面。
2、軟件設計說明書：包括軟件概要設計說明和軟件詳細設計說明兩部分。
3、軟件驗證與確認計劃：必須描述所採用的軟件驗證和確認方法
4、軟件驗證和確認報告：描述軟件驗證與確認計劃的執行結果。
5、用戶文檔(例如手冊、指南等)必須指明成功運行該軟件所需要的數據、控制命令以及運行條件等；必須指明所有的出錯信息、含義及其修改方法，還必須描述將用戶發現的錯誤或問題通知項目承辦單位(或軟件開發單位)或項目委託單位的方法。
出題概率：★★
140128、150113
配置管理過程構造小組應該包括如下成員
1、小組負責人。其對整個構造過程負責。主要職責是協調與其他部門或與上級主管的關係， 監督工作進程，協調小組內部關係。
2、技術支持專家。其負責在技術、設備方面爲本組提供支持和服務，並負責本組同其他部門就技術問題進行聯絡，如瞭解相關項目情況、開發環境和開發人員狀況等。
3、配置管理技術專家。其對配置管理過程的構造和配置管理工具十分熟悉。主要任務是指導配置管理過程的構造，幫助制訂配置管理規章，負責對開發人員進行配置管理工具的培訓。通常由配置管理工具提供商或專門的配置管理顧問機構的人員擔當此任。
4、配置管理系統用戶代表。他們是從將來要在實際的項目開發過程中使用該系統、遵循該過程的開發人員中挑選出來的。他們負責從構造初期瞭解配置管理系統和規程，根據開發經驗協助制訂、修改配置管理規程，並在試驗項目中擔任部分開發角色。這部分成員應包括軟件開發項目經理、設計人員、編碼、測試和構造、發佈人員。該項目小組成立後，將按後述步驟開展配置管理過程的構造工作。
出題概率：★
140364
建立基線的目的及其在項目實施中的應用
配置項的識別是配置管理活動的基礎，也是制定配置管理計劃的重要內容。軟件配置項分類軟件的開發過程是一個不斷變化着的過程，爲了在不嚴重阻礙合理變化的情況下來控制變化，軟件配置管理引入了“基線”這一概念。根據這個定義，我們在軟件的開發流程中把所有需加以控制的配置項分爲基線配置項和非基線配置項兩類，例如，基線配置項可能包括所有的設計文檔和源程序等；非基線配置項可能包括項目的各類計劃和報告等。
出題概率：★
140370
