UML软件工程组织

　　ISO 9000國際品質管理標準在國內已經推行多年，在中華民國資訊軟體協會、標準檢驗局、資策會、及各相關單位的大力推動下，國內目前也已經有四十家以上之資訊軟體公司取得ISO-9000認證。但仍有許多人對ISO 9000國際品質管理標準的有效性感到質疑，甚至有部份已推行品質管理系統的公司也未能全然受到品質系統的效益，反而覺得品質系統帶來額外的負擔。然而，不論由國外的報告，國內產業的成功經驗、或者國外企業的經驗等資料都明確顯示，有效實施ISO-9000品質系統的軟體業者，不論在品質或是成本上，都能得到絕佳的利益，甚至在AT&T的報告資料中更顯示在成功實施ISO 9000後，軟體人員的平均生產力幾乎得到跳躍性的成長。對於一個無論在學理或是實證經驗上均被高度肯定的標準，在執行面上所以產生此一落差，究其原因，往往在於品質系統導入時未能同時建立軟體工程觀念及技術，乃至急就章的套用不同產業的制度與觀念以快速取得認證，以致未蒙其利反先受其害。為與國內軟體同業共同建立真正符合所需的軟體品質系統，希望能藉本文與軟體同業共同探討此一議題。

一、 ISO9000品質系統的建置

　　ISO9000本質上是一個品質管理系統標準，在品質系統建置的過程中，對品質系統架構面提供了一個良好的指導，可以幫助組織建立一個完整且能持續改善的品質系統。由於ISO9000是一個架構面的規範，並成功的結合了學理與企業成功經驗，所以能成為廣被全世界各行各業接受的品質管理系統標準。
　　由於ISO-9000標準並不深入探討各行業品保技術與執行細節，因此在建置與推動ISO-9000品質系統時，必須依據產業及組織本身之需要，建立或引進適當之作法。不同產業間的觀念或者有相互參考學習的價值，但並絕不適合直接引用或要求，即使同一產業間不同的企業，其作業程序亦可能有相當程度之差異，而不能直接套用。例如以可接受品質為目標的商用軟體，與追求最高品質的航太軟體，其開發與驗證作業程序上便有迥然不同的思考與作法。
　　軟體同業在導入ISO-9000品質系統時，一個較為理想的作法應該是在ISO-9000的品質系統架構下，參照軟體工程方法與觀念，依據組織的需求與達成能力建立初期系統，並以持續改善的精神，不斷的檢討品質系統運作狀況，逐步改善整體系統的效能與運作成本。而一些軟體業的標準，如ISO-12207、ISO-15504等相關標準，亦提供建立軟體作業或流程標準的良好指導。或者如ISO9000-3:1997，雖然是配合ISO 9001:1994標準建立的指導綱要，仍然可以提供軟體同業一些很好的指導。

二、 ISO 9000與CMM

　　常常有人將ISO 9000與軟體業另一著名的CMM模式(Capability Maturity Model)相互比較。也常常有業界先進與筆者試著探討實施ISO-9000標準的軟體業約可達到CMM模式第幾級的標準。但筆者深感此一問題實際上似乎沒有定論。相較於此一專為軟體業設計，原文厚度超過500頁的CMM模式，連同附件算來總厚度不超過33頁的ISO 9001:2000標準對每一需求項目規範的詳細程度實在相去甚遠；但仔細比較ISO 9001:2000標準的要求項目與CMM各級標準要求的關鍵作業領域(Key Process Area，參看圖一)，除了如技術變更管理(Technology change management )等少數項目外，ISO 9001:2000標準要求的項目不僅近乎涵蓋了CMM規範的所有關鍵作業領域，更多了如管理審查。內部稽核、文件管制、資源管理等企業整體品質管理作業的重要項目。似乎一個徹底執行ISO-9000品質系統的軟體業者可同時滿足CMM Level 4，乃至Level 5的要求；某些國外人士確實亦有相同的評價。但由於ISO 9001:2000對每一要求項目的規定比較模糊寬鬆，即使通過認證的業者，也未必各個項目都能符合CMM模式的相關要求，如果是只為取得ISO 9001認證而建立的品質系統，更可能連Level 2的要求都達不到。因此，ISO-9000品質系統的有效性仍植基於企業建立制度化品質改善機制的決心。
　　不論ISO 9000亦或CMM模式都強調PDCA循環與持續改善的精神。但ISO 9000是以架構整體品質系統為優先，再透過持續改善的過程，加強每一流程到理想的程序。而CMM模式則對每一關鍵流程的導入有著較嚴格的要求，但以分批逐步導入的方式架構整個品質系統。雖然導入的邏輯不同，但如果能確實的建置、實施、與持續改善品質系統，兩者都可以為軟體業建置出一個能有效提昇企業競爭力與品質的品質系統。

