輕鬆談軟工

兩個小鎮之間有一個荒蕪之地，一些汽車會經過，一個聰明的商人於是在那裡開了一間加油站，生意還不錯。一個月過後有人在旁邊開了一間雜貨店，買點日用品喝點水，再過一些日子有人開了咖啡店，可以休息聊個天。漸漸的有人在那裡蓋房子住了下來，於是餐廳、學校、銀行進駐，慢慢的變成一個小鎮。 同樣一個故事發生在另外一個地方，生意人覺得加油站真賺錢，於是在附近蓋了第二間加油站，生意也還可以，於是第三個人再進來蓋加油站，開始削價競爭，最後三家生意都做不下去紛紛倒店了。 老掉牙的故事，每隔四五年就會聽到一次，但感受卻越來越深。 我們現在做的系統（或事情），是第二個加油站，還是邁向小鎮的咖啡廳？

家裡總有些小蟑螂，我們想盡了各種方法來除小蟑螂，例如買強力黏蟑紙，或是殺蟑螂的誘餌，一開始都有點功效，但過了一陣子蟑螂又跑出來了。 根本的解決之道在於，蟑螂為什麼會到我家？過去我們大概兩三天會倒一次垃圾，因為家裡的塑膠袋是大的，每天倒垃圾覺得浪費。於是我們換成小的垃圾袋，並開始每天倒垃圾，於是乎家裡的小蟑螂慢慢地就不見了。 治標真的不是辦法，必須要找出問題的根源並加以解決。 軟體的開發也是，如果你的公司不斷的產生 bug, 或是品質出現問題，別只是見 bug 除 bug，得好好想想： bug 為何會出現？

往花蓮的自強號上，旁邊坐著一位五十幾歲的長者，一直反覆的看著一本旅遊書籍，看起來是歐洲旅遊的書。我好奇便問他：『剛從歐洲旅遊回來嗎？』，他嚇了一跳，我連忙向他道歉，他親切說；『沒關係』，接著很興奮的告訴我他的攝影心得，就這麼聊了起來。 他一邊翻閱書上的照片，許多的地方他都去過，他說他喜歡研究別人取景的角度為何和他不同，借此學習更好的攝影技巧。看得出他對生命充滿熱情，喜歡思考、創作與分享。聊著聊著才知道他原來是台中知名建商的董事長。 除了生活上的樂趣外，他也跟我分享他的經營理念。他對員工的要求是 『不能凡事都照著規格書、設計圖走，那是官僚』 。為什麼？他們的員工每天都在接觸房子的買賣，久了就麻痺了，以為房子的買賣很輕鬆，但是對許多買房子的人可能是畢生的積蓄，一生可能只買一次房子。 他說他接觸過很多醫生、教授或高科技產業的客戶， 他們在自己的領域上十分的專業，"但對房子的事情真的就是不懂" ，所以不能拿規格書來壓他們，應該是要幫助他們。 姑且不論這位董事長是否真的做到這樣的原則（畢竟我跟他不熟），這些道理在軟體工程產業上也是相通的。寫軟體的如果在客戶搞不清楚規格的情況下一直以規格來壓客戶，那就是以專業的傲慢來欺騙客戶的無知。 當然，蓋房子跟寫軟體畢竟不同，各位覺的呢？

