【正文】 基線通常對應(yīng)于開發(fā)過程中的里程碑（ Milestone），一個(gè)產(chǎn)品可以有多個(gè)基線，也可以只有一個(gè)基線。 凡是納入配置管理范疇的工作成果統(tǒng)稱為配置項(xiàng)（ Configuration Item, CI），配置項(xiàng)主要有兩大類： （ 1）屬于產(chǎn)品組成部分的工作成果，例如需求文檔、設(shè)計(jì)文檔、源代碼、測試用例 等 。 圖 141 技術(shù)評審過程域示意圖 技術(shù)評審的注意事項(xiàng)： ? 評審人員的職責(zé)是發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員給出消除缺陷的辦法，而不是替開發(fā)人員消除缺陷。 技術(shù)評審有兩種基本類型： ? 正規(guī)技術(shù)評審（ FTR）?？蛻趄?yàn)收流程如圖 131所示。 客戶對產(chǎn)品的驗(yàn)收主要有兩種方式： ? 成果審查?！鞍踩笔窍鄬Χ缘模话愕?，如果黑客為非法入侵花費(fèi)的代價(jià)（考慮時(shí)間、費(fèi)用、危險(xiǎn)等因素）高于得到的好處，那么這樣的系統(tǒng)可 以認(rèn)為是安全的。即測試軟件系統(tǒng)在異常情況下能否正常運(yùn)行的能力。 ? 邀請 其它 項(xiàng)目的開發(fā)人員參與系統(tǒng)測試。 開發(fā)組長管理編程、代碼審查、單元測試、集成測試、缺陷管理與改錯(cuò)等活動(dòng)。 圖 111 實(shí)現(xiàn)與測試流程圖 由于實(shí)現(xiàn)與測試是工作量最大、時(shí)間最長、產(chǎn)生 工 作成果（代碼與文檔）最多的一個(gè)項(xiàng)目研發(fā)過程域，所以需要作充分的準(zhǔn)備工作。 圖 104 數(shù)據(jù)庫設(shè)計(jì)流程 《數(shù)據(jù)庫設(shè)計(jì)報(bào)告 》 模塊設(shè)計(jì) 設(shè)計(jì)軟件所有模塊的主要接口與屬性、數(shù)據(jù)結(jié)構(gòu)和算法，產(chǎn)生《模塊設(shè)計(jì)報(bào)告》。 體系結(jié)構(gòu)設(shè)計(jì)流程如圖 102 所示。 技術(shù)預(yù)研的流程 如圖 91 所示。 需求開發(fā) 過程 域 產(chǎn)生的主要文檔有： 需求分析 用戶需求說明書 產(chǎn)品需求規(guī)格說明書 用戶需求調(diào)查 輸出 輸出 產(chǎn)品需求定義 需求 變更 控制 需求確認(rèn) 需求跟蹤 需求 開發(fā) 過程域 需求 管理 過程域 24 《用戶需求說明書 》 《產(chǎn)品需求規(guī)格說 明書》 9 技術(shù)預(yù)研 技術(shù)預(yù)研（ Technical PreResearch, TPR）是指在立項(xiàng)之后到開發(fā)工作完成之前的時(shí)間內(nèi)，對 項(xiàng)目將采用的關(guān)鍵技術(shù) 提前學(xué)習(xí)和研究，以便盡可能早地發(fā)現(xiàn)并解決開發(fā)過程中將會遇到的技術(shù)障礙。而“需求分析”則貫穿于上述兩個(gè)階段。 ? 對 項(xiàng)目進(jìn)行綜合評估。 立項(xiàng)管理 與結(jié)項(xiàng) 管理是前后呼應(yīng)的兩個(gè)過程域，使得項(xiàng)目管理過程“有始有終”。由于對應(yīng)關(guān)系比較復(fù)雜，最好在表格中加必要的文字解釋。 建立與維護(hù)需求跟蹤矩陣： 20 ? 正向跟蹤。示例如下： 本需求文檔建立在雙方對需求的共同理解基礎(chǔ)之上，我同意后續(xù)的開發(fā)工作根據(jù)該需求文檔開展。 圖 51 風(fēng)險(xiǎn)管理示意圖 在項(xiàng)目的生命周期內(nèi)，上述 4 個(gè)活動(dòng)將被循環(huán)執(zhí)行，如圖 51 所示。 比較低 2 例如進(jìn)度延誤低于 10%，或者費(fèi)用超支低于 10%。另一種是主動(dòng)態(tài)度，可比作“防火模式”。 工作成果名稱 新開發(fā)的成果規(guī)模 （代碼行、類、文檔頁數(shù)） 復(fù)用或自動(dòng)生成的成果規(guī)模 （代碼行、類、文檔頁數(shù)） 工作成果 1 工作成果 2 … 總和 表 44 工作成果及其規(guī)模跟蹤表 控制偏差 對比“項(xiàng)目實(shí)際進(jìn)展”和“項(xiàng)目計(jì)劃”，分析偏差，如果發(fā)現(xiàn)項(xiàng)目實(shí)際進(jìn) 展顯著偏離計(jì)劃，則及時(shí)采取糾正措施。 任務(wù)跟蹤 項(xiàng)目經(jīng)理（或其指定的項(xiàng)目成員）周期性地（如每周一次）跟蹤每個(gè)重要的任務(wù)，將采集的數(shù)據(jù)保存在《項(xiàng)目監(jiān)控?cái)?shù)據(jù)表》之中。 項(xiàng)目的計(jì)劃書可分兩類：一是全局的計(jì)劃書（ Overall Plan），這里稱為《項(xiàng)目計(jì)劃》； 10 二是一些下屬計(jì)劃書（ Subordinate Plan），例如《配置管理計(jì)劃》、《質(zhì)量保證計(jì)劃》、一些開發(fā)計(jì)劃和測試計(jì)劃等。 項(xiàng)目團(tuán)隊(duì)的政策 項(xiàng)目中的任何管理人員、開發(fā)人員、測試人員等，必須學(xué)習(xí)與本職工作相關(guān)的過程規(guī)范，每個(gè)人都必須明白自己“ 應(yīng)當(dāng)在什么時(shí)候依據(jù)什么規(guī)范做什么事情 ”。 質(zhì)量保證小組的政策 機(jī)構(gòu)領(lǐng)導(dǎo)任命一位熟悉過程規(guī)范并且有豐富的質(zhì)量管理經(jīng)驗(yàn)的人擔(dān)任 QAG 的負(fù)責(zé)人（或稱為質(zhì)量經(jīng)理）。技術(shù)評審活動(dòng)由項(xiàng)目開發(fā)團(tuán)隊(duì)組織。 ? 機(jī)構(gòu)領(lǐng)導(dǎo)不僅要口頭支持，還要親自參與軟件過程改進(jìn)的實(shí)踐。 配置控制委員會 對配置管理各項(xiàng)活動(dòng)擁有決策權(quán)（例如審批計(jì)劃，審批變更請求等）。 （ 2）完善性維護(hù)：在資源允許的情況下，不斷改善產(chǎn)品功能與質(zhì)量。 機(jī)構(gòu) 支撐 過程 角色 配置管理員 （ 1）為項(xiàng)目制定《配置管理計(jì)劃》。 項(xiàng)目經(jīng)理 （ 1）向機(jī)構(gòu)領(lǐng)導(dǎo)匯報(bào)工 作。公司 在應(yīng)用 精簡模型 時(shí)，可以將 精簡模型的各個(gè)角色映射到公司 原有的崗位上，也可以依據(jù) 精簡模型 角色建立新的崗位。 技術(shù)評審 盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時(shí)消除缺陷，從而有效地提高產(chǎn)品的質(zhì)量。 需求管理 在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求與其它工作成果的一致性，并控制需求的變更。 0 圖 11 精簡 模型 產(chǎn)品概念 產(chǎn)品定義 產(chǎn)品開發(fā) 產(chǎn)品測試 客戶驗(yàn)收 產(chǎn)品維護(hù) 立項(xiàng)管理 項(xiàng)目規(guī)劃 項(xiàng)目監(jiān)控 風(fēng)險(xiǎn)管理 需求管理 結(jié)項(xiàng)管理 需求開發(fā) 配置管理 質(zhì)量保證 培訓(xùn)管理 項(xiàng)目 管理 過程 項(xiàng)目 研發(fā) 過程 機(jī)構(gòu)支撐過程 服務(wù)與維護(hù) 技術(shù)評審 技術(shù)預(yù)研 并行 、迭代 根據(jù)產(chǎn)品特征確定最合適的開發(fā)模型， 以線性順序?yàn)橹?，以并行、迭代為輔。 精簡 模型把產(chǎn)品生命周期劃分為 6 個(gè)階段，分別為： ? 產(chǎn)品概念階段 ? 產(chǎn)品定義階段 ? 產(chǎn)品開發(fā)階段 ? 產(chǎn)品測試階段 ? 用戶驗(yàn)收階段 ? 產(chǎn)品維護(hù)階段 在 精簡 模型中，軟件項(xiàng)目的過程有三大類：項(xiàng)目管理過程、項(xiàng)目研發(fā)過程和機(jī)構(gòu)支持過程。所以 精簡 模型有助于使機(jī)構(gòu)內(nèi)的各個(gè)職能單位 有條不紊地開展工作。 項(xiàng)目規(guī)劃 為項(xiàng)目的研發(fā)和管理工作制定合理的行動(dòng)綱領(lǐng)（即項(xiàng)目計(jì)劃），以便所有相關(guān)人員按照該計(jì)劃有條不紊地開展工作。在 精簡模型 中，實(shí)現(xiàn)與測試是“編程、代碼審查、單元測試、集成測試、缺陷管理與改錯(cuò)”的綜合表述。 服務(wù)與維護(hù) 是指產(chǎn)品銷售之后的客戶服務(wù)和產(chǎn)品維護(hù)，其宗旨是提高客戶對產(chǎn)品以及對開發(fā)方的滿意度。 （ 2）分析并解決機(jī)構(gòu)內(nèi)存在的共性質(zhì)量問題，協(xié)組 SEPG 完善規(guī)范。 程序員 （ 1）根據(jù)系統(tǒng)設(shè)計(jì)文檔，編寫軟件系統(tǒng)的代碼。 培訓(xùn)管理員 制定機(jī)構(gòu)（或項(xiàng)目）的《培訓(xùn)計(jì)劃》，監(jiān)督該計(jì)劃的實(shí)施，撰寫《培訓(xùn)評估報(bào)告》。結(jié)項(xiàng)委員會的人員組成與立項(xiàng)評審委員會的類似。建議讓 SEPG 和QAG 的大部分人員重疊，這些人既是 SEPG 成員又是質(zhì)量保證員，扮演兩種角色。 機(jī)構(gòu)的質(zhì)量保證員獨(dú)立于任何項(xiàng)目，并賦予他一定的權(quán)利，對質(zhì)量不合格的工作成果作出處理。系統(tǒng)測試階段必須有項(xiàng)目外的人員參與，以保證系統(tǒng)測試的客觀性。 機(jī)構(gòu)領(lǐng)導(dǎo)賦予 QAG 一定的權(quán)利，可以對質(zhì)量不合格的工作成果做出處理。 SEPG 對項(xiàng)目過程能力的評估成績將作為評定項(xiàng)目人員工作業(yè)績的重要因素，具體比重由機(jī)構(gòu)領(lǐng)導(dǎo)決定，建議占 30％以上的比重。 圖 31 項(xiàng)目規(guī)劃流程圖 項(xiàng)目計(jì)劃模板 4 項(xiàng)目監(jiān)控 項(xiàng)目監(jiān)控（ Project Monitoring and Control, PMC）的目的是通過周期性地跟蹤項(xiàng)目計(jì)劃的各種參數(shù)如進(jìn)度、工作量、費(fèi)用、資源、工作成果等，不斷地了解項(xiàng)目的進(jìn)展情況，以便當(dāng)項(xiàng)目實(shí)際進(jìn)展?fàn)顩r顯著偏離計(jì)劃時(shí)能夠及時(shí)采取糾正措施。資源跟蹤表的參考格式如表 43 所示。被刻畫為風(fēng)險(xiǎn)的事件最終可能發(fā)生也可能不發(fā)生。 參數(shù) 等級 值 描述 風(fēng)險(xiǎn) 嚴(yán)重性 很高 5 例如進(jìn)度延誤大于 30%，或者費(fèi)用超支大于 30%。 ? 風(fēng)險(xiǎn)分析：估計(jì)風(fēng)險(xiǎn)嚴(yán)重性、風(fēng)險(xiǎn)可能性、風(fēng)險(xiǎn)系數(shù)。 子 承包商 供應(yīng)商 與子承包商、 供應(yīng)商 簽訂的合同公正嗎？雙方互利嗎？ 子承包商、 供應(yīng)商 的信譽(yù)好嗎？ 子承包商、 供應(yīng)商 有可能倒閉嗎？ 子承包商、 供應(yīng)商 能及時(shí)交付質(zhì)量合格的產(chǎn)品（或部件）嗎？ 子承包商、 供應(yīng)商 有能力做好售后服務(wù)嗎？ 管理風(fēng)險(xiǎn) 風(fēng)險(xiǎn)類型 檢查項(xiàng) 項(xiàng)目計(jì)劃 對項(xiàng)目的規(guī)模、難度估計(jì)是否比較正確？ 人力資源（開發(fā)人員、管理人員）夠用嗎？合格嗎？ 項(xiàng)目所需的軟件、硬件能按時(shí)到位嗎？ 項(xiàng)目的經(jīng)費(fèi)夠用嗎？ 進(jìn)度安排是否過于緊張？有合理的緩沖時(shí)間嗎？ 進(jìn) 度表中是否遺忘了一些重要的（必要的）任務(wù)？ 進(jìn)度安排是否考慮了關(guān)鍵路徑？ 是否可能出現(xiàn)某一項(xiàng)工作延誤導(dǎo)致其他一連串的工作也被延誤？ 任務(wù)分配是否合理？（即把任務(wù)分配給合適的項(xiàng)目成員，充分發(fā)揮其才能） 是否為了節(jié)省錢，不采用（購買）成熟的軟件模塊，一切從零做起？ … 項(xiàng)目團(tuán)隊(duì) 項(xiàng)目成員團(tuán)結(jié)嗎？是否存在矛盾？ 是否絕大部分的項(xiàng)目成員對工作認(rèn)真負(fù)責(zé)？ 絕大部分的項(xiàng)目成員有工作熱情嗎？ 團(tuán)隊(duì)之中有“害群之馬”嗎？ 技術(shù)開發(fā)隊(duì)伍中有臨時(shí)工嗎？ 本項(xiàng)目開發(fā)過程中是否會有 核心人員辭職、調(diào)動(dòng)？ 是否能保證“人員流動(dòng)基本不會影響工作的連續(xù)性”？ 項(xiàng)目經(jīng)理是否忙于行政事務(wù)而無暇顧及項(xiàng)目的開發(fā)工作？ 上級領(lǐng)導(dǎo) 行政部門 合作部門 本項(xiàng)目是否得到上級領(lǐng)導(dǎo)的重視？ 上級領(lǐng)導(dǎo)是否隨時(shí)會抽調(diào)本項(xiàng)目的資源用于其他“高優(yōu)先級”的項(xiàng)目？ 上級領(lǐng)導(dǎo)是否過多地介入本項(xiàng)目的事務(wù)并且瞎指揮？ 行政部門的辦事效率是否比較底，以至于拖項(xiàng)目的后腿？ 行政部門是否經(jīng)常干一些無益于生產(chǎn)力的事情，以至于騷擾本項(xiàng)目？ 機(jī)構(gòu)是否能全面、公正地考核員工的工作業(yè)績？ 機(jī)構(gòu)是否有較好的獎(jiǎng)勵(lì)和 懲罰措施？ 本項(xiàng)目的合作部門的態(tài)度積極嗎？是否應(yīng)付了事？或者做事與承諾的不一致？ 技術(shù)風(fēng)險(xiǎn) 風(fēng)險(xiǎn)類型 檢查項(xiàng) 需求開發(fā)人員懂得如何獲取用戶需求嗎？效率高嗎？ 17 需求開發(fā) 需求管理 需求開發(fā)人員懂得項(xiàng)目所涉及的具體業(yè)務(wù)嗎？能否理解用戶的需求？ 需求文檔能夠正確地、完備地表達(dá)用戶需求嗎？ 需求開發(fā)人員能否與客戶對有爭議的需求達(dá)成共識？ 需求開發(fā)人員能否獲得客戶對需求文檔的承諾？以保證客戶不隨便變更需求？ 綜合技術(shù) 開發(fā)能力 包括設(shè)計(jì) 編程、測試等 開發(fā)人員是否有開發(fā)相似產(chǎn)品的經(jīng) 驗(yàn)？ 待開發(fā)的產(chǎn)品是否要與未曾證實(shí)的軟硬件相連接？ 對開發(fā)人員而言，本項(xiàng)目的技術(shù)難度高嗎？ 開發(fā)人員是否已經(jīng)掌握了本項(xiàng)目的關(guān)鍵技術(shù)？ 如果某項(xiàng)技術(shù)尚未實(shí)踐過，開發(fā)人員能否在預(yù)定時(shí)間內(nèi)掌握？ 開發(fā)小組是否采用比較有效的分析、設(shè)計(jì)、編程、測試工具？ 分析與設(shè)計(jì)工作是否過于簡單、草率，從而讓程序員邊做邊改？ 開發(fā)小組采用統(tǒng)一的編程規(guī)范嗎？ 開發(fā)人員對測試工作重視嗎？能保證測試的客觀性嗎？ 項(xiàng)目有獨(dú)立的測試人員嗎？懂得如何進(jìn)行高效率地測試嗎？ 是否對所有重要的工作成果進(jìn)行了 同行評審（正式評審或快速檢查）？ 開發(fā)人員懂得版本控制、變更控制嗎？能夠按照配置管理規(guī)范執(zhí)行嗎？ 開發(fā)人員重視質(zhì)量嗎？是否會在進(jìn)度延誤時(shí)降低質(zhì)量要求？ 表 54 風(fēng)險(xiǎn)檢查表 風(fēng)險(xiǎn)名稱 風(fēng)險(xiǎn)識別人 風(fēng)險(xiǎn)編號 風(fēng)險(xiǎn)識別日期 風(fēng)險(xiǎn)描述 風(fēng)險(xiǎn)嚴(yán)重性 風(fēng)險(xiǎn)系數(shù) 風(fēng)險(xiǎn)可能性 風(fēng)險(xiǎn)處理人 風(fēng)險(xiǎn)減緩措施 跟蹤記錄 （ 1）記錄何人在何時(shí)做了什么事情 （ 2）記錄當(dāng)前風(fēng)險(xiǎn)狀態(tài)（正在處理，已經(jīng)解決，不作處理） 18 表 55 風(fēng)險(xiǎn)管理報(bào)告 6 需求管理 需求管 理（ Requirement Management, RM）的目的在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求 與其他 工作成果的一致性，并控制需求的變更。 [ ] 工作成果不合格，需要作比較大的修改，之后必須重新對其評審。不論采用何種跟蹤方式，都要建立與維護(hù)需求跟蹤矩陣（即表格）。 補(bǔ)充說明：本規(guī)程中的“原需求文檔”是指已經(jīng)通過了評審并獲得書面承諾的需求文檔。 不論項(xiàng)目屬于正常結(jié)束還是異常結(jié)束，都要按照 結(jié)項(xiàng) 管理規(guī)范處理。 機(jī)構(gòu)領(lǐng)導(dǎo)指示 結(jié)項(xiàng)申請 機(jī)構(gòu)領(lǐng)導(dǎo)審批 結(jié)項(xiàng)評審 資產(chǎn)檢查 綜合評估 經(jīng)驗(yàn)總結(jié) 23 本規(guī)范闡述了需求開發(fā)過程 域 的兩個(gè)主要規(guī)程： ? 需求調(diào)查 ? 需求定義 需求開發(fā)與需求管理是相輔相成的兩類活動(dòng)，它們共同構(gòu)成完整的需求工程。常用的需求分析方法有“問答分析法”、“結(jié)構(gòu)化分析法”和“面向?qū)ο蠓治龇ā?。最糟糕的是，如果此技術(shù)障礙無法攻克，不得已要改變技術(shù)方案、重新設(shè)計(jì)系統(tǒng)，那么不僅浪費(fèi)了人力、財(cái)力、時(shí)間，處理不好還會使開發(fā)隊(duì)伍陷入混亂狀態(tài)。 圖 101 系統(tǒng)設(shè)計(jì)過程域示意圖 系