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

軟件文檔分為三類

若管理文檔中的3標(biāo)注了開發(fā)文檔，則屬于開發(fā)文檔里
若沒有開發(fā)兩字，則屬于管理文檔中

文檔質(zhì)量的四個等級

配置管理

什么是配置管理（了解）

配置管理的6個主要活動

配置項

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

---

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

---

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

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

---

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

配置項的狀態(tài)

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

• 配置項剛建立時,其狀態(tài)為“草稿”。配置項通過評審后,其狀態(tài)變?yōu)?#34;正式”。
• 此后若更改配置項,則其狀態(tài)變?yōu)椤毙薷摹薄．?dāng)配置項修改完畢并重新通過評審時,其狀態(tài)又變?yōu)椤罢健?br />

配置項的版本號

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

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

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

配置項的版本管理

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

配置基線（了解）

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

---

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

---

基線通常對應(yīng)于開發(fā)過程中的里程碑( Milestone) ,一個產(chǎn)品可以有多個基線,也可以只有一個基線。交付給外部顧客的基線一般稱為發(fā)行基線( Release) ,內(nèi)部開發(fā)使用的基線一般稱為構(gòu)造基線 ( Build)。

配置庫

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

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

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

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

配置庫的權(quán)限設(shè)置（了解）

配置控制委員會 ( CCB )

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

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

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

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

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

---

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

---

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

1. 配置標(biāo)識（了解）

2. 配置控制（了解）

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

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

4. 配置狀態(tài)報告

每個受控配置項的標(biāo)識和狀態(tài)

每個變更申請的狀態(tài)和已批準(zhǔn)修改的實施狀態(tài)

每個基線的當(dāng)前和過去版本狀態(tài)

其他配置管理活動的記錄

5. 配置審計（了解）

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

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

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

6. 發(fā)布管理和交付（了解）

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

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

各角色在配置活動中的權(quán)限

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。