加油站與小鎮

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

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

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

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

留言

張貼留言

這個網誌中的熱門文章

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) 式兩種表示法。採用連續表示法...
閱讀完整內容

漫談「模式驅動架構」(三)

作者：
敏捷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的觀念，其價值應較受關切，敏捷方法都與這四項宣言有關，這四項宣言都關係到人的運用與活動，例如發展者之間的溝通重於過程與工具的使用，專案的施行不能只有過程而沒有(好的)人，其他諸如迅速產生可執行的軟體、客戶的合作以及...
閱讀完整內容

Code inspection 的代價 (continued)

作者：
本來應該寫在 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 的動作，而是以後續的動態測試才取代。我們知道， 動態測試是治標不治本的方法 ，它 能找到的錯誤是比較少的。假設有有一半的錯誤沒有在動態測試中被找出來而不小心流到使用者手上，那代價可能很難估算。第一：如果造成客戶的業務損失; 第二：維護階段除錯的效...
閱讀完整內容