深圳軟件三日教學行(20~23)-02

深圳真是個美麗乾淨的城市!

道路非常的寬敞,到處都是豪華式的大廈林立。 若與台灣這邊的都市比起來,高雄市是比較接近的,但是卻仍沒有像深圳這般如此大又寬的馬路。 空氣也比台北清新太多了,主要的原因就是,這邊是禁止吃汽油的摩托車、而只能騎乘吃電的輕型機踏車。 喔,還有個有趣的現象,這裡並沒有專用的自行車道,所以騎踏車的民眾,竟然是騎在內側的快速道路上,而且還是逆向行駛,好像這也不算是違法,真是奇特的一景呢。

隔天早上我們與對方企管顧問公司派來接洽的兩位女孩子在旅社見面 (其實她們前一晚就從廣州前來並住宿在同一旅社),用完餐後然後由她們帶我們搭地鐵前去教課的地點。

這邊的環境對我來說一切都透著新鮮。 沒想到,早上約 8:00 時分,來來往往的群眾根本就是與台北一樣,儘是趕著上班、臉上總是冷漠、匆匆忙忙的上班族。 而這邊的地鐵也與台北的捷運一樣,但是又乾淨上太多了,而且趕著上班的人潮,大約只有台北的 1/10 左右吧,每一般列車都還能有空位乘坐。
深圳地鐵

我們教課的地點就是所謂的「深圳軟件園」,應該就是等同於台北「南港軟體園區」,但是卻又是大上太多太多了。
深圳軟件園

閱讀全文 »

深圳軟件三日教學行(20~23)-01

這個月初,突然接到來自大陸廣州某家企管顧問公司的來信,希望能邀請 HSDc. 團隊至深圳教授 EA (Enterprise Architect) UML 工具操作使用。 怎麼會知道 HSDc. 團隊? 原來是 Ringle 的那本著作:「UML 與團隊協同合作」有大陸那邊亦有耳聞,且最近即將出版簡體版本。 因為結合了基礎觀念與實務操作,所以算是還頗為實用的工具用書。 而且對方一定指名要有 Ringle 親自來任教,其他講師,包括我與 Cathy (這次共安排了三位講師),都只算是助教性質。 😉

對大陸事務的協調與聯絡,當然是由 Cathy 負責處理了。 她的執行能力與行動力是我所看過諸多人當中最積極的。 月初聯絡與討論,然後規劃了三天共 18 個小時的課程,安排了日程、交通與食宿等,這個星期,20號(星期日) 晚上就搭機成行了。

老實說,我還真頗不想去。 主要的原因是,我還沒有搭過飛機出國過。 🙁

但可不是搭飛機害怕喔,而是我實在想把我第一次的「處女航」獻給家人、一同出國旅遊啦。 這類洽公性的事務,實在有些些的不甘心。 不過,基於現實的因素,對方相當有誠意,講師鐘點費用與在台灣我們的報價是一樣的,而關於搭機與食宿等,都由對方買單;再則,我還真想瞧瞧大陸在最南邊這一端的軟件發展情形。 喔,對啦,順便也去探望一下我老婆她哥哥,聽說他在「東莞」開了三家的韓國烤肉餐廳。 一年多不見,而且他聽說我要過來深圳這邊,就很積極的說要帶我去他的餐廳吃大餐。 🙂

我們是搭 20號晚上 7:20 「國泰航空」飛往香港的飛機 (當日沒有直接飛往深圳,所以只好到香港再入境)。 我是開車,再去接 Ringle 一同到桃園機場。 因為是在「第一航廈」出(入)境,而那邊的停車場過夜每天只收 NT$100,當然划算多了。

因為啦,是第一次的出國,當然一切都算是透露著新鮮好奇,所以總是隨手拿著我老婆的 Sony T10 DC,看到就拍照,留著紀念。

一到出境大廳,然後拿著電子機票 Check-in 登記飛機座位後,就到了樓上一整排的商店區。 尤其是看到了 StartBucks,開心~ 離登機還有一個半小時,當然就是在這裡喝個咖啡休息囉。

桃園國際機場一景

這個時間正是耶誕氣氛,StarBucks 的熱門咖啡就是 "太妃糖核果拿鐵" 與 "櫻桃摩卡"。 我點了太妃糖,呼,真是香濃好喝啊。論花式調味咖啡,還真的是 StarBucks 的咖啡特別濃郁好喝,但就是太貴了些。
StarBucks@桃園國際機場

閱讀全文 »

[輕鬆一下] Title 掛「正」工程師?

前一陣子,拜訪了一家數位創新應用的某軟體研發單位,洽談顧問輔導的合作方案。

