軟件文檔的分類

（1）開發(fā)文檔：描述開發(fā)過程 本身

① 可行性研究報告和項目任務(wù)書
② 需求規(guī)格說明
③ 功能規(guī)格說明
④ 設(shè)計規(guī)格說明，包括程序和數(shù)據(jù)規(guī)格說明
⑤ 開發(fā)計劃
⑥ 軟件集成和測試計劃
⑦ 質(zhì)量保證計劃
⑧ 安全和測試信息

（2）產(chǎn)品文檔：描述開發(fā)過程的 產(chǎn)物

1、培訓(xùn)手冊
2、參考手冊和用戶指南
3、軟件支持手冊
4、產(chǎn)品手冊和信息廣告

（3）管理文檔：記錄項目管理的信息

1、開發(fā)過程的每個階段的進度和進度變更的記錄
2、軟件變更情況的記錄
3、開發(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級文檔。

15.1.2 信息系統(tǒng)項目相關(guān)信息（文檔）管理的規(guī)則和方法 492
信息系統(tǒng)文檔的規(guī)范化管理 主要體現(xiàn)在文檔書寫規(guī)范、圖表編號規(guī)則、文檔目錄編寫標準和文檔管理制度等幾個方面。

15.2 配置管理 493
配置管理定義：應(yīng)用技術(shù)的和管理的指導(dǎo)和監(jiān)控方法以標識和說明配置項的功能和物理特征，控制這些特征的變更，記錄和報告變更處理和實現(xiàn)狀態(tài)并驗證與規(guī)定的需求的遵循性。

配置管理包括6個主要活動：制定配置管理計劃、配置標識、配置控制、配置狀態(tài)報告、配置審計、發(fā)布管理和交付。（計識制狀態(tài)審計理付）

15.2.1 配置管理 的概念

1、配置項（基線：設(shè)計文檔和源程序，非基線：各類計劃和報告）

GB/T 11457-2006 對配置項的定義為:“為配置管理設(shè)計的硬件、軟件或二者的集合，在配置管理過程中作為一個單個實體來對待?！币韵聝?nèi)容都可以作為配置項進行管理：外部交付的軟件產(chǎn)品和數(shù)據(jù)、指定的內(nèi)部軟件工作產(chǎn)品和數(shù)據(jù)、指定的用于創(chuàng)建或支持軟件產(chǎn)品的支持工具、供方/供應(yīng)商提供的軟件和客戶提供的設(shè)備/軟件。典型配置項包括項目計劃書、需求文檔、設(shè)計文檔、源代碼、可執(zhí)行代碼、測試用例、運行軟件所需的各種數(shù)據(jù)，它們經(jīng)評審和檢查通過后進入配置管理。

所有配置項都應(yīng)按照相關(guān)規(guī)定統(tǒng)一編號，按照相應(yīng)的模板生成，并在文檔中的規(guī)定章節(jié)（部分）記錄對象的標識信息。在引入配置管理工具進行管理后，這些配置項都應(yīng)以一定的目錄結(jié)構(gòu)保存在配置庫中。

在信息系統(tǒng)的開發(fā)流程中需加以控制的配置項可以分為基線配置項和非基線配置項兩類，例如，基線配置項可能包括所有的設(shè)計文檔和源程序等；非基線配置項可能包括項目的各類計劃和報告等。

所有配置項的操作權(quán)限應(yīng)由CMO （配置管理員）嚴格管理，基本原則是：基線配置項向開發(fā)人員開放讀取的權(quán)限；非基線配置項向PM、CCB及相關(guān)人員開放。

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

2、配置項狀態(tài)（草稿、正式、修改）

配置項的狀態(tài)可分為“草稿” “正式”和“修改”三種。配置項剛建立時，其狀態(tài)為“草稿”。配置項通過評審后，其狀態(tài)變?yōu)椤罢健?。此后?strong>更改配置項，則其狀態(tài)變?yōu)椤?strong>修改”。當(dāng)配置項修改完畢并重新通過評審時，其狀態(tài)又變?yōu)椤罢健薄?br>

