9. 考虑软件的移植性

　　移植是软件开发中一项具体而又实际的工作，不要相信某些软件工具的广告宣传（比如java 的宣传口号write&nbsponce&nbsprun&nbspmany ? 译者注）。

　　即使仅仅对软件进行常规升级，也要把这看得和向另一个操作系统或数据库移植一样重要。

　　记得从16位Windows移植到32位windows的“乐趣”吗 ？当你使用了某个操作系统的特性，如它的进程间通信(IPC)策略，或用某数据库专有语言写了存储过程。你的软件和那个特定的产品结合度已经很高了。

　　好的软件设计者把那些特有的实现细节打包隐藏起来，所以，当那些特性该变的时候，你的仅仅需要更新那个包可以了。

　　10. 接受变化

　　这是一句老话了：不变的只有变化。

　　你应该将所有系统将可能发生的变化以及潜在需求记录下来，以便将来能够实现（参见“Architecting&nbspfor& nbspChange”，Thinking&nbspObjectively，&nbspMay&nbsp1999）

　　通过在建模期间考虑这些假设的情况，你有可能开发出足够强壮且容易维护的软件。设计强壮的软件是你基本的目标。

　　11. 不要低估对软件规模的需求

　　Internet 带给我们的大的教训是你必须在软件开发的初阶段考虑软件规模的可扩充性。

　　只有100人的部门使用的应用程序，明天可能会被有好几万人的组织使用，下月，通过因特网可能会有几百万人使用它。

　　在软件设计的初期，根据在用例模型中定义的必须支持的基本事务处理，确定软件的基本功能。然后，在建造系统的时候再逐步加入比较常用的功能。

　　在设计的开始考虑软件的规模需求，避免在用户群突然增大的情况下，重写软件。

　　12. 性能仅仅是很多设计因素之一

　　关注软件设计中的一个重要因素--性能，这好象也是用户关心的事情。一个性能不佳的软件将不可避免被重写。

　　但是你的设计还必须具有可靠性，可用性，便携性和可扩展性。你应该在工程开始应该定义并区分好这些因素，以便在工作中恰当使用。性能可以是，也可以不是优先级高的因素，我的观点是，给每个设计因素应有的考虑。

　　13. 管理接口

　　“UML&nbspUser&nbspGuide”（Grady&nbspBooch，Ivar& nbspJacobson和Jim&nbspRumbaugh ，Addison&nbspWesley，&nbsp1999）中指出，你应该在开发阶段的早期定义软件模块之间的接口。

　　这有助于你的开发人员全面理解软件的设计结构并取得一致意见，让各模块开发小组相对独立的工作。一旦模块的接口确定之后，模块怎样实现不是很重要了。

　　从根本上说，如果你不能够定义你的模块“从外部看上去会是什么样子”，你肯定也不清楚模块内要实现什么。

　　14. 走近路需要更长的时间

　　在软件开发中没有捷径可以走。

　　缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。

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

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

　　避免走捷径，只做一次但要做对（do&nbspit&nbsponce&nbspby&nbspdoing&nbspit&nbspright）。

　　15. 别信赖任何人

　　产品和服务销售公司不是你的朋友，你的大部分员工和高层管理人员也不是。

　　大部分产品供应商希望把你牢牢绑在他们的产品上，可能是操作系统，数据库或者某个开发工具。

　　大部分的顾问和承包商只关心你的钱并不是你的工程（停止向他们付款，看一看他们会在周围呆多长时间）。

　　大部分程序员认为他们自己比其他人更，他们可能抛弃你设计的模型而用自己认为更好的。

　　只有良好的沟通才能解决这些问题。

　　要明确的是，不要只依靠一家产品或服务提供商，即使你的公司（或组织）已经在建模、文档和过程等方面向那个公司投入了很多钱。