圖一：CMM的關鍵作業流程
(引用自"Capability Maturity Model for Software")

三、 ISO-9000與軟體工程

　　如前文所述，ISO-9000標準提供品質系統的架構指導與需求，而軟體品質系統各項作業的方法與技術仍應仰賴軟體工程或相關標準之指導。依筆者之淺見，除了如管理審查、人員訓練、持續改善等一般品質系統的重點要求外，下列項目可能是軟體同業在推行ISO 9000品質系統時，值得特別留意的一些軟體工程重點項目。有志推動ISO-9000之軟體同業如能同時注意這些項目的制度化與改善，應可獲得明顯而效之利益。

(一)、合約與需求管理

對應條文

主要滿足7.2 顧客相關流程之產品需求決定、產品需求審查、客戶溝通等條款之要求。

基本要點

由於軟體產業的特性，與客戶在合約及產品需求上之溝通與管理，常常是軟體同業都備感困難的工作，也常常是軟體專案不能順利結案之關鍵。在需求管理上，應注意以下項目之達成：

(1)	合約審查與授權流程
	妥善審查合約條款及提供客戶之產品資訊，以避免因不當的合約內容或業務承諾而造成公司重大損失。
(2)	需求訪談時之方式與記錄
	有效的與客戶溝通，確認客戶需求，尤其是不同部門間的需求，並妥善的記錄與確認。
(3)	需求變更之管理與記錄
	當客戶需求變更時，應有適當之處理方式與記錄，以免造成雙方日後的困擾。

改善方向

除了基本要點外，隨著制度的執行經驗與持續改善，可以逐步實施與引進以下項目，以改善需求溝通與審查工作：

(1)相關領域經驗與知識的累積
	在重要業務領域培養有經驗之系統分析人員或顧問，以更能有效掌握客戶需求，甚至為客戶改善作業。
(2)檢查表之設置與改善
	建立需求檢查表，用以檢驗合約與需求規格之完整性與適切性。檢查表應隨著使用經驗及技術演進而增修其內容。
(3)需求分析方法與技術之改進
	引進更好的需求分析方法或技術以改善需求分析工作之效率，如使用者更容易瞭解的需求表達方式，或如快速雛型法、螺旋開發模式等改善與使用者間互動的開發方法。
(4)需求審查技術的引進
	除了需求分析方法的改善外，需求審查技術的改善，也有助於改善需求品質，如與使用者共同實施的檢視作業(Inspection)，即為一例。

(二)、軟體開發流程與標準

對應條文

主要對應到如"7.3.1.設計與開發規劃"，"7.3.2設計與開發輸入"，"7.3.3.設計與開發規劃輸出"，"7.5.1生產與服務供應的管制"，"7.5.2生產與服務供應流程的確認"等條款之要求。

基本要點

引進或建置適當之軟體開發流程模式及標準，以確保軟體人員採行一致且適當之開發方法。在建置軟體開發標準時，參酌引進相關標準可能是一個很好的作法，如ISO12207，SDG2.0等標準；但自行建立或使用內部標準亦無不可，重點在符合企業及客戶之需求。

改善方向

隨著軟體開發作業的經驗的累積與技術的提昇，可以朝以下方向改善：

(1)建立細部作業指引
	如 Coding Standard，Naming Convention，程式師守則等細部指引之建立，將實際有助於程式品質及系統可維護性的提昇。
