最佳的软件开发方法，是在整个开发生命周期中使用不同的表达方法：
方框图、电路图、逻辑图、时序图、状态转换图、柱状图、伪代码等。
* 使用越多的符号、越丰富多样的表达方法，越能对开发中的产品进行可视化。
> 对于需求工程
* 选择一组最优的技术和语言。（原则47、48）
> 对于设计工作
* 选择一组最优的技术和语言。（原则63、81）
> 对于编码
* 选择一种最合适的语言。（原则102、103）
* 由于在不同阶段之间转换时困难的，所以使用同一种语言不一定有帮助。
* 如果一种语言在开发的不同阶段都是最优选择，则务必使用它。
Matsubara, T., "Bringing up Software Designers", American Programmer, 3, 7 (July-August 1990), 00, 15-18.
系统运行的环境在本质上是无限的，不可能被完全理解。当我们开发一个系统，宣称要解决某个环境中的一个问题时，我们会对该环境进行假设。
* 对需求工程、设计、编码、和测试期间所做的所有假设，始终保持察觉是不可能的。
* 对有意识作出的假设做个记录。（可能假设不切实际）
* 记录上述假设的影响。通常封装每个假设可以隔离上述假设的影响。（原则65）
Lehman, M., "Software Engineering, the Software Process and Their Support", Software Engineering Journal, 6, 5(Sept. 1991), pp. 243-258, Section 3.6.
每个复杂的问题，都有一个简单的解决方案。这是错误的。Wlad Turski.
* 高度怀疑：“只要遵循这10个简单步骤，软件质量问题就会消失。”
Turski, W., oral comments made at a conference in the late 1970s.
衡量软件系统质量的一种方法是查看其用户手册内容的多少。设计良好的软件，用法应该不言而喻。
* 对于界面，使用标准的界面，让行业专家设计浅显易懂的图标、命令、协议和用户场景。
* 通常，用户需要简单、干净、清晰的用户界面，而不是软件开发人员眼中的各种技巧。
Hoare, C.A.R., "Programing Sorcery or Science?" IEEE Software, 1,2 (April 1984), pp. 14-15.
要降低不断上涨的软件开发成本和风险，最有效的办法是购买而非自己从头开发。
* 从头开发的软件，可能会冒着超出预算 100% 和 延期 的风险，且最终可能只完成了75%的预期。
* 不断增加的成本通常会导致需求缩减，最终的实现可能跟已有的软件差不多。
* 作为开发者，应当复用尽可能多的软件（参考原则84）。
Brooks, F., "No Silver Bullet: Essence and Accidents of Software Engineering", IEEE Computer, 20, 4 (April 1987), pp. 10-19.
系统工程的第一定律：无论你处在系统开发生命周期的何处，系统都将发生变化，并且对其进行改变的愿望将在整个生命周期中持续存在。
By Edward Bersoff
* 在开发过程中，软件也可能发生巨大变化：新的代码、测试、需求规格说明。
> 应对变化要确保
* 软件开发设计的所有产品之间的相互饮用都适当（原则43、62、107）；
* 变更管理流程已就位（原则174、178-183）；
* 预算和开发时间有充足的余地，不会为了满足预算和开发时间而忽略必要的变更（原则147、148、160）。
Bersoff, E., V. Henderson, and S. Siegel, Software Configuration Management, Englewood Cliffs, N.J.: Prentice Hall, 1980, Section 2.2.
提供给用户的功能 / 性能越多，用户想要的功能 / 性能越多。一旦用户看到产品，他们就会想要更多的东西。
* 必须要为不可避免的情况做好准备。
* 期间产生的每个文档都朝着有利于更改的方式进行存储和组织。
Curis, B., H. Krasner, and H. Iscoe, "A Field Study of the Software Design Process for Large Systems", Communications of the ACM, 31, 11 (November 1988), pp. 1268-1287.
渐进地扩展系统，是降低软件开发风险最有效的方法之一。
> 优点
* 降低每次开发的风险；
* 看到一个产品版本，通常可以帮助用户想象出他们想要的其他功能。
> 缺点
* 如果过早选用了不合适的系统架构，可能需要重构才能适应后续的需求变更；
* 在开始增量开发之前，开发一次性原型（原则11、12、13），可以降低这种风险。
Mills, H., "Top-Down Programming in Large Systems", in Debugging Techniques in Large Systems, R. Ruskin, ed., Englewood Cliffs, N.J.: Prentice Hall, 1971.
如果你已经决定开发一次性原型，那么就要用最快的方式。
* 使用“一页纸”的需求规格说明。
* 不用担心设计或编码中的文档。
* 使用任何工具。
* 使用任何编程语言。
* 不用担心编程语言的可维护性。
Andriole, S., Rapid Application Prototyping, Wellesley, Mass.: QED, 1992.
如果基于模糊需求构建了“演进式原型”，一旦需求错了，你将不得不抛弃这个“高质量”软件，从而浪费了资源。
* 构建一次性原型，只开发没有被充分理解的特性。
* 构建演进式原型时，要优先构建已经被充分理解的特性（充分理解，或用一次性原则进行过验证）。
Davis A., "Operational Prototyping: A New Development Approach", IEEE Software, 9,5 (Sep. 1992), pp. 70-78.