變更管理 (工程)
系統工程中的變更管理流程,是一種對系統變更的請求、決定可達性、計劃、實施、和評估的過程,主要目的係以一系列相互關聯的因子,來支援變更的處理和可追溯性[1]。
緒論
變更管理、變更控制、和形態管理三者間常有重疊和混淆。下列定義仍未整合這些領域:
變更管理能夠帶來改善受影響系統、從而滿足「客戶需求」的好處而被接受。但也為了它潛在混淆和不必要地複雜化變更管理而飽受批評。在某些情況下,特別在資訊科技領域,更多的資金和工作任務被投入於系統維護〈和變更管理〉,而非系統的初始創建[2]。在大型ERP系統初期實施期間的典型企業投資約佔整體預算的15-20%。
- 持續變更法則:使用的系統必須變更,否則自動變得不那麼有用。
- 增加複雜性法則:透過變更,系統結構變得越來越複雜,需要更多的資源來簡化它。
變更管理在製造領域也非常重要,由於不斷增加的全球性競爭、技術進步、和苛求的客戶[4],也面臨着許多的變更。許多系統在使用時往往會發生變更和演變,所以這些行業的問題在很多方面都有一定程度的經驗。
註記:在下面的流程中,變更委員應負責不僅僅是接受/拒絕的決策,也要優先考慮變更請求如何批次處理的影響。
流程和交付標的
元建模技術常用於有關變更管理流程的描述,圖一為描繪在本節中所解釋的過程數據圖。
活動
有六種主要活動共同組成變更管理流程,包括:識別潛在的變更〈Identify potential change〉、分析變更請求〈Analyze change request、評估變更〈Evaluate change〉、規劃變更〈Plan change〉、實施變更〈Implement change〉、審查〈Review〉和變更結案〈close change〉。這些活動由四個不同的角色所執行,詳列於表一。這些活動(或其下屬活動)也詳列於表二。
角色 | 說明 |
---|---|
客戶 | 客戶係遇到問題、或新功能需求而請求變更的角色,可以是個人、或組織實體,可在公司內部或外部要求實施變更。 |
專案經理 | 專案經理是變更請求相關的專案的所有者。在某些情況下,會有一位專門的變更經理,在那種情況下承擔這個角色。 |
變更委員會 | 變更委員會決定是否實施一個變更請求,有時,此項任務也可由專案經理履行。 |
變更執行者 | 變更執行者係為規劃、實施變更的人,對於規劃細節有部分由專案經理負責,可能會有爭議。 |
活動 | 下屬活動 | 說明 |
---|---|---|
識別潛在的變更 | 需要新功能[5] | 客戶需要新功能,並闡述需求。 |
遇到問題[5] | 客戶遇到系統上的問題(例如:程式錯誤),並導致一件問題報告的後果。 | |
請求變更 | 客戶透過建立一個變更請求,提案變更。 | |
分析變更請求 | 確定技術可行性 | 專案經理確定變更請求提案的技術可行性,導致一個「變更技術可行性」。 |
確定成本和效益 | 專案經理確定變更請求提案的成本和效益,導致一個「變更成本和效益」。這和上述的下屬活動可以任何順序完成,彼此獨立。因此,建模為無序的活動。 | |
評估變更 | 基於變更請求,其「變更技術可行性」和「變更成本和效益」由變更委員會作成通過/未通過的決策。這被建模為一個單獨的活動,因為它是一個重要的流程步驟,並且具有執行它的另一個角色。蘭柯‧何姆斯〈Remko Helms〉建議將此建模為一個下屬活動〈沒有任何活動包含它〉 。 | |
規劃變更 | 分析變更影響 | 在一個「變更影響分析」確定了變更範圍(亦即受變更影響的其他項目),這個活動導致另一個通過/未通過的決策,或甚至構成「分析變更請求」活動的一部分,可能會有爭議。 |
建立計劃 | 為了實施變更而建立一個變更計劃,一些流程說明〈例如:Mäkäräinen, 2000〉闡明可能「保留」變更,並以批式方式處理這些變更,這個活動可被視為一個好做法。 | |
實施變更 | 執行變更 | 變更是「被計劃的」,這個活動和普及變更有很強烈的關係,因為系統的其他部分〈甚至其他系統〉有時也需要適應變更。 |
普及變更 | 由「執行變更」活動而來的變更,必須普及於受其影響的系統其他部分,因為這個與上述下屬活動彼此高度依賴,而被建模為並行活動。 | |
測試變更 | 變更執行者測試其所執行的變更,是否滿足了「變更請求」。如圖所示,這可能導致一個和上述二個下屬活動一起進行的疊代流程。 | |
更新文檔 | 「文檔」更新,以反映實施的變更。 | |
發佈變更 | 一個新的「系統發佈」公開化,以反映實施的變更。 | |
審查和變更結案 | 驗證變更 | 新的「系統發佈」中的變更實施,由專案經理進行最後一次的驗證。也許這必須在發佈之前發生,但是由於其與文獻資料來源和圖表複雜性相互矛盾的考量,選擇以這種方式進行建模,並包括這個議題。 |
變更結案 | 完成這個變更周期,亦即,結束「變更日誌登記」。 |
交付標的
除了活動,過程數據圖〈如圖一〉也顯示了每個活動的交付標的,亦即數據。這些交付標的、或概念說明於表三,就此而論,最重要的概念為「變更請求」和「變更日誌登記」。
有些概念是由作者所定義〈亦即缺乏參考文獻〉,因為未能發現〈好〉定義,或者它們明顯是一個活動的結果,這些概念標有星號〈*〉。概念的性質已經被排除在模型之外,因為它們大部分都是微不足道的,圖表可能會很快變得太複雜。因此,一些概念〈例如:「變更請求」、「系統發佈」〉藉助由 Weerd 提出的版本控制方法[6],但是由於圖表複雜性的限制,這也被排除在外。
概念 | 說明 |
---|---|
需求 | 一個組件〈或項目; NASA, 2005〉的必需功能。 |
問題報告 | 說明第一級服務台僱員無法解決的問題的文件,包括:日期、報告問題者的連絡資訊、問題的地點和說明、採取的行動和處置 ... 等項目,但是這在圖中並無描述〈Dennis, et al., 2002〉。 |
變更請求 | 說明請求的變更、以及為何它很重要的文件,可源自「問題報告」、系統強化、其他專案、底層系統的變更、和高層管理者,這裏總結為「需求」〈Dennis, et al., 2002〉。重要的屬性:「通過/未通過決策」,亦即,要執行變更?或不要執行變更? |
變更日誌登記* | 在所有變更〈例如:為了一個專案〉的集合中的不同輸入,是由「變更請求」、「變更技術可行性」、「變更成本和效益」、「變更影響分析」、「變更計劃」、「測試報告」、「變更驗證」所組成。如果這個過程被提前終止〈亦即,如果變更沒有執行〉,並非所有這些項目都必須包含在內。 |
變更技術可行性 | 這個概念表明是否「可靠的硬件和軟件、技術資源能夠滿足提案系統的需要〈亦即,變更請求〉、並在需要的時間內可藉由組織獲得、或開發」〈Vogl, 2004〉。 |
變更成本和效益 | 實施所需的預期工作、和實施變更所帶來的優勢(如節約成本,增加收入),也被稱為經濟可行性〈Vogl, 2004〉。 |
變更影響分析 | 評估變更的程度〈Rajlich, 1999〉。 |
變更計劃 | 「為實現某些目標、或實現某種目的(亦即,變更)而採取的計劃、方法、或設計」(Georgetown University, n.d.), 在這種情況下就是變更。 |
項目 | 「用於表示任何產品的非特定術語,包括系統、子系統、組件、下屬組件、部件、套件、附屬件、電腦程式、電腦軟件或部件」(Rigby, 2003),具有〈重疊的〉子類型:「新增項目」和「變更項目」。 |
新增項目* | 不言自明:一個新創建的「項目」;「項目」的子類型。 |
變更項目* | 不言自明:一個已經存在,但已被改變的「項目」;「項目」的子類型。 |
測試報告 | 「說明對(受變更影響的〉系統或組件進行測試的實施和結果的文件」(IEEE, 1991〉。 |
文檔 | 根據賓夕法尼亞州立大學圖書館(2004)的定義,文件是「附有其他材料(通常非書本)的印刷材料,並說明、給出使用說明、或以其他功能作為主要材料的指南」。在這方面,它也可以是數位材料、甚至是訓練教材,只要和系統(或部分的系統〉關連。 |
系統發佈 | 「出售或公開展示的商品」(Princeton University, 2003),由一個或多個「項目」、和隨附的文檔所組成。 |
變更驗證 | 確認變更實施的結果,是否滿足早先所建立的要求(Rigby, 2003)。 |
除了「變更」之外,還可以區分偏差和豁免[7]。偏差是在一個項目創建之前偏離其需求的授權(或其請求)。 豁免本質上是相同的,但是在項目的創建期間、或創建後。 這兩種方法可視為簡約的變更管理(亦即,對當前的問題沒有真正的解決方案)。
範例
在軟件開發可找到運作中變更管理流程的好範例。用戶通常會報告錯誤、或希望從其軟件程式中獲得新功能,從而導致變更請求。然後,軟件產品公司將探究實施這一變更的技術和經濟可行性,從而決定變更是否真的實現。如果確實如此,則必須透過使用功能點來規劃變更。變更的實際執行,會導致電腦程式的創建或更改,並且在普及這個變更時,可能會導致其他程式碼片段也發生變更。在初步測試結果看起來令人滿意之後,可以將文檔與軟件一起更新並發佈。最後,由專案經理驗證變更,並在變更日誌中登記結案。
在這裏所處理的變更管理的另一個典型範圍,就是製造業領域。以一輛汽車的設計和生產為例,如果在長距離駕駛後發現車輛安全氣囊自動填充空氣,這毫無疑問會導致顧客投訴(或者在測試階段所期望的問題提報)。反過來,這些會產生一個變更請求(見右圖二),這可能會證明變更是合理的。 儘管如此,還是要做一個最簡單的成本和效益分析,然後才能批准變更請求。在分析對汽車設計和生產時程的影響之後,就可創建實施變更的計劃。依據這個計劃,這個變更實際上是可以實現的。隨後在這個新版汽車被公開發佈之前,有望得到徹底的測試。
在工業廠房
由於復雜流程對於即使是小變更也非常敏感,所以對工業設施和流程的變更的適當管理,被認為是安全的關鍵。美國職業安全與衛生管理局(OSHA)制定了指導如何進行變更和記錄的相關規定。主要的需求是由一個多學科小組對一個提案的變更進行徹底審查,以確保盡可能多的觀點被用來最大限度地減少發生危害的機會。在這種情況下,變更管理被稱為「變更的管理」(MOC),它只是流程安全管理許多要素之一,第 1910.119(l).1節。
參見
- 變更控制
- 變更管理
- 工程變更通知、工程變更命令、變更請求
- 受控環境下的專案管理第二版〈PRINCE2〉
- 信息技術基礎架構庫〈ITIL〉
- 版本控制
- 發佈管理
- 軟件版本週期
- 軟件生命週期管理
- 系統工程
- 事務跟蹤管理系統
參考文獻
- ^ Crnkovic, Asklund & Persson-Dahlqvist, 2003
- ^ Dennis, Wixom & Tegarden, 2002.
- ^ Hinley 1996.
- ^ Huang & Mak, 1999.
- ^ 5.0 5.1 ,實際上,不需要「需要新功能」和「發現問題」兩者同時出現才需要變革,一般只要一種即可。然後分別建立兩個「起始點」(即初始狀態),兩者都需要變更。
- ^ Weerd 2006
- ^ Scott & Nisse, 2001.
延伸閱讀
- Crnković I., Asklund, U. & Persson-Dahlqvist, A. (2003). Implementing and Integrating Product Data Management and Software Configuration Management. London: Artech House.
- Dennis, A., Wixom, B.H. & Tegarden, D. (2002). System Analysis & Design: An Object-Oriented Approach with UML. Hoboken, New York: John Wiley & Sons, Inc.
- Georgetown University (n.d.). Data Warehouse: Glossary. Retrieved April 13, 2006 from: https://web.archive.org/web/20060423164505/http://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html.
- Hinley, D.S. (1996). Software evolution management: a process-oriented perspective. Information and Software Technology, 38, 723-730.
- Huang, G.H. & Mak, K.L. (1999). Current practices of engineering change management in UK manufacturing industries. International Journal of Operations & Production Management, 19(1), 21-37.
- IEEE (1991). Standard Glossary of Software Engineering Terminology (ANSI). The Institute of Electrical and Electronics Engineers Inc. Retrieved April 13, 2006 from: http://www.ee.oulu.fi/research/ouspg/sage/glossary/#reference_6(頁面存檔備份,存於互聯網檔案館).
- Mäkäräinen, M. (2000). Software change management processes in the development of embedded software. PhD dissertation. Espoo: VTT Publications. Available online: http://www.vtt.fi/inf/pdf/publications/2000/P416.pdf(頁面存檔備份,存於互聯網檔案館).
- NASA (2005). NASA IV&V Facility Metrics Data Program - Glossary and Definitions. Retrieved March 4, 2006 from: https://web.archive.org/web/20060307232014/http://mdp.ivv.nasa.gov/mdp_glossary.html.
- Pennsylvania State University Libraries (2004). CCL Manual: Glossary of Terms and Acronyms. Retrieved April 13, 2006 from: https://web.archive.org/web/20060615021317/http://www.libraries.psu.edu/tas/ cataloging/ccl/glossary.htm.
- Princeton University (2003). WordNet 2.0. Retrieved April 13, 2006 from: http://dictionary.reference.com/search?q=release(頁面存檔備份,存於互聯網檔案館).
- Rajlich, V. (1999). Software Change and Evolution. In Pavelka, J., Tel, G. & Bartošek, M. (Eds.), SOFSEM'99, Lecture Notes in Computer Science 1725, 189-202.
- Rigby, K. (2003). Managing Standards: Glossary of Terms. Retrieved April 1, 2006 from: https://web.archive.org/web/20060412081603/http://sparc.airtime.co.uk/users/wysywig/gloss.htm.
- Scott, J.A. & Nisse, D. (2001). Software Configuration Management, Guide to Software Engineering Body of Knowledge, Chapter 7, IEEE Computer Society Press.
- Vogl, G. (2004). Management Information Systems: Glossary of Terms. Retrieved April 13, 2006 from Uganda Martyrs University website: https://web.archive.org/web/20060411160145/http://www.321site.com/greg/courses/mis1/glossary.htm.
- Weerd, I. van de (2006). Meta-modeling Technique: Draft for the course Method Engineering 05/06. Retrieved March 1, 2006 from: https://bscw.cs.uu.nl/bscw/bscw.cgi/d1009019/Instructions[永久失效連結] for the process-data diagram.pdf [restricted access].