輕鬆談軟工

一夥程式設計師正在啟奏當今皇上。『今年有什麼偉大的成就嗎？』皇上問道。 程式設計師私下討論了一會兒，然後回話：『比起去年，我們今年多修正了50% 的Bug』 皇上滿臉困惑的看著他們。他們顯然並不知道『Bug』是什麼。他低聲與宰相商量一會兒，然後轉向這些程式設計師，面露慍色。『你們犯了品質管制不良之罪。明年起不得在有任何的Bug！』他當庭宣下這道聖旨。 當然啦，明年當這夥程式設計師再度向皇上奏報時，就完全不提 Bug 的事了。 以上是取自 G.M. Weinberg 的著作 Quality Software Management v1: System thinking 的中譯本： 軟體管理學-系統化思考 內的一個小故事。Prof. Wenberg 是我個人滿喜歡的一位軟體工程作家，他總是能用淺顯易懂的小故事道破許多軟體工程的問題。把這本好書推薦給大家，有空的話真的可以好好看看。

自從2002年Scott W. Ambler寫了一本叫" Agile Modeling - Effective Practices for eXtrem Programming and the Unified Process "以來，Agile Modeling(AM)的觀念與方法逐漸大行其道，由於AM的觀念可用之於各種物件導向軟體發展方法上，因此希望來輕鬆談談AM這種方法論(methodology)，以收拋磚引玉之效，同時也呼應『目』與『F』那篇文章。這篇文章所談的大部分來自Ambler的說法，我只不過摘要式地加以闡述，但仍然可做為軟體工程師創製模式時借鏡。 依照Ambler的定義，AM是一種渾沌、實用為基礎的方法論，其有效地用於模式化與文件化軟體系統，「渾沌」(chaordic)一詞可說道盡AM的精神，依個人的詮釋是「不受限但處理的事物漸趨規則」之意，也就是說，規則來自於渾沌的演進，至於此地所說的方法論(methodology)並非指發展軟體的方法，而是指每天由軟體專家們應用的一些常規(practices)，這些常規依照AM原則與真義(value)而定。Ambler依他的經驗，擬定了核心與補充原則共17項，以及共21項的常規，至於AM的真義有4項來自於XP(Bechk 2000)，但加上「謙卑」(humility)一項，而形成Ambler所說的AM真義，我想這5項真義值得加以簡單說明，因為所有的原則都源自於這5項真義： 溝通(Communication)： 發展團隊成員之間以及專案相關人士間的溝通必須有效。 簡單(Simplicity)： 發展符合需要的最簡單的解決方案。 反應(Feedback)： 盡早並且時常獲取對工作的回應。 勇氣(Courage)： 要有嘗試新技術的勇氣，而且成為決策。 謙卑(Humility)： 必須謙卑允許別人提供對於你專案工作的意見。 這五項真義以及各項常規與原則是引自於敏捷聯盟(Agile Alliance)的四項敏捷宣言，因篇幅受限，我不便在此地詳述這些17項原則與21項常規，讀者如有興趣可參考Ambler著作Agile Modeling，或網頁： http://www.agilemodeling.com/ ，不過我希望討論其中最主要與實用的「簡單」這一項真義所在。 Unix的發展者之一P.J.Plauge