軟體系統常常背上許多莫需有罪名，有時候是需求的提供者沒把需求說清楚（或根本說了錯誤的需求），有時候是使用者不會用 （沒參與教育訓練或沒看說明書）造成操作不當。當後者的情況發生時，使用者通常會怪罪『介面設計不好』。 的確多數的軟體工程師對於介面的設計不重視也不在行，但有時候使用者也太無理取鬧，把所有的錯誤都賴在介面設計上。 張大叔最近開始使用線上照片沖洗的功能，但照片卻遲遲沒有寄到，他上網查了一下，發現住址寫錯了。他打電話到客服中心發飆。 『你們的系統有問題不穩定，把我家的地址記錯了。明明是100號，怎麼會記成200號？』 客服查了一下，回應說： 『張先生，有可能是您打錯了，系統記錄的的確是200號』 『怎麼可能？我打過無數次了，怎麼可能會把自己的住址打錯？』 客服有耐心的說： 『有可能1和2相鄰，您打的時候打太快了，所以不小心打錯了』 『那你們系統要做檢查嘛，哪有那們笨的系統？要做防呆嘛』 客服楞了一下，還好他邏輯還清楚： 『張先生，我們系統不知道你住100號，怎麼知道您打錯了？沒有辦法喔...』 這下換張大叔楞了一下，但他還是很生氣。 『這照片是我送給老婆的生日禮物，照片我選了好久，沒有按時寄過來這個禮物就沒有意義了』 ，頓了一下又說： 『你們要怎麼賠償我的損失？』 『先生，這是您打字錯誤所造成的，我們沒有辦法賠償。我們會通知郵局將包裹重寄，但您要再負擔一次運輸費用』 客服說。 張大叔一聽還要多負擔就生氣： 『都是你們系統的問題為什麼要我負擔？你們介面設計的太糟，介面要儘量防呆嘛... 比如說不要讓我們用打的，讓我們用選的...』 客服有點聽不下去了： 『先生，忠孝東路門排很多，我們不可能把所有門排都列出來讓你選』 『怎麼不可以，你可以每一個位數都用一個下拉式選單，三個位數只需要三個下拉式選單，你們設計要用點腦筋嘛』 ...

今天上課前突然想到一個故事，稍作改變後用來跟學生講解流程改善。 某公司聘用一個員工上種樹，他需要鋤頭挖洞，將樹植下，最後再用鏟子把地鏟平。以他的速度一天只能種十顆樹，比老闆預期的進度差太多，於是老闆又聘了兩個人來幫忙，速度提昇了兩倍。 [from work harder to work smarter] 但是這樣的速度還是不夠快，而成本又太高已經沒有經費在聘用員工，只好想辦法進行流程改善。他仔細觀察三個員工的工作方式，發現花在工具的抽換花了太多的時間。於是他重新更換了三個人的工作：A 只做挖洞的動作，B 隨後將樹植下, C 隨後在將地鏟平。這樣的工作模式可以省去更換工具的時間，更棒的是，每個人更能夠把自己的工作做的專精，效率又提高了兩成。 [但，小心成為官僚流程] 這樣的流程跑了很久，員工來來去去換了許多次，但都保持一定的高效率。一天，老闆去看工地，發現A 挖玩洞後，C 緊接著把洞補起來填平，老闆生氣的說：『你們在做什麼？B君呢？』 『喔，他今天請假了』A 說。 最後這個笑點看似誇張，但在企業流程卻常見。許多人習慣了只知道follow 流程去做，卻不之所以然，所以很容易鬧出笑話。另一方面企業也常常不重視流程的教育訓練，所以常常空有好流程卻無法發揮最大的效用。

Continuous Integration 在討論版本控管時，我們曾經提到WiMAX計畫使用一個輔助工具「 JCIS 」進行持續整合(Continuous Integration)的工作。那麼，為什麼要做持續整合呢？維基百科中對於 持續整合 的理論有些初步的介紹，包含下列十個重要的Practices： 維護一個程式庫(Maintain a code repository) 將建置自動化 (Automate the build) 使建置能進行自我測試(Make the build self-testing) 每人每天送交程式碼(Everyone commits every day) 每次送交都應該被建置(Every commit should be built) 維持快速的建置時間(Keep the build fast) 在實際運行的環境下進行測試(Test in a clone of the production environment) 簡化取得最新可交付版本的方法(Make it easy to get the latest deliverables) 每個人都能看到最新版建置的測試結果(Everyone can see the results of the latest build) 將佈署自動化 (Automate deployment) 上述許多Practices都要求自動化，自動化又可以分為半自動和全自動，以半自動為例，可能是有人每天固定手動執行make指令，將所有要建置的檔案編譯與連結，接著有人將結果複製到實際運行的環境，再下指令讓電腦執行所有的測試，這個過程雖然必須由人來操作，但只要下少許指令就可以完成了。那麼全自動呢？就是在專案開始的時候進行若干設定，之後由電腦自動處理一切編譯、連結、測試等工作，這就需要一套輔助工具了。 要確實完成這麼多的Practices，其實門檻是很高的。即使是在企業界，也難免會有不遵守遊戲規則的軟體工程師，更何況我們的開發主力是學校裡沒什麼專案成敗壓力的學生。舉例說，要做到「每人每天送交程式碼」幾乎是不可能的，基本上學生開發程式是有一天沒一天的，最多只能要求到「有修改就必須送交程式碼」。另外像是「每次送交都應該被建置」，在我們第一年的WiMAX計畫中可以說是完全失敗。在開發環境未能統一的...