3、配置項版本號

配置項的版本號規(guī)則與配置項的狀態(tài)相關(guān)。
（1）處于 “草稿” 狀態(tài)的配置項的版本號格式為 0.YZ, YZ的數(shù)字范圍為01?99。 隨著草稿的修正，YZ的取值應(yīng)遞增。YZ的初值和增幅由用戶自己把握。
（2）處于 “正式” 狀態(tài)的配置項的版本號格式為 X.Y，X為主版本號，取值范圍為1?9。Y為次版本號，取值范圍為0?9。配置項第一次成為“正式”文件時，版本號為1.0。
如果配置項升級幅度比較小，可以將變動部分制作成配置項的附件，附件版本依次為1.0，1.1，……。當(dāng)附件的變動積累到一定程度時，配置項的Y值可適量增加，Y值增加一定程度時，X值將適量增加。當(dāng)配置項升級幅度比較大時，才允許直接增大X值。
（3）處于 “修改” 狀態(tài)的配置項的版本號格式為 X.YZ。配置項正在修改時，一般只增大Z值，X.Y值保持不變。當(dāng)配置項修改完畢，狀態(tài)成為“正式”時，將Z值設(shè)置為0，增加X.Y值。參見上述規(guī)則（2) 。

4、配置項版本管理

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

5、配置基線

信息系統(tǒng)的開發(fā)過程是一個不斷變化著的過程，為了在不嚴重阻礙合理變化的情況下來控制變化，配置管理引入了“配置基線(Configuration Baseline)”這一概念。
配置基線（常簡稱為基線）由一組配置項組成，這些配置項構(gòu)成一個相對穩(wěn)定的邏輯實體?；€中的配置項被“凍結(jié)” 了，不能再被任何人隨意修改。對基線的變更必須遵循正式的變更控制程序。
一組擁有唯一標識號的需求、設(shè)計、源代碼文卷以及相應(yīng)的可執(zhí)行代碼、構(gòu)造文卷和用戶文檔構(gòu)成一條基線。產(chǎn)品的一個測試版本（可能包括需求分析說明書、概要設(shè)計說明書、詳細設(shè)計說明書、已編譯的可執(zhí)行代碼、測試大綱、測試用例、使用手冊等）是基線的一個例子。
基線通常對應(yīng)于開發(fā)過程中的里程碑，—個產(chǎn)品可以有多個基線，也可以只有一個基線。交付給外部顧客的基線一般稱為發(fā)行基線，內(nèi)部開發(fā)使用的基線一般稱為構(gòu)造基線。
對于每一個基線，要定義下列內(nèi)容：建立基線的事件、受控的配置項、建立和變更基線的程序、批準變更基線所需的權(quán)限。在項目實施過程中，每個基線都要納入配置控制，對這些基線的更新只能采用正式的變更控制程序。

建立基線還可以有如下好處：
(1)基線為開發(fā)工作提供了一個定點和快照。
(2)新項目可以在基線提供的定點上建立。新項目作為一個單獨分支，將與隨后對原始項目(在主要分支上)所進行的變更進行隔離。
(3)當(dāng)認為更新不穩(wěn)定或不可信時，基線為團隊提供一種取消變更的方法。
(4)可以利用基線重新建立基于某個特定發(fā)布版本的配置，以重現(xiàn)已報告的錯誤。

6、配置庫（開發(fā)、受控、產(chǎn)品 庫）

配置庫(Configuration Library)存放配置項 并 記錄與配置項相關(guān)的所有信息，是配置管理的有力工具，利用庫中的信息可回答許多配置管理的問題。
使用配置庫可以幫助配置管理員把信息系統(tǒng)開發(fā)過程的各種工作產(chǎn)品，包括半成品或階段產(chǎn)品和最終產(chǎn)品管理得井井有條，使其不致管亂、管混、管丟。

