加油站與小鎮

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

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

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

我們現在做的系統（或事情），是第二個加油站，還是邁向小鎮的咖啡廳？
逢甲大學資訊工系教授，主要研究興趣在軟體工程、數位學習。

留言

張貼留言

這個網誌中的熱門文章

CMMI是什麼?

作者：
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)式兩種表示法。採用連續表示法者，可依據企業軟體開發的實際需求，自由選擇為數恰當且最相關的PA進行導入工作。採用階段表示法者，則須依據SEI規範，在一期間內同時導入若干相關PA。在連續表示法中，…
閱讀完整內容

給我測試案例，其他免談(一)

作者：
以寫程式為生(領薪水)的朋友一般都不會擔心程式太大寫不完，但都討厭要配合所謂客戶要求的「需求變更」而常常要把已經寫好的程式不斷改來改去，作很多虛功。依據我的觀察，對這些程式設計高手而言，原來已經寫好的程式要再修改，大概超過 3 次就是耐心的極限了；因為此時的程式已經幾乎是變得體無完膚，不但客戶不會滿意，連寫程式的人自己看了也會想吐血。

對程式設計高手而言，寫程式從來不會有什麼問題，而要寫出「什麼程式才是真正你要的東西」才是大問題。偏偏，「需求變更」就是一個他人常用的藉口(因為不一定是客戶要求的，只要之前有人在需求分析階段有錯誤或偷懶沒有詳細分析，最後都可歸咎於需求變更)，反正是你先去寫，然後他再去看，刺激他的神經之後，再提出他的修改看法叫你改，如此永不疲憊。另一種狀況是，需求分析說明文件的內容只是應付軟體工程開發階段的記錄，非常抽象，譬如是「能令使用者感到愉快的一個小型輸入畫面」。

如果我是負責程式設計的，在看完那種「不可能的任務」(Mission Impossible)需求分析說明文件之後，我因為要繼續領薪水、又要能融入傳統的軟體開發工作團隊之中，我就可能會轉而要求負責軟體測試的團隊成員趕快先把測試案例設計出來，不要等到我把程式寫好了再用這些案例去測我的程式，請他們先把完整的測試案例給我。因為既然以後是要用這些測試案例來測我的程式，那我就依據這些案例的內容來設計我的程式，只要在測試執行時這些案例都能順利通過，我的程式就找不到與這些測試案例目的相關的錯誤了。

給我測試案例，其他免談。
閱讀完整內容

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…
閱讀完整內容