【正文】 所有的項目成員都要使用?；€的主要屬性有：名稱、標(biāo)識符、版本、日期等?；€中的配置項被“凍結(jié)”了，不能再被任何人隨意修改（見變更控制規(guī)程）。配置項及其歷史記錄反映了軟件的演化過程。 每個配置項的主要屬性有 ：名稱、標(biāo)識符、文件狀態(tài)、版本、作者、日期等。 （ 2）項目管理和機構(gòu)支撐過程域產(chǎn)生的文檔。毫無疑問，人們應(yīng)當(dāng)將文件分門別類、有條理地保存起來。 本規(guī)范闡述了配置管理過程域的四個主要規(guī)程： ? 制定配置管理計劃 ? 配置庫管理 ? 配置項版本控制 ? 配置項變更控制 項目研發(fā)和管理過程中會產(chǎn)生許許多多的工作成果，例如文檔、程序和數(shù)據(jù)等，它們都應(yīng)當(dāng)被保存起來，以便查閱和修改。 技術(shù)評審過程域產(chǎn)生的主要文檔有： ? 《技術(shù)評審計劃》 ? 《技術(shù)評審?fù)ㄖ? ? 《技術(shù)評審報告》 ? 《技術(shù)評審檢查表》 《技術(shù)評審計劃》 《技術(shù)評審?fù)ㄖ?《技術(shù)評審報告》 《技術(shù)評審檢查表 》 15 配置管理 配置管理（ Configuration Management, CM）的目的是通過執(zhí)行版本控制、變更控制等規(guī)程，以及使用配置管理軟件，來保證所有配置項的完整性和可跟蹤性。 制定技術(shù)評審計劃 正規(guī)技術(shù)評審 非正規(guī)技術(shù)評審 33 ? 技術(shù)評審應(yīng)當(dāng)“ 就是論事 ”，不要打擊有失誤的開發(fā)人員的工作積極性，更不準搞人身攻擊（如挖苦、諷刺等）。 技術(shù)評審過程域有三個主要規(guī)程：“制定技術(shù)評審計劃”、“正規(guī)技術(shù)評審”和“非正規(guī)技術(shù)評審”，如圖 141 所示?，F(xiàn)實中，為了節(jié)約時間，允許人們有選擇地對工作成果進行技術(shù)評審。 ITR 的形式比較靈活，通常在同伴之間開展，不必舉行評審會議，評審人員比較少。 FTR 比較嚴格，需要舉行評審會議，參加評審會議的人員比較多。 可見技術(shù)評審有助于“提高質(zhì)量、提高生產(chǎn)率、降低成本”，符合軟 件過程改進的根本目的。 ? 越早消除缺陷就越能降低開發(fā)成本。 本規(guī)范闡述了技術(shù)評審過程域的三個主要規(guī)程： ? 制定技術(shù)評審計劃 ? 正式技術(shù)評審 ? 非正式技術(shù)評審 技術(shù)評審能夠在任何開發(fā)階段執(zhí)行，它可以比測試更早地發(fā)現(xiàn)并消除工作成果中的缺陷。 圖 131 客戶驗收流程 客戶驗收過程域產(chǎn)生的主要文檔有： ? 《客戶驗收計劃》 ? 《驗收測試用例》 ? 《客戶驗收報告》 補充說明： “客戶驗收”是針對合同項目而言的。驗收測試人員來自于客戶方，而系統(tǒng)測試人員則來自于開發(fā)方。 驗收測試的內(nèi)容、方法與系統(tǒng)測試幾乎是相同的。 ? 驗收測試。驗收人員審查開發(fā)方應(yīng)當(dāng)交付的成果，如代碼、文檔等等。 制定測試計劃 設(shè)計測試用例 執(zhí)行系統(tǒng)測試 缺陷管理與改錯 審批 審批 迭代 31 《系統(tǒng)測試計劃》 《測試用例》 《測試報告》 13 客戶驗收 客戶驗收（ Customer Acceptance, CA）是指客戶依據(jù)合同對產(chǎn)品進行審查和測試，確保產(chǎn)品滿足客戶需求。測試組長管理上述事務(wù)。 項目經(jīng)理組建系統(tǒng)測試小組，并指定一名成員任測試組長。 ? 安裝與反安裝測試。是指測試軟件系統(tǒng)防止非法入侵的能力。重點是測試軟件系統(tǒng)的易用性和視覺效果等。即測試軟件系統(tǒng)處理事務(wù)的速度，一是為了檢驗性能是否符合需求，二是為了得到某些性能數(shù)據(jù)供人們參考（例如用于宣傳）。健壯性有兩層含義：一是容錯能力，二是恢復(fù)能力。 ? 健壯性測試。即測試軟件系統(tǒng)的功能是否正確，其依據(jù)是需求文檔，如《產(chǎn)品需求規(guī)格說明書》。 系統(tǒng)測試小組應(yīng)當(dāng)根據(jù)項目的特征確定測試內(nèi)容。 ? 本項目的部分開發(fā)人員。系統(tǒng)測試小組的成員主要來源于： ? 機構(gòu)獨立的測試小組（如果存在的話）。 系統(tǒng)測試過程中發(fā)現(xiàn)的 所有缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應(yīng)當(dāng)及時消除缺陷（改錯）。由于系統(tǒng)測試的目的是驗證最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計，所以當(dāng)產(chǎn)品需求和系統(tǒng)設(shè)計文檔完成之后，系統(tǒng)測試小組就可以提前開始制定測試計劃和設(shè)計測試用例，而不必等到“實現(xiàn)與測試”階段結(jié)束。 《編程文檔》 《實現(xiàn)與測試計劃 》 12 系統(tǒng)測試 系統(tǒng)測試（ System Test, ST）的目的是對最終軟件系統(tǒng)進行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計。開發(fā)組長由項目經(jīng)理指定。所以開發(fā)人員還要互相審查和測試同伴的代碼。對于小型項目，項目經(jīng)理可以兼任開發(fā)組長 。 實現(xiàn)與測試工作基本上在開發(fā)小組內(nèi)部開展。上述任何活動中發(fā)現(xiàn)的缺陷必須用統(tǒng)一的缺陷管理工具來管理，開發(fā)人員應(yīng)當(dāng)及時消除缺陷（改錯）。 實現(xiàn)與測試的 流程如圖 111 所示。 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)的代碼。 項 目經(jīng)理指定若干名開發(fā)人員從事模塊的設(shè)計（以下稱為模塊設(shè)計人員），模塊設(shè)計人員將在實現(xiàn)階段編寫這些模塊的代碼。 數(shù)據(jù)庫設(shè)計流程如圖 104 所示。 圖 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é)助設(shè)計用戶界面。 詳細設(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è)計報告》。 項目經(jīng)理指定若干名開發(fā)人員從事體 系結(jié)構(gòu)設(shè)計（以下稱為體系結(jié)構(gòu)設(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)。 高層設(shè)計階段的重點是軟件系統(tǒng)的體系結(jié)構(gòu)設(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)品。 ? 防止開發(fā)進程被技術(shù)障礙打斷，導(dǎo)致大量的相關(guān)工作被阻塞。最糟糕的是，如果此技術(shù)障礙無法攻克，不得已要改變技術(shù)方案、重新設(shè)計系統(tǒng)，那么不僅浪費了人力、財力、時間，處理不好還會使開發(fā)隊伍陷入混亂狀態(tài)。 一般說來，在設(shè)計或?qū)崿F(xiàn)階段遇到了技術(shù)障礙，才去攻克問題，其代價通常比較高。 在產(chǎn)品開發(fā)過程中，技術(shù)問題可能會層出不窮。系統(tǒng)設(shè)計人員將依據(jù)《產(chǎn)品需求規(guī)格說明書》開展系統(tǒng)設(shè)計工作。常用的需求分析方法有“問答分析法”、“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā薄? 一、需求調(diào)查 需求調(diào)查的目的是通過各種途徑獲取用戶的需求信息（原始材料），產(chǎn)生《用戶需求說明書》。需求調(diào)查階段和需求定義階段在邏輯上存在先后關(guān)系，實際工作中二者通常是迭代進行的。 圖 81 需求開發(fā)與需求管理流程圖 需求開發(fā)可分為兩個階段：“用戶需求調(diào)查階段”和“產(chǎ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)成完整的需求工程。 ? 總結(jié)經(jīng)驗教訓(xùn)，使整個機構(gòu)受益。例如評估項目完成情況、項目質(zhì)量、投入產(chǎn)出分析、項目的市場價值、項目對企業(yè)的貢獻等等。 有價值的 結(jié)項 管理至少包括三項內(nèi)容： ? 對項目的有形資產(chǎn)和無形資產(chǎn)進行清算，既要防止資產(chǎn)流失，又要及時地利用這些資產(chǎn)。 不論項目屬于正常結(jié)束還是異常結(jié)束，都要按照 結(jié)項 管理規(guī)范處理。后者原因有多種，歸根結(jié)底都是由于該項目不再符合機構(gòu)的最大利益。 項目結(jié) 束有兩種狀況：一是正常結(jié)束，二是異常結(jié)束。 需求變更申請 申請變更的 需求文檔 輸入名稱，版本，日期等信息 變更的內(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)等。 補充說明：本規(guī)程中的“原需求文檔”是指已經(jīng)通過了評審并獲得書面承諾的需求文檔。 ＃ 需求文檔 （版本，日期） 設(shè)計文檔 （版本，日期） 代碼 （版本，日期） 測試用例 （版本，日期） 1 標(biāo)題或標(biāo)識符，說明 標(biāo)題或標(biāo)識符，說明 代碼名稱，說明 測試用例名稱，說明 2 … … … … 表 63 簡單的需求跟蹤矩陣格式 需求變更控制 ? 修改“原需求文檔”中不正確的 內(nèi)容，產(chǎn)生新的需求文檔。表 63 為簡單的需求跟蹤矩陣格式。矩陣單元之 間的可能存在“一對一”、“一對多”或“多對多”的關(guān)系。不論采用何種跟蹤方式，都要建立與維護需求跟蹤矩陣（即表格）。檢查設(shè)計文檔、代碼、測試用例等工作成果是否都能在需求文檔中找到出處。檢查需求文檔中的每個需求是否都能在后續(xù)工作成果中找到對應(yīng)點。 項目經(jīng)理跟蹤需求。 [ ] 工作成果不合格，需要作比較大的修改，之后必須重新對其評審。 甲方負責(zé)人簽字 乙方負責(zé)人簽字 需求工程 需求開發(fā) 需求變更控制 需求管理 需求 確認 需求跟蹤 需求調(diào)查 需求分析 需求定義 19 評審結(jié)束 輸出 《需求評審報告》 ， 書面的需求承諾 需求評審報告摘要 需求文檔 輸入名稱，標(biāo)識符，版本，作者，完成日期， … 需求評審報告 輸入名稱，標(biāo)識符，評 審日期， … 評審結(jié)論 [ ] 工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。如果需求發(fā)生變化，我們將按照“需求變更控制規(guī)程”執(zhí)行。 當(dāng)需求文檔通過正式的評審之后，開發(fā)方負責(zé)人（項目經(jīng)理）和客戶對需求文檔作書面承諾，使之具有商業(yè)合同效果。 子 承包商 供應(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ù)？