輕鬆談軟工

趁歲末，我花了一點時間，回憶一些各方對今年發表的諺語與部落格文章所提出的意見，雖然這些意見不能涵蓋全面，但多少反應一些現象，這種現象顯示國內軟工教育問題，就是學校的軟工教育訓練不能完全『 學以致用 』，也讓我這個開授軟工課程多年的教師匠有點『做白工』的感覺，嚴重一點說，有點誤人子弟。 話說，從今年2月20日薛教授post上去的『好人難為』一篇文章，以及最近Q39諺語：『Schedule是用來Delay的』說起，我覺得我們的軟體工程師似乎受很大的委曲，大部分的委曲都是說很難與老闆溝通，有人說溝通無效只好忍氣吞聲，或者默認，甚至乾脆打包走人(「好人難為」意見箱)，『‧‧‧要不然抱怨變化永遠趕不上客戶的一通電話』(Q39諺語)，甚至說如果客戶來個需求變更，那(專案)就要delay到天荒地老等等，是不是那麼嚴重，我想還不至於吧，不過我相信這些抱屈都是事實，也都是經驗之談，不過從軟工的角度來看，似乎並不希奇，雖然有幾位教授以及本人對這種現象多少有些解釋也提供一點意見，我相信這種現象並非完全無解，重點在於『學以致用』，要致用當然要『百鍊成鋼』，只可惜據我所知，許多學校的軟工訓練並未提供這種機會(包括我自己)，例如世界上許多軟工界的『先賢』或『現賢』，提供不少設計軟體的方法(methodologies)、原則(principles)、或樣式(patterns)，諸如Agile Methods，Protected Variations及其引伸的OCP、DIP、或Information Hinding等等原則，我不知我們的軟體工程師發展軟體時是否應用到這些『優美』的方法、原則、與樣式？但這些設計原則的確可以解決上述不少問題，我不相信當我們的工程師要應用這些方法‧‧‧時老闆會加以干涉，如果我們的軟體工程界發生這種干涉現象，『軟體工程學會』應該出面解釋甚至說服，學會有責任導正軟體發展的方向，而不是只開開會討論了事，這是我寫這篇不怎麼討喜的短文主要動機。

版本控管 在整合國科會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』也可以套用在聯絡人的關係的建立。 只是一個突發奇想，可能有點人來瘋。但有興趣的朋友、研究生或許可以試試研究看看。

學生們還是問，為什麼需要軟體工程？和程式設計有什麼不同？為什麼需要作專案管理、監控、控管等等？寫得出程式不是比較實在嗎？ 這是因為學生寫的程式太小、參與開發的人太少、專案關係人太少、而維護的時間太短，以致於他們無法想像軟體工程的必要性。 真的軟體專案是『大長多多』的。 到了業界，一個專案要破萬行很容易的，程式一旦 大 ，相互關係就會變複雜，動一行指令可能會牽涉到好多地方。所以需要學軟體工程，學如何切模組、作架構設計。學設計概念，知道如何才容易維護、好擴充功能。程式一旦變大，它的成本也會指數性的上升，你需要學習成本估算的方法。 專案的時間通常很 長 ，不是一個星期能完成的家庭作業。所以你需要專案文件（幫助你記憶），專案管理（來掌握時間與分配人力）。維護當然把整個時程拉的更長，所以設計的時候要考慮彈性、成本要把維護算進去。在組織人力調配上，你需要考慮開發與維護是否是同一組人。在這麼長的時間裡，各種不同的版本會產生，你需要版本控管的機制，也需要需求管理來控管變更。 學生的作業多是老師給好的題目，於是很難體會為什麼需要系統分析。業界的專案牽涉的人 多 ，光是『安排』訪談可能就需要一個月。每個人的意見都不一樣，你必須學習一些系統分析的方法來收集、挖掘、歸納、整理、協調、妥協這些需求，再讓這些需求一個個的被所有人確認。除了清楚的腦袋、好的溝通能力、專業技術的判斷，你也需要一些系統分析的方法論。 一個真正系統的完成，需要的專業知識太多，決不是一個人能夠完成的，我們需要很 多 人一起來開發。如何組織這些人？如何分工？是依照<專案管理師、系統分析師、系統設計師、系統工程師、系統測試人員>來切割？還是依據領域來切割？這麼多人合作，版本管理更重要了。組織也需要定一套一致的 coding standard 及 SOP來提升整體的效率。 學校的『小短少少』的環境有時候很難體會軟體工程的重要性。透過專題的製作與建教合作或許有些幫助。

