按照現代專案管理的概念，乙個專案的生命週期分為啟動、實施、收尾三個過程。需求變更的控制不應該只是專案實施過程考慮的事情，而是要分布在整個專案生命週期的全過程。為了將專案變更的影響降低到最小，就需要採用綜合變更控制方法。綜合變更控制主要內容有找出影響專案變更的因素、判斷專案變更範圍是否已經發生等。
進行綜合變更控制的主要依據是專案計畫、變更請求和提供了專案執行狀況資訊的績效報告。
(1)專案啟動階段的變更預防
對於任何專案，變更都無可避免，也無從逃避，只能積極應對，這個應對應該是從專案啟動的需求分析階段就開始了。對乙個需求分析做得很好的專案來說，基準檔案定義的範圍越詳細清晰，使用者跟專案經理扯皮的幌子就越少。如果需求沒做好，基準檔案裡的範圍含糊不清，被客戶抓住空子，往往要付出許多無謂的犧牲。如果需求做得好，文件清晰且又有客戶簽字，那麼後期客戶提出的變更就超出了合同範圍，需要另外收費。這個時候千萬不能手軟，這並非要刻意賺取客戶的錢財，而是不能讓客戶養成經常變更的習慣，否則後患無窮。相對於需求來說，什麼wbs、風險管理、計畫進度都是次要的，只要需求做好了就會一帆風順。
(2)專案實施階段的需求變更
成功專案和失敗專案的區別就在於專案的整個過程是否是可控的。專案經理應該樹立乙個理念——「需求變更是必然的、可控的、有益的」。專案實施階段的變更控制需要做的是分析變更請求，評估變更可能帶來的風險和修改基準檔案。控制需求漸變需要注意以下幾點：
需求一定要與投入有聯絡，如果需求變更的成本由開發方來承擔，則專案需求的變更就成為必然了。所以，在專案的開始，無論是開發方還是出資方都要明確這一條：需求變，軟體開發的投人也要變。
需求的變更要經過出資者的認可，這樣才會對需求的變更有成本的概念，能夠慎重地對待需求的變更。
小的需求變更也要經過正規的需求管理流程，否則會積少成多。在實踐中，人們往往不願意為小的需求變更去執行正規的需求管理過程，認為降低了開發效率，浪費了時間。但正是由於這種觀念才使需求逐漸變為不可控，最終導致專案的失敗。
精確的需求與範圍定義並不會阻止需求的變更。並非對需求定義得越細，就越能避免需求的漸變，這是兩個層面的問題。太細的需求定義對需求漸變沒有任何效果。因為需求的變化是永恆的，並非需求寫細了，它就不會變化了。
注意溝通的技巧。實際情況是使用者、開發者都認識到了上面的幾點間題，但是由於需求的變更可能來自客戶方，也可能來自開發方，因此，作為需求管理者，專案經理需要採用各種溝通技巧來使專案的各方各得其所。
(3)專案收尾階段的總結
能力的提高往往不是從成功的經驗中來，而是從失敗的教訓中來。許多專案經理不注重經驗教訓總結和積累，即使在專案運作過程中碰得頭破血流，也只是抱怨運氣、環境和團隊配合不好，很少系統地分析總結，或者不知道如何分析總結，以至於同樣的問題反覆出現。
事實上，專案總結工作應作為現有專案或將來專案持續改進工作的一項重要內容，同時也可以作為對專案合同、設計方案內容與目標的確認和驗證。專案總結工作包括專案中事先識別的風險和沒有預料到而發生的變更等風險的應對措施的分析和總結，也包括專案中發生的變更和專案中發生問題的分析統計的總結。
軟體設計師必考知識點
1.數制及其轉換,原碼,補碼,反碼與原碼的關係 2.校驗方法和校驗碼 3.算術運算和邏輯運算 4.陣列位址的影射 壓縮儲存 5.鍊錶 線性表的操作 6.樹的有關性質 二叉樹,二叉排棄樹等 7.遞迴演算法 8.各種流程圖的填空和迴圈次數認定 9.cpu運算器,控制器等的組成和作用 10.記憶體 介質的...
軟體設計師歷年下午試題知識點分布情況
2004 下半年下午試題 題號知識點大類 知識點小類 所屬科目 1資料流圖 資料流起點和終點 資料字典 軟體工程 2e r 圖關係模式 sql語句 unique 資料庫3 uml類圖和序列圖 類的屬性 補充序列圖 組裝和聚集 物件導向程式設計4pv 操作pv 操作實現互斥 作業系統 5拓撲排序 if...
軟體設計師選擇題真題知識點歸納
軟體成熟度 可重複級核心 建立基本的專案管理和實踐來跟蹤專案費用 進度和功能特性 已定義級 使用標準開發過程構建系統 已管理級 尋求主動的應對系統的開發問題 優化級 連續的監督和改進標準化的系統開發過程 能力成熟度模型cmmi 未完成級 過程域的乙個或多個特定目標沒有被滿足。已執行級 關注過程域的特...