版本控管 在整合國科會CMMI文件與程式開發的過程中，總計劃與各子計畫的文件與程式都需要一個版本管理的機制，一方面萬一有電腦當機或是檔案損毀時，可以迅速還原最新的版本，解決資料備份的問題，另一方面還可以在歷史紀錄中往返，將刪去的文件或程式找回來。對於文件或程式整合而言，版本控管十足是一個Time Machine。 我們在第一年開發之前就已經預期到版本控管的重要性，因此在專案初期便架設可透過Web介面存取的版本控管伺服器(Apache + Subversion)，並且安排Subversion的教育訓練。但是，可能是一開始時教育訓練的內容安排不符合需求，也可能是開發團隊不夠用心，導致版本控管並不上軌道。最常發生的問題包括：團隊成員未確實解決衝突(Conflicts)、久久不送交(Commit)程式、送交無法編譯的程式、送交時不寫註解等。 這些問題的原因，有部分與先前討論過的缺乏一致的開發環境有關，部分團隊使用的IDE沒有支援版本控管，所以得在IDE編譯完後才知道有沒有問題，然後再使用其他版本控管軟體(TortoiseSVN等)送交程式；或在Windows上取出(Check out)程式然後複製到Linux的機器上修改與編譯，然後再複製回Windows上覆蓋舊版本後送交，然而在取出後到送交前的這段時間，如果沒有進行更新(Update)和合併(Merge)的動作，這些行為常常會導致衝突。 久而久之，有些團隊成員開始害怕使用版本控管系統，導致送交的週期越來越長，甚至有超過二個禮拜沒有送交程式碼，失去使用版本控管的優點。長時間的修改送交週期，也讓成員忘記曾經修改過什麼東西，自然不知道要寫什麼註解，這些都是讓版本控管失去威力的錯誤行為。經過一整年的觀察後，總計畫在第二年開始前，重新規劃Subversion的使用方式。 首先，我們將版本控管的支援加入一致的開發環境中。在Virtual Machine中，我們使用Eclipse搭配Subclipse套件，讓IDE與版本控管合而為一，之前也提到，單元測試的執行也加到程式中，這些都是確保程式無誤的前置作業。另外，針對文件撰寫的環境(通常是Windows平台)，撰寫TortoiseSVN的操作手冊，讓新加入的成員快速進入狀況。 接著，我們訂定幾個需要遵守的原則(Principle)，在文件部分，要進行編輯的文件一定要...

