軟系統的硬工程

「軟系統的硬工程」written for 國科會科普獎，獎項的競爭者比較少，這篇文章進了複審但沒進決審，我還是寫得不夠「科普」，決審名單中，生物科技這個領域的文章比較多，評審顯然比較青睞這個領域的文章，或者評審多是這個領域的專家。

---------------
軟系統的硬工程

一般人看到軟體這個名詞，都會注意「軟」這個字，軟也可以說是有彈性的意思，使用者都希望能有一種超級軟體，幫助他們工作更有效率，而且能夠彈性地改變，符合不同時間狀況下的需求。但電腦是一種非常笨的機器，它由0與1組合而成的，說一步做一步，能在電腦上運作的軟體，都是程式設計師一步一步地撰寫程式，預先告訴電腦所有可能發生的正確與錯誤情況，與其對應的處理方法，否則電腦就會當機或是由系統告訴使用者「出錯了，我不知道下一步要怎麼辦！」因此開發軟體系統的時候，得配合工程管理的分析流程與設計方法，這樣才能保證軟體系統的品質優良可靠好用，軟體系統也有硬式工程開發管理的一面。


資訊科技工業革命

軟體系統是使用者使用機器的介面，透過不同的軟體系統，可以幫助使用者「自動化」處理許多事務，而自動化的用意跟十八世紀工業革命的初衷如出一轍，可靠有效的自動化機器取代了人力，有效地提高了生產力與產品的品質，所以當時出現了很多機械技師，除了開發新式機器外，還得維護並照顧這些機器，它們既不會「罷工」也不會「怠工」，是老闆眼中的最佳員工。

自從電腦出現後到現在，已經深入到每一個企業甚至家庭當中，程式設計的技術也不像第一次工業革命的時候一樣，只有機械工程技師才有機會可以接觸到這些機器，便宜的電腦就在每一個人家裡的桌上，每一個對程式設計有興趣的人都有機會成為程式設計師，我們正站在自二十世紀肇始的資訊科技工業革命浪潮當中，在「人人都能寫程式、大家都能做系統」的情況下，要製作一個品質優良、穩定可靠、功能完備的軟體系統，就是另一個需要達成的目標。

電腦是採取「垂直階層」分工設計架構的策略，從硬體的核心開始，上一層的作業系統負責處理所有硬體的溝通介面，並提供上層的系統程式呼叫的API（Application Programming Interface、應用程式介面），但由於這些API會隨作業系統甚至是程式語言的改變而不同，這個問題造成軟體系統開發前，要先評估並慎選作業系統與程式語言開發環境，如此才能夠讓這些軟體系統上線運作後，無痛地執行維運與升級的任務，所幸目前的IT（Information Technology、資訊科技）領域技術大廠都有共識，朝向解決這個問題的方向努力當中，例如昇陽的JVM（Java Virtual Machine、爪哇虛擬機器）與微軟的 CLR（Common Language Runtime、通用語言架構），這些技術都適當地將下層的作業系統封裝起來，對上層應用程式提供統一的API介面，因此有效解決了不同作業系統或程式語言的問題。

在垂直階層的電腦基礎上，一部電腦裡同時運作資料庫跟應用程式伺服器這兩個複雜的軟體系統，會發生系統負荷過重的缺點，因此產生了「水平階層」分散式處理的架構，也就是目前最熱門的Multi-Tier Architecture（多層架構），以3-Tier為例，使用者端的介面程式位於使用者的電腦上，透過網路連接應用程式伺服器，然後再連接另一台資料庫主機，而伺服器都可以用平行擴充的 Clustering 叢集方式，提供大量使用者同時連線使用時的高系統負載用量。在多層架構運作下的軟體系統架構，既有效又可靠，還附加了安全性與維護管理的功能，可說是既節省成本，又保有未來擴充性的一種解決方案，這也是目前公認最適當的軟體系統架構。


梓人建構師

多層架構與實作技術的規劃分析問題，都得要由Architect（系統建構師）來做判斷與決策，這也是一位程式設計師，進階到系統分析師後，最後夢寐以求的一項工作，目前最有名氣的就是微軟的首席建構師比爾蓋茲。唐代的柳宗元，撰寫了一篇文章「梓人傳」，非常貼切地描寫了一位房屋建築師的工作寫照，軟體業界的建構師這個名詞也是從建築業界借來的。

