科技新知

改善軟體品質的新趨勢-從改善工作方法與引進新機制談起

作者/葉翔騰   [發表日期: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(釋出樹):儲存釋出的版本