改善軟體品質的新趨勢－從改善工作方法與引進新機制談起
作者/葉翔騰 [發表日期：2015/12/4]
前言
品管，雖然是把守產品釋出的最後一道防線，但是品管的手段絕不是在最後釋出階段（Delivery Phase or Release Phase）才啟用，唯有將缺失「發現」點（也就是採用品管手段之處），擺在距離缺失「發生」點越近越好的地方，才能使投入的成本效益達到最高！
本文將把軟體開發生命週期分成四個階段(如圖一)，提出各階段的工作方法如何調整、應該採用哪些新的機制，以取得最高的品管成本效益。這四個階段分別為：需求蒐集、系統設計、程式設計與釋出測試。
《圖一》軟體開發生命週期
需求蒐集
在需求蒐集階段可以解析為：需求涵蓋、塑模分析方法與需求描述等三個面向，如此即可找出可以改善工作品質、引進新機制的解決方案(如圖二)(註一)。
《圖二》提昇需求蒐集階段品質的策略
一、需求涵蓋
以需求涵蓋而言，主要的目的是要降低需求遺漏的風險，最有效的策略是將需求進行分類，比方說，分成：
- 功能需求：指的是一般的使用者所關心的操作功能、企業流程，如：『營業員的一天』；
- 架構需求：則是使用者會忽略(註二)、但是上線之後營運人員會關注的需求，涵蓋：管理、安全性、效能、可靠性、可稽核性、可移植性、可修改性等等，在一般的情況下，這一類的需求是專案整體考量；
- 人機界面需求：則是聚焦在使用者的操作界面，諸如：使用者需要的輸入設備是鍵盤、數字鍵盤、觸控式螢幕、滑鼠、平板電腦、觸控筆等等。此外，更細緻的人機界面需求則屬於人因工程的範疇，包括：顏色的選擇、螢幕的配置、操作的順序與操作的提示等等。
二、塑模分析方法
而塑模分析方法，則著重在：
- 透過物件導向塑模方法，以不同的面向來審視需求(註三)，確保需求的完整性；
- 採用分析樣式（Analysis Pattern）(註四)，縮短分析的時間，並有效提昇分析的品質。
三、需求描述
最後，需求描述則是要思考如何做為後續專案管理的標的，有底下幾個方式：
- 流程：企業需求是以數個流程組成，因此比較適合以流程為最小需求描述單位，做為後續的專案進度管理單位；
- 使用案例：透過描述一連串使用者與系統之間的互動，做為後續的專案進度管理單位；
- 混合型：由於一個流程，往往過於龐大，因此可以切成數個較小的使用案例，做為比較有彈性、精確的專案進度管理。
簡單為這一個階段的品質提昇策略做一個結論：
- 以塑模技巧、需求分類，讓系統分析師能看到多個面向；
- 以多個面向，確保需求的涵蓋度；
- 繼承成熟的分析樣式，縮短分析階段的時程、減少分析缺失的風險、提昇分析品質；
- 選擇適合專案特性的需求描述方式，做為後續專案管理的標的。
系統設計
在系統設計階段，能夠提昇品質與降低後續修改、維護成本的策略，除了採用物件導向設計、慎選設計樣式（Design Pattern）之外，還要以能提升後續自動化測試與縮短釋出時程進行設計，如圖三：
《圖三》系統設計階段的品管策略
這個階段的主要策略，是將程式碼依據它的特性加以分類，放在它該放的地方(註五)：
一、人機界面程式：
- 將輸入檢核的程式碼集中置於相關的輸入元件中；
- 將與企業流程判斷相關的程式碼，盡可能置於伺服器端，若無法這麼做，也要將這類程式碼集中於一個物件；
- 提高共用人機界面元件的比例；
如此，就可以透過該元件的自動化單元測試（詳述於下一階段），有效提昇自動化測試的比例。
二、伺服端程式：
可以將企業流程分成兩個部份：
- 流程控制：負責主要企業流程的控制，會叫用許多企業邏輯判斷元件；
- 企業邏輯：被流程控制叫用的元件，該元件內有許多單純的企業邏輯 method；
舉例來說，一個處理員工特休假的程式，可能包括：讀取員工基本資料、判斷年資、判斷特休假天數與寫入特休假主檔等四個程序，可以將其拆成：
- 企業邏輯元件：員工基本資料處理元件（含年資判斷、特休假天數計算等method）、員工特休假元件（含新增員工特休假記錄等method）；
- 特休假流程控制元件：負責叫用員工基本資料處理元件，以取得特休假天數，再叫用員工特休假元件，以產生新的員工特休假記錄，以及相關例外處理、Log 紀錄等流程控制。
如此，就可以透過該元件的自動化單元測試（詳述於下一階段），有效提昇自動化測試的比例。
簡單為這一個階段的品質提昇策略做一個結論：
- 依據程式碼的特性加以分類，可以讓程式設計師在撰寫流程控制時，專注在流程；撰寫企業邏輯時，專注在單純的企業邏輯；
- 適當的分類與拆解，不僅能提昇元件在使用率，也能減少缺失；
- 這些元件的單元測試程式，可以在釋出測試階段再利用，可以有效提昇釋出版本的品質及縮短釋出的時程。
程式設計
下圖四說明在程式設計階段的品管策略：
《圖四》程式設計階段的品管策略
本階段的主要策略就是提供一個有效的機制，將發現/發生程式碼缺失的時間點重疊：
一、採用單元測試框架（Unit Test Framework）
- 此框架已被廣泛運用在所有主流程式語言，包括：Java、.Net、C++等，且與開發工具（IDE）緊密結合；
- 此框架提供常用的預期結果比對、測試程式的啟動、執行結果的彙整等等，程式設計師不需再花時間撰寫這些程式碼；
- 此框架大幅降低程式設計師單元測試的負擔，大部分的情況下只要把參數、預期結果傳給單元測試框架，此框架即可幫程式設計師進行測試、比對、產生報告。
二、程式碼覆蓋度（Code Coverage）量化數據
- 程式碼覆蓋度（Code Coverage）量化數據 = 單元測試所經歷過的程式行數/該元件總程式行數 × 100%，一般要求的標準為 80~85%；
- 各主流程式語言都有程式碼覆蓋度（Code Coverage）量化數據的工具程式，與開發工具（IDE）緊密結合，可以與單元測試框架配合，在單元測試過程記錄/產生該量化數據；
- 程式設計師可以根據該工具，檢視自己所設計的單元測試程式，透過增加不同參數、叫用不同 method 的手段，提昇測試覆蓋度。
簡單為這一個階段的品質提昇策略做一個結論：
- 單元測試框架，讓程式設計師可以在最小負擔的情況下，確保自己產出程式碼的品質；
- Code Coverage則能提供具體量化數據，有效降低程式設計階段發生缺失的機會。
釋出測試
最後在釋出測試階段，最主要的策略就是採用『持續性釋出』的機制(如圖五)：
《圖五》釋出測試階段的品管策略
持續性釋出（Continuous Delivery）包括：
一、結合版本控制機制，自動從Source Tree(註六)簽出（Check Out），並簽入（Check In）Test Tree(註六)。
二、結合自動化Build機制
三、結合單元測試機制，產生單元測試與Code Coverage報告。
四、結合自動化佈署機制，將此版本佈署於測試環境
五、結合自動化功能測試，產生功能測試報告
簡單為這一個階段的品質提昇策略做一個結論：採用持續性釋出的機制，就是要持續快速釋出一個版本，只要能持續性快速釋出，就能在缺失發生後的最短時間，發現缺失的存在。
結語
加諸在所有開發階段(Phase)的品管手段，並不侷限是增加一個管理流程（如：回報進度），有時候只是一種工作方法的改善。本文透過軟體開發生命週期的四個階段，提供各階段的品管相關策略，有許多都是工作方法的改善，如：需求分類、需求塑模、分析樣式、需求描述、程式碼分類歸位等等，也有採用的新機制，如：單元測試框架、Code Coverage、持續性釋出等等，都是目前軟體品質管理的趨勢，對於軟體品質的提昇與成本的下降，確實有立竿見影的效果。
【註一】一般會將第一階段描述為需求分析，本文則改為需求蒐集，主要是為了凸顯需求涵蓋與需求描述兩個議題。
【註二】同一時間大量的購票需求湧進網站，造成網站癱瘓，就是屬於這一類的需求。
【註三】物件導向最有威力的地方是透過命名（Naming）、賦予責任（Given Responsibilities），就可以把焦點從該物件的細節，轉移到與該物件有關的其他資訊。
【註四】分析樣式（Analysis Pattern）是在系統分析階段，可以被重複使用的概念性塑模（Conceptual Modeling），由於已經被廣泛採用，故其成熟度必然很高。
【註五】把程式碼放在正確的地方，是『Refactoring 重構』的一個主要精神，有助於抓蟲（Debug）與維護。
【註六】組態管理（Configuration Management）所控制的檔案版本，會以檔案的樹狀結構來儲存，依據釋出的程序，一般至少會有三棵樹狀結構：
- Source Tree（來源樹）：儲存開發團隊所交付的原始來源版本
- Test Tree（測試樹）：儲存Build 成功、待測試的版本
- Release Tree（釋出樹）：儲存釋出的版本