第十四章信息文檔管理與配置管理

軟件文檔分為三類

若管理文檔中的3標注了開發文檔，則屬于開發文檔里
若沒有開發兩字，則屬于管理文檔中

文檔質量的四個等級

配置管理

什么是配置管理（了解）

配置管理的6個主要活動

配置項

配置項:項目計劃書、需求文檔、設計文檔、源代碼、可執行代碼、測試用例、運行軟件所需的各種數據,它們經評審和檢查通過后進入配置管理。

---

有些文檔生成后不可修改的(如測量報告、會議紀要、工作報告) ,就不能當做配置項。配置項是可以修改的。

---

配置項可以分為基線配置項和非基線配置項兩類

●基線配置項可能包括所有的設計文檔和源程序等;
●非基線配置項可能包括項目的各類計劃和報告等。

---

所有配置項的操作權限應由CMO (配置管理員)嚴格管理,基本原則是:基線配置項向開發人員開放讀取的權限;非基線配置項向PM、CCB (控制變更委員會)及相關人員開放。

配置項的狀態

配置項的狀態可分為"草稿”“正式” 和“修改”三種。

• 配置項剛建立時,其狀態為“草稿”。配置項通過評審后,其狀態變為"正式”。
• 此后若更改配置項,則其狀態變為”修改”。當配置項修改完畢并重新通過評審時,其狀態又變為“正式”
  

配置項的版本號

( 1 )處于"草稿”狀態的配置項的版本號格式為0.YZ , Yz的數字范圍為01一99。隨著草稿的修正, Yz的取值應遞增。Yz的初值和增幅由用戶自己把握。
(例如:0.1、0.5、0.99)

( 2 )處于“正式”狀態的版本號格式為X.Y , x為主版本號,取值范圍為1一9。Y為次版本號,取值范圍為0一9。配置項第一次成為“正式”文件時,版本號為1.0。
(例如:1.1、1.5、2.3)

( 3 )處于“修改”狀態的版本號格式為X.YZ。配置項正在修改時,一般只增大z值, X.Y值保持不變。當配置項修改完畢,狀態成為“正式”時,將z值設置為0 ,增加X.Y值。
(例如:1.15、1.16)

配置項的版本管理

配置項的版本管理作用于多個配置管理活動之中，如配置標識、配置控制和配置審計、發布和交付等。在項目開發過程中,絕大部分的配置項都要經過多次的修改才能最終確定下來。對配置項的任何修改都將產生新的版本。由于我們不能保證新版本一定比舊版本”好”, 所以不能拋棄舊版本。版本管理的目的是按照一定的規則保存配置項的所有版本,避免發生版本丟失或混淆等現象,并且可以快速準確地查找到配置項的任何版本。

配置基線（了解）

配置基線(常簡稱為基線)由-組配置項組成,這些配置項構成一個相對穩定的邏輯實體。基線中的配置項被“凍結”了,不能再被任何人隨意修改。對基線的變更必須遵循正式的變更控制程序。

---

一組擁有唯一標識號的需求、設計、源代碼文卷以及相應的可執行代碼、構造文卷和用戶文檔構成一條基線。 產品的一個測試版本(可能包括需求分析說明書、概要設計說明書、詳細設計說明書、己編譯的可執行代碼、測試大綱、測試用例、使用手冊等)是基線的一個例子。

---

基線通常對應于開發過程中的里程碑( Milestone) ,一個產品可以有多個基線,也可以只有一個基線。交付給外部顧客的基線一般稱為發行基線( Release) ,內部開發使用的基線一般稱為構造基線 ( Build)。

配置庫

配置庫可以分開發庫、受控庫、產品庫3種:
①開發庫,也稱為動態庫、程序員庫或工作庫,用于保存開發人員當前正在開發的配置實體,動態庫是開發人員的個人工作區,由開發人員自行控制。庫中的信息可能有較為頻繁的修改。( 可以任意的修改)

②受控庫,也稱為主庫,包含當前的基線加上對基線的變更。受控庫中的配置項被置于完全的配置管理之下。在信息系統開發的某個階段工作結束時，將當前的工作產品存入受控庫。( 存放階段性產物的，可以修改,需要走變，更流程)

③產品庫,也稱為靜態庫、發行庫、軟件倉庫,包含已發布使用的各種基線的存檔,被置于完全的配置管理之下。在開發的信息系統產品完成系統測試之后,作為最終產品存入產品庫內,等待交付用戶或現場安裝。 (存放最終產品的, 一般不再修改,真要修改的話需要走變更流程)

