软件生存周期及开发模型汇总课件

1、第2章 软件生存周期及开发模型 软件生存周期 问题定义 软件定义 可行性研究 需求分析 总体设计 详细设计软件生命周期 软件开发 编码 单元测试 综合测试 运行维护 持续满足用户需求软件过程 软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。工作任务里程碑、交付物SQA点 过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。公共过程框架辅助活动框架活动任务集合软件开发模型软件开发模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活

2、动、任务和开发策略。软件开发模型也常称为： 软件过程模型 软件生存周期模型 软件工程范型1.瀑布模型 (Waterfall Model) 传统的瀑布模型需求分析验证规格说明验证设计验证编码测试综合测试维护定义时期开发时期维护时期传统瀑布模型开发软件的特点1.阶段间具有顺序性和依赖性。2.推迟实现的观点。3.每个阶段必须完成规定的文档; 每个阶段结束前完成文档审查, 及早改正错误。传统瀑布模型存在什么问题？传统的瀑布模型过于理想化。事实上，人在工作过程中不可能不犯错误。在设计阶段可能发生规格说明文档中的错误。而设计上的缺陷或错误可能在实现过程中显现出来。在综合测试阶段将发现需求分析、设计或编码阶

3、段的许多错误。 实际的瀑布模型 瀑布模型的优缺点瀑布模型有许多优点：可强迫开发人员采用规范的方法（例如，结构化技术）； 严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。 实际项目很少按照该模型给出的顺序进行； 用户常常难以清楚地给出所有需求； 用户必须有耐心，等到系统开发完成； 开发者常常被不必要地耽搁。2. 原型模型 -快速原型模型 （Rapid Prototype Model） 快速建立起来的可以在计算机上 运行的程序，他所能

4、完成的功能 往往是最终产品能完成的功能的 一个子集。快速原型模型工作过程原型模型从需求收集开始。 开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。然后是“快速设计”，快速设计集中于软件那些对用户可见部分的表示。“快速设计”导致原型的建造。 原型由用户评估，并进一步精化待开发软件的需求，逐步调整原型使其满足客户的要求。同时开发者对将要做的事情有更好的理解， 这个过程是迭代的。按线性模型构建软件系统 听取用 户意见建造/修改原型用户测试运行原型快速原型验证规格说明验证设计验证编码测试综合测试维护变化的需求验证维护过程开发过程原型模型 适用情况用户定义了一组一般性目

5、标，但不能标识出详细的输入、处理及输出需求；开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式；原型模型可能是最好的选择 原型模型存在的问题用户似乎看到的是软件的工作版本，其实开发者常常需要实现上的折衷，以使原型能够尽快工作。3. 增量模型（渐增模型）(Incremental Model) 先完成一个系统子集的开发，再按同样的开发步骤增加功能 (系统子集),如此递增下去直至满足全部系统需求。 系统的总体设计在初始子集设计阶段就应作出设想。增量模型需求分析验证规格说明验证设计验证维护针对每个构件完成详细设计、编码和集成，经测试后交付给用户分析分析分析分析设计设计设计设计编码编码编码

6、编码测试测试测试测试增量1增量2 增量3增量4 交付交付交付交付增量模型的优点在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。使用增量模型的困难在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软

7、件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾。多个构件并行开发，具有无法集成的风险。4.螺旋模型(Spiral Model)产品交付给用户后用户可能不满意；到了预定的交付日期软件可能还未开发出来；实际的开发成本可能超过预算；产品完成前一些关键的开发人员 “跳槽”了；产品投入市场之前竞争对手发布 了一个功能相近、价格更低的软 件等。软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。例如：螺旋模型的基本思想使用

8、原型及其他方法来尽量降低风险。快速原型验证规格说明验证设计验证编码测试综合测试维护变化的需求验证风险分析风险分析风险分析风险分析风险分析风险分析可看作在每个阶段之前都增加了风险分析过程的快速原型模型。简化的螺旋模型图1.8 完整的螺旋模型 螺旋模型风险分析工程实施用户通信用户评估产品维护项目产品增强项目新产品开发项目概念开发项目计划建造及发布螺旋模型优点对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试或测试不足；维护和开发之间并没有本质区别。特点风险驱动主要适用于内部开发的大规模软件项目要有具有丰富风险评估专门知识的开发人员，否则风险

