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