【正文】 值的數(shù)據(jù)。工作成果跟蹤表的參考格式如表 44 所示。一種是被動態(tài)度，可比作“救火模式”。 中等 3 例如進度延誤低于 20%，或者費用超支低于 20%。 ? 風(fēng)險跟蹤：跟蹤風(fēng)險減緩 過程，記錄風(fēng)險的狀態(tài)。 當(dāng)需求文檔通過正式的評審之后，開發(fā)方負責(zé)人（項目經(jīng)理）和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。 項目經(jīng)理跟蹤需求。矩陣單元之 間的可能存在“一對一”、“一對多”或“多對多”的關(guā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é)項 管理至少包括三項內(nèi)容： ? 對項目的有形資產(chǎn)和無形資產(chǎn)進行清算，既要防止資產(chǎn)流失，又要及時地利用這些資產(chǎn)。 圖 81 需求開發(fā)與需求管理流程圖 需求開發(fā)可分為兩個階段：“用戶需求調(diào)查階段”和“產(chǎn)品需求定義階段”。系統(tǒng)設(shè)計人員將依據(jù)《產(chǎn)品需求規(guī)格說明書》開展系統(tǒng)設(shè)計工作。 ? 防止開發(fā)進程被技術(shù)障礙打斷，導(dǎo)致大量的相關(guān)工作被阻塞。 項目經(jīng)理指定若干名開發(fā)人員從事體 系結(jié)構(gòu)設(shè)計（以下稱為體系結(jié)構(gòu)設(shè)計人員）。 數(shù)據(jù)庫設(shè)計流程如圖 104 所示。上述任何活動中發(fā)現(xiàn)的缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應(yīng)當(dāng)及時消除缺陷（改錯）。開發(fā)組長由項目經(jīng)理指定。系統(tǒng)測試小組的成員主要來源于： ? 機構(gòu)獨立的測試小組（如果存在的話）。 ? 健壯性測試。是指測試軟件系統(tǒng)防止非法入侵的能力。 制定測試計劃 設(shè)計測試用例 執(zhí)行系統(tǒng)測試 缺陷管理與改錯 審批 審批 迭代 31 《系統(tǒng)測試計劃》 《測試用例》 《測試報告》 13 客戶驗收 客戶驗收（ Customer Acceptance, CA）是指客戶依據(jù)合同對產(chǎn)品進行審查和測試，確保產(chǎn)品滿足客戶需求。驗收測試人員來自于客戶方，而系統(tǒng)測試人員則來自于開發(fā)方。 可見技術(shù)評審有助于“提高質(zhì)量、提高生產(chǎn)率、降低成本”，符合軟 件過程改進的根本目的。 技術(shù)評審過程域有三個主要規(guī)程：“制定技術(shù)評審計劃”、“正規(guī)技術(shù)評審”和“非正規(guī)技術(shù)評審”，如圖 141 所示。毫無疑問，人們應(yīng)當(dāng)將文件分門別類、有條理地保存起來?；€中的配置項被“凍結(jié)”了，不能再被任何人隨意修改（見變更控制規(guī)程）?；€的主要屬性有：名稱、標識符、版本、日期等。 （ 2）項目管理和機構(gòu)支撐過程域產(chǎn)生的文檔。 制定技術(shù)評審計劃 正規(guī)技術(shù)評審 非正規(guī)技術(shù)評審 33 ? 技術(shù)評審應(yīng)當(dāng)“ 就是論事 ”，不要打擊有失誤的開發(fā)人員的工作積極性，更不準搞人身攻擊（如挖苦、諷刺等）。 FTR 比較嚴格，需要舉行評審會議，參加評審會議的人員比較多。 圖 131 客戶驗收流程 客戶驗收過程域產(chǎn)生的主要文檔有： ? 《客戶驗收計劃》 ? 《驗收測試用例》 ? 《客戶驗收報告》 補充說明： “客戶驗收”是針對合同項目而言的。驗收人員審查開發(fā)方應(yīng)當(dāng)交付的成果，如代碼、文檔等等。 ? 安裝與反安裝測試。健壯性有兩層含義：一是容錯能力，二是恢復(fù)能力。 ? 本項目的部分開發(fā)人員。 《編程文檔》 《實現(xiàn)與測試計劃 》 12 系統(tǒng)測試 系統(tǒng)測試（ System Test, ST）的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。 實現(xiàn)與測試工作基本上在開發(fā)小組內(nèi)部開展。 項 目經(jīng)理指定若干名開發(fā)人員從事模塊的設(shè)計（以下稱為模塊設(shè)計人員），模塊設(shè)計人員將在實現(xiàn)階段編寫這些模塊的代碼。 詳細設(shè)計階段 高層設(shè)計階段 體系結(jié)構(gòu)設(shè)計 模塊設(shè)計 數(shù)據(jù) 庫設(shè)計 用戶界面設(shè)計 需求開發(fā) 實現(xiàn)與測試 26 圖 102 體系結(jié)構(gòu)設(shè)計流程 《體系結(jié)構(gòu)設(shè)計報 告》 用戶界面設(shè)計 設(shè)計軟件的用戶界面，產(chǎn)生《用戶界面設(shè)計報告》。 圖 91 技 術(shù)預(yù)研流程 技術(shù)預(yù)研過程中產(chǎn)生的主要文檔有： 《技術(shù)預(yù)研計劃》 《技術(shù)預(yù)研報告》 10 系統(tǒng)設(shè)計 系統(tǒng)設(shè)計（ System Design, SD）是指設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu)、用戶界面、數(shù)據(jù)庫、 制定計劃 撰寫預(yù)研報告 工作成果介紹 技術(shù)評審 … 開展技術(shù)預(yù)研 25 模塊等，從而在需求與代碼之間建立橋梁，指導(dǎo)開發(fā)人員去實現(xiàn)能滿足用戶需求的軟件產(chǎn)品。 在產(chǎn)品開發(fā)過程中，技術(shù)問題可能會層出不窮。需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系，實際工作中二者通常是迭代進行的。例如評估項目完成情況、項目質(zhì)量、投入產(chǎn)出分析、項目的市場價值、項目對企業(yè)的貢獻等等。 項目結(jié) 束有兩種狀況：一是正常結(jié)束，二是異常結(jié)束。表 63 為簡單的需求跟蹤矩陣格式。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應(yīng)點。如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程”執(zhí)行。直到項目的所有風(fēng)險都被識別與解決為止。 很低 1 例如進度延誤低于 5%，或者費用超支低于 5%。風(fēng)險管理屬于“防火模式”，目的就是“防止風(fēng)險產(chǎn)生真正的危害”。 記錄日期 顯著偏差描述 原因分析 糾正措施 結(jié)果 表 45 項目偏差控制報告 13 項目進展匯報 周期性地匯報項目進展情況。任務(wù)跟蹤表的參考格式如表 41 所示。 下屬計劃書是對《項目計劃》的補充，其內(nèi)容不可與《項目計劃》沖突。項目經(jīng)理應(yīng)當(dāng)樹立榜樣，并且督促項目成員們按規(guī)范做事。在機構(gòu)領(lǐng)導(dǎo)的許可下，該負責(zé)人組建 QAG（成員可以是全職的也可以是兼職的）。 三、測試 測試是指通過運行測試用例（ test case）來找出軟件中的缺陷。例如參加培訓(xùn)和考試 ，準照過程規(guī)范執(zhí)行立項管理和結(jié)項管理等。 表 13 精簡模型 的角色與職責(zé)簡表 8 公司 軟件過程的政策 目標 ? 持續(xù)改進機構(gòu)的軟件過程能力，不斷地提高產(chǎn)品質(zhì)量、提高生產(chǎn)率并且降低開發(fā)成本。 臨時角色 職責(zé)說明 立項建議小組 （ 1）開展立項調(diào)查、產(chǎn)品構(gòu)思和可行性分析，撰寫相應(yīng)文檔。 （ 2）創(chuàng)建并維護配置庫，如分配權(quán)限、清除垃圾文件、備份配置庫等。 （ 2）是項目規(guī)劃、項目監(jiān)控、風(fēng)險管理和需求管理過程域的負責(zé)人。 一個人可以被賦予多個角色， 視具體情況而定。 機構(gòu)支撐過程域 目的 配置管理 通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件來保證所有配置項的完整性和可跟蹤性。 項目研發(fā)過程域 目的 需求開發(fā) 通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。 系統(tǒng)設(shè)計 實現(xiàn)與測試 系統(tǒng)測試 客戶驗收 其它： 人力資源管理 財務(wù)管理 行政管理 市場營銷 … 4 精簡 過程域的目的 精簡模型 所有 17 個過程域的目的如表 11 所示。上述三類過程可以細分為 17 個主要過程域，分布在 產(chǎn)品生命周期 的各個階段。這樣，機構(gòu)領(lǐng)導(dǎo)、項目經(jīng)理、開發(fā)人員、測試人員、質(zhì)量保證人員 等人根據(jù) 精簡 模型，很容易知道自己“應(yīng)該在什么時候、按照什么規(guī)范做什么事情”。 結(jié)項管理 在項目開發(fā)工作結(jié)束后，對項目的有形資產(chǎn)和無形資產(chǎn)進行清算、對項目進行綜合評估以及總結(jié)經(jīng)驗教訓(xùn)等。 實現(xiàn)與測試 依據(jù)系統(tǒng)設(shè)計文檔，編寫并測試整個系統(tǒng)的代碼。 培訓(xùn)管理 根據(jù)機構(gòu)（或項目）的需求來制定培訓(xùn)計劃，并監(jiān)督該計劃的實施，確保培訓(xùn)取得預(yù)期效果。 質(zhì)量保證小組 （ QAG） （ 1）監(jiān)督規(guī)范的實施，確保所有項目以及相關(guān)部門準照規(guī)范開展工作。 系統(tǒng)設(shè)計師 根據(jù)需求文檔設(shè)計軟件系統(tǒng)的體系結(jié)構(gòu)、用戶界面、數(shù)據(jù)庫、模塊等，并撰寫相應(yīng)的設(shè)計文檔。 （ 3）跟蹤質(zhì)量問題，給出質(zhì)量改進措施。 結(jié)項評審委員會 對項目的有形資產(chǎn)和無形資產(chǎn)進行清算 ，對項目進行綜合評估，總結(jié)經(jīng)驗教訓(xùn)等。 SEPG 的主要職責(zé)是建立適合于機構(gòu)的過程規(guī)范， QAG 的主要職責(zé)是監(jiān)督該規(guī)范的實施。 一、 質(zhì)量保證 機構(gòu)的質(zhì)量保證員周期性地檢查項目成員的“工作過程以及工作成果”是否符合既定的規(guī)范，來監(jiān)控和改進“過程質(zhì)量以及產(chǎn)品質(zhì)量”。其中單元測試和集成測試可以由項目開發(fā)團隊組織。 QAG 準照 SEPG 制定的“質(zhì)量保證規(guī)范”開展工作。 如果項目對機構(gòu)過程規(guī)范的裁剪幅度比較大，遭到 QAG 的反對，如果雙方不能達成共識，則由機構(gòu)領(lǐng)導(dǎo)處理該爭議。 項目計劃過程域有 3 個主要規(guī)程：“制定項目計劃”、“審批項目計劃”和“項目計劃變更控制”，流程如圖 31 所示。 費用類別 主要開支項、用途 金額 時間 表 42 費用跟蹤表 資源跟蹤 項目經(jīng)理（或其指定的項目成員）周期性地跟蹤軟硬件資源，將采集的數(shù)據(jù)保存在《項目監(jiān)控數(shù)據(jù)表》之中。 所有可能危害項目的因素都稱為風(fēng)險。 ? 風(fēng)險系數(shù)：是風(fēng)險嚴重性和風(fēng)險可能性的乘積。 風(fēng)險管理有 4 個主要活動： ? 風(fēng)險識別：根據(jù)風(fēng)險檢查表，識別出本項目的風(fēng)險。 商業(yè)風(fēng)險 風(fēng)險類型 檢查項 政治 法律 市場 政府或者其他機構(gòu)對本項目的開發(fā)有限制嗎？ 有不可預(yù)測的市場動蕩嗎？ 有不利于我方的官司要打嗎？ 本產(chǎn)品銷售后在使用過程中可能導(dǎo)致發(fā)生重大的損失或傷亡事故嗎？ 競爭對手有不正當(dāng)?shù)母偁幮袨閱幔? 本產(chǎn)品銷售后在使用過程中可能導(dǎo)致發(fā)生重大的損失或傷亡事故嗎？ 是否在開發(fā)很少有人真正需要卻自以為很好的產(chǎn)品？ 是否在開發(fā)可能虧本的產(chǎn)品？ 客戶 客戶的需求是否含糊不清？ 客戶是否反反復(fù)復(fù)地改動需求？ 客戶指定的需求和交付期限在客觀上可行嗎？ 客戶對產(chǎn)品的健壯性、可靠性、性能等質(zhì)量因素有非常過分的要求嗎？ 客戶的合作態(tài)度友善嗎？ 與客戶簽的合同公正嗎？雙方互利嗎？ 風(fēng)險識別 風(fēng)險分析 風(fēng)險減緩 風(fēng)險跟蹤 16 客戶的信譽好嗎？例如按客戶的需求開發(fā)了產(chǎn)品，但是客戶可能不購買。 [√ ] 工作成果基本合格，需要作少量的修改，之后通過審核即可。 ? 正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。 ? 控制需求文檔的變更，防止發(fā)生混亂。例如有些項目因不適應(yīng)市場而被中途淘汰，有些項目在執(zhí)行過程中大大因偏離計劃（如進度延誤、費用超支）而被取消。 圖 71 結(jié) 項管理流程圖 結(jié)項管理的流程如圖 71 所示，產(chǎn)生的主要文檔有： 《結(jié)項申請書》 《結(jié)項評審報告》 8 需求開發(fā) 需求開發(fā)（ Requirement Development, RD）的目的是通過調(diào)查與分析，獲取用 戶需求并定義產(chǎn)品需求。 二、需求分析 需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節(jié)等。因為其他人的工作可能會被阻塞，已經(jīng)投入的不少資源將被閑置。詳細設(shè)計階段的重點是用戶界面設(shè)計、數(shù)據(jù)庫設(shè)計和模塊設(shè)計，如圖 101 所示。 用戶界面設(shè)計流程如圖 103 所示。在本規(guī)范中，實現(xiàn)與測試是“編程、代碼審查、單元測試、集成測試、缺陷管理與改錯”的綜合表述。 特別要注意的是，開發(fā)人員應(yīng)當(dāng)對自己的代碼進行審查和測試（這是 份內(nèi) 的工作），但是不能作為該代碼已經(jīng)通過審查和測試的依據(jù)。這樣可以提高系統(tǒng)測試的效率。一般地，系統(tǒng)測試的主要內(nèi)容包括： ? 功能測試。 ? 用戶界面測試。 系統(tǒng)測試小組各成員共同制定測試計劃、設(shè)計測試用例、執(zhí)行測試，并撰寫相應(yīng)的文檔。驗收人員對待交付的產(chǎn)品進行全面的測試，確保產(chǎn)品功能、質(zhì)量符合需求。技術(shù)評審的主要好處有： ? 通過消除工作成果的缺陷而提高產(chǎn)品的質(zhì)量。 理論上講，為了確保產(chǎn)品的質(zhì)量，產(chǎn)品的所有工作成果都應(yīng)當(dāng)接受技術(shù)評審。 配置管理是對工作成果的一種有效保護。所有配置項都 被保存在配置庫里，確保不會混淆、丟失