分類彙整: 設計原則

可用性與可靠性的設計考量

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

分類: 分析設計建模, 問題解決, 思考, 生活感觸, 職場, 設計原則 | 1 則留言

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

許多採用使用案例建模方法進行需求分析的開發者,對於不需要使用者介入的系統自動作業 … 閱讀全文

分類: 分析設計建模, 利害關係人, 設計原則 | 發佈留言

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

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

分類: CNet/ZDNet, 分析設計建模, 利害關係人, 專案團隊, 思考, 知識管理, 職場, 設計原則 | 2 則留言

應用服務的減震點

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

分類: 分析設計建模, 問題解決, 思考, 設計原則 | 發佈留言

觀點表達的概念抽象化

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

分類: 分析設計建模, 寫作, 溝通, 生活感觸, 設計原則, 閱讀 | 發佈留言

跨越遠端界面呼叫的藩離

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

分類: 分析設計建模, 設計原則 | 1 則留言

軟體開發者不應該自廢武功!!

本文係投稿於 CNet / ZDNet Taiwan 的初稿,並分為上下兩篇文章 … 閱讀全文

分類: CNet/ZDNet, 分析設計建模, 問題解決, 專案監控, 專案風險, 溝通, 系統思考, 設計原則 | 7 則留言

流程與交易的整合(其二)

上次提到用服務層的概念整合業務流程與功能性交易,並指出因應交易流程整合的非同步呼 … 閱讀全文

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

技術在 SOA 是次要的嗎?

「SOA 不只是技術」,是我們常聽到的一句話;然而,SOA 是否與技術無關呢?近 … 閱讀全文

分類: 專案管理, 設計原則, 軟體開發, 開發流程 | 1 則留言

設計樣式已成明日黃花?

在 OO 社群中,由人稱 GoF 所著的《design Patterns: El … 閱讀全文

分類: 分析設計建模, 編程技巧, 設計原則, 軟體開發, 閱讀 | 發佈留言