該系所的組長介紹了旗下從事數位媒體播放的開發小組,以瞭解是否有進一步互動合作的機會。

該小組的成員年紀都很輕,全都是高學歷研究所以上畢業。 其中一位女孩子,還是就讀博士班的研究生,身材高佻,而且看起來就是相當聰慧的樣子。

第一次見面總是會互相遞送名片、彼此簡單認識一下。 我對那位女孩子遞給我的名片特別感興趣,因為她的名片職稱是掛上「正」工程師。 我拜訪過有百家以上的單位了吧,還是第一次看到這樣的 Title 說。 一般啦,工程師較常見的職稱不外乎是 "資深 (Senior)" 或是較 "資淺 (Junior)" 的。 像這樣 "俗又有力",一目瞭然,一看就知道是擔任正職的工作,也是很不錯的呢。

我比較喜歡開些小玩笑,藉此也可以暖暖場子。 我跟那位女孩子說,耶!? 少掉一個字勒。 哪一個字呢? 那女生問道‧‧‧ 我說,應該是叫做「正妹」工程師吧?

哈,女孩子總是喜歡聽到讚美的話,聽我這樣說當然笑得很開心勒。 :mrgreen:

不過,說一句老實話,那位「正」工程師的確是名副其實的「正妹」工程師啦。 😀

[純消遣] 軟體產品有料號嗎?

最近我暫時協助團隊對外的產品報價事宜,老實說,許多電話打來的問題,真讓我實在無奈得很。

某個單位詢問 EA (Enterprise Architect) 的報價事宜。 為了買幾套 EA,光是電話詢問已經好幾次,卻還遲遲未見下 Order 單。 我一向做事比較乾脆,我是蠻訝異這類的開發軟體,有需要的人自然就會買,怎麼還會問拉哩拉雜無關技術性的一些問題? 尤其是砍價,這好像是台灣人的通病,不砍就是不舒服;可是,一方面我們僅是代理、利潤相當微薄,再則,這個軟體要比較的應該是與 Rational Rose, Borland TogetherJ 來相比、而 EA 比這兩者還便宜上近 20 餘倍的價格,功能卻毫不遜色。 而也是因為這樣,我們也才從國外洽談該軟體的代理,作為我們顧問輔導與系統開發的利器。

除了價錢問題外,一些古怪的問題我總算見識到了。 話說該單位的業務採購,竟然打電話問我說: 這個 EA 產品有沒有 "料號"?

料號!? 是的,沒錯。為什麼要料號? 因為我們公司需要建檔。 我只好反問說: 請問貴公司購買 WindowsXP 有沒有給料號? 他好像也答不出來。 我也只好再說,軟體這種東西哪有料號,只有序號 (serial number) 啊。 是不是他自己把料號與序號搞錯了? 再則,這類開發軟體的採購,都是透過網路 eMail 寄送 License Key,再從原廠網站下載登錄註冊即可,也並沒有實體的產品包裝的。

該位業務又問了: 那麼我們可不可以為該軟體自行建檔建立料號呢? 這…… User 單位要怎麼自己建檔,那不是你們的自由嗎? 我是再補上一句啦: 要建檔可以,不過,你要能找得到可以幫該軟體貼得到標籤的地方啦。

寫好使用案例 (Use Case)有什麼好處?

上個月我在「工研院」授課時,其中一位較為資深的程式開發人員問的問題: 我感覺不到寫好使用案例 (Use Case) 有什麼好處?

別誤會,這位年輕的開發人員並沒有惡意,我也認識他一陣子了。他的確是有感而發,覺得在工作上,從以前透過一般的需求規格書,到現在開發時導入 使用案例 的分析需求技術,但是,他並沒有感受到因為這樣而有加快程式撰寫的速度,反而還覺得縛手綁腳,經常需要受到規範。

這個問題,可比想像得還難以回答。 是為了可以有效保存需求分析的資產? 還是為了系統的彈性 (flexibility)? 前者似乎有道理,但如此對現在正進行的開發專案好像沒有說服力,甚至開發人員還覺得為了要補足這些需求文件,反而拖累了開發的速度;後者的系統彈性問題,我則是很確定與寫得好需求分析文件沒什麼直接的關係,彈性度的考量,與軟體的結構設計 (structure desgin)才是更主要的關鍵。

思考許久,我是以為,寫的好使用案例最直接的關鍵是: 影響到專案開發整個流程的節奏!

