《系统集成项目管理》第十五章 信息（文档）和配置管理
文章目錄
- 一、信息系統項目相關信息（文檔）及其管理
- 1、信息系統項目相關信息（文檔）
- 2、信息系統項目相關信息（文檔）管理的規則和辦法
- 二、配置管理
- 1、配置管理的概念
- （1）配置項
- （2）配置項狀態
- （3）配置項版本號
- （4）配置項版本管理
- （5）配置基線
- （6）配置庫
- （7）配置庫權限設置
- （8）配置控制委員會（CCB）
- （9）配置管理員（CMO）
- （10）配置管理系統
- 2、制定配置管理計劃
- 3、配置標識
- 4、配置控制
- （1）變更申請
- （2）變更評估
- （3）通告評估結果
- （4）變更實施
- （5）變更驗證與確認
- （6）變更的發布
- （7）基于配置庫的變更控制
- 5、配置狀態報告
- 6、配置審計
- （1）功能配置審計
- （2）物理配置審計
- 7、發布管理和交付
- 三、補充
- 1、各角色在配置管理活動中的權限
一、信息系統項目相關信息（文檔）及其管理
1、信息系統項目相關信息（文檔）
信息系統相關信息（文檔）：是指某種數據媒體和其中所記錄的數據。
- 它具有永久性，并可以由人或機器閱讀，通常僅用于描述人工可讀的東西。
- 在軟件工程中，文檔常常用來表示對活動、需求、過程或結果，進行描述、定義、規定、報告或認證的任何書面或圖示的信息（包括紙質文檔和電子文檔）。
信息系統項目相關信息（文檔）種類：開發文檔、產品文檔、管理文檔。
- 開發文檔：描述開發過程本身，基本的開發文檔是：
- 可行性研究報告和項目任務書；
- 需求規格說明；
- 功能規格說明；
- 設計規格說明，包括程序和數據規格說明；
- 開發計劃；
- 軟件集成和測試計劃；
- 質量保證計劃；
- 安全和測試信息。
- 產品文檔：描述開發過程的產物，基本的產品文檔包括：
- 培訓手冊；
- 參考手冊和用戶指南；
- 軟件支持手冊；
- 產品手冊和信息廣告。
- 管理文檔：記錄項目管理的信息，例如：
- 開發過程的每個階段的進度和進度變更的記錄；
- 軟件變更情況的記錄；
- 開發團隊的職責定義。
文檔的質量 可以分為 四級：
- 最低限度文檔（1級文檔）：適合開發工作量低于一個人月的開發者自用程序。該文檔應包含程序清單、開發記錄、測試數據和程序簡介。
- 內部文檔（2級文檔）：可用于沒有與其他用戶共享資源的專用程序。除1級文檔提供的信息外，2級文檔還包括程序清單內足夠的注釋以幫助用戶安裝和使用程序。
- 工作文檔（3級文檔）：適合于由同一單位內若干人聯合開發的程序，或可被其他單位使用的程序。
- 正式文檔（4級文檔）：適合那些要正式發行供普遍使用的軟件產品。關鍵性程序或具有重復管理應用性質（如工資計算）的程序需要4級文檔。4級文檔遵守GB 8567的有關規定。
2、信息系統項目相關信息（文檔）管理的規則和辦法
信息系統文檔的規范化管理：主要體現在文檔書寫規范、圖表編號規則、文檔目錄編寫標準 和 文檔管理制度等幾個方面。
（1）文檔書寫規范。遵循統一的書寫規范，包括符號的使用、圖標的含義、程序中注釋行的使用、注明文檔書寫人及書寫日期等。
- 例如，在程序的開始要用統一的格式包含程序名稱、程序功能、調用和被調用的程序、程序設計人等。
（2）圖表編號規則。對圖表進行有規則的編號，可以方便圖表的查找。圖表的編號一般采用分類結構。根據生命周期法的5個階段，可以給出如下圖所示的分類編號規則。
（3）檔目錄編寫標準。文檔目錄中應包含文檔編號、文檔名稱、格式或載體、份數、每份頁數或件數、存儲地點、存檔時間、保管人等。
- 文檔編號一般為分類結構，可以采用同圖表編號類似的編號規則。
- 文檔名稱要完整規范。
- 格式或載體指的是原始單據或報表、磁盤文件、磁盤文件打印件、大型圖表、重要文件原件、光盤存檔等。
（4）文檔管理制度。主要包括建立文檔的相關規范、文檔借閱記錄的登記制度、文檔使用權限控制規則等。
- 建立文檔的相關規范是指文檔書寫規范、圖表編號規則和文檔目錄編寫標準等。
- 文檔的借閱應該進行詳細的記錄，并且需要考慮借閱人是否有使用權限。在文檔中存在商業秘密或技術秘密的情況下，還應注意保密。特別要注意的是，項目干系人簽字確認后的文檔要與相關聯的電子文檔一一對應，這些電子文檔還應設置為只讀。
二、配置管理
配置管理：是為了系統地控制配置變更，在系統的整個生命周期中維持配置的完整性和可跟蹤性，而標識系統在不同時間點上配置的學科。
- 在GB/T 11457-2006中，將**“配置管理”**正式定義為：“應用技術的和管理的指導和監控方法以標識和說明配置項的功能和物理特征，控制這些特征的變更，記錄和報告變更處理和實現狀態并驗證與規定的需求的遵循性。”
- 配置管理包括6個主要活動：制定配置管理計劃、配置標識、配置控制、配置狀態報告、配置審計、發布管理和交付。
1、配置管理的概念
（1）配置項
配置項的定義（GB/T11457-2006）為：“為配置管理設計的硬件、軟件或二者的集合，在配置管理過程中作為一個單個實體來對待。”
- 典型配置項：包括項目計劃書、需求文檔、設計文檔、源代碼、可執行代碼、測試用例、運行軟件所需的各種數據，它們經評審和檢查通過后進入配置管理。
- 所有配置項都應按照相關規定統一編號，并以一定的目錄結構保存在配置庫中。
在信息系統的開發流程中需加以控制的配置項可以分為基線配置項和非基線配置項兩類
- 基線配置項可能包括所有的設計文檔和源程序等；
- 非基線配置項可能包括項目的各類計劃和報告等。
所有配置項的操作權限應由CMO（配置管理員） 嚴格管理，基本原則是：
- 基線配置項向開發人員開放讀取的權限；
- 非基線配置項向PM、CCB及相關人員開放。
（2）配置項狀態
配置項的狀態：可分為 草稿、正式 和 修改 三種。
- 配置項剛建立時，其狀態為“草稿”。
- 配置項通過評審后，其狀態變為**“正式”**。
- 此后若更改配置項，則其狀態變為“修改”。
- 當配置項修改完畢并重新通過評審時，其狀態又變為“正式”。
（3）配置項版本號
配置項的版本號規則與配置項的狀態相關。
- “草稿”狀態：的配置項的版本號格式為 0.YZ，YZ的數字范圍為01～99。隨著草稿的修正，YZ的取值應遞增。YZ的初值和增幅由用戶自己把握。
- “正式”狀態：的配置項的版本號格式為 X.Y ，X為主版本號，取值范圍為1～9。Y為次版本號，取值范圍為0～9。
- 配置項第一次成為“正式”文件時，版本號為1.0。
- 如果配置項升級幅度比較小，可以將變動部分制作成配置項的附件，附件版本依次為1.0，1.1，…。當附件的變動積累到一定程度時，配置項的Y值玎適量增加，Y值增加一定程度時，X值將適量增加。當配置項升級幅度比較大時，才允許直接增大X值。
- 處于“修改”狀態的配置項的版本號格式為 X.YZ。配置項正在修改時，一般只增大Z值，XY值保持不變。當配置項修改完畢，狀態成為“正式”時，將Z值設置為O，增加X.Y值。參見上述規則(2)。
（4）配置項版本管理
配置項的版本管理作用于多個配置管理活動之中，如配置標識、配置控制和配置審計、發布和交付等。
- 在項目開發過程中，絕大部分的配置項都要經過多次的修改才能最終確定下來。
- 對配置項的任何修改都將產生新的版本。由于我們不能保證新版本一定比舊版本“好”，所以不能拋棄舊版本。
- 版本管理的目的：是按照一定的規則保存配置項的 所有版本，避免發生版本丟失或混淆等現象，并且可以快速準確地查找到配置項的任何版本。
（5）配置基線
**配置基線（常簡稱為基線）**由一組配置項組成，這些配置項構成一個相對穩定的邏輯實體。基線中的配置項被“凍結”了，不能再被任何人隨意修改。對基線的變更必須遵循正式的變更控制程序。
- 基線的構成：一組擁有唯一標識號的需求、設計、源代碼文卷以及相應的可執行代碼、構造文卷和用戶文檔構成一條基線。
- 產品的一個測試版本（可能包括需求分析說明書、概要設計說明書、詳細設計說明書、已編譯的可執行代碼、測試大綱、測試用例、使用手冊等）是基線的一個例子。
- 基線通常對應于開發過程中的里程碑( Milestone)，一個產品可以有多個基線，也可以只有一個基線。
- 交付給外部顧客的基線一般稱為發行基線( Release)，
- 內部開發使用的基線一般稱為構造基線(Build)。
- 對于每一個基線，要定義下列內容：建立基線的事件、受控的配置項、建立和變更基線的程序、批準變更基線所需的權限。
（6）配置庫
配置庫(Configuration Library)：存放配置項并記錄與配置項相關的所有信息。
配置庫可以分開發庫、受控庫、產品庫3種類型。
- 開發庫（Development Library），也稱為動態庫、程序員庫或工作庫，用于保存開發人員當前正在開發的配置實體，如：新模塊、文檔、數據元素或進行修改的已有元素。動態中的配置項被置于版本管理之下。動態庫是開發人員的個人工作區，由開發人員自行控制。庫中的信息可能有較為頻繁的修改，只要開發庫的使用者認為有必要，無需對其進行配置控制，因為這通常不會影響到項目的其他部分。
- 受控庫（Controlled Library），也稱為主庫，包含當前的基線加上對基線的變更。受控庫中的配置項被置于完全的配置管理之下。在信息系統開發的某個階段工作結束時，將當前的工作產品存入受控庫。若修改需要進行變更控制過程。
- 產品庫(Product Library)，也稱為靜態庫、發行庫、軟件倉庫，包含已發布使用的各種基線的存檔，被置于完全的配置管理之下。在開發的信息系統產品完成系統測試之后，作為最終產品存入產品庫內，等待交付用戶或現場安裝。
配置庫的建庫模式有兩種：按配置項類型建庫 和 按任務建庫。
- 按配置項的類型分類建庫，適用于通用軟件的開發組織。在這樣的組織內，往往產品的繼承性較強，工具比較統一，對并行開發有一定的需求。使用這樣的庫結構有利于對配置項的統一管理和控制，同時也能提高編譯和發布的效率。但由于這樣的庫結構并不是面向各個開發團隊的開發任務的，所以可能會造成開發人員的工作目錄結構過于復雜，帶來一些不必要的麻煩。
- 按開發任務建立相應的配置庫，適用于專業軟件的開發組織。在這樣的組織內，使用的開發工具種類繁多，開發模式以線性發展為主，所以就沒有必要把配置項嚴格地分類存儲，人為增加目錄的復雜性。對于研發性的軟件組織來說，采用這種設置策略比較靈活。
（7）配置庫權限設置
配置庫的權限設置主要是解決：庫內存放的配置項什么人可以“看”、什么人可以“取”、什么人可以“改”、什么人可以“銷毀”等問題。
配置管理員 負責為每個項目成員分配對配置庫的操作權限.
（8）配置控制委員會（CCB）
配置控制委員會(Configuration Control Board，CCB)，負責對配置變更做出評估、審批以及監督已批準變更的實施。
- CCB建立在項目級，其成員可以包括項目經理、用戶代表、產品經理、開發工程師、測試工程師、質量控制人員、配置管理員等。
- CCB不必是常設機構，完全可以根據工作的需要組成，例如按變更內容和變更請求的不同，組成不同的CCB。
- 小的項目CCB可以只有一個人，甚至只是兼職人員。
通常，CCB不只是控制配置變更，而是負有更多的配置管理任務，例如：配置管理計劃審批、基線設立審批、產品發布審批等。
（9）配置管理員（CMO）
配置管理員(Configuration Management Oflicer，CMO)，負責在整個項目生命周期中進行配置管理活動，具體有：
- 編寫配置管理計劃。
- 建立和維護配置管理系統。
- 建立和維護配置摩。
- 配置項識別。
- 建立和管理基線。
- 版本管理和配置控制。
- 配置狀態報告。
- 配置審計。
- 發布管理和交付。
- 對項目成員進行配置管理培訓。
（10）配置管理系統
配置管理系統：用來進行配置管理的軟件系統。
- 目的：通過確定配置管理細則和提供規范的配置管理軟件，加強信息系統開發過程的質量控制，增強信息系統開發過程的可控性，確保配置項（包括各種文檔、數據和程序）的完備、清晰、一致和可追蹤性，以及配置項狀態的可控制性。
2、制定配置管理計劃
配置管理計劃：對如何開展項目配置管理工作的規劃，是配置管理過程的基礎，應該形成文件并在整個項目生命周期內處于受控狀態。
- 配置控制委員會（CCB）負責審批該計劃。
配置管理計劃的主要內容為：
- 配置管理活動，覆蓋的主要活動包括配置標識、配置控制、配置狀態報告、配置審計、發布管理與交付；
- 實施這些活動的規范和流程；
- 實施這些活動的進度安排；
- 負責實施這些活動的人員或組織，以及他們和其他組織的關系。
3、配置標識
配置標識( Configuration ldentifcation)（配置識別），包括為系統選擇配置項并在技術文檔中記錄配置項的功能和物理特征。
配置標識是 配置管理員（CMO） 的職能，基本步驟如下。
- 識別需要受控的配置項。
- 為每個配置項指定唯一性的標識號。
- 定義每個配置項的重要特征。
- 確定每個配置項的所有者及其責任。
- 確定配置項進入配置管理的時間和條件。
- 建立和控制基線。
- 維護文檔和組件的修訂與產品版本之間的關系。
4、配置控制
配置控制：配置項和基線的變更控制。
- 包括下述任務：標識和記錄變更申請，分析和評價變更，批準或否決申請，實現、驗證和發布已修改的配置項。
（1）變更申請
變更申請主要就是陳述：what，why，how。
相關流程：相關人員如項目經理填寫變更申請表，說明要變更的內容、變更的原因、受變更影響的關聯配置項和有關基線、變更實施方案、工作量和變更實施人等，并提交給配置控制委員會（CCB）。
（2）變更評估
配置控制委員會（CCB）負責組織對變更申請進行評估并確定以下內容。
- 變更對項目的影響。
- 變更的內容是否必要。
- 變更的范圍是否考慮周全。
- 變更的實施方案是否可行。
- 變更工作量估計是否合理。
CCB決定是否接受變更，并將決定通知相關人員。
（3）通告評估結果
CCB把關于每個變更申請的批準、否決或推遲的決定通知受此處置意見影響的每個干系人。
- 如果變更申請得到批準，應該及時把變更批準信息和變更實施方案通知給那些正在使用受影響的配置頊和基線的干系人。
- 如果變更申請被否決，宜通知有關干系人放棄該變更申請。
（4）變更實施
項目經理組織修改相關的配置項，并在相應的文檔或程序代碼中記錄變更信息。
（5）變更驗證與確認
項目經理指定人員對變更后的配置項進行測試或驗證。
項目經理應將變更與驗證的結果提交CCB，由其確認變更是否已經按要求完成。
（6）變更的發布
配置管理員將變更后的配置項納入基線。
配置管理員將變更內容和結果通知相關人員，并做好記錄。
（7）基于配置庫的變更控制
現以某軟件產品升級為例，簡述其流程。檢入(cheek in)
(3)程序員將開發庫中修改好的代碼段檢入(cheek in)受控庫。Cheek in后，代碼的“鎖定”被解除，其他程序員可以Check out該段代碼了。
(4)軟件產品的升級修改工作全部完成后，將受控庫中的新基線存入產品庫中（軟件產品的版本號更新為V2.2，舊的V2.1版并不刪除，繼續在產品庫中保存）。
5、配置狀態報告
配置狀態報告（Confzguration Status Reporting）也稱配置狀態統計(Configuration Status ACCounting)，其任務是有效地記錄和報告管理配置所需要的信息。
- 目的：及時、準確地給出配置項的當前狀況，供相關人員了解，以加強配置管理工作。
- 配置狀態報告應著重反映當前基線配置項的狀態，以向管理者報告系統開發活動的進展情況。
- 配置狀態報告應定期進行，并盡量通過CASE工具自動生成，用數據庫中的客觀數據來真實地反映各配置項的情況。
配置狀態報告應該包含以下內容：
- 每個受控配置項的標識和狀態。一旦配置項被置于配置控制下，就應該記錄和保存它的每個后繼進展的版本和狀態。
- 每個變更申請的狀態和已批準的修改的實施狀態。
- 每個基線的當前和過去版本的狀態以及各版本的比較。
- 其他配置管理過程活動的記錄。
6、配置審計
配置審計(Configuration Audit）（配置審核 或 配置評價）
- 包括：功能配置審計 和 物理配置審計，分別用以驗證當前配置項的 一致性 和 完整性。
- 目的：確保項目配置管理的有效性，體現了配置管理的最根本要求——不允許出現任何混亂現象，例如：
- 防止向用戶提交不適合的產品，如交付了用戶手冊的不正確版本；
- 發現不完善的實現，如開發出不符合初始規格說明或未按變更請求實施變更；
- 找出各配置項間不匹配或不相容的現象；
- 確認配置項已在所要求的質量控制審核之后納入基線并入庫保存；
- 確認記錄和文檔保持著可追溯性。
（1）功能配置審計
功能配置審計(Functional Configuration Audit) 是審計配置項的一致性（配置項的實際功效是否與其需求一致），具體驗證以下幾個方面。
- 配置項的開發已圓滿完成。
- 配置項已達到配置標識中規定的性能和功能特征。
- 配置項的操作和支持文檔已完成并且是符合要求的。
（2）物理配置審計
**物理配置審計(Physical Conflguration Audit)**是審計配置項的完整性（配置項的物理存在是否與預期一致），具體驗證如下幾個方面。
- 要交付的配置項是否存在。
- 配置項中是否包含了所有必需的項目。
7、發布管理和交付
發布管理和交付活動
- 主要任務：有效控制軟件產品和文檔的發行和交付，在軟件產品的生存期內妥善保存代碼和文檔的母拷貝。
- 存儲
- 復制
- 打包
- 交付
- 重建
三、補充
1、各角色在配置管理活動中的權限
總結
以上是生活随笔為你收集整理的《系统集成项目管理》第十五章 信息（文档）和配置管理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 《系统集成项目管理》第十四章 项目采购管
- 下一篇： 售前笔记（一）