了解
配置庫的建庫模式有兩種：按配置類型建庫和按任務建庫
( 1 )按配置項的類型分類建庫，適用于通用軟件的開發組織。在這樣的組織內,往往產品的繼承性較強,工具比較統- - ,對并行開發有一定的需求使用這樣的庫結構有利于對配置項的統一管理和控制,同時也能提高編譯和發布的效率。
( 2 )按開發任務建立相應的配置庫,適用于專業軟件的開發組織。在這樣的組織內,使用的開發I具種類繁多,開發模式以線性發展為主,所以就沒有必要把配置項嚴格地分類存儲,人為增加目錄的復雜性。對于研發性的軟件組織來說,采用這種設置策略比較靈活。

配置庫的權限設置（了解）

配置控制委員會 ( CCB )

配置控制委員會( CCB) ,負責對配置變更做出評估、審批以及監督已批準變更的實施。( CCB還有一個稱呼變更控制委員會)

• 其成員可以包括項目經理、用戶代表、產品經理、開發工程師、測試工程師、質量控制人員、配置管理員等。CCB不必是常設機構,完全可以根據工作的需要組成,例如按變更內容和變更請求的不同,組成不同的CCB。小的項目CCB可以只有一個人,甚至只是兼職人員。
• 通常，CCB不只是控制配置變更,而是負有更多的配置管理任務,例如:配置管理計劃審批、基線設立審批、產品發布審批等。( CCB是決策機構,不是執行機構)

配置管理員（CMO）（了解）

制定配置管理計劃（了解）

軟件配置管理是在貫穿整個軟件生命周期中建立和維護項目產品的
完整性。

---

配置管理計劃由配置管理員制定，配置控制委員會負責審批。

---

配置管理計劃的主要內容為:
①配置管理活動,覆蓋的主要活動包括配置標識、配置控制、配置狀態報告、配置審計、發布管理與交付。
②實施這些活動的規范和流程。
③實施這些活動的進度安排。
④負責實施這些活動的人員或組織,以及他們和其他組織的關系。

1. 配置標識（了解）

2. 配置控制（了解）

3. 基于配置庫的變更控制

現以某軟件產品升級為例，簡述其流程。
( 1 )將待升級的基線(假設版本號為V2.1 )從產品庫中取出,放入受控庫。
( 2 )程序員將欲修改的代碼段從受控庫中檢出(cheek out) ,放入自己的開發庫中進行修改。代碼被Check out后即被"鎖定”, 以保證同- -段代碼只能同時被一個程序員修改,如果甲正對其修改，乙就無法Check out。
( 3 )程序員將開發庫中修改好的代碼段檢入( Checkin )受控庫。Cheek in后,代碼的”鎖定”被解除,其他程序員可以Check out該段代碼了。
( 4 )軟件產品的升級修改工作全部完成后,將受控庫中的新基線存入產品庫中(軟件產品的版本號更新為V2.2，舊的V2.1版并不刪除,繼續在產品庫中保存)。

4. 配置狀態報告

每個受控配置項的標識和狀態

每個變更申請的狀態和已批準修改的實施狀態

每個基線的當前和過去版本狀態

其他配置管理活動的記錄

5. 配置審計（了解）

配置審計也稱配置審核或配置評價,包括功能配置審計和物理配置審計,分別用以驗證當前配置項的一致性和完整性。

配置審計的作用: .
①防止向用戶提交不適合的產品，如交付了用戶手冊的不正確版本。
②發現不完善的實現,如開發出不符合初始規格說明或未按變更請求實施變更。
③找出各配置項間不匹配或不相容的現象
④確認配置項已在所要求的質量控制審核之后納入基線并入庫保存。
⑤確認記錄和文檔保持著可追溯性。

功能配置審計是審計配置項的一致性(配置項的實際功效是否與其需求一致)
物理配置審計是審計配置項的完整性(配置項的物理存在是否與預期一致)

6. 發布管理和交付（了解）

發布管理和交付:①存儲②復制③打包④交付⑤重建

文檔管理、配置管理I具:SVN、CC、GIT。

各角色在配置活動中的權限

總結

以上是生活随笔為你收集整理的高项_第十四章信息文档管理与配置管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。