發表文章

加油站與小鎮

圖片
兩個小鎮之間有一個荒蕪之地,一些汽車會經過,一個聰明的商人於是在那裡開了一間加油站,生意還不錯。一個月過後有人在旁邊開了一間雜貨店,買點日用品喝點水,再過一些日子有人開了咖啡店,可以休息聊個天。漸漸的有人在那裡蓋房子住了下來,於是餐廳、學校、銀行進駐,慢慢的變成一個小鎮。

同樣一個故事發生在另外一個地方,生意人覺得加油站真賺錢,於是在附近蓋了第二間加油站,生意也還可以,於是第三個人再進來蓋加油站,開始削價競爭,最後三家生意都做不下去紛紛倒店了。

老掉牙的故事,每隔四五年就會聽到一次,但感受卻越來越深。

我們現在做的系統(或事情),是第二個加油站,還是邁向小鎮的咖啡廳?

治標不治本

圖片
家裡總有些小蟑螂,我們想盡了各種方法來除小蟑螂,例如買強力黏蟑紙,或是殺蟑螂的誘餌,一開始都有點功效,但過了一陣子蟑螂又跑出來了。

根本的解決之道在於,蟑螂為什麼會到我家?過去我們大概兩三天會倒一次垃圾,因為家裡的塑膠袋是大的,每天倒垃圾覺得浪費。於是我們換成小的垃圾袋,並開始每天倒垃圾,於是乎家裡的小蟑螂慢慢地就不見了。

治標真的不是辦法,必須要找出問題的根源並加以解決。
軟體的開發也是,如果你的公司不斷的產生 bug, 或是品質出現問題,別只是見 bug 除 bug,得好好想想:bug 為何會出現?

TCSE 2017

圖片
2017 年第 13 屆台灣軟體工程研討會於 7/8 圓滿落幕。本次共有25 個學術研究單位參加,包含中央大學、中央研究院、中正大學、中華電信研究所、元智大學、台中教育大學、台北大學、台北科技大學、台灣大學、交通大學、成功大學、亞洲大學、宜蘭大學、東吳大學、東海大學、虎尾科技大學、政治大學、修平科技大學、海洋大學、高雄師範大學、崑山科技大學、逢甲大學、嘉義大學、輔仁大學、靜宜大學等。第一天參與會議約 180 人,晚宴席開12桌約 120 人,第二天半天的活動也有約 100 人與會。

本次大會主題為 Software Engineering and Data Science,共有 83 篇投稿,最後收錄 75 篇論文,包含 12 篇英文論文,6 篇展示論文及 57 篇中文論文。針對這三類論文共邀請九位委員選出六篇最佳論文,其中最佳英文論文兩篇:
Chien-Hung Liu and Woie-Kae Chen, Coupling Analysis and Visualization of KDT Scripts. (台北科技大學)Hwai-Jung Hsu and Yves Lin, How Agile Works in a Software Corporation: An Empirical Study of Assessing Agile Methods from Viewpoints of Business Data Analytics. (逢甲大學, 鈦坦科技) 最佳中文論文三篇:
徐偉哲, 鄭永斌, Virtual Objects for Program Visualization in xDIVA  (中央大學)李信杰, 黃琪恩, 游傑麟, 以Text-Attribute- Context為基礎識別演化網頁中變動元素之方法與自動化網頁回歸測試之實務應用 (成功大學)陳鵬中, 馬尚彬, 呂致緯,  LODE: 鏈結開放資料之建立、查詢與服務生成平台 (海洋大學) 以及最佳展示論文一篇
李霽烝, 陳薇涵, 陳錫民, 基於共享機制的計程車評價分享平台 (逢甲大學) 感謝李允中教授的協助,特別邀請到美國 University of Texas at Dallas 的 Prof. Lawrence Chung 主講 Big Data Analytics: A Requi…

使用CRC cards的『責任驅動設計』方法

圖片
本文簡單介紹一般人比較不熟習的所謂『責任驅動設計』(Responsibility-Driven Design 簡稱 RDD),這種設計方法是根據系統的責任,來設計類別的行為與方法或功能,因此RDD可運用在軟體發展上。

