軟體其實還真的蠻有趣 (1)

這兩個月,我們顧問團隊,還可真是相當地忙,從 10 月到現在(包括到年底),幾乎每天都要出去,除了對企業的軟體設計教育訓練、IT 資訊單位專案開發的顧問輔導,還有幾個正在洽談的專案輔導案 …,喔,還有演講與座談會等。嗯,看來「軟體設計顧問」這事業,在我們手上,慢慢已有逐漸紮根,也有許多軟體公司與 IT 單位等越來越比較能認同我們的軟體設計理念,以及所帶給他們所謂的 “最佳實務” 的方式。

以上星期而言,我與 Ringle 竟然一起跑了五個單位,最有意思的是,每個單位的需求範疇與實現的平台都完全不一樣。嘿,這對我而言,實在是樂趣多多,客戶所牽及問題的廣度與深度,讓我得以從各種不同的觀點與角度來思考與回應。我是不太擔心會被 “問倒”,反而是有些擔心客戶不太敢提問問題,有時反而還要我主動來 “引導” 客戶來回應與互動討論。

因為上星期所發生的一些事件實在很有趣也有意思,甚至,還蠻有成就感的,所以還蠻想分享個人的心得與樂趣,藉此也說明,我,以及 Ringle,都很確定一件事: 軟體設計真的很有樂趣,解決問題(問題越大越複雜越好),是一種享受,而不是折磨。

星期一,是固定到國內某大零售超商的資訊公司,擔任某一個專案的顧問輔導。該專案在我們加入前,據他們說已跑了兩個月,仍然在需求面的分析還沒 “定案”,所以無法轉到 “Coding”。嗯,這已是普遍軟體公司專案開發的 “常態”,我們是從不信這一套,所以輔導一開始就重新 Review 與決定架構與開發設計範圍,然後找一個大 BP(Business Process),逐漸收斂,以活動圖(Activity Diagram)描述與記錄後,再協助他們依據我們所給的一個簡單 “mapping” 的原則,就可轉出到對資訊系統開發最有效的使用案例 (Use Case);再來是打開一到兩個的使用案例,利用基本分析類別(analysis class)的框架,利用循序圖來描述出內部結構元素的互動情形;然後… 第四個輔導日就給產出實現使用案例的應用程式碼,還包含了測試案例與功能測試碼等。整個輔導的過程,是還同時負責這些相關設計產出的教育訓練。我們是蠻主張的,從一個小型的實戰專案中,藉由有經驗的顧問,擔任教練的角色,協同作戰,快速跑過整個開發循環,然後從過程中釐出團隊成員彼此間看法與想法的分歧、再慢慢去作 “調和” 的工作,快速開發、快速產出、快速取得回饋,這是我們一而再地強調 “Iteration” 的最佳實踐!

星期二,我們是到淡水附近,國內某家非常大的保險公司,當然也是資訊單位,這兩個單位的 IT 資訊人員可是各約有 100 人左右,規模算是蠻大的。這家保險公司花了數百萬元購買國外某家非常非常知名大廠的 “Business Framework” 產品,光是設計文件就有數百 MB 之多,但,該產品卻並沒有被 “實現(Implementation)” 至某一平台,所以,該單位當然是想盡辦法希望能實用到該產品所提供非常浩瀚的領域知識(Knowledge),不過,兩年來,該 IT 單位委外其他 ISV 實現的成果一直不佳,無法符合他們的期望。

嗯,在前幾次與該單位的 meeting 會議中,我看過該產品,的確廣度與深度相當地浩瀚,從 Activity Diagram, Use Case, Object Model, E-R Model, Interface Design Model …等,一應俱全。我與 Ringle 看過之後,也相當驚嘆,看來是 “名家” 的作品,直覺的判斷,應該是 Grady Booch 幾年前專案開發的產品。 讚嘆之餘,不過,我是認為,要實現好像沒有想像得那麼難,若連一個案例都沒有被實現出來,應該是分析的手法與角度有些問題。 一般呢,我們在輔導某家客戶之前,總是會由該單位提出案例,我們會利用一個 “prototype” 來實現整個架構與結構的設計呈現,眼見為憑,當然,總是需要證明一下我們的 “實力”,也算是一種試煉,同時也比較能確保若談成輔導案時的一種信賴度。