以往學生在學軟體工程時，總覺得這門課就是在「寫文件」，對於為什麼要寫文件，以及文件的用途，不甚了解，甚至覺得寫文件是很枯燥乏味的一件事。的確，為了交作業而寫文件，我想沒有人會認為寫文件是有用的，特別是對於一個虛擬的軟體專案而言，即使必須開發對應的軟體，充其量也是一個小品，而且一個學期的時間又很有限，所以不是文件品質不好就是軟體沒寫好，更別提要維護了， 而學生無法對軟體跟專案產生情感，自然無法體會文件的意義。 過去三年，筆者因為主持國科會整合型計畫「WiMAX 無線通訊系統軟體與工具開發(I),(II),(III)」的關係，需要主導撰寫其Light-weight CMMI文件，剛開始的第一年，參與計畫的學生們也是哀鴻遍野，學生們即便已經參加過國科會舉辦的Light-weighted CMMI研討會，寫出來的文件，和實際的軟體設計仍有一段很大的落差，一直到第二年，需要開始維護第一年的軟體時，學生才慢慢體會到軟體工程要的不只是文件，而是文件所帶來的價值：溝通與管理。 有一個經常被提到的問題是「軟體流程」？我們的WiMAX整合行計畫到底有多大呢？是否真的需要軟體工程或是完善的軟體流程才能完成呢？這裡先簡單描述一下我們的案子，大家都知道WiMAX被視為M-Taiwan重點發展項目，WiMAX(802.16e)是一個相當複雜的通訊協定，而我們的目標是開發一套完整的「WiMAX網路模擬軟體」，由於WiMAX由上到下包含許多子層，而各子層又各須非常專業的知識，因此，這個案子需要軟體工程加入，才能有效地整合各種跨領域的知識，構成一個完整的系統。也因此我們(北科大軟體研發中心)才提出這個跨領域的整合型計畫，希望開發出WiMAX網路模擬軟體，以開放原始碼的方式貢獻給業界作為WiMAX參考模型，並分享我們的開發經驗。 在WiMAX的案子中分成三個主要項目：「應用」、「協定」與「輔助工具」，應用有「即時視訊傳輸應用」與「適地性資訊服務」；協定負責WiMAX通訊協定的所有子層包含媒體存取控制、安全加密、實體層編碼、實體層調變與通道模擬；輔助工具則提供通訊軟體模型建構工具與持續整合等輔助。由此可知，計畫規模頗大，最多曾經有12個子計畫。軟體流程不能保證專案如期完工，但能用來監控時程與進度，如果沒有流程，進度落後或是超前，都無法掌握，那軟體勢必是無法順利開發與整合的。 有了第一年的...

最近 HTC 出了一款 Android 手機， HTC Hero , 相信3C 迷及 Google 的愛好者都相當注意。我雖然也注意了一陣子，但最近才發現它一直很強調它的 People-centric 的特色-- 就是以人為中心，將電子郵件、通話紀錄、簡訊整合在一起的功能。這樣的設計感覺起來很直覺，很好用。 回頭看看過去的設計，是以通話、傳簡訊、查看通話記錄為主的『功能導向』設計，『人』只是這些動作的參數。這才驚覺原來現在的手機介面設計流行（進化到?）『物件導向』。這樣的進化是偶然？還是從物件設計的理論得到靈感？ 如果是後者，也許可以進一步的思考物件設計的技術 -- 例如繼承 -- 如何應用在手機上。 把手機上的聯絡人用繼承樹（a kind of）來模組，如此一來在訊息傳送給父類別的群組時也會送給子類別的聯絡人，或許這樣可以簡化整個手機上的群組關係。當然，物件上的『association』也可以套用在聯絡人的關係的建立。 只是一個突發奇想，可能有點人來瘋。但有興趣的朋友、研究生或許可以試試研究看看。

『如果我問我的顧客想要什麼，他們會回答我一匹跑的更快的馬』- 亨利 福特 最近上了一本新書『 Inside Steve's Brain 』，說的是蘋果賈柏斯對經營、設計的一些理念。我想大家對賈柏斯轟轟烈烈的事蹟一定很熟悉（特別是蘋果迷），在此不做贅述。我個人雖不是蘋果迷，但也深深的佩服他對設計的執著與相關產品的簡約。我一直覺得台灣需要的不是系統實作人才，應是軟體設計人才。設計是什麼？我所說的並不是什麼結構性設計、物件導向設計、架構設計等技術的東西。 而是態度。一種對設計的態度。 什麼是設計的態度？答案也許在這本書中。推薦各位看看。 一般而言，軟體工程裡都教我們系統分析時要做需求訪談，聽顧客的話。但在某個領域中，特別是創新的領域中，傾聽自己內心的渴望（對產品的渴望）是更重要的：我們如何能做出讓人能夠感動的產品？Steve 相當欣賞亨利 福特的一句話：『如果我問我的顧客想要什麼，他們會回答我一匹跑的更快的馬』。 在顧客的框框下，你所開發出來的產品是不會感動人的 ，所以 Steve 在開發產品的時候是不做市調的，這相當有自信且冒險。但對 Steve 而言是行得通的，畢竟能讓一個工作團隊花『六』個月的時間調整一個 scrollbar 的人並不多。