1989年Rebecca Wirfs-Brock與Brain Wilkerson在OOPSLA'89發表『責任驅動設計』的軟體設計方法,後來她們與Lauren Wiener共同寫了一本叫『Designing Object-Oriented Software』(PTR Prentice Hall 1990)的書用以實作RDD,2003年Wirfs-Brock與Alan McKean合著『Object Design - Roles, Responsibilities, and Collaborations』(Addison-Wesley)一書更深入介紹RDD,讀者如沒有這兩本書而有興趣的話可從網路叫出RDD相關文章參考。

本文介紹這種軟體設計方法,乃是因為在OOSE或OOAD的書籍很少提到,據我所知上課時老師也很少介紹,這種方法的設計觀念是認為,軟體物件以及大型原件的設計是基於『責任』(responsibilities)、『角色』(roles)、以及『合作』(collaborations),這種觀念,有部份異於諸如UP之類的「傳統」軟體發展想法,但是RDD是一種非正規(informal)的設計概念,其後半部如與傳統的設計與實作連結,這個方法應該值得關注,不過我在此地必須說明,RDD並非完全脫離一般OOAD甚至OOSE的觀念,只不過它對於物件的定義有別於UML的型態 ,物件並非單純資料與演繹的結合,而認為物件是結合其『角色』與『責任』的東西,當要執行某些責任時需與其他物件合作才能完成。因此,RDD的重點在於,發展物件之間的合作與溝通模式,以及物件責任與動態,而不在於物件的內部狀態(internal state)與結構,CRC cards的內涵剛好符合這種需要。如果我們定義軟體應用系統是由一群物件間的相互作用(interactions)而成,則這種相互作用就是得自於client/server模式。
Client/Server模式 物件的作業元(operations)在RDD中視為『服務』,這種服務可以提供需要的其他物件,因此只要服務存在,我們說物件就有責任…

現今軟體發展流程趨向

降低發展軟體系統的工作量、減少發展所需的時間是現今軟體發展流程的主要趨勢,因此由郭忠義、薛念林、馬尚彬與黃為德共同發展一本書名為『現代軟體工程─物件導向軟體發展策略』,這本書有別於傳統的軟體工程書籍,引進現代的先進軟體工程技術,並具有下列特色:
全面理解基本軟體工程與物件導向的觀念。提供『案例研究』(case study)以說明物件導向軟體發展流程。介紹系統化軟體測試與方法,導引出各種敏捷軟體發展方法,如Scrum方法。根據軟體設計原理與發展樣式,協助發展者發展可保養的軟體系統,提高設計品質。以敏捷觀念介紹一些有用的建模原理與應用,例如責任驅動設計(Responsibility-Driven Design,RDD)、模型驅動架構(Model Driven Architecture,MDD)。專章介紹軟體度量預測與使用CRR卡模型,兼顧傳統與實用性。 依照上述特色,本書的目的主要用來說明物件導向軟體工程的特徵,同時提供簡易而實用的物件導向的特有功能與技術,由於軟體發展不能只抱持單一種類的方法或流程,因此本書介紹的軟體發展流程是基本流程的框架(framework),發展者可將這種框架『客製化』以適合其需求,讀者學習完本書後,就有能力應用物件導向技術從事其發展軟體的工作。
     本書主要提供大專院校研究生或大四學生研讀,同時也提供工業界人士,需要以傳統或敏捷方法發展可保養的軟體系統時參考,研讀本書,必須具有軟體工程,以及物件導向程式語言的知識,如Java或C++語言。作者深切期盼任何對本書的評論,以便將來修正。
     本部落格僅提供對於近代軟體發展策略有興趣的人士參考,而無意做任何商傳,謹特別聲明。
圖片
『簡單』- 讓混亂發展成規則 (Order from Chaos)

