信息系統(tǒng)項目文檔及其管理

信息系統(tǒng)項目文檔及其管理

信息系統(tǒng)項目相關(guān)信息（文檔)

配置管理

配置管理的概念

配置管理的目標和方針

日常配置管理活動

信息系統(tǒng)項目相關(guān)信息（文檔)

1、軟件文檔一般分為三類:開發(fā)文檔、產(chǎn)品文檔、管理文檔。

(1）開發(fā)文檔描述開發(fā)過程本身，基本的開發(fā)文檔包括:

1）可行性研究報告和項目任務(wù)書。

2）需求規(guī)格說明。

3）功能規(guī)格說明。

4)設(shè)計規(guī)格說明，包括程序和數(shù)據(jù)規(guī)格說明。

5）開發(fā)計劃。

6）軟件集成和測試計劃

7）質(zhì)量保證計劃。

8）安全和測試信息。

(2）產(chǎn)品文檔描述開發(fā)過程的產(chǎn)物，基本的產(chǎn)品文檔包括:

1）培訓手冊。

2)參考手冊和用戶指南

3）軟件支持手冊。

4）產(chǎn)品手冊和信息廣告。

(3）管理文檔記錄項目管理的信息,例如:

1)開發(fā)過程的每個階段的進度和進度變更的記錄。

2）軟件變更情況的記錄。

3）開發(fā)團隊的職責定義。

4）項目計劃、項目階段報告。

5）配置管理計劃。

2、文檔的質(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)鍵性程序或具有重復管理應(yīng)用性質(zhì)（如工資計算）的程序需要4級文檔。

配置管理

1、配置管理定義:

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

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

配置管理的概念

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

2、配置項可以分為基線配置項和非基線配置項兩類，例如，基線配置項可能包括所有的設(shè)計文檔和源程序等;非基線配置項可能包括項目的各類計劃和報告等。

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

4、配置項的狀態(tài)可分為“草稿”“正式”和“修改”三種。配置項剛建立時，其狀態(tài)為“草稿”。配置項通過評審后，其狀態(tài)變?yōu)椤罢健薄４撕笕舾呐渲庙棧瑒t其狀態(tài)變?yōu)椤靶薷摹薄．斉渲庙椥薷耐戤叢⒅匦峦ㄟ^評審時，其狀態(tài)又變?yōu)椤罢健薄Ｈ鐖D所示

5、配置項版本號

