1. 人遠比技術重要; 多花點時間到軟件需求和設計一個使用戶能很容易理解的界面上.

2. 理解你要實現的東西; 好的軟件設計人員把大多數時間花費在建立系統模型上.

3. 謙虛是必須的品格; 從同事,客戶口中獲取足夠多的新東西.

4. 需求就是需求; 成功的軟件取決于時間,預算和是否滿足用戶的需求.

5. 需求其實很少改變, 改變的是您對需求的理解.

6. 經常閱讀;  在這個每日都會發生變化的產業中, 您不可能在已取得的成就上陶醉太久.

7. 降低軟件模塊間的耦合度. 解釋耦合度 : 模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。模块 间联系越多，其耦合性越强，同时表明其独立性越差。降低模块间的耦合度能减少模块间的影响，防止对某一模块修改所引起的 “牵一发动全身”的水波效应，保证系统设计顺利进行。 
    高耦合度的系统是很难维护的。一处的修改引起另一处甚至更多处的变动。

    你可以通过以下方法降低程序的耦合度：隐藏实现细节，强制构件接口定义，不使用公用数据结构，不让应用程序直接操作数据库（我的经验法则是：当应用程序员在写SQL代码的时候，你的程序的耦合度就已经很高了）。    耦合度低的软件可以很容易被重用、维护和扩充

8. 提高軟件的內聚性
   如果一个软件的模块只实现一个功能，那么该模块具有高内聚性。高内聚性的软件更容易维护和改进。

    判断一个模块是否有高的内聚性，看一看你是否能够用一个简单的句子描述它的功能就行了。如果你用了一段话或者你需要使用类似“和”、“或”等连词，则说明你需要将该模块细化。    只有高内聚性的模块才可能被重用。

9. 考慮 軟件的移植性; 好的軟件設計者把那些特有的實現細節打包隱藏起來, 那些特性改變時,更新包即可.

10. 接受變化; 應該當將所有系統將可能發生的變化以及潛在需求記錄下來, 以便將來能夠實現.     通過在建模期間的考慮這些假設的情況, 您 就可能開發出足夠強壯且容易維護的軟件.

11. 不要低估對軟件規模的需求;  internet 給我們最大的教訓是您 必須在軟件開發的最初階段就考慮軟件規模的可擴充性.

12. 性能僅僅是很多設計的因素之一. 性能不是優先級最高的因素, 必須具有可靠性,可用性, 便攜性和可擴展性.

13. 管理接口;  應在開發階段早期就定義好軟件模塊之間的接口;

14. 走近路需要更長的時間, 在軟件開發中沒有捷徑可走. 縮短你的需求分析時間, 軟件建模節省一周, 節省一天的測試時間    缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。   

在软件建模上每节省一周，在将来的编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。

    你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重

新安排一下项目计划。
    避免走捷徑, 只做一次但要做對 (do it once by do it right )

15. 別信賴任何人; 包括產品供應商,顧問和承包商, 商業味太重; 而程序員自認為比其它人更優秀.

16. 證明您的設計是在實踐中可行,

17. 應用已知的模式;

18. 研究每個模型的長處和弱處;

19. 在現有任務中應用多個模型;

20. 教育您的聽眾; 要保證團隊有一個通用的設計語言,才能真正合作, 需求建模, 用例和用戶界面模型;

21. 帶工具的傻瓜還是傻瓜; 并不是有了優秀的工具就代表你很優秀;

22. 理解完整的過程, 好的設計者需要考慮全局,從長遠考慮如何使軟件滿足用戶需要, 如何提供維護和技術支持.

23. 常做測試, 早做測試;

24. 把您的工作歸檔;

25. 技術會變, 基本原理不變;