我在治療期間,抽空讀了一本肯恩‧西格爾(Ken Segall)著作,書名為『簡單』的書 (應該稱為『極致簡單』- Insanely Simple),西格爾主要在闡述史蒂夫‧賈伯斯(Steve Jobs)以『簡單』至上的觀念引導蘋果的成功故事,其實,賈伯斯曾經被蘋果「放逐」11年,於1997年再度回到蘋果擔任執行長,賈伯斯不在期間,蘋果每下愈況,一直到賈伯斯回來時,蘋果已經岌岌可危,幾近破產邊緣,賈伯斯以『簡單』至上的觀念重振蘋果。『簡單』至上的概念很難說得清楚,它可能是一種選擇,一種氛圍或一種指引,視你的需要而定,簡言之,『簡單』就是『打破複雜,創造絕對優勢』,你/妳如果用過蘋果的產品如iPad,可能就會有所感受,例如更新作業系統(iOS)就很簡單,總之,蘋果的基本理念是:『硬體簡單化,而背後的軟體卻豐富化』。賈伯斯如何以『簡單』至上的觀念讓蘋果起死回生,有興趣的朋友可看看西格爾的書。

發展軟體的需求,開始時都顯得比較混亂,不過『簡單』可以讓混亂發展成規則,我想,『簡單』這種觀念是否可以運用在軟體發展上,謹提供個人的看法。眾所熟悉的"KISS"原則 (Keep It Simple, Stupide) ,就是勸導人們撰寫程式與設計軟體時,要保持簡單清楚但不要太複雜,發展C語言的P.J. Plauger與B.W. Kernighan在他們的"The Elements of Programming Style"書裡,提供數十條寫程式必須遵循的『簡單』原則,例如其中有一則原則是說"Keep it simple to make it faster",所以程式如寫得太複雜,則可能會降低效率。此外,『簡單』也可以說是敏捷方法的原則之一,2001年Agile Alliance所發表的敏捷宣言(manifesto),是『簡單』的價值闡述,『簡單』的優點是你不必花費太多的時間去實作困難的解決方案(除非簡單的方案無法解決你的問題),總之,簡單的解決方案容易保養也容易改進。

談到『簡單』,我想到去年12/8我在本部落格po了一篇題為『CRC cards - 非正規物件導向發展技術』的文章(惜因少有反應,所以最近我把它列入草稿),CRC cards雖然屬非正規方法…

CRC cards - 非正規物件導向發展技術

圖片
最近看到Kent Beck與Martin Fowler講的一句『諺語』,說:"Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文,提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』,溝通在軟體發展的過程中十分重要,尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto),此地不宜對宣言多做闡述),問題是你要使用何種工具或方法來溝通?我想除use cases外,CRC cards可能是最佳工具之一,它是隨時隨地可得的低技術工具,易學易用。

軟體開發與維護時,工作夥伴的合作十分重要,換言之,團隊合作是發展工作成敗的關鍵,夥伴合作必須有好的工具或技術協助,CRC cards可能是適當的工具之一,據我所知,在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997),而這種技術雖然簡單,但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別,因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術,而且也希望各界人士能予指正。

CRC cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html),其出現時期與WWW相同,至今約有20幾年的歷史,這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作,後來的演變卻超乎在教室內的需要,而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach),雖然屬非正規方法,但CRC cards可做為正規方法的輸入或前端作業,如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOSE、Shla…

再漫談『課程改進』

