從生產管理角度檢視軟體品質的責任

最近常在思考，軟體開發的品質到底是什麼，我們能承擔的品質出問題的風險有多大？在軟體開發過程，無論你是走Scrum或是DevOps的開發流程，都希望交付出來的軟體品質是好的，因此，每當談軟體開發中的測試種類就包含這些議題

• TDD
• 自動化測試
• 測試左移
• 增量測試
• 整合測試
• UI測試
• …

在DevOps也透過不斷持續性高頻率的佈署降低系統問題帶來的損害。不過，我認為這些都是在軟體工程面的手法。說穿了這些責任其實都是落在工程團隊（在DevOps中QA人員是併在工程團隊），換句話說一旦出事情都會是在工程團隊身上，但是，對於品質這個範疇真的只有工程團隊責任嗎？或許我們從工業工程在生產製造過程對於品質的角度來看軟體開發品質這件事情

品質工程

品質管理這個詞最早是被運用在生產製造領域，也因此針對品質管理開始有了這種手法，例如:TQM、SPC、品管七大手法、六個標準差…等等。而對於品質定義是

• 品質是適合使用
• 品質是符合要求或規格
• 品質是在競爭的價格下，滿足顧客的需要和期望
• 品質是產品出廠後，對社會所造成的損失
• 品質是精準

也因為這樣所以在生產製造過程中，總是會針對品質訂定許多指標避免不良產品流入到市場。當然，也因為這樣要維持一個好的品質產出，也不是一種佛心事業，要有好的品質，伴隨而來就是要投入一定的品質成本：

• 鑑定成本(appraisal cost) : 投入於檢驗、測試及發掘不良等所花費之成本
• 預防成本(preventive cost):為了防止不良產品(或服務)發生所支出之成本
• 內部失敗成本(internal failure cost) ：指產品、零件或物料交給顧客之前就發現未達到顧客之品質需求條件所造成之費用
• 外部失敗成本(external failure cost) ：將產品運交顧客之後，因為發生不良品或被消費者懷疑為不良品所支出之成本

其中，預防成本與鑑定成本係發現不良品之前的成本，稱為事前成本，而內部及外部失敗成本是發現不良品之後的成本，稱事後成本。事前成本是企業比較好控制的一環，大多數企業會盡量讓事前成本和品質水準達到一定的平衡點，所以，不可諱言的當你需要有一定品質，就是必要投入一定的成本與時間。

如果，換到軟體開發角度上，大多數的決策者或是需求者，卻往往不這樣認為，認為用原有成本與時間就可以達到良好的品質。在軟體開發過程的原有成本就變是原本的開發人力，時間就是能完成一個能動功能的時間。要在這些不變情況下提升軟體品質，這是多麼不可思議的事情。

再者，製造生產是可以透過複製多條生產線來攤平品質成本帶來的影響，這是取決於每條生產線是可以生產相同產品，產生出相同價值而攤平成本。但是軟體開發可以嗎？從這下面這張圖來看

軟體開發真正能Repeating相同開發相同程式碼是不太可能。舉例來說同樣都是開發Ｗeb的查詢功能，不同需求背後串接的API也不一定相同，User想要的介面與行為也不同，看似相同其實是有差異性。就像是製造一台Toyta和一台BMW，同樣都是做一輛車，但是背後的生產流程也是不同。絕對不可能用同樣生產線可以同時生產Toyta和BMW。因此，對於每一次開發來說，不同需求，換言之就等於是一條新開的產品生產線，是需要投入相對等值的品質成本才能確保品質。不會說之前做過或是這只是小修改，這樣就不會出錯之類的幻想

可靠度工程

談到品質工程中，又往往會講到可靠度，當然在軟體開發中，軟體品質與系統可靠度往往都會被列入同等考量或是相同定義。而在可靠度工程中，最有名的就是所謂的浴缸曲線，且失效時間(MTTF)與失效率則是在可靠度工程中兩個觀察指標

一般來說產品製造談到的可靠性，首先談論的會是先期的設計的可靠性，在設計的可靠性，它會具有下列幾點要素

• 產品可靠性決定於設計階段
• 產品可靠性必須由團隊共同負責，包括設計、製造、品管、採購等部門成員
• 製造過程只能依設計之可靠性來滿足其特性，並無法透過製程來提昇可靠度水準
• 品質管制只能依現有的製程水準控制在穩定的狀態，它也無法提昇可靠度水準。

