【正文】 ..........................................................................................................................................37 18 服務(wù)與維護 ...............................................................................................................................................38 4 1 軟件研發(fā)制度綜述 精簡 模型 “精簡模型”是 基于 CMMI 以及軟 件工程和項目管理知識而創(chuàng)作的 一種“軟件過程改進方法和規(guī)范”，它由眾多的過程規(guī)范和文檔模板組成。 精簡 模型的主要特征和優(yōu)點有： 5 一、直觀的過程模型 精簡 模型將項目管理、項目研發(fā)、機構(gòu)支撐所包含的工作劃分為相對獨立的三類過程，各個過程域之間的關(guān)系直觀明 了。用戶可以根據(jù)自己產(chǎn)品的特征，適當?shù)夭眉艋驍U充 精簡 的過程域，很容易制定出最適合于本產(chǎn)品的過程模型。杜絕不符合機構(gòu)最大利益的立項建議被采納，避免浪費機構(gòu)的資源、資金、時間等。 風險管理 在風 險產(chǎn)生危害之前識別它們，從而有計劃地消除或削弱風險。 系統(tǒng)設(shè)計 設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu)、用戶界面、數(shù)據(jù)庫、模塊等，從而在需求與代碼之間建立橋梁，指導(dǎo)開發(fā)人員去實現(xiàn)能滿足用戶需求的軟件產(chǎn) 品。 客戶驗收 客戶依據(jù)合同對產(chǎn)品進行審查和測試，確保產(chǎn)品滿足客戶需求。 質(zhì)量保證 提供一種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控“過程質(zhì)量”與“產(chǎn)品質(zhì)量”，從而實現(xiàn)持續(xù)地改進質(zhì)量。 圖 12 精簡模型 文檔結(jié)構(gòu) 項目管理過程域 主要規(guī)程 文檔模板 立項管理 立項建議 立項評審 項目籌備 《立項建議書》 《立項調(diào)查報告書》 《立項可行性分析報告》 《立項評審報告》 結(jié)項管理 結(jié)項管理 《結(jié)項申請書》 《結(jié)項評審報告》 項目規(guī)劃 制定項目計劃 審批項目計劃 項目計劃變更控制 《項目計劃》 《項目計劃變更控制報告》 項目監(jiān)控 項目計劃跟蹤 偏差控制 項目進展總結(jié) 《項目監(jiān)控數(shù)據(jù)表》 《項目偏差控制報告》 《項目進展報告》 風險管理 風險管理 《 風險檢查表》 《風險管理報告》 需求管理 需求確認 需求跟蹤 需求變更控制 《需求跟蹤報告》 《需求變更控制報告》 項目研發(fā)過程域 主要規(guī)程 文檔模板 需求開發(fā) 需求調(diào)查 需求分析 需求定義 《用戶需求說明書》 《產(chǎn)品需求規(guī)格說明書》 技術(shù)預(yù)研 技術(shù)預(yù)研 《技術(shù)預(yù)研計劃》 《技術(shù)預(yù)研報告》 過程改進政策 過程域 規(guī)程 文檔模板 6 系統(tǒng)設(shè)計 體系結(jié)構(gòu)設(shè)計 用戶界面設(shè)計 數(shù)據(jù)庫設(shè)計 模塊設(shè)計 《體系結(jié)構(gòu)設(shè)計報告》 《用戶界面設(shè)計報告》 《數(shù)據(jù)庫設(shè)計報告》 《模塊設(shè)計報告》 實現(xiàn)與測試 實現(xiàn)與測試 《實現(xiàn)與測試計劃》 《編程文檔》 系 統(tǒng)測試 系統(tǒng)測試 《系統(tǒng)測試計劃》 《測試用例》 《測試報告》 客戶驗收 客戶驗收 《客戶驗收計劃》 《客戶驗收報告》 技術(shù)評審 正式技術(shù)評審 非正式技術(shù)評審 《技術(shù)評審計劃》 《技術(shù)評審報告》 《技術(shù)評審檢查表》 機構(gòu)支撐過程域 規(guī)程與關(guān)鍵活動 文檔模板 質(zhì)量保證 制定質(zhì)量保證計劃 過程與產(chǎn)品質(zhì)量檢查 問題跟蹤與質(zhì)量改進 《質(zhì)量保證計劃》 《質(zhì)量保證檢查表》 《質(zhì)量保證報告》 《質(zhì)量問題跟蹤表》 配置管理 制定配置管理計劃 配置庫管理 版本控制 變更控制 《配置管理計劃》 《配置庫管理報告》 《 配置項變更控制報告》 培訓(xùn)管理 機構(gòu)培訓(xùn)管理 項目培訓(xùn)管理 《培訓(xùn)計劃》 《培訓(xùn)評估報告》 服務(wù)與維護 客戶服務(wù) 《客戶服務(wù)計劃》 《客戶服務(wù)報告》 產(chǎn)品維護 《產(chǎn)品維護計劃》 《產(chǎn)品維護報告》 表 12 精簡模型 規(guī)范細分 精簡模型 角色與職責表 精簡模型 的主要角色及其職責如表 13 所示（詳見各個過程域?qū)巧c職責的描述）。 （ 2）在機構(gòu)范圍內(nèi)推廣該規(guī)范（如培訓(xùn)、考核），評估機構(gòu)過程能力等。 （ 2）監(jiān)督項目經(jīng)理的工作，審批項目經(jīng)理的各種申請。 項目研發(fā) 過程 角色 需求分析員 調(diào)查、分析并定義需求，撰寫相應(yīng)的需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。 測試員 從事單元測試、集成測試和系統(tǒng) 測試，主要工作包括制定測試計劃、設(shè)計測試用例、執(zhí)行測試和撰寫測試報告。 （ 2）周期性的開展“過程與產(chǎn)品質(zhì)量檢查”。 產(chǎn)品維護人員 （ 1）糾錯性維護：及時解決用戶遇到的技術(shù)故障和消除產(chǎn)品中的缺陷。 立項評審委員會 由機構(gòu)領(lǐng)導(dǎo)、各級經(jīng)理、市場人員、技術(shù)專家、財務(wù)人員等組成，委員會按少數(shù)服從多數(shù)原則投票決定是否同意立項。該委員會由項目內(nèi)外的技術(shù)專家組成。 ? 機構(gòu)領(lǐng)導(dǎo)組建 SEPG 和 QAG，專門從事軟件過程改進工作。一般地， SEPG 成員和質(zhì)量保證員共占機構(gòu)總?cè)藬?shù)的 5%左右。 質(zhì)量管理有種基本措施：“質(zhì)量保證”、“技術(shù)評審”和“測試”。 如果時間允許的話，應(yīng)當盡可能多地對產(chǎn)品的重要工作成果進行技術(shù)評審。 一般地，產(chǎn)品開發(fā)過程中有四個測試階段：單元測試、集成測試、系統(tǒng)測試和驗收測試。如果有條件的話， 建議 9 機構(gòu)成立專門的測試小組從事單元測試、集成測試和系統(tǒng)測試工作。這種獨立性有助于質(zhì)量保證員客觀地檢查和監(jiān)控“過程以及產(chǎn)品的質(zhì)量”。對于 QAG 與項目之間出現(xiàn)的難以調(diào)和的爭議，由機構(gòu)領(lǐng)導(dǎo)處理。這項工作應(yīng)當在“項目規(guī)劃過程域”中完成，并在《項目計劃》中體現(xiàn)出來。如果必要的資金和資源已經(jīng)到位，那么項目經(jīng)理和核心成員即可組成一個項目規(guī)劃小組，著手 制定《項目計劃》，并按計劃執(zhí)行研發(fā)和管理工作。而下屬計劃書一般由項目成員制定，由項目經(jīng)理審批即可。 為持續(xù)過程改進提供有價值的數(shù)據(jù)。費用跟蹤表的參考格式如表 42 所示。工作成果跟蹤表的參考格式如表 44 所示。 基本信息 項目名稱 報告日期 項目編號 報告批次 第 N 份 項目經(jīng)理 項目所處階段 項目進展狀況 計劃 實際情況 任務(wù)與進度 工作成果 費用 人力資源 軟 硬件資源 問題與對策 表 46 項目 進展 報告 14 5 風險管理 風險管理（ Risk Management, RiskM）的目的是在風險產(chǎn)生危害之前識別它們，從而有計劃地消除或削弱風險。一種是被動態(tài)度，可比作“救火模式”。 ? 風險可能性：指風險發(fā)生的幾率。 中等 3 例如進度延誤低于 20%，或者費用超支低于 20%。 表 53 風險系數(shù)等級 15 風險嚴重性的等級劃分如表 51 所示，風險可能性的等級劃分如表 52 所示，風險系數(shù)的等級劃分如表 3 所示。 ? 風險跟蹤：跟蹤風險減緩 過程，記錄風險的狀態(tài)。風險管理過程域產(chǎn)生的主要文檔是 《風險管理報告》 。 當需求文檔通過正式的評審之后，開發(fā)方負責人（項目經(jīng)理）和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。 甲方負責人簽字 乙方負責人簽字 需求工程 需求開發(fā) 需求變更控制 需求管理 需求 確認 需求跟蹤 需求調(diào)查 需求分析 需求定義 19 評審結(jié)束 輸出 《需求評審報告》 ， 書面的需求承諾 需求評審報告摘要 需求文檔 輸入名稱，標識符，版本，作者，完成日期， … 需求評審報告 輸入名稱，標識符，評 審日期， … 評審結(jié)論 [ ] 工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。 項目經(jīng)理跟蹤需求。檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。矩陣單元之 間的可能存在“一對一”、“一對多”或“多對多”的關(guān)系。 ＃ 需求文檔 （版本，日期） 設(shè)計文檔 （版本，日期） 代碼 （版本，日期） 測試用例 （版本，日期） 1 標題或標識符，說明 標題或標識符，說明 代碼名稱，說明 測試用例名稱，說明 2 … … … … 表 63 簡單的需求跟蹤矩陣格式 需求變更控制 ? 修改“原需求文檔”中不正確的 內(nèi)容，產(chǎn)生新的需求文檔。 需求變更申請 申請變更的 需求文檔 輸入名稱，版本，日期等信息 變更的內(nèi)容 及其理由 評估需求變更將對 項目造成的影響 21 申請人簽字 變更申請的審批意見 項目經(jīng)理簽字 審批意見： 簽字，日期 客戶簽字 （合同項目） 審批意見： 簽字，日期 更改需求 文檔 變更后的 需求文檔 輸入名稱，版本，完成日期等信息 更改人簽字 重新評審需求文檔 需求評審小組簽字 評審意見： 簽字，日期 變更結(jié)束 項目經(jīng)理簽字 簽字 日期 ： 表 64 需求變更控制報告 22 7 結(jié)項管理 結(jié) 項管理（ Project Closing Management, PCM）是指在項目開發(fā)工作結(jié)束后，對項目的有形資產(chǎn)和無形資產(chǎn)進行清算；對項目進行綜合評估；總結(jié)經(jīng)驗教訓(xùn)等。后者原因有多種，歸根結(jié)底都是由于該項目不再符合機構(gòu)的最大利益。 有價值的 結(jié)項 管理至少包括三項內(nèi)容： ? 對項目的有形資產(chǎn)和無形資產(chǎn)進行清算，既要防止資產(chǎn)流失，又要及時地利用這些資產(chǎn)。 ? 總結(jié)經(jīng)驗教訓(xùn)，使整個機構(gòu)受益。 圖 81 需求開發(fā)與需求管理流程圖 需求開發(fā)可分為兩個階段：“用戶需求調(diào)查階段”和“產(chǎn)品需求定義階段”。 一、需求調(diào)查 需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生《用戶需求說明書》。系統(tǒng)設(shè)計人員將依據(jù)《產(chǎn)品需求規(guī)格說明書》開展系統(tǒng)設(shè)計工作。 一般說來，在設(shè)計或?qū)崿F(xiàn)階段遇到了技術(shù)障礙，才去攻克問題，其代價通常比較高。 ? 防止開發(fā)進程被技術(shù)障礙打斷，導(dǎo)致大量的相關(guān)工作被阻塞。 高層設(shè)計階段的重點是軟件系統(tǒng)的體系結(jié)構(gòu)設(shè)計。 項目經(jīng)理指定若干名開發(fā)人員從事體 系結(jié)構(gòu)設(shè)計（以下稱為體系結(jié)構(gòu)設(shè)計人員）。 如果可能的話，邀請用戶或美工人員協(xié)助設(shè)計用戶界面。 數(shù)據(jù)庫設(shè)計流程如圖 104 所示。 Step2. 數(shù)據(jù)庫設(shè)計 Step1. 設(shè)計 準備 邏輯設(shè)計 物理設(shè)計 安全性設(shè)計 優(yōu)化 Step3. 撰寫 文檔 Step4. 設(shè)計 評審 迭代 28 圖 105 模塊設(shè)計流程 《模塊設(shè)計報告》 11 實現(xiàn)與測試 實現(xiàn)與測試（ Implementation and Test, IT）的目的是依據(jù)系統(tǒng)設(shè)計文檔，編寫并測試整個系統(tǒng)的代碼。上述任何活動中發(fā)現(xiàn)的缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應(yīng)當及時消除缺陷（改錯）。對于小型項目，項目經(jīng)理可以兼任開發(fā)組長 。開發(fā)組長由項目經(jīng)理指定。由于系統(tǒng)測試的目的是驗證最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計，所以當產(chǎn)品需求和系統(tǒng)設(shè)計文檔完成之后，系統(tǒng)測試小組就可以提前開始制定測試計劃和設(shè)計測試用例，而不必等到“實現(xiàn)與測試”階段結(jié)束。系統(tǒng)測試小組的成員主要來源于： ? 機構(gòu)獨立的測試小組（如果存在的話）。 系統(tǒng)測試小組應(yīng)當根據(jù)項目的特征確定測試內(nèi)容。 ? 健壯性測試。即測試軟件系統(tǒng)處理事務(wù)的速度，一是為了檢驗性能是否符合需求，二是為了得到某些性能數(shù)據(jù)供人們參考（例如用于宣傳）。是指測試軟件系統(tǒng)防止非法入侵的能力。 項目經(jīng)理組建系統(tǒng)測試小組，并指定一名成員任測試組長。 制定測試計劃 設(shè)計測試用例 執(zhí)行系統(tǒng)測試 缺陷管理與改錯 審批 審批 迭代 31 《系統(tǒng)測試計劃》 《測試用例》 《測試報告》 13 客戶驗收 客戶驗收（ C