這是一個專班學生的故事。 他的工作是跟物料管理系統的開發相關。公司用的實作框架中包含一個 tree 的 model。有一天，因為使用者的需求變更，他的上司決定把 tree  model 改掉以快速的解決顧客的問題。他仔細的看了這個方法，知道一定會對後續的成本計算產生問題，因此請主管不要改 tree model。 但是顧客的問題必須要馬上的被解決，所以主管決定還是要改。有軟體工程概念的他，瞭解這個問題的嚴重性，他深深的知道這個東西一改，以後的程式都會以這個基礎下去開發，到最後成本計算穩死無疑，因此堅決不可以改，兩個人於是吵了起來。 其他的組員覺得他很奇怪，沒事為什麼要跟主管過不去，還跟主管吵架。在一個保守的組織中，他的『雞婆』並沒有受到肯定，也沒有人有時間深入瞭解他所說的道理，只是覺得他很『機車』，他只好閉上嘴巴照做。 過了三個月，這個問題浮現了，大家忙得雞飛狗跳。但是，沒有人知道他們所遇到的問題是主管所造成的，也沒有人想到他。大家忙著找一個可以立即解決成本計算錯誤的方法。也許，再把 tree model 亂改一通吧。 大家覺得這個故事有哪些啟示呢？

最近景氣不好，許多公司的MIS部門開始接受到上級的指示，把部門內的產品做一些包裝拿到外面去賣。賣不好，部門的人事可能就得精簡。這對MIS部門的確是晴天霹靂，景氣好的時候公司需要大量的電腦化支援，所以雇用了不少的人，現在人力過剩也是事實，只好硬著頭皮來賣產品。 但是從支援部隊轉換為賺錢部隊並不是一件容易的事，個人認為需要考慮幾點。從  開發者   來看，應考慮幾點 心態調整。 過去的MIS主要以支援為主，不是主要的生產部隊，績效的評估從模糊的『服務績效』變成明確的『獲利績效』。MIS人員是否做好了心理準備？ 面對客戶 。過去MIS人員僅要面對自家公司的人員，自己人好說話，軟體有bug也可以互相容忍一下; 或者是習慣性的接受同公司的任何修改請求。現在必須全新的體認開發者與客戶之間的商業關係，制度化的客服與變更流程顯得更重要。 在產品方面，或可從下面幾點來看： 產品的獨立性 。MIS 所開發的產品通常並不完全，而是搭配其他購入的產品共同存在（所以MIS人員的職責有一部份就在於整合自家產品與商業產品）。顧客要的是一整套的解決方案，而不會單一的產品，所以你得與商業產品搭配一起販售，這時候利潤的計算與分配、甚至於是合作模式都需要好好的計畫。 企業機密 。MIS所開發的產品多半伴隨著企業邏輯，應該要考慮企業機密的問題。如果企業的弱點或漏洞隨著產品一起出去，讓競爭者有機可乘，便倒賠了一把。 產品的品質 。 為了配合公司的業務流程，MIS所開發的系統多半是修修改改的，架構、功能、實作方法都相當複雜，若要當成產品來賣，恐怕得好好整理一下。 在管理方面應該考慮 產品或專案 。MIS主管可能會有這樣的誤解：A公司與我們業務相同，我們可以將我們的產品直接或微幅修改後賣給他們。在這樣的狀況下，產品的價格會壓的很低。殊不知每個公司都有自己的文化、作業流程，軟體系統移植後一定需要很多的修改，成本一定不會太低。也就是說，主管所認為可以大量直接販售的產品其實是一個誤解，應以專案的方式進行。所以專案管理的能力得重新訓練才行。 組織調整。 需不需要將開發團隊由原有的MIS部門切割出來？切割的好處是MIS可以專心的服務原有公司，不需要為業務煩心。但原有系統的設計是分散在所有員工的腦袋中，要做清楚的切割的確有困難度。如果沒有切割開來，就得避免MIS員工在服務與客戶之中迷失，不能因為重服務而失了客戶，也不能因為...

