迭代增量开发.pdf

迭代增量开发迭代增量开发 迭代增量开发迭代增量开发 Iterative and Incremental Development (第一讲) 在1970年Winston Royce博士发表了一篇名为 “Managing the Development of Large Software Systems”的论文。这篇论文发表在 Proceedings of IEEE WESCON 的 1-9 页。这篇论文被公认为是软件开发瀑布模型的鼻祖，但是 Royce 的思想是被以某种扭曲了的方式认同的。一些软件项目的管理者对Royce的话断 章取义，捏造并传播了这样的一种思想：软件在设计之前是可以被完整地分析的软件在设计之前是可以被完整地分析的，， 软件在设计之前是可以被完整地分析的软件在设计之前是可以被完整地分析的，， 在编码之前是可以完整地被设计的和在测试之前是可以被完整地编码的在编码之前是可以完整地被设计的和在测试之前是可以被完整地编码的——这 在编码之前是可以完整地被设计的和在测试之前是可以被完整地编码的在编码之前是可以完整地被设计的和在测试之前是可以被完整地编码的 就是瀑布模型。假如Royce博士还在世的话，我想他会对瀑布模型对软件开发产 生了如此深远的影响感到吃惊，同时也会对他的思想被歪曲感到愤怒。 并不奇怪，甚至今天我们还能听见管理人员斥责开发人员在编码阶段还在作 设计。管理人员希望能够通过在进度表上的设计阶段处画一个X来表示设计阶段 的结束，以控制项目的进度。Royce的论文实际上描述了我们今天称为迭代增量迭代增量 迭代增量迭代增量 式的开发风格式 。在他的论文中他描述了分析是如何被设计中的问题所约束的，设 式式 计中的问题是如何反馈到分析中，以及编码中的问题是如何反馈到设计中的。他 还描述了增量式地逐渐发布一个项目的过程，在每个增量中，都有这个版本自己 的分析、设计、编码和测试活动。 在下面几讲中，我们将概要介绍迭代增量开发的一些基本知识。首先，我们 先了解一下瀑布模型及它的一些缺陷，然后我们介绍迭代增量开发过程(IIDP) 和它是如何解决瀑布模型的缺陷的。 瀑布模型瀑布模型 （（Waterfall ）） 瀑布模型瀑布模型 （（ ）） 以下是一个故事，情节纯属虚构，请勿对入座。 任务： A 君：某软件公司的项目经理 B 君：A 君的直接上司，某软件公司的软件部经理 BB 君：B 君的直接上司，某软件公司的总经理 日期是某年1 月 2 日，A 君坐在一间会议室中，在座的还有几个公司的高级 主管和一群和 A 君一样的项目经理，B 君也在。此次会议是BB 君召集的。 “我们有一个新项目需要开发。”BB 君说。接着 BB 简要描述了公司对市 场的分析和对要开发的产品的简单想法。 “我们必须在10 月 1 日之前将产品投放市场，”BB 这样要求，“A 君，你 们需要多长时间进行系统分析？” A 君说：“先生，我们现在对需求一无所知，无法告诉您系统分析需要花多 长时间。” “需求文档准备好还需要3 到 4 个星期，” BB 说，“现在假设需求文档就 摆在你面前，进行分析需要多长时间？” A 君没有吱声。 “如果分析的时间超过了4 月 1 日，那么我们就有麻烦了。A 君，你们能在 4 月 1 日前完成分析工作吗？” BB 继续问。 B 君硬着头皮说：“我们会找到办法的！” A 君顿感脑袋发大。 “很好，”BB 微笑着说，“现在，再说说设计需要多少时间？” “先生，”A 君说，“没有分析，我们无法判断设计需要多少时间。” BB 的表情变的严厉了，“假设假设，A 君你已经有了分析，”他说，同时紧盯 假设假设 着 A 君，“设计需要多少时间？” B 君犹豫着说：“先生，完成项目只剩仅仅6 个月