(2)新的開發技術或流程的引進
	引進如UML模式，元件開發技術，Iterative 開發模式，Build開發模式等新的方法或技術，並建立程序準則，以改善開發作業之品質。

(三)、建構管理之實施

對應條文

主要符合"7.3.7 設計與開發變更的管制"，"7.5.3 鑑別與追溯"， "8.3 不合格品管制"等條款之要求。

基本要點

由於變更而造成系統內部版本紊亂是軟體品質的大敵。尤其系統人員常常不願意集中管制程式，使得此一工作更加困難。在建構管理上，至少應達到以下要點：

(1)	軟體產品最新版本之管制
(2)	開發中版本與發行版本間之有效鑑別與區隔
(3)	變更需求之管制，確保變更工作是在良好的協調與管理下進行。
(4)	產品發行管理，包含產品發行時機評估，產品變更清單建立，發行對象掌握與管理等要項。

改善方向

大多數的軟體專案事實上一直飽受版本管理問題之苦，若能實施一定程度的建構管理工作，通常會立即感受到好處，尤其越大型的專案越明顯，此時可進一步推動如以下項目之改善事宜：

(1)	文件一致性之管制，確保不同文件在變更過程中能即時的同步變更。
(2)	變更評估與管制，實施變更評估與管制作業，對每一變更適當評估其影響範圍及處理方式，再作變更，以避免因變更作業產生的副作用或後遺症。
(3)	多版本控管，設計機制以保留多版本之建構項目，以因應回溯及變型(Alias)之需求，更有效的支援各種開發及維護作業需求。
(4)	"#000099" face="Comic Sans MS">(5)	自動化工具之引進，搭配引進自動化工具，使得建構管理工作能被更有效率的進行。

(四)、軟體審查與驗證

對應條文

主要對應"7.3.5 設計與開發審查"，"7.3.5 設計與開發驗證"，"7.3.6 設計與開發確認"等條款之需求。

基本要點

開發過程中之審查與複核作業被證明是確保開發品質，降低開發成本之有效措施。在實施上必須明訂每一開發工作項目或階段之審查方式、審查人、及審查時機，賦予審查所需之資源，並確認審查工作之有效進行。

改善方向

軟體同業一般採用之審查方式常是主管審核或同仁查核(Peer Review)，但常常未賦予適當之時間資源，而且此一方法之有效性事實上亦有待加強。因此，當公司日益發展之後，可考慮以下之改善方向：

(1)	引進正規之查核方式，如檢視(Formal Inspection)，徒步檢查(Walkthrough)，技術複核(Formal Technique Review)等方式，以加強審查效果。
(2)	新的開發技術或流程的引進建立審查查檢表，以加強查核工作之效果，並依查核經驗不斷改進查驗表之內容。

(五)、軟體測試

對應條文

主要在符合"7.3.5 設計與開發驗證"，"7.3.6 設計與開發確認"，"8.2.4 產品的監控與量測"，"8.3 不合格品管制"等條款之要求。

基本要點

軟體測試工作宜建立以下符合基本要點之制度：

(1)	具備有效規劃整個測試工作範圍、方法、人員、及時間之測試計畫。
(2)	清楚的測試項目，並予以審查以確保測試工作之完整性與適切性。
(3)	良好的問題管理程序，記錄、管理、與追蹤測試時所發現的問題。

改善方向

良好的測試工作是產品品質的重要保障，也是專案成功的重要基礎作業，惟國內目前在此一部份仍然有很大的進步空間，軟體同業可朝以下方向再改善測試工作：

(1)	賦予測試工作所需之人員與時程，擺脫由程式人員自行測試或將程式直接交給使用者測試之傳統作法，避免因人員盲點或使用者技術不足所造成的影響。
(2)	引進測試技術與方法，或建立測試工作指引，引導測試人員對每一測試項目進行更完整有效之測試。
(3)	建立與專案發展工作密切配合之漸進式測試方式或採用螺旋開發模式，提早測試工作時間，以達到預防錯誤擴散之效果。
(4)	建立測試管理制度，以有效管制測試工作之有效執行。
(5)	引進自動化工具，提昇測試工作效率。

