總是要到驗收前，才會發現程式品質有問題？(下)

留下回應

分享

    

確認與驗證的過程

在軟體工程的領域中，確認過程代表確定開發產出滿足及符合原始的設計，也就是把事情做對。而驗證過程則代表檢查開發設計滿足或適合預期的使用，也就是做正確的事情。在台灣，一般大型軟體專案多半採用V-Model的軟體開發流程模式來進行軟體的確認與驗證。此開發模式展現了不同抽象層次觀點的開發作業與相關的測試作業之間的關係。

一般而言，我們會將軟體專案開發分為三個開發層次，高階的抽象層次為處理使用者的需求分析；中階的抽象層次則將重點置於將所了解的需求轉化為軟體架構；低階的抽象層次主要為系統功能的細部設計與系統實作。

在每個開發作業完成之後，開發者應當進行確認過程來確保開發作業符合需求及設計規格後才能進行下一個開發作業。而直到程式被實作出來之後，開發者必須依序按照不同開發層次的要求來進行驗證過程，以各種不同類型的測試作業來檢查軟體是否真能符合實際使用上的需求。如下圖所示。

V-Model

此開發模式配置了良好的結構方法，讓每個開發作業都可以根據前一個開發作業的詳盡產出來進行作業。而測試設計可以很好地提早在編程前就開始進行，如此將為專案省下大量的時間。但事實上，採用V-Model在專案後期仍然還是會從程式碼當中出現不少瑕疵，似乎按照規格來開發系統仍然無法解決需求與設計在專案後期因為經常變動而影響程式碼品質的困境。

為什麼會如此呢？從V-Model的開發流程結構我們其實不難發現到，愈高階層次的開發作業是愈晚被驗證的，而在它尚未被驗證前，較低階層次的開發作業都會因為它的變動而受到影響。例如，在系統測試時，如果發現軟體無法通過驗證的原因是因為需求規格的瑕疵，如此就必須回過頭來修正需求規格的瑕疵，並重新進行設計與程式開發。換句話說，不良的需求或設計往往會加重測試的負擔與壓力。

換句話說，愈高階層次的開發產出，其瑕疵是愈晚才會被驗證出來。而相較於低階層次的開發產出，其衝擊影響力又是相當嚴重的，因為這代表瑕疵將會在較低層次的開發產出中擴散與蔓延。因此在實務上要做到「早期發現、早期治療」，讓需求或設計的瑕疵盡早被發現與解決其實並不容易。除非需求與設計規格能夠儘早驗證完全無誤，然而，在程式在尚未實作出來之前，開發者又該如何做到這一點呢？

如何早期發現、早期治療？

如果對於需求或設計，開發者無法先驗證其可行性與正確性，而必須等待程式實作出來才能靠測試作業來加以驗證的話，那麼我們將會期望測試作業必須具備相當高的效率及足夠的涵蓋面。但實際上，測試的效率與涵蓋面會受限於專案的時程與成本，因此希冀測試作業能夠有效率地找出程式所有的瑕疵的想法往往是不切實際的。

因此，要用較低的成本與時間來達到最佳的程式品質，其關鍵並不在於測試的效率與涵蓋面，而是在於提昇需求與設計規格的品質。然而，我們該如何發展出較佳的需求與設計規格，並且能夠及早發現存在需求與設計規格的瑕疵以適時加以修正呢？

提早驗證、同儕檢視

筆者認為，開發者在進行分析及設計的過程中，就應該同時思考需求規格與設計該如何驗證的問題，而不是等需求或設計規格完成後才去設計驗證的程序。同時，在需求或設計規格交付之前，應該讓團隊針對欲交付產出進行實質上的技術審查，以集思廣義的方式促進集體反思，以找出分析或設計者所忽略的潛在問題與瑕疵。

在驗證需求或設計方面，在分析或設計過程就必須思考驗證需求或設計的具體方法。這代表了不一定要等實作設計的程式完成後，才能開始寫測試程式。如果我們無法依據設計來寫出測試程式時，其實正代表著我們設計的思慮多半是有問題的，我們對設計的想法可能還不夠具體，如此的設計是很可能存在許多我們所想不到的缺陷與瑕疵的。當然，先寫測試程式並不是唯一可以「在分析或設計過程中思考需求或設計如何驗證」的方式，不管採用任何形式的開發方法論，筆者認為都應該先想到如何以具體可行的方式來驗證需求與設計。

舉個例子來說，架構設計必須包含架構的概念驗證（POC，Proof of Concept）。架構設計者不應該省略驗證架構的程式，卻期待程式實作者來幫他實現未經驗證的設計構想。他必須自己親自驗證架構，透過驗證使自己設計的架構趨於成熟，而不致讓開發團隊在使用架構的過程中出現問題叢生的困擾。

而在技術審查方面，在設計過程中進行software inspection，除了可以提早發現需求或設計的瑕疵，更能促進團隊成員相互學習以提昇開發能力。品質不只要靠檢驗，而是不去設計有缺陷及瑕疵的系統。然而，不管開發者的分析或設計能力有多強，都不能保證其開發產出絕對沒有問題。在這種思維下，全員參與是一個好主意，同僚參與需求或設計規格的審查(peer review)可讓系統更趨於完善，一來可以用比較客觀的方式來確保設計符合需求及使用者需要，二來也可以讓同僚更清楚我們在做什麼，相互觀摩學習並增進團隊的效能。

因此，在思考如何驗證需求與設計的過程中，我們不知不覺地把焦點放在最主要目標的達成上，更有效地整合開發作業與測試作業。而讓同僚參與過程中，將有效撤除開發作業之間的藩離，透過同步的協同作業發揮一加一大於二的團隊綜效。其實同步與整合，正是讓程式瑕疵得以早期發現、早期治療。