在進行這一個 prototype 之前,其實前幾星期他們已先找過該產品在國內代理的 “某大廠”,該大廠還委請國外的專家來進行 10 天的輔導與試行開發(與原型開發意義是一樣的)。但,結果仍非他們所期,雖然有完成功能面的需求實作,但,這不是他們想要的,他們要的是,在結構面要能完全支援該 business framework 規格的 Interface Design Model,而,往往一個小小的功能,可是要 “串” 上 10幾20個企業元件,這可還沒有牽涉到平台面的實作物件喔。

早上的會議作了一些其他議題的討論,包括教教她們如何抓出 “essential entity”,然後該如何 mapping 至該 business framework 產品內 E-R Model 的那一部分。嗯,看看樣子,其實她們應該也是沒有期待這次的 prototype 能有所 “成果”,這麼多人,花了那麼多時間,就是一直打不開這個 “潘朵拉密盒”,只有我與 Ringle 當天在該 prototyping 會議,我們又不懂該領域的相關知識,怎麼會有可能給實現出來? 嗯嗯,我好像一直很樂觀,甚至,並不覺得這有難到無法解開,我是這麼認為,要能找到這把 “關鍵之鑰” 來打開寶盒,從 Domain 的觀點與 IT 平台實作的角度切入,都不太正常,那是個 “Business Framework”,是軟體大師的作品,當然要從 “純” 軟體的角度切入才有可能解開!!

我與 Ringle 都是這麼確信,只不過,我比 Ringle 更來得樂觀就是了。中午吃飯時,Ringle 還有些 worry,但,我還是一直很有信心,信心的一個最主要來源就是,我是相信 Ringle 一定可以找到方法切入 prototype 的實作面的。要當場就能展現從浩瀚複雜表象的文檔裡,分析出脈絡,還要能具體實作,這可非 Ringle 莫屬,這我可沒辦法(我能看出問題與茫點,但實作的功力,可是差一大截),而且,我真的不得不佩服,Ringle 還真是這一行的天才,吃完飯後,他已經想好實現的方法了,而且,一想出來,馬上開始動手,除了利用 EA 定出好幾個層次的 Interface 元件後,找出要實現這一個功能的 operation(每一個 operation,又會呼叫其它的 interface,環環相扣),然後寫好使用案例,光只是一個查詢功能,就會呼叫到 10 餘顆的 interface,又要 “想像” 來寫出具體實現的物件 …。三個小時,還真讓 Ringle 給完全寫出來了,只差沒有加上與資料庫連結的這一段細部設計。 她們部長(很漂亮與和藹的女生)以及其 SA 這次可真是相當驚嘆,我們所展現出如何分析的手法與思考邏輯,以及如何具體呈現的設計與產出,正是她們所沒有,也正是她們真正需要的,Bingo !!

總算睜大眼睛了,然後更希望我們能加上與資料庫連結的那一段細部設計與實作,所以再約定了下一個星期再展示算是第二個循環的 prototype。還是 Ringle,只利用星期日的時間一天 “順便” 學一下 Java Spring 與 Hibernate,整個 prototype,實現一個使用案例,從 JSP 到企業元件到資料庫,就給徹底的給實作出來了。 今天早上呢,就是去展示這個 refine 的 prototype,再作一次更細部的解說,大家都很滿意,也都很 Happy,明年度的顧問輔導合作,應該是很有機會創造 “皆大歡喜” 的成果出來的。 還有,這一次也可以說是這幾年來最有成就感的一次,要能 “看到” 一個內部都是完全以interface 為主的企業框架,可真是難得,然後透過我們手裡,而且別人還無法給實現,我們又只利用一到兩天的時間就 “打通” 脈絡,那一種喜悅與成就感,就是擔任軟體顧問職的最大價值了。

好了,回到家後,輕鬆一下,我的 “Relax” 就是玩「魔獸爭霸 3」對戰。工作是順利,但打電玩呢,就是不怎麼順利,又連敗了,這種即時戰略,要手與腦的全能協調,好像不太能適合我勒~

星期三早上,是應邀開車到台中「逢甲大學地理資訊研究所」作個演講。前幾個星期,已安排這天下午三個小時左右的演講,而在以 Email 溝通的過程中,他們的問題,是讓我有些失望,大概就是想找個 “方法論”,找出 “How-to” 來解決他們在專案開發上遇到的種種問題,所以,問題諸如軟體專案從生命週期、分工合作模式、角色等面向,PIM, PSM 等模型該如何區隔 …等。嗯,簡報該如何準備? 這些問題,好像整理成 50 頁也講不完,但反過來想,好像一頁的簡報也能回答眾多這類所謂 “方法論”、”流程論” 等等這些軟體工程的問題,就決定了,準備一頁簡報來 “應付” 在場聽者的各類問題,而且我還很有信心,所有的線索與答案,都只在這一頁的簡報就能找到的。

