【正文】 頁數） 復用或自動生成的成果規(guī)模 （代碼行、類、文檔頁數） 工作成果 1 工作成果 2 … 總和 表 44 工作成果及其規(guī)模跟蹤表 控制偏差 對比“項目實際進展”和“項目計劃”，分析偏差，如果發(fā)現項目實際進 展顯著偏離計劃，則及時采取糾正措施。 項目經理周期性地總結項目進展情況，撰寫《項目進展報告》并通報給機構領導和所有項目成員。 所有可能危害項目的因素都稱為風險。人們對待風險有兩種態(tài)度。另一種是主動態(tài)度，可比作“防火模式”。 為了便于量化管理，我們給風險定義 3 個參數： ? 風險嚴重性 ：指風險對項目造成的危害程度。 ? 風險系數：是風險嚴重性和風險可能性的乘積。 比較高 4 例如進度延誤 20%~30%，或者費用超支 20%~30%。 比較低 2 例如進度延誤低于 10%，或者費用超支低于 10%。 表 51 風險嚴重性等級 參數 等 級 值 描述 風險 可能性 很高 5 風險發(fā)生的幾率為 ~ 比較高 4 風險發(fā)生的幾率為 ~ 中等 3 風險發(fā)生的幾率為 ~ 比較低 2 風險發(fā)生的幾率為 ~ 很低 1 風險發(fā)生的幾率為 ~ 表 52 風險可能性等級 風險 系數 風險可能性 很高 5 比較高 4 中等 3 比較低 2 很低 1 風險 嚴重性 很高 5 25 20 15 10 5 比較高 4 20 16 12 8 4 中等 3 15 12 9 6 3 比較低 2 10 8 6 4 2 很低 1 5 4 3 2 1 本表灰色部分的風險系數值為 10~25，應當優(yōu)先處理。 風險管理有 4 個主要活動： ? 風險識別：根據風險檢查表，識別出本項目的風險。 ? 風險減緩：對于風險系數超過“容許值”的每一個風險，都應當采取減緩措施。 圖 51 風險管理示意圖 在項目的生命周期內，上述 4 個活動將被循環(huán)執(zhí)行，如圖 51 所示。 常用的 《 風險檢查表 》 ，使用者應根據實際情況進行適當的刪減或補充。 商業(yè)風險 風險類型 檢查項 政治 法律 市場 政府或者其他機構對本項目的開發(fā)有限制嗎？ 有不可預測的市場動蕩嗎？ 有不利于我方的官司要打嗎？ 本產品銷售后在使用過程中可能導致發(fā)生重大的損失或傷亡事故嗎？ 競爭對手有不正當的競爭行為嗎？ 本產品銷售后在使用過程中可能導致發(fā)生重大的損失或傷亡事故嗎？ 是否在開發(fā)很少有人真正需要卻自以為很好的產品？ 是否在開發(fā)可能虧本的產品？ 客戶 客戶的需求是否含糊不清？ 客戶是否反反復復地改動需求？ 客戶指定的需求和交付期限在客觀上可行嗎？ 客戶對產品的健壯性、可靠性、性能等質量因素有非常過分的要求嗎？ 客戶的合作態(tài)度友善嗎？ 與客戶簽的合同公正嗎？雙方互利嗎？ 風險識別 風險分析 風險減緩 風險跟蹤 16 客戶的信譽好嗎？例如按客戶的需求開發(fā)了產品，但是客戶可能不購買。 需求管理過程域的三個主要規(guī)程： ? 需求確認 ? 需求跟蹤 ? 需求變更控制 圖 61 需求工程結構圖 需求確認 項目經理邀請同行專家和用戶（包括客戶和最終用戶）一起評審需求文檔， 盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。示例如下： 本需求文檔建立在雙方對需求的共同理解基礎之上，我同意后續(xù)的開發(fā)工作根據該需求文檔開展。我明白需求的變更將導致雙方重新協(xié)商成本、資源和進度等。 [√ ] 工作成果基本合格，需要作少量的修改，之后通過審核即可。 評審意見 評審小組成員 輸入評審小組成員 表 61 需求評審報告 需求承諾 需求文檔 輸入名稱，標識符，版本，作者，完成日期 客戶承諾 承諾 … 簽字，日期 項目經理承諾 承諾 … 簽字，日期 表 62 需求承諾 需求跟蹤 將系統(tǒng)設計、編程、測試等階段的工作成果與需求文檔進行比較，建立與維護“需求文檔－設計文檔－代碼－測試用例”之間的一致性，確保產品依據需求文檔進行開發(fā)。 建立與維護需求跟蹤矩陣： 20 ? 正向跟蹤。 ? 逆向跟蹤。 ? 正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對應關系。由于對應關系比較復雜，最好在表格中加必要的文字解釋。 ? 當需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。 ? 控制需求文檔的變更，防止發(fā)生混亂。 開發(fā)方負責人（項目經理）和客戶共同控制需求變更。 立項管理 與結項 管理是前后呼應的兩個過程域，使得項目管理過程“有始有終”。前者是指項目按預定計劃結束。例如有些項目因不適應市場而被中途淘汰，有些項目在執(zhí)行過程中大大因偏離計劃（如進度延誤、費用超支）而被取消。 國內很多項目普遍存在“虎頭蛇尾”的現象， 結項 管理 畸 變成了“走過場，吃頓飯”，這是非常有害的。 ? 對 項目進行綜合評估。該評估報告可以作為考核項目人員業(yè)績的重要依據。 圖 71 結 項管理流程圖 結項管理的流程如圖 71 所示，產生的主要文檔有： 《結項申請書》 《結項評審報告》 8 需求開發(fā) 需求開發(fā)（ Requirement Development, RD）的目的是通過調查與分析，獲取用 戶需求并定義產品需求。需求工程結構圖如圖 61 所示，需求開發(fā)和需求管理的流程如圖 81 所示。而“需求分析”則貫穿于上述兩個階段。我們把從事需求 開發(fā)工作的人員稱為需求分析員（也叫系統(tǒng)分析員），避免 與其它 開發(fā)人員混淆。 二、需求分析 需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等。 三、需求定義 需求定義的目的是根據需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生《產品需求規(guī)格說明書》。 需求開發(fā) 過程 域 產生的主要文檔有： 需求分析 用戶需求說明書 產品需求規(guī)格說明書 用戶需求調查 輸出 輸出 產品需求定義 需求 變更 控制 需求確認 需求跟蹤 需求 開發(fā) 過程域 需求 管理 過程域 24 《用戶需求說明書 》 《產品需求規(guī)格說 明書》 9 技術預研 技術預研（ Technical PreResearch, TPR）是指在立項之后到開發(fā)工作完成之前的時間內，對 項目將采用的關鍵技術 提前學習和研究，以便盡可能早地發(fā)現并解決開發(fā)過程中將會遇到的技術障礙。如果一點技術障礙都沒有遇到，要么是開發(fā)人員的技術水平實在太高了，要么是項目的技術含量實在 太低了，這類情況比較少見。因為其他人的工作可能會被阻塞，已經投入的不少資源將被閑置。 所以開展技術預研工作至少有兩大好處： ? 幫助開發(fā)人員更好地進行需求開發(fā)、系統(tǒng)設計和程序設計。 技術預研的流程 如圖 91 所示。 本規(guī)范闡述了系統(tǒng)設計過程域的四個主要規(guī)程： ? 體系結構設計 ? 用戶界面設計 ? 數據庫設計 ? 模塊設計 系統(tǒng)設計過程域分為兩個階段：高層設計階段 和詳細設計階段。詳細設計階段的重點是用戶界面設計、數據庫設計和模塊設計，如圖 101 所示。通過系統(tǒng)分解，確定子系統(tǒng)的功能和子系統(tǒng)之間的關系，以及模塊的功能和模塊之間的關系，產生《體系結構設計報告》。 體系結構設計流程如圖 102 所示。 制作用戶界面的資源如圖像、圖標或者界面專用組件等 項目經理指定若干名開發(fā)人員從事用戶界面設計（以下稱為界面設計人員）。 用戶界面設計流程如圖 103 所示。 項目經理指定若干名開發(fā)人員從事數據庫設計（以下稱為數據庫設計人員）。 圖 104 數據庫設計流程 《數據庫設計報告 》 模塊設計 設計軟件所有模塊的主要接口與屬性、數據結構和算法，產生《模塊設計報告》。 模塊設計流程如圖 105 所示。在本規(guī)范中，實現與測試是“編程、代碼審查、單元測試、集成測試、缺陷管理與改錯”的綜合表述。一般地，編程、代碼審查、單元測試、集成測試大致存在先后順序關系，也可以并行、迭代地開展。 圖 111 實現與測試流程圖 由于實現與測試是工作量最大、時間最長、產生 工 作成果（代碼與文檔）最多的一個項目研發(fā)過程域，所以需要作充分的準備工作。一個項目可能有一個或者多個開發(fā)小 Step2. 模塊設計 Step1. 設計 準備 接口與屬性設計 數據結構 與算法設計 Step3. 撰寫 文檔 Step4. 設計 評審 迭代 編程 代碼審查 單元測試 集成測試 模塊 軟件系統(tǒng) 準備 缺陷管理與改錯 29 組。 特別要注意的是，開發(fā)人員應當對自己的代碼進行審查和測試（這是 份內 的工作），但是不能作為該代碼已經通過審查和測試的依據。 實現與測試過程域產生的主要文檔有： ? 《實現與測試計劃》 ? 《編程文檔》 ? 《代碼審查報告》 ? 《測試用例》 ? 《測試報告》 ? 《缺陷管理報告》（由缺陷管理工具自動生成） 一個項目可能有多個開發(fā)小組，視項目規(guī)模而定。 開發(fā)組長管理編程、代碼審查、單元測試、集成測試、缺陷管理與改錯等活動。 系統(tǒng)測試流程如圖 121 所示。這樣可以提高系統(tǒng)測試的效率。 30 圖 121 系統(tǒng)測試流程圖 項目經理設法組建富有成效的系統(tǒng)測試小組。 ? 邀請 其它 項目的開發(fā)人員參與系統(tǒng)測試。 ? 機構的質量保證人員。一般地，系統(tǒng)測試的主要內容包括： ? 功能測試。由于正確性是軟件最重 要的質量因素，所以功能測試必不可少。即測試軟件系統(tǒng)在異常情況下能否正常運行的能力。 ? 性能測試。 ? 用戶界面測試。 ? 安全性（ security）測試。“安全”是相對而言的，一般地，如果黑客為非法入侵花費的代價（考慮時間、費用、危險等因素）高于得到的好處，那么這樣的系統(tǒng)可 以認為是安全的。 系統(tǒng)測試過程域產生的主要文檔有： ? 《系統(tǒng)測試計劃》 ? 《系統(tǒng)測試用例》 ? 《系統(tǒng)測試報告》 ? 《缺陷管理報告》 對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產品需求并且遵循系統(tǒng)設計。 系統(tǒng)測試小組各成員共同制定測試計劃、設計測試用例、執(zhí)行測試，并撰寫相應的文檔。 開發(fā)人員及時消除測試人員發(fā)現的缺陷。 客戶對產品的驗收主要有兩種方式： ? 成果審查。確保這些成果是完整的并且是正確的。驗收人員對待交付的產品進行全面的測試，確保產品功能、質量符合需求。兩者主要區(qū)別在于執(zhí)行 人員不同。客戶驗收流程如圖 131所示。 《客戶驗收計劃》 《客戶驗收報告》 驗收準備 問題處理 成果審查與驗收測試 交付與簽字 32 14 技術評審 技術評審（ Technical Review, TR）的目的是盡早地發(fā)現工作成果中的缺陷， 并幫助開發(fā)人員及時消除缺陷，從而有效地提高產品的質量。技術評審的主要好處有： ? 通過消除工作成果的缺陷而提高產品的質量。 ? 開發(fā)人員能夠及時地得到同行專家的幫助和指導，無疑會加深對工作成果的理解，更好地預防缺陷，一定程度上提高了開發(fā)生產率。 技術評審有兩種基本類型： ? 正規(guī)技術評審（ FTR）。 ? 非正規(guī)技術評審（ ITR）。 理論上講，為了確保產品的質量，產品的所有工作成果都應當接受技術評審。技術評審方式也視工作成果的重要性和復雜性而定。 圖 141 技術評審過程域示意圖 技術評審的注意事項： ? 評審人員的職責是發(fā)現工作成果中的缺陷，并幫助開發(fā)人員給出消除缺陷的辦法，而不是替開發(fā)人員消除缺陷。 ? 在會議評審期間要限制過多的爭論，以免浪費他人的時間。 配置管理是對工作成果的一種有效保護。如果把所有文件一股腦地塞進計算機里，那么使用起來肯定很麻煩。 凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項（ Configuration Item, CI），配置項主要有兩大類： （ 1）屬于產品組成部分的工作成果，例如需求文檔、設計文檔、源代碼、測試用例 等 。這些文檔雖然不是產品的組成部分，但 是值得保存。所有配置項都 被保存在配置庫里，確保不會混淆、丟失。 34 基線（ Baseline）由一組配置項組成，這些配置項構成了一個相對穩(wěn)定的邏輯實體?；€通常對應于開發(fā)過程中的里程碑（ Milestone），一個產品可以有多個基線，也可以只有一個基線。通常將交付給客戶的基線稱為一個“ Release”，為內部開發(fā)用的基線則稱為一個“ Build”