以使用案例為導向 (use case driven)的開發模式,我的體會是越來越能感受到那個所謂的 "driven" 這個字眼。 短線專案的特性,幾乎是偏以需求為優先。而使用案例的分析,其本質上仍是屬於功能 (functional)性的分析。只是有別於模組化的功能樹分析模式,後者的功能模組,耦合性 (coupling) 太重,容易牽一髮而動全身,所以在需求分析階段,會耗費許多時間在分析共用模組的考量;而使用案例,是一種目標導向 (goal-oriented)的功能分析方式。 每一個使用案例,都可以看待成是系統在某一段期間 (session),可以滿足使用者使用系統的目的。 所以每一個使用案例,是可以個別被獨立開發,也就是說,UC-A 與 UC-B 甚至可以交付給不同團隊並行開發。而至於兩者若有共用性的議題的考量,則是延宕到結構設計階段再來討論即可。因為在需求分析階段,不用花太多時間在共用議題的考量上,所以可以很快速地實現 (realize)功能需求。

能抓得好與定義得好一個一個的橢圓使用案例,就能以該使用案例為開發單位。 這麼說好了,甚至可以把該使用案例就當成是一個迷你系統,然後來串連出整個開發的程序與產出。 例如,針對一個使用案例,就會設計一個位於中間層 (middleware)的控制型物件 (control object),並從使用案例的敘述 (use case description)中,找出該物件應承擔的行為 (behavior),然後再轉化成更詳細規格、程式語言的方法 (method)。 定義好控制物件與其應有的行為,就可以知道需求分析是容易並可以無縫式地轉移到實做階段,並快速地界定出程式碼的骨架 (sketletion),再來就是補足細節、實做邏輯、連結資料庫或外部系統 等等…。

閱讀全文 »

關於庫存管理以 “Boundle(綑)” 為單位的結構設計

上星期參觀「東和鋼鐵」的煉鋼生產過程,收穫頗多。 除了感受到現場工作人員需要忍受酷熱危險的工作環境,而仍是那麼地辛勤工作,不禁敬佩與慚愧,應要能更珍惜自身的工作;另外一個收獲就是,總算看到了我們對「東鋼」設計企業物件類別圖時,一些概念術語中,關於到 "物 (Item)" 的實體呈現。

像在現場上我們就看到以 "捆 (Boundle)" 為單位的鋼材。 可能像長條形的凹型鋼是以三根為一捆,在入庫/出庫(出貨) 時就是以一捆一捆為單位來管理。 在庫存管理時,每一捆都會給一個序號 (serial number),但一根一根的鋼材並不需要為其作追蹤管理,所以並不需要給予編號;若某一捆的某一根鋼材有瑕疵,就是換掉再綁入該捆即可;每一捆的鋼材規格可能會不一樣,可能有 "凹型鋼"、"馬蹄鋼"、"T型鋼" (想像的規格) 等。

所以當時看到已綁成捆的鋼材,我問 Ringle 說 "捆 (Boundle)" 應該是屬於 "特定項目 (Specific Item)" 吧? Ringle 說沒錯,而且在類別設計時,並不需設計一個 "鋼材" 的 特定項目 類別。 所以有趣的一個問題是,當看到一捆有三根鋼材,若共有三捆時要入庫,在庫存管理系統內,會有幾個物件? 答案可不是 3x3=9 個 instances (個體),而是只有三個 instances,而所屬類別就是 "Boundle"。

"Boundle" 的規格 (Specification)資訊紀錄在哪裡呢? 此時自然會有一種 "產品 (Product)" 類型的類別被挖掘出來。 在庫存系統中,會有個 "成品" 的類別被設計出來,並紀錄著各種鋼材等項目的規格資訊。

每一次的出庫、入庫都需要記錄相關的資訊,所以會設計 "入庫"、"出庫" 兩種類別。 而這類型的物件就是所謂以交易為核心 "Transcation Pattern (交易樣式)" 中的交易物件。

再來,若要查詢現在庫存的數量,該找誰問呢? 此時就會有個 "庫存 (Inventory)" 的類別來擔負 "查詢庫存數量" 的責任。 有意思的是,"庫存" 類別在古早以人工來紀錄的時代以來,就是等同於 "帳冊" 的角色,而這在我的認知算是在電腦系統內 "Log" 類型 這樣的一種角色。 不過 Ringle 倒是很肯定的告訴我,是 "Log" 沒錯,而在 "Transaction Pattern" 中,這仍是屬於 "Specific Item" 的類型。

基本上,一個以鋼材物料的庫存系統主要組成結構元素的輪廓就慢慢浮現出來了,先略過 "人 (Role)", "地 (Place)" 的類別設計,一個基本的 UML 概念類別圖 (Conceptual Class Diagram)如下圖:

庫存系統的概念類別圖
圖、庫存系統的概念類別圖

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal