软件工程第二章.PPT

第1块 积木 第1块 积木 第1块 积木 第1块 积木 第2块 积木 第2块 第3块积 积木 木 第2块 积木 第3块积 第4块 木 积木
第N次 集成
第1块 积木
第2块 积木
第3块积 第4块 木 积木
第N块 积木
1．模型的本意 要开发一个大的软件系统，先开发其中的 一个核心模块（或子系统），然后再开发 其他模块（或子系统），这样一个个模块 （或子系统）地增加上去，就像搭积木一 样，直至整个系统开发完毕为止。 在每增加一个模块前，先要对该模块进行 模块测试。通过后再将此模块加入到系统 中，然后还要进行系统集成测试。系统集 成测试成功后，再增加新的模块。 这样多次循环，直到系统搭建完毕为止。
2．模型的特点 原型驱动。因此，开发者必须先有一个原 型(样品)，至少要有一个原型的核心。 原型模型与迭代模型相同点是：反复循环 几次，直到客户确认为止。不同点是：原 型模型事先有一个展示性的产品原型(样品)， 而迭代模型可能没有。
3．选择模型的条件 （1）已有产品或产品的原型(样品)，只需 客户化的工程项目。 （2）简单而熟悉的行业或领域。 （3）有快速原型开发工具。 （4）进行产品移植或升级。 由于上述条件不太苛刻，所以凡是有软件 产品的IT企业，在他们熟悉的业务领域内， 当客户招标时，他们都会以原型模型作为 软件开发模型，去制作投标书，去讲解标 投标。
周期序号
1 2 3
周期名称
立项（或签合同）、 下达任务书 需求分析 概要设计
周期序号
6 7 8
周期名称
软件测试 软件发布与实施 软件维护
4
5
详细设计
编码实现
9
版本更新或退役
现在，让我们来回顾一下第1章中对软件生 命周期模型的定义。 在【定义1-2】中指出：软件生命周期模型 是指在整个软件生命周期中，软件开发过 程应遵循的开发路线图。或者说，软件生 命周期模型是软件开发全部过程、活动和 任务的结构框架。 显而易见，这个定义不但非常全面，而且 十分准确，它符合所有软件生命周期模型 对生命周期的定义与解释。
6．快速原型法 由于原型模型的开发速度较快，有时也将它称作快 速原型法（Rapid Prototyping）。 在开发工具和开发环境迅速发展的今天，在信息系 统开发中，原型法和快速原型法又被赋予新的内容： 事先没有原型产品，也可以采取这种办法。 基本思路是：采用以面向元数据为主的方法，在需 求分析的基础上，利用Power Designer等数据库 分析和设计工具，快速建立信息系统的概念数据模 型CDM和物理数据模型PDM；然后利用面向对象 的编程工具，快速地实现需求分析中确认的流程、 功能、性能和接口；之后交付给用户试用，反复循 环几次，直到客户确认满意为止。
4．模型的优点 开发阶段清晰，便于评审、审计、跟踪、 管理和控制。 5．模型的缺点 传统的项目组织方法是按顺序完成每个工 作流程，即瀑布式生命周期。瀑布只能一 个个台阶地往下流，不可能倒着往上流， 这就是它致命的缺点。 瀑布式生命周期通常会导致在项目后期， 出现“问题堆积”，更可怕的是，错误的 传递会采取发散扩大的方式。
2．模型的特点 （1）任务或功能模块驱动，可以分阶段提 交产品。 （2）有多个任务单，这些多个任务单的集 合，构成项目的一个总《任务书》，或总 《用户需求报告》/《需求规格说明书》。
3．选择模型的条件 （1）在整个项目开发过程中，需求都可能 发生变化，客户接受分阶段交付。 （2）分析设计人员对应用领域不熟悉，难 以一步到位。 （3）中等或高风险项目（工期过紧且可分 阶段提交的系统或目标、环境不熟悉）。 （4）用户可参与到整个软件开发过程中。 （5）使用面向对象语言或第四代语言。 （6）软件公司自己有较好的类库、构件库。
原型模型很适合于企业资源规划ERP （Enterprise Resource Planning）系统， 尽管市场上推出了许多公司的分行业 ERP“产品”，但是这些“产品”的产品化 程度相当低，都必须在实施中做大量的客 户化工作。 有些公司的分行业ERP“产品”称作“分行 业解决方案”，这个“分行业解决方案” 就是分行业的原型，即快速原型法中的原 型。
2.3 增量模型
增量模型（Incremental Model）是遵循 递增方式来进行软件开发的。 软件产品被作为一组增量构件（模块）， 每次需求分析、设计、实现、集成、测试 和交付一块构件，直到所有构件全部实现 为止。 这一过程就像小孩子搭积木盖房子一样， 如图2-2所示。
第1次 集成 第2次 集成 第3次 集成 第4次 集成
2.5 迭代模型
针对瀑布模型的缺陷，人们提出了迭代模 型（Iterative Model）。 在多种迭代模型中，要算美国的I. Jacobson，G. Booch和J. Rumbaugh三 位软件专家提出的RUP（Rational Unified Process）模型最为成功。如图2-3表示。
快速原型法选择的条件之一是：项目组中 有数据库分析和设计的专家，有面向对象 编程的专家，文档制作有成熟的模板，而 且系统或项目又不是非常大。 快速原型法选择的条件之二是：项目组的 开发环境为分行业的业务基础平台(比如 Justep X3业务基础平台)，该业务基础平 台又完全适合所需开发的系统或项目，而 且系统或项目又不是非常大。 以上两个条件，只要符合一个，就可以采 用快速原型法。
8
9
60岁以上
因病去世
老年
死亡
退休，老有所乐，写回忆录，立遗嘱
丧事从简，长眠于地下
为什么不同的软件生命周期模型，可能对 应着不同的生命周期。 因为生命周期不同，该软件的开发阶段划 分、评审次数、基线标准、产品发布、维 护方式都有所不同。 软件生命周期模型能清晰、直观地表达软 件开发全过程，明确规定了要完成的主要 活动和任务，用来作为软件项目工作的基 础。一般来说，若以时间为序，软件的生 命周期可详细地划分为几个阶段，如表2-3 所示。
4．模型的优点 开发速度快，用户意见反馈实时，有利于 开发商在短时间内推广并实施多个客户。 正因为原型模型具有这些优点，所以它一 直是软件企业界的主流开发模型。凡是有 软件产品积累的软件公司，他们在投标、 开发、实施项目的过程中，都非常喜欢用 原型模型。 5．模型的缺点 因为事先有一个展示性的产品原型，所以 在一定程度上，不利于开发人员的创新。
5．模型的缺点 如果软件系统的组装和拆卸性不强，或开 发人员全局把握水平不高（没有数据库设 计专家进行系统集成），或者客户不同意 分阶段提交产品，或者开发人员过剩，就 不宜采用这种模型。
2.4 原型模型
许多软件公司在生产软件产品与实施软件项 目时，经常采用一种“原型法”，它来源于 原型模型，下面就介绍这种模型。 1．模型的本意 原型模型（Prototype Model）的本意是： 在初步需求分析之后，马上向客户展示一个 软件产品原型(样品)，对客户进行培训，让 客户试用，在试用中收集客户意见，根据客 户意见立刻修改原型，之后再让客户试用， 反复循环几次，直到客户确认为止。
6. 改进措施 为了克服该模型的缺陷，微软采取严格的里程碑 管理制度。 CMM/CMMI则采取阶段评审和不符合项 (Noncompliance Items)的动态跟踪制度，只有 前一阶段的不符合项全部改正后，才允许开发人 员进入后一阶段的工作。 所谓不符合项，就是在评审中发现的问题项，它 与Bug既有联系，又有区别。对于这些不符合项， 软件管理部门要列出表格，记录在案，确定责任 人，限定改正时间，动态跟踪到底。
2.2 瀑布模型
1970年温斯顿· 罗伊斯（Winston Royce）提出 了著名的“瀑布模型”，直到80年代早期，它一 直是唯一被广泛采用的软件开发模型。直至今日， 该模型仍然具有强大的生命力。 瀑布模型（Waterfall Model）又称流水式过程 模型，它可以形象地用阶梯瀑布描述，水由上向 下一个阶梯接着一个阶梯地倾泻下来，最后进入 一个风平浪静的大湖，这个大湖就是软件企业的 产品库，如图2-1所示。
【例2-1】 1996年8月，当时的某高级工程师， 带领一个程熟练的程序员，来到营口港务局通信 中心，开发该中心的电话业务信息管理系统。 当时，虽然这两个人手中并无什么“原型”，但 是他俩一个是数据库设计高手，一个是编程高手， 所以俩人分工负责，一人设计数据库，一人编写 程序，双方配合默契，只用一个多月时间，就圆 满地完成了开发任务，收回了全部开发费用，获 得了客户的好评。 这是一个典型的“快速原型法”例子。
周期划分 胚胎至分0岁 30~60岁
周期名称 胎儿 婴儿 幼儿 儿童 少年 青年 中年
周期的主要活动 定期到妇幼保健院或妇产科医院检查 请保姆看护，上婴儿室或托儿所 上幼儿园，健康、活泼、天真地成长 上小学，好好学习，天天向上 上中学，参加中考、高考，自古英雄 出少年 上大学，攻读硕士、博士学位，应聘 就业，开始追求创新，追求异性 上班，追求事业上的成就、成功、贡 献，经营幸福的家庭
4．模型的优点 （1）由于将一个大系统分解为多个小系统， 这就等于将一个大风险分解为多个小风险， 从而降低了开发难度。 （2）人员分配灵活，刚开始不用投入大量 人力资源。如果核心模块产品很受欢迎， 则可增加人力实现下一个增量。当配备的 人员不能在设定的期限内完成产品时，它 提供了一种先推出核心产品的途径。即可 先发布部分模块给客户，对客户起到镇静 剂的作用。
1．模型的本意 在瀑布模型中，软件开发的各项活动严格 按照线性方式进行，当前阶段的活动接受 上一阶段活动的工作结果，实施完成所需 的工作内容。 对当前阶段活动的工作结果需要进行验证， 如果验证通过，则该结果作为下一阶段活 动的输入，继续进行下一阶段的活动，否 则返回上一阶段修改。
瀑布模型认为：项目经理或软件管理人员， 只要控制好每级台阶的高度和宽度，在每 个台阶处设立里程碑或基线，并组织好对 基线的评审与审计，就可以控制好项目的 开发成本、进度和质量。 早期的面向过程的结构化分析、结构化设 计、结构化编程、结构化测试、结构化维 护方法，很适合于瀑布模型。或者说，瀑 布模型适合于结构化方法，即面向过程的 软件开发方法。