信息系统项目文档及其管理
信息系統項目文檔及其管理
- 信息系統項目相關信息（文檔)
- 配置管理
- 配置管理的概念
- 配置管理的目標和方針
- 日常配置管理活動
信息系統項目相關信息（文檔)
1、軟件文檔一般分為三類:開發文檔、產品文檔、管理文檔。
(1）開發文檔描述開發過程本身，基本的開發文檔包括:
1）可行性研究報告和項目任務書。
2）需求規格說明。
3）功能規格說明。
4)設計規格說明，包括程序和數據規格說明。
5）開發計劃。
6）軟件集成和測試計劃
7）質量保證計劃。
8）安全和測試信息。
(2）產品文檔描述開發過程的產物，基本的產品文檔包括:
1）培訓手冊。
2)參考手冊和用戶指南
3）軟件支持手冊。
4）產品手冊和信息廣告。
(3）管理文檔記錄項目管理的信息,例如:
1)開發過程的每個階段的進度和進度變更的記錄。
2）軟件變更情況的記錄。
3）開發團隊的職責定義。
4）項目計劃、項目階段報告。
5）配置管理計劃。
2、文檔的質量可以分為四級:
1）最低限度文檔(1級文檔)，
適合開發工作量低于一個人月的開發者自用程序。該文檔應包含程序清單、開發記錄、測試數據和程序簡介。
(2)內部文檔（2級文檔)，
可用于沒有與其他用戶共享資源的專用程序。除1級文檔提供的信息外，2級文檔還包括程序清單內足夠的注釋以幫助用戶安裝和使用程序。
(3)工作文檔（3級文檔)，
適合于由同一單位內若干人聯合開發的程序，或可被其他單位使用的程序。
(4)正式文檔(4級文檔)，
適合那些要正式發行供普遍使用的軟件產品。關鍵性程序或具有重復管理應用性質（如工資計算）的程序需要4級文檔。
配置管理
1、配置管理定義:
“應用技術的和管理的指導和監控方法以標識和說明配置項的功能和物理特征，控制這些特征的變更，記錄和報告變更處理和實現狀態并驗證與規定的需求的遵循性。”
2、配置管理包括6個主要活動:制訂配置管理計劃、配置標識、配置控制、配置狀態報告、配置審計、發布管理和交付。
配置管理的概念
1、典型配置項包括項目計劃書、需求文檔、設計文檔、源代碼、可執行代碼、測試用例、運行軟件所需的各種數據，它們經評審和檢查通過后進入配置管理。
2、配置項可以分為基線配置項和非基線配置項兩類，例如，基線配置項可能包括所有的設計文檔和源程序等;非基線配置項可能包括項目的各類計劃和報告等。
3、所有配置項的操作權限應由CMO(配置管理員）嚴格管理，基本原則是:基線配置項向開發人員開放讀取的權限;非基線配置項向PM、CCB及相關人員開放。
4、配置項的狀態可分為“草稿”“正式”和“修改”三種。配置項剛建立時，其狀態為“草稿”。配置項通過評審后，其狀態變為“正式”。此后若更改配置項，則其狀態變為“修改”。當配置項修改完畢并重新通過評審時，其狀態又變為“正式”。如圖所示
5、配置項版本號
(1）處于“草稿”狀態的配置項的版本號格式為0.YZ,YZ的數字范圍為01～99。隨著草稿的修正，YZ的取值應遞增。YZ的初值和增幅由用戶自己把握。
(2）處于“正式”狀態的配置項的版本號格式為X.Y，X為主版本號，取值范圍為1～9。Y為次版本號，取值范圍為0～9。配置項第一次成為“正式”文件時，版本號為1.0。如果配置項升級幅度比較小，可以將變動部分制作成配置項的附件，附件版本依次為1.0，1.1…。當附件的變動積累到一定程度時，配置項的Y值可適量增加，Y值增加一定程度時，X值將適量增加。當配置項升級幅度比較大時，才允許直接增大X值。
(3）處于“修改”狀態的配置項的版本號格式為X.YZ。配置項正在修改時，一般只增大Z值，X.Y值保持不變。當配置項修改完畢，狀態成為“正式”時，將Z值設置為0,增加X.Y值。參見上述規則(2)。
6、配置項版本管理
在項目開發過程中，絕大部分的配置項都要經過多次的修改才能最終確定下來。對配置項的任何修改都將產生新的版本。由于我們不能保證新版本一定比舊版本“好”，所以不能拋棄舊版本。版本管理的目的是按照一定的規則保存配置項的所有版本，避免發生版本丟失或混淆等現象，并且可以快速準確地查找到配置項的任何版本。
7、配置基線（常簡稱為基線）由一組配置項組成，這些配置項構成一個相對穩定的邏輯實體。基線中的配置項被“凍結”了，不能再被任何人隨意修改。對基線的變更必須遵循正式的變更控制程序。
8、一組擁有唯一標識號的需求、設計、源代碼文卷以及相應的可執行代碼、構造文卷和用戶文檔構成一條基線。產品的一個測試版本（可能包括需求分析說明書、概要設計說明書、詳細設計說明書、已編譯的可執行代碼、測試大綱、測試用例、使用手冊等）是基線的一個例子。
9、一個產品可以有多個基線，也可以只有一個基線。交付給外部顧客的基線一般稱為發行基線，內部開發使用的基線一般稱為構造基線。
10、配置庫存放配置項并記錄與配置項相關的所有信息，是配置管理的有力工具
11、配置庫可以分開發庫、受控庫、產品庫3種類型。
1）開發庫，也稱為動態庫、程序員庫或工作庫，用于保存開發人員當前正在開發的配置實體，如:新模塊、文檔、數據元素或進行修改的已有元素。動態中的配置項被置于版本管理之下。動態庫是開發人員的個人工作區，由開發人員自行控制。庫中的信息可能有較為頻繁的修改，只要開發庫的使用者認為有必要，無需對其進行配置控制，因為這通常不會影響到項目的其他部分。
2）受控庫,也稱為主庫，包含當前的基線加上對基線的變更。受控庫中的配置項被置于完全的配置管理之下。在信息系統開發的某個階段工作結束時，將當前的工作產品存入受控庫。
3）產品庫,也稱為靜態庫、發行庫、軟件倉庫，包含已發布使用的各種基線的存檔，被置于完全的配置管理之下。在開發的信息系統產品完成系統測試之后，作為最終產品存入產品庫內，等待交付用戶或現場安裝。
12、配置庫的建庫模式有兩種:按配置項類型建庫和按任務建庫。
(1）按配置項的類型分類建庫，適用于通用軟件的開發組織。使用這樣的庫結構有利于對配置項的統一管理和控制，同時也能提高編譯和發布的效率。
2）按開發任務建立相應的配置庫，適用于專業軟件的開發組織。
13、配置庫權限設置:配置管理員負責為每個項目成員分配對配置庫的操作權限。教材上的圖感覺有問題。
14、配置控制委員會
配置控制委員會(CCB），負責對配置變更做出評估、審批以及監督巳批準變更的實施。CCB其成員可以包括項目經理、用戶代表、產品經理、開發工程師、測試工程師、質量控制人員、配置管理員等。CCB不必是常設機構，完全可以根據工作的需要組成，例如按變更內容和變更請求的不同，組成不同的CCB。小的項目CCB可以只有一個人，甚至只是兼職人員。
通常，CCB不只是控制配置變更，而是負有更多的配置管理任務，例如:配置管理計劃審批、基線設立審批、產品發布審批等。
15、配置管理員
配置管理員(CMO)，負責在整個項目生命周期中進行配置管理活動，具體有:
(1）編寫配置管理計劃。
(2）建立和維護配置管理系統。
(3）建立和維護配置庫。
(4)配置項識別。
(5）建立和管理基線。
(6）版本管理和配置控制。
(7）配置狀態報告。
(8）配置審計。
(9)發布管理和交付。
16.配置管理系統
配置管理系統是用來進行配置管理的軟件系統，其目的是通過確定配置管理細則和提供規范的配置管理軟件，加強信息系統開發過程的質量控制，增強信息系統開發過程的可控性，確保配置項(包括各種文檔、數據和程序）的完備、清晰、一致和可追蹤性，以及配置項狀態的可控制性。
配置管理的目標和方針
軟件配置管理是在貫穿整個軟件生命周期中建立和維護項目產品的完整性。高級項目經理應確保以下配置管理目標得以實現。
(1)確保軟件配置管理計劃得以制訂，并經過相關人員的評審和確認。
(2）應該識別出要控制的項目產品有哪些，并且制定相關控制策略，以確保這些項目產品被合適的人員獲取。
(3）應制定控制策略，以確保項目產品在受控制范圍內更改。
(4)應該采取適當的工具和方法，確保相關組別和個人能夠及時了解到軟件基線的狀態和內容。
日常配置管理活動
1、配置管理計劃是對如何開展項目配置管理工作的規劃，是配置管理過程的基礎。配置控制委員會負責審批該計劃。配置管理計劃的主要內容為:
(1）配置管理活動，覆蓋的主要活動包括配置標識、配置控制、配置狀態報告、配置審計、發布管理與交付。
(2）實施這些活動的規范和流程。
2、配置標識
配置標識也稱配置識別，包括為系統選擇配置項并在技術文檔中記錄配置項的功能和物理特征。配置標識是配置管理員的職能，基本步驟如下。
(1)識別需要受控的配置項。
(2）為每個配置項指定唯一性的標識號。
(3）定義每個配置項的重要特征。
(4)確定每個配置項的所有者及其責任
(5）確定配置項進入配置管理的時間和條件。
(6）建立和控制基線。
(7)維護文檔和組件的修訂與產品版本之間的關系。
3、配置控制
配置控制即配置項和基線的變更控制,包括下述任務:標識和記錄變更申請，分析和評價變更，批準或否決申請，實現、驗證和發布已修改的配置項。
(1）變更評估
CCB負責組織對變更申請進行評估并確定以下內容。
1)變更對項目的影響。
2)變更的內容是否必要。
3）變更的范圍是否考慮周全。
4）變更的實施方案是否可行。
5）變更工作量估計是否合理。
CCB決定是否接受變更，并將決定通知相關人員。
4、配置狀態報告
配置狀態報告也稱配置狀態統計，其任務是有效地記錄和報告管理配置所需要的信息，目的是及時、準確地給出配置項的當前狀況,供相關人員了解，以加強配置管理工作。配置狀態報告應該包含以下內容。
(1)每個受控配置項的標識和狀態。一旦配置項被置于配置控制下，就應該記錄和保存它的每個后繼進展的版本和狀態。
(2）每個變更申請的狀態和已批準的修改的實施狀態。
(3）每個基線的當前和過去版本的狀態以及各版本的比較。
(4)其他配置管理過程活動的記錄。
配置狀態報告應著重反映當前基線配置項的狀態，以向管理者報告系統開發活動的進展情況。
配
置狀態報告應定期進行，并盡量通過CASE工具自動生成，用數據庫中的客觀數據來真實地反映各配置項的情況
5、配置審計
配置審計也稱配置審核或配置評價，包括功能配置審計和物理配置審計，分別用以驗證當前配置項的一致性和完整性。配置審計的實施是為了確保項目配置管理的有效性，體現了配置管理的最根本要求—不允許出現任何混亂現象，例如:
(1）防止向用戶提交不適合的產品，如交付了用戶手冊的不正確版本。
(2）發現不完善的實現，如開發出不符合初始規格說明或未按變更請求實施變更。
(3）找出各配置項間不匹配或不相容的現象。
(4）確認配置項已在所要求的質量控制審核之后納入基線并入庫保存。
(5）確認記錄和文檔保持著可追溯性。
1)功能配置審計
功能配置審計是審計配置項的一致性（配置項的實際功效是否與其需求一致）,具體驗證以下幾個方面。
(1）配置項的開發已圓滿完成。
(2）配置項已達到.配置標識中規定的性能和功能特征。
(3）配置項的操作和支持文檔巳完成并且是符合要求的。
2)物理配置審計
物理配置審計是審計配置項的完整性（配置項的物理存在是否與預期一致），具體驗證如下幾個方面。
(1）要交付的配置項是否存在。
(2）配置項中是否包含了所有必需的項目。
6、發布管理和交付
發布管理和交付活動的主要任務是:有效控制軟件產品和文檔的發行和交付，在軟件產品的生存期內妥善保存代碼和文檔的母拷貝。
(1）存儲。
(2）復制
(3)打包。應確保按批準的規程制備交付的介質。應在需方容易辨認的地方清楚標出發布標識。
(4)交付。供方應按合同中的規定交付產品或服務。
(5）重建。應能重建軟件環境，以確保發布的配置項在所保留的先前版本要求的未來一段時間里是可重新配置的。
總結
以上是生活随笔為你收集整理的信息系统项目文档及其管理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 信息系统项目管理师之风险管理
- 下一篇： 信息系统沟通管理