配置庫可以分為開發(fā)庫、受控庫、產(chǎn)品庫3種類型
（1）開發(fā)庫，也稱為動態(tài)庫、程序員庫或工作庫，用于保存開發(fā)人員當(dāng)前正在開發(fā)的配置實體，如：新模塊、文檔、數(shù)據(jù)元素或進行修改的已有元素。動態(tài)中的配置項被置于版本管理之下。動態(tài)庫是開發(fā)人員的個人工作區(qū)，由開發(fā)人員自行控制。庫中的信息可能有較為頻繁的修改，只要開發(fā)庫的使用者認為有必要，無需對其進行配置控制，因為這通常不會影響到項目的其他部分。
（2）受控庫，也稱為主庫，包含當(dāng)前的基線加上對基線的變更。受控庫中的配置項被置于完全的配置管理之下。在信息系統(tǒng)開發(fā)的某個階段工作結(jié)束時，將當(dāng)前的工作產(chǎn)品存入受控庫。
（3）產(chǎn)品庫，也稱為靜態(tài)庫、發(fā)行庫、軟件倉庫，包含已發(fā)布使用的各種基線的存檔，被置于完全的配置管理之下。在開發(fā)的信息系統(tǒng)產(chǎn)品完成系統(tǒng)測試之后，作為最終產(chǎn)品存入產(chǎn)品庫內(nèi)，等待交付用戶或現(xiàn)場安裝。

建庫模式：按配置項類型建庫（通用軟件）、按任務(wù)建庫（專業(yè)軟件）

配置庫的建庫模式有兩種：按配置項類型建庫和按任務(wù)建庫。
（1）按配置項的 類型分類建庫，適用于通用軟件的開發(fā)組織。使用這樣的庫結(jié)構(gòu)有利于對配置項的統(tǒng)一管理和控制，同時也能提高編譯和發(fā)布的效率。但由于這樣的庫結(jié)構(gòu)并不是面向各個開發(fā)團隊的開發(fā)任務(wù)的，所以可能會造成開發(fā)人員的工作目錄結(jié)構(gòu)過于復(fù)雜，帶來一些不必要的麻煩。
（2）按開發(fā) 任務(wù)建立相應(yīng)的配置庫，適用于專業(yè)軟件的開發(fā)組織。在這樣的組織內(nèi)，使用的開發(fā)工具種類繁多，開發(fā)模式以線性發(fā)展為主，所以就沒有必要把配置項嚴格地分類存儲，人為增加目錄的復(fù)雜性。對于研發(fā)性的軟件組織來說，采用這種設(shè)置策略比較靈活。

7、 配置庫權(quán)限設(shè)置

配置庫的權(quán)限設(shè)置主要是解決庫內(nèi)存放的配置項什么人可以“看”、什么人可以“取”、什么人可以“改”、什么人可以“銷毀”等問題。
配置管理員負責(zé)為每個項目成員分配對配置庫的操作權(quán)限。



質(zhì)量保證工程師(QA)

8、配置控制委員會（CCB），決策機構(gòu)

配置控制委員會(Configuration Control Board, CCB),負責(zé)對配置變更做出評估、審批以及監(jiā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ā)布審批等。

9、配置管理員（CMO）

配置管理員(Configuration Management Officer, CMO),負責(zé)在項目的整個生命周期中進行配置管理活動，具體有：
（1）編寫配置管理計劃
（2）建立和維護配置管理系統(tǒng)
（3）建立和維護配置庫
（4）配置項識別
（5）建立和管理基線
（6）版本管理和配置控制
（7）配置狀態(tài)報告
（8）配置審計
（9）發(fā)布管理和交付
（10）對項目成員進行配置管理培訓(xùn)

10、配置管理系統(tǒng)