(六)、專案管理

	1.	對應條文
		主要在符合"7.1 產品實現的規劃"，"7.5.1生產與服務供應的管制"等條款之需求。
	2.	基本要點
		由於軟體產業，尤其是系統整合公司，每一專案的時程、規模、組織、環境、方法、技術等各方面可能都有很大的差異性，不容易以固定的程序統一規範，而必須於專案計畫中作細部規劃，良好的專案規劃與管制作業是軟體專案成功的基礎。圖一亦顯示CMM將專案規劃與監控追蹤列為Level 2的二個關鍵流程，足見其重要性。
	3.	改善方向
		為了強化專案規劃與追蹤管理工作，企業可逐步引進量化的專案管理、專案績效評估、專案成本估算與量測，科技人員成長管理(可參考People CMM)。另外，配合開發工作流程的改進，以Build Integration或螺旋式的開發方式，亦有助於增加專案的有效查核點，改善專案管理效能。

(七)、系統維護管理

	1.	對應條文
		主要在滿足"7.5.1生產與服務供應的管制"，"7.5.2生產與服務供應流程的確認"、"7.5.5產品保存"等相關條款之要求。
	2.	基本要點
		軟體維護工作時應注意客戶需求評估與管理、變更管理、產品發行管理等要項，並注意資料蒐集與統計工作，以作為改善產品及開發流程之依據。
	3.	改善方向
		維護階段與客戶間存在密切的實質互動，可以有效的蒐集與評估軟體產品之品質與特性資料，作為後續產品及開發流程改善的重要依據。此外，透過問題統計分析作業的有效運作，可以使維護階段不僅於消極的回應客戶需求，更可主動的提昇產品與服務；不僅降低維護服務成本，更能有效的維繫客戶關係。實證經驗顯示，成功的維護案往往比開發案更能創造利潤。

(八)、量測與統計

	1.	對應條文
		主要滿足"8.2.1 顧客滿意"、"8.2.3流程監控與量測"、"8.2.4 產品的監控與量測"、"8.4資料分析"等條款之需求。
	2.	基本要點
		統計量測作業是產品與流程改善的重要輸入，透過統計量測作業才能有效改善軟體流程，並遂步建立軟體量化管理作業。諸如問題數、客戶抱怨數、生產力、人力成本、專案成本等各項數據應該都是不難量測，並能為企業帶來明顯效果的量測項目。
	3.	改善方向
		量測作業與資料分析結果，應作為企業持續改善之輸入。軟體量測項目應可用於評估與改善開發流程、專案管控作業、產品品質量測等用途。長期累測統計之結果應可作為專案成本估算與管控基礎，透過可靠度估算作業並可作為產品放行時之參考依據。使得軟體專案可以量化的方式管理與評估。

四、結語

　　良好的品質系統可以為企業帶來重大的利益，筆者曾經在客戶端實際觀察到以下各項效益：

1.減少客戶變更需求之爭議
2.縮短驗收時程
3.提高專案利潤
4.減少人員流動的影響
5.改善專案內部管理，降低專案失敗風險
6.強化內部溝通工作，提昇組織之整合度與內部管理。
7.提供公司主管貫徹管理理念之有效途徑
8.提高產品品質，降低失敗成本。

　　如果不當的建置與執行品質系統，常常反而造成公司重大的負擔與進步的阻礙，而失敗因素通常來自推行心態上的迷思。依據SEI的統計，軟體公司每推進一個CMM Level，平均約需20個月左右的時間。但國內軟體公司卻常常迫於績效或市場需要，而期望在六個月以內通過ISO-9000認證，通過後亦不積極於進行持續改善。或者亟亟於以最少的成本建立與實施品質系統，但卻無視於因品質不良所造成的成本與損失，類似偏差，都造成企業不能獲致品質系統之效益，殊為可惜。
　　ISO 9000國際品質管理標準為企業提供一個良好的品質系統架構，但軟體同業仍應基於軟體工程之理念與需求建置符合本身所需之品質系統，並致力於持續改善工作，以真正獲致品質系統之效益，成為真正的贏家。　