1、軟件項目信息文檔管理與配置管理軟件項目信息文檔管理與配置管理軟件項目信息文檔管理與配置管理V:1.0精細整理，僅供參考 軟件項目信息文檔管理與配置管理日期：20 xx年X月軟件項目信息文檔管理與配置管理1、軟件文檔一般分為三類：開發(fā)文檔、產品文檔、管理文檔1）開發(fā)文檔描述開發(fā)過程本身，基本的開發(fā)文檔包括：（1）可行性研究報告和項目任務書（2）需求規(guī)格說明書（3）功能規(guī)格說明書（4）設計規(guī)格說明書，包括程序和數(shù)據(jù)規(guī)格說明書（5）開發(fā)計劃（6）軟件集成和 HYPERLINK javascript:; t _self 測試計劃（7）質量保證計劃（8）安全和測試信息2）產品文檔描述開發(fā)過程的產物，基本

2、的產品文檔包括：（1）培訓手冊（2）參考手冊和用戶指南（3）軟件支持手冊（4）產品手冊和信息廣告3）管理文檔 HYPERLINK javascript:; t _self 記錄項目信息管理的信息，例如：（1）開發(fā)過程的每個階段的進度和進度變更的記錄（2）軟件變更情況記錄（3）開發(fā)團隊職責定義（4）項目計劃、項目階段報告（5） HYPERLINK javascript:; t _self 配置管理計劃2、文檔的質量可以分為四級：最低限度文檔（1級文檔），適合開發(fā)工作量低于一個人月的開發(fā)者自用程序。該文檔應包含程序清單、開發(fā)記錄、測試數(shù)據(jù)和程序簡介。內部文檔（2級文檔），可用于沒有其他用戶共享資源

3、的專用程序。除1級文檔提供的信息外，2級文檔還包括程序清單內足夠的注釋以幫助用戶安裝和使用程序。工作文檔（3級文檔），適合于由同一單位內若干人聯(lián)合開發(fā)的程序，或被其他單位使用的程序。正式文檔（4級文檔）適合那些正式發(fā)行供普遍使用的軟件產品。關鍵性程序或具有重復管理應用性質（如工資計算）的程序需要4級文檔。4級文檔遵守GB/T8567-2006的有關規(guī)定。 3、配置管理包括6個主要活動：制定配置管理計劃、配置標識、配置控制、配置狀態(tài)報告、配置審計、發(fā)布管理和交付。4、在信息系統(tǒng)的開流程中需加以控制的配置薦可以分為基線配置和非基線配置項兩類5、所有配置項的操作權限應由CMO（配置管理員）嚴格管理，

4、基本原則是：基線配置項向開發(fā)人員開放讀取的權限；非基線配置項向PM、CCB及相關人員開放。6、配置項的狀態(tài)分為草稿、正式、修改三種。7、配置項的版本號規(guī)則與配置項的相關狀態(tài)：1）處于草稿狀態(tài)的配置項的版本號格式為2）處于正式狀態(tài)的配置項的版本號格式為3）處于修改狀態(tài)的配置項的版本號格式為并且，由于我們不能保證新版本一定比舊版本好，所以不能拋棄舊版本。8、信息系統(tǒng)的開發(fā)過程是一個不斷變化著的過程，為了在不嚴重阻礙合理變更的情況下來控制變化，配置管理引入了配置基線的概念。9、基線通常對應于開發(fā)過程中的里程碑，一個產品可以有多個基線，也可以只有一個基線。交付給外部顧客的基線一般稱為發(fā)行基線，內部開發(fā)

5、使用的基線一般稱為構造基線。10、建立基線有以下好處：1）基線為開發(fā)工作提供了一個定點和快照。2）新項目可以在基線提供的定點上建立。新項目作為一個單獨分支，將與隨后對原始項目（在主要分支上）所進行的變更進行隔離。3）當認為更新不穩(wěn)定或不可信時，基線為團隊提供一種取消變更的方法。4）可以利用基線重新建立基于某個特定發(fā)布版本的配置，以實現(xiàn)以報告的錯誤11、配置庫可以分為開發(fā)庫、受控庫、產品庫3種類型1）開發(fā)庫。也稱為動態(tài)庫、程序員庫或工作庫，用于保存開發(fā)人員當前正在開發(fā)的配置實體。動態(tài)庫是開發(fā)人員的個人工作區(qū)，由開發(fā)人員自行控制。2）受控庫。也稱為主庫，包含包含當前的基線加 上對基線的變更。受控庫

6、中的配置項被置于完全的配置管理之下。在信息系統(tǒng)開發(fā)的某個階段工作結束時，將目前的工作產品存入受控庫。3）產品庫。也稱為靜態(tài)庫、發(fā)行庫、軟件倉庫。在開發(fā)的信息系統(tǒng)產品完成測試之后，作為最終產品存入產品庫內，等待交付用戶或現(xiàn)場包裝。12、配置庫的操作權限13、受控庫的權限設置 14、產品庫的權限設置 15、配置委員會，負責對配置變更做出評估、審批以及監(jiān)督已批準變更的實施。CCB建立在項目級，其成員可以包括項目經理、用戶代表、產品經理、開發(fā)工程師、測試工程師、質量控制人員、配置管理員等。小的項目CCB可以只有一個人，甚至只是兼職人員。CCB不只是控制配置變更，而是負有更多的配置管理任務，例如：配置管

7、理、計劃審批、基線設立審批、產品發(fā)布審批等。16、配置庫的變更控制流程：1）將待升級的基線（假設版本號為）從產品庫中取出，放入受控庫2）程序員將欲修改的代碼段從受控庫中檢出（Check Out），放入自己的開發(fā)庫中進行修改。代碼被Check Out后即被鎖定，以保證員一段代碼只能同時被一個程序員修改，如果甲正對其修改，乙就無法Check Out。3）程序員將開發(fā)庫中修改好的代碼段檢入（Check in）受控庫。Check in后，代碼的鎖定被解除，其他程序員可以Check Out該段代碼了。4）軟件產品的升級修改工作全部完成后，將受控庫中的新基線存入產品庫中（軟件產品的版本號更新為，舊的版本不刪除，繼續(xù)在產品庫中保存） 17、配置審計也稱配置審核或配置評價，包括功能配置審計和物理配置審計，分別用以驗證當前配置項目的一致性和完整性。18、功能配置審計是審計配置項的一致性（配置項的實際功效是否與其一致），具體體現(xiàn)在以下幾個方面：1）配置項目的開發(fā)已圓滿完成2）配置項已到達到配置標