《新》第1章+概述.pptVIP

* 不带反馈环的，基本上是顺序的。因为 --原型系统已通过与用户交互而得到验证。 --开发人员建立原型时已得到很多知识。 本质：快速，第一个系统常常抛弃（理想） 理想上，原型可以作为标示软件需求的一种机制。如果建立了可运行原型，开发者就可以在此基础上试图利用已有的程序片断或使用工具（报表生成器、窗口管理器等）来进快生成工作程序。 但当原型已经完成了上述目的之后，我们将如何处理它们呐？Brook 给出了一个答案： “在大多数项目中，建造的第一个系统很少是可用的。它可能太慢，太大，难以使用或三者皆有。没有其它选择，只能重新开始，虽然痛苦，但会得到更好的结果。建造一个经过重新设计的版本，解决了上述的问题……。当使用了新的系统概念或新技术时，你应该建造一个抛弃型的系统，因为即使是最好的计划也不可能是无所不知的，第一次就能完全正确。因此，管理上的问题不是你是否要建造一个指导系统，然后抛弃它，你必须这么做。唯一的问题是：是否需要事先计划好建造一个抛弃型系统，或是承诺要将抛弃型系统交付给用户。” * （1） 原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。 （2） 开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎样不去做不该做的事情”），因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。 软件产品一旦交付给用户使用之后，维护便开始了。根据所需完成的维护工作种类的不同，可能需要返回到需求分析、规格说明、设计或编码等不同阶段，如图1.4中虚线箭头所示。 * 用户似乎看到的是软件的工作版本，其实……原型只是“用口香糖和打包绳”拼凑起来的；为了使原型很快能够工作没有考虑软件的总体质量和长期的可靠性。当被告知该产品必须重建，才能使其达到高质量时，用户叫苦连天，会要求做“一些修改”，使原型成为最终的工作产品。如此，软件开发管理常常就放松了。 开发者常常需要实现上的折衷，以使原型能够尽快工作。一个不合适的操作系统或程序设计语言可能被采用，仅仅因为它是通用的和有名的；一个效率低的算法可能被使用，仅仅为了演示功能。经过一段时间之后，开发者可能对这些选择已经习惯了，忘记了他们不合适的所有原因。于是这些不理想的选择就成为了系统的组成部分。 虽然会出现问题，原型仍是软件工程的一个有效范型。关键是如何定义一开始的游戏规则，即用户和开发者两方面必须达成一致：原型被建造仅是为了定义需求，之后就该被抛弃（或至少部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。 * * —— 传统的瀑布模型 需求分析 验证 规格说明 验证 设计 验证 编码 测试 综合测试 维护 定义时期 开发时期 维护时期 传统瀑布模型开发软件的特点 1.阶段间具有顺序性和依赖性。 2.推迟实现的观点。 3.每个阶段必须完成规定的文档; 每个阶段结束前完成文档审查, 及早改正错误。 传统瀑布模型存在什么问题？ 传统的瀑布模型过于理想化。事实上，人在工作过程中不可能不犯错误。 在设计阶段可能发生规格说明文档中的错误。 而设计上的缺陷或错误可能在实现过程中显现出来。 在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。 —— 实际的瀑布模型 —— 瀑布模型的优缺点 瀑布模型有许多优点：可强迫开发人员采用规范的方法（例如，结构化技术）； 严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。 “瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。 实际项目很少按照该模型给出的顺序进行； 用户常常难以清楚地给出所有需求； 用户必须有耐心，等到系统开发完成； 开发者常常被不必要地耽搁。 2. 原型模型 ---快速原型模型 （Rapid Prototype Model） 快速建立起来的可以在计算机上 运行的程序，他所能完成的功能 往往是最终产品能完成的功能的 一个子集。 快速原型模型工作过程 原型模型从需求收集开始。 开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。 然后是“快速设计”，快速设计集中于软件那些对用户可见部分的表示。“快速设计”导致原型的建造。 原型由用户评估，并进一步精化待开发软件的需求，逐步调整原型使其满足客户的要求。同时开发者对将要做的事情有更好的理解， 这个过程是迭代的。 按线性模型构建软件系统 听取用 户意见 建造/修改原型 用户测试 运行原型 快速原型 验证