软件工程课件-03软件过程与生命周期模型.pptVIP

软件生命周期模型 软件过程与生命周期模型 建造修补模型 瀑布模型 快速原型 极限编程 同步--稳定模型 螺旋模型 面向对象的生命周期模型 软件过程与生命周期模型 软件产品发展过程中的一系列步骤称为“生命周期模型”（life-cycle model），主要的模型有：瀑布模型、快速原型开发模型、螺旋模型等 生命周期模型规定了软件过程的各个阶段，如需求、规格说明、设计、实现、集成和维护阶段，以及这些阶段完成的顺序 每一种模型的主要内容、优点、缺点 建造—修补模型 构建产品不使用规格说明、或者不进行设计；开发者只是简单地建造了一个软件产品，为满足客户的要求，多次改写该软件 建造—修补模型(续) 优点：对于100行或200行的短程序可以做得很好 缺点：对于任何规模的软件产品来说，建造—修补模型的缺点有： (1) 对没有规格说明和设计文档的产品进行维护相当困难，而且发生回归错误的机会也相当大。 (2) 从整个软件过程来说（特别是考虑到维护阶段），实际上建造—修补模型的花费远远大于有正规的规格说明、经过详细设计的产品所需要的花费 瀑布模型 Royce于1970年提出 各阶段工作及发现错误回溯 关键点是：在该阶段的文档已经完成并且该阶段的产品得到SQA小组的认可之前，没有一个阶段是完整的，这将导致反复修改 瀑布模型(续) 当产品移交给客户后，对产品的修改和加强都构成了维护，维护可能修改从需求开始的所有阶段的文档，瀑布模型是一个动态的模型，反馈环在这个动态过程中起着重要的作用 文档的维护必须和代码的维护同步 瀑布模型(续) 优点 (1)强制性原则：阶段产品与文档确认之前不进入下一个阶段 （2)文档驱动：文档与产品的同步，维护的重要依据，许多瀑布模型的成功归功于它本质上是一个文档驱动的模型 瀑布模型(续) 缺点 由文档驱动原则引起，客户只能在整个产品完成编程之后才首次能够看到工作的产品，说明文档的描述所理解的产品与实际的产品有很大的差距，规格说明文档只存在于纸面上，客户因而不能真正理解产品本身会是什么样子。 举例：建筑合同与裁缝方式 快速原型开发模型 快速原型是一个与产品子集功能相同的工作模型。建立快速原型的第一步是建造一个快速原型，并让客户和未来的用户试用该原型，直到客户认为快速原型确实满足了大多数要求为止 快速原型开发模型（续） 优点： （1）产品的开发从快速原型到交付的产品基本上是线性的 （2）开发进度快 缺点：没有经过长时间验证 快速原型和瀑布模型结合，快速原型可以用作需求分析技术 增量模型 软件在工程上渐增实现，产品以一系列增量构件的形式设计、实现、集成和测试，每个构件（builds）由一些代码块组成，这些代码块来自多个相互作用的模块，完成特定的功能 在增量模型的每一个阶段，编写出一个新的构件的代码后，集成到结构中，作为一个整体进行测试，当产品达到功能目标时，即满足了规格说明进，这个进程停止 增量模型（续） 开发者可以将目标产品分成构件，只是必须服从以下约束： 由于每个构件都集成到目前的软件中，生成的产品必须是可测试的。如果将产品分成太少的构件，则增量模型退化成建造—修补模型；相反，如果产品由太多的构件组成，则在每个阶段将在大量的时间花费在少量增加功能的集成测试上 增量模型（续） 优点： （1）增量模型在每个阶段交付一个可用的产品，从第一个构件交付开始，客户即可开始工作（瀑布模型最后一次性交付） （2）减少一个全新产品对客户组织所带来的心理上的影响 （3）分阶段交付产品不需要客户大的资金支出，特别是当基于投资的高回报而选择最早的构件 （4）客户可以在任何时候停止产品的开发 增量模型（续） 缺点： （1）增量模型面临的困难是每个增加的构件必须能合并到已有的结构中去，却不破坏原来的结构，因此软件设计必须是可扩充的（硬件：插卡）?良好的可维护性 （2）增量模型容易退化成建造—修补模型，必须处理整体性与可扩充性：增量模型是一个矛盾的术语 增量模型（续） 并存增量模型：当设计小组设计第一个构件的同时，规格说明小组转向第二个构件的规格说明 极限编程 由增量模型发展而来 根据效益分析，确定所需特性 测试驱动 成对编程 每日构建 极限编程（续） XP的特性 （1）XP小组的计算机设置在一个大房间中，大房间中有许多彼此相边的小隔间 （2）一个客户代表始终和XP小组一起工作 （3）没有一个人能连续两周超时工作 （4）没有规格说明，而是XP小组的所有成员一起完成规格说明、设计、代码和测试过程 （5）建造出各种构件之前没有概要设计阶段。建造产品的过程中设计在不断地调整