《系統整合專案管理》第十五章 資訊（文件）和配置管理
文章目錄
一、資訊系統專案相關資訊（文件）及其管理
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)
- 將待升級的基線（假設版本號為V2.1）從產品庫中取出（複製操作)，放入受控庫。
- 程式設計師將欲修改的程式碼段從受控庫中檢出(cheek out)，放入自己的開發庫中進行修改。程式碼被Check out後即被“鎖定”，以保證同一段程式碼只能同時被一個程式設計師修改，如果甲正對其修改，乙就無法Check out。
(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、各角色在配置管理活動中的許可權
