分類彙整: 分析設計建模

彈性分類群組策略的設計

最近寫了很多的占星文章,不知道有沒有人不習慣呀?為了擔心有些讀者無法適應,同人在 … 閱讀全文

分類: 分析設計建模, 問題解決, 編程技巧, 設計原則 | 發佈留言

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

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

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

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

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

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

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

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

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

為何聽不到使用者心聲?

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

分類: CNet/ZDNet, 分析設計建模, 利害關係人, 問題解決, 專案團隊, 溝通, 生活感觸, 系統思考, 組織, 職場, 衝突 | 4 則留言

溝通的關鍵時刻

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

分類: CNet/ZDNet, 分析設計建模, 問題解決, 溝通, 生活感觸, 職場, 衝突, 閱讀 | 1 則留言

應用服務的減震點

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

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

觀點表達的概念抽象化

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

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

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

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

分類: 分析設計建模, 品質文化, 問題解決, 專案監控, 專案規劃, 生活感觸 | 3 則留言

跨越遠端界面呼叫的藩離

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

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