使用 SPC 監控軟體發展流程

在軟體發展流程中使用SPC一直是許多公司所期望的目標，關於SPC是否適 用於軟體發展流程一直是一個爭論的議題之一，Lantzy最早開始探討這個議題的 [15]，他針對軟體發展流程要成功實施SPC，提出了七個步驟。該研究指出了以 下幾個重點：

 好的指標必頇要與最終產品品質具有高度之相關性。

 必頇針對產生實體物件的活動建構指標，例如：程式的撰寫。

 SPC必頇用在關鍵的流程。

 使用SPC的流程必頇有能力製造出符合規格的產品。

Kan[13]針對軟體發展過程的指標之理論與應用做了廣泛且深入的研究，他 認為繪製在管制圖上的點是在流程進行中(in-process)量測而得，不能代表產品的 最終品質，即在專案結束前永遠不會知道產品的品質，因此軟體品質的管制若要 做到與製造業一樣的即時(on-time)管制是非常困難。SPC在品質工程模型(quality engineering models)中是一項非常有用的工具，例如：缺陷模式(defect models)與 可靠度模式(reliability models)。

在2001年 High Maturity Workshop [19]中SPC是一個重要的議題，共有35個 CMM Level 4以上的組織參加此研討會，他們做成以下幾點結論：第一，CMMI Level 3的公司所使用的量測數據常常是無法使用管制圖進行管制的，因為這些量 測都還停留在專案階段等級(project phase level)，因此資料粗糙而無法提供Level 4所需要的解析度(granularity)。第二，由於太多共同因素使得變異太大時，可預

7

測性變差或者無法找到真正的可歸屬因素，使用管制圖的效果會很差，甚至比不 使用管制圖更差。

Weller[23]提供了一個成功運用SPC的實例，說明了缺陷(defect)雖然無法全 部移除卻可以有效的管理。整個流程可以分為兩階段，第一階段是監控編碼階段 後期的檢查流程(Inspection process)²，目的是希望流程是穩定的且可預測的，這 階段使用個別值移動全距管制圖(X-Rm chart)監控檢查速度(inspection rate)與準

3. 當有點超出管制界線時，必頇找到可歸屬原因(assignable causes)，確定此點 屬於特殊情況(special case)才可將此點移除；若其他資料點也受到此因素影 響，就算在管制界線內也必頇移除。

Florac 等人[7]利用 NASA 專案的資料展示利用管制圖來建立不同專案的流 程表現基準(process performance baseline, PPB)的詳細過程，他們針對管制圖首先 提出以下六點重要的觀念：

2在多種不同的同仁審查方式中，最正式及嚴謹的就是檢查(Inspections)， 檢查的活動依序為規 畫、準備、團體審查會議、矯正、驗證。

8

1. 選擇關鍵的流程。

2. 提供操作型定義。

3. 注意資料的同質性與合理的分群。

4. 使用正確的管制圖。

5. 了解多原因系統(multiple-cause system)與混合原因系統(mix-cause system)。

6. 測詴管制界線並且重新計算與更新管制界線。

Jakolte與Saxena兩位[11]針對軟體發展流程的管制圖經濟性設計提出一套成 本模型，目前軟體發展流程所使用的管制界限都是沿用製造業的三倍標準差觀念 而建，可是軟體產業與製造業不同之處是型二誤差所造成的成本比型一誤差大很 多，例如一個缺失如果在編碼階段已經產生卻沒被找到，到了測詴階段才被找到 的話，修正此缺失的人力成本會比在編碼階段大上很多倍，而且當超出管制界限 時並不需要停止整個軟體發展流程來進行修復，型一誤差的成本比製造業小很多，

因此這兩位學者建議軟體發展流程所使用的管制界限應小於三倍標準差。

Komuro[14]分享了HSE(Hitachi Software Engineering)在軟體發展流程使用 SPC的經驗，他認為在使用SPC於軟體發展流程時應該先監控的流程要視企業的 目的而定。若將SPC用於整個軟體發展流程只會增加企業的負擔。經由早期缺失 偵測比率(early bug detection rate)與最終缺失率(bug rate)的分析發現，在測詴階段 之前若能找到越多的缺失就會使產品品質明顯提升，如果想提升最終產品的品質，

則必頇監控測詴階段之前的同仁審視(peer review)流程。Komuro於是進一步分析 同仁審視階段與測詴階段修正缺失的成本，發現在同仁審視階段若能找到缺失會 節省一半以上的成本。Komuro建議使用X-Rm chart監控審視速率(review speed)與 審視效率(review efficiency)，使用Z chart監控缺陷密度，並示範如何找到共同原 因並修正管制界限，最後建立出PPB。

Sargut與Demirörs[20]認為SPC對成熟度低的組織也是有幫助的，他們使用某 家公司在進入CMMI Level 3前的資料進行分析，雖然此公司已經有定義良好的流

9

程與指標資料，但是要進行量化分析還是有困難的，在使用SPC前，有許多基礎 工作需要完成，包括：診斷公司的現況、規畫改進的方案、選擇指標、定義新的 流程、重新組織資料庫並找到初始的基準、使用其他量測來標準化指標資料。在 使用SPC之前的資料都是以表格、直方圖或柏拉圖等方式呈現，分析也是憑經驗 或直覺，而使用SPC後最大的好處即是可輕易找到離群值並偵測到特殊情況，且 在做決策的時候獲得很大的幫助。在管制圖方面還有以下兩個重點：

1. 當管制圖超出管制界限時必頇找到原因才能採取對的行動，例如以缺陷密度

為例，超過上限時可能是軟體品質差或者檢驗流程效率太好，而超過下限的 時候可能是軟體品質佳或者是檢驗效率太差，這時要因分析圖(Cause and Effect Diagram)是一個重要的工具。

2. 由於軟體發展流程的複雜性與許多外部的參數會膨脹資料的變異，如果只分

析單一特殊流程，則資料量可能太少，如果同時分析多個一般流程，由於變 異的膨脹則可能找不到某些失控點，因此我們常常在此做取捨。

Jacob與Pillai[10]使用管制圖監控編碼階段的同仁審視流程與缺失密度，並且 持續改善編碼流程。Manlove與Kan[16]使用管制圖監控設計、編碼、測詴與維護 階段的不同軟體指標。目前SPC已經成功地使用於同仁審視、編碼與測詴階段，

不過每個成功的經驗差異都很大，使用的管制圖與軟體指標也都不同，而且同時 監控多個管制圖在實際使用上較不方便。