用原型、模型和概要来提高程序设计水平

为了消除这种后果，一些读者提倡使用drawings或screen paintings去估计系统体系和行为。另外还有一些人建议使用小容量的模型。这样就产生一个问题，究竟哪一种方法最好，即用哪一种方法可以获得最多的回报。

所有这些方法在软件设计过程中都是很重要的——虽然它们侧重的重点不同。事实上，我更倾向于在同一个项目中同时使用上述三种方法。

在设计软件的过程中，有许多方法。开发者倾向于使用符合自己个性的方法，除非他们被逼无奈。我习惯用瀑布法。在我被培养起来开发程序的早期，我是在Tandy TRS－80上联合使用COBOL和BASIC的，从那时起我就开始喜欢自上向下、结构化的编程方法。不要理解错了，我偶尔也大胆地用面向对象法或最优编程法试验。然而，我经常用一种老的，顺序的方法草拟项目开发计划（这也许是我在软件开发上的一个弱点）。无论如何，这就是我与使用原型、模型和概要的目标不同之处。

评估风险和技术可行性

当使用瀑布法时，我通常用原型来仔细研究风险的程度并试验新技术。原型是作为概念性验证的工具被加以发展的，它同时也是一种有效的风险评估工具。如果一个开发小组不能胜任小规模的工程，那么在大规模工程中很难获得成功。原型最初是用来评估风险并检测技术可行性的工具。用这种态度对待原型就会消除使用该方法的许多缺点。举例来说，使用原型的一个缺点是它趋于使关键技术推迟到工程后期才开始实现。如果你把原型作为一个切实可行的学习过程，那么关键技术可以提前实现。

我曾涉及设计一个系统设计，该系统最终将变得很大。用户需要一个该工程的简化版——用于概念验证，如果你愿意做，这只需花很短的一段时间。技术上的挑战之一就是要在网络界面的基础上处理多个PDA。该原型包括一个数据库、一个网络服务器和为了加速PDA间数据交换及用于数据库引擎的软件/硬件。原型开发时重点放在网络基础上的PDA界面，根据风险和技术复杂度来评估该项目。原型真正的目的是：鉴别风险、评估可行性。

交流是关键

我用概要和模型来帮助定义商业规则、建立功能要求；有时仅仅用它来帮助从用户的角度来理解工程。我不常用概要。在早些时候，我常常用我自己的观点来组织系统——即，我看待软件的功能大多仅仅建立在我能实现的功能上。这在整个80年代中期的CMM一级开发中很典型。

在工程结束时，客户得到的系统包有许多“特性”，我认为这些特性是很不错的。但是从用户来看，该系统有许多没用的花哨的功能，很笨重并且难以使用。概要消除了许多缺点，特别是精简了商业规则并建立了GUI（图形用户界面）的模式。“请给我一个规划，好吗？”是我的特色中的一部分；我在每一个工程的开始阶段都一直这么强调。

建立系统说明书

原型和模型常常同步使用，但不能在此水平上更进一度。原型是可以工作的系统，在较小规模上展示核心功能。与此相反，模型仅仅是显示系统中的各个模块，这种显示是没有固有功能的。我把软件模型比作一个组装模型车，它的每一块都有，但是模型没有真正的功能——比方说，它的喇叭不会叫。它仅仅是把实物按比例缩小的表示。我喜欢为整个系统建立一个纸上模型用以确信软件功能已被详细分解说明了。一旦用户认可该“模型”，开发小组将开始行动。

让它为你工作

为了简单说明，我用概要去定义商业过程、建立商业规则并检查这两者的同一性和关系。用模型来检查我是否正确理解要求并拥有有效的蓝本。一旦获得纸上模型，用screen painting来确保我理解用户的要求。最后，系统原型主要用于核心功能，用它来确保我设计出核心功能并估计技术风险。当所有的准备工作都做好之后，确定系统却是可以顺利完成，我就可以放心大胆的投入系统实现中了。