從7月份起，我陸續發表了3+1篇有關MDA的介紹文章，其中+1這篇是：『利用「原型樣式」快速發展軟體』一文，對於這種快速發展軟體的方式可能一般人不太熟悉，但無妨。對於這幾篇MDA相關的文章，讀者反應卻十分冷淡，可能與文章的內容有關，其實我盡可能不談理論，只談一些觀念與技術。這一篇「MDA續篇」仍然不涉及太多的理論敘述，但仍然無法避免，我盡可能平述基本理論概念。我假設讀者已看過3+1等四篇文章，對於MDA的輪廓諒有所了解，這篇文章希望補充一點MDA的基本原理。 MDA的基本原理： 下圖顯示MDA之所以可用的原因。 (點選放大) 圖中，除CIM->PIM的轉換須依賴人工技巧之外，其他模式轉換通常可借助工具來作業 (註： M2M = Model-to-Model，M2C = Model-to-Code)。對於MDA而言，模式間的轉換有重要的意涵，就是在較高抽象層次(abstraction level)作分析，也就是建構PIM，設計的抽象層次較低，程式的產生更低，從高抽象層次轉換到低層次的作業則盡可能借助自動化工具(理由已如3+1文章內所述)，例如M2M以及M2C則自動化轉換，這種不同抽象層次的作業完全符合所謂「事務分離」(separation of concern - SoC)的架構法(architectural approach)，SoC可以讓業務分析者集中在業務邏輯的分析與設計而不必考慮系統的細節，簡言之，分析者只要管好(包括發展與保養)PIM即可，為達到這種SoC，OMG因此定義不同抽象層次的觀點(view)，即CIM、PIM、PSM、與Code (OMG的MDA樣式並不包括Code)。 MDA是軟體發展的一種骨架(framework)，因此適用於你所使用的任何軟體發展方法，例如你可以用傳統的分析與設計法，或敏捷模式化(agile modeling)，或+1文章內所談的「原型樣式」(archetype patterns)來描述CIM與製作PIM，所以不用改變你所學的東西，就如Grady Booch所說的：公司要訓練MDA專家並無困難，也就是說只要懂一點UML而且仍然可保持所學，以減低訓練費用，同時，使用MDA技術尚可加速ROI。(註：最近有人提議使用OMG最近所提供的Business Process Modeling Notation (BPMN) 來描述C

物件導向設計是近十年來軟體工程很重要的課題，除了物件程式設計的技巧、方法論、設計流程以外，工具也是相當重要。在Rational Rose 被IBM併購之前我就使用過它的 UML 設計工具，當時它是我電腦的必備軟體之一，因為不只是上課、做系統需要，我甚至會用它來做一般事務的知識管理。 但隨著UML的快速改版，Rose的改版速度也相當的快，不僅如此，價格飆升也相當的快，快到我追不到。於是，我開始改用open source的一些方案，例如 ArgoUML以及在 Eclipse 上的UML。然而，這些系統的穩定性都不夠。後來，在資訊處中開始使用搭配 power builder 的 power designer，雖然功能與穩定性不錯，但推廣的狀況卻不是很好。 這幾年的感覺是，不要太拘泥於軟體工具的選擇，應該回歸到設計的本質， 其實紙筆就是最好的工具，相互討論就是最好的方法論 。軟體工具採用反而造成相互討論的困難，對設計造成傷害。一群人圍在圓桌上討論設計圖才是最重要的。 用紙筆做UML的設計還是有技巧的。過去我劃類別圖時先劃上一個像『目』的圖案 -- 其中最上面的格子寫上類別名稱、第二個格子寫上屬性、第三個格子寫上方法名稱 -- 但這個方法不好。因為屬性與方法的個數會在討論的過程中不斷的新增，所以固定大小的『目』造成了許多的不便。如左上圖的『F』則保留討論上的彈性，你可以在討論的過程中不斷的加上屬性與類別名稱，且名稱的長度也不會受限。直到你的設計告一段落（例如討論好一些 sequence diagram）才將F關住，成為『目』。 我特別將『F』設計成一個圖形，藉此，傳達軟體設計上『互動』、『敏捷』、『慎重』的重要性。工具依舊是重要的，但在設計初期的時候。我還是強烈的建議使用紙筆來做腦力激盪。

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

本來應該寫在 Code inspection 的代價 一文的意見中，但考慮到內容比較多，故還是以一文說明。 看了許多專家的看法，我也提出自己的看法。我的假設是這樣的 Programmer 的月薪為 35,000/月 資深的 inspector 月薪為 60,000/月 速紀員可能是系統助理，月薪較低，為 28,000/月 主席的月薪為 60,000/月 雖然一天工作八小時，但扣掉一些喝水、聊天的時間，一天工作有六小時應該不錯了，所以 這些角色分別的時薪應該分別為 182 (35000/((30-8)*6)), 312, 145, 312。真的是蠻低的吧。 在 overview 階段 review 的速度為 500/statement, 所以共需 2 小時，假設 overview 的階段 scriber 不需參加，則成本為：(1*182+2*312+312*1)*2 = $2,236 在 individual preparation 階段 review 的速度為 125/statement, 所以共需 8 小時，因為此階段 scriber 與 chair 不需參加，則成本為：(1*182+2*312)*8 = $6,448 在 inspection 階段每個人都要參加，因為 review 的速度為 90/statement, 所以共需 11 小時，則成本為：(1*182+2*312+145*1+312*1)*11 = $13,893 在 follow up 的階段進行除錯，假設錯誤率為 3%，亦即有 30 個錯誤，而程式員除錯的效率為每個錯誤需要五小時除錯，則需要 5*182*30=27,300。 加總以上的成本則共為 $49,877 。但這可不是這 1,000 行程式的成本， 這僅是 code inspection 的成本 ，不包含分析、設計、實作與後續動態測試的成本啊。光這樣看來，每行程式的價值就有將近 50 元， Szuwulin 所言『 五 行一塊錢』似乎是少了些。 問題是台灣很少執行 code inspection 的動作，而是以後續的動態測試才取代。我們知道， 動態測試是治標不治本的方法 ，它 能找到的錯誤是比較少的。假設有有一半的錯誤沒有在動態測試中被找出來而不小心流到使用者手上，那代價可能很難估算。第一：如果造成客戶的業務損失; 第二：維護階段除錯的效

除了動態測試（執行程式來檢驗是否正確）以外，靜態的檢視也是非常重要的測試方法。檢視的對象可以是 code, 設計文件、需求文件等。當檢視的對象是 code, 我們稱之為 code inspection，一般而言有以下的角色： 撰寫者 (owner) ：程式的撰寫者 檢視員 (inspector) ：檢視程式的錯誤，通常都是較為資深或領域專家 速記員 (scriber) ：在檢視會議中幫忙記錄 主席 (chair/moderator) ：仲裁與協調會議的進行 在分工比較細的組織中，甚至還有報告者，但可以撰寫者來兼任。靜態檢視可以分為幾個步驟 簡介 (Overview) : 由撰寫程式者向所有的檢視者簡介系統內容 獨立準備 (Individual Preparation): 每個 inspector 獨立的閱讀與檢視程式碼，並將疑問處圈選出來，預備在會議上討論 檢視會議 (inspection): 檢視程式碼 追蹤 (follow up) : 修正會議上所找出來錯誤，並持續追蹤 依照 Sommerville 書上的資料顯示， 簡介、獨立準備、檢視會議  的速度分別是 500, 125, 90 statement/hour, 假設我們完成了一個 1,000 statement 的程式碼，檢視員有 2 位， 請問一次 code inspection 花公司多少錢？值得嗎？ （請假設每個員工的薪水）。有興趣的大家一起算算吧！

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

針對與時間因素有關處理的潛在錯誤而設計的測試案例，可能是嵌入式軟體測試的另一個精華表現。譬如，不少人都有如此的經驗：只要不規則地亂按一些按鍵，有時就可把手機或其他手持設備弄當掉，必須重新開機才行；但若要詳細說明如何才把那個機器弄當掉的，卻又說清不楚，也不一定有把握每次都可以把機器弄當掉。 我們都知道在硬體沒有問題的前提下，如果發生當機狀況就是因為軟體中有錯誤存在(反過來則不一定，即軟體中有錯誤卻不一定會造成當機)。但是，在看似相同的使用過程(或給予相同的輸入資料)中，有的時候可以正常運作，而有的時候卻發生當機，那是怎麼回事呢？一般來說，是因為受到時空因素不同的影響才可能產生這種現象。先舉一個類似的例子來說明：如果一個星期以前用"ABCD"為關鍵字在 Google 上搜尋所得到的結果，與一個星期之後同樣用"ABCD"為關鍵字在 Google 上搜尋所得到的結果，兩者不一定是相同的；因為網路上那麼多人在創造資訊，只要時空因素有改變，雖然其他同樣的處理程序及條件不變，輸出的結果就可能會不一樣。如果需要掌握輸出結果，就必須能掌握時空因素的描述，譬如當清楚指明使用 Google 搜尋的確切時間以及地區別時，也許 Google 就能再度輸出一份完全相同的結果(當然這要看 Google 提供的服務功能到底有多強才行，在此只是個協助說明的例子)。 一個成功的、以找出可能與時間因素有關錯誤為目的的嵌入式軟體測試案例，是可以清楚地描述如何用一組輸入資料(包含輸入順序、或時間間隔等等說明)來把機器弄當掉的。只要依照測試案例的內容來執行測試，如果實際輸出結果與預期的輸出不同(譬如當機了)，那這個版本的軟體就存在著某種(即測試案例的目的所描述的)時間因素有關錯誤。另外一個重點是，不會發生有時正常、有時卻不正常的狀況，因為成功的測試執行結果必須要能隨時再產生(reproduce)。 獲得這樣一個測試案例設計的費用，若相當於一個軟體工程師半個月的薪水，你覺得是便宜還是貴呢？(再提醒一次，相對而言，嵌入式軟體的測試是比較簡單的軟體工程技術應用。)

這次辛樂克怪颱侵台，重創台灣，其中后豐大橋斷橋，造成1死5失蹤的大不幸事件，照理颱風來前就必須封閉該危橋，但事後我們的官員說依照「程序」處理，這種說法讓我想起陳振炎教授文章所談的敏捷方法，我曾在其「意見」箱內談到，使用任何敏捷方法時不要忘記敏捷宣言的精神，我認為宣言的精神不但使用敏捷方法時必須時時在意，處理日常事務亦須念茲在茲，宣言第四項"Responding to change over following a plan"，"plan"可解釋為一種「程序」，程序故然重要，但反應變動應高於程序(不含法律)，這位官員在這個時候的這種說法有待商榷，也許他的字典裡沒有「敏捷」這種東西吧! 敏捷(agility)最重要的定義是：快速與彈性反應改變(rapid and flexible response to change)，或說"embrace change"，change就是一種變動，能快速並彈性處理各種變動(如封橋)才符合敏捷精神，因此如能活用敏捷之義，其功能大矣! 總之，如果不懂embrace change，可能會誤用各種發展「流程」的真義，我們可以看看CMMI ML5：具調整與修正流程的能力‧‧‧，(本部落格中鄭有進教授文章：CMMI是什麼？)，將發展流程客戶化就是調整與修正流程，可想見使發展流程適合自己專案之需的重要性，但這要靠人，所以說"People over Process"。

這是我還在讀研究所時所發生的事。有一個在職的同學突然間常常出現在實驗室，一副很輕鬆的樣子。他的公司在美國算是很大的公司（應該說是非常大的公司），軟體部門也非常大，而且他一向忙得不可開交，很難想像他怎麼有可能這麼輕鬆。原來他們所做的project 竟然提早一個月結束，team leader告訴他們不要讓經理知道他們已經做完，暫時享受一下悠閒的時間，所以他就有時間來學校晃一晃。 這種事當然不可能常發生，可是到底發生什麼？是招標端（客戶端）的評估能力差？cost estimation 的問題？project planning的問題？太高估了？假如兩方老闆發現了，會怎麼樣想？假如你是team leader你會作什麼？more testing? more refactoring?

台灣軟體業積弱不振, 可能因思維較舊所致: 工廠思維: 軟體工程在 1968 NATO 大會出現時, 仿效其他工程領域, 把軟體視為工廠生產, 講求精細分工 嚴格控管 注意產量成本等. 但新趨勢是, 軟體講求創意及合作, 像 工藝家聯合工作室, 而不像工廠. 電機思維: 軟體本由電機電子而來, 從The Institute of Electrical and Electronic Engineers, Inc, IEEE 這代表性機構的名稱, 即可看出此沿革, 但演進至今, 軟體已與電機無關. 軟體業界深知軟體開發(含物件導向開發)需製作大量文件( 含程式)，構成龐大負擔，常導致很多溝通不準或思考不週之處 (即 Bugs)。有些公司製作不少文件卻乏人閱讀，全無溝通之效；甚 或冀望多年後維修程式時，將會閱讀文件， 殊不知程式是不斷變動的，文件更新常趕不上變動的。 敏捷方法視開發為合作活動(如攀岩)，力求以面對面直接溝通， 來取代目前文件製作及閱讀的間接溝通，使開發變得快而準(即 agile)。 又，敏捷方法以測試來帶動開發 (Test-driven development)，軟體品質極佳。 最後，除國外重視的溝通訓練外，吾人亦加強國人不足的思考訓練， 溝通及思考乃深層基本功；–練功後人人紮實、軟體優質， 再用逆向工程工具動態產生class diagram, sequence diagram等，有可能敏捷達 成CMMI 一些process areas 的 goals。 此敏捷方法係陳振炎教授擴充極限開發法 (extreme programming)而得， 方法細節請見下面網站的上課教材：敏捷方法苗圃 ( www.agilemethod.csie.ncu.edu. tw ) 陳振炎教授 國立中央大學資訊工程系

假設有一個非常簡單的嵌入式軟體，它的開機模組功能包括要檢查所有主機內 10 個硬體組件是否能正常運作；其中具輸出功能的燈號、螢幕、喇叭，具輸入功能的按鈕、麥克風，具儲存功能的記憶體等都必須完整檢查(否則就算開了機，使用者可能不知道，或是使用者知道已開機但操作按鈕卻無法動作)，其他的如插孔或卡槽介面就等要用時再檢查。 要怎樣設計測試案例來測試這個開機模組呢？負責嵌入式軟體的朋友最怕是硬體出毛病，自己不知道卻還一直在那裡找問題，所以就瞄準這一方面先下手無妨。測試目的就定為「找出螢幕壞了卻還繼續處理開機程序的錯誤」，測試步驟是找一台主機、把螢幕拆掉(或把相關連線拔掉、真的把螢幕弄壞等等)、然後按開關鈕。預期的正確結果應該是開機模組要用其他的燈號或喇叭來輸出訊息提醒使用者螢幕壞了，同時停止繼續開機的程序。真正測試的時候如果出現的不是這樣的預期結果就證明開機程式還有這個錯誤存在。 負責測試的朋友幫負責寫軟體的朋友找出這個錯誤以後，程式的邏輯處理內容就改成如果檢查到螢幕有問題就要用閃爍燈號或喇叭發聲來提醒使用者，看是要送修或怎樣，然後停止執行。這時候的潛在衍生錯誤就可能會發生了，譬如原來設計的開機檢查順序是先檢查螢幕再檢查燈號及喇叭，所以如果螢幕不正常時可以馬上就用燈號及喇叭嗎？它們還沒有被檢查呢。還有，如果螢幕有問題要先閃爍燈號，要閃爍多久後才停止繼續處理呢？需要再測試嗎？ 據一些有經驗的專家表示，現在採用以開放原始碼(open source)為軟體基礎的嵌入式個人隨身設備，例如 PDA 手機，其程式規模(包括系統軟體及應用軟體)大約在 500 萬行左右。可以想像的是，這裡面絕對是夠複雜的，不管它們是怎麼樣組合而成。如果再回頭去看那一段最基本的開機模組部份，最原始的版本可能只需要 200 行就足夠了；但是為了要陸續通過那些測試案例而再加進去的部份，會有多少行？說不定是 2000 行。另外的議題則是，加進這些行數以後的新版本，是否提高了產品的品質？如果是，那當初看來似乎沒有什麼了不起的測試案例就是有意義的。 相關文章： 嵌入式軟體的測試(一)

最近因為接了行政職，生活開始忙碌了起來。為了能夠讓訊息暢通與方便行程的安排，忍痛買了 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

嵌入式軟體、客戶訂製軟體、套裝軟體三者，那一個最難設計製作？那一個又最簡單？這些問題也許因為立場或看法的不同而會有不同的答案；不過我是認為嵌入式軟體應該是最簡單的。主要的依據是一般嵌入式軟體都只需要跟硬體打交道，只要都打點好就行；但是如客戶訂製軟體就不一樣，必須跟人打交道，而偏偏每個人的想法或看法卻不一定相同，很難搞定。套裝軟體就更複雜了，在設計的時候可能還不知道將來是那些人會買來用的。 順著這個邏輯，嵌入式軟體的測試相對而言也會是比較單純的。(補充一下，如果沒有領域知識，那任何軟體的設計製作都會是很難的。所以如果是因為對於嵌入式軟體是怎麼一回事還不太清楚而認為嵌入式軟體最難的朋友，也許在開始接觸過一陣子之後就會改變想法了。) 嵌入式軟體的測試，主要是組態測試(configuration test)與控制測試(control test)。組態測試是要找出軟體模組之間可能的不協調(synchronization)，而控制測試是要找出因為時間掌握(timing)沒有考慮週到所發生的不協調。以嵌入式系統開機功能為例，負責開機功能的軟體先要分別檢查所有的硬體(如記憶體及其他晶片組等等)是否能正常運作。最簡單的方式是循序一樣一樣來，但是如此開機時間就長，使用者無法接受；因此投機的方式就是只檢查最主要的幾樣，其它等將來要用的時候再檢查，節省時間。設計這種測試案例，是最典型的嵌入式軟體的組態測試技術。 如果對這個有興趣，可能還需要去參考一下軟體工程書上給予「組態」的定義：一組為達成某一共同目的、由組態項目所形成的集合。組態測試就是要設法證明某個嵌入式軟體的組態事實上不完善，不符合組態的定義。(PS. 希望這一段寫得不要太玄。) 相關文章： 嵌入式軟體的測試(二)

「所有具優良結構的物件導向軟體架構，其內部都充滿樣式(patterns)」，Grady Booch這句話乃是提供本人寫這篇 輕鬆談 的動機。其實，在各種行業中，製作複雜系統時樣式往往扮演重要的角色，由樣式所建構的軟體具有彈性、模組化、可重用以及易解的特性，軟體系統如具有這些特性則不旦能夠符合需求，而且能夠輕鬆反應需求變更，我想這種軟體應該就是品質好的軟體。樣式有許多類型，如分析樣式(analysis patterns)，架構樣式(architectural patterns)，設計樣式(design patterns)，程式樣式(idioms)，或「 原型樣式 」(archetype patterns)等等。本文所要談的是，原在『漫談「模式驅動架構」(二)』中所設計的MDA過程( CIM->PIM->PSM->Code )，我們將利用 原型樣式 改變成為： 選用業務原型樣式->產生PIM->自動化轉換成PSM->自動化產生程式 CIM則成為選用適當原型樣式的指引，這個過程的重點在於PIM的產生，適應原型樣式產生的PIM比一般標準的物件導向分析與設計(OO analysis & design)快速而且簡單，符合敏捷精神。本文約略來談談利用「原型樣式」快速發展軟體。 何謂原型(archetype)？有多種定義，這裡所談的原型是指「一種原始的(primordial)事物或環境，這些事物或環境前後一貫地重覆發生，而且被認為具有普遍性的觀念或狀況」，如果這些事物或環境是指業務範疇與業務軟體系統，則稱為「業務原型」(business archetypes)，業務原型之間的合作(collaborations)則稱為「業務原型樣式」。Jim Arlow與Ila Neustadt提供9種業務原型樣式，包括： Party ， PartyRelationship ， CRM ， Product ， Inventory ， Order ， Quantity ， Money ，以及 Rule 等業務原型樣式，這些原型樣式皆重覆發生在業務範疇之內，你/妳可以現用或經修改這些原型樣式來建構分析模式，這種技術稱為 「元件基塑模」(component-based modeling)。我們利用經修改的Order原型樣式發展Order Processing S

對於軟體開發人員而言，好的測試案例應該是很有價值的東西，因為如果一個軟體在依據一個測試案例進行測試執行時無法得到正確的預期結果，就知道有某個特定的錯誤存在；而如果這個軟體能在依據所有的測試案例進行測試執行時都得到預期的正確結果，那就不會有人可以說什麼話了，乖乖地付錢給寫程式的人吧。(當然，這必須是針對所謂「好的測試案例」才有意義，否則隨便寫兩、三個測試案例，寫程式的人也可以隨便寫幾行程式就應付自如，只是程式還是無法使用，自欺欺人而已。) 從這個角度來看，會設計「好的測試案例」的人應該在軟體開發團隊裡是有其一定地位的，這種人與一般寫程式的人在心態上就不一樣，大多是以「防禦性」或「預防性」的方式來處理程式邏輯；譬如從來不假設所有可使用的資源(如記憶體)是永遠不會有問題的，因此只要需要任何資源都會先確定這個資源的取得沒有問題才開始動作，否則就進入特殊狀況處理程序。這種人設計的測試案例非常細緻，專門找平常不容易出現的錯誤。(正常狀況都無法得到正確結果的實在不夠資格稱為軟體，真的。) 經驗豐富的軟體從業朋友在工作時是很有樂趣的，旁人只見到高來高去的溝通，而且非常有效率，一點都不八股，同時生產力與品質都有一定的水準(agility?)。在這種環境之下，似乎需求說明文件或需求規格都可以抽象化，文件規模大量減少，幾頁的文圖就可以描述一個應用系統，尤其是不太需要人機介面的核心模組。這些文件原有內容跑到那裡去了？答案是測試案例，那些細緻的、正常狀況下都不會發生的可能預防作為描述，都在測試案例說明裡面。 專家們相信，測試案例與需求規格兩者很可能是相同的東西，就像是拓樸學裡介紹的梅比烏斯帶子(Mobius Strip)，沒有裡面或外面之分；而測試案例比需求規格略佔優勢的地方是，測試案例的描述一般比較明確，需求規格的描述則會弱一些。對軟體開發階段與轉換程序而言，越是明確的描述，越能讓轉換所得的軟體堅實(solid)。這個觀點目前應該是還沒有方法來證明，所以只在提出與討論的階段；雖然有可能是亂想一通(研究的過程之一)，但感覺上似乎不離譜。 你的看法如何呢？難道只是又把需求分析的工作藏到測試案例設計去了？

寫程式的人也要負責最基本的軟體測試工作，那就是單元測試的部份。也因為如此，這類測試常常會跟除錯一併進行，反正一個人要能負責把程式弄好(最起碼在自己能設想到的普通狀況下要能算出正確的答案)，用什麼方法都行。 除錯器(debugger)是最有效的軟體開發輔助工具了，設定中斷點，程式執行到那裡的時候可以逐次檢查各個暫存器的內容、變數的值等等，所有狀況清清楚楚，好不威風。如果沒有除錯器支援怎麼辦？沒關係，自己來。沒有把握的程式部份就在裡面多加一些指令或敘述，把當時的環境狀況、變數現值印(顯示)出來，然後追蹤看看到底自己腦子裡想的、手裡寫出來的，以及編譯器、函數庫、作業系統等系統軟體所轉換出來、認知的，究竟有什麼差異。通常弄明白以後，錯誤就能除掉了。 如果這個概念明確，那是不是可以考慮把測試案例就寫在原來的程式裡呢(怎麼寫先不管它，因為現代的程式語言都蠻複雜的，相關測試輔助系統也還不夠人性化)？當程式執行時「恰好」遇到與測試案例所規劃的狀況相同時，就表示在作單元測試了，預期正確結果可以與當時的計算結果比較，如果兩者相同就不作任何動作，否則就進入例外特殊處理的程式部份。如此，雖然有一點吹牛，但以後當我再說「給我測試案例，其他免談」的要求時，是否表示我這個寫程式的可能已經到了精益求精的水準，負責測試的同仁也不敢不給我了？ 事實上，XP(eXtreme Programming) 派軟工朋友所提倡的 Test Driven Development 方法就是在這些方面表現其功力。他們定義的 unit test 就是一段 code，能達到相當於處理單元測試工作的功能，而不是傳統的一個程序(到 Wikipedia 網站上查一下就可以找到很多相關資訊)。

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

敏捷MDA (Agile MDA) 在「模式驅動架構」(二)中，我們以圖形表示MDA過程 (MDA Process)，理論上，Code，PSM，與PIM之間可以反向轉換，但事實上十分困難，因此圖中只顯示向前轉換，實際上也是依照這種方式在運用MDA，只要發展PIM，其他模式皆可以以自動轉換方式產生，因此，PIM可視之為可執行的模式 (executable model)，這顯示MDA支持敏捷軟體發展(agile software development)。我們要在本文漫談MDA與敏捷(agility)的結合，稱之為「敏捷MDA 」(Agile MDA)，這個名詞可能是由參與擬定MDA標準的Stephen J. Mellor首創。 那麼， 我們先談談「敏捷」(agility)的基本概念。依據世上許多公司行號的經驗，軟體發展專案的成功率偏低，以美國為例，有30%的專案未完成就得取消，一半以上的專案費用幾乎超過預測的兩倍，種種這些危機，主要原因是因為發展軟體費時費力，而且無法建造完全符合客戶需求的應用系統，多年來，各種各樣的軟體發展方法都在嘗試處理這類問題，但只不過增加一些文件而忽略人的因素，因此2001年2月11-13日在美國猶他州的Snowbird鎮有17位方法學專家聚會研議，共同發表所謂「敏捷宣言」(The Agile Manifesto)，這是該宣言產生的由來，宣言有4項，為不失真我們引用原文如下(讀者不仿參考： http://www.agilealliance.com/ )： Individuals and interactions over processes and tools Working software over comprehensive documents Customer collaboration over contract negotiation Responding to change over following a plan "over"右邊各項並非不重要仍然有其價值，只不過左邊各項依據agilty的觀念，其價值應較受關切，敏捷方法都與這四項宣言有關，這四項宣言都關係到人的運用與活動，例如發展者之間的溝通重於過程與工具的使用，專案的施行不能只有過程而沒有(好的)人，其他諸如迅速產生可執行的軟體、客戶的合作以及

以寫程式為生(領薪水)的朋友一般都不會擔心程式太大寫不完，但都討厭要配合所謂客戶要求的「需求變更」而常常要把已經寫好的程式不斷改來改去，作很多虛功。依據我的觀察，對這些程式設計高手而言，原來已經寫好的程式要再修改，大概超過 3 次就是耐心的極限了；因為此時的程式已經幾乎是變得體無完膚，不但客戶不會滿意，連寫程式的人自己看了也會想吐血。 對程式設計高手而言，寫程式從來不會有什麼問題，而要寫出「什麼程式才是真正你要的東西」才是大問題。偏偏，「需求變更」就是一個他人常用的藉口(因為不一定是客戶要求的，只要之前有人在需求分析階段有錯誤或偷懶沒有詳細分析，最後都可歸咎於需求變更)，反正是你先去寫，然後他再去看，刺激他的神經之後，再提出他的修改看法叫你改，如此永不疲憊。另一種狀況是，需求分析說明文件的內容只是應付軟體工程開發階段的記錄，非常抽象，譬如是「能令使用者感到愉快的一個小型輸入畫面」。 如果我是負責程式設計的，在看完那種「不可能的任務」(Mission Impossible)需求分析說明文件之後，我因為要繼續領薪水、又要能融入傳統的軟體開發工作團隊之中，我就可能會轉而要求負責軟體測試的團隊成員趕快先把測試案例設計出來，不要等到我把程式寫好了再用這些案例去測我的程式，請他們先把完整的測試案例給我。因為既然以後是要用這些測試案例來測我的程式，那我就依據這些案例的內容來設計我的程式，只要在測試執行時這些案例都能順利通過，我的程式就找不到與這些測試案例目的相關的錯誤了。 給我測試案例，其他免談。

CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法

軟體工程有許多觀念是比較抽象的，也因此有許多生動有趣的故事孕育而生，用來闡述這些生澀的觀念。這個部落格既然名為『輕鬆談軟工』，我覺得也適合談一些小故事。 有一個樵夫靠砍材為生，砍材的斧頭就是他主要的生財工具，也是所有家人的依靠。隨著小孩子一個個的出生，樵夫的經濟壓力越來越大，於是他越勤勞的工作，工作的時間越來越長。日子久了，斧頭生鏽越來越嚴重，木頭都砍不下去了，路過的人好奇的問：『老樵夫啊，斧頭都生鏽了，怎麼都不磨一磨？』 『開什麼玩笑？砍材都來不及了，哪來的時間磨斧頭？』老樵夫頭也沒抬的說。 這個故事主要談的是 流程改善 。許多軟體工程師每天都像樵夫一般勤奮的工作，可是工具、方法錯了，勤奮的工作並沒有帶來相對的報酬。他們或許感覺需要停下來改善工作的流程，例如規範需求變更的流程、設計版本控管的機制、研究專案成本的估算方法，無奈手頭上的案子每個都是十萬火急，只好暫時把流程改善的工作丟到一旁。這一丟可能就是好幾年，也丟掉可能成功的契機。 如何解決？我想組織必須要有 長痛不如短痛 的決心，另一方面，高階主管的鼓勵、決心與半壓迫的魄力也很需要。沒有決心，每個經理人都是以專案為重 - 能砍多少材是多少材吧，很難做長遠的規劃。

也許歐美的軟體都已經被別人測試得差不多了(雖然我們知道事實上軟體是測不完的，但總是會有人擔心說重要的軟體測試早已就被作掉)，所以我們不妨用中文資料處理應用中最基本的「排序」這個領域來看一下軟體測試的市場空間有多大(究竟我們的中文應用水準要比歐美人仕要強得多吧)。 假設有一個軟體模組 utility.sort 等著我們作黑箱測試。我們瞭解排序的基本計算方法對於程式設計師而言是很簡單的，而程式設計人員自己也已先作過單元測試，所以好像感覺上黑箱測試也玩不出什麼新花樣來。但是幾乎所有的軟工書上都說要先作等值分割，而稍微花一點功夫坐下來想一想，就可能會發現真的有許多不同的資料群組可以形成叢聚；譬如在數值方面，除了常見的整數之外，實數部份的有理數與無理數等等，都是等值分割的參考基礎。一般程式設計師是比較容易犯錯的原因不外是對這些數系定義域的忽略(因為唸書時都學過的)而已；試想，若把 0.33、1/3、1/3.0、3**0.3 等數值一起輸入此模組，執行出來的排序結果與預期的正確結果不同的機會可能是蠻高的。再進一步看，若把 123(數字)、一百二十三、壹佰貳拾叁、１２３(全形字)等數字及中文資料輸入此模組時，執行出來的排序結果是否會與預期的正確結果相同呢？我想機會是非常低的。因此，只在數值資料(不同資料格式)的定義域上作等值分割，就已經真的可以開始進行測試案例的規劃了(書上老掉牙的技術還是不錯的)。 接下來在非數值方面，那空間更是廣大了。中文資料的排序習慣上不外乎是依據筆劃或部首、注音等等，但不管怎麼樣，都不應該用內碼值的大小來處理，因為那是不具意義性的。若把王小明、李美麗、林國棟等姓名資料輸入此模組，執行出來的排序結果與預期的正確結果比較如何呢？此時突然發現所謂的預期正確結果本身就值得懷疑，為什麼是王小明、林國棟、李美麗？難道林國棟、李美麗、王小明就不正確嗎？顯然越想下去問題就越多。 是不是一個最基本的排序軟體模組就需要很多的測試人力呢？

自1955年開始有了軟體產業以來，軟體成為推動著世界向前邁進的主要動力之一。1993年，全球IT軟體與服務產值首度超過硬體產值，正式宣告了軟體成為資訊科技主軸的時代來臨。時至今日，不論是我們日常生活所及，或是在企業與組織內部，或是國防與太空科技，軟體都扮演了不可或缺的角色，主導著各類系統的運作，其對人類影響之深遠與巨大，可說是無遠弗屆。 談到軟體產業，就不能不談到與其息息相關的軟體工程。全世界軟體業發展成熟的國家如歐美、日本、及印度等國，不但重視軟體工程，也藉由軟體工程技術與流程改善來發展具有一定品質的系統與產品，讓其軟體產業在世界佔有一席之地。這裡談到的軟體工程，已不僅僅是過往大家所只著重的程式開發技術，它還包含了流程（Process）、塑模（Model）、與品質（Quality）等軟體開發的重要觀念。 回顧台灣過去約三十年的軟體產業，長久以來一直未能蓬勃發展，目前似乎更已陷入瓶頸。這幾年來，政府與民間合力推動了一些對整體軟體產業具有實際而深遠影響的計畫，這些計畫大致上可以分為四個主軸：從經濟部CMMI品質能力提升計畫、教育部軟體工程聯盟計畫、研考會SOA軟體架構為基礎的電子化政府計畫、到軟體市場東進計畫以向外承接軟體外包市場，目的在建構軟體產業的基礎環境以及擴展市場，進而提振整個產業。 個人認為台灣的軟體產業要走出自己的一條路，除了政府與民間原有的努力之外，應該要有更寬廣的軟體工程新思維以及更聚焦的作法，可歸納為由下到上四個層面：第一是軟體知識，第二是軟體教育，第三是軟體流程，第四則是軟體市場。 在軟體知識部分，必須將軟體知識與領域知識合一。整體產業的未來發展應該要能結合專業領域知識與軟體知識，這又可分為三個層面來談，其一是國內軟體公司雖然具備相當的專業領域知識，但相對而言，軟體知識以及軟體系統整合的能力則較缺乏，因此必須著力提升其軟體方面的知識與能力，才能與原有的領域知識相加相乘，建立更優越的競爭能力；其次是過去數十年來，台灣擁有相當多紮實優異的傳統產業，雖然隨著科技與時代進步而逐漸式微或外移，但是如果台灣的軟體公司能將專業領域擴展至傳統產業，藉由兩者的結合重新賦予傳統產業全新之生命力，而軟體產品服務亦可隨著傳統產業的外移而向外擴展，發光發熱；最後台灣軟體產業則應與目前在世界佔有舉足輕重地位的台灣硬體系統產業結合，藉此提高嵌入式軟體的開發與測試市場，走出原有的

軟體測試相關的詞彙很多，最常聽到的可能是單元測試、整合測試、系統測試、alpha測試、beta測試等與一般軟體測試工作階段有關的區分說法，或是如黑箱測試、白箱測試等與軟體測試方法有關的區分說法，或是如驗收測試、回歸測試等與軟體測試基本觀念有關的說法。另外在非功能需求方面如：人機介面測試、資料庫介面測試、網路介面測試、例外狀況處理測試、多國語言支援能力測試、資訊安全防範能力測試等等，也都是目前很普遍的說法。雖然這些詞彙原則上都是直接由英文翻譯過來，但軟體從業人員或軟工學生應該多少都能知道它們的含意及大致內容。 不管怎樣，有這麼多種的詞彙就可能表示有這麼多種不同的軟體測試工作需要處理，或許是要人力來擔當，或許是要用軟體工具來協助。從另一個角度來看，這就是商機，因為需要人力就代表著業務機會(企業)或是工作機會(個人)，而需要軟體工具就是軟體產品的市場機會。 我們來看一下軟體測試的市場有多大吧。一般軟體工程專業人士認為軟體測試相關工作的比重大約是整個軟體開發工作的 40% 以上，而程式寫碼相關工作的比重則約是整體軟體開發工作的 15% 以下，其他工作包括需求分析、設計，以及品質管理、組態管理等。如果以微軟視窗系列產品(如 NT、XP、Vista)開發的人力資源記錄來看，大概每一項產品都約在數千人年(NT: 900人x3年=2700人年、Vista: 1500人x5年=7500人年)，因此其中任一項的 40% 就表示至少 1000 人年的軟體測試人力資源需求。 在台灣，假設一般中小型軟體公司每人年的營業能力為新台幣 100 萬元，則 1000 人年的軟體測試的潛在市場即為新台幣 10 億元，或是相當於目前 10~20 個具 50~100 人力規模軟體公司的共同年營業額。

每次我在課堂上開始介紹軟體測試的目的是要「證明程式中有某一種錯誤」，而不是要表示程式是對(註*)的時候，總是有不少學生會瞪大了眼睛，或是以為我不小心說錯了，或是認為這是一個不可思議的說法，因為這跟自己以往的直覺認知完全不同。 (註*：以目前使用的軟體開發方法而言，一個典型的軟體幾乎不可能沒有錯誤存在。) 其實，軟體測試作法(也就是證明程式中有某一種錯誤)的原理很簡單：假設我們認為一個程式裡存在著一種錯誤 e。我們特意去設計一組輸入資料 I，如果把這組資料輸入到這個程式來執行時應該得到的輸出結果是 O。然後我們真的把這組資料拿給這程式來執行，得到 O' 的輸出結果。如果 O 與 O' 不同，那就證明這個程式果然有 e 這個錯誤。 軟體測試的原理說來簡單，但要想出可能存在的錯誤種類以及設計一組可以找出這種錯誤的輸入資料，就必須有幾把刷子了。通常這就是「測試案例設計」的專業工作，先要能規劃出到底一共要設計多少個測試案例(也就是想好要找出那幾種程式設計師可能會犯的錯誤)，然後再在每一個案例中設計出一組或多組輸入資料與執行後應該得到的正確輸出結果。 依據別人設計的測試案例把資料輸入、記錄輸出結果看看與應該得到的正確結果是否相同的工作報酬，事實上與在麥當勞打工的數字是差不多的，因為不需要太多專業技能(當然還是要有基本的知識，並不是每個人都能勝任在麥當勞打工的工作的)。但是如果能夠設計好(註**)的測試案例，那就會有很顯著的報酬差異了，說不定可以多一個零。 (註**：譬如找出錯誤的機率比較高，或找出的錯誤可以大幅增進軟體品質等等。) 以往台灣的製造業多以代工為主業，產品的組態都是由下單的買主自己規範；現在台灣的製造業對自有品牌的意識越來越強，產品的組態，尤其是其中軟體部份(譬如智慧型手機的嵌入式軟體)的品質，更已成為競爭的要素。如果大多數的軟體從業人員都在寫程式的紅海裡辛苦打拼，是不是，相對地，軟體測試的藍海是另一個不錯的取捨呢？

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

CIM - PIM - PSM 樣式 在「漫談模式驅動架構」(一)中我們談到，OMG將MDA建構成CIM-PIM-PSM樣式，程式則由PSM轉換(transformation)而成，這是依照一種較合宜而方便的觀點(viewpoints)所形成的樣式，事實上MDA卻允許有其他的觀點，而產生其他的樣式，但CIM-PIM-PSM樣式的重點在於其提供「事務分離」的概念，因此我們仍然以大家接受的OMG樣式來漫談 ，實際運作時，該樣式可以延伸成CIM-PIM-PSM-Code 。 何謂CIM，CIM有時稱為「範疇模式」(domain model)或「業務模式」(business model)，用來描述業務系統，但本身並非軟體，這個模式表示系統的關鍵需求，以及描述問題範疇的字彙(vocabulary)，但不涉及系統的細節，一般物件導向系統分析方法就可用來建構這個模式，PIM就是依據這個模式而產生。 PIM是表示業務邏輯(business logic)的模式，這個模式顯示系統的工作內容，但不涉及與任何特殊技術平台(technology platform)的關係，如EJB，.NET或關聯性資料庫等，PIM類似OOA的分析模式(analysis model)但更為詳盡完整，每一種業務只有一種PIM。至於PSM則結合PIM所擬定的規格來顯示系統將如何在特殊技術平台上實作，因此它是由PIM轉換而來，程式則由PSM轉換而得。PIM，PSM與程式之間的轉換可以用人工，但一般皆使用MDA工具來擔任，因人工不但費時而且可能出錯。在此我們引用Booch等人的所謂「MDA宣言」(The MDA Manifesto)來支持這個觀點，宣言有三點：(1) Direct representation; (2) Automation ; (3) Open standards，因篇幅關係我們不在此地詳談這三點宣言，因為自動化涉及MDA的運用甚巨，因此我們希望強調第(2)點 - 自動化轉換。以上說明對於不熟悉物件導向軟體工程的人士可能較為抽象，也許下圖(雖然不很完整)可以協助了解MDA的運作方式： （點圖形放大） 圖中我們同時將MDA與傳統的發展過程做比較，兩者之間的生命週期差異不大，但MDA主要特點在於 PIM->PSM->Code的自動化轉換，保養是在PIM而不是程式，PIM是唯一代表業務邏輯的模

「模式驅動架構」(Model Driven Architecture - MDA)的由來 「漫談模式驅動架構」將分3期來簡述 MDA 技術的內容及其影響，讀者如有興趣可參閱學會發行的 Journal of Software Engineering Studies, 2(1), pp.3-12 本人發表的文章，我們在這一系列漫談中並不深談MDA 的理論，而只希望談談這種技術到底為何，至於專有名詞不易翻譯者，原則上將延用原文，但必要時會加以解釋。要了解這一系列漫談的文章，讀者最好具備物件導向的一般觀念。 2002年早期, Object Management Group (OMG ) 聲明，MDA 為其策略方向，並於2003年6月發表"MDA Guide Version 1.0.1"，至此 MDA 的發展有其「官方」依據。 MDA 是基於所謂 "事務分離" (Separation of Concern) 以及 "抽像化" (Abstraction) 的原理與觀念而設計，因此系統分析師與發展者可以集中精神在事務邏輯的分析與設計上，而不必顧慮系統層次的細節，例如將來系統要在何種平台上實作等問題，為達到這項目的，OMG 在發表的 「MDA指引」中定義 MDA的三種模式，建構這三種模式同時也顯示使用MDA來發展軟體系統的基本過程(process)，包括: Computation Independent Model(CIM); Platform Independent Model(PIM); 以及Platform Specific Model(PSM)，PIM 與 PSM是使用事實標準(de facto standard)的視覺化建模語言UML來描述，PIM代表業務邏輯，PSM由PIM轉換(transformation)而來，其顯示在特殊平台上的系統模式，程式則由PSM轉換產生, 這種轉換固然可以人工為之，但一般皆使用MDA工具自動化轉換，因人工轉換費時而且易錯，軟體產品如果依PIM-PSM-Code過程產生就可在「標的平台」 (target platform)上使用，我們將在往後的漫談簡介這三種模式如何形成。 雖然 MDA 在軟體工程中並非 "銀製子彈"(silver bullet)，那麼企業接受這