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