3/21本人寫了一篇文章介紹OCP設計原則 (意即：要延伸一個類別時不能要求修改該類別) ，多少引起一些反應，現在我們利用這篇短文來輕鬆談談，另外一項重要的軟體設計原則：「依存反向原則」(Dependency Inversion Principle - DIP)。 首先我們談談何謂軟體「設計原則」，在軟體發展的領域中，所謂設計原則是：「在發展軟體系統的動作中，一種可接受的規則或方法，也就是說可使用的工作原則」( http://dictionary.reference.com/ )，好的設計原則必須是能夠協助發展者產生設計主意(idea)，而且可以讓設計者能夠透過設計意涵來思考其實際的設計(Rebecca J. Wirfs-Brock 2009)，依據這樣的定義，我們所要談的設計原則是可實地應用的，不過原則並非嚴格的設計規則，有如設計樣式(design patterns)一樣，僅在某種環境中使用，過份使用設計原則，可能會增加程式的負擔與工作量，因此，如果你確定類別的功能將來不致改變，則不一定要去使用設計原則，不過大部分的設計原則，都是將實作(implementation)引藏起來，以保持設計的彈性，如OCP或本文即將介紹的DIP。 DIP的定義可見諸於各類設計樣式的書本或網頁，簡言之就是：『抽象不能依存於細節，而細節必須依存於抽象』(Abstraction shouldn't depend on details. Details should depend on abstraction - Rebecca J. Wirfs-Brock 2009)，這是何意？我們舉一個簡單的例子：一家公司顧有許多員工，也就是說公司就必須直接依存於這些員工，以軟體結構語言來說，公司是屬於「高階模組」(high-level module)，就是上述DIP定義所謂的「抽象」，而員工則屬於「低階模組」(low-level modeule)，也就是定義所說的「細節」，如果公司因業務需要必須增聘具有高強能力或專長的員工(也許稱之為super employee)，而沒想到使用DIP，則必須修改複雜的公司模組內容，這種修改將影響公司模組的結構，這樣就違反DIP，如果希望增加任何員工而不想影響到公司模組，DIP告訴我們，可以在公司模組與員工模組之間介入一種「抽象層」(abstract layer

今天在研討會中聽到一個不錯的比喻。軟體工程度量在國內一直很難推動，這或許與國內對於工程量化的觀念比較不足有關係。這一點可以日常生活中的用語窺得一二， 西方人說『wait a minute』，以『分』為單位 台灣人稱火車慢了為『慢點』，以『小時』為單位 印度人則說『等天』，以『天』為單位 這讓我想起PSP (personal software process)方法要求以 分 為單位來記錄工時，但對於我們的工程師的確是很大的壓力。以我們逢甲資訊處為例，工時的紀錄幾乎都是以小時為單位。這之間的關聯是否為巧合？有趣。

最近學生報告了一篇有趣的論文。研究團隊開發了一個系統 CodeConjurer（程式碼魔術師），說的是可以憑空產生的程式碼。你會想，這怎麼可能？ 它的原理很簡單，首先各位都知道 google 搜尋引擎可以去找全世界網頁的資料，其實還有許多是針對程式碼的搜尋引擎。例如 Merobase。研究團隊利用 Merobase 到一些 opensouce 的地方（例如 SourceForge）找程式碼，程式設計者只要寫出你想要用的物件的功能（也就是定義他的介面），CodeConjurer 就幫你找出一些可能的軟體元件，你可以進去看裡面的程式碼檢驗是否這就是你要的元件，如果是的話，可以馬上下載並整合到你的專案中。這無疑的可以幫你節省一些時間。 當然，光是透過介面的定義就認定該原始碼就是你要的可能會有些風險。為了進行 semantic check, CodeConjurer 也與 JUnit 作整合，開發者在使用這些元件前應該先透過 JUnit 確認元件的 semantics。 如果這個東西真的可行的話，第一個要擔心可能是老師們，因為抄襲的問題可能會越來越嚴重，學生可能越來越不寫程式。但從軟體工程的角度來看，這不失為是一種 code reuse 的發展趨勢。在防堵學生抄襲的同時，老師們也需要教導如何在有限的時間內套用正確、合適的元件來增加軟體開發的效率。

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

看到「好人難為」一文，主角是一位專班學生，看來他似乎很委曲，因此我在意見箱內提議，他可以好好研究一下軟體設計的第一原則：Open-Closed Principle (OCP)，或許可以解決他的困擾，這件事涉及到軟體工程的教育與訓練的問題，也就是說，學以致用的問題，因此有必要寫一篇短文以OCP為例，來談談軟體設計原則的運用，這些原則並非軟體發展的食譜(cookbook)，而是發展者必須放在心裡的「指引」(guideline)，這種指引必須落實成為diciplines，其他如設計樣式(design patterns)也具有指引特性，因此才能廣泛運用，也就是說，可以重覆使用(reuse)，學習時最好蒐集一些範例，可能有助於這些設計原則或樣式的運用，有如念法律的人必須研究一些判例一樣，學習軟體發展方法時也不例外。 OCP是物件導向方法的核心，1988年由Bertrand Meyer在他的著作" Object-Oriented Software Construction "一書提出，它是說：「軟體實體必須能夠延伸但不能修改」(Software entities should be open for extension but closed for modification)，換言之，必要時可以延伸軟體實體的功能但不必修改它，該軟體實體可以是類別、模組、功能、程式、或組件，完全看你用在何處。Meyer的原意是說，類別實作(或程式)除了須要除錯外，如要改變功能或增加新功能時不得改變父類別(superclass)，而由子類別(subclass)來達成，子類別可以利用繼承(inheritance)機制重用父類別的屬性或作業元，但可改變或增減其功能，因此繼承不旦可以重用父類別的實作，同時可以延伸原功能，該子類別的介面可以異於父類別的介面，這是一般具有物件導向的人所熟悉的繼承機制。 到1990年代OCP被重新定義為，新介面可以繼承自「抽象類別」，但非繼承實作部分，原介面不得修改，也就是說，你設計的組件或模組不能改變，當需求改變時，你可以增加新程式以延伸該模組的功能，但不能改變你也許認為十分完美而能作業的原程式，請看下圖(R.C. Martin)， 左邊圖形表示，如果Client想使用另一個Server時，Client必須改變，因為兩者皆是concrete，這樣就不

對開發軟體系統的人而言，最害怕的並不是寫程式，而是千奇百怪的需求。一個朋友告訴我他曾經做過某個學校的校務系統，在加退選的前一天： 『第十五個選課的人不可以退選』學校突然向他們要求這個需求。 經過了解才知道一門課至少必須有十五位選課才可以開課，否則就會倒班，所以校方就提出這個需求。但是用這種方式來預防倒班也有點奇怪。 有趣的事發生了。甲生是第十五個選到課的人（當然他自己不知道他是第十五位），而第十六位選到課的同學正好是他朋友，甲生眼睜睜的看到他同學可以退選，自己卻不能退選。接著又有其他人加選後退選也可以，但他剛好又是第十五位，他還是不能退選，你說氣不氣人？ 於是這個問題學生提出來，最後只好把把這個限制拿掉。有時候一個系統的功能看起來沒有幾項，卻是在修修改改之間浪費了很多的時間，如果能夠事先想清楚，是不是可以省很多的時間？如果一個有經驗的系統分析師能夠在顧客提出奇怪的需求時就能跟他們分析這些需求後續可能造成的影響，那就有很大的幫助。

我自己以前很喜歡寫程式，現在不年輕了就較懶惰，所以大家猜的出來這故事發生在很久很久以前... 一顆1MB的RAM要一千塊美金，而且要排隊一個月才買得到的時代 。 我當初為了一家forwarder/broker（海陸運）公司寫一些應用程式。幫他們架網路，再完成了會計系統、出入口系統等業務的東西，終於要幫Sales的人們開發他們的系統。花了一些時間，把基本需求完成，然後很雞婆的幫他們作了一個小工具。結果，那個小工具成為Sales的人們最喜歡用的功能。 為什麼說雞婆呢？因為這沒有在他們本來的需求裡，而是在某幾次吃飯或咖啡場合聊他們做事的方法，我自己去作一些prototype開發出來的。其實那個功能需要跨幾個資料庫撈一些資料再整合，只是我們當初所使用的資料庫系統會鎖住資料庫，沒辦法邊看邊編輯資料。其實是為了安全的考量，資料庫鎖住是很合理的事。可是為了這限制，我一直沒有辦法完成我想要的功能。最後，在某一次的嘗試中，動態跑到作業系統裡把lock挪掉，做完工作，再把lock搬回，竟然就完成了所期待的工作。雖然有些危險，但是我非常有把握在這些功能的使用範圍內，應該是不會發生任何問題。 事實上，這工具他們之後用了很久，而且沒有發生任何意外。直到有一天我接到越洋電話... 時間已過幾年，我也搬來台灣。原來他們要upgrade系統，再重建構系統，所以希望我說明當初到底用了什麼撇步完成那功能。 坦白說，我連什麼功能都忘了，哪裡記得什麼妙法？ 不知道各位有類似的經驗嗎？很多時候拼命coding，不是trial-and-error，就是靠著一些靈感完成工作。然後，沒記下來，過幾天就忘光光了。 明明知道要加註解，可是怎麼可以停下這麼順的『手感』，就繼續code下去了。更不用講到文件了...

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

這是一個朋友的朋友的故事。 當時他還是一個剛當上PM的年輕工程師，第一個案子就遇到大系統，是一個會計相關的系統。辛苦了兩年系統終於到了收成的時機，但是由於許多的需求一開始沒有說的清楚，客戶不斷的質疑他們功能並不完整，介面也不好用，案子又拖了兩個月都結不案。有一天客戶約他吃飯討論系統功能，他準時赴約。 沒想到客戶劈頭第一句話就說：『怎麼不早點來』？他自認以他的手錶來說是準時的，於是那一場氣氛不太好的飯局並沒有達到共識，雙方不歡而散。 過了幾天客戶又約了吃飯，這次他早了10分鐘。想不到幾個客戶已經坐在那裡喝茶等他了，客戶看了看他，還是說：『怎麼不早點來？』。他心裡悶的很，想到張良的故事。心裡想，我下次提早半個小時來，看你怎麼說。 第三次他提前半個小時來，果然比客戶早些了。在愉快的用餐後準備離開前，客戶起身握著他的手說：『下次再提早來』。他有點震驚，卻也不敢說什麼。回去問他的老前輩，是不是顧客在發什麼神經？ 老前輩嘆口氣說：『他的意思是要你提前（錢）來』。年輕的小伙子才恍然大悟。 這自然是不可取的事，卻也說明了軟體驗收的困難。許多細微的地方如果沒有寫清楚、說明白，就等的驗收的時候被刁難吧！所以在定義需求規格的時候，腦袋裡一定要想到『 我怎麼驗收這一項需求 ？ 』。 另一方面，一定要有把需求擴大來想的本事，顧客跟你說：『這裡要可以輸入商品名稱』， 不要單純的以為只要用一個 TextArea 放個欄位給使用者輸入就好了，顧客腦袋裡想的是一個『商品管理系統』 ，到時候商品名稱要用點的、用拉的、絕對不會是鍵盤輸入的（輸入有很多種，鍵盤輸入只是其中一種）。所以要跟他確認，千萬不要一廂情願的往容易的方面想。如果他真的要一個『商品管理系統』，那麼就得加錢、加時間、或至少釐清了我們做不到。

已經是好久以前的事了… 我們到一個部門跟他們談office automation，問他們需要什麼。他們竟然很訝異的說『電腦不是什麼都會嗎？』（雖然過了好多年，這好像仍然是一些人會問的問題） 拿出我們軟工的本領，就開始『需求工程』了，可是問題不太像我以前所碰到的CASE容易，更不像課本裡所說的那麼單純。我們問他們如何作業，沒有人講得清楚，甚至有許多不同版本。結果變成我們替他們釐清問題，替他們定義一些作業方式，就像我們替他們定一堆SOP一樣，結果還被批評一番。經果許多討論與翻修，終於完成。這中間有多少時候我常想，為什麼不是他們，而是我在替他們定需求呢？難道我以前碰過得人，就那麼的合作嗎？ 好不容易prototype出來了，他們開始使用好像不太熟悉，可是試用一段時間後，他們終於瞭解原來電腦不是什麼都會，可是同時看到他們可以藉著軟體系統作更多的事。 以後幾年的合作，他們從被動不合作的『使用者』，變成主動且很聰明的『需求提供者』。他們的胃口也變大，可以想出一大堆非常有創意的應用。真的很難想像當初那不太甘願合作的樣子。 不知大家有沒有，相似的經驗？假如以為需求分析，只是問問東西，或是定一些定義出來，那就好像不是這麼一回事了。

自由軟體盛行多年，近年來國科會也開始再推自由軟體，初期僅允許技職院校申請計畫，最近也允許一般大學的申請。大部分教授還是喜歡申請一般型的研究計畫，不喜歡申請自由軟體計畫，我分析原因有幾個： 國科會的自由軟體計畫必須遵守輕量級 CMMI 的規定，產生許多文件（例如計畫書、規格書、設計文件、測試報告），工作量相對比較高。 不能只是理論，必須真的實作出來。 期末必須做實體展示，而且接受委員的審查。如果是整合型計畫的話，還需要接受期中審查。 相對於一般型計畫，只要有論文產出，自由軟體的計畫的確要花費很多的功夫。最近有聽到一些聲音：『 整天都在寫文件，哪裡有時間作系統 ？』。我個人是贊成寫文件的，也期望國科會要堅持下去，不要因此就妥協了，原因如下： 可以讓參與計畫的學生練習寫文件。出社會文件是絕對少不了的。一些研究型的計畫所產出的系統因為不需要長期維護，所以文件相對不重要，造成學生的誤解。 研究成果需要寫成論文發表，其原因就是希望後人可以延續其研究成果繼續發揮。自由軟體寫成文件後，後人才有辦法繼續的擴充。輕系統文件而重研究論文是不公平的。 絕大部分知名的 open source 軟體，都有完整、及時更新的文件說明。 文件是軟體的一部份。 今年 1/14 日的理監事會議中， 郭譽申教授  也提到一個台灣自由軟體計畫的問題。國外的自由軟體的發展都是心甘情願的、無償的開發，等到做出了一些規模，再徵求 donate。國內反倒是透過國家的力量來推廣，大家申請了計畫來做系統，做完了卻任其荒廢在 open foundry ，實在可惜。 順道，想請問各位，有哪些 open source 是適合軟體工程使用的？

去年12月初去參加在北京舉行的 Asia Pacific Software Engineering Conference， Ivar Jacobson  (UML的開發者之一)的Keynote Speech令我印象深刻，推薦大家到  APSEC 2008  的網站下載他的演講投影片。 摘錄幾句他對Process的觀點： Every process tries to be complete. – As a consequence every successful process will grow until it dies under its own weight. • Every process usually becomes just shelf-ware. – Law of Nature: People don’t read process descriptions. • The process is out of sync with what the team does… – …and the project – process gap get wider and wider • The project has to adopt an entire process. – No-one uses an entire process or limits themselves to practices from one process. It’s no wonder no-one likes process. Jacobson認為practice比process重要： Practices are First Class Citizens. Process is just a package of practices. 什麼是practice? A practice provides a way to systematically address a particular aspect of a process. Practices focus on the essentials. It is the key things to do and the key things to produce. 個人的感想是： 沒有一個process是特別好的，包括CMMI。 真正