UML软件工程组织

軟體流程管理的迷思(SCM)
来源:8848software
目前“軟體配置管理” (Software Configuration Management, SCM) 在臺灣產業界非常紅不讓,許多大公司已經全面展開了有關CMM/CMMI的實施工作,有些已經通過了2級和3級的評審。不過更多的企業還是在進行這方面的探索,有人詢問是否需要這樣的SCM工具,它真的可以幫助和支援軟體發展 ? 或者是再一次浪費金錢 ?

SCM的責任
根據IEEE的定義,“軟體配置管理”是一門應用技術、管理和監督相結合的學科,通過標識和文件檔來記錄配置項目的功能和物理特性。通過控制這些特性的變更,然後記錄和報告變更的過程和狀態,並驗證它們與需求是否一致。 因此,從定義可以看出,軟體配置管理(SCM)是一門綜合性的學科,其中不僅包含管理,也包含一些技術手段。另外,SCM通過管理配置項目來控制變更、驗證變更,使專案的混亂和錯誤達到最小,並提高最大限度的生產率。

事實上,實施SCM的目的是保證軟體專案的工作產品在整個專案週期中的“完整性”。所謂完整性是指,工作產品要求有完整的變更歷史記錄,要求有正式的變更過程,而且還要求保證工作產品能和需求以及變更保持一致性。

要通過ISO9001以及CMM (Capability Maturity Model) 認證,企業必須建立一整套全面、可行、有效的管理機制。這種管理機制,完全有別于傳統軟體發展的管理模式。這些認證要求我們必須對整個軟體發展生命週期進行規範化管理,例如

l 在整個軟體發展機構或部門內部建立嚴謹的工作流程,規範所有相關人員的活動和角色。

l 管理人員可以在任何時候對軟體發展過程進行量化、回溯,並以日誌和各種圖文報表加以顯示。

l 重點關心是整個企業內部什麼人,在什麼時候,對什麼檔案做了什麼類型的改動,如何改動,是否通過足夠的評審等等一系列問題。TOP

不可忽略的SCM
從CMM的實施情況來開,軟體配置管理( SCM )實際上是專案管理的基礎工作之一。原因如下:

l SCM是一個相對獨立的管理活動,也就是說,它不一定依賴其他的管理活動的開展。因此,在很多企業中,配置管理完全可以在其他的管理活動沒有開展或者還不成熟時獨立進行。

l 其他許多的管理活動中,多數都要以完善的配置管理作為基礎。比如說需求管理,對需求管理而言,無論需求的變更影響分析,還是需求的變更執行都是依賴在變更控制和配置管理基礎上的。其他的比如專案計畫管理、品質管制、專案跟蹤管理、子合同管理等都是類似的情況。

l 從實際經驗的總結來看,配置管理是諸多管理活動中最易操作、最容易實現並且能在專案最先體現出效果的管理手段。配置管理相對其他的管理,技術性較強,變化不大,對開發人員來說收效明顯,接受的程度高。
  
因此,意味著企業在導入CMM或CMMI時,我們首先要建立一套完整的配置管理制度 (SCM Policy)。有條件的話最好還要建立配置管理工具環境 (SCM Tool)。只有在此基礎上,才能為隨後更加深入的專案管理提供基礎。

總而言之,SCM是 ISO9001和CMM Level2中的重要組成元素,它在軟體產品開發的生命週期中,提供了結構化的、有順序化的、產品化的管理軟體工程的方法,是軟體發展和維護的基礎。TOP

CMM 模型概要

点击打开新窗口
圖1

從圖(1) 便發現CMM等級越高,軟體開發所需要的成本和時間會減低、產品的品質會提高。 難怪SCM在國外早已經引用十多年了。 從過去的CMM到現在的CMMI (Capability Maturity Model® Integration) 不斷地改進以符合現有的需求和標準。TOP

SCM為什麼會失敗

通常失敗可分為先天和後天的因素

先天因素

從分析衆多企業為什麼會失敗導入SCM的過程中,發現根本的問題主要有以下三點。

1. SCM小組孤單工作

企業在決定實施SCM之前,組織一個小組進行研究探討是很有必要的。可是,我們發現很多企業在組成SCM小組之後就讓它獨立的制定流程規範,並在完成之後才交給專案小組實施,但其結果通常是行不通或效果不好,從而導致SCM導入或實施失敗。

因為SCM或CMM或CMMI只陳述了要做什麽,但並沒有講清楚怎麽做?因此導入或實施時必須由有實際導入經驗的人員參與,他們應該對軟體生命周期每一階段的過程管理都相當熟悉,並且具備軟體生命周期各階段的實際開發和維護經驗。沒有這些珍貴經驗,就無法很好地設計,組織和管理開發與維護過程。

