分類彙整: 軟體開發

有關「軟體專案管理」的後續討論

在回應了鳥毅對軟體專案管理的看法後,鳥毅在他的網誌中提出一些後續觀點。然而我發現 … 閱讀全文

分類: 品質文化, 專案監控, 專案管理, 專案規劃 | 發佈留言

探討「用 real world 的直觀來認知 model」

在〈軟體設計需面對現實〉一文中,我曾針對 Gameboy 提出「用 real w … 閱讀全文

分類: 分析設計建模, 問題解決, 專案管理, 設計原則, 軟體開發 | 1 則留言

專案管理不適用軟體專案?

鳥毅在他的網誌中提到他對軟體專案管理的看法: 據在下所知,台灣最早採用專案管理的 … 閱讀全文

分類: 品質文化, 專案監控, 專案規劃 | 3 則留言

軟體設計須面對現實

最近看到有人領域模型中的客戶類別如此設計: 這個設計觀點是將個人戶與公司戶都看成 … 閱讀全文

分類: 分析設計建模, 設計原則, 軟體開發 | 10 則留言

軟體開發的團隊綜效

最近同事分享參與公司其它大型軟體專案的開發經驗,她認為軟體開發過程中,專案領導者 … 閱讀全文

分類: 品質文化, 專案團隊, 知識管理, 軟體審查 | 5 則留言

類別設計演化論

最近HSDc有一篇文章,主題是《繼承或是一般化?》,作者Ringle Lai認為 … 閱讀全文

分類: 分析設計建模, 設計原則, 軟體開發 | 15 則留言

軟體開發能力的自我組織

在不理想的軟體開發環境中,產能與產出多半不能平衡。太過重視產能,容易使軟體開發停留在技術宏觀及理論層次,但這樣會缺少的相對的有效產出,所有概念都只是空談;但如果太強調產出,我們很難適應環境變遷所造成的影响,浪費我們投入的產能,做出來的東西都是無用之物。產能與產出不能平衡時,勢必造成報酬遞減現象,而只有兩者相互回饋,才能形成技術與經驗的增強環路,達成報酬遞增的現象。 閱讀全文

分類: 專案團隊, 編程技巧, 軟體審查 | 4 則留言

不要用技術來主導需求分析

很多系統分析師喜歡用技術的眼光來看客戶的需求。當客戶提出他們的看法之後,系統分析 … 閱讀全文

分類: 分析設計建模, 問題解決, 軟體開發 | 8 則留言

軟體設計並不昧於專案現實

專案現實不但不會侵蝕我們的能力,而是讓我們能力與時俱進,因為軟體設計是不昧於專案現實的,所以專案前期面對現實的規劃(管理面)與分析設計(技術面)是必須的 閱讀全文

分類: 分析設計建模, 品質文化, 易經思維, 系統思考, 軟體開發 | 4 則留言

模組與耦合

其實國內的workflow engine廠商其實都聲稱符合WfMC工作流程標準,但一般人很難了解它們各模組間是否有做到真正的分離。曾問過幾家workflow engine要如何整合其應用程式,所得到的答案多半是「客製化」這個專業術語,但進一步了解才發現,他們並未設計界面來做為減震點(Decouple Point)以減少不必要的模組相依,而是模組必須和特定的實作緊密耦合在一起,也就是他們的客製化會使原先定義良好的模組被破壞了。因此可以推知他們並不是採用模組分離的設計,也就是並未符合所謂的模組鬆散耦合的理想。我想這當中除了作業環境會有不相容的問題外(Web base vs. AP base),更重要的原因就是市場利基的考量,技術問題容易克服的,但workflow市場恐怕還沒具備須鬆散耦合設計的條件。 閱讀全文

分類: 分析設計建模, 設計原則, 軟體開發 | 4 則留言