【正文】 A 。 需求變更控制流程 需求的變更是不可避免的，因此如何有效控制需求的變化對(duì)于項(xiàng)目成功至關(guān)重要。需求不穩(wěn)定，是項(xiàng)目組的“危險(xiǎn)警報(bào)”。這一點(diǎn)，將在以后 《 配置管理 》 和 《 質(zhì)量管理 》 中，再做詳細(xì)討論。 （ 3）需求變化既可能來(lái)自組織外部，也可能來(lái)自項(xiàng)目組內(nèi)部。 （ 2）統(tǒng)計(jì)每月 /每周基線需求項(xiàng)的增加、刪除、修改的數(shù)量。因?yàn)槿魏紊蠈有枨蟮淖兓罱K要反映到最底層需求項(xiàng)的變化。 需求變更 —— 變更波及的外部分析 （ 1）變更是否與基線（已經(jīng)實(shí)現(xiàn)的部分）相沖突（是否是基線內(nèi)的）； （ 2） 變更是否存在與雖未實(shí)現(xiàn)，但已經(jīng)決定的需求相沖突； （ 3）不采納變更是否會(huì)有技術(shù)上的風(fēng)險(xiǎn)，或者采納變更會(huì)有什么技術(shù)上的風(fēng)險(xiǎn)； （ 4）不采納變更是否會(huì)有業(yè)務(wù)上的風(fēng)險(xiǎn)，或者采納變更會(huì)有什么業(yè)務(wù)上的風(fēng)險(xiǎn)； （ 5）不采納變更是否會(huì)導(dǎo)致質(zhì)量降低，或者采納變更會(huì)有多大的質(zhì)量提升； （ 6） 變更在技術(shù)實(shí)現(xiàn)上是可行的嗎？ （ 7） 采納變更是否會(huì)導(dǎo)致用戶進(jìn)一步提出更多不合理的要求？ （ 8）采納變更對(duì)現(xiàn)有項(xiàng)目組在人力、技術(shù)、工具等方面，是否能夠承受，增加資 源是否可能； （ 9）采納變更的需求變更量的估計(jì)是多少？（以單元為單位、以時(shí)間為單位、以 成本為單位） （ 10）采納變更后，雖然進(jìn)行了合理安排，包括采用關(guān)鍵路徑法，調(diào)整進(jìn)度安 排，但最后仍然對(duì)進(jìn)度的影響是多少？ （ 11）采納變更以后使多少實(shí)際已經(jīng)開發(fā)完成的單元被廢棄，相關(guān)的工作量是多 少？ （ 12）采納變更以后使多少實(shí)際已經(jīng)開發(fā)所用的單元時(shí)間被浪費(fèi)，相關(guān)的比率是 多少？ （ 13） 變更對(duì)市場(chǎng)、銷售、培訓(xùn)、維護(hù)的影響有多大？ 需求變更 —— 需求變更波及分析報(bào)告 標(biāo)題： 變更描述： 分析人 日期： 優(yōu)先級(jí)評(píng)定： 相關(guān)收益： 相關(guān)代價(jià)： 相關(guān)成本： 相關(guān)風(fēng)險(xiǎn)： 增加耗時(shí)： 增加人力： 對(duì)進(jìn)度的影響： 對(duì)成本的影響： 對(duì)質(zhì)量的影響： 直接影響的其他部分： 間接影響的其他部分： 導(dǎo)致的計(jì)劃變更： 導(dǎo)致的成本變更： 其他影響： 假定前提： 條件與約束： 評(píng)審人意見： 需求穩(wěn)定性評(píng)估 為了了解需求的穩(wěn)定性情況，可以對(duì)需求的穩(wěn)定性，進(jìn)行評(píng)估。需求變更波及分析也是保證項(xiàng)目組在需求變更以后，可以做到“在計(jì)劃、成本、質(zhì)量（不是降低質(zhì)量標(biāo)準(zhǔn)為代價(jià)）范圍的變更”。 這樣的分析，對(duì)需求變更委員會(huì)做出變更批準(zhǔn)還是放棄的決策，具有重要的意義。這種不理智的“反差”，正好說(shuō)明了我們軟件項(xiàng)目管理的水平，是處在原始和粗放的狀態(tài)。工作量不可預(yù)知、成本不可預(yù)知。 有一些版本控制工具，可以幫助項(xiàng)目經(jīng)理來(lái)做到記錄相應(yīng)的信息。變更記錄要記錄變更原因、變更內(nèi)容、變更影響、變更實(shí)現(xiàn)過(guò)程、其他相應(yīng)變更等。有時(shí)，這是一個(gè)比較難于做出的決定，他依賴于對(duì)新需求的分析，評(píng)估它對(duì)市場(chǎng)、用戶和產(chǎn)品本身的影響。因此，需求變更控制委員會(huì)要做的工作，是對(duì)新需求，決定是全面升版，還是局部更改。 需求變更 —— 6大需求變更控制活動(dòng) 但是，版本并不一定就是新產(chǎn)品。新需求是反映為基線的調(diào)整，還是版本的變化。每一條記錄，反映了需求的現(xiàn)實(shí)情況。甚至包括對(duì)軟件產(chǎn)品本身以外的影響，如：因需求變更，版本控制沒(méi)有相應(yīng)的記錄、產(chǎn)品使用手冊(cè)沒(méi)有做相應(yīng)修改等。這些部分全部必須做相應(yīng)的修改。 需求變更 —— 6大需求變更控制活動(dòng) （ 4）跟蹤所有受需求變更影響的工作產(chǎn)品： 當(dāng)確定某一需求發(fā)生變更時(shí)，根據(jù)需求跟蹤矩陣，找到與變更需求有關(guān)的各層、各環(huán)節(jié)需求項(xiàng)。頻繁地需求變更，應(yīng)該超出了需求變化的范圍。新需求不但導(dǎo)致分析、編碼、測(cè)試的工作量增加，項(xiàng)目管理有關(guān)的各環(huán)節(jié)（需求管理、計(jì)劃管理、成本管理、配置管理、質(zhì)量管理等）都會(huì)有所變化。 系統(tǒng)分析師和架構(gòu)師應(yīng)評(píng)估變更對(duì)系統(tǒng)技術(shù)實(shí)現(xiàn)的影響。如果有，也是主觀的、非定量的。 波及分析完全依賴于需求的跟蹤能力。 需求變更 —— 6大需求變更控制活動(dòng) （ 3）進(jìn)行需求變更影響分析： 波及分析有利于對(duì)需求變更要求，進(jìn)行更深入、精確的理解，幫助變更控制委員會(huì)做出科學(xué)的決策。因?yàn)橛袝r(shí)，在項(xiàng)目范圍，但不在合同范圍，需要項(xiàng)目進(jìn)行二期合同開發(fā)），評(píng)估變更的波及，最后決定變更是可以接受，還是放棄。 需求變更控制活動(dòng) 6大需求變更控制活動(dòng) （ 1）確定需求變更控制過(guò)程： 確定需求變更的選擇、分析、決策、記錄的過(guò)程，所有需求的變更，都要在選擇、分析、決策、記錄環(huán)節(jié)上，受到機(jī)制和責(zé)任的保證。例如建議在開發(fā)該產(chǎn)品新版本時(shí)修改需求。解決這個(gè)問(wèn)題最好的辦法是事先建立“游戲規(guī)則”： – 開發(fā)方與客戶方達(dá)成“事不過(guò)三”的約定（符合中國(guó)人的習(xí)慣），即允許客戶變更三次需求；如果客戶第四此變更需求，開發(fā)方有權(quán)拒絕，除非客戶愿意補(bǔ)償開發(fā)方的損失。 ? 需求變更控制過(guò)程中最難辦的事情是莫過(guò)于“拒絕客戶提出的需求變更請(qǐng)求”。 ? 需求變更控制的目的： 如果需求變更帶來(lái)的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。對(duì)項(xiàng)目開發(fā)小組而言， 變更需求意味著要調(diào)整資源、重新分配任務(wù)、修改前期工作成果等，開發(fā)小組要為此付出較重的代價(jià) 。 – 市場(chǎng)發(fā)生了變化，原先的需求文檔可能跟不上當(dāng)前的市場(chǎng)需求，因此要變更需求。 ? 需求發(fā)生變更的起因主要有： – 隨著項(xiàng)目的進(jìn)展，人們（包括開發(fā)方和客戶方）對(duì)需求的了解越來(lái)越深入。不論采用何種跟蹤方式，都要建立與維護(hù)需求跟蹤矩陣（即表格）。 正向跟蹤和逆向跟蹤合稱為 “雙向跟蹤” 。 用 例系 統(tǒng) 需 求系 統(tǒng) 測(cè) 試用 例項(xiàng) 目 計(jì) 劃結(jié) 構(gòu) / 數(shù) 據(jù)流 圖 類 圖代 碼 實(shí) 現(xiàn)集 成 測(cè) 試用 例詳 細(xì) 設(shè) 計(jì)單 元 測(cè) 試其 他 需 求軟 件 需 求硬 件 需 求追 溯 與 回 溯追 溯 與 回 溯追 溯 與 回 溯需求跟蹤 ? 正向跟蹤： 以用戶需求為切入點(diǎn)，檢查 《 用戶需求說(shuō)明書 》 或 《 需求規(guī)格說(shuō)明書 》 中的每個(gè)需求是否都能在后繼工作產(chǎn)品中找到對(duì)應(yīng)點(diǎn)。 開始被建議 被批準(zhǔn) 被實(shí)現(xiàn) 被交付被驗(yàn)證被丟棄被拒絕評(píng)審?fù)ㄟ^(guò)評(píng)審未通過(guò)設(shè)計(jì)完成編碼完成單元測(cè)試取消 取消集成測(cè)試完成用戶測(cè)試接收 需求狀態(tài)變化的追蹤 如果我們能夠做到軟件需求的定義 ， 那么 ， 通過(guò)跟蹤定義了的需求 ， 我們就能夠知道需求在實(shí)現(xiàn)過(guò)程中的具體實(shí)現(xiàn)細(xì)節(jié)與目標(biāo)的距離 。 項(xiàng)目階段里程碑是應(yīng)交付成果 ， 交付成果最主要的內(nèi)容 ，就是需求的實(shí)現(xiàn) 。 需求實(shí)現(xiàn)過(guò)程 —— 需求狀態(tài)變化 在需求狀態(tài)的變化中 ， 軟件項(xiàng)目經(jīng)理第一位需要關(guān)注的是那些被拒絕 、 被丟棄的需求 。 記錄下丟棄的原因和決定責(zé)任人 。 表明需求已經(jīng)被實(shí)現(xiàn) 。 被實(shí)現(xiàn) 已實(shí)現(xiàn)設(shè)計(jì) 、 編碼 、 單元測(cè)試 。 被拒絕 在一系列需求開發(fā)過(guò)程后 ， 該需求沒(méi)有被認(rèn)可 。從需求實(shí)現(xiàn)階段來(lái)看 ， 需求在這個(gè)階段 ， 仍然受各種因素的影響 ， 產(chǎn)生不可預(yù)料的變化 。 需求跟蹤 2. 需求的屬性 ? 創(chuàng)建需求的時(shí)間 ? 需求的版本號(hào) ? 創(chuàng)建需求的作者 ? 負(fù)責(zé)認(rèn)可該需求的人員 ? 需求狀態(tài) ? 需求的原因或根據(jù)（或信息的出處） ? 需求涉及的子系統(tǒng) ? 需求涉及的產(chǎn)品版本號(hào) ? …… 需求跟蹤 3. 需求狀態(tài) ? 已建議 —— 該需求已被有權(quán)提出需求的人建議 ? 已批準(zhǔn) —— 該需求已被分析，估計(jì)了其對(duì)項(xiàng)目余下部分的影響（包括成本和對(duì)項(xiàng)目其余部分的干擾），已有一個(gè)確定的產(chǎn)品版本號(hào)或編號(hào)，軟件開發(fā)團(tuán)隊(duì)已同意實(shí)現(xiàn)該項(xiàng)需求 ? 已實(shí)現(xiàn) —— 使用所選擇的方法已驗(yàn)證了實(shí)現(xiàn)的需求，例如測(cè)試和檢測(cè)，審查該需求跟蹤與測(cè)試用例相符。 需求跟蹤 1. 需求的標(biāo)識(shí) 需求類型 需求 需求類型可以是： F=功能需求， D=數(shù)據(jù)需求， B=行為需求， I=接口需求； O=輸出需求。 現(xiàn)在我們知道了 ， 什么會(huì)被加到出錯(cuò)報(bào)告中 ， 但是出錯(cuò)報(bào)告是個(gè)什么樣子 ， 則留由設(shè)計(jì)人員決定 。 找一個(gè)自稱為 HTML的入門者 ， 看看能不能根據(jù)錯(cuò)誤報(bào)告快速解決錯(cuò)誤 ？ 試試這個(gè)： “ HTML分析器可以產(chǎn)生一個(gè)錯(cuò)誤報(bào)告 ， 錯(cuò)誤報(bào)告包含有在被分析文件中出錯(cuò)的