【正文】 通常將交付給客戶的基線稱為一個(gè)“ Release”，為內(nèi)部開發(fā)用的基線則稱為一個(gè)“ Build”。 34 基線（ Baseline）由一組配置項(xiàng)組成，這些配置項(xiàng)構(gòu)成了一個(gè)相對(duì)穩(wěn)定的邏輯實(shí)體。這些文檔雖然不是產(chǎn)品的組成部分，但 是值得保存。如果把所有文件一股腦地塞進(jìn)計(jì)算機(jī)里，那么使用起來(lái)肯定很麻煩。 ? 在會(huì)議評(píng)審期間要限制過(guò)多的爭(zhēng)論，以免浪費(fèi)他人的時(shí)間。技術(shù)評(píng)審方式也視工作成果的重要性和復(fù)雜性而定。 ? 非正規(guī)技術(shù)評(píng)審（ ITR）。 ? 開發(fā)人員能夠及時(shí)地得到同行專家的幫助和指導(dǎo)，無(wú)疑會(huì)加深對(duì)工作成果的理解，更好地預(yù)防缺陷，一定程度上提高了開發(fā)生產(chǎn)率。 《客戶驗(yàn)收計(jì)劃》 《客戶驗(yàn)收?qǐng)?bào)告》 驗(yàn)收準(zhǔn)備 問(wèn)題處理 成果審查與驗(yàn)收測(cè)試 交付與簽字 32 14 技術(shù)評(píng)審 技術(shù)評(píng)審（ Technical Review, TR）的目的是盡早地發(fā)現(xiàn)工作成果中的缺陷， 并幫助開發(fā)人員及時(shí)消除缺陷，從而有效地提高產(chǎn)品的質(zhì)量。兩者主要區(qū)別在于執(zhí)行 人員不同。確保這些成果是完整的并且是正確的。 開發(fā)人員及時(shí)消除測(cè)試人員發(fā)現(xiàn)的缺陷。 系統(tǒng)測(cè)試過(guò)程域產(chǎn)生的主要文檔有： ? 《系統(tǒng)測(cè)試計(jì)劃》 ? 《系統(tǒng)測(cè)試用例》 ? 《系統(tǒng)測(cè)試報(bào)告》 ? 《缺陷管理報(bào)告》 對(duì)最終軟件系統(tǒng)進(jìn)行全面的測(cè)試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計(jì)。 ? 安全性（ security）測(cè)試。 ? 性能測(cè)試。由于正確性是軟件最重 要的質(zhì)量因素，所以功能測(cè)試必不可少。 ? 機(jī)構(gòu)的質(zhì)量保證人員。 30 圖 121 系統(tǒng)測(cè)試流程圖 項(xiàng)目經(jīng)理設(shè)法組建富有成效的系統(tǒng)測(cè)試小組。 系統(tǒng)測(cè)試流程如圖 121 所示。 實(shí)現(xiàn)與測(cè)試過(guò)程域產(chǎn)生的主要文檔有： ? 《實(shí)現(xiàn)與測(cè)試計(jì)劃》 ? 《編程文檔》 ? 《代碼審查報(bào)告》 ? 《測(cè)試用例》 ? 《測(cè)試報(bào)告》 ? 《缺陷管理報(bào)告》（由缺陷管理工具自動(dòng)生成） 一個(gè)項(xiàng)目可能有多個(gè)開發(fā)小組，視項(xiàng)目規(guī)模而定。一個(gè)項(xiàng)目可能有一個(gè)或者多個(gè)開發(fā)小 Step2. 模塊設(shè)計(jì) Step1. 設(shè)計(jì) 準(zhǔn)備 接口與屬性設(shè)計(jì) 數(shù)據(jù)結(jié)構(gòu) 與算法設(shè)計(jì) Step3. 撰寫 文檔 Step4. 設(shè)計(jì) 評(píng)審 迭代 編程 代碼審查 單元測(cè)試 集成測(cè)試 模塊 軟件系統(tǒng) 準(zhǔn)備 缺陷管理與改錯(cuò) 29 組。一般地，編程、代碼審查、單元測(cè)試、集成測(cè)試大致存在先后順序關(guān)系，也可以并行、迭代地開展。 模塊設(shè)計(jì)流程如圖 105 所示。 項(xiàng)目經(jīng)理指定若干名開發(fā)人員從事數(shù)據(jù)庫(kù)設(shè)計(jì)（以下稱為數(shù)據(jù)庫(kù)設(shè)計(jì)人員）。 制作用戶界面的資源如圖像、圖標(biāo)或者界面專用組件等 項(xiàng)目經(jīng)理指定若干名開發(fā)人員從事用戶界面設(shè)計(jì)（以下稱為界面設(shè)計(jì)人員）。通過(guò)系統(tǒng)分解，確定子系統(tǒng)的功能和子系統(tǒng)之間的關(guān)系，以及模塊的功能和模塊之間的關(guān)系，產(chǎn)生《體系結(jié)構(gòu)設(shè)計(jì)報(bào)告》。 本規(guī)范闡述了系統(tǒng)設(shè)計(jì)過(guò)程域的四個(gè)主要規(guī)程： ? 體系結(jié)構(gòu)設(shè)計(jì) ? 用戶界面設(shè)計(jì) ? 數(shù)據(jù)庫(kù)設(shè)計(jì) ? 模塊設(shè)計(jì) 系統(tǒng)設(shè)計(jì)過(guò)程域分為兩個(gè)階段：高層設(shè)計(jì)階段 和詳細(xì)設(shè)計(jì)階段。 所以開展技術(shù)預(yù)研工作至少有兩大好處： ? 幫助開發(fā)人員更好地進(jìn)行需求開發(fā)、系統(tǒng)設(shè)計(jì)和程序設(shè)計(jì)。如果一點(diǎn)技術(shù)障礙都沒(méi)有遇到，要么是開發(fā)人員的技術(shù)水平實(shí)在太高了，要么是項(xiàng)目的技術(shù)含量實(shí)在 太低了，這類情況比較少見。 三、需求定義 需求定義的目的是根據(jù)需求調(diào)查和需求分析的結(jié)果，進(jìn)一步定義準(zhǔn)確無(wú)誤的產(chǎn)品需求，產(chǎn)生《產(chǎn)品需求規(guī)格說(shuō)明書》。我們把從事需求 開發(fā)工作的人員稱為需求分析員（也叫系統(tǒng)分析員），避免 與其它 開發(fā)人員混淆。需求工程結(jié)構(gòu)圖如圖 61 所示，需求開發(fā)和需求管理的流程如圖 81 所示。該評(píng)估報(bào)告可以作為考核項(xiàng)目人員業(yè)績(jī)的重要依據(jù)。 國(guó)內(nèi)很多項(xiàng)目普遍存在“虎頭蛇尾”的現(xiàn)象， 結(jié)項(xiàng) 管理 畸 變成了“走過(guò)場(chǎng)，吃頓飯”，這是非常有害的。前者是指項(xiàng)目按預(yù)定計(jì)劃結(jié)束。 開發(fā)方負(fù)責(zé)人（項(xiàng)目經(jīng)理）和客戶共同控制需求變更。 ? 當(dāng)需求文檔或后續(xù)工作成果發(fā)生變更時(shí)，要及時(shí)更新需求跟蹤矩陣。需求跟蹤矩陣保存了需求與后續(xù)工作成果的對(duì)應(yīng)關(guān)系。 ? 逆向跟蹤。 評(píng)審意見 評(píng)審小組成員 輸入評(píng)審小組成員 表 61 需求評(píng)審報(bào)告 需求承諾 需求文檔 輸入名稱，標(biāo)識(shí)符，版本，作者，完成日期 客戶承諾 承諾 … 簽字，日期 項(xiàng)目經(jīng)理承諾 承諾 … 簽字，日期 表 62 需求承諾 需求跟蹤 將系統(tǒng)設(shè)計(jì)、編程、測(cè)試等階段的工作成果與需求文檔進(jìn)行比較，建立與維護(hù)“需求文檔－設(shè)計(jì)文檔－代碼－測(cè)試用例”之間的一致性，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。我明白需求的變更將導(dǎo)致雙方重新協(xié)商成本、資源和進(jìn)度等。 需求管理過(guò)程域的三個(gè)主要規(guī)程： ? 需求確認(rèn) ? 需求跟蹤 ? 需求變更控制 圖 61 需求工程結(jié)構(gòu)圖 需求確認(rèn) 項(xiàng)目經(jīng)理邀請(qǐng)同行專家和用戶（包括客戶和最終用戶）一起評(píng)審需求文檔， 盡最大努力使需求文檔能夠正確無(wú)誤地反映用戶的真實(shí)意愿。 常用的 《 風(fēng)險(xiǎn)檢查表 》 ，使用者應(yīng)根據(jù)實(shí)際情況進(jìn)行適當(dāng)?shù)膭h減或補(bǔ)充。 ? 風(fēng)險(xiǎn)減緩：對(duì)于風(fēng)險(xiǎn)系數(shù)超過(guò)“容許值”的每一個(gè)風(fēng)險(xiǎn)，都應(yīng)當(dāng)采取減緩措施。 表 51 風(fēng)險(xiǎn)嚴(yán)重性等級(jí) 參數(shù) 等 級(jí) 值 描述 風(fēng)險(xiǎn) 可能性 很高 5 風(fēng)險(xiǎn)發(fā)生的幾率為 ~ 比較高 4 風(fēng)險(xiǎn)發(fā)生的幾率為 ~ 中等 3 風(fēng)險(xiǎn)發(fā)生的幾率為 ~ 比較低 2 風(fēng)險(xiǎn)發(fā)生的幾率為 ~ 很低 1 風(fēng)險(xiǎn)發(fā)生的幾率為 ~ 表 52 風(fēng)險(xiǎn)可能性等級(jí) 風(fēng)險(xiǎn) 系數(shù) 風(fēng)險(xiǎn)可能性 很高 5 比較高 4 中等 3 比較低 2 很低 1 風(fēng)險(xiǎn) 嚴(yán)重性 很高 5 25 20 15 10 5 比較高 4 20 16 12 8 4 中等 3 15 12 9 6 3 比較低 2 10 8 6 4 2 很低 1 5 4 3 2 1 本表灰色部分的風(fēng)險(xiǎn)系數(shù)值為 10~25，應(yīng)當(dāng)優(yōu)先處理。 比較高 4 例如進(jìn)度延誤 20%~30%，或者費(fèi)用超支 20%~30%。 為了便于量化管理，我們給風(fēng)險(xiǎn)定義 3 個(gè)參數(shù)： ? 風(fēng)險(xiǎn)嚴(yán)重性 ：指風(fēng)險(xiǎn)對(duì)項(xiàng)目造成的危害程度。人們對(duì)待風(fēng)險(xiǎn)有兩種態(tài)度。 項(xiàng)目經(jīng)理周期性地總結(jié)項(xiàng)目進(jìn)展情況，撰寫《項(xiàng)目進(jìn)展報(bào)告》并通報(bào)給機(jī)構(gòu)領(lǐng)導(dǎo)和所有項(xiàng)目成員。 軟硬件資源名稱 級(jí)別 實(shí)際配置 獲取方式與時(shí)間 使用說(shuō)明 關(guān)鍵 12 關(guān)鍵 普通 … 普通 表 43 資源跟蹤表 工作成果及其規(guī)模跟蹤 項(xiàng)目經(jīng)理（或其指定的項(xiàng)目成員）周期性地跟蹤工作成果及其規(guī)模，將采集的數(shù)據(jù)保存在《項(xiàng)目監(jiān)控?cái)?shù)據(jù)表》之中。 任務(wù)名稱 實(shí)際起止時(shí)間 跟蹤日期、當(dāng)前進(jìn)度 實(shí)際工作量 實(shí)際工作成果 表 41 任務(wù)跟蹤表 費(fèi)用跟蹤 項(xiàng)目經(jīng)理（或其指定的項(xiàng)目成員）周期性地跟蹤項(xiàng)目費(fèi)用，將采集的數(shù)據(jù)保存在《項(xiàng)目監(jiān)控?cái)?shù)據(jù)表》之中。 本規(guī)范闡述了項(xiàng)目監(jiān)控過(guò)程域的三個(gè)主要規(guī)程： ? 項(xiàng)目計(jì)劃跟蹤 ? 控制偏差 ? 項(xiàng)目進(jìn)展匯報(bào) 圖 41 項(xiàng)目監(jiān)控流程 制定項(xiàng)目計(jì)劃 審批項(xiàng)目計(jì)劃 項(xiàng)目計(jì)劃變更控制 按計(jì)劃執(zhí)行 研發(fā)與管理工作 項(xiàng)目計(jì)劃跟蹤 偏差控制 項(xiàng)目進(jìn)展總結(jié) 周期性地開展 11 項(xiàng)目計(jì)劃跟蹤 周期性的跟蹤任務(wù)（含進(jìn)度和工作量）、費(fèi)用、資源、工作成果等，及時(shí)了解項(xiàng)目的實(shí)際進(jìn)展情況。通?！俄?xiàng)目計(jì)劃》由項(xiàng)目經(jīng)理負(fù)責(zé)制定，由機(jī)構(gòu)領(lǐng)導(dǎo)審批。 2 立項(xiàng) 管理 參見《 項(xiàng)目管理制度試行 版本》 3 項(xiàng)目規(guī)劃 在立項(xiàng)管理過(guò)程域的項(xiàng)目籌備階段，機(jī)構(gòu)領(lǐng)導(dǎo)首先任命一位項(xiàng)目經(jīng)理，之后機(jī)構(gòu)領(lǐng)導(dǎo)協(xié)助項(xiàng)目經(jīng)理籌備項(xiàng)目經(jīng)費(fèi)、人力資源、軟件硬件資源等。 允許項(xiàng)目經(jīng)理根據(jù)本項(xiàng)目的特征，在 SEPG 和 QAG 的指導(dǎo)下，適當(dāng)?shù)夭眉艋驍U(kuò)充機(jī)構(gòu)的過(guò)程規(guī)范，從而快速建立本項(xiàng)目的過(guò)程規(guī)范。這種權(quán)利使得 QAG 的工作不會(huì) 被輕視，并有助于加強(qiáng)全員的質(zhì)量意識(shí)。 QAG 在行政上獨(dú)立于任何項(xiàng)目。驗(yàn)收測(cè)試由客戶組織。測(cè)試與技術(shù)評(píng)審的主要區(qū)別是前者要運(yùn)行軟件而后者不必運(yùn)行軟件。 二、技術(shù)評(píng)審 在工作成果剛產(chǎn)生之際，對(duì)其進(jìn)行技術(shù)評(píng)審（分正式或非正式兩種），目的是盡早地發(fā)現(xiàn)工作成果中的缺 陷，并幫助開發(fā)人員及時(shí)消除缺陷，從而提高產(chǎn)品的質(zhì)量。 質(zhì)量管理的政策 質(zhì)量管理口號(hào)：“在開發(fā)過(guò)程之中內(nèi)建質(zhì)量而非修補(bǔ)質(zhì)量”。這樣不僅節(jié)約人力資源，并且提高了工作效果（由制定規(guī)范的人去監(jiān)督規(guī)范的實(shí)施最合適不過(guò)）。 機(jī)構(gòu)領(lǐng)導(dǎo)的支持 ? 機(jī)構(gòu)領(lǐng)導(dǎo)批準(zhǔn)用于 軟件過(guò)程改進(jìn)的必要經(jīng)費(fèi)，例如支付咨詢費(fèi)，購(gòu)買相關(guān)軟件工具等。 技術(shù)評(píng)審委員會(huì) 對(duì)工作成果進(jìn)行正式技術(shù)評(píng)審，盡早地發(fā)現(xiàn)工作成果中的缺陷，并幫助開發(fā)人員及時(shí)消除缺陷。 （ 2）申請(qǐng)立項(xiàng)，并在立項(xiàng)評(píng)審會(huì)議上答辯。 客戶服務(wù)人員 為客戶提供與產(chǎn)品相關(guān)的服務(wù)（如技術(shù)咨 詢），快速響應(yīng)客戶的要求，給客戶一個(gè)滿意的解答。 質(zhì)量保證員 （即 QAG 成員） （ 1）為項(xiàng)目制定《質(zhì)量保證計(jì)劃》。 （ 2）隨時(shí)測(cè)試和檢查自己的代碼，及時(shí)消除代碼中的缺陷。 （ 3）監(jiān)督項(xiàng)目成員的工作，審批項(xiàng)目成員的各種申請(qǐng)。 項(xiàng)目 管理 過(guò)程角色 機(jī)構(gòu)領(lǐng)導(dǎo) （ 1）是機(jī)構(gòu)內(nèi)所有項(xiàng)目的主管，對(duì)立項(xiàng)管理和結(jié)項(xiàng)管理有最終決策權(quán)。 常設(shè)角色 職 責(zé)簡(jiǎn)述 7 機(jī)構(gòu)過(guò)程改進(jìn)角色 軟件工程過(guò)程組 （ SEPG） （ 1）制定適合于本機(jī)構(gòu)的過(guò)程規(guī)范。 表 11 精簡(jiǎn) 過(guò)程域的目的 5 精簡(jiǎn)模型 文檔結(jié)構(gòu)與規(guī)范細(xì)分 精簡(jiǎn)模型 的文檔結(jié)構(gòu)如圖 12 所示， SPP 包含 17 個(gè)過(guò)程域 ， 規(guī)范細(xì) 分如表 12 所示。 配置管理是對(duì)工作成果的一種有效保護(hù)。 系統(tǒng)測(cè)試 對(duì)最終系統(tǒng)進(jìn)行全面的測(cè)試，確保最終系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計(jì)。 技術(shù)預(yù)研 在立項(xiàng)之后到開發(fā)工作完成之前的時(shí)間內(nèi)，對(duì)項(xiàng)目將采用的關(guān)鍵技術(shù)提前學(xué)習(xí)和研究，盡可能早地發(fā)現(xiàn)并解決開發(fā)過(guò)程中將會(huì)遇到的技術(shù)障礙。 項(xiàng)目監(jiān)控 周期性地跟蹤項(xiàng)目計(jì)劃的各種參數(shù)如進(jìn)度、工作量、費(fèi)用、資源等，不斷地了解項(xiàng)目的進(jìn)展情況，以便當(dāng)項(xiàng)目實(shí)際進(jìn)展顯著偏離計(jì)劃時(shí)能夠及時(shí)采取糾正措施。 項(xiàng)目管理過(guò)程域 目的 立項(xiàng)管理 采納符合機(jī)構(gòu)最大利益的立項(xiàng)建 議，通過(guò)立項(xiàng)管理使該建議成為正式的項(xiàng)目。 二、容易裁剪與擴(kuò)充 精簡(jiǎn) 模型的三類過(guò)程貫穿了產(chǎn)品的整個(gè)生命周期， 17 個(gè)最常見的過(guò)程域都合理地安排在產(chǎn)品生命周期中的某些階段。 項(xiàng)目管理過(guò)程包含 6 個(gè)過(guò)程域，分別為： ? 立項(xiàng)管理 ? 結(jié)項(xiàng)管理 ? 項(xiàng)目規(guī)劃 ? 項(xiàng)目監(jiān)控 ? 風(fēng)險(xiǎn)管理 ? 需求管理 項(xiàng)目研發(fā)過(guò)程包含 7 個(gè)過(guò)程域，分別 為： ? 需求開發(fā) ? 技術(shù)預(yù)研 ? 系統(tǒng)設(shè)計(jì) ? 實(shí)現(xiàn)與測(cè)試 ? 系統(tǒng)測(cè)試 ? 客戶驗(yàn)收 ? 技術(shù)評(píng)審 機(jī)構(gòu)支撐過(guò)程包含 4 個(gè)過(guò)程域，分別為： ? 配置管理 ? 質(zhì)量保證 ? 培訓(xùn)管理 ? 服務(wù)與維護(hù) 精簡(jiǎn) 模型如圖 11 所示。 0 軟件 研發(fā)管理制度 文件狀態(tài)： [√ ] 草稿 [ ] 正式發(fā)布 [ ] 正在修改 文件標(biāo)識(shí)： LolaageSoftwarePM 當(dāng)前版本： 作 者： 宋孝光 完成日期： 2020/3/27 1 版本 /狀態(tài) 作者 參與者 修改日期 備注 宋孝光 2020/3/26 第一版草稿 宋孝光 2020/3/27 整理目錄 2 目錄 1 軟件研發(fā)制度綜述 ...................................................................................................................................... 4 精簡(jiǎn)模型 ..................................