軟件配置管理系列--軟件配置管理概念－2,用戶角色
2.1 用戶角色
就像1.3中的場景所描述的，一個CM系統有許多不同的用戶，每一種用戶都屬于特定的角色，對CM系統也有不同的視角，因此對CM系統有不同的需求。圖1說明了項目經理、配置經理、軟件工程師、測試員、QA經理和客戶對CM系統的期望，每一個方框代表了一個功能域，圖1中的方框（審計、統計、控制、組件、結構和構建）是可以存在于任何CM系統的功能域，但是當與團隊和過程功能結合后，就可以組成了一個全盤的（或者說是復雜的）CM系統。
圖1
這些功能域有：
組件：識別、分類、保存和訪問組成產品的組件。
結構：代表了產品的架構。
構建：支持制品和產品的構建。
審計：保持產品和過程的審計軌跡。
統計：收集產品和過程的統計信息。
控制：控制如何和何時進行變更。
過程：支持產品功能正確性的管理。
團隊：支持項目團隊開發和維護一系列產品。
這些功能的需求會在下面詳談。
對于組件的需求包括：記錄組件的版本，區別和區別的原因；標識組成一個配置的組件，其中包括各個版本的組件；標識產品和其擴展的基線；確定代表特定項目組件和制品集合的項目環境。此外，用戶需要版本庫或運行庫來保存和捕獲組件和CM信息，例如保存源代碼、對象代碼、可執行程序、圖表、文檔和基線等。
對于結構需求，用戶需要：通過代表產品組件的列表來建立產品的模型；指出組件、版本和配置的分界點，以此使之可重用；標識和維護組件的關系；選擇兼容的組件來組成正確和一致版本的產品。
對于構建需求，用戶需要：簡化構建和編譯產品的過程；在任何時間對產品的狀態進行快照和凍結的能力；通過減少重新編譯的組件和節約空間來優化構建系統的機制；利用變更影響分析預測衍生物發生的更改；在任何給定時間更方便的重新生成任何階段或部分的產品。
對于審計需求，用戶需要：所有變更的歷史；在產品和他們的演化中能夠追蹤所有相關的組件。所有所作工作的詳細日志。
對于統計需求，用戶需要：記錄統計數據來檢驗產品狀態的機制，更容易的生成關于產品和過程的各個方面的報告。
對于控制需求，用戶需要：小心的訪問系統的組件防止未保證的變更和變更沖突；在線的變更請求表單和問題報告支持；也意味著要追蹤問題原因、時間和處理的負責人。用一種控制的方式傳遞變更，貫穿不同但是相關的產品版本；分割產品達到減少變更影響的方法。
對于過程需求，用戶需要：支持他們的生命周期模型和組織政策；識別將要做的任務，以及這些這些任務何時和如何完成的能力；與正確的人交流相關信息的能力；和記錄產品知識的工具。
對于團隊需求，用戶需要：單獨的和組的工作空間；合并修改時解決沖突的方法；支持創建和維護產品族的工具。
需要注意過程框和團隊框被表示成重要的功能，這是因為它們會和所有其它部分互相影響。對一個用戶來說，一個理想的CM系統應該支持所有的集成了團隊和過程的功能域，目前沒有一個單獨的系統支持所有這些功能域。
2.2 CM系統的集成
任何一個CM系統都有與環境集成程度的概念，一個CM系統可以與其他工具共存或完全集成。集成包括了環境的各個方面：過程、工具集和數據庫。過程集成意味著CM系統使用模式（組成了CM過程）的結合。工具集集成意味著在環境中安裝所有的CM系統，至少是與環境中的其他工具可以共存。舉個例子，用戶希望CM系統能夠在編輯器中執行“保存”時創建一個新的版本。數據庫集成關注CM數據庫的邏輯位置－－是否與現存環境的數據庫以某種方式合并，或者是它是一個獨立的實體，或者是它利用了其它數據庫的信息。所有這類集成都是普通的工具集成和技術遷移問題。但是自從CM系統嘗試影響環境中的大多數對象和對象的整個生命周期的所有階段時，CM系統的集成開始對環境中的許多工具產生了重要的影響。大多數CM系統與其他工具共存，而且有一些環境讓CM成為他們自身的一部分。
2.3 何時開始使用CM系統
這要看項目組何時在開發和維護的產品上開始使用CM系統。一些小組選擇在產品經過了開發周期并準備好交付給客戶方時，另一方面，一些小組選擇從項目的一開始就將所有的事情放在CM之下。兩種方式都有各自的成本，舉個例子，團隊會根據變更的成本作出選擇，如果需要許多手工的過程（例如填寫變更請求單，獲得CCB的通過和確認），團隊一般會選擇在開發的主要過程結束后納入CM控制，但是如果變更請求過程可以在線操作，只需要花費較少的時間和人力，CM將會在較早的時間被引入。理論上講，CM適應于產品的整個生命周期－－從概念、開發、產品發布、客戶交付、客戶使用到維護。理想情況下，CM系統必須盡可能將成本最小化，因此應該盡早將CM應用到項目。然而，現存的CM系統，容易將精力集中在產品生命周期的特定階段，所以用戶會被功能限制。
2.4 CM控制的級別
有許多輔助CM執行的步驟、政策和工具，他們會對用戶和產品的演進提供不同程度的控制。例如，它們會要求工程師提交正式的書面的變更請求，接著是CCB的評估和對變更的授權。然后配置經理為軟件工程師創建工作區，從受保護的版本庫選取特定的文件放置到這個工程師獨立的工作區。另一方面，另一種不同的步驟、政策和工具或許允許工程師直接用電郵通知配置經理和CCB的其他成員他的變更請求，然后這些成員立刻反饋，經過批準，變更請求指派給一個工程師，然后這個工程師直接從版本庫得到代碼并進行修改，所有這些操作不需要手工的干預，因為CM系統可以自動的記錄所有的訪問，一個正式的修改過程記錄會被創建。
第一個場景被認為是對任何活動都非常嚴格和積極的控制，而后一個場景則是對活動寬松和被動的控制。最好不要在第一種場景進行經常性的修改，因為人力成本很大，而第二種情況鼓勵頻繁的修改，因為這很容易。不同級別的控制可能更適合于產品生命周期的一定階段，例如，第一種適合維護階段，而第二種適合開發階段。無論使用何種CM系統，在產品的演進的某個時間點上都有特定級別的控制，它會限制，加強用戶過程或者兩者皆有。現存的CM系統提供了各自的控制級別，或松或緊，很少具備允許用戶選擇控制級別的靈活性。
2.5 區分過程和產品
CM包括了過程和產品，一個CM過程代表了一系列依序執行的CM任務，本質上講，這個過程是將要做的事情、及其執行者和執行方式的計劃，對過程的支持是一種管理功能。過程模型會考慮組織和軟件開發生命周期模型的策略和步驟。CM產品是工程任務過程的結果，一個CM系統需要同時提供這兩個方面的功能。現存的系統提供了一些產品和過程的支持，但是同時支持通常并不是很簡單。
2.6 CM的自動化程度
如前所述，CM通常是手工和自動步驟的組合，有可能在不需要任何即時輔助的情況下執CM，但這是沒有效率的，我們的目標是在CM的非創造性部分盡可能的自動化。例如，即使已經有系統可以提供完整的完整的自動變更請求，仍可以用在組織的策略文件夾中寫文檔的方式來填寫變更請求表單和反饋，而不是即時捕捉和執行。盡管每一種CM系統都提供了不同程度的CM自動化功能，仍需要用戶用手工手段來作為自動步驟所不能完成任務的補充。
2.7 CM系統的功能
現存的CM系統提供了CM部分必須的一些功能，但是沒有一種系統提供了滿足所有不同用戶需求的功能，改進需要時間，需要隨著用戶對環境架構更好的理解來完成。下一部分重點介紹現存CM系統中概念的映射。