輕鬆談軟工

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

也許歐美的軟體都已經被別人測試得差不多了(雖然我們知道事實上軟體是測不完的，但總是會有人擔心說重要的軟體測試早已就被作掉)，所以我們不妨用中文資料處理應用中最基本的「排序」這個領域來看一下軟體測試的市場空間有多大(究竟我們的中文應用水準要比歐美人仕要強得多吧)。 假設有一個軟體模組 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)，那麼企業接受這