這星期聽了一個有趣的演講。談的是如何進行個案教學，其實這個主題對企管的人而言是家常便飯，但對資訊工程的老師而言，卻還蠻新鮮的。特別是身為軟體工程的教育者，深深的感受到軟體工程的傳授是很困難的，原因如下 學生的經歷不夠，很難體會軟體工程所提到的問題。例如我們說『需求難以表達』，學生可能會覺得 -- 口才有這麼差嗎？ 資工系的學生覺得寫程式才是王道。卻不知很多的專案失敗在工程方法。 課堂的時間太短，沒有辦法真正的體會軟工的議題。例如一個學期跑一個專案，想要讓學生從專案中體會一些軟工的原理, 但一個學這麼短的時間根本跑不了大專案，而小專案偏偏又很難體會軟工的重要性。 所以我能體會有些老師把軟體工程當成『程式語言』來教，至少寫寫程式還可以讓學生學些什麼。 但如果能夠有 case study 進來，我想軟體工程的課一定會有趣得多。這裡的 case study 和課堂上的『舉例』有極大的差別。Harvard設計一個 case study 給的經費約台幣 30 萬，台灣最近也類似的教學改善計畫，也都是十萬的倍數（企管課程），想當然案例的設計要嚴謹的許多。想想看，如果我們可以聽到並一起探討 google 在設計 gamil 的專案管理、測試、設計，可能比上了十天的軟體工程收穫更多。或是可以參考台灣凌群電腦在軟體流程改善的進行方式，對學生的幫助一定很大。 希望教育部能夠支援像這樣的課程，其實買設備的教改計畫幫助不大。

最近因為接了行政職，生活開始忙碌了起來。為了能夠讓訊息暢通與方便行程的安排，忍痛買了 BlackBerry 黑莓手機。黑莓手機手機在國外賣的嚇嚇叫，他的 QWERT 功能讓習慣電腦操作的人愛不釋手，實際使用後，發現它的好處不只這些。 國外的系統在介面的使用上的確著墨很多，BB 的介面讓你很快的建立一個會議 --- 一隻手就可以辦到。查詢聯絡人的資料也是，即便你有上千筆的聯絡人，也可以在很短的時間內找你要的人，然後寫 email, 送 MMS 或打電話給他。資工系的學生通常會以『沒有美感』來作為介面設計不好的藉口，這個觀念應該要改。 回到主題來談談錯誤的管理。BB 雖然功能強大，但還是會有錯誤。寫過程式的我們都知道程式的錯誤難免，也可以忍受 --- 只要他們有專業的報修制度。我打過幾次電話，前兩次電話響了近三分鐘都沒有回應，直到第三次才有人來接，但回應是『晚上沒有技術人員，請我白天再打』。我猜想他們的流程大概是這樣子的吧： customer reports the bug through phone help desk records the bug, ask the engineer resolve the problem on line if they are available. If the engineer are not available, ask the customer call later.  現在的手機功能太強，就像是一個小秘書，沒有小秘書兩三天還得了？所有的工作都停擺了。顧客可沒有辦法配合他們的維修流程啊（白天大家忙得要命，哪有時間打電話)。於是我上了 google, 打上錯誤訊息，一下子跑出好多的解決方案。看了第一個方法，我就解決了我的問題。 BB 他們做了什麼？什麼都沒有做 ，只是許多閒暇 人事透過 web 2.0 將他們的錯誤解決方法寫在部落格上，透過許多人不斷的回應，於是最佳解決方案就出來了。或許報修的流程要改一下： customer reports the bug through phone ask the customer to "google their problem", if not resolved, go step 3. help desk records the bug, ask the engine...

