【正文】 性循環(huán)不被控制的變更是項(xiàng)目陷入混亂、不能按進(jìn)度執(zhí)行或軟件質(zhì)量低劣的共同原因。為了使開發(fā)組織能夠嚴(yán)格控制軟件項(xiàng)目應(yīng)確保以下事項(xiàng)：? 應(yīng)仔細(xì)評估已建議的變更。? 挑選合適的人選對變更做出決定。? 變更應(yīng)及時(shí)通知所有涉及的人員。? 項(xiàng)目要按一定的程序來采納需求變更。變更控制過程并不是給變更設(shè)置障礙。相反地，它是一個(gè)渠道和過濾器，通過它可以確保采納最合適的變更，使變更產(chǎn)生的負(fù)面影響減少到最小。變更過程應(yīng)該做成文檔，盡可能簡單，當(dāng)然首要的是有效性。在科學(xué)的、經(jīng)驗(yàn)的、用戶和項(xiàng)目組都能接受的項(xiàng)目預(yù)期時(shí)間內(nèi)，項(xiàng)目組能比較充分地獲取用戶的需求的前提下，需求變更管理可以使需求的意外變化，在可控、可接受的范圍內(nèi)，使項(xiàng)目計(jì)劃、成本、質(zhì)量不受到負(fù)面的影響，或使影響在可容忍的范圍內(nèi)。這就是項(xiàng)目經(jīng)理需求變更管理的職責(zé)和目標(biāo)。項(xiàng)目管理應(yīng)該達(dá)成一個(gè)策略，它描述了如何處理需求變更。策略具有現(xiàn)實(shí)可行性，要被加強(qiáng)才有意義。下述需求變更的策略是有用的：? 所有需求變更必須遵循的過程，按照此過程，如果一個(gè)變更需求未被采納，則其后過程不再予以考慮。? 對于未獲批準(zhǔn)的變更，除可行性論證之外，不應(yīng)再做其它設(shè)計(jì)和實(shí)現(xiàn)工作。? 簡單請求一個(gè)變更不能保證能實(shí)現(xiàn)變更，要由項(xiàng)目變更控制委員會（ C C B）決定實(shí)現(xiàn)哪些變更。? 項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者應(yīng)該能夠了解變更數(shù)據(jù)庫的內(nèi)容。? 絕不能從數(shù)據(jù)庫中刪除或修改變更請求的原始文檔。? 每一個(gè)集成的需求變更必須能跟蹤到一個(gè)經(jīng)核準(zhǔn)的變更請求。當(dāng)然，大的變更會對項(xiàng)目造成顯著的影響，而小的變更就可能不會有影響。原則上，應(yīng)該通過變更控制過程來處理所有的變更。但實(shí)踐中，可以將一些具體的需求決定權(quán)交給開發(fā)人員來決定。但只要變更涉及兩個(gè)人或兩個(gè)人以上都應(yīng)該通過控制過程來處理。. 需求變更控制活動（1）確定需求變更控制過程： 確定需求變更的選擇、分析、決策、記錄的過程，所有需求的變更，都要在選擇、分析、決策、記錄環(huán)節(jié)上，受到機(jī)制和責(zé)任的保證。（2）建立需求變更控制委員會： 組織公司、項(xiàng)目組內(nèi)部和用戶利益和風(fēng)險(xiǎn)承擔(dān)人員，成立需求變更控制委員會，由他們來決定要變更哪些需求，是否在項(xiàng)目范圍之內(nèi)（包括：項(xiàng)目范圍和合同范圍。因?yàn)橛袝r(shí)，在項(xiàng)目范圍，但不在合同范圍，需要項(xiàng)目進(jìn)行二期合同開發(fā)），評估變更的波及，最后決定變更是可以接受，還是放棄。對變更的需求設(shè)置優(yōu)先級、制定版本規(guī)定等。（3）進(jìn)行需求變更影響分析： 波及分析有利于對需求變更要求，進(jìn)行更深入、精確的理解，幫助變更控制委員會做出科學(xué)的決策。波及分析還可以幫助項(xiàng)目組對現(xiàn)有系統(tǒng)做出合理的、有前瞻性的調(diào)整，使面對日后新的需求變更，有充足的技術(shù)準(zhǔn)備。 波及分析完全依賴于需求的跟蹤能力。沒有需求形式化記錄、沒有需求跟蹤鏈，就沒有波及分析的可能。如果有，也是主觀的、非定量的。由此對項(xiàng)目計(jì)劃、成本、質(zhì)量控制的影響分析，其可信度是有疑問的。 系統(tǒng)分析師和架構(gòu)師應(yīng)評估變更對系統(tǒng)技術(shù)實(shí)現(xiàn)的影響。 項(xiàng)目經(jīng)理應(yīng)根據(jù)新需求，明確相關(guān)任務(wù)，評估新的工作量和相應(yīng)的要求變化。新需求不但導(dǎo)致分析、編碼、測試的工作量增加，項(xiàng)目管理有關(guān)的各環(huán)節(jié)（需求管理、計(jì)劃管理、成本管理、配置管理、質(zhì)量管理等）都會有所變化。 在需求變更評估分析中，也要做需求穩(wěn)定性評估。頻繁地需求變更，應(yīng)該超出了需求變化的范圍。項(xiàng)目經(jīng)理要考慮項(xiàng)目組織管理方面，是不是發(fā)生了什么問題。 （4）跟蹤所有受需求變更影響的工作產(chǎn)品： 當(dāng)確定某一需求發(fā)生變更時(shí)，根據(jù)需求跟蹤矩陣，找到與變更需求有關(guān)的各層、各環(huán)節(jié)需求項(xiàng)。例如：涉及需求項(xiàng)的設(shè)計(jì)模型、代碼模塊、測試用例等。這些部分全部必須做相應(yīng)的修改。依據(jù)需求跟蹤矩陣，可以完整地追蹤到需求變更所影響到的所有地方，可以不會發(fā)生遺漏，而產(chǎn)生系統(tǒng)BUG，或產(chǎn)品缺陷。甚至包括對軟件產(chǎn)品本身以外的影響，如：因需求變更，版本控制沒有相應(yīng)的記錄、產(chǎn)品使用手冊沒有做相應(yīng)修改等。 因?yàn)樾枨笞兏?，需求狀態(tài)記錄應(yīng)相應(yīng)地發(fā)生變化。每一條記錄，反映了需求的現(xiàn)實(shí)情況。（5） 調(diào)整需求基線： 需求變化以后，需求變更控制委員會要決定是否調(diào)整需求基線。新需求是反映為基線的調(diào)整，還是版本的變化。 基線是產(chǎn)品的標(biāo)準(zhǔn)，基線變化可以作為產(chǎn)品標(biāo)準(zhǔn)的變化，也可以理解為將發(fā)行一個(gè)新版本的產(chǎn)品。 但是，版本并不一定就是新產(chǎn)品。因?yàn)?，?dāng)產(chǎn)品面對不同地區(qū)、不同用戶群的時(shí)候，也可以確定不同的版本。因此，需求變更控制委員會要做的工作，是對新需求，決定是全面升版，還是局部更改。是基線變化，還是個(gè)別版本變化。有時(shí)，這是一個(gè)比較難于做出的決定，他依賴于對新需求的分析，評估它對市場、用戶和產(chǎn)品本身的影響。 （6）維護(hù)需求變更記錄和文檔： 決定變更基線或提升版本以后，就要做好記錄，修改相應(yīng)的文檔。變更記錄要記錄變更原因、變更內(nèi)容、變更影響、變更實(shí)現(xiàn)過程、其他相應(yīng)變更等。變更記錄越完整，對于追溯，甚至以后可能發(fā)生的回退，就越有幫助。 有一些版本控制工具，可以幫助項(xiàng)目經(jīng)理來做到記錄相應(yīng)的信息。 . 需求變更控制委員會軟件開發(fā)活動中公認(rèn)變更控制委員會或C C B（有時(shí)也稱為結(jié)構(gòu)控制委員會）為最好的策略之一。變更控制委員會可以由一個(gè)小組擔(dān)任，也可由多個(gè)不同的組擔(dān)任，負(fù)責(zé)做出決定究竟將哪一些已建議需求變更或新產(chǎn)品特性付諸應(yīng)用。典型的變更控制委員會同樣決定在哪一些版本中糾正哪一些錯誤。許多項(xiàng)目已經(jīng)有負(fù)責(zé)變更決策的人員，而正式組建變更控制委員、制定操作步驟會使他們更有效地工作。廣義上，變更控制委員會對項(xiàng)目中任何基線工作產(chǎn)品的變更都可做出決定，需求變更文檔僅是其中之一。大項(xiàng)目可以有幾級控制委員會，有些負(fù)責(zé)業(yè)務(wù)決策（例如需求變更），另一些負(fù)責(zé)技術(shù)決策。有些變更控制委員會可以獨(dú)立做出決策，而有些只是負(fù)責(zé)決策的建議工作。高級變更控制委員會做出的決策對計(jì)劃的影響應(yīng)比低級的大。小項(xiàng)目中，只需一兩個(gè)人就可做出所有決策?？吹健白兏刂莆瘑T會”這個(gè)詞組，會使某些人想到一群高高在上而且浪費(fèi)時(shí)間的官僚分子。然而，有變更控制委員會的企業(yè)結(jié)構(gòu)可以幫助很好地管理項(xiàng)目，哪怕是一個(gè)小項(xiàng)目。這個(gè)結(jié)構(gòu)并不浪費(fèi)時(shí)間或是累贅，相反會很有效率。一個(gè)有效率的變更控制委員會定期地考慮每個(gè)變更請求，并且基于對由此帶來的影響和獲益做出及時(shí)的決策。變更控制委員會只要能讓合適的人做正確的事就足夠了，不必追求大而全。一、變更控制委員會的組成變更控制委員會的成員應(yīng)能代表變更涉及的團(tuán)體。變更控制委員會可能包括如下方面的代表：? 產(chǎn)品或計(jì)劃管理部門。? 項(xiàng)目管理部門。? 開發(fā)部門。? 測試或質(zhì)量保證部門。? 市場部或客戶代表。? 制作用戶文檔的部門。? 技術(shù)支持部門。? 幫助桌面或用戶支持熱線部門。? 配置管理部門。對于小項(xiàng)目只需幾個(gè)人充當(dāng)其中的一些角色就可以，并不一定要面面俱到。組建包含軟、硬件兩方面的項(xiàng)目的變更控制委員會時(shí)，也要包括來自硬件工程、系統(tǒng)工程、制造部門或者硬件質(zhì)量保證和配置管理的代表。建立變更控制委員會在保證權(quán)威性的前提下應(yīng)盡可能精簡人員。大團(tuán)隊(duì)可能很難碰頭和做出決策。確保變更控制委員成員明確擔(dān)負(fù)的責(zé)任。有時(shí)為了獲得足夠的技術(shù)和業(yè)務(wù)信息，也可以邀請其他人員參加會議。二、變更控制委員會總則設(shè)立變更控制委員會的第一步是寫一個(gè)總則，描述變更控制委員會的目的、授權(quán)范圍、成員構(gòu)成、做出決策的過程及操作步驟。總則也應(yīng)該說明舉行會議的頻度和事由。管理范圍是指該委員會能做什么樣的決策，及哪種決策應(yīng)上報(bào)到高一級的委員會。1. 制定決策制定決策過程（程式）的描述應(yīng)確認(rèn)：? 變更控制委員會必須到會的人數(shù)或作出有效決定必須出席的人員數(shù)。? 決策的方法，例如：投票、一致通過或其它機(jī)制。? 變更控制委員會主席是否可以否決C C B的集體決定。變更控制委員會應(yīng)該對每個(gè)變更權(quán)衡利弊后做出決定。“利”包括節(jié)省的資金或額外的收入、增強(qiáng)的客戶滿意度、競爭優(yōu)勢、減少上市時(shí)間?！氨住笔侵附邮茏兏螽a(chǎn)生的負(fù)面影響，包括增加的開發(fā)費(fèi)用、推遲的交付日期、產(chǎn)品質(zhì)量的下降、減少的功能、用戶不滿意。如果估計(jì)的費(fèi)用超過了本級變更控制委員會的管理范圍，上報(bào)到高一級的委員會，否則用制訂的決策程式來對變更做出決定。2. 交流情況一旦變更控制委員會做出決策時(shí)，指派的人員應(yīng)及時(shí)更新數(shù)據(jù)庫中請求的狀態(tài)。有的工具可以自動通過電子郵件來通知相關(guān)人員。若沒有這樣的工具，就應(yīng)該人工通知，以保證他們能充分處理變更。3. 重新協(xié)商約定變更總是有代價(jià)的。即使拒絕的變更也因?yàn)闆Q策行為（提交、評估、決策）而耗費(fèi)了資源。變更對新的產(chǎn)品特性會有很大的影響。向一個(gè)工程項(xiàng)目中增加很多功能，又要求在原先確定的進(jìn)度計(jì)劃、人員安排、資金預(yù)算和質(zhì)量要求限制內(nèi)完成整個(gè)項(xiàng)目是不現(xiàn)實(shí)的。當(dāng)工程項(xiàng)目接受了重要的需求變更時(shí)，為了適應(yīng)變更情況要與管理部門和客戶重新協(xié)商約定。協(xié)商的內(nèi)容可能包括：推遲“交貨”時(shí)間、要求增加人手、推遲實(shí)現(xiàn)尚未實(shí)現(xiàn)的較低優(yōu)先級的需求，或者質(zhì)量上進(jìn)行折衷。要是不能獲得一些約定的調(diào)整，應(yīng)該把面臨的威脅寫進(jìn)風(fēng)險(xiǎn)管理計(jì)劃中，這樣當(dāng)項(xiàng)目沒有達(dá)到期望的結(jié)果時(shí)就不會有人驚奇了。. 需求變更波及分析對于項(xiàng)目組來說，一個(gè)新的需求提出來以后，這個(gè)需求如果接受，可能對系統(tǒng)造成多大的影響？系統(tǒng)結(jié)構(gòu)上的、數(shù)據(jù)結(jié)構(gòu)上的、涉及的模塊、版本上的變更影響有多大？需求變更在技術(shù)上有潛伏性，在工程上，也表現(xiàn)為不可預(yù)知性。工作量不可預(yù)知、成本不可預(yù)知。項(xiàng)目經(jīng)理往往受市場人員的壓力，對用戶宣稱“免費(fèi)維護(hù)”，但在項(xiàng)目組內(nèi)部，對于需求變更的成本，甚至可能是“巨大”的。 需求波及分析是軟件項(xiàng)目管理的需求管理比較重要的組成部分，在需求變更決策前，通過波及分析，可以達(dá)到精確理解需求、評估系統(tǒng)對需求變更要求的接納程度、變更的代價(jià)、變更對系統(tǒng)總體架構(gòu)、甚至產(chǎn)品發(fā)展的影響等。這樣的分析，對需求變更委員會做出變更批準(zhǔn)還是放棄的決策，具有重要的意義。一旦變更控制委員會批準(zhǔn)需求變更的要求，就能比較清晰地知道相應(yīng)變更的內(nèi)容、工作范圍、需要的時(shí)間等。需求變更波及分析也是保證項(xiàng)目組在需求變更以后，可以做到“在計(jì)劃、成本、質(zhì)量（不是降低質(zhì)量標(biāo)準(zhǔn)為代價(jià)）范圍的變更”。 一、需求變更波及的內(nèi)部分析：（1）所有涉及到的輸入界面有關(guān)部分；（2）所有涉及到的報(bào)表等輸出界面有關(guān)部分；（3）所有涉及到的外部接口部分；（4）所有涉及到的內(nèi)部接口部分；（5）所有涉及到的數(shù)據(jù)庫表結(jié)構(gòu)；（6）所有涉及到的系統(tǒng)數(shù)據(jù)定義；（7）所有涉及到的公用模塊定義、公用子程序庫、控件庫；（8）所有涉及到的系統(tǒng)常量、宏定義；（9）所有涉及到的已經(jīng)實(shí)現(xiàn)的代碼；（10）所有涉及到的已經(jīng)完成的單元、集成測試；（11）所有涉及到的已經(jīng)編寫完成的用戶文檔（使用手冊、維護(hù)手冊）；（12）所有涉及到的已經(jīng)編寫完成的幫助文件、培訓(xùn)教材；（13）所有涉及到的第三方軟件和工具；（14）所有涉及到的項(xiàng)目管理有關(guān)的需求管理、計(jì)劃管理、成本管理、配置管理、質(zhì)量管理有關(guān)的數(shù)據(jù)庫、文檔庫；（15）所有涉及到的其他應(yīng)該檢查的部分；二、需求變更波及的外部分析：（1）變更是否與基線（已經(jīng)實(shí)現(xiàn)的部分）相沖突（是否是基線內(nèi)的）；（2） 變更是否存在與雖未實(shí)現(xiàn)，但已經(jīng)決定的需求相沖突；（3）不采納變更是否會有技術(shù)上的風(fēng)險(xiǎn)，或者采納變更會有什么技術(shù)上的風(fēng)險(xiǎn)；（4）不采納變更是否會有業(yè)務(wù)上的風(fēng)險(xiǎn)，或者采納變更會有什么業(yè)務(wù)上的風(fēng)險(xiǎn)；（5）不采納變更是否會導(dǎo)致質(zhì)量降低，或者采納變更會有多大的質(zhì)量提升；（6） 變更在技術(shù)實(shí)現(xiàn)上是可行的嗎？（7） 采納變更是否會導(dǎo)致用戶進(jìn)一步提出更多不合理的要求？（8）采納變更對現(xiàn)有項(xiàng)目組在人力、技術(shù)、工具等方面，是否能夠承受，增加資源是否可能；（9）采納變更的需求變更量的估計(jì)是多少？（以單元為單位、以時(shí)間為單位、以成本為單位）（10）采納變更后，雖然進(jìn)行了合理安排，包括采用關(guān)鍵路徑法，調(diào)整進(jìn)度安排，但最后仍然對進(jìn)度的影響是多少？（11）采納變更以后使多少實(shí)際已經(jīng)開發(fā)完成的單元被廢棄，相關(guān)的工作量是多少？（12）采納變更以后使多少實(shí)際已經(jīng)開發(fā)所用的單元時(shí)間被浪費(fèi)，相關(guān)的比率是多少？（13） 變更對市場、銷售、培訓(xùn)、維護(hù)的影響有多大？三、需求變更波及分析報(bào)告. 需求穩(wěn)定性評估為了了解需求的穩(wěn)定性情況，可以對需求的穩(wěn)定性，進(jìn)行評估。評估的基本過程是：（1）統(tǒng)計(jì)基線需求的數(shù)量：通過需求數(shù)據(jù)庫，可以按最底層的需求項(xiàng)為單位，統(tǒng)計(jì)需求的數(shù)量。因?yàn)槿魏紊蠈有枨蟮淖兓?，最終要反映到最底層需求項(xiàng)的變化。比較差的設(shè)計(jì)，可能使簡單的需求變化，帶來巨大的系統(tǒng)元素的修改。（2）統(tǒng)計(jì)每月/每周基線需求項(xiàng)的增加、刪除、修改的數(shù)量。如同需求基線一樣，根據(jù)項(xiàng)目的大小和歷史經(jīng)驗(yàn)，項(xiàng)目經(jīng)理也要定一個(gè)穩(wěn)定性基線，當(dāng)需求變化量在一定時(shí)間內(nèi)超過了穩(wěn)定性基線，項(xiàng)目經(jīng)理就要分析原因，采取措施。（3）需求變化既可能來自組織外部，也可能來自項(xiàng)目組內(nèi)部。對需求不穩(wěn)定的因素和來源進(jìn)行分析，做出的評估，是獲得需求穩(wěn)定的好辦法。. 需求跟蹤為了更好的管理需求狀態(tài)、精確化評估變更影響，必然要做好需求跟蹤。需要說明的是需求跟蹤會帶來不錯的效益，但需付出較大的工作量。需求跟蹤包括編制每個(gè)需求同系統(tǒng)元素之間的聯(lián)系文檔。這些元素包括別的需求、體系結(jié)構(gòu)、其他設(shè)計(jì)部件、源代碼模塊、測試、幫助文件、文檔等。跟蹤能力信息使變更影響分析十分便利，有利于確認(rèn)和評估實(shí)現(xiàn)某個(gè)建議的需求變更所必須的工作。. 需求跟蹤目的需求跟蹤提供了一個(gè)表明與合同或說明一致的方法。更進(jìn)一步，需求跟蹤可以改善產(chǎn)品質(zhì)量，降低維護(hù)成本，而且很容易實(shí)現(xiàn)重用。需求跟蹤是個(gè)要求手工操作且勞動強(qiáng)度很大的任務(wù)，要求組織提供支持。隨著系統(tǒng)開發(fā)的進(jìn)行和維護(hù)的執(zhí)行，要保持關(guān)聯(lián)鏈信息與實(shí)際一致。跟蹤能力信息一旦過時(shí)，可能再也不會重建它了。由于這些原因，應(yīng)該正確使用需求跟蹤能力。下面是在項(xiàng)目中使用需求跟蹤能力的一些好處：? 審核 跟蹤能力信息可以幫助審核確保所有需求被應(yīng)用。? 變更影響分析 跟蹤能力信息在增、刪、改需求時(shí)可以確保不忽略每個(gè)受到影響的系統(tǒng)元素。? 維護(hù) 可靠的跟蹤能力信息使得維