去年TCSE2011 Panel discussion之後,我在2011/07/13po了一`篇叫『課程改進』短文,文中主要討論,教學生是先教程式設計或模式觀念,該文引起一些討論,2011/12/05我又發表一篇:『CRC cards - 非正規物件導向發展技術』(該文因無人點閱故暫還原為草稿),我因此想到「冷飯熱炒」po這篇短文就教對該類議題的有心人士。
     事實上,討論程式與模式孰先孰後不會有結論,也不應有結論,因何者為先何者為後,甚至兩者平行教學,端視教師的觀念與想法,不過我認為,這個議題可能影響往後的軟體工程與物件軟體工程的教學以及學生學習的深度與速度,我教過幾年的物件軟工課程,發現有些學生對於模式的概念相當薄弱,因此要了解諸如UML的功能與運用時有些困難,甚至於利用UML來發展軟體也有些「障礙」,因此我才想到何不早先讓學員了解模式與程式之間的關聯!
     不過,如果你/妳不反對教授大一或大二的程式設計時,可同時授予學生物件導向的觀念;CRC cards可能是教導學生盡早具備物件導向觀念,簡單但有效的利器,事實上,Kent Beck與Ward Cunningham介紹CRC cards時的原意就是要教導程式員認知物件導向的觀念,只不過後來卻「脫離」教室而成為快速而且有效的物件先期設計方法,而成為非正規物件導向軟體發展技術(參照2011/12/05CRC crads一文)。
     這篇短文只是用來補充前置『課程改進』一文,總希望學生能夠盡速進入物件導向的領域,因為物件導向軟體發展方法可能是目前de factor軟體發展法,如果老師們能夠加以指正這種論述,本人表示樂觀與感謝。

「註」CRC cards是簡潔(compact),低技術(low-tech),便宜,容易學習的工具,而且不一定要使用電腦,甚至可做為正規方法如UP等的輸入,這一點再另文討論。

TCSE 2011 Panel discussion

前言
今年在輔大舉行的TCSE Panel discussion,三位與談者與眾多與會者對『軟體核心能力』這個議題,在一個小時的時間內做了許多探討。以下的抄本,由輔仁大學范姜永益教授轉錄自當天的錄音,特此致謝;抄本業經與談人修訂、補充。建議讀者參考當天的 投影片 一起閱讀,更歡迎大家在『輕鬆談軟工』一起加入討論。附帶說明,此抄本已略去錄音效果不佳的部份,敬請包涵。
Transcript begins
北科大 鄭教授開場 軟體領域最近的熱度,大家都知道。最近參加的一個會議裡,電腦公會的代表提到,幾家ICT大廠有數千個android 軟體開發的職缺;同一個會議中亦談到雲端軟體開發,在座好幾個大廠每家亦以數以百計的數量開出軟體開發人員的需求。各位,如果您或是您的學生會寫Android的程式 我想出路應該是沒有什麼問題。但是,身為教育界的一分子,我們要回頭問問我們自己:剛自學校畢業的軟體工程師寫的軟體到底如何?我們學生要具備怎麼樣的核心能力才能做出好的軟體? 針對這個議題,軟工學會理事長李允中教授特別為今天的panel discussion訂了一個討論題目:『軟體核心能力』(software core competences)。針對這個議題,六月份時李教授在中央大學召開一個會議。李教授提出的核心能力分為基礎與進階:基礎的部份包含了基礎技術能力與團隊合作,像是如何描述一個問題、如何做設計、如何規劃Architecture 等等;進階的能力部分則涵蓋如何開發、審查、驗證 以及可用性、大型軟體的議題等的議題等。當然,我們今天的討論並不需要侷限在這幾個議題上,而可以有更深、更廣的的討論。
今天很高興我們請到三位軟工界非常熟悉的學者與談。第一位是中央大學的黃為德教授,第二位是銘傳大學的劉龍龍教授,第三位是大同大學的郭譽申教授。三位panelists 各有七分鐘的時間闡述見解共計二十一分鐘。接下來我們會留大約一半的時間進行討論,在座的各位可以在panelists 談完他們的看法之後,大家來討論。
中央大學 黃教授 大家袋子裡面是不是有一台手機,如果手機裡面沒有軟體,你的手機可能無用武之地,你到銀行要領錢,銀行告訴你說電腦壞了,可能是軟體系統故障或惡化(deterioration),叫你兩小時後再來,你可能會抓狂,更嚴重的,假如是飛機,如果沒有軟體,它飛得上去下得來嗎? 這就是軟體之所以重要的小例子…

課程改進

今年在輔大招開的TSCE11,其中在Panel Discusion中(主題:軟體核心能力),我提議軟工教育訓練由OO modeling概念開始,而程式則依據models來撰寫,這種提議可能須修改教學程序,不過我認為,「軟體核心能力」的目的乃是要建立優良的軟體系統,而models比複雜的程式容易描述系統,也比較容易保養系統,因為其抽象層次較高,也符合程式語言以及軟體發展方法的演變之故。我提出這種意見,希望對軟體工程教育有興趣的人士能夠討論,提供意見。

蓋房子和寫軟體

往花蓮的自強號上,旁邊坐著一位五十幾歲的長者,一直反覆的看著一本旅遊書籍,看起來是歐洲旅遊的書。我好奇便問他:『剛從歐洲旅遊回來嗎?』,他嚇了一跳,我連忙向他道歉,他親切說;『沒關係』,接著很興奮的告訴我他的攝影心得,就這麼聊了起來。

他一邊翻閱書上的照片,許多的地方他都去過,他說他喜歡研究別人取景的角度為何和他不同,借此學習更好的攝影技巧。看得出他對生命充滿熱情,喜歡思考、創作與分享。聊著聊著才知道他原來是台中知名建商的董事長。

除了生活上的樂趣外,他也跟我分享他的經營理念。他對員工的要求是『不能凡事都照著規格書、設計圖走,那是官僚』。為什麼?他們的員工每天都在接觸房子的買賣,久了就麻痺了,以為房子的買賣很輕鬆,但是對許多買房子的人可能是畢生的積蓄,一生可能只買一次房子。

他說他接觸過很多醫生、教授或高科技產業的客戶,他們在自己的領域上十分的專業,"但對房子的事情真的就是不懂",所以不能拿規格書來壓他們,應該是要幫助他們。

姑且不論這位董事長是否真的做到這樣的原則(畢竟我跟他不熟),這些道理在軟體工程產業上也是相通的。寫軟體的如果在客戶搞不清楚規格的情況下一直以規格來壓客戶,那就是以專業的傲慢來欺騙客戶的無知。

當然,蓋房子跟寫軟體畢竟不同,各位覺的呢?

有理說不清

軟體系統常常背上許多莫需有罪名,有時候是需求的提供者沒把需求說清楚(或根本說了錯誤的需求),有時候是使用者不會用 (沒參與教育訓練或沒看說明書)造成操作不當。當後者的情況發生時,使用者通常會怪罪『介面設計不好』。

的確多數的軟體工程師對於介面的設計不重視也不在行,但有時候使用者也太無理取鬧,把所有的錯誤都賴在介面設計上。

張大叔最近開始使用線上照片沖洗的功能,但照片卻遲遲沒有寄到,他上網查了一下,發現住址寫錯了。他打電話到客服中心發飆。
『你們的系統有問題不穩定,把我家的地址記錯了。明明是100號,怎麼會記成200號?』

客服查了一下,回應說:『張先生,有可能是您打錯了,系統記錄的的確是200號』

『怎麼可能?我打過無數次了,怎麼可能會把自己的住址打錯?』

客服有耐心的說:『有可能1和2相鄰,您打的時候打太快了,所以不小心打錯了』

『那你們系統要做檢查嘛,哪有那們笨的系統?要做防呆嘛』

客服楞了一下,還好他邏輯還清楚:『張先生,我們系統不知道你住100號,怎麼知道您打錯了?沒有辦法喔...』

這下換張大叔楞了一下,但他還是很生氣。『這照片是我送給老婆的生日禮物,照片我選了好久,沒有按時寄過來這個禮物就沒有意義了』,頓了一下又說:『你們要怎麼賠償我的損失?』

『先生,這是您打字錯誤所造成的,我們沒有辦法賠償。我們會通知郵局將包裹重寄,但您要再負擔一次運輸費用』客服說。

張大叔一聽還要多負擔就生氣:『都是你們系統的問題為什麼要我負擔?你們介面設計的太糟,介面要儘量防呆嘛... 比如說不要讓我們用打的,讓我們用選的...』

客服有點聽不下去了:『先生,忠孝東路門排很多,我們不可能把所有門排都列出來讓你選』

『怎麼不可以,你可以每一個位數都用一個下拉式選單,三個位數只需要三個下拉式選單,你們設計要用點腦筋嘛』

...

問題解決

古時候,中國有一則寓言是說:有四個人走到一面高牆前面,高牆的通門用鐵鍊與鎖鎖住,其中三人試圖用盡各種方法要打開門鎖,用石頭打、火燒、以及用木棒挖鎖等方法,但最後仍然無功,這時候,忽然看到那第四人從森林走出,手握一把長竹竿,走到牆面前以撐竿跳的方式跳過那一面牆。

第四人並沒解決門鎖的問題,而是避開重新定義問題,創造新的而可解決的問題,因此基本上問題不在門鎖,而目的是人要到達牆的另一面。

這則故事顯示,"what"與"how"的問題,前面三個人只想『我如何打開那道門』(how),至於另外一個人則避開那三個人的困境,只是想『我要做甚麼』(what),答案是『我要過那面牆』,一旦他將問題放在"what"上面,他就可以設計如何執行而獲得成功,他解決問題不只是解決,而是問題要合理解決。

發展軟體就應如這則寓言中第四人的作法,要如何達到有許多方法,其中CRC cards (Class-Responsibility-Collaborator cards)技術,可能是最佳方法之一,但似乎未在國內引起廣泛注意,我們另文討論。

從種樹小故事看流程改善

今天上課前突然想到一個故事,稍作改變後用來跟學生講解流程改善。

某公司聘用一個員工上種樹,他需要鋤頭挖洞,將樹植下,最後再用鏟子把地鏟平。以他的速度一天只能種十顆樹,比老闆預期的進度差太多,於是老闆又聘了兩個人來幫忙,速度提昇了兩倍。

[from work harder to work smarter]
但是這樣的速度還是不夠快,而成本又太高已經沒有經費在聘用員工,只好想辦法進行流程改善。他仔細觀察三個員工的工作方式,發現花在工具的抽換花了太多的時間。於是他重新更換了三個人的工作:A 只做挖洞的動作,B 隨後將樹植下, C 隨後在將地鏟平。這樣的工作模式可以省去更換工具的時間,更棒的是,每個人更能夠把自己的工作做的專精,效率又提高了兩成。

[但,小心成為官僚流程]
這樣的流程跑了很久,員工來來去去換了許多次,但都保持一定的高效率。一天,老闆去看工地,發現A 挖玩洞後,C 緊接著把洞補起來填平,老闆生氣的說:『你們在做什麼?B君呢?』
『喔,他今天請假了』A 說。

最後這個笑點看似誇張,但在企業流程卻常見。許多人習慣了只知道follow 流程去做,卻不之所以然,所以很容易鬧出笑話。另一方面企業也常常不重視流程的教育訓練,所以常常空有好流程卻無法發揮最大的效用。

軟體工程與大型整合專案—以WiMAX整合型計畫為例 (3/3)

圖片
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計畫中可以說是完全失敗。在開發環境未能統一的情況下,子計畫的開發人員往往以為只要在自己的開發環境上能建置…

無題

趁歲末,我花了一點時間,回憶一些各方對今年發表的諺語與部落格文章所提出的意見,雖然這些意見不能涵蓋全面,但多少反應一些現象,這種現象顯示國內軟工教育問題,就是學校的軟工教育訓練不能完全『學以致用』,也讓我這個開授軟工課程多年的教師匠有點『做白工』的感覺,嚴重一點說,有點誤人子弟。

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

軟體工程與大型整合專案—以WiMAX整合型計畫為例 (2/3)

圖片
版本控管

在整合國科會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整合型計畫為例 (1/3)

圖片
以往學生在學軟體工程時,總覺得這門課就是在「寫文件」,對於為什麼要寫文件,以及文件的用途,不甚了解,甚至覺得寫文件是很枯燥乏味的一件事。的確,為了交作業而寫文件,我想沒有人會認為寫文件是有用的,特別是對於一個虛擬的軟體專案而言,即使必須開發對應的軟體,充其量也是一個小品,而且一個學期的時間又很有限,所以不是文件品質不好就是軟體沒寫好,更別提要維護了, 而學生無法對軟體跟專案產生情感,自然無法體會文件的意義。

過去三年,筆者因為主持國科會整合型計畫「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來提升整體的效率。
學校的『小短少少』的環境有時候很難體會軟體工程的重要性。透過專題的製作與建教合作或許有些幫助。