1、性能仅仅是很多设计因素之一
    关注软件设计中的一个重要因素--性能，这好象也是用户最关心的事情。一个性能不佳的软件将不可避免被重写。
但是你的设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始就应该定义并区分好这些因素，以便在工作中恰当使用。性能可以是，也可以不是优先级最高的因素，我的观点是，给每个设计因素应有的考虑。
2、不要低估对软件规模的需求
Internet 带给我们的最大的教训是你必须在软件开发的最初阶段就考虑软件规模的可扩充性。今天只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。
在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，确定软件的基本功能。然后，在建造系统的时候再逐步加入比较常用的功能。在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。
3、管理接口
你应该在开发阶段的早期就定义软件模块之间的接口。这有助于你的开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工作。一旦模块的接口确定之后，模块怎样实现就不是很重要了。从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。
4、走近路需要更长的时间
在软件开发中没有捷径可以走。缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。在软件建模上每节省一周，在将来的编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重新安排一下项目计划。避免走捷径，只做一次但要做对。
5、不要信赖任何人
产品和服务销售公司不是你的朋友，你的大部分员工和高层管理人员也不是。大部分产品供应商希望把你牢牢绑在他们的产品上，可能是操作系统，数据库或者某个开发工具。
大部分的顾问和承包商只关心你的钱并不是你的工程。大部分程序员认为他们自己比其他人更优秀，他们可能抛弃你设计的模型而用自己认为更好的。只有良好的沟通才能解决这些问题。要明确的是，不要只依靠一家产品或服务提供商，即使你的公司（或组织）已经在建模、文档和过程等方面向那个公司投入了很多钱。
6、证明你的设计在实践中可行
在设计的时候应当先建立一个技术原型， 或者称为“端到端”原型。以证明你的设计是能够工作的。你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。
7、教育你的听众
你花了很大力气建立一个很成熟的系统模型，而你的听众却不能理解它们，甚至更糟－连为什么要先建立模型都不知道。那么你的工作是毫无意义的。
教给你开发人员基本的建模知识；否则，他们会只看看你画的漂亮图表，然后继续编写不规范的程序。另外， 你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候，你的团队才能实现真正的合作。
8、应用已知的模式
目前，我们有大量现成的分析和设计模式以及问题的解决方案可以使用。一般来说，好的模型设计和开发人员，都会避免重新设计已经成熟的并被广泛应用的东西。 
9、研究每个模型的长处和弱点
目前有很多种类的模型可以使用,用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加 入实际数据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用的。每个模型在你建模过程中有其相应的位置，但是，你需要明白在什么地方，什么时候使用它们。
10、在现有任务中应用多个模型
当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。
程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。
11、带工具的傻瓜还是傻瓜
你给我CAD/CAM工具，请我设计一座桥。但是，如果那座桥建成的话，我肯定不想当第一个从桥上过的人，因为我对建筑一窍不通。使用一个很优秀的CASE工具并不能使你成为一个建模专家，只能使你成为一个优秀CASE工具的使用者。成为一个优秀的建模专家需要多年的积累，不 会是一周针对某个价值几千美元工具的培训。一个优秀的CASE工具是很重要，但你必须学习使用它，并能够使用它设计它支持的模型。
12、理解完整的过程
好的设计人员应该理解整个软件过程，尽管他们可能不是精通全部实现细节。开发是一个很复杂的过程，除了编程、建模、测试等你擅长工作外，还有很多工作要做。好的设计者需要考虑全局。必须从长远考虑如何使软件满足用户需要，如何提供维护和技术支持等。
13、技术会变，基本原理不会
如果有人说“使用某种开发语言、某个工具或某某技术，我们就不需要再做需求分析，建模，编码或测试”。不要相信，这只说明他还缺乏经验。抛开技术和 人的因素，实际上软件开发的基本原理自20世纪70年代以来就没有改变过。你必须还定义需求，建模，编码，测试，配置，面对风险，发布产品，管理工作人员 等等。软件建模技术是需要多年的实际工作才能完全掌握的。好在你可以从我的建议开始，完善你们自己的软件开发经验。
14、常做测试，早做测试
如果测试对你的软件来说是无所谓的，那么你的软件多半也没什么必要被开发出来。建立一个技术原型供技术评审使用，以检验你的软件模型。在软件生命周期中，越晚发现的错误越难修改，修改成本越昂贵。尽可能早的做测试是很值得的。
15、把你的工作归档
不值得归档的工作往往也不值得做。归档你的设想，以及根据设想做出的决定；归档软件模型中很重要但不很明显的部分。 给每个模型一些概要描述以使别人很快明白模型所表达的内容。