(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…。當附件的變動積累到一定程度時，配置項的Y值可適量增加，Y值增加一定程度時，X值將適量增加。當配置項升級幅度比較大時，才允許直接增大X值。

(3）處于“修改”狀態(tài)的配置項的版本號格式為X.YZ。配置項正在修改時，一般只增大Z值，X.Y值保持不變。當配置項修改完畢，狀態(tài)成為“正式”時，將Z值設(shè)置為0,增加X.Y值。參見上述規(guī)則(2)。

6、配置項版本管理

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

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

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

9、一個產(chǎn)品可以有多個基線，也可以只有一個基線。交付給外部顧客的基線一般稱為發(fā)行基線，內(nèi)部開發(fā)使用的基線一般稱為構(gòu)造基線。

10、配置庫存放配置項并記錄與配置項相關(guān)的所有信息，是配置管理的有力工具

11、配置庫可以分開發(fā)庫、受控庫、產(chǎn)品庫3種類型。

1）開發(fā)庫，也稱為動態(tài)庫、程序員庫或工作庫，用于保存開發(fā)人員當前正在開發(fā)的配置實體，如:新模塊、文檔、數(shù)據(jù)元素或進行修改的已有元素。動態(tài)中的配置項被置于版本管理之下。動態(tài)庫是開發(fā)人員的個人工作區(qū)，由開發(fā)人員自行控制。庫中的信息可能有較為頻繁的修改，只要開發(fā)庫的使用者認為有必要，無需對其進行配置控制，因為這通常不會影響到項目的其他部分。

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

3）產(chǎn)品庫,也稱為靜態(tài)庫、發(fā)行庫、軟件倉庫，包含已發(fā)布使用的各種基線的存檔，被置于完全的配置管理之下。在開發(fā)的信息系統(tǒng)產(chǎn)品完成系統(tǒng)測試之后，作為最終產(chǎn)品存入產(chǎn)品庫內(nèi)，等待交付用戶或現(xiàn)場安裝。

12、配置庫的建庫模式有兩種:按配置項類型建庫和按任務(wù)建庫。

(1）按配置項的類型分類建庫，適用于通用軟件的開發(fā)組織。使用這樣的庫結(jié)構(gòu)有利于對配置項的統(tǒng)一管理和控制，同時也能提高編譯和發(fā)布的效率。

2）按開發(fā)任務(wù)建立相應(yīng)的配置庫，適用于專業(yè)軟件的開發(fā)組織。

13、配置庫權(quán)限設(shè)置:配置管理員負責為每個項目成員分配對配置庫的操作權(quán)限。教材上的圖感覺有問題。

14、配置控制委員會

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

15、配置管理員

配置管理員(CMO)，負責在整個項目生命周期中進行配置管理活動，具體有:

(1）編寫配置管理計劃。

(2）建立和維護配置管理系統(tǒng)。

(3）建立和維護配置庫。

(4)配置項識別。

(5）建立和管理基線。

(6）版本管理和配置控制。

(7）配置狀態(tài)報告。

(8）配置審計。

(9)發(fā)布管理和交付。

16.配置管理系統(tǒng)

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

配置管理的目標和方針

軟件配置管理是在貫穿整個軟件生命周期中建立和維護項目產(chǎn)品的完整性。高級項目經(jīng)理應(yīng)確保以下配置管理目標得以實現(xiàn)。

(1)確保軟件配置管理計劃得以制訂，并經(jīng)過相關(guān)人員的評審和確認。

(2）應(yīng)該識別出要控制的項目產(chǎn)品有哪些，并且制定相關(guān)控制策略，以確保這些項目產(chǎn)品被合適的人員獲取。

(3）應(yīng)制定控制策略，以確保項目產(chǎn)品在受控制范圍內(nèi)更改。

(4)應(yīng)該采取適當?shù)墓ぞ吆头椒ǎ_保相關(guān)組別和個人能夠及時了解到軟件基線的狀態(tài)和內(nèi)容。

日常配置管理活動

1、配置管理計劃是對如何開展項目配置管理工作的規(guī)劃，是配置管理過程的基礎(chǔ)。配置控制委員會負責審批該計劃。配置管理計劃的主要內(nèi)容為:

(1）配置管理活動，覆蓋的主要活動包括配置標識、配置控制、配置狀態(tài)報告、配置審計、發(fā)布管理與交付。

(2）實施這些活動的規(guī)范和流程。

2、配置標識

配置標識也稱配置識別，包括為系統(tǒng)選擇配置項并在技術(shù)文檔中記錄配置項的功能和物理特征。配置標識是配置管理員的職能，基本步驟如下。

(1)識別需要受控的配置項。

(2）為每個配置項指定唯一性的標識號。

(3）定義每個配置項的重要特征。

(4)確定每個配置項的所有者及其責任

(5）確定配置項進入配置管理的時間和條件。

(6）建立和控制基線。

(7)維護文檔和組件的修訂與產(chǎn)品版本之間的關(guān)系。

3、配置控制

配置控制即配置項和基線的變更控制,包括下述任務(wù):標識和記錄變更申請，分析和評價變更，批準或否決申請，實現(xiàn)、驗證和發(fā)布已修改的配置項。

(1）變更評估

CCB負責組織對變更申請進行評估并確定以下內(nèi)容。

1)變更對項目的影響。

2)變更的內(nèi)容是否必要。

3）變更的范圍是否考慮周全。

4）變更的實施方案是否可行。

5）變更工作量估計是否合理。

CCB決定是否接受變更，并將決定通知相關(guān)人員。

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

配置狀態(tài)報告也稱配置狀態(tài)統(tǒng)計，其任務(wù)是有效地記錄和報告管理配置所需要的信息，目的是及時、準確地給出配置項的當前狀況,供相關(guān)人員了解，以加強配置管理工作。配置狀態(tài)報告應(yīng)該包含以下內(nèi)容。

(1)每個受控配置項的標識和狀態(tài)。一旦配置項被置于配置控制下，就應(yīng)該記錄和保存它的每個后繼進展的版本和狀態(tài)。

(2）每個變更申請的狀態(tài)和已批準的修改的實施狀態(tài)。

(3）每個基線的當前和過去版本的狀態(tài)以及各版本的比較。

(4)其他配置管理過程活動的記錄。

配置狀態(tài)報告應(yīng)著重反映當前基線配置項的狀態(tài)，以向管理者報告系統(tǒng)開發(fā)活動的進展情況。

配

置狀態(tài)報告應(yīng)定期進行，并盡量通過CASE工具自動生成，用數(shù)據(jù)庫中的客觀數(shù)據(jù)來真實地反映各配置項的情況

5、配置審計

配置審計也稱配置審核或配置評價，包括功能配置審計和物理配置審計，分別用以驗證當前配置項的一致性和完整性。配置審計的實施是為了確保項目配置管理的有效性，體現(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）配置項中是否包含了所有必需的項目。

6、發(fā)布管理和交付

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

(1）存儲。

(2）復制

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

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

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

項目管理 ProjectMan

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。