配置管理系統(tǒng)是用來進行配置管理的軟件系統(tǒng)，其目的是通過確定配置管理細則和提供規(guī)范的配置管理軟件，加強信息系統(tǒng)開發(fā)過程的質(zhì)量控制，增強信息系統(tǒng)開發(fā)過程的可控性，確保配置項(包括各種文檔、數(shù)據(jù)和程序)的完備、清晰、一致和可追蹤性，以及配置項狀態(tài)的可控制性。

15.2.2 制定配置管理計劃

配置管理計劃是對如何開展項目配置管理工作的規(guī)劃，是配置管理過程的基礎(chǔ)，應(yīng)該形成文件并在整個項目生命周期內(nèi)處于受控狀態(tài)。配置控制委員會負責(zé)審批該計劃。
配置管理計劃的主要內(nèi)容為：
（1）配置管理活動，覆蓋的主要活動包括配置標識、配置控制、配置狀態(tài)報告、配置審計、發(fā)布管理與交付；
（2）實施這些活動的規(guī)范和流程；
（3）實施這些活動的進度安排；
（4）負責(zé)實施這些活動的人員或組織，以及他們和其他組織的關(guān)系。

15.2.3 配置標識

配置標識（Configuration Identification）也稱配置識別，包括為系統(tǒng)選擇配置項并在技術(shù)文檔中記錄配置項的功能和物理特征。配置標識是配置管理員的職能，基本步驟如下
（1）識別需要受控的配置項
（2）為每個配置項指定唯一性的標識號
（3）定義每個配置項的重要特征
（4）確定每個配置項的所有者及其責(zé)任
（5）確定配置項進入配置管理的時間和條件
（6）建立和控制基線
（7）維護文檔和組件的修訂與產(chǎn)品版本之間的關(guān)系

15.2.4 配置控制

配置控制即配置項和基線的 變更控制，包括下述任務(wù)：標識和記錄變更申請，分析和評價變更，批準或否決申請，實現(xiàn)、驗證和發(fā)布已修改的配置項。
1、變更申請
2、變更評估
CCB負責(zé)組織對變更申請進行評估并確定以下內(nèi)容。
（1）變更對項目的影響。
（2）變更的內(nèi)容是否必要。
（3）變更的范圍是否考慮周全。
（4）變更的實施方案是否可行。
（5）變更工作量估計是否合理。
3、通告評估結(jié)果
4、變更實施
5、變更驗證與確認
6、變更的發(fā)布
7、基于配置庫的變更控制
現(xiàn)以某軟件產(chǎn)品升級為例，簡述其流程。
(1)將待升級的基線(假設(shè)版本號為V2.1)從產(chǎn)品庫中取出，放入受控庫。
(2)程序員將欲修改的代碼段從受控庫中檢出(Check out)，放入自己的開發(fā)庫中進行修改。代碼被Check out后即被“鎖定”，以保證同一段代碼只能同時被一個程序員修改，如果甲正對其修改，乙就無法Check out。
(3)程序員將開發(fā)庫中修改好的代碼段檢入(Check in)受控庫。Check in后，代碼的“鎖定”被解除，其他程序員可以Check out該段代碼了。
(4)軟件產(chǎn)品的升級修改工作全部完成后，將受控庫中的新基線存入產(chǎn)品庫中(軟件產(chǎn)品的版本號更新為V2.2，舊的V2.1版并不刪除，繼續(xù)在產(chǎn)品庫中保存)。

15.2.5 配置狀態(tài)報告

配置狀態(tài)報告（Configuration Status Reporting）也稱配置狀態(tài)統(tǒng)計（Configuration Status Accounting），其任務(wù)是有效地記錄和報告管理配置 所需要的信息，目的是及時、準確地給出配置項的當(dāng)前狀況，供相關(guān)人員了解，以加強配置管理工作。

