接上文，北京北大青鸟学校学术部提供
14. 合理安排项目计划
在软件开发中没有捷径可以走。缩短你的在需求分析上花的时间，结果只能是开发出来的软件不能满足用户的需求，必须被重写。在软件建模上每节省一周，在将来的编码阶段可能会多花几周时间，因为你在全面思考之前就动手写程序。你为了节省一天的测试时间而漏掉了一个bug，在将来的维护阶段，可能需要花几周甚至几个月的时间去修复。与其如此，还不如重新安排一下项目计划。
15. 别信赖任何人
大部分程序员认为他们自己比其他人更优秀，他们可能抛弃你设计的模型而用自己认为更好的。 只有良好的沟通才能解决这些问题。要明确的是，不要只依靠一家产品或服务提供商，即使你的公司（或组织）已经在建模、文档和过程等方面向那个公司投入了很多钱。
16. 证明你的设计在实践中可行
在设计的时候应当先建立一个技术原型， 或者称为“端到端”原型。以证明你的设计是能够工作的。你应该在开发工作的早期做这些事情，因为，如果软件的设计方案是不可行的，在编码实现阶段无论采取什么措施都于事无补。技术原型将证明你的设计的可行性，从而，你的设计将更容易获得支持。
17. 应用已知的模式
目前，我们有大量现成的分析和设计模式以及问题的解决方案可以使用。一般来说，好的模型设计和开发人员，都会避免重新设计已经成熟的并被广泛应用的东西。
北京北大青鸟学校建议大家多看看这个网站：http://www.ambysoft.com/processPatternsPage.html 收藏了许多开发模式的信息。
18. 研究每个模型的长处和弱点
目前有很多种类的模型可以使用。用例捕获的是系统行为需求，数据模型则描述支持一个系统运行所需要的数据构成。你可能会试图在用例中加入实际数据描述，但是，这对开发者不是非常有用。同样，数据模型对描述软件需求来说是无用的。每个模型在你建模过程中有其相应的位置，但是，你需要明白在什么地方，什么时候使用它们。
19. 在现有任务中应用多个模型
当你收集需求的时候，考虑使用用例模型，用户界面模型和领域级的类模型。当你设计软件的时候，应该考虑制作类模型，顺序图、状态图、协作图和最终的软件实际物理模型。程序设计人员应该慢慢意识到，仅仅使用一个模型而实现的软件要么不能够很好地满足用户的需求，要么很难扩展。
20. 教育你的听众
教给你开发人员基本的建模知识；否则，他们会只看看你画的漂亮图表，然后继续编写不规范的程序。另外， 你还需要告诉你的用户一些需求建模的基础知识。给他们解释你的用例(uses case)和用户界面模型，以使他们能够明白你要表达地东西。当每个人都能使用一个通用的设计语言的时候（比如UML-译者注），你的团队才能实现真正的合作。 （北京北大青鸟学校，未完）