2. 全面展開SCM工作

SCM小組提供了一組看來可行的規範。因此,企業希望在最短的時間裏完成SCM的導入,但實際情況卻可能事與願違。

I. 在導入過程中會發現所制定的規範可能有些地方與實際情況有出入,但因爲覆蓋層面太廣反而不容易找到和確定改進點,結果是欲速則不達。

II. 在沒有充分理解「原本的軟體開發流程」和「想要導入所制定的SCM規範」之間的相容性。一些隱藏在「原本的軟體開發流程」的問題,可能在經過一段時間被剛導入SCM工作所掩蓋,這不單會讓問題沒有在最早時期被發現,而且還會增加更多的問題。更甚的還會大大增加分析問題和持續改進的難度。因此,SCM或CMM的實施應該先選擇一個著眼點,然後有計劃、分階段、一步一步地進行。從衆多已成功導入SCM或CMM或CMMI的企業說明了,這樣做的話不僅不會延長導入的時間,相反還會加快導入、實施和改進的步伐。

3. 引用現有模組

照搬或引用其他企業實施的模組是不可取的。因為不同企業有不一樣的開發方法、開發環境以及開發工具,這些會影響通模組的適用性和通用性,因此最有效的就是根據自己企業的實際情況制定一個模組,總遠比直接採用其他企業的模組有意義。

後天的因素

現在,我們知道SCM可以協調軟體發展使得混亂和錯誤減到最小並最有效地提高生產效率,可是為什麼企業在導入SCM時,成功的比例不是很高。

点击打开新窗口

圖2

根據圖 (2),我們認識到缺少任何一項,便會讓辛苦導入的SCM專案毀於一旦,白白浪費了寶貴的金錢和時間。

所以,為了確保SCM成功的導入,企業需要強硬執行下述二點

1. 通過行政手段規定開發人員使用SCM的工具。

2. 通過技術與工具的配合對軟體產品及其開發過程和生命週期進行管理。

唯有通過控制、記錄、追蹤對軟體的修改和每個修改產生的軟體元件來實現對軟體產品的管理。TOP

SCM 應用層次

大體上,SCM的應用層次可以從低到高分為三級

(一)版本控制 ( Version Control )

(二)以開發者為中心 ( Develop-Centric )

(三)過程驅動 ( Process Driven )

(一)版本控制 ( Version Control )

主要應用在個人獨立開發或小組開發,它可以控制任何檔的版本、實現分支和歸併功能、進行版本比較、標記注釋和版本報告資訊。目前主要工具為MS Visual SourceSafe。

(二)以開發者為中心 ( Develop-Centric )

主要應用在部門級開發,它可用於軟體維護、不斷增加的開發任務、平行開發、QA及測試,它面向大型團隊、利於交流、能最大限度地利用人力資源。目前主要工具為 IBM Rational ClearCase。

(三)過程驅動 ( Process Driven )

主要使用在企業級開發,著重解決新的工具引入、IT審核、管理報告、複雜的生命週期、應用工具包、集成解決方案、資料庫等問題,實現真正規範的團隊開發。目前主要工具為 CA AllFusion Harvest Change Manager; McCabe TRUEChange; Source Integrity Enterprise Edition。TOP

合適的SCM工具

僅僅意識到SCM的重要性以及可行性還是不夠的。根據大量的實踐經驗,最重要的還需要有一套軟體配置管理自動化的平臺,也就是一個以SCM工具作為實施的基礎。一套功能強大、實施容易、管理方便的配置管理工具,可以極大地提高配置管理的導入和實施效果。

當然,企業本身應根據其開發特性,選擇適合其本身等級的SCM工具。由於台灣IT、金融等產業正面臨加入了WTO的衝擊,筆者建議這些產業應使用第三等級的SCM工具。例如上面提到的 AllFusion Harvest Change Manager; McCabe TRUEChange 和 Source Integrity Enterprise Edition。

在這些SCM的產品中。Computer Associates公司所推出的AllFusion Harvest Change Manager是一套非常優秀的SCM工具。AllFusion Harvest Change Manager將配置管理和變更控制緊密地結合在一個產品中,並提供靈活的變更控制流程定制,支援從小團隊開發到大型專案實施的各種規模軟體專案,並具有簡單易用、快速實施、安全穩定的突出特點。另外最重要的是原廠技術和售後服務,在亞太地區包括台灣,CA具有很多成功案例。而且原廠技術顧問皆具有大型企業變更管理方案建置經驗。

在國外市場上的佔有率也非常高,現在正在被越來越多的國內用戶認可。我們相信,在不久的將來,SCM將成為所有軟體發展人員和管理人員所依賴和熟悉的管理手段。

版权所有:UML软件工程组织