1. 變更請求管理(Change Request Management: CRM)
變更請求
變更伴隨著軟體開發的各個階段。軟體開發過程中的變更可以從兩個側面來描述，一個是對軟體開發過程之中工件（如：需求設計文件、設計模型、程式碼及測試指令碼等）的變更；另一方面是驅動工件變更的理由（如：缺陷修正、新功能新增等等）。這種驅動軟體工件變更的理由就是變更請求。
變更請求管理（CRM）的必要性
伴隨著現代化社會的高速發展，對軟體開發的要求也越來越高，變更量之多、變更頻率之快，使開發人員必須在相當的壓力之下，迅速解決問題。另一方面，隨著開發規模的不斷擴大，加入開發的人數也在不斷增加，處理錯誤的成本也相應成指數級增加。在這種狀況下，是否能高效地跟蹤併合理地管理變更請求對軟體開發的成功與否，就起到了舉足輕重的作用。所以，為了保證整個專案開發的成功，在專案管理方面必須克服如下挑戰：
難以有效地管理和追蹤變更請求
變更請求是指在軟體開發生命週期內產生的所有需要改動專案相關內容的請求，如：缺陷、功能增強、需求變更等。它是推動專案向前發展的源動力，同時也是專案重要的過程資產。所以，能否有效地管理和追蹤變更請求成為專案成功的關鍵要素之一。正是因為如此，目前有很多研發企業都已建立了自己的變更管理流程，但多數企業都是以書面變更單的形式來記錄和管理變更請求，但此種方式很難對變更請求的發展狀態進行追蹤，導致變更管理流程難以貫徹實施，同時也很難對變更請求進行統計分析。
缺少必要的團隊溝通導致工作效率降低
目前大多數專案的研發人員都在幾十人甚至上百人，在如此大規模的專案中溝通成了一個至關重要的問題。例如某個開發人員對自己模組的介面進行改動後沒有及時通知相關的開發人員，導致整合困難。又如某個核心模組的缺陷被修改後沒有通知整個團隊，導致開發團隊多次修改同一個缺陷。諸如此類的溝通問題如果不能很好的解決將會導致團隊效率的降低。
難以及時準確地瞭解專案狀態和發展趨勢
在軟體開發生命週期中變更請求可以被視為專案的活動或任務，所以變更請求的資訊和統計資料可以直接反映專案的狀態和發展趨勢，但由於我們多以書面變更單的形式來記錄和管理變更請求，導致難以查詢變更請求的狀態或對現有變更請求進行統計分析，所以，專案經理通常是通過會議、電話或郵件的方式去了解專案狀態，但這種方式不但耗時且很難及時準確地瞭解專案狀態和發展趨勢，致使專案經理對專案做出錯誤的判斷或決策。
難以進行量化的專案管理
變更請求是專案管理的重要資料之一，通過對這些資料的統計分析可以進行量化的專案管理。例如我們可以統計專案組每個成員的任務分配情況；統計目前還有多少未被響應的變更請求；統計缺陷的平均修復時間；統計在一段時間範圍內變更請求數量的變化等等！以上這些統計資料都是專案經理迫切需要的，但如果在專案規模較大的情況下，僅以手工的方式對變更單進行管理，根本無法對其進行統計分析。
難以將專案活動與配置管理物件的變更相關聯
專案活動的主要來源是變更請求，專案活動的最終結果是配置管理物件的變更（即文件或程式碼的修改）。通過傳統的專案管理方式很難將專案活動與配置管理物件的變更相關聯。從而使得開發人員不清楚自己對程式碼所作的修改是和那些任務相關，導致在整合時程式碼提交錯誤；同樣整合人員和專案經理很難確定某一個特定的變更請求到底和那些程式碼的修改相關，導致整合過程出現的問題難以定位，以上這些問題都會直接導致整合時間的拖延。
由此可見，如果沒有變更管理，重要的變更就會被遺漏，專案的監視、檢查能力就會喪失，專案管理人員及開發人員不能掌握工作重點及輕重緩急，測試及文件的編寫均不能反映專案開發的實際狀況。直接後果表現為：由於交貨期推遲而造成的開發成本增加、生產率低下、產品質量低下。
變更請求管理是軟體開發的成本降低的最大因素之一。再優秀的軟體開發團隊也不能保證從一開始就100%地正確開發。在開發系統生命週期中，變更是永遠不可避免的。部署高效的CRM 系統，通過對專案開發整個生命週期中的變更請求進行管理及各種資料查詢，可以使問題的解決時間大幅度降低，從而有效地降低開發成本。
如何有效地組織和管理變更請求
成立變更管理委員會
變更請求管理決不是向大家所想象的僅僅是單一的跟蹤，變更請求管理所強調的是對開發過程中成百上千的變更請求進行慎重的資訊管理，“慎重”包含的是跟蹤、分析、決策的完整過程。這種“慎重”的處理過程必須由一個變更管理委員會（CCB）進行控制和管理，CCB 應該由開發團隊中富有分析、決策能力的角色構成，CCB 的主要職責是對遞交進來的所有變更請求進行審查、分析，從而決定如何處理這些變更請求。
制定合理的變更流程
如前所述，變更管理的關鍵目的是通過建立合理的變更流程，來改進產品的質量和服務。而變更管理流程執行的有效性取決於團隊之間的密切配合。單一的工具並不能保證變更請求管理的成功。以下是變更請求管理流程實施的基本步驟：
1． 確定變更請求管理流程執行的範圍：你可以從一個專案、一個部門或多個組開始實施。但在制定變更管理流程前，你必須確定好實施範圍，然後制定響應的變更流程；
2． 制定變更管理流程模型：這是整個變更管理流程的核心部分。你必須與團隊人員合作，編制、審查和修改此模型，直到團隊每一個人都能認可此流程；
3． 決定團隊各個角色在流程實施中所起的作用：通常情況下，在團隊中有變更請求提交者、
CCB、請求解決方案實施者、測試人員及QA 等；
4． 確定實施計劃及開始實施日程：實施過程可以分階段完成，但要注意跟蹤各個階段完成的質量，保證變更請求相關者對各個階段完成的認可；
5． 部署變更請求管理系統：在完成了上述步驟後，你已具備了實施變更請求管理的條件；
6． 不斷強化變更管理流程：變更管理流程不是一成不變，它需要團隊發展的不斷變化及時作相應的調整，不斷地被改進和強化。
開發專案有關人員都有權利提交變更請求。如開發人員在編碼過程中，會覺得某部分設計不合理，提出更改設計的請求，這種請求如不得到跟蹤管理，我們就不能清晰地掌握產品是否真正滿足了終端使用者需求。所以，完整的變更管理系統，不應該僅僅是對缺陷的管理。它應是通過對缺陷及其各種他變更的登記、保管、跟蹤、解析，達到團隊之間的各種變化資訊的共有、安全而可靠的高質量變更資訊管理系統。這種資訊管理系統通過以下特徵的體現，有效地組織和管理變更請求。
1． 應可提供具有各種重要特徵的變更請求資訊，且對各種變更請求在處理完畢之前的內容能及時調整、並保證各種請求的資訊絕對不能丟失。
2． 有效地跟蹤各種變更，對管理人員提出各種變更狀況的查詢請求，做到快而準地提供資訊。
3． 有能力對專案整體發展狀況，提供巨集觀及定量的分析，從而能合理分配專案開發人員的工作、合理制定專案的計劃、合理管理專案各種請求實施的優先順序。
有效的CRM 系統，應具備從簡單地列出問題清單對缺陷進行跟蹤，到對專案開發的各種可能的變更流程進行定義、以及各種變更請求在適當時機採用適當方法進行訪問等靈活多樣的選擇性，以適應開發過程中的各種變化。也就是說，有效的CRM 系統應具備良好的系統適應性、擴充套件性及靈活定製性。
典型的變更管理流程
2. 完整的變更請求管理解決方案：IBM Rational ClearQuest
概要
IBM Rational ClearQuest 是強有力的且靈活性很強的CRM 系統。通過對開發整個生命週期中發生的各種型別變更請求的跟蹤及管理，保證各種規模的開發團隊按照預定計劃按期交出高質量的軟體產品。
IBM Rational ClearQuest 是一個具有定製性高、跨越多種資料空間的CRM 系統。適用於在任何平臺上，任何型別的專案中，捕獲各種型別的變更。ClearQuest 使用行業標準資料庫（Microsoft Access、 SQLAnywhere 、SQL Server 、DB2、Oracle），因此支援的專案可大可小；並擁有可完全定製的介面和工作流程機制，能適用於任何開發過程。此外，通過提供各種各樣的流程模，對於一般的開發環境和流程，可以做到“拿來就用”或“稍做修整，即可使用”的方便而靈活的部署。
ClearQuest 與IBM Rational 的其他解決問題方案（如配置管理工具、自動測試管理工具、需求管理工具）的整合，使團隊開發的各個角色在開發的各個階段都可以隨時遞交變更請求，成為支援軟體開發整個生命週期的變更管理的有效工具。
ClearQuest 的特點
有效的記錄、管理和追蹤變更請求
ClearQuest 通過多種易於使用的客戶端（Windows，UNIX，Web，Email），讓您在任何地點、以任何方式都可以捕獲在整個開發生命週期中出現的各種型別的變更請求，包括測試階段發現的缺陷、需求分析階段的需求擴充套件請求等等。所有的變更請求在ClearQuest 中被集中儲存在統一的資料庫之中，以便進行各種形式的查詢，同時也便於集中管理。另外，ClearQuest 給變更請求還附加了狀態資訊，以便於追蹤變更請求的發展狀態。
促進團隊的溝通和協作
ClearQuest 提供一套完備的電子流管理系統。它可以利用企業現有的郵件服務系統實現自動電子郵件通知功能。當系統內提交了新的變更請求或已有變更請求的狀態發生變化時，ClearQuest 會自動通過電子郵件通知相關的人員，從而大大促進團隊的溝通和協作。
隨時隨地瞭解專案狀況
ClearQuest 支援通過WEB 的方式對系統進行訪問，在瀏覽器中可以查詢變更請求的狀態、瀏覽變更請求的資訊、生成多種統計分析圖表和專案狀態報告。所以，專案經理無論是在公司還是在外地出差都可以及時準確的瞭解專案的狀況。
靈活、客觀的專案統計指標
ClearQuest 的查詢、圖表（年齡、趨勢、分佈圖表）、報告（與SoDA 整合）功能，使得專案管理人員能夠方便、準確地得到專案統計指標資料，如：
“變更請求是否在團隊成員中被合理分配?”
“還有多少優先順序為1 的缺陷未得到處理?”
“平均修復一個錯誤需要多長時間?”，“實現一個擴充套件請求需要花多少時間?”
“在兩個月內變更請求數量的變化曲線”
依賴各種專案統計指標資料，專案管理人員就可以進行更加科學、量化的管理、規劃、調配、監控，保證專案如期的進行。
系統可定製能力強
在ClearQuest 系統中所涉及的表單資訊域、狀態變遷過程、分析圖表和狀態報告等都是可以根據企業的實際需要進行定製的，並且可以隨專案的發展不斷進行調整。所以，ClearQuest 可以適用於任何型別以及任何規模的專案。對於一個立足長遠發展的企業而言，ClearQuest 是一筆可以長期保值的投入。
可以有效地控制各種變更請求之間關係在ClearQuest 可以建立各種變更之間的關係，這種變更的關係實際上是雙向的，這種關係的管理，體現在以下幾個方面：
1． 變更請求的包括關係，通過建立多數“子”請求與“父”請求的關係，控制全部“子”請求沒有到closed 狀態，“父”請求不能close；
2． 不同變更請求之間的連線關係， 通過建立定義不同的變更請求型別，建立資料的參照關係（record reference），實現資料共享。比如：在缺陷變更請求中呼叫使用者資訊時，可以另建立使用者變更資訊資料庫，通過建立與缺陷變更請求關聯，便可得到實現。
通過與ClearCase 的整合可以實現專案活動和配置管理物件的統一ClearQuest 可以和配置管理工具ClearCase 整合，從而將變更請求和配置管理物件有機的聯絡到一起。主要的整合方式有以下兩種：
1、 ClearQuest 與Base ClearCase 整合
整合是通過將ClearCase 的版本物件庫（VOB）與ClearQuest 的資料庫相關聯來實現的，整合後開發人員在修改程式碼（Check Out）時會自動彈出ClearQuest 的變更請求列表，並強制開發人員將此次修改與特定的變更請求相關聯。這樣一來，開發人員在程式碼提交時可以清楚的知道哪些修改過的程式碼是對應哪些任務的，整合人員可以準確的瞭解到某次建立到底整合進來哪些變更請求。專案經理可以輕鬆的定位變更請求和哪些改動相關。
2、 ClearQuest 與UCM ClearCase 整合
此種整合方式與上一種整合方式從實現機制上沒有本質的區別，但從功能上二者的整合更加緊密，且很多功能更加自動化。如開發人員在提交程式碼時系統會自動檢測出此次需要提交的變更請求，待開發人員確認後系統會自動對程式碼進行歸併。總而言之，UCM 對於開發人員來講使用非常簡便且不要出錯，對於整合人員來講，由於UCM 採用組建式管理，使得系統架構更加清晰，整合工作更加快捷。對於專案經理來講UCM 為團隊提供了一套完整且高效的變更管理流程。