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