如果換成軟體開發要素來看

• 系統可靠性決定於需求階段
• 系統可靠性由團隊共同負責，包括談需求者、開發者、測試人員、SRE等成員
• 開發過程只能依需求可靠性滿足其特性，並無法透過開發者能力提升可靠度水準
• 測試只能控制系統品質能符合需求水準，也無法提升可靠度水準

為什麼我認為可靠度的浴缸曲線其實跟軟體開發很相似。在軟體開發早期，一定會遇到許多bug，所以，會透過不斷測試與修正，達到一定穩定後交付給用戶使用，基本來說User使用的階段所遭遇到失效率是相對低的。

而當系統運行一段時間，難免會因為資料的增長、流量增加或是元件或語言版本的過時，造成一定系統失效機率，一種比較常發生案例就是用的元件有問題，但因為版本過舊，現在也無法被Support與修改，就會走向老化失效

而大部分架構規劃不錯，且有不斷投入維護資源，該系統就會比較偏向早期失效，發生老化失效時間就會被拉長。我們可以發現一件事情，不管可靠度工程與品質工程如何運用，都不可能讓一個產品達到0失效又或是所謂SLA為100%（能到達99.99995 %之類，是需要投入相當多成本？）

試想，如果今日需求設計不斷變更，要求時間更短，而其餘條件不變情況下，發生系統失效率與失效時間又會有多大呢？

軟體品質

曾記得有一個老前輩跟我說過品質是做出來，後來才理解，真正含意則是

品質是「設計和製造」出來的，不是檢查出來的

軟體設計來自於需求面，軟體設計來自於開發面。這兩者絕對會是屬於1+1的類型，如果當前者為0，無論是哪種優秀開發者也無法讓1+1變成2。而當產品（需求）不斷變更設計，生產線（開發者）可以立即就生產（開發）出高良率的產品（系統）。

在敏捷的時代與快速變化的市場，當然不可能說一切需求都是很明確才能開始開發，這樣似乎也跟不上時代（市場）潮流。因此，當我們都在追求時間與速度的同時，則會讓Ｘ和Ｙ變成一種不可控的變數，那就必須評估X+Y所產生風險是否是大家能承擔，而承擔這個責任絕對不只有一方的責任。而是從需求到開發過程的成員都必須共同承擔這項責任。

有時候，我自己也很好奇在製造業中對於如何產生出高品質與高可靠性的思維都相當充分與理解，但是面對於軟體開發（生產），卻可以自動忽略這些層面。

我認為會影響軟體品質好壞的因素是相當多，包含:

• 需求透明度
• 需求準確度
• 時間成本
• 人力成本
• 架構/程式設計
• 測試

測試工程其實只是軟體工程一部分，但是，卻有許多認為只要測試好，就能一定達到SLA 100%，如果達不到，就一定測試沒做好或是開發者能力問題。此外，也因為在軟體開發過程中，品質成本支出並不會在財務報表上記上一筆，也讓人往往忘記軟體品質提升也是需要有相對應成本

我想在軟體開發品質上我們也因該從另一個角度來看待這項事情，才能在平衡各項因素下，做到我們所能承擔風險的軟體品質。而不是在理想幻想品質就會自動產生，再者，現在軟體開發複雜度已經比以前高很多，挑戰也是，想要用以前標準與思維是行不通的。而在現實場域也常常遇到，需求者在沒有與開發者相互溝通下，自認為一個小小需求異動或是功能變更，只是一個很簡單事情，有這樣思維是相當可怕，這樣其實不僅破壞整個團隊效率也破壞整體系統可靠度。例如:想要在報表多一個欄位，看似web直接加一個來欄位就可以，而這欄位是原本沒有被設計的(需求沒提到)，其實修改部分簡單看來就必須從Web →API →SP →Table，更別說是資料來源要怎樣處理?資料要如何寫入?是否有其他外部系統也在使用也需要修改?Index是否需要?強行別Model異動修改…等。而只是被認為只要加一個欄位就好。尤其，當今日我們期望系統做得越彈性功能越強大又能串接更多資料或是平台的同時，其相對架構也越複雜了。

在硬體思維下，金錢是很容易被衡量，但是軟體往往花費是人力與心力，因為無形，所以自然就被認為理所當然，也就忽略其成本效益