軟體工程與CMMI

最近流傳一句話，“CMMI是什麼？CMMI就是讓你每天晚一個小時下班”。身為這句話的原始作者，我有必要指出，這句話還有下半句，而且更為重要。“如果自己不想辦法把事情做好，這一小時將永遠補不回來，而且可能得不到預期的效果。

我在此要強調一個觀念是，我們要作的是軟體工程，而不是或不只是CMMI。事實上，CMMI中的流程領域（ProcessArea），除了組織面的幾個領域，莫不都涵蓋在軟體工程中。因此，只要軟體工程做得好，CMMI自然就沒有問題，而且可能不只補回一小時。反之，如果沒有把軟體工程做好，則CMMI就真的只會讓你晚一個小時回家，而且這一小時將永遠補不回來。

何謂「軟體工程」？

什麼是軟體工程？從歷史的眼光來看，軟體工程是軟體危機（SoftwareCrisis）之後的產物，也是歷經一串軟體的慘案後，大家才逐漸了解要開發一個比較複雜的軟體系統，必須遵循一定的開發流程，遵守一定的工作步驟，才能順利完成。早期的電腦，基本上是數學家及科學家的工具（或玩具），主要都用來做數學的運算，因此大部分的程式都是一個人獨力完成的。在這種情況下，程式大多是屬於個人的創作，而且自己就是使用者，因此，可以想到哪裡就寫到哪裡。可是當硬體的運算能力變強之後，電腦可以做的事情也越來越多了，此時的軟體不再是個人創作，而是團隊合作的成果，但是在沒有標準工作程序的狀況下，慘案就不斷發生。至此，大部分人才充分理解到，軟體開發也應該和其他領域的工程專案一樣，要先確認需求，要先有系統設計然後才能撰寫程式，再經一系列的測試才能交付給使用者。這就是我們一般通稱的瀑布開發模式（WaterfallModel），而這樣的開發流程，在其他工程領域，如建築、機械等，其實都已行之有年了。因此，這樣的開發流程，並不是軟體工程所獨創，而是根據其他工程領域的成功經驗，再結合軟體的特性而來的。

何謂「標準工作程序」？

什麼是一個標準工作程序（Process）呢？或者我們為什麼需要制訂標準工作程序呢？我們制訂標準工作程序的主要目的是要將一件工作的最佳實行（BestPractice）的步驟記錄下來，以便我們自己日後，甚至於任何人，只要遵循這些步驟照著做，都可以得到最佳的結果。就好像食譜一樣，只要每一步驟都照著做，就可以烹飪出一道美味的菜一樣。而前述的瀑布開發模型，其實就是其他工程領域的最佳實行演進而來的。但是我們的最佳實行是怎麼來的呢？一是參考別人，二是不斷嘗試。有一句台語，「有樣學樣，沒樣自己想」，正是最好的寫照。當我們作一件新的工作時，如果我們沒有前例可循，土法煉鋼或是暴力法常是我們採用的方式。若是成功了，或許會覺得運氣真好，瞎貓碰到死老鼠。但是下次呢？如果我們沒有把成功的步驟記錄下來，下次還能碰到死老鼠嗎？如果我們能把成功的步驟記錄下來，任何一隻瞎貓，只要照著做，每一次都能碰到死老鼠。這就是我們為什麼要制訂標準工作程序的主要原因。

CMMI改善工作程序　落實基本動作

CMMI基本上是一個工作程序改善（ProcessImprovement）的框架（Framework）。CMMI所要問的，不只是做對了沒、做好了沒，而是我們可不可能做得更好。因此CMMI的程序才要去稽核做對沒，做好了沒，因為如果連做對做好都談不上，那何來改善?實際上，軟體開發的工作程序，一直都在持續演化中，而且也都有新的工作程序模型出現，每一種新的程序模型都是為了改善舊的程序模型的缺失。例如傳統的瀑布模型最主要的缺失是如果誤解了使用者的需求，往往必須等到系統完成才真正知道，可是此時為時已晚，而且修正的代價往往很高。因此，就有了雛形模式（Prototyping）及反覆式模式（Interactive），乃至於最近在學術界十分流行的輕快式（Agile）及極致式（ExtremeProgramming）等模式，莫不是針對目前常用的開發模型的某些缺點，提出可能的改善方案。

雖然CMMI的目的是工作程序的改善，CMMI也可以用來幫助選擇比較適合的開發模式，但是CMMI真正重視的是基本動作的落實。以CMMI的工程程序領域（Engineering ProcessArea）來說，其所規範的如需求展開、需求管理、技術解答（包括設計以及實作，TechnicalSolution）、產品整合、驗證以及確認等動作，不論採用那一種開發模型，這些動作都是一定要有的，只是在不同的開發模式中，這些動作的型態會有所不同。例如在Waterfall模式中，需求展開是在前面階段，透過密集的使用者訪談將之完成（理想狀況下）而在XP（ExtremeProgramming）模式中，則透過一次又一次的使用者故事（UserStory）慢慢將之組合出來。雖然做法不同，但精神是一致的。也就是說，CMMI只會要求你做哪些動作，至於如何完成這些動作，則是由組織自行決定的。另一個比較特殊的例子是專案規劃（ProjectPlanning）。一個專案若是採用Waterfall模式，則專案範圍、產出及專案時程可能在專案啟動就大致完全確定。但如果是產品開發，則也許採用反覆式模式，雖然一般而言，產品的範圍及專案時程在啟動時也許無法完全決定，但每一次在Interaction開始之前，則應該已決定好這次Interaction的範圍及時程。因此，我們相當於把一個較大的產品開發拆成幾個較小的專案，所應該完成的工作並無兩樣，在這裡我們特別要強調的是，不管專案或產品開發，無論是採用哪一種開發模式，主要的基本動作都是相同的，也都是不能省略的。

