一般人的理解，變更、配置管理這個方案是用在開發人員的角度上的工具，我想這是對的，它是用在這方面的工具，實際上它的意義比它應用的更廣泛。如何讓大家來認識這一點，我先從軟件開發的復雜度來談起。
第一個問題，我想跟大家探討一下，我們有多少人或者用了多長時間在ms-dos 系統上，這個系統是在二三十年前的一個系統�？赡芟胂蟛坏�，實際上這個版本的開發，才用了六個星期，實際代碼數才是4000 行。我們來看一下最新的microsoft 操作系統的情況。能想象的到，這個系統大概有4 百萬行的代碼，加上了大概有多達1 萬人員的開發人數經過了三到四年的開發歷程才誕生出來的系統。在二三十年前的系統跟現在的系統有多大的區別，大家能想象的到嗎？我們從這兩個例子的比較可以看到，實際上這個系統的復雜度要提升了大概萬倍或者百萬倍的復雜度。這就使我們聯想到軟件開發系統或軟件開發過程隨著時間的增長它會變得越來越復雜。
除了開發過程之外，我們想到的是在開發之后可能有很多的變更或者有很多的問題你要去跟蹤管理。作為項目經理或者項目總開發人員，你每天或者每時所做得事情都面臨著一個變更的過程，這個過程的管理是個相當復雜的過程。還有其他方面的復雜因素，比方說隨著你公司的不斷發展壯�，你的team 成員還有開發組織機構都在不斷變更，你會面臨在異地開發的狀況或者在不同的部門，怎么樣去結合在一起組織你的開發過程。
舉一個例子，比如在開發過程之中你的團隊人員的團隊管理過程發生錯誤，這個team 就談到兩個人員在同時修改同一個代碼的時候，他們發生代碼覆蓋的錯誤。另外一個錯誤我們可以聯想到軟件復雜度會給你帶來的錯誤，舉個例子來說，比如我現在在修改組件的時候，沒有想到其他人員正在用這個組件來做事情。另外一個錯誤，可能讓我們聯想到你在流程的支持過程之中，缺乏一些因素來影響到你犯錯誤，比如我們忘記解決在軟件發布之后的一些缺陷。另外一個因素可以讓我們聯想到當你組織的復雜度改變了之后，所產生的錯誤，比如我們很多的團隊人員，不同的項目組，工作在同一個環境之下，當一個項目組對某一個缺陷、某一個錯誤進行更正的時候，這個缺陷會對哪些項目組產生影響，這個管理不當就會產生錯誤。所以，我們把變更、配置管理解決方案定成我們是在軟件開發過程之中或者軟件管理之中，我們要盡量縮小你的錯誤或減少你的錯誤，我們要最大限度提高變更、配置管理的能力。
再回到我們對一些官方軟件，從如何定義的角度來看這個問題。二三十年前所定的軟件配置管理，它定義成是控制和管理軟件開發過程之中的配置性，這個是提高軟件開發過程之中的配置管理的力度，這個實際上是監視和報告軟件開發過程之中的變化狀況。這些是我們配置管理的內容，也是我們應該解決的問題�，F在軟件配置管理的范疇提升到資產的開發管理角度之上，首先要控制和跟蹤你開發的工作。另外還要保證你的軟件開發過程中沒有不應該丟失的東西丟失或者毀壞掉。如果讓我們看一下配置管理或者變更管理的工具市場，有各種各樣的工具來解決這個問題。我們稱為完整的變更、配置管理工具。這種管理工具包括了要控制進行變更跟蹤，版本管理、建立管理還有發布管理這些范疇，我們synergy 這個產品就是屬于這類范疇的解決方案。另外一類工具我們稱為一般的版本管理工具，或者是一些免費的配置管理工具。這類工具所解決的問題在我們很早以前定義的范疇里，這類工具不足以能夠管理軟件開發過程之中的復雜度，來幫助用戶實現他們的商業價值。
下面，我想談一下我們配置管理解決方案在軟件開發流程之中所起的作用或者角色。首先，我們配置管理解決方案的一些傳統角色，在軟件開發過程之中起一個版本管理的角色，另外是變更請求管理和跟蹤、建立管理的這類傳統性的角色。除此之外，它還起到了額外的角色，這類解決方案要幫助團隊進行友好的交流和協作。另外一個角色起到記憶所有開發過程之中的活動，能夠瞬間回到某個活動過程做的事情。還有一個角色，自動化反復開發的流程，另外一個角色是在變更、配置管理控制資產的背后，它起到一個開發過程之中的實施作用，所以，我們可以理解為變更、配置管理在開發的流程之中起到的是一個基礎框架的作用。在我們的組織之中哪些人應該用到變更、配置管理解決方案呢？從傳統的角度來說，它是用在了開發人員跟配置管理人員之中的解決方案。當我們定義了新的配置管理的范疇之后，我們變更、配置管理解決方案應該用在全隊人員的所有角色之中，它會對整個開發流程或者組織管理起到舉足輕重的作用。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
