加油站與小鎮 取得連結 Facebook X Pinterest 以電子郵件傳送 其他應用程式 作者: 薛念林 8月 08, 2017 兩個小鎮之間有一個荒蕪之地,一些汽車會經過,一個聰明的商人於是在那裡開了一間加油站,生意還不錯。一個月過後有人在旁邊開了一間雜貨店,買點日用品喝點水,再過一些日子有人開了咖啡店,可以休息聊個天。漸漸的有人在那裡蓋房子住了下來,於是餐廳、學校、銀行進駐,慢慢的變成一個小鎮。 同樣一個故事發生在另外一個地方,生意人覺得加油站真賺錢,於是在附近蓋了第二間加油站,生意也還可以,於是第三個人再進來蓋加油站,開始削價競爭,最後三家生意都做不下去紛紛倒店了。 老掉牙的故事,每隔四五年就會聽到一次,但感受卻越來越深。 我們現在做的系統(或事情),是第二個加油站,還是邁向小鎮的咖啡廳? 取得連結 Facebook X Pinterest 以電子郵件傳送 其他應用程式 留言
漫談Agile Modeling 作者: 黃為德 12月 15, 2008 自從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... 閱讀完整內容
CMMI是什麼? 作者: Y C Cheng 8月 01, 2008 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) 式兩種表示法。採用連續表示法... 閱讀完整內容
漫談「模式驅動架構」 (二) 作者: 黃為德 7月 19, 2008 CIM - PIM - PSM 樣式 在「漫談模式驅動架構」(一)中我們談到,OMG將MDA建構成CIM-PIM-PSM樣式,程式則由PSM轉換(transformation)而成,這是依照一種較合宜而方便的觀點(viewpoints)所形成的樣式,事實上MDA卻允許有其他的觀點,而產生其他的樣式,但CIM-PIM-PSM樣式的重點在於其提供「事務分離」的概念,因此我們仍然以大家接受的OMG樣式來漫談 ,實際運作時,該樣式可以延伸成CIM-PIM-PSM-Code 。 何謂CIM,CIM有時稱為「範疇模式」(domain model)或「業務模式」(business model),用來描述業務系統,但本身並非軟體,這個模式表示系統的關鍵需求,以及描述問題範疇的字彙(vocabulary),但不涉及系統的細節,一般物件導向系統分析方法就可用來建構這個模式,PIM就是依據這個模式而產生。 PIM是表示業務邏輯(business logic)的模式,這個模式顯示系統的工作內容,但不涉及與任何特殊技術平台(technology platform)的關係,如EJB,.NET或關聯性資料庫等,PIM類似OOA的分析模式(analysis model)但更為詳盡完整,每一種業務只有一種PIM。至於PSM則結合PIM所擬定的規格來顯示系統將如何在特殊技術平台上實作,因此它是由PIM轉換而來,程式則由PSM轉換而得。PIM,PSM與程式之間的轉換可以用人工,但一般皆使用MDA工具來擔任,因人工不但費時而且可能出錯。在此我們引用Booch等人的所謂「MDA宣言」(The MDA Manifesto)來支持這個觀點,宣言有三點:(1) Direct representation; (2) Automation ; (3) Open standards,因篇幅關係我們不在此地詳談這三點宣言,因為自動化涉及MDA的運用甚巨,因此我們希望強調第(2)點 - 自動化轉換。以上說明對於不熟悉物件導向軟體工程的人士可能較為抽象,也許下圖(雖然不很完整)可以協助了解MDA的運作方式: (點圖形放大) 圖中我們同時將MDA與傳統的發展過程做比較,兩者之間的生命週期差異不大,但MDA主要特點在於 PIM->PSM->Code的自動化轉換,保養是在PIM而不是程式,PIM是唯一代表業務邏輯的模... 閱讀完整內容
留言
張貼留言