我又與 Ringle 一起開車到台中,中二高沙鹿交流道下車,開車過大雅,有個很寬的道路,就給它右轉進去,我知道逢甲的方向在那邊沒錯,但是,進去的是新闢的科學園區,然後走到底就沒路啦。Ringle 馬上 Show 出他的 Treo Palm 手機,有個 ShowMap 導航軟體,指出我們大概的座標,沒想到,沒有地圖顯示中科的道路。真諷斥也真有趣,剛好也讓我想到開場的主題:為什麼國內某家知名 PXGo 的導航軟體,沒有支援 Palm, Symbian 等手機 PDA 系統,為什麼只能開發 MS 相關的應用軟體?

耶? 大部分的人是這麼認為:西瓜靠大邊,所以當然選擇主流的市場啊! 問題是,我的意思是,那為什麼不乾脆所有的平台都一起開發? 為什麼一套產品一定非得要與某個主流平台綁那麼緊,各家平台的實作技術,有這麼困難嗎?

真正的問題在哪裡呢? 這個導航產品的 “結構面” 不見了啦,根本沒有用心作好 GIS(地理資訊系統) 這個領域的概念分析與分解,而成為真正有效的軟體結構模型。該產品推論應是以專案的方式進行,然後直接從需求面的功能觀點,直接給轉移至與平台緊依的實作面,至於結構面,肯定是給忽略掉了。若是如此,當然無法 “萃取” GIS 這個問題領域的核心,也就是把該領域的重要概念與術語,給表達至軟體的領域模型上,然後再參考要實現的各平台特性,包括 Win Mobile, Palm 等系統,加上平台面的細部設計即可。 咦? 好像也就同時說明了 PIM 與 PSM 模型的區隔了。

Architecture-Centric Process

我用一頁的簡報就是以這張圖來作整個流程開發說明的。細節上我想就不再做說明,或者,我應該會寫另一篇文章來專門解釋一張圖的 “涵意”,它可以 “讀出” 相當多的故事與假設點的,同時也代表一件事,從需求面切入與從結構面切入或甚至直接從實作面切入,各有其開發模式,絕對不會是一樣的,而所注重的開發角色與其技能也都不盡相同,那更說明了一個重點,根本就沒有所謂的一種 “標準開發流程” 可以被複製與管理的!! (未完,待續 ...)

文章導覽

   

