加油站與小鎮

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

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

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

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

留言

張貼留言

這個網誌中的熱門文章

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

大長多多

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

漫談Agile Modeling

作者：
圖片
自從2002年Scott W. Ambler寫了一本叫" Agile Modeling - Effective Practices for eXtrem Programming and the Unified Process "以來，Agile Modeling(AM)的觀念與方法逐漸大行其道，由於AM的觀念可用之於各種物件導向軟體發展方法上，因此希望來輕鬆談談AM這種方法論(methodology)，以收拋磚引玉之效，同時也呼應『目』與『F』那篇文章。這篇文章所談的大部分來自Ambler的說法，我只不過摘要式地加以闡述，但仍然可做為軟體工程師創製模式時借鏡。 依照Ambler的定義，AM是一種渾沌、實用為基礎的方法論，其有效地用於模式化與文件化軟體系統，「渾沌」(chaordic)一詞可說道盡AM的精神，依個人的詮釋是「不受限但處理的事物漸趨規則」之意，也就是說，規則來自於渾沌的演進，至於此地所說的方法論(methodology)並非指發展軟體的方法，而是指每天由軟體專家們應用的一些常規(practices)，這些常規依照AM原則與真義(value)而定。Ambler依他的經驗，擬定了核心與補充原則共17項，以及共21項的常規，至於AM的真義有4項來自於XP(Bechk 2000)，但加上「謙卑」(humility)一項，而形成Ambler所說的AM真義，我想這5項真義值得加以簡單說明，因為所有的原則都源自於這5項真義： 溝通(Communication)： 發展團隊成員之間以及專案相關人士間的溝通必須有效。 簡單(Simplicity)： 發展符合需要的最簡單的解決方案。 反應(Feedback)： 盡早並且時常獲取對工作的回應。 勇氣(Courage)： 要有嘗試新技術的勇氣，而且成為決策。 謙卑(Humility)： 必須謙卑允許別人提供對於你專案工作的意見。 這五項真義以及各項常規與原則是引自於敏捷聯盟(Agile Alliance)的四項敏捷宣言，因篇幅受限，我不便在此地詳述這些17項原則與21項常規，讀者如有興趣可參考Ambler著作Agile Modeling，或網頁： http://www.agilemodeling.com/ ，不過我希望討論其中最主要與實用的「簡單」這一項真義所在。 Unix的發展者之一P.J.Plauge...
閱讀完整內容