文件是溝通的最終且必要媒介

許多人對推動CMMI的怨言主要在於文件的要求太多，為此我們必須要先特別了解文件產生的目的在於溝通的需要，而不是來自流程，或是CMMI的要求。如果只是為了CMMI的要求而產生文件，那真的以後永遠都要晚一個小時下班了。以目前大部份專案或產品開發來說，大都需要一個團隊的合作與努力，才能順利完成，因此，使用者、管理階層以及團隊成員間的溝通協調都是絕對必要的。雖然有專案會議、審查、平時的聊天、電子郵件等各種正式及非正式的溝通，但是文件是溝通的最終且必要的媒介。

以使用者需求確認這件工作來說，我們有沒有可能僅僅透過使用者訪談以及和使用者的專案會議就能完全確認？我想許多人都會認為不可能，至少不太可能，因此我們就必須要撰寫使用者需求工作說明書，系統功能清單等文件。這些文件的主要目的是什麼？是為了和使用者溝通，而不是CMMI的要求。

再以系統設計這件工具來說，SA在告訴PA或程式設計師要實作那些功能及程式時，可不可能只靠口頭交待，就能將資料模型(DataModel)，E-R Diagram及Tableschema完全解釋清楚，如果有兩個以上的PA時，只靠口頭溝通就能完全一致且清楚嗎？如果不能的話，是不是要把資料模型寫成文件。因此文件的另一目的是為了專案成員之間的溝通，而不僅是CMMI的要求。除非使用者另有需求，在系統完成之後再來補文件，基本上是不太有意義的事。以補文件這件事而言，代表著這份文件可能是不必要的，或者根本上做事方法錯誤。而大部份補文件的情形，通常是後者，即做事方法錯誤。

確實審查　幫助及早發現並避免錯誤

那我們要怎樣才能不補文件，或是能夠及時或適時地將文件產出呢？最重要的是靠審查(Review)，尤其是技術審查(TechnicalReview)。審查的目的，大家都知道是要及早發現錯誤，但是更重要的是避免錯誤被放大。大部份軟體工程的書都會講，改正一個在需求階段的錯誤所花的人力如果是一的話，如果這個錯誤沒被發現，在系統設計修正它所花的人力將是二到五倍，而到了系統實作，即Coding階段才來修正，所花的人力則是十到五十倍，若是到了UAT階段或上線之後才發現，則修正這個錯誤所花的人力是六十到一百倍。那我們要怎樣才能在需求階段或系統設計階段發現錯誤呢？唯有審查，又審查，再審查。最近大家流傳著樵夫與磨斧頭的故事，技術審查即是主要的磨斧頭工夫。另一個非常淺顯的例子是，當程式委外或委DC時，第一批回來的程式一定要做審查，道理非常簡單，若不做審查且找出錯誤，則相同的錯誤會在以後的程式重複出現。若有五批程式，則至少要花五倍的時間才能把錯誤全部修改好，這又是另一個磨斧頭的例子。

但是技術審查和文件產出又有什麼關係呢？在需求階段或是系統設計階段的審查，我們是不是需要做報告或是作簡報呢？如果沒有簡報，相信要做好審查是相當困難的。實際上，只要將簡報內容略加擴充，其實就足以產生適當的文件了。一般而言，一件工作大概有二到五次的技術審查，就可以做到相當不錯的境界，亦即可以避免絕大多數的錯誤。審查和稽核(Audit)的目的不同，稽核只檢查該做的工作有沒有做到，而審查則要檢查工作做對了沒有，是不是還可以做得更好。因此，只要各種技術審查做得確實，CMMI的各項稽核根本不是問題，而且，由於許多錯誤都可以在專案前面階段檢查出來，可以讓專案的進行更加順利，因此不僅可能可以不用加班趕工，甚至提早下班，都不是天方夜譚。

小改變帶來的大改善

最後，我要再度重新強調，我們真正要努力的，是把軟體工程做好，而不只是滿足CMMI的要求而已。CMMI只是一個流程改善的框架而已，沒有軟體工程，就不會有流程改善。軟體工程或CMMI的目的，並不是在產出文件，而是要把系統做好，而要把系統做好，許多小小的改變，其實可以得到絕大的改善。例如說有一個病人，患有高血壓、糖尿病、心血管疾病及腦中風的危險，若要全面有效治療，如開心手術或開腦手術，病人可能就會喪命在手術台上。但若病人改善飲食，每天持續作溫和的運動如散步，一段時間之後，也許心肺功能改善到可以開腦手術的地步。而在專案這邊也是一樣，要進行全面的流程改善也許相當困難，但是有許多小小的改變卻是可能，也可以收到很好的效果。這些小小的改變是：
一、第一批程式一定要做Code Review
二、專案會議中，留一段時間作技術審查，設計部份要做簡報，程式部份，可能的話要做Demo
三、事先想好測試個案
四、規劃系統整合步驟
五、專案一定要做好人力規劃及備援方案

其實還可以列出更多更多，不過最重要的是，大家要多多思考，如何讓自己更聰明的工作，更有效率的工作，而不僅僅是賣命的工作。賣命的工作，並不能讓你避開慘案，唯有記取歷史的教訓，以及盡量複製自己以及別人成功的經驗，才能真正讓你享受專案成功的果實和喜悅，而這才是導入CMMI 的真正目的。