內行人看門道,外行人看熱鬧

最近高鐵售票系統的問題,在網路上引來許多的的熱烈討論。其中喲哪桑在〈從高鐵售票看 CMMI 〉一文中認為神通的問題是開發者與 CMMI 都有問題,有網友針對這個觀點評論說:

就我所知,CMMI是用來規範開發流程,使專案能夠在規定的時間及預算內完成,至於開發出的產品是好是壞,就不是CMMI能控制的了。

另外神通電腦的客戶是高鐵公司,而不是乘客。提需求的是高鐵,驗收的也是高鐵,只要高鐵驗收通過,就不是神通的責任,是高鐵要對民眾負責。

喲哪桑對這則評論另行撰文,並提出:

坦白說,猛然一看我還有點氣,然而再想想,這不正是典型工程師的想法嗎?

「我就只是照規格做哇!你們規格這樣開,我也照著做,明明我沒做錯,為什麼要罵我小小工程師呢?」

唉!這下不只要說ML3的PA沒做好,我還想請神通與高鐵的人去看看PMBOK、看看Stakeholder Management了。

看了這一連串的對話,我發現似乎很多人都可以從高鐵售票系統指出神通的問題,好像他們都變成無所不知的專家,那這樣神通找他們當顧問是不是就會成功了呢?

很明顯地,以上推論並不會成立,為什麼呢?因為那些專家只是在紙上談兵,他們建構了許多假設,然後依據這些假設作出結論。然而那些假設都是未經證實的,所以如果神通找他們當顧問,我想專案要成功就會遭遇更大的風險,因為假設往往是專案風險的主要來源。 閱讀全文 →

分類: 利害關係人, 品質文化, 問題解決, 專案管理, 生活感觸 | 9 則留言

類別到底是不是有機體?

在〈物件 (Object) 的媽媽是 類別 (Class)?〉一文中,Kenming 兄提到「物件是有機的生命體,但類別卻不是,事實上,世界上根本就沒有『類別』這種有機體;而若是類別不是有機的生命體,那麼,物件就絕對不可能是由其誕生的!」。然而,對於 Kenming 兄的這個觀點似乎很難有定論,誠如 William 君所回應的「 說實在的,這不管是在生命科學層次、哲學層次還是在電腦實踐層次,都未必有標準答案。」。為什麼 Kenming 兄會認為類別不是有機體呢?我想這一段話可以看出個端倪:

我相信在實做面的技術,為了穩定與效能等考量,會把 Class 當成 Object 來用,那麼,Class 在該應用平台是否也是 “Instance” ?

Kenming 兄大概是認為類別並不具有任何的實體,沒有生命期,至少在象徵軟性議題的問題領域結構設計與需求方面的範疇是如此,所以類別在軟體設計上並不屬於有機體。

不過,我倒認為這樣的論點雖然可以簡化設計思維,但對於進階設計者而言,卻會發現設計中,用這樣的觀點來看事情,對設計卻會造成一些困擾,因為真實世界的問題常常不如我們想像地那麼簡單,當我們發現問題領域需要同中求異或異中求同的過程中,就會出現類別這個有機體。 閱讀全文 →

分類: 分析設計建模, 易經思維, 設計原則, 軟體開發 | 發佈留言

喜添嬌女

這個月我們家增加了一個家庭新成員了,女兒於 2007/1/12 晚上出生,2800g 的可愛寶寶。

女兒的降臨是讓人期待已久的,然而生產的過程卻是令人緊張的。寶寶過了預產期兩天還沒有產兆出現,到醫院看胎兒監視器後卻發現寶寶的心跳並不是很穩定,而原來的婦產科醫生卻臨時有事,結果臨時換醫生。醫生研判有胎兒窘迫的現象,只好剖腹生產,所幸手術過程順利,母女平安。

不過不管過程如何,寶寶順利生下來總是令人快樂的,雖然新手爸媽,生活步調變得不一樣了,常會被小傢伙弄得手忙腳亂,雖然辛苦,但看到可愛的女兒,那些疲累也就會自然而然消失了,真是奇妙。 閱讀全文 →

分類: 占星, 生活感觸, 親子關係 | 4 則留言

有關「軟體專案管理」的後續討論

在回應了鳥毅對軟體專案管理的看法後,鳥毅在他的網誌中提出一些後續觀點。然而我發現有些觀念還是不夠清晰,可能是因為我前文沒有說清楚,因此,另闢新主題來表達我的看法。

首先,鳥毅提到:

因為手上的PMBOK資料是舊版,後來在下去找PMBOK第三版,果然看到同人所提到PMBOK對軟體工程管理的部份

