【正文】 統(tǒng)設(shè)計過程域產(chǎn)生的主要文檔有： ? 《體系結(jié)構(gòu)設(shè)計報告》 ? 《用戶界面設(shè)計報告》 ? 《數(shù)據(jù)庫設(shè)計報告》 ? 《模塊設(shè)計報告》 體系結(jié)構(gòu)設(shè)計 分析與設(shè)計軟件的體系結(jié)構(gòu)。 圖 103 體系結(jié)構(gòu)設(shè)計流程 《用戶界面設(shè)計》 Step1. 設(shè)計 準備 Step5. 撰寫 文檔 Step6. 設(shè)計 評審 Step2. 確定 約束 因素 Step3. 確定 設(shè)計 策略 Step4. 系統(tǒng) 分解 設(shè)計 Step2. 界面設(shè)計 Step1. 設(shè)計 準備 原型創(chuàng)作 原型評估 細化 Step3. 撰寫 文檔 Step4. 設(shè)計 評審 迭代 27 數(shù)據(jù)庫設(shè)計 設(shè)計軟件的數(shù)據(jù)庫，產(chǎn)生《數(shù)據(jù)庫設(shè)計報告》。 實現(xiàn)與測試的 流程如圖 111 所示。所以開發(fā)人員還要互相審查和測試同伴的代碼。 系統(tǒng)測試過程中發(fā)現(xiàn)的 所有缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應當及時消除缺陷（改錯）。即測試軟件系統(tǒng)的功能是否正確，其依據(jù)是需求文檔，如《產(chǎn)品需求規(guī)格說明書》。重點是測試軟件系統(tǒng)的易用性和視覺效果等。測試組長管理上述事務。 驗收測試的內(nèi)容、方法與系統(tǒng)測試幾乎是相同的。 ? 越早消除缺陷就越能降低開發(fā)成本?，F(xiàn)實中，為了節(jié)約時間，允許人們有選擇地對工作成果進行技術(shù)評審。 本規(guī)范闡述了配置管理過程域的四個主要規(guī)程： ? 制定配置管理計劃 ? 配置庫管理 ? 配置項版本控制 ? 配置項變更控制 項目研發(fā)和管理過程中會產(chǎn)生許許多多的工作成果，例如文檔、程序和數(shù)據(jù)等，它們都應當被保存起來，以便查閱和修改。配置項及其歷史記錄反映了軟件的演化過程。 所有的項目成員都要使用。 每個配置項的主要屬性有 ：名稱、標識符、文件狀態(tài)、版本、作者、日期等。 技術(shù)評審過程域產(chǎn)生的主要文檔有： ? 《技術(shù)評審計劃》 ? 《技術(shù)評審通知》 ? 《技術(shù)評審報告》 ? 《技術(shù)評審檢查表》 《技術(shù)評審計劃》 《技術(shù)評審通知》 《技術(shù)評審報告》 《技術(shù)評審檢查表 》 15 配置管理 配置管理（ Configuration Management, CM）的目的是通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件，來保證所有配置項的完整性和可跟蹤性。 ITR 的形式比較靈活，通常在同伴之間開展，不必舉行評審會議，評審人員比較少。 本規(guī)范闡述了技術(shù)評審過程域的三個主要規(guī)程： ? 制定技術(shù)評審計劃 ? 正式技術(shù)評審 ? 非正式技術(shù)評審 技術(shù)評審能夠在任何開發(fā)階段執(zhí)行，它可以比測試更早地發(fā)現(xiàn)并消除工作成果中的缺陷。 ? 驗收測試。 項目經(jīng)理組建系統(tǒng)測試小組，并指定一名成員任測試組長。即測試軟件系統(tǒng)處理事務的速度，一是為了檢驗性能是否符合需求，二是為了得到某些性能數(shù)據(jù)供人們參考（例如用于宣傳）。 系統(tǒng)測試小組應當根據(jù)項目的特征確定測試內(nèi)容。由于系統(tǒng)測試的目的是驗證最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計，所以當產(chǎn)品需求和系統(tǒng)設(shè)計文檔完成之后，系統(tǒng)測試小組就可以提前開始制定測試計劃和設(shè)計測試用例，而不必等到“實現(xiàn)與測試”階段結(jié)束。對于小型項目，項目經(jīng)理可以兼任開發(fā)組長 。 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)的代碼。 如果可能的話，邀請用戶或美工人員協(xié)助設(shè)計用戶界面。 高層設(shè)計階段的重點是軟件系統(tǒng)的體系結(jié)構(gòu)設(shè)計。 一般說來，在設(shè)計或?qū)崿F(xiàn)階段遇到了技術(shù)障礙，才去攻克問題，其代價通常比較高。 一、需求調(diào)查 需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生《用戶需求說明書》。 ? 總結(jié)經(jīng)驗教訓，使整個機構(gòu)受益。后者原因有多種，歸根結(jié)底都是由于該項目不再符合機構(gòu)的最大利益。 ＃ 需求文檔 （版本，日期） 設(shè)計文檔 （版本，日期） 代碼 （版本，日期） 測試用例 （版本，日期） 1 標題或標識符，說明 標題或標識符，說明 代碼名稱，說明 測試用例名稱，說明 2 … … … … 表 63 簡單的需求跟蹤矩陣格式 需求變更控制 ? 修改“原需求文檔”中不正確的 內(nèi)容，產(chǎn)生新的需求文檔。檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。 甲方負責人簽字 乙方負責人簽字 需求工程 需求開發(fā) 需求變更控制 需求管理 需求 確認 需求跟蹤 需求調(diào)查 需求分析 需求定義 19 評審結(jié)束 輸出 《需求評審報告》 ， 書面的需求承諾 需求評審報告摘要 需求文檔 輸入名稱，標識符，版本，作者，完成日期， … 需求評審報告 輸入名稱，標識符，評 審日期， … 評審結(jié)論 [ ] 工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。風險管理過程域產(chǎn)生的主要文檔是 《風險管理報告》 。 表 53 風險系數(shù)等級 15 風險嚴重性的等級劃分如表 51 所示，風險可能性的等級劃分如表 52 所示，風險系數(shù)的等級劃分如表 3 所示。 ? 風險可能性：指風險發(fā)生的幾率。 基本信息 項目名稱 報告日期 項目編號 報告批次 第 N 份 項目經(jīng)理 項目所處階段 項目進展狀況 計劃 實際情況 任務與進度 工作成果 費用 人力資源 軟 硬件資源 問題與對策 表 46 項目 進展 報告 14 5 風險管理 風險管理（ Risk Management, RiskM）的目的是在風險產(chǎn)生危害之前識別它們，從而有計劃地消除或削弱風險。費用跟蹤表的參考格式如表 42 所示。而下屬計劃書一般由項目成員制定，由項目經(jīng)理審批即可。這項工作應當在“項目規(guī)劃過程域”中完成，并在《項目計劃》中體現(xiàn)出來。這種獨立性有助于質(zhì)量保證員客觀地檢查和監(jiān)控“過程以及產(chǎn)品的質(zhì)量”。 一般地，產(chǎn)品開發(fā)過程中有四個測試階段：單元測試、集成測試、系統(tǒng)測試和驗收測試。 質(zhì)量管理有種基本措施：“質(zhì)量保證”、“技術(shù)評審”和“測試”。 ? 機構(gòu)領(lǐng)導組建 SEPG 和 QAG，專門從事軟件過程改進工作。 立項評審委員會 由機構(gòu)領(lǐng)導、各級經(jīng)理、市場人員、技術(shù)專家、財務人員等組成，委員會按少數(shù)服從多數(shù)原則投票決定是否同意立項。 （ 2）周期性的開展“過程與產(chǎn)品質(zhì)量檢查”。 項目研發(fā) 過程 角色 需求分析員 調(diào)查、分析并定義需求，撰寫相應的需求文檔，盡最大努力使需求文檔能夠正確無誤地反映用戶的真實意愿。 （ 2）在機構(gòu)范圍內(nèi)推廣該規(guī)范（如培訓、考核），評估機構(gòu)過程能力等。 質(zhì)量保證 提供一種有效的人員組織形式和管理方法，通過客觀地檢查和監(jiān)控“過程質(zhì)量”與“產(chǎn)品質(zhì)量”，從而實現(xiàn)持續(xù)地改進質(zhì)量。 系統(tǒng)設(shè)計 設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu)、用戶界面、數(shù)據(jù)庫、模塊等，從而在需求與代碼之間建立橋梁，指導開發(fā)人員去實現(xiàn)能滿足用戶需求的軟件產(chǎn) 品。杜絕不符合機構(gòu)最大利益的立項建議被采納，避免浪費機構(gòu)的資源、資金、時間等。 精簡 模型的主要特征和優(yōu)點有： 5 一、直觀的過程模型 精簡 模型將項目管理、項目研發(fā)、機構(gòu)支撐所包含的工作劃分為相對獨立的三類過程，各個過程域之間的關(guān)系直觀明 了。 項目管理過程包含 6 個過程域，分別為： ? 立項管理 ? 結(jié)項管理 ? 項目規(guī)劃 ? 項目監(jiān)控 ? 風險管理 ? 需求管理 項目研發(fā)過程包含 7 個過程域，分別 為： ? 需求開發(fā) ? 技術(shù)預研 ? 系統(tǒng)設(shè)計 ? 實現(xiàn)與測試 ? 系統(tǒng)測試 ? 客戶驗收 ? 技術(shù)評審 機構(gòu)支撐過程包含 4 個過程域，分別為： ? 配置管理 ? 質(zhì)量保證 ? 培訓管理 ? 服務與維護 精簡 模型如圖 11 所示。 項目管理過程域 目的 立項管理 采納符合機構(gòu)最大利益的立項建 議，通過立項管理使該建議成為正式的項目。 技術(shù)預研 在立項之后到開發(fā)工作完成之前的時間內(nèi)，對項目將采用的關(guān)鍵技術(shù)提前學習和研究，盡可能早地發(fā)現(xiàn)并解決開發(fā)過程中將會遇到的技術(shù)障礙。 配置管理是對工作成果的一種有效保護。 常設(shè)角色 職 責簡述 7 機構(gòu)過程改進角色 軟件工程過程組 （ SEPG） （ 1）制定適合于本機構(gòu)的過程規(guī)范。 （ 3）監(jiān)督項目成員的工作，審批項目成員的各種申請。 質(zhì)量保證員 （即 QAG 成員） （ 1）為項目制定《質(zhì)量保證計劃》。 （ 2）申請立項，并在立項評審會議上答辯。 機構(gòu)領(lǐng)導的支持 ? 機構(gòu)領(lǐng)導批準用于 軟件過程改進的必要經(jīng)費，例如支付咨詢費，購買相關(guān)軟件工具等。 質(zhì)量管理的政策 質(zhì)量管理口號：“在開發(fā)過程之中內(nèi)建質(zhì)量而非修補質(zhì)量”。測試與技術(shù)評審的主要區(qū)別是前者要運行軟件而后者不必運行軟件。 QAG 在行政上獨立于任何項目。 允許項目經(jīng)理根據(jù)本項目的特征，在 SEPG 和 QAG 的指導下，適當?shù)夭眉艋驍U充機構(gòu)的過程規(guī)范，從而快速建立本項目的過程規(guī)范。通常《項目計劃》由項目經(jīng)理負責制定，由機構(gòu)領(lǐng)導審批。 任務名稱 實際起止時間 跟蹤日期、當前進度 實際工作量 實際工作成果 表 41 任務跟蹤表 費用跟蹤 項目經(jīng)理（或其指定的項目成員）周期性地跟蹤項目費用，將采集的數(shù)據(jù)保存在《項目監(jiān)控數(shù)據(jù)表》之中。 項目經(jīng)理周期性地總結(jié)項目進展情況，撰寫《項目進展報告》并通報給機構(gòu)領(lǐng)導和所有項目成員。 為了便于量化管理，我們給風險定義 3 個參數(shù)： ? 風險嚴重性 ：指風險對項目造成的危害程度。 表 51 風險嚴重性等級 參數(shù) 等 級 值 描述 風險 可能性 很高 5 風險發(fā)生的幾率為 ~ 比較高 4 風險發(fā)生的幾率為 ~ 中等 3 風險發(fā)生的幾率為 ~ 比較低 2 風險發(fā)生的幾率為 ~ 很低 1 風險發(fā)生的幾率為 ~ 表 52 風險可能性等級 風險 系數(shù) 風險可能性 很高 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 本表灰色部分的風險系數(shù)值為 10~25，應當優(yōu)先處理。 常用的 《 風險檢查表 》 ，使用者應根據(jù)實際情況進行適當?shù)膭h減或補充。我明白需求的變更將導致雙方重新協(xié)商成本、資源和進度等。 ? 逆向跟蹤。 ? 當需求文檔或后續(xù)工作成果發(fā)生變更時，要及時更新需求跟蹤矩陣。前者是指項目按預定計劃結(jié)束。該評估報告可以作為考核項目人員業(yè)績的重要依據(jù)。我們把從事需求 開發(fā)工作的人員稱為需求分析員（也叫系統(tǒng)分析員），避免 與其它 開發(fā)人員混淆。如果一點技術(shù)障礙都沒有遇到，要么是開發(fā)人員的技術(shù)水平實在太高了，要么是項目的技術(shù)含量實在 太低了，這類情況比較少見。 本規(guī)范闡述了系統(tǒng)設(shè)計過程域的四個主要規(guī)程： ? 體系結(jié)構(gòu)設(shè)計 ? 用戶界面設(shè)計 ? 數(shù)據(jù)庫設(shè)計 ? 模塊設(shè)計 系統(tǒng)設(shè)計過程域分為兩個階段：高層設(shè)計階段 和詳細設(shè)計階段。 制作用戶界面的資源如圖像、圖標或者界面專用組件等 項目經(jīng)理指定若干名開發(fā)人員從事用戶界面設(shè)計（以下稱為界面設(shè)計人員）。 模塊設(shè)計流程如圖 105 所示。一個項目可能有一個或者多個開發(fā)小 Step2. 模塊設(shè)計 Step1. 設(shè)計 準備 接口與屬性設(shè)計 數(shù)據(jù)結(jié)構(gòu) 與算法設(shè)計 Step3. 撰寫 文檔 Step4. 設(shè)計 評審 迭代 編程 代碼審查 單元測試 集成測試 模塊 軟件系統(tǒng) 準備 缺陷管理與改錯 29 組。 系統(tǒng)測試流程如圖 121 所示。 ? 機構(gòu)的質(zhì)量保證人員。 ? 性能測試。 系統(tǒng)測試過程域產(chǎn)生的主要文檔有：