9、更大。5. 面向对象模型喷泉模型 (Fountain Model)可重用部件组装模型 (构件集成模型） （Component Integration Model)5. 面向对象模型喷泉模型(Fountain Model)可重用部件组装模型 (构件集成模型) (Component Integration Model) 喷泉模型分析设计实现测试集成演化喷泉模型特点 主要用于支持面向对象开发过程体现了软件创建所固有的迭代和无间隙的特征可重用部件组装模型(构件集成模型)使用重用技术的软件工程模型构件(Components)：可重用的软件成份可复用性（Reusability）集成化软件开发环境（ISEE

10、-Integrated Software Engineering Environment）可重用部件组装模型用户通信计划产品开发及发布用户评估风险分析标志候选构件查找构件若存在则提取构件若不存在则构造构件进行下一次迭代将新构件存入库中基于构件的软件工程(CBSE)过程模型 构 件 开 发分析 设计 编程 测试领域分析系统测试构件提交领域专家经验现有系统资料领域构件需求构件/构架库领域构架领域构件系统开发系统专用构件应用系统构件生产线领域构架领域构件问题域用户需求系统生产线 系 统 组 装 分析 设计 编程构架细化专 用 构 件 开 发分析 设计 编程 测试 软 件 生 产 线应用构件提取车间构

11、件生产车间标准规范 与 质量保证1基础构件，2功能构件 3接口构件，4用户界面构件 应用构件库 构件库组装车间领域 1领域 2应用系统 .12346. 形式化方法模型转换模型(Transformational Model)净室模型(Cleanroom Model)形式化规格语言及其变换技术 基于模型的规格说明及其变换技术 基于代数结构及其变换技术 基于时序逻辑的规格说明和验证技术 基于可视形式化技术转换模型形式化规格说明与需求比较后修正形式化开发记录变换n变换2变换1测试系统需求目标系统 净室模型(形式化的增量开发模型)基于思想： 力求在分析和设计阶段就消除错误，确保正确，然后在无缺陷或“洁净

12、”的状态下实现软件的制作。三个关键技术： 置于统计过程控制之下的增量开发 基于函数的规范、设计、验证 统计测试和软件认证 净 室 模 型盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量 #1盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量 #2盒结构规约需求收集形式化设计正确性验证代码检查测试计划统计性使用测试验证增量 #1.Rational 统一过程Rational统一过程（Rational Unified Process, RUP）是由Rational软件公司推出的一种完整而且完美的软件过程。RUP总结了经过多年商业化验证的6条最有效

13、的软件开发经验，这些经验被称为“最佳实践”。最佳实践迭代式开发管理需求使用基于构件的体系结构可视化建模验证软件质量控制软件变更RUP软件开发生命周期敏捷过程与极限编程敏捷软件开发宣言由下述4个简单的价值观组成。（1）个体和交互胜过过程和工具（2）可以工作的软件胜过面面俱到的文档（3）客户合作胜过合同谈判（4）响应变化胜过遵循计划极限编程极限编程（eXtreme Programming, XP）是敏捷过程中最富盛名的一个，其名称中“极限”二字的含义是指把好的开发实践运用到极致。目前，极限编程已经成为一个典型的开发方法，广泛应用于需求模糊且经常改变的场合。极限编程的有效实践客户作为开发团队的成员使用用户素材短交付周期验收测试结对编程测试驱动开发集体所有持续集成可持续的开发速度开放的工作空间及时调整计划简单的设计重构使用隐喻极限编程的整体开发过程极限编程的迭代过程综上所述，以极限编程为杰出代表的敏捷过程，具有对变化和不确定性的更快速、更敏捷的反应特性，而且在快速的同时仍然能够保持可持续的开发速度。上述这些特点使得敏捷过程能够较好地适应商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束。微软过程微软过程基本准则项目计划应该兼