配置狀態(tài)報告應(yīng)該包含以下內(nèi)容
（1）每個受控配置項的標識和狀態(tài)。一旦配置項被置于配置控制下，就應(yīng)該記錄和保存它的每個后繼進展的版本和狀態(tài)。
（2）每個變更申請的狀態(tài)和已批準的修改的實施狀態(tài)。
（3）每個基線的當(dāng)前和過去版本的狀態(tài)以及各版本的比較。
（4）其他配置管理過程活動的記錄。
配置狀態(tài)報告應(yīng)著重反映當(dāng)前基線配置項的狀態(tài)，以向管理者報告系統(tǒng)開發(fā)活動的進展情況。配置狀態(tài)報告應(yīng)定期進行，并盡量通過CASE工具自動生成。

15.2.6 配置審計

配置審計（Configuration Audit）也稱為配置審核或配置評價，包括功能配置審計和物理配置審計，分別用以驗證當(dāng)前配置項的一致性和完整性。
配置審計的實施是為了確保項目配置管理的有效性，體現(xiàn)了配置管理的最根本要求——不允許出現(xiàn)任何混亂現(xiàn)象，例如：
（1）防止向用戶提交不適合的產(chǎn)品，如交付了用戶手冊的不正確版本；
（2）發(fā)現(xiàn)不完善的實現(xiàn)，如開發(fā)出不符合初始規(guī)格說明或未按變更請求實施變更；
（3）找出各配置項間不匹配或不相容的現(xiàn)象；
（4）確認配置項己在所要求的質(zhì)量控制審核之后納入基線并入庫保存；
（5）確認記錄和文檔保持著可追溯性。

1、功能配置審計（一致性）

功能配置審計是審計配置項的一致性（配置項的實際功效是否與其需求一致），具體驗證以下幾個方面。
（1）配置項的開發(fā)已圓滿完成。
（2）配置項已達到配置標識中規(guī)定的性能和功能特征。
（3）配置項的操作和支持文檔已完成并且是符合要求的。

2、物理配置審計（完整性）

物理配置審計是審計配置項的完整性（配置項的物理存在是否與預(yù)期一致），具體驗證如下幾個方面。
（1）要交付的配置項是否存在。
（2）配置項中是否包含了所有必需的項目。

15.2.7 發(fā)布管理和交付

發(fā)布管理和交付活動的主要任務(wù)是：有效控制軟件產(chǎn)品和文檔的發(fā)行和交付，在軟件產(chǎn)品的生存期內(nèi)妥善保存代碼和文檔的母拷貝。

1、存儲

應(yīng)通過下述方式確保存儲的配置項的完整性：
（1）選擇存儲介質(zhì)使再生查錯或損壞降至最低限度
（2）根據(jù)媒體的存儲器，以一定頻次運行或刷新已存檔的配置項
（3）將副本存儲在不同的受控場所，以減少丟失的風(fēng)險

2、復(fù)制

復(fù)制是用拷貝方式制造軟件的階段。應(yīng)建立規(guī)程以確保復(fù)制的一致性和完整性。應(yīng)確保發(fā)布用的介質(zhì)不含無關(guān)項(如軟件病毒或不適合演示的測試數(shù)據(jù))。應(yīng)使用適合的介質(zhì)以確保軟件產(chǎn)品符合復(fù)制要求，確保其在整個交付期中內(nèi)容的完整性。

3、打包

應(yīng)確保按批準的規(guī)程制備交付的介質(zhì)。
應(yīng)在需方容易辨認的地方清楚地標出發(fā)布標識。

4、交付

供方應(yīng)按合同中的規(guī)定交付產(chǎn)品或服務(wù)。

5、重建

應(yīng)能重建軟件環(huán)境，以確保發(fā)布的配置項在所保留的先前版本要求的未來一段時間里是可重新配置的。

文檔管理、配置管理工具：SVN、CC、GIT。

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

文章來源地址http://www.zghlxwxcb.cn/news/detail-429483.html

到了這里，關(guān)于系統(tǒng)集成項目管理工程師 筆記（第15章 信息（文檔）和配置管理）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！