對于項目管理來說，文檔非常重要，如果是傳統(tǒng)的工程行業(yè)項目的話，僅僅標(biāo)書就是幾百上千頁的。相對來說，其實信息系統(tǒng)開發(fā)項目已經(jīng)好很多了。另外就是配置項，它是比文檔更大的一個概念，項目文檔是包含在配置項中的，除了文檔之外，它還包括源程序、計劃、報告等。今天我們就主要來看一看在信息系統(tǒng)項目中的這些文檔和配置項相關(guān)的內(nèi)容。今天的內(nèi)容比較長，但是只是說明項比較多，重點內(nèi)容其實還好。其它的相關(guān)了解知識也都是非常有用的內(nèi)容，大家可以好好看看哦。
軟件系統(tǒng)相關(guān)的文檔一般分為三類，包括 開發(fā)文檔、產(chǎn)品文檔、管理文檔 。
開發(fā)文檔用于描述 開發(fā)過程本身 ，基本的開發(fā)文檔包括：
可行性研究報告和項目任務(wù)書
需求規(guī)格說明
功能規(guī)格說明
設(shè)計規(guī)格說明，包括程序和數(shù)據(jù)規(guī)格說明
開發(fā)計劃
軟件集成和測試計劃
質(zhì)量保證計劃
安全和測試信息
產(chǎn)品文檔主要是描述 開發(fā)過程的產(chǎn)物 ，包括產(chǎn)品使用、維護、增強、轉(zhuǎn)換、傳輸方面的內(nèi)容，這些文檔包括：
培訓(xùn)手冊
參考手冊和用戶指南
軟件支持手冊
產(chǎn)品手冊和信息廣告
管理文檔記錄項目管理的信息，例如：
開發(fā)過程的每個階段的進度和進度變更的記錄
軟件變更情況的記錄
開發(fā)團隊的職責(zé)定義
項目計劃、項目階段報告
配置管理計劃
文檔的質(zhì)量可以分為四級：
1）最低限度文檔（1級文檔），適合開發(fā)工作量低于一個人月的開發(fā)者自用程序。該文檔應(yīng)包含程序清單、開發(fā)記錄、測試數(shù)據(jù)和程序簡介。
2）內(nèi)部文檔（2級文檔），可用于沒有與其他用戶共享資源的專用程序。除1級文檔提供的信息外，2級文檔還包括程序清單內(nèi)足夠的注釋以幫助用戶安裝和使用程序。
3）工作文檔（3級文檔），適合于同一單位內(nèi)若干人聯(lián)合開發(fā)的程序，或可被其他單位使用的程序。
4）正式文檔（4級文檔），適合那些要正式發(fā)行供普遍使用的軟件產(chǎn)品。關(guān)鍵性程序或具有重復(fù)管理應(yīng)用性質(zhì)（如工資計算）的程序需要4級文檔。4級文檔遵守 GB/T8567-2006 的有關(guān)規(guī)定。
配置管理是為了系統(tǒng)地控制配置變更，在系統(tǒng)的整個生命周期中維持配置的完整性和可跟蹤性，而標(biāo)識系統(tǒng)在不同時間點上配置的學(xué)科。在 GB/T 11457-2006 中，將配置管理定義為：“應(yīng)用技術(shù)的和管理的指導(dǎo)和監(jiān)控方法以標(biāo)識和說明配置項的功能和物理特性，控制這些特征的變更，記錄和報告變更處理和實現(xiàn)狀態(tài)并驗證與規(guī)定的需求的遵循性?！?/p>
其實，從上面的定義中，我們就可以看出，配置管理實際是為了解決多重維護、同時修改以及丟失版本或不知版本的問題。它包括 6 個主要的活動：制訂配置管理計劃、配置標(biāo)識、配置控制、配置狀態(tài)報告、配置審計、發(fā)布管理和交付。而 CMMI 定義的配置管理主要包含制定配置管理計劃、識別配置項、建立配置管理系統(tǒng)、創(chuàng)建或發(fā)行基線、跟蹤變更、控制變更、建立配置管理記錄、執(zhí)行配置審核、版本控制這些步驟。
配置管理計劃的主要內(nèi)容包括配置管理軟硬件資源、配置項計劃、基線計劃、交付計劃、備份計劃、配置審核和評審、變更管理等，由 CCB（變更控制委員會）審批該計劃。制定配置管理計劃，便于配置管理員按計劃開展配置管理工作，并保持配置管理工作的一致性。制定配置管理計劃的步驟包括：
建立并維護配置管理的組織方針
確定配置管理需使用的資源
分配責(zé)任
培訓(xùn)計劃
確定配置管理的項目干系人，并確定其介入時機
制定識別配置項的準(zhǔn)則
制定配置管理軟件資源
制定基線計劃
制定配置庫備份計劃
制定變更控制流程
制定審批計劃
GB/T 11457-2006 中對配置項的定義為：“為配置管理設(shè)計的硬件、軟件或二者的集合，在配置管理過程中作為一個單個實體來對待?！笨梢宰鳛榕渲庙椀挠校和獠拷桓兜能浖a(chǎn)品和數(shù)據(jù)、指定的內(nèi)部軟件工作產(chǎn)品和數(shù)據(jù)、指定的用于創(chuàng)建或支持軟件產(chǎn)品的支持工具、供方/供應(yīng)商提供的軟件和客戶提供的設(shè)備/軟件。典型配置項包括項目計劃書、需求文檔、設(shè)計文檔、源代碼、可執(zhí)行代碼、測試用例、運行軟件所需的各種數(shù)據(jù)，它們經(jīng)評審和檢查通過后進入配置管理。
在識別配置項的過程中，要遵循下列步驟：
識別配置項
為每個配置項指定唯一的標(biāo)識號
確定每個配置項的重要特征
確定配置項進入配置管理的時間
確定每個配置項擁有者的責(zé)任
填寫《配置項管理表》
審批《配置項管理表》
需要加以控制的配置項可以分為基線配置和非基線配置項兩類，基線配置可能包括所有的設(shè)計文檔和源程序等；非基線配置可能包括項目的各類計劃和報告等。所有配置項的操作權(quán)限應(yīng)由CMO（配置管理員）嚴格管理，基本原則是：基線配置項向開發(fā)人員開放讀取權(quán)限；非基線配置項向 PM、CCB 及相關(guān)人員開放。這個我們后面還會說。
配置管理系統(tǒng)用于控制工作產(chǎn)品的配置管理和變更管理。該系統(tǒng)包括存儲媒體、規(guī)程和訪問配置系統(tǒng)的工具，用于記錄和訪問變更請求的工具。CMO（配置管理員）建立并維護用于控制工作產(chǎn)品的配置管理系統(tǒng)和變更管理系統(tǒng)。建立配置管理系統(tǒng)的步驟包括：
建立使用于多控制等級配置管理的管理機制
存儲和檢索配置項
共享和轉(zhuǎn)換配置項
存儲和復(fù)原配置項的歸檔版本
存儲、更新和檢索配置管理記錄
創(chuàng)建配置管理報告
保護配置管理系統(tǒng)的內(nèi)容
權(quán)限分配
配置庫是用于記錄與配置的所有信息，是配置管理的有力工具，利用庫中的工具可評價變更的后果，這對變更控制有重要意義。從庫中還可以提取各種配置管理過程的管理信息，可利用庫中的信息查詢回答許多配置管理的問題。
配置庫可以分為三種類型：
開發(fā)庫（Development Library），也稱為動態(tài)庫、程序員庫、動態(tài)系統(tǒng)、開發(fā)系統(tǒng)、工作空間或工作庫，用于保存開發(fā)人員當(dāng)前正在開發(fā)的配置實體。無需對其進行配置控制。主要供開發(fā)人員使用，修改頻繁，控制寬松。
受控庫（Controlled Library），也稱為主庫、系統(tǒng)庫、主系統(tǒng)、受控系統(tǒng)，包含當(dāng)前基線加上對基線的變更。受控庫中的配置項被置于完全的配置管理之下，保存生存期內(nèi)某一階段結(jié)束時發(fā)布的階段性產(chǎn)品。
產(chǎn)品庫（Product Library），也稱為靜態(tài)庫、發(fā)行庫、軟件倉庫、備份庫、靜態(tài)系統(tǒng)等。包含已發(fā)布使用的各種基線的存檔，被置于完全的配置管理之下。在開發(fā)的信息系統(tǒng)產(chǎn)品完成系統(tǒng)測試之后，作為最終產(chǎn)品存入產(chǎn)品庫內(nèi)，等待交付用戶或現(xiàn)場安裝。
配置庫的建庫模式有兩種：
按配置項的類型分類建庫。這種形式適用于產(chǎn)品的繼承性較強，工作比較統(tǒng)一，對并行開發(fā)有一定的需求。優(yōu)點是有利于對配置項的統(tǒng)一管理和控制，同時也能提高編譯和發(fā)布的效率。缺點是由于這樣的庫結(jié)構(gòu)并不是面向各個開發(fā)團隊的開發(fā)任務(wù)，所以可能會造成開發(fā)人員的工作目錄結(jié)構(gòu)過于復(fù)雜，帶來一些不必要的麻煩。
按開發(fā)任務(wù)建庫。也可以說是按項目建立相應(yīng)的配置庫。適用于專業(yè)軟件相關(guān)的研發(fā)組織，優(yōu)點在于設(shè)置策略靈活，缺點則是不利于對配置項的統(tǒng)一管理和控制。
配置庫的權(quán)限管理非常重要，我們主要通過三個表格來看一下：
配置項的狀態(tài)可以分為“草稿（Draft）”、“正式發(fā)布（Released）”和“正在修改（Changing）”三種。配置項剛建立時，其狀態(tài)為“草稿”。配置項通過評審后，其狀態(tài)變?yōu)椤罢健?。此后若更改配置項，則其狀態(tài)變?yōu)椤靶薷摹薄．?dāng)配置項修改完畢并重新通過評審時，其狀態(tài)又變?yōu)椤罢健薄＿@三種狀態(tài)變化的過程可以參考下圖加深理解。
配置項的版本號規(guī)則與配置項的狀態(tài)相關(guān)：
處于“草稿”狀態(tài)的配置項的版本號格式為 0.YZ ，YZ的數(shù)字范圍為01-99。隨著草稿的修正，YZ的取值應(yīng)遞增。YZ的初值和增幅由用戶自己把握。
處于“正式”狀態(tài)的配置項的版本號格式為X.Y，X為主版本號，取值范圍為1-9，Y為次版本號，取值范圍為0-9.
處于“修改”狀態(tài)的配置項的版本號格式為X.YZ。配置項正在修改時，一般只增大Z值，X.Y值保持不變。當(dāng)配置項修改完畢，狀態(tài)成為“正式”時，將Z值設(shè)置為0，增加X.Y值。
一般來說，配置項的版本控制流程是先創(chuàng)建配置項，然后修改處于“草稿”狀態(tài)的配置項 0.YZ 的或者“發(fā)布”狀態(tài)的 X.YZ 變成“修改”狀態(tài)，版本號變成 X.Y 。然后通過技術(shù)評審或領(lǐng)導(dǎo)審批，成為正式“發(fā)布”版本，版本號也轉(zhuǎn)為 X.Y 。之后進行的變更就繼續(xù)重復(fù)上述的流程即可。
之前我們一直提到了一個名詞：基線。不知道大家有沒有印象，其實基線（配置基線）就是一組經(jīng)過正式審查并且達成一致的規(guī)范或工作產(chǎn)品，是開發(fā)工作的基礎(chǔ)?；€由一組配置項組成，這些配置項構(gòu)成了一個相對穩(wěn)定的邏輯實體?；€通常對應(yīng)于開發(fā)過程中的里程碑，一個產(chǎn)品可以有多個基線，也可以只有一個基線?；€的主要屬性有：名稱、標(biāo)示符、版本、日期等。
對于基線來說，有幾種不同的角度可以劃分出許多不同的基線。
國家標(biāo)準(zhǔn)：功能基線（系統(tǒng)規(guī)格說明）、分配基線（需求規(guī)格說明書）、產(chǎn)品基線（軟件產(chǎn)品所有配置項規(guī)格說明）
實際工作：需求基線、設(shè)計基線、測試基線、產(chǎn)品基線
對內(nèi)對外：發(fā)行基線（交付給外部客戶）、構(gòu)造基線（企業(yè)內(nèi)部使用）
上面的這幾種基線類型的劃分也是很容易出選擇題的內(nèi)容哦。建立配置基線的步驟可以概括為以下幾步：獲得CCB授權(quán)、創(chuàng)建構(gòu)造基線或發(fā)行基線、形成文件、使基線可用。
配置審核主要是對配置項的處理是否有背離初始的規(guī)格說明或已批準(zhǔn)的變更請求的現(xiàn)象。配置審核的目的就是為了確保項目配置管理的有效性。具體來說包括：防止不適用的產(chǎn)品；發(fā)現(xiàn)不完善的地方；找出各配置項之間不匹配的地方；確認配置項已在所要求的質(zhì)量控制審查之后作為基線入庫保存；確認記錄和文檔保持著可追溯性。
對于配置審核也有兩個分類：
功能配置審核：功能配置審核主要是針對驗收的，著重與功能和文檔性的完備。包括：檢查配置項的 開發(fā) 是否已圓滿 完成 ；配置項是否 已達 到規(guī)定的 性能 和 功能 特定特性；配置項的運行和支持 文檔 是否完成，是否符合要求。
物理配置審核：物理配置審核其實主要就是針對開發(fā)過程是否正確的審核。包括：每個構(gòu)建的配置項是否符合相應(yīng)的技術(shù)文檔（系統(tǒng)規(guī)格說明書、需求文檔、編碼標(biāo)準(zhǔn)等）；配置項與配置狀態(tài)報告中的信息是否相對應(yīng)。
配置狀態(tài)報告詳細記錄了開發(fā)過程中的每一項變更，反映了開發(fā)活動的歷史情況，從而達到提高所有開發(fā)人員之間的通信能力，避免出現(xiàn)不一致和沖突的目的。它的內(nèi)容包括：變更內(nèi)容、變更原因、變更請求人和實施人、變更發(fā)生時間、變更影響分析。其實配置狀態(tài)報告記錄的都是變更相關(guān)的內(nèi)容，畢竟沒有變更狀態(tài)也就不會發(fā)生變化，也就沒有報告記錄的必要，后面我們還有一課是專門講項目變更的。配置狀態(tài)報告的任務(wù)是有效記錄和報告管理配置所需要的信息。它的目的是及時、準(zhǔn)確地將軟件配置項的當(dāng)前狀況，供相關(guān)人員了解，以加強配置管理工作。
最后我們再簡單地了解一下配置管理中的角色和分工情況。配置管理過程中有幾個重要的角色，分別是項目經(jīng)理、配置控制委員會、配置管理員、開發(fā)人員。
項目經(jīng)理（PM）是整個信息系統(tǒng)開發(fā)和維護活動的負責(zé)人，他根據(jù)配置控制委員會的建議，批準(zhǔn)配置管理的各項活動并控制它們的進程。其具體工作職責(zé)如下：
制定項目的組織結(jié)構(gòu)和配置管理策略
批準(zhǔn)、發(fā)布配置管理計劃
決定項目起始基線和軟件開發(fā)工作里程碑
接受并審閱配置控制委員會的報告
配置控制委員會（CCB）負責(zé)指導(dǎo)和控制配置管理的各項具體活動的進行，為項目經(jīng)理的決策提供建議。其具體工作職責(zé)包括：
批準(zhǔn)配置項的標(biāo)志以及軟件基線的建立
制定訪問控制策略
建立、更改基線的設(shè)置、審核變更申請
根據(jù)配置管理員的報告決定相應(yīng)的對策
配置管理員（CMO），根據(jù)配置管理計劃執(zhí)行各項管理任務(wù)，定期向 CCB 提交報告，并列席 CCB 的例會。他們的具體工作職責(zé)包括：
軟件配置管理工具的日常管理與維護
提交配置管理計劃
各配置項的管理與維護
執(zhí)行版本控制和變更控制方案
完成配置審計并提交報告
對開發(fā)人員進行相關(guān)的培訓(xùn)
識別開發(fā)過程中存在的問題并制定解決方案
開發(fā)人員（Dev），他們的職責(zé)就是根據(jù)項目組織確定的配置管理計劃和相關(guān)規(guī)定，按照配置管理工具的使用模型來完成開發(fā)任務(wù)。
看著感覺非常多吧？其實重點需要我們關(guān)注的內(nèi)容并不是特別多，包括文檔分類、文檔等級、配置庫、版本號、配置審核分類這幾塊，在上面也都加粗或者標(biāo)紅了。其它的內(nèi)容其實就像開頭說過的一樣，也都是非常有意思的內(nèi)容，有興趣的同學(xué)可以查閱相關(guān)的資料繼續(xù)深入學(xué)習(xí)哦。
參考資料：
《信息系統(tǒng)項目管理師教程》
《某機構(gòu)培訓(xùn)資料》
《項目管理知識體系指南 PMBOK》第六版
