輕鬆談軟工

本來應該寫在 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軟體架構為基礎的電子化政府計畫、到軟體市場東進計畫以向外承接軟體外包市場，目的在建構軟體產業的基礎環境以及擴展市場，進而提振整個產業。 個人認為台灣的軟體產業要走出自己的一條路，除了政府與民間原有的努力之外，應該要有更寬廣的軟體工程新思維以及更聚焦的作法，可歸納為由下到上四個層面：第一是軟體知識，第二是軟體教育，第三是軟體流程，第四則是軟體市場。 在軟體知識部分，必須將軟體知識與領域知識合一。整體產業的未來發展應該要能結合專業領域知識與軟體知識，這又可分為三個層面來談，其一是國內軟體公司雖然具備相當的專業領域知識，但相對而言，軟體知識以及軟體系統整合的能力則較缺乏，因此必須著力提升其軟體方面的知識與能力，才能與原有的領域知識相加相乘，建立更優越的競爭能力；其次是過去數十年來，台灣擁有相當多紮實優異的傳統產業，雖然隨著科技與時代進步而逐漸式微或外移，但是如果台灣的軟體公司能將專業領域擴展至傳統產業，藉由兩者的結合重新賦予傳統產業全新之生命力，而軟體產品服務亦可隨著傳統產業的外移而向外擴展，發光發熱；最後台灣軟體產業則應與目前在世界佔有舉足輕重地位的台灣硬體系統產業結合，藉此提高嵌入式軟體的開發與測試市場，走出原有的...