我並不了解鳥毅提到的第三版的軟體工程管理的部分是什麼,其實專案管理流程的基本精神在於PDCA,不論新版或舊版都是依循這種精神,只是新版更強調監控要貫穿整個專案階段,軟體工程管理的部分應該還是屬於軟體產業的應用領域,軟體專案管理者必須去了解專案管理如何與軟體工程相互整合,任何應用領域的專案都會和應用領域的工程面做整合,軟體只是其中一種應用領域而已,PMBOK 所規範的是專案管理的通用原理及原則,工程上的實務還是要靠各種不同工程領域的專家相互整合,這點與 CMMI 只規範 what to do,而不會告訴你 how to do 的道理是一樣的。 閱讀全文 →

分類: 品質文化, 專案監控, 專案管理, 專案規劃 | 發佈留言

探討「用 real world 的直觀來認知 model」

在〈軟體設計需面對現實〉一文中,我曾針對 Gameboy 提出「用 real world 的直觀來認知 model ,這有點危險」提出個人的看法。對此 Gameboy 為其觀點 defend,然而在討論過程中卻因為對文字感受不同而造成一些爭論。因此,我認為有必要再進一步地探討「用 real world 的直觀來認知 model 」這個主題,以避免不必要的誤會。

基本上我和 Gameboy 對「real world」的定義不同,Gameboy 提到:

因為我看到太多 beginner 的抽象化是

僅僅源自於他們的直觀認知

而非從 Requirement 下手

但 Real World 中直觀的名詞

不見得適合作為 Domain Model 中的 Entity

但卻往往被他們誤植於 Domain Model 中

由上可知 Gameboy 所言之 real world 其實指的是系統開發人員對系統的初步直覺認知,但在未經需求分析之前,容易落入以技術來主導需求,而使領域模型變成與現實問題領域脫節。Gameboy 的看法並沒有錯,但 Gameboy 說的「real world」與我所認知的「real world」並不一樣,我擔心如果沒有界定清楚,言者無心,聽者有意,很讓初學者落入「言語的流沙河」的陷阱-對軟體設計錯誤認知的來源。

我所認知的「real world」是指對領域專家對問題領域的真實認知,也就是洞察問題領域的認知。領域專家多半不懂我們 modeling 的工具與技術,只有當我們提供 model 給他們看時,他們才會大致理解我們的 model 有沒有涵蓋他們的需求。在實務上,許多技術人員卻很喜歡用技術的角度來 modeling,然後告訴使用者這就是系統的領域模型,結果是這樣的 model 在真實世界的問題領域上一點都不直觀,因為牽涉了太多了技術細節(眉角),根本就不是領域概念的 what to do,而是技術實作的 how to do,這樣的領域模型怎麼可能做到概念上的抽象化呢,抽象化不足,後續必然面臨以技術層次主導需求的惡果-更大的複雜度與更小的彈性。 閱讀全文 →

分類: 分析設計建模, 問題解決, 專案管理, 設計原則, 軟體開發 | 1 則留言

專案管理不適用軟體專案?

鳥毅在他的網誌中提到他對軟體專案管理的看法:

據在下所知,台灣最早採用專案管理的是營建工程界,由於土木建築設計好後變動性較小,因此使用 WBS 比起軟體容易;軟體有許多不確定性,使用Agile開發後更模糊了設計與開發的界限,因此在下並不覺得 PMBOK 套用到軟體專案也適用。

專案管理不適用於軟體專案?要回答這個問題要先知道什麼是專案管理。依據 PMBOK 對專案管理的定義為「在專案活動中,為了達成專案目標所作的相關知識、技巧、工具及技術的應用。專案管理會完整經歷如專案初始、規劃、執行、控制與監控及結案等五大管理流程的應用及整合」。

專案的管理工作內容有:

  1. 識別出需求。
  2. 建立清楚與可達成的目標。
  3. 平衡品質、規模、時間及成本等專案限制,這些限制是會相互影響的。
  4. 為每一個不同考量及期待的利害關係人,調適規格、計劃及方法。

理論上,專案管理與您所開發的產品與服務的內容所採用的方法論沒有關係,所以,對於任何的領域而言,只要專案有明確可行的目標、專案開發的過程中需要規劃、執行與監控及結案等活動,並不會有不適用的問題,即使不同的應用領域會有不同的工程活動(軟體開發流程、軟體工程管理)及一般管理活動,但專案管理流程與這些管理及開發活動是可以相互整合的,所以照理說軟體專案不會有專案管理的不適用問題。 閱讀全文 →

分類: 品質文化, 專案監控, 專案規劃 | 3 則留言

軟體設計須面對現實

最近看到有人領域模型中的客戶類別如此設計:

customer_design.PNG

這個設計觀點是將個人戶與公司戶都看成客戶,因且可以把公司戶與個人戶的都有的共通屬性放到客戶類別上,然後把個別所特有的差異化屬性放到衍生類別個人與公司上。表面上,這似乎是Party〔Fowler96〕樣式的應用,然而仔細推究其設計內容,卻會發現這個設計會使系統增加沒有必要的複雜度(Unnecessary Complex)。

因為個人戶與公司戶其實有很大的差異性,衍生類別的屬性很多,也有複雜的處理邏輯,就算我們採用的永續機制框架-Hibernate可以處理類別的繼承,但繼承卻讓我們的類別之間相互牽連,卻只是為了讓公司與個人的屬性不要重覆出現而要花費如此的成本似乎太奢侈了。

其實這個設計最大的問題是只從結構面的角度來設計類別,只考慮抽取共通屬性,卻缺少了行為面的封裝,這是營養不良的領域模型,設計的本質還是採用程序導向的基本思維,造成問題的主因是設計者並未針對實際發生的問題層面來設計,而是以預期的技術層面來考量,也就是說,樣式的錯誤引用把設計問題變複雜了。 閱讀全文 →

分類: 分析設計建模, 設計原則, 軟體開發 | 10 則留言

服務的供需法則

在《容忍異端的文化》一文中,與網友莫齋討論到組織內部目標一致性的問題,莫齋舉了一個具體實例,然而她所提的例子和之前討論的情況有點不同,但也很值得探討,於是另闢主題表達我的觀點。 閱讀全文 →

分類: 生活感觸, 知識管理, 策略, 管理, 組織, 行銷 | 1 則留言

軟體開發的團隊綜效

最近同事分享參與公司其它大型軟體專案的開發經驗,她認為軟體開發過程中,專案領導者其實並不擅長管理工作:雖然所開發的系統很單純,但每次都是整個專案重新開始;就算想把之前做過的程式碼略做修改,結果卻牽一髮而動全身幾乎整個系統都會被翻修到,要做到re-use根本就是不可能的任務。同事認為管理階層應該考量如何把系統模組化,才能增加開發的效率與生產力。

同事所提的問題其實我們都很清楚,公司很多大型軟體專案都有同樣的問題,也帶來慘痛的經驗與教訓。問題不在技術上,因為大專案能夠得到公司最多的資源,所用的技術是最新的,人員也是最優秀的,而是在開發過程中沒有發揮團隊綜效,大家都很努力做了很多事,但整合時卻問題叢生,似乎永遠有解決不完的問題。 閱讀全文 →

分類: 品質文化, 專案團隊, 知識管理, 軟體審查 | 5 則留言

類別設計演化論

最近HSDc有一篇文章,主題是《繼承或是一般化?》,作者Ringle Lai認為類別的繼承不應該用生物繼承的角度去看它。他提道:

現代人中的上一個分類其實是「人屬」, 「人屬」有一個重要的特性是會製作工具,而現代人種則除了製作簡單工具的這個重要特性外,另外可以進行縝密的思考,因此,產生了製作太空船這樣的行為。

但是,如果我們利用「繼承」的概念去解釋上面的設計圖,則會作這樣的解讀:現代人種繼承自人屬;這種觀念,似乎和我們一般的看法大異其趣。

因此,用「繼承」的語彙來形容類別間的關係,其實並不適合。

然而,到底生物學中的繼承是什麼呢?維基百科對「Biological inheritance」名詞做這樣的解釋:

Biological inheritance is the process by which an offspring cell or organism acquires or becomes predisposed to characteristics of its parent cell or organism. Through inheritance, variations exhibited by individuals can accumulate and cause a species to evolve.

(生物的繼承是後代細胞或生命體取得或變成先天傾向它的父母細胞或生命體的特性的過程。透過繼承,個體的變化可以累積並且造成物種的逐步演進。)

由上面解釋看起來,並不能證明類別繼承與生物繼承在意義上有顯著不同!換句話說,Ringle Lai在該篇文章所提到的「根據生物學的觀點來說,分類是沒有繼承關係的」論點,令我無法理解他的立論根據為何,因為以定義來看生物分類的繼承關係,繼承的重點在於特性的相似性,人種的特性是由人屬所衍生出來的,用人種繼承人屬以類別設計的角度和生物學上的定義並沒有太大的差異。 閱讀全文 →

分類: 分析設計建模, 設計原則, 軟體開發 | 15 則留言