文章的第一段中，梓人就說「吾善度材。視棟宇之制，高深圓方短長之宜，吾指使而群工役焉。舍我，眾莫能就一宇。故食於官府，吾受祿三倍；作於私家，吾收其宜大半焉。」後來卻發現梓人房間裡的床缺了隻腳，他卻得找工人來修理。但在實地觀察梓人指揮規劃京兆尹官署修繕時，作者才發現梓人的工作價值在分析與設計整個建築物，木匠與工人都要透過梓人指揮調度，最後完成時，也只有他才有資格在棟梁上寫下：「某年某月某日某建」。

柳宗元其實是要以梓人之道來比喻為相之法，建築的道理同樣可以套用在軟體業界上，軟體系統就像是建築物，程式設計師等同於工匠，而建構師就可以說是軟體業界的建築師。設計建築物並不是只靠層層分工就可以完成的，建築師得掌握整體設計，配合結構技師分析建築物的安全性，還有水電技師配電，再往下分配給建築包商，然後才在現場工地實作。這需要一個作業流程的配合，設計與開發作業是由一個作業團隊共同執行處理的，適當的作業流程規範，可以讓工作團隊緊密結合在一起，透過良好的設計圖互相溝通，才有辦法成就一個安全可靠、有品質保證的建築物。

軟體系統從規劃、分析、設計到實作，開發團隊需要一個共同遵循的開發流程，從使用者的需求開始，到軟體建構、系統分析、程式設計、測試層層分工合作，如果沒有工程管理的規範，就無法確保成品的品質。因為人人都能寫程式，開發團隊的大小、專案的規模大相逕庭，系統開發程序並沒有放諸世界皆準的標準，對軟體開發團隊來說，先選擇一個適當的開發程序標準，再作適當的微幅調整，就是最適合的開發流程，而這個系統開發作業程序就是軟體品質保證的試金石。


軟體系統品質保證

軟體系統的品質可單純地以bug（臭蟲）數量這種直觀的方式來評估，系統的bug越多，很自然地就代表品質越差，但現在的軟體系統規模龐大，有很多系統的bug在測試驗收的階段還沒辦法被發現，如果產品推出後造成客戶的損失再來解決就為時以晚了，因此軟體系統的品質保證必須藉由適當的軟體系統開發程序，規範規劃設計到開發每一個階段的工作，如此才能保證可以及早發現並解決問題，換句話說，就是藉由嚴謹的開發「過程」，來確保成品的品質。

傳統的軟體系統開發程序是瀑布式生命週期模型，也就是指軟體從需求分析、設計、開發、測試、安裝、維護這些一個接著一個的步驟，進入設計階段後就不能再回到需求分析，這是因為傳統的系統開發者認為，需求的變動會影響後續設計的結果，如果大幅度或頻繁地修改需求，會造成系統開發時程無限期延後的後果。瀑布式的模型產生了許多爭議，開發的各個階段可能會重疊，階段中的活動也可能會重覆，如果在開發階段才發現分析錯誤，就一定得要重新分析。

漸進式開發方法改進瀑布式的缺點，是由規劃、分析、開發、使用者評估再回到規劃，這樣週而復始地螺旋式循環，漸進地讓系統越來越貼近使用者的需求。RUP（Rational Unified Process、統一流程）就是一種使用案例驅動、以架構為基礎、反覆、漸進式開發的標準流程方法，但因為RUP過於龐大複雜體系，需要撰寫非常多的規格文件，所以比較適合上百人的大型軟體開發團隊使用。

對於一般一到十幾個人的小型團隊來說，XP（Extreme Programming、終極編程）提供了跟RUP完全不同的設計理念，這是一種簡捷有效的開發程序，主要由一些設計準則組成，例如成對編程（以兩人一組做程式設計）、測試導向（持續地不斷地自動化測試，提高系統品質）、重構（持續改善不良的設計），這些準則的目的是希望開發團隊能彈性有效快速反應使用者的需求，不要製造太多文件，文件跟系統一樣，都需要大量的維護成本。

農產品加工工廠會針對自己的產品，使用不同的製造與管理流程，再透過CAS優良農產品及其加工品最高品質的認證，保障加工產品的品質，讓消費者安心享用這些產品。軟體工業也是如此，廠商可以使用不同的開發流程，但對客戶來說，如果廠商通過一個公正的認證標準，就等於已經有了基本的品質保證，目前軟體業已逐漸有大型化、國際化的趨勢，所以我們需要一個全球公認的認證標準，用以評定軟體開發團隊的軟體專案開發能力。

