两种原型：一次性 ( throwaway ) 原型、演进式 ( evolutionary ) 原型

* 一次性原型用“快速”而“粗糙”的方式构建，交给客户用以得到反馈，在得到期待的信息后即被废弃；
  得到的信息被整理进需求规格说明，用于正规产品的开发。
  
* 演进式原型用高质量的方式构建，交给用户用以获得反馈，获得期待的信息便开始进行修改，以更加贴近客户的需求。
  重复此过程，直到产品收敛到所期望的样子。
  
  
> 使用原则
* 一次性原则适合关键需求特性没有被很好理解时使用；

* 演进式原则在关键性原则被充分理解，但其他需求特性没被充分理解时使用。如果对大多数功能都不了解，则应先构建一次性原型，从零开始构建演进式模型。

Davis, A., "Operational Prototyping: A New Development Approach," IEEE Software, 9, 5 (September 1992), pp. 70-78.

Fred Brooks 建议：无论如何，你一定要做好抛弃的准备。

* 一个被完整部署的系统，往往是第二个被创建的系统，第一个系统被用来验证关键的设计问题和操作概念（≈25%的资源）。

> 2个原则
* 全新产品：开发人员要规划开发一系列 “一次性原则”（原则 11、12、13）;
* 商业产品：可预期第一个版本的产品在一定年限内被维护，之后将被完全替换（原则185、186、188、201）。

* 在程序变得不可维护而替换之前，对程序可以调整的地方还有很多（原则186、191、195、197）。

Royce, W., "Managing the Development of large Software System," WESCON 70, 1970; reprinted in 9th International Conference on Software Engineering, Washington D.C.: IEEE Computer Society Press, 1987, pp. 328-338.

项目经常会因为客户与开发人员的目标不同（或不兼容）而失效。

> 博弈
* 开发人员为了最大化营收，会尝试完整开发所有特性，即使会导致项目延期；

* 客户愿意放弃其中的部分功能，希望能按时交付其他特性。


> 双方达成一致目标
* 按优先级对需求排序（原则50），以便开发人员了解他们的相对重要性；

* 根据需求的优先级奖励开发人员（高、中、低优先级）；

* 对逾期交付实行处罚机制。

永远不要忽视开发软件的原因：满足真正的需求、解决真正的问题。

* 解决需求问题的唯一方法，是跟有真正需求的人沟通：客户 / 用户。

* 紧跟外部环境变化的唯一方法：沟通。

* 忽视外部环境变化的短期会让生活看起来更容易，但最终会导致系统将无法使用。

Farbman, D., "Myths That Miss", Datamation(November 1980), pp.109-112.

在需求阶段，无论你多么努力地试图去了解客户的需求，都不如给他们一个产品，这是确定他们真实需求的最有效方法。

* 瀑布式开发模型，将在99%资源耗尽后，才向客户第一次交付，这样大部分的客户反馈发生在资源耗尽后。

* 尽早将原型交予客户，收集反馈，此时只耗费5%-20%的资源，这样确保将剩余资源用于开发正确的系统。

Gomaa, H., and D. Scott, "Prototyping as a Tool in the Specification of User Requirements," Fifth International Conference on Software Enginneering, Washington, D.C.: IEEE Computer Society Press, 1981, pp. 333-342.

系统的低可靠性问题可能会在系统上线多年后才暴露出来 — 甚至可能造成人员伤害。

* 软件执行效率不高，可以通过分离消耗时间的执行单元，重构代码来提高效率（原则194）。
* 低可靠性代码难以发现，而且难以修复。
* 低可靠性问题显现，通常难以隔离其影响。

Sommerville, I., Software Eginnering, Reading, Mass: Addsion Wesley, 1992, Session 20.0.

质量无法通过软件的改进来获得

* 上面👆对于质量的可维护性、可靠性、适应性、可测试性、安全性等，都适用。
* 不能将“一次性原型”的代码转换为最终产品的代码。

Floyd C., "A Systematic Look at Prototyping". in Approaches to Prototyping, R. Buddle, et al., Berlin, Germany: Springer Verlag, 1983, pp. 1-18, Session 3.1.

IBM为NASA开发的机载软件，约300W行代码，产品发布后每万行代码中发现的错误少于一个。

* 大型软件可以以非常高的质量构建，但价格昂贵。
* 提高软件质量的方法：
    * 让客户参与（原则8）
    * 原型设计，在开发前验证需求（原则11 - 13）
    * 保持设计简单（原则67）
    * 审查代码（原则98）
    * 雇佣最优秀的人（原则130、131）
* 追求高质量软件的同时，需要意识到随之而来的高成本。

Joyce, E., "Is Error-Free Software Achievable?" Datamation(February 15, 1989).

贝尔实验室发现：要求 1 - 2 bug / KLOC（千行代码），那么每个人一个月的效率通常为 150 - 300 行代码。

ref: [Fleckenstein, W., “Challenges in Software Development”, IEEE Computer, 16, 3 (March 1983), pp. 60-64]

* 开发效率与质量之间存在明显的关系。

* 质量要求越高，开发效率越低；质量要求越低，开发效率越高。

Lehman, M., "Programming Productivity - A Life Cycle Concept", COMPCON 81, Washington, D.C.: IEEE Computer Society Press, 1981, Session 1.1.

温伯格 “政治困境” 原则：当优化某人关注的质量时，肯能会影响其他人关注的质量。

* 软件质量没有唯一的定义。

* 质量可能是优雅设计的代码；可能是响应时间或高吞吐量；可能是低开发成本。

* 项目需确定各因素的优先级，同时传达给所有相关方。

Weinberg, G., Quality Software Management, Vol. 1: Systems Thinking, New York: Dorset House, 1992, Section 1.2.