【正文】 ustomer Acceptance, CA）是指客戶依據(jù)合同對產(chǎn)品進行審查和測試，確保產(chǎn)品滿足客戶需求。 ? 驗收測試。驗收測試人員來自于客戶方，而系統(tǒng)測試人員則來自于開發(fā)方。 本規(guī)范闡述了技術(shù)評審過程域的三個主要規(guī)程： ? 制定技術(shù)評審計劃 ? 正式技術(shù)評審 ? 非正式技術(shù)評審 技術(shù)評審能夠在任何開發(fā)階段執(zhí)行，它可以比測試更早地發(fā)現(xiàn)并消除工作成果中的缺陷。 可見技術(shù)評審有助于“提高質(zhì)量、提高生產(chǎn)率、降低成本”，符合軟 件過程改進的根本目的。 ITR 的形式比較靈活，通常在同伴之間開展，不必舉行評審會議，評審人員比較少。 技術(shù)評審過程域有三個主要規(guī)程：“制定技術(shù)評審計劃”、“正規(guī)技術(shù)評審”和“非正規(guī)技術(shù)評審”，如圖 141 所示。 技術(shù)評審過程域產(chǎn)生的主要文檔有： ? 《技術(shù)評審計劃》 ? 《技術(shù)評審?fù)ㄖ? ? 《技術(shù)評審報告》 ? 《技術(shù)評審檢查表》 《技術(shù)評審計劃》 《技術(shù)評審?fù)ㄖ?《技術(shù)評審報告》 《技術(shù)評審檢查表 》 15 配置管理 配置管理（ Configuration Management, CM）的目的是通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件，來保證所有配置項的完整性和可跟蹤性。毫無疑問，人們應(yīng)當(dāng)將文件分門別類、有條理地保存起來。 每個配置項的主要屬性有 ：名稱、標(biāo)識符、文件狀態(tài)、版本、作者、日期等。基線中的配置項被“凍結(jié)”了，不能再被任何人隨意修改（見變更控制規(guī)程）。 所有的項目成員都要使用?；€的主要屬性有：名稱、標(biāo)識符、版本、日期等。配置項及其歷史記錄反映了軟件的演化過程。 （ 2）項目管理和機構(gòu)支撐過程域產(chǎn)生的文檔。 本規(guī)范闡述了配置管理過程域的四個主要規(guī)程： ? 制定配置管理計劃 ? 配置庫管理 ? 配置項版本控制 ? 配置項變更控制 項目研發(fā)和管理過程中會產(chǎn)生許許多多的工作成果，例如文檔、程序和數(shù)據(jù)等，它們都應(yīng)當(dāng)被保存起來，以便查閱和修改。 制定技術(shù)評審計劃 正規(guī)技術(shù)評審 非正規(guī)技術(shù)評審 33 ? 技術(shù)評審應(yīng)當(dāng)“ 就是論事 ”，不要打擊有失誤的開發(fā)人員的工作積極性，更不準(zhǔn)搞人身攻擊（如挖苦、諷刺等）。現(xiàn)實中，為了節(jié)約時間，允許人們有選擇地對工作成果進行技術(shù)評審。 FTR 比較嚴(yán)格，需要舉行評審會議，參加評審會議的人員比較多。 ? 越早消除缺陷就越能降低開發(fā)成本。 圖 131 客戶驗收流程 客戶驗收過程域產(chǎn)生的主要文檔有： ? 《客戶驗收計劃》 ? 《驗收測試用例》 ? 《客戶驗收報告》 補充說明： “客戶驗收”是針對合同項目而言的。 驗收測試的內(nèi)容、方法與系統(tǒng)測試幾乎是相同的。驗收人員審查開發(fā)方應(yīng)當(dāng)交付的成果，如代碼、文檔等等。測試組長管理上述事務(wù)。 ? 安裝與反安裝測試。重點是測試軟件系統(tǒng)的易用性和視覺效果等。健壯性有兩層含義：一是容錯能力，二是恢復(fù)能力。即測試軟件系統(tǒng)的功能是否正確，其依據(jù)是需求文檔，如《產(chǎn)品需求規(guī)格說明書》。 ? 本項目的部分開發(fā)人員。 系統(tǒng)測試過程中發(fā)現(xiàn)的 所有缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應(yīng)當(dāng)及時消除缺陷（改錯）。 《編程文檔》 《實現(xiàn)與測試計劃 》 12 系統(tǒng)測試 系統(tǒng)測試（ System Test, ST）的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。所以開發(fā)人員還要互相審查和測試同伴的代碼。 實現(xiàn)與測試工作基本上在開發(fā)小組內(nèi)部開展。 實現(xiàn)與測試的 流程如圖 111 所示。 項 目經(jīng)理指定若干名開發(fā)人員從事模塊的設(shè)計（以下稱為模塊設(shè)計人員），模塊設(shè)計人員將在實現(xiàn)階段編寫這些模塊的代碼。 圖 103 體系結(jié)構(gòu)設(shè)計流程 《用戶界面設(shè)計》 Step1. 設(shè)計 準(zhǔn)備 Step5. 撰寫 文檔 Step6. 設(shè)計 評審 Step2. 確定 約束 因素 Step3. 確定 設(shè)計 策略 Step4. 系統(tǒng) 分解 設(shè)計 Step2. 界面設(shè)計 Step1. 設(shè)計 準(zhǔn)備 原型創(chuàng)作 原型評估 細(xì)化 Step3. 撰寫 文檔 Step4. 設(shè)計 評審 迭代 27 數(shù)據(jù)庫設(shè)計 設(shè)計軟件的數(shù)據(jù)庫，產(chǎn)生《數(shù)據(jù)庫設(shè)計報告》。 詳細(xì)設(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è)計報告》。 圖 101 系統(tǒng)設(shè)計過程域示意圖 系統(tǒng)設(shè)計過程域產(chǎn)生的主要文檔有： ? 《體系結(jié)構(gòu)設(shè)計報告》 ? 《用戶界面設(shè)計報告》 ? 《數(shù)據(jù)庫設(shè)計報告》 ? 《模塊設(shè)計報告》 體系結(jié)構(gòu)設(shè)計 分析與設(shè)計軟件的體系結(jié)構(gòu)。 圖 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)品。最糟糕的是，如果此技術(shù)障礙無法攻克，不得已要改變技術(shù)方案、重新設(shè)計系統(tǒng)，那么不僅浪費了人力、財力、時間，處理不好還會使開發(fā)隊伍陷入混亂狀態(tài)。 在產(chǎn)品開發(fā)過程中，技術(shù)問題可能會層出不窮。常用的需求分析方法有“問答分析法”、“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā?。需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系，實際工作中二者通常是迭代進行的。 機構(gòu)領(lǐng)導(dǎo)指示 結(jié)項申請 機構(gòu)領(lǐng)導(dǎo)審批 結(jié)項評審 資產(chǎn)檢查 綜合評估 經(jīng)驗總結(jié) 23 本規(guī)范闡述了需求開發(fā)過程 域 的兩個主要規(guī)程： ? 需求調(diào)查 ? 需求定義 需求開發(fā)與需求管理是相輔相成的兩類活動，它們共同構(gòu)成完整的需求工程。例如評估項目完成情況、項目質(zhì)量、投入產(chǎn)出分析、項目的市場價值、項目對企業(yè)的貢獻(xiàn)等等。 不論項目屬于正常結(jié)束還是異常結(jié)束，都要按照 結(jié)項 管理規(guī)范處理。 項目結(jié) 束有兩種狀況：一是正常結(jié)束，二是異常結(jié)束。 補充說明：本規(guī)程中的“原需求文檔”是指已經(jīng)通過了評審并獲得書面承諾的需求文檔。表 63 為簡單的需求跟蹤矩陣格式。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格）。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應(yīng)點。 [ ] 工作成果不合格，需要作比較大的修改，之后必須重新對其評審。如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程”執(zhí)行。 子 承包商 供應(yīng)商 與子承包商、 供應(yīng)商 簽訂的合同公正嗎？雙方互利嗎？ 子承包商、 供應(yīng)商 的信譽好嗎？ 子承包商、 供應(yīng)商 有可能倒閉嗎？ 子承包商、 供應(yīng)商 能及時交付質(zhì)量合格的產(chǎn)品（或部件）嗎？ 子承包商、 供應(yīng)商 有能力做好售后服務(wù)嗎？ 管理風(fēng)險 風(fēng)險類型 檢查項 項目計劃 對項目的規(guī)模、難度估計是否比較正確？ 人力資源（開發(fā)人員、管理人員）夠用嗎？合格嗎？ 項目所需的軟件、硬件能按時到位嗎？ 項目的經(jīng)費夠用嗎？ 進度安排是否過于緊張？有合理的緩沖時間嗎？ 進 度表中是否遺忘了一些重要的（必要的）任務(wù)？ 進度安排是否考慮了關(guān)鍵路徑？ 是否可能出現(xiàn)某一項工作延誤導(dǎo)致其他一連串的工作也被延誤？ 任務(wù)分配是否合理？（即把任務(wù)分配給合適的項目成員，充分發(fā)揮其才能） 是否為了節(jié)省錢，不采用（購買）成熟的軟件模塊，一切從零做起？ … 項目團隊 項目成員團結(jié)嗎？是否存在矛盾？ 是否絕大部分的項目成員對工作認(rèn)真負(fù)責(zé)？ 絕大部分的項目成員有工作熱情嗎？ 團隊之中有“害群之馬”嗎？ 技術(shù)開發(fā)隊伍中有臨時工嗎？ 本項目開發(fā)過程中是否會有 核心人員辭職、調(diào)動？ 是否能保證“人員流動基本不會影響工作的連續(xù)性”？ 項目經(jīng)理是否忙于行政事務(wù)而無暇顧及項目的開發(fā)工作？ 上級領(lǐng)導(dǎo) 行政部門 合作部門 本項目是否得到上級領(lǐng)導(dǎo)的重視？ 上級領(lǐng)導(dǎo)是否隨時會抽調(diào)本項目的資源用于其他“高優(yōu)先級”的項目？ 上級領(lǐng)導(dǎo)是否過多地介入本項目的事務(wù)并且瞎指揮？ 行政部門的辦事效率是否比較底，以至于拖項目的后腿？ 行政部門是否經(jīng)常干一些無益于生產(chǎn)力的事情，以至于騷擾本項目？ 機構(gòu)是否能全面、公正地考核員工的工作業(yè)績？ 機構(gòu)是否有較好的獎勵和 懲罰措施？ 本項目的合作部門的態(tài)度積極嗎？是否應(yīng)付了事？或者做事與承諾的不一致？ 技術(shù)風(fēng)險 風(fēng)險類型 檢查項 需求開發(fā)人員懂得如何獲取用戶需求嗎？效率高嗎？ 17 需求開發(fā) 需求管理 需求開發(fā)人員懂得項目所涉及的具體業(yè)務(wù)嗎？能否理解用戶的需求？ 需求文檔能夠正確地、完備地表達(dá)用戶需求嗎？ 需求開發(fā)人員能否與客戶對有爭議的需求達(dá)成共識？ 需求開發(fā)人員能否獲得客戶對需求文檔的承諾？以保證客戶不隨便變更需求？ 綜合技術(shù) 開發(fā)能力 包括設(shè)計 編程、測試等 開發(fā)人員是否有開發(fā)相似產(chǎn)品的經(jīng) 驗？ 待開發(fā)的產(chǎn)品是否要與未曾證實的軟硬件相連接？ 對開發(fā)人員而言，本項目的技術(shù)難度高嗎？ 開發(fā)人員是否已經(jīng)掌握了本項目的關(guān)鍵技術(shù)？ 如果某項技術(shù)尚未實踐過，開發(fā)人員能否在預(yù)定時間內(nèi)掌握？ 開發(fā)小組是否采用比較有效的分析、設(shè)計、編程、測試工具？ 分析與設(shè)計工作是否過于簡單、草率，從而讓程序員邊做邊改？ 開發(fā)小組采用統(tǒng)一的編程規(guī)范嗎？ 開發(fā)人員對測試工作重視嗎？能保證測試的客觀性嗎？ 項目有獨立的測試人員嗎？懂得如何進行高效率地測試嗎？ 是否對所有重要的工作成果進行了 同行評審（正式評審或快速檢查）？ 開發(fā)人員懂得版本控制、變更控制嗎？能夠按照配置管理規(guī)范執(zhí)行嗎？ 開發(fā)人員重視質(zhì)量嗎？是否會在進度延誤時降低質(zhì)量要求？ 表 54 風(fēng)險檢查表 風(fēng)險名稱 風(fēng)險識別人 風(fēng)險編號 風(fēng)險識別日期 風(fēng)險描述 風(fēng)險嚴(yán)重性 風(fēng)險系數(shù) 風(fēng)險可能性 風(fēng)險處理人 風(fēng)險減緩措施 跟蹤記錄 （ 1）記錄何人在何時做了什么事情 （ 2）記錄當(dāng)前風(fēng)險狀態(tài)（正在處理，已經(jīng)解決，不作處理） 18 表 55 風(fēng)險管理報告 6 需求管理 需求管 理（ Requirement Management, RM）的目的在客戶與開發(fā)方之間建立對需求的共同理解，維護需求 與其他 工作成果的一致性，并控制需求的變更。直到項目的所有風(fēng)險都被識別與解決為止。 ? 風(fēng)險分析：估計風(fēng)險嚴(yán)重性、風(fēng)險可能性、風(fēng)險系數(shù)。 很低 1 例如進度延誤低于 5%，或者費用超支低于 5%。 參數(shù) 等級 值 描述 風(fēng)險 嚴(yán)重性 很高 5 例如進度延誤大于 30%，或者費用超支大于 30%。風(fēng)險管理屬于“防火模式”，目的就是“防止風(fēng)險產(chǎn)生真正的危害”。被刻畫為風(fēng)險的事件最終可能發(fā)生也可能不發(fā)生。 記錄日期 顯著偏差描述 原因分析 糾正措施 結(jié)果 表 45 項目偏差控制報告 13 項目進展匯報 周期性地匯報項目進展情況。資源跟蹤表的參考格式如表 43 所示。任務(wù)跟蹤表的參考格式如表 41 所示。 圖 31 項目規(guī)劃流程圖 項目計劃模板 4 項目監(jiān)控 項目監(jiān)控（ Project Monitoring and Control, PMC）的目的是通過周期性地跟蹤項目計劃的各種參數(shù)如進度、工作量、費用、資源、工作成果等，不斷地了解項目的進展情況，以便當(dāng)項目實際進展?fàn)顩r顯著偏離計劃時能夠及時采取糾正措施。 下屬計劃書是對《項目計劃》的補充，其內(nèi)容不可與《項目計劃》沖突。 SEPG 對項目過程能力的評估成績將作為評定項目人員工作業(yè)績的重要因素，具體比重由機構(gòu)領(lǐng)導(dǎo)決定，建議占 30％以上的比重。項目經(jīng)理應(yīng)當(dāng)樹立榜樣，并且督促項目成員們按規(guī)范做事。 機構(gòu)領(lǐng)導(dǎo)賦予 QAG 一定的權(quán)利，可以對質(zhì)量不合格的工作成果做出處理。在機構(gòu)領(lǐng)導(dǎo)的許可下，該負(fù)責(zé)人組建 QAG（成員可以是全職的也可以是兼職的）。系統(tǒng)測試階段必須有項目外的人員參與，以保證系統(tǒng)測試的客觀性。 三、測試 測試是指通過運行測試用例（ test case）來找出軟件中的缺陷。 機構(gòu)的質(zhì)量保證員獨立于任何項目，并賦予他一定的權(quán)利，對質(zhì)量不合格的工作成果作出處理。