最近，RFID 開始紅了起來，也應用在許多很多地方，改變人類生活的方式，例如，你到超市買隻魚，可透過 RFID 知道這隻魚從出生到販賣的所有流程：他在哪裡被飼養、吃的是哪些飼料、什麼時候捕獲、什麼時候配送等。 簡單的說，過去我們只在乎魚這個『產品』，現在，我們在乎它被產生的『過程』。 為什麼？ 因為過程代表著品質 。光看魚的眼睛或紅鰓並沒有辦法完全代表他的品質（有聽過一些不肖的商人用漂本粉的吧），當我們瞭解他被生產的過程，例如是不受污染的環境與飼料，我們更能相信它的品質。 軟體工程裡所談的需求管理或 需求追溯（requirements traceability） 有類似的概念。過去我們寫程式、產生系統，也僅重視他最後的產品：能夠順利的執行、畫面十分的平順就好了。但軟體是需要維護的，如果我們沒有紀錄軟體的歷程，那麼一旦需求變更，我們就很難知道所要對應修改的模組。 進一步思考，我們的軟體系統有沒有 RFID？可不可以透過一個機制記錄它被生產的資訊，例如：經過哪些人設計、分析、測試，它的版本修改為何？如果一個沒有被完整測試過的系統，我想我們應該不會有買的意願吧。

718 水災在全台造成了嚴重的影響。我的老家在高雄縣的一個鄉下，過去只要是中型的雨就會造成淹水，鄉民苦不堪言。新的鄉長上任後誓言改善水患，這兩年來即使是豪大雨來也沒見過淹水，可見得事在人為。 台中這次少見的受創嚴重，幾個重要的路段都嚴重癱瘓，我因此查了一下雨量: 單日雨量 597.5 毫米，是台中氣象局有史以來第二高，僅次於八七水災。好玩的是北屯區並沒有因此大亂，反倒是西屯區受創。其實重點並不是在於單日雨量，而是在瞬間雨量，連市長也說了 「就是雨下太大了！沒有沒的原因」、「瞬間雨量之大，創下十多年來新紀錄。」 我好奇的上網查詢瞬間雨明確的值，無奈都沒有資料。這讓我聯想到當軟體工程師寫系統規格書時，通常沒有把效能需求清楚，到時候出現問題了，只好各持一方，也各有各的委屈。 以校務系統為例，最大挑戰之一就是一學期一次的選課，因為那也是瞬間湧入的大量要求，好的系統分析師必須去分析可能的量，再依據這個值去做設計、測試、驗收。好吧，最可怕的值就是全校的學生都在開放選課的那一秒同時湧入，那麼約末是一萬五千人，我們的設計就必須朝這個方向去前進，壓力測試的時候也要模擬這麼多的量，然後做系統的調校。如果市長可以明確的說：『我們系統可以允許瞬間雨量每小時100毫米並持續兩小時，無奈此次是200毫米又持續三小時，超過我們的負荷量。氣候的異常必須讓我重新思考一個新的系統』（此數字純為假設）， OK，這樣比較科學吧！ 但其實我覺得解決的方法也沒有那麼複雜。我看我們新任的鄉長就是多了一份 SOP 的程序：只要一有颱風來，一定派出大量的人清理排水孔，光是這一點就解決一大半的問題。三年前我到香港城市大學參訪的時候，正好下著小雨，有可能有輕微颱風入境，他們就到各排水口仔仔細細的移除每一個可能的雜物。你說他們比較自動自發？我倒相信他們是有一套標準程序，並且確實的落實著。 CMMI 講的就是一些標準程序，我們不能老是因為人而相信系統，人常常會變，組織的程序卻可以傳承。 雖然我不是水利專家，但我相信所有的工程都有其共通性，在政府又準備花大錢整治水利之時， 千萬不要忘了標準程序這一塊 ，要不然只是買了一些高級設備或白花了銀子而已，沒有多大的用處。