jim yeh on 十月 14th, 2008

最近寫了很多的占星文章,不知道有沒有人不習慣呀?為了擔心有些讀者無法適應,同人在此寫了一篇有關軟體開發的文章以中和主題,並用來分享我對彈性分類策略的設計心得。 許多的資料查詢,常會根據某些不同的分群觀點來將資料作分類。例如交易資料中的「產品分類」或是「單據種類」,使用者經常會希望將這些欄位當作查詢條件,讓他們可以找出相同產品分類或是單據分類的資料。 然而,實際上的查詢作業需求可能會比較複雜,也就是使用者可能會需要在一次資料查詢的結果,希望把不同資料分類,但彼此的分類之間卻同屬於相同分類群組的資料顯示在一起。我們可以新增資料分類群組的欄位,並依據資料分類來設定其分類群組的內容。這種作法在資料查詢方面的實作上非常簡便,但缺點則是要在資料的維護上額外花費一些成本。 因為這樣的設計會造成資料欄位的遞移相依,違反資料正規化的原則。當資料分類內容修改時,分類群組的內容也要跟著修正;而實際上很可能會因為程式的瑕疵或系統出現異常現象而造成資料不完整或缺乏一致性的風險。 而且,很多依據分類群組集中查詢的需求往往是在專案後期才提出來,如果開發者並不願意因此改動資料庫結構,要如何在不增加群組欄位的情況下,實作出依據分類群組集中查詢的功能呢? 答案當然是將分類群組欄位化成對應的查詢語法或群組欄位的顯示內容,這樣會讓查詢資料的實作程式變得複雜些。因為程式實作者除了必須知道資料的來源之外,尚須瞭解群組欄位與資料分類之間如何轉換。而當相同的查詢需求散布在系統各個程式之間時,就會增加程式開發的複雜度與出錯機率。尤其使用者可能會視作業方式來增加分類群組的需求,開發者應該如何運用設計的彈性,以降低程式開發沒有必要的複雜度呢? 同人在此提出一種設計手法,運用彈性分類群組策略的設計來解決以上的問題

Continue reading about 彈性分類群組策略的設計

     
jim yeh on 八月 7th, 2008

除了軟體功能之外,開發者還必須兼顧性能的設計,其中當然包括兼顧操作的人性化需求外,還必須思考如何減少因為設計不良而造成操作錯誤的機會。

Continue reading about 可用性與可靠性的設計考量

     
jim yeh on 七月 10th, 2008

許多採用使用案例建模方法進行需求分析的開發者,對於不需要使用者介入的系統自動作業,通常會用工作排程者來當成使用案例的主要參與者。讓系統工作排程來啟動使用案例以與系統互動,這對系統開發者而言,可以讓他們了解系統應該如何與外界互動以完成系統所提供的功能,這樣看起來是可行的需求塑模手法。 不過,工作排程者牽涉到系統設計的觀點,如果我們不想讓需求相依於系統設計,那麼我們就必須將工作排程者變成更共通而抽象化的概念。工作排程者的抽象化概念是什麼呢?我們不難理解,工作排程者也只不過是實現時間概念的具體設計。因此,照理時間才是系統自動作業的主要參與者。 然而,當我們把時間當成系統自動作業的主要參與者時,我們會遭遇到另一個問題。那就是基於黑箱的角度來看系統,使用案例應該是以使用者或外部系統來看系統,瞭解如何系統與互動而達到特定目的或產生價值。很顯然地,系統自動作業並沒有辦法為「時間」達到任何的目的或創造價值。 換句話說,我們並未找到系統自動作業的真正使用者,即使我們把工作排程者當成使用者,以使用系統的組織觀點來看,我們將會無法了解系統自動作業和組織目標的達成有何關係,而遺漏了相當重要的使用案例觀點(use case view)。

Continue reading about 系統自動作業的主要參與者

     
jim yeh on 六月 30th, 2008

在現實世界中,通常很難找到不僅懂得軟體開發的技能,又同時具備問題領域知識的人才。而且軟體開發專案本身存在時程與成本等限制,多半不允許系統分析師花太多的時間與成本學習問題領域知識。因此,要期待系統分析師學習問題領域知識是不切實際且又不符合經濟效益的做法。 系統分析師要如何展現出系統分析的專業,才能整合問題領域與解決方案領域的知識,有效地提出具體可行的問題解決方案?

Continue reading about 展現系統分析專業的七種能力

     
jim yeh on 四月 17th, 2008

鍾翠玲看到建築師與校方的溝通上出了問題,她認為這是因為校方沒有積極地參與設計的緣故。但如果在軟體專案碰到同樣的現象時,筆者不一定會認為是因為使用者缺乏積極參與。筆者認為,即使使用者積極參與設計,開發者還是會因為與使用者之間存在觀念溝通上的藩離,而聽不見使用者的心聲。

Continue reading about 為何聽不到使用者心聲?

     
jim yeh on 三月 25th, 2008

要如何進行有效溝通呢?最近,同人聽到一場課程,提出如何掌握溝通的「關鍵時刻」的方法,可以讓我們在溝通過程中,透過不斷循序反覆經歷探詢、提議、行動、確認四個階段,與他人進行有效的溝通。

Continue reading about 溝通的關鍵時刻

     
jim yeh on 一月 18th, 2008

我們必須為應用服務設計減震點來緩衝需求變動所帶來的衝擊,並且讓應用服務可以很有彈性地被重組,使得應用服務的開發變得更有效率。而且這個減震點必須可以支援跨系統甚至是跨平台或程式語言的需求,因為這樣才能不會受限於不同的技術領域,而達到完全地整合各種異質性系統的目的。

Continue reading about 應用服務的減震點

     
jim yeh on 一月 11th, 2008

記得在前一陣子,同人曾與 Joy 討論過有關如何表達觀點的話題。他提到在 funP 大量閱讀後,常常會去思考如何用更恰當的方式來表達觀點。而某一天,我突然領略到觀點的組織其實就是將想法概念化的抽象思考過程,而這個的觀念正好可以做為如何恰當地表達觀點的一個思考方向。

Continue reading about 觀點表達的概念抽象化

     
jim yeh on 十二月 11th, 2007

雖然「計劃趕不上變化,變化比不上老闆一句話」,但趕不上或比不上並不代表要放棄計劃,否則專案的成功也只是聽天由命的偶然罷了。同人認為,軟體專案要成功,關鍵不在於如何照計劃進行,而是要「計劃」當計劃趕不上變化時該怎麼辦。

Continue reading about 當軟體專案計劃趕不上變化時

     
jim yeh on 十二月 5th, 2007

這樣一來,在遠端呼叫的情況下,設計與實作就很難分離了。因為呼叫端的程式必須知道 RPC 的呼叫方式,它相依了 RPC 的實作細節。不同 RPC 的技術實作,會讓呼叫端必須更改呼叫的程式碼,因而產生了沒有必要的複雜度。

Continue reading about 跨越遠端界面呼叫的藩離