共有 12 則迴響

  1. Hello Mr.張祐誠:

    大概知道您想表達的。

    您所提的,諸如演算法則等,是屬於 Domain 上需求的範疇,這點是需要尊重 Domain Expert 的專業知識;而,後述您所提的,是屬於 IT 實體平台的現實考量,這是屬於平台技術專家。

    此兩者,一反映的是需求面;另一則是反映的是實做面,均不可或缺。

    但,與個人所指的 “領域概念軟體模型”,仍是另一回事的。也就是,以上兩者,若能再重視結構面的設計,那麼,個人相信產品的價值可得以再提高更多的…

  2. Mr.Kenming

    其實我這邊直指的架構設計,指的正是由上到下,不同階層的領域資訊分類與萃取,與語言無關,與平台無關,如GIS的點線面空間表現方式、座標換算、資料搜尋演算法、衛星資訊判讀解譯、圖層操作轉換..等,都與平台和語言無關,只有進行到最底階層的In與Out設計(資料讀取、螢幕輸出、互動裝置訊息擷取處理)時,才會牽扯進平台與語言資訊(include the certain libary、call the certain API),且引用呼叫平台介面時,若能再包一層,就更能將平台資源呼叫鎖定在特定package,如此,才不致於讓直接呼叫與引用分散流竄在系統各環節,若需移植不同平台,也只需抽換平台資源呼叫引用這一層(或包裝,whatever),包得好,一般連與底層溝通介面都毋需更改,以上正是我所說的架構設計,但有時硬體的資源與開發環境是很現實的,,不支援就是不支援情況下,再巧的結構與架構,恐也難達成無米之炊。

  3. Hello Mr.張祐誠:
    我相信有做 IT 平台的架構分析。
    不過,我並非指是架構的設計喔,是指領域模型的結構分析與設計。

    架構(architecture)設計與結構(structure)設計,是兩個議題,也算是不同的兩個層次。

    或者可以這麼說,結構面的分析與設計,是架構設計考量其中的重要一環;而平台的實做設計,也是支撐架構設計其中更為實際的一環,但也因為如此,使得 “實” 的平台實做極受重視,而 “虛” 的軟體結構設計卻比較為之疏忽。

    個人推測,您所提的架構設計,可能比較偏向是 IT 平台面的實做設計。

    後續您所提的問題,其實在個人的內文後也有提過,您可以再行思考過,就當作是個參考。

  4. 我不覺得PXGo的架構沒做好,一個具備完整功能GIS圖台的複雜度,由底層寫上來,程式碼少說有十幾萬行,若缺乏良好架構設計,PXGo光是虫就抓不完,因為無良好架構的10幾萬行的程式碼,在聚合力的牽扯上,是無法想像的,有用過PXGo的人應該感覺的出,它應該沒有操作兩下就彈出個Error message,況且在計憶體與裝置資源都受限的smart device平台上,無事先的良好系統分析與規劃,肯定連show map都有問題,移不移植某平台,有時不是技術問題,市場策略與軟硬結盟也有很大關係,不然問一下東森購物台,看他們有沒有賣Palm。

  5. Hi M:

    謝謝您的經驗分享。
    有些的作法我們是不同的,我們反而不會去設定很多 “限制”,強調的是如何 “聚焦” 的功夫。

    另,我們反而比較經常、甚至蠻願意接手失敗的專案,好像比較難? 其實換成另外一個角度,因為反而讓客戶有比較,更容易去凸顯手法上的不同之處。

    另,我到有些好奇, M 是在那家公司服務?

  6. 我的部門會業界出名也是因為和上面有類似的機緣,某公司用了很貴的framework,不過實做的經驗很少,也畫了很完整的UML圖樣,請了歐洲的原廠專家來,就是做不出user想要的。一年後我們進入,立即設定非常多的限制(Use case最重要的就是限制),很快就作出了。
    問題是,新的專案都沒這麼幸運,因為台灣客戶買了就預期你要有他想要的『所有』功能,只要專案範圍說明書不清楚的全都是要的,一定要等到失敗了才有機會(如果你還在的話)讓你設定限制。
    我要說的是,讓看這文章的人知道,接手別人的失敗專案和從頭來的差很多,就好像談戀愛趁虛而入比從頭來追難的多了。

  7. Hi 訪客先生:

    >當GPS接收API方式不同, Database, UI架構完全不同, 還剩下什麼去抽象?!
    是 Logic/Flow, Business Logic, Object Model 嗎?!

    >Embedded Systems 常常跟實做綁的很緊.

    既然我會提出這樣的見解,當然是知道如何做到與 “平台” 沒有相依的軟體模型。

    而這些,是與是否是 Embedded System 並沒有多大關連的,甚而,與 APIs, DB, UI 等也沒有什麼關係的。

    軟體開發最常遇到的謬誤,就是經常有這樣的假設前提,馬上聯想到平台的支援與實作,卻沒有用心來思考如何捕捉某一問題領域(如 GIS) 的概念,轉成有效的軟體模型,才不得以與平台綁得如此緊。

    若訪客先生是熟知某一嵌入式系統領域的開發廠商,不妨試著聯絡我們,我們很樂意到貴公司拜訪並說明。 您可以當作是 “只是參考”,聽聽看是否有些道理。”若”… “果真” 能實現各平台的 PxGO, 應該是對該產品有正面的經濟效益吧?

  8. ING ?!

    >> 為什麼國內某家知名 PXGo 的導航軟體,沒有支援 Palm, Symbian 等手機 PDA 系統,
    >> 為什麼只能開發 MS 相關的應用軟體?
    >>
    >> 耶? 大部分的人是這麼認為:西瓜靠大邊,所以當然選擇主流的市場啊! 問題是,
    >> 我的意思是,那為什麼不乾脆所有的平台都一起開發? 為什麼一套產品一定非得要與某個主流平台綁那麼緊,各家>> 平台的實作技術,有這麼困難嗎?

    當GPS接收API方式不同, Database, UI架構完全不同, 還剩下什麼去抽象?!
    是 Logic/Flow, Business Logic, Object Model 嗎?!

    >> P.S. 只談軟體設計(Design)與創意思維,(How-to)面問題請勿找我。

    Embedded Systems 常常跟實做綁的很緊.

  9. Hi Encoh,
    你一個人就很強了, 如果你和站長合作… 大家都沒飯吃了:P

發佈回覆給「M」的留言 取消回覆

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *