软件开发模型.docx

精品文档1. 瀑布模型（Waterfall Model） 瀑布模型有以下优点： 1）为项目提供了按阶段划分的检查点。 2）当前一阶段完成后，您只需要去关注后续阶段。 3）可在迭代模型中应用瀑布模型。 瀑布模型有以下缺点： 1）在项目各个阶段之间极少有反馈。 2）只有在项目生命周期的后期才能看到结果。 3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。2. 快速原型模型Rapid Prototype Model） 快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。 显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。 快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。 3. 增量模型（Incremental Model） 存在以下缺陷： 1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。 2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。4. 螺旋模型（Spiral Model）: 将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。5. 演化模型(incremental model) 主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。 实际上，这个模型可看作是重复执行的多个“瀑布模型”。 “演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。6. 喷泉模型（fountain model, (面向对象的生存期模型, OO模型)） 喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。 喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。 喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。1、喷泉模型的优点 喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。 2、喷泉模型的缺点 由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。7. 智能模型(四代技术（4GL）)智能模型拥有一组工具（如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功能及电子表格等），每个工具都能使开发人员在高层次上定义软件的某些特性，并把开发人员定义的这些软件自动地生成为源代码。这种方法需要四代语言（4GL）的支持。4GL不同于三代语言，其主要特征是用户界面极端友好，即使没有受过训练的非专业程序员，也能用它编写程序；它是一种声明式、交互式和非过程性编程语言。4GL还具有高效的程序代码、智能缺省假设、完备的数据库和应用程序生成器。目前市场上流行的4GL（如FoXPro等）都不同程度地具有上述特征。但4GL目前主要限于事务信息系统的中、小型应用程序的开发。 8. 混合模型（hybrid model）过程开发模型又叫混合模型（hybrid model），或元模型（meta-model）,把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）。实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。 瀑布模型 文档驱动 系统可能不满足客户的需求 快速原型模型 关注满足客户需求 可能导致系统设计差、效率低，难于维护 增量模型 开发早期反馈及时，易于维护 需要开放式体系结构，可能会设计差、效率低 螺旋模型 风险驱动 风险分析人员需要有经验且经过充分训练软件工程的“迭代式开发”已经逐渐取代“瀑布式开发”成为主流。所谓“迭代式开发”，根据我的理解说白了就是象爱因斯坦那样做小板凳，终极的理想板凳就是不断修正前面板凳错误的后一个板凳，“最好的是下一个”。“迭代式开发”与“瀑布式开发”存在本质的不同，传统“瀑布式开发”的出发点是务求各个开发阶段的成果都是最优成果，无需变更。而“迭代式开发”则是假设各个阶段的成果都有优化、变更的余地。我们采取了“迭代式开发”，当前工作围绕的核心是如何使未来的变更、优化变得容易。应用“迭代式开发”，公司的产品战略是可以通过N次迭代实现，问题是资本的耐心常常是有限的，产品经过趋向于无穷大的N次迭代肯定会日臻完美，但我们必须使资本在每次迭代中看到利润。换句话说，产品的开发必须结合商业成功的良性循环中。在先启阶段的最初迭代中，由构思新项目开始项目管理工作流程，其间，将创建并复审最初的前景、商业理由和风险列表工件。目标是获得足够的资金，以便继续进行限定规模和计划等重要工作。创建了软件开发计划初稿，并通过最初的迭代计划启动项目。使用这个最初的授权，可以继续针对评估项目规模和风险中的前景、风险列表和商业理由进行工作，以便为充实制定软件开发计划中的软件开发计划建立稳固的基础。在完成软件开发计划的制定后，应当对项目的风险和可能的商业回报有足够的了解，以便作出明智的决定，为先启阶段的其余部分争取资金，或放弃该项目。在这里，项目管理工作流程将合并到所有后续迭代的公用流程。在计划下一次迭代中，项目经理和构架设计师决定在下一次迭代中要改进或实现的需求。在早期的迭代中，重点是发现和改进需求；而在后期的迭代中，重点是构建软件来实现这些需求。 迭代计划在管理迭代中执行，管理迭代最后以对迭代的评估和复审而结束，判断是否已经实现了迭代的目标。如果迭代明显无法达到目标，并且已断定在随后的迭代中无法恢复项目，则可以通过迭代验收复审来判断是否应当终止项目。另一种选择是，可以在迭代的中点附近进行迭代评估标准复审，对迭代测试计划进行复审，这时，测试计划应当是明确的。通常，这种可选的复审只用于长期（六个月或更长）迭代。它使项目管理人员和其他涉众有机会进行中期更正。在进行管理迭代的同时，将在监控项目中执行每天、每周和每月的例行项目管理任务，其间，将监测项目的状态，并在出现问题和错误时进行处理。当某个阶段的最后迭代完成时，作为阶段收尾的一部分，将进行主要里程碑复审，并假定项目将继续进行，对下一个阶段作出计划。在项目结束时，作为项目收尾的一部分，将进行项目验收复审并终止项目，除非复审确定所交付的产品不可接受，这种情况下，