見。造成這樣的結(jié)果就是由于沒有控制和管理好項目的范圍?？梢婍椖康娜s束中范圍的影響起到關(guān)鍵作用。

一般來說，在啟動軟件項目初期，客戶就應(yīng)該提出一個相對確定的項目范圍，為項目的實(shí)施提供一個牢固的前提和框架，同時也是為后期的項目管理劃出一個明晰的“圈”，所有項目活動的開展，包括項目成本、質(zhì)量和時間的控制也應(yīng)該在此范圍內(nèi)進(jìn)行。但是，在實(shí)際的操作過程中，這個“圈”的邊界有可能會出現(xiàn)模糊、擴(kuò)大的現(xiàn)象，甚至這些擴(kuò)大和模糊的部分會給項目帶來風(fēng)險。項目范圍（Scope）、時間（Time）、成本（Cost）、質(zhì)量（Quality）之間的關(guān)系模型如下圖所示。

　　如果項目范圍即既定的面積S不變，成本C、質(zhì)量Q、時間T就可以在一個固定的S的邊界限制下給出一個約束的關(guān)系模型Cost=f(Quality,Time,Scope)。但是，如果S的值并不固定，就如上圖所示出現(xiàn)邊界模糊或者向外擴(kuò)展時， C、Q、T就失去可依賴的邊界限制，其之間的約束關(guān)系就會變得復(fù)雜。因此，我們在對項目范圍進(jìn)行控制時，一是要保證項目初期的S是準(zhǔn)確可靠的，盡量減少邊界的模糊性；二是要保證項目實(shí)施過程中S的穩(wěn)定，盡量避免擴(kuò)大化，或是說讓擴(kuò)大化受到合理的控制。

　　范圍變更控制流程分析　　

　　范圍變更控制是指對有關(guān)項目范圍的變更實(shí)施控制。主要的過程輸出是范圍變更、糾正行動與教訓(xùn)總結(jié)。

　　一個項目的范圍計劃可能制訂的非常好，但是想不出現(xiàn)任何改變幾乎是不可能的，因此變更是不可避免的，關(guān)鍵問題是如何對變更進(jìn)行有效的控制。項目經(jīng)理和項目小組必須意識到范圍變更本身并沒有什么不對，事實(shí)上很多時候這會使系統(tǒng)更健壯、更實(shí)用?？蛻敉ǔ２荒芤婚_始就確定所有需求，而且情況會隨時間而變化，如果不能包容變更，那么最終的軟件系統(tǒng)可能就達(dá)不到應(yīng)有的價值。但是如果變更失控，后果也非常嚴(yán)重，甚至于導(dǎo)致整個項目的失敗。

　　變更控制的目的不是控制變更的發(fā)生，而是對變更進(jìn)行管理，確保變更有序進(jìn)行。為執(zhí)行變更控制，必須建立有效的范圍變更流程，它對管好項目至關(guān)重要。變更控制流程主要包括四個關(guān)鍵控制點(diǎn)：授權(quán)、審核、評估、確認(rèn)。在變更過程中要跟蹤和驗(yàn)證，確保變更被正確執(zhí)行。范圍變更控制流程下圖所示。

　　提交變更請求：項目的任何涉眾均可提交變更請求。通過將變更請求狀態(tài)設(shè)置為已提交，變更請求被記錄到變更請求追蹤系統(tǒng)中并放置到變更控制委員會（CCB）復(fù)審隊列中。

　　復(fù)審變更請求：此活動的作用是復(fù)審已提交的變更請求。在 CCB 復(fù)審會議中對變更請求的內(nèi)容進(jìn)行初始復(fù)審，以確定它是否為有效請求。如果是，則基于小組所確定的優(yōu)先級、時間表、資源、努力程度、風(fēng)險、嚴(yán)重性以及其他任何相關(guān)的標(biāo)準(zhǔn)，判定該變更是在當(dāng)前發(fā)布版的范圍之內(nèi)還是范圍之外。

　　確認(rèn)重復(fù)或拒絕：如果懷疑某個變更請求為重復(fù)的請求或已拒絕的無效請求（例如，由于操作符錯誤、無法重現(xiàn)、工作方式等），將指定一個 CCB 代表來確認(rèn)重復(fù)或已拒絕的變更請求。如果需要的話，該代表還從提交者處收集更多信息。

　　更新變更請求：如果評估變更請求時需要更多的信息，或者如果變更請求在流程中的某個時刻遭到拒絕，那么將通知提交者，并用新信息更新變更請求。然后將已更新的變更請求重新提交給 CCB 復(fù)審隊列，以考慮新的數(shù)據(jù)。

　　安排和分配工作：一旦變更請求被置為已打開，項目經(jīng)理就將根據(jù)請求的類型把工作分配給合適的角色，并對項目時間表做必要的更新。

　　進(jìn)行變