CMMI（Capability Maturity Model Integration、能力成熟度模型整合）的國際認證已經成為軟體工業的基本競爭指標。CMMI整合了多個標準，將軟體開發分為五個能力等級，Level 1 一般執行方法，代表沒有固定流程，無法複製成功經驗；Level 2 已管理流程，表示專案已導入流程管理，可控制時程，有充足的管理資源，類似的專案可複製過去的成功經驗，但不同專案可能有不同的管理流程；Level 3 已定義流程，代表會持續改善已成為公司的資產的組織標準流程；Level 4 已量化管理流程，會使用適當的統計量化技術控制品質，並建立品質及流程績效的量化目標；Level 5 最佳化流程，可改變與適應量化的管理流程，以符合目前與預期的經營目標，系統化地推展漸進與創新的技術改善，並根據改善的目標來評估流程改善成效。

CMMI並沒有限制開發流程的規格，只以開發團隊的表現來評定開發能力等級，這也是目前政府大力推動的方向，甚至明訂目標在2008年培養出七十家通過CMMI Level 3 認證的廠商，而具CMMI Level 5 能力等級的則有三家。


溝通模式語言

「這是啥米碗糕？」如果是個閩南人看到這句話，會覺得親切，如果是北方人，即使每一個字都認識，放在一起就會讓人覺得丈二金剛，摸不著頭緒，還可能會猜想是不是一種新的碗裝米糕小吃，如果是外國人就更慘了，對華語根本一竅不通，這表示溝通需要有一種共通語言。

在開發團隊遵循的開發流程中，從系統規劃開始，就必須製作適當的文件，文件的內容是要描述專案的各種面向，包括系統架構、需求分析、設計內容、測試、安裝、維護等資訊，為了讓整個開發團隊都能確實瞭解文件的內容，我們需要一種共通的語言。語言會形成軟體業界的文化。物件導向被譽為世紀末軟體革命的程式設計方法，在物件導向領域中UML（Unified Modeling Language、統一塑模語言）就背負著記錄物件導向領域文化的任務。

「不學詩，無以言」詩是語言文字的精華，短短的幾句話，適當地勾勒出說話者的心境，準確地傳達讓聽者感同身受。「勸君莫惜金縷衣，勸君惜取少年時。花開堪折直須折，莫待無花空折枝！」短短四句話，就能描繪把握當下的用意與情境，讓人心領神會。所以有了語言之後，還需要另一種精簡的溝通模式，能言簡意賅地傳達設計的精髓。

當我們一說「巴洛克式建築風格」，很自然地就能聯想到羅馬著名的聖彼得大教堂，17世紀初源自於羅馬的華麗奔放建築模式。建築設計理論家亞歷山大在「建築的永恆之道（The Timeless Way of Building）」這本書中說，建築設計的過程，就像一個受精卵逐步分化的發育過程一樣，是一種從整體往下到細部的設計過程，透過這種「由粗到細」的設計方法，讓建築物產生一種設計的風格與文化。而這些建築設計，是以 Pattern（模式）來描述，模式收集了所有代表性的問題與對應的設計方法，這也是「建築模式語言（A Pattern Language）」這本書提出的概念。

物件導向軟體模式化開發方法的經典著作是 E. Gamma、R. Helm、R. Johnson與 J. Vlissides 的 「設計模式（Design Patterns - Elements of Reusable Object-Oriented Software）」，他們把物件導向常見的設計模式分為生成、結構、行為三大類共23個模式，這些具有「代表性」的模式，已成為物件導向系統設計時的基本常識，舉例來說，當我們要說明系統內只有一個單一物件實體這樣的設計時，就會以Singleton來稱呼這種設計模式。


軟體工程

軟體系統就跟機器設備一樣並不是萬靈丹，必須要在符合公司或使用者的需求下，才能完整地發揮軟體系統的功效，貿然買進或開發某個系統，只會造成公司的維護成本負擔，品質低劣的系統也會造成使用者莫大的困擾。軟體系統的設計開發，配合適當的開發流程，就可保證專案品質，而CMMI就是開發流程的認證標章。在開發過程中，設計文件要以共通的塑模語言描述，再配合精簡的設計模式，這樣就能成就一套完整有效的軟體工程。