软件工程1-3.过程模型

3.3.1 增量模型
增量模型应用举例
– 如果在项目既定的商业要求期限之前不可能找到 足够的开发人员，这种情况下增量模型显得特别 有用。早期的增量可以由较少的人员实现。如果 核心产品的口碑不错，可以为下一个增量投入更 多的人力(如果需要的话) 。 – 此外，增量能够有计划地管理技术风险，例如， 一个系统需要用到某个正在开发的新硬件，而这 个新硬件的交付日期不确定。因此可以在早期的 增量中避免使用这个硬件，这样，就可以保证部 分功能按时交付给最终用户，不至于造成过分的 延期。
瀑布模型造成软件错误的积累和放大效应
原始要求 分析 正确的规格说明 错误的规格说明 设计 编码 正确设计 错误设计 对错误说明的设计 正确编码 错误编码 错误设计的编码 错误说明编码
测试
正确功能 可纠正错误
不可纠正和潜伏的错误
交付的软件产品
3.2 瀑布模型
思考： 1、我们的日常生活中，有哪些活动是符 合瀑布模型的？ 2、为什么有时候我们的小型开发团队连 瀑布模型都不能坚持做到？客观因素 是什么？ 3、瀑布模型的实用之地在哪里？
《软件工程》
第一部分 软件过程 第3章 惯例过程模型
Chapter 3 Prescriptive Process Models
Prescriptive ：giving directives or rules
prescriptive a.规定的，指示的；约定俗成的
软件工程的基本原理
1968 年正式提出“软件工程”这一术语之后， 软件工程围绕计算机科学、工程和管理三个 方面，做了很多研究，建立了早期关于软件 工程管理的一些基本准则，从中，我们可以 看出早期软件工程的一些思路与出发点。 其中最著名的是著名软件工程专家B.W.Boehm 在1983 年的一篇论文中，提出的软件工程7 条基本原理，反映了作为软件工程应该关注 和考虑的若干本质问题：
3.2 瀑布模型
沟通
项目启动 需求获取
策划
项目估算 进度计划 项目跟踪
建模
分析 设计
构建
编码 测试
部署
交互 支持 反馈
基于通用过程框架的瀑布模型
The Waterfall Model
Com m unic a t ion
proje c t init ia t ion re quire me nt gat hering
（4） 采用现代程序设计技术
– 实践表明：采用先进的技术既可提高软件开发的效率，又可 提高软件维护的效率。 – 80年代及之前：结构化分析、设计技术 – 90年代：面向对象分析、设计技术
软件工程的基本原理 （5） 结果应能清楚地审查
– 软件产品是看不见、摸不着的逻辑产品，开发过程难以评价 和管理。 – 根据软件开发项目的总目标及完成期限，规定开发组织的责 任和产品标准，使所得的结果能够清楚地审查
3.3.1 增量模型
软 件 功 能 和 特 征
第n个增量 沟通 策划 建模
分析设计
交付第n个增量 构建
编码测试
部署
交付反馈
第2个增量 沟通 策划 建模
分析设计
交付第2个增量 构建
编码测试
部署
交付反馈
第1个增量
沟通 策划 建模
分析设计
交付第1个增量
构建
编码测试
部署
交付反馈
项目时间
增量模型
3.3.1 增量模型
com ponent reuse aut om at ic code generat ion t est ing
Planning
Co nst r uct io n
De ploym e nt
int egrat ion deliv ery feedback
Team # 1 Mode ling
business modeling dat a modeling process modeling
Planning
estima ting scheduling tracking
Mode ling
analysis design
Const r uc t ion
code t est
De ploy m e nt
de liv ery support f ee dba c k
3.2 瀑布模型
问题定义
定义阶段 软件需求 软件设计 开发阶段 软件实现
软件工程的基本原理
（1）用分阶段的生命周期计划严格管理
– 经统计表明，不成功的软件项目中有一半左右是由于计划不 周造成的。 – Boehm认为，在软件的整个生命周期中应制定并严格执行六 类计划：项目概要计划、里程碑计划、项目控制计划、产品 控制计划、验证计划、运行维护计划。
（2）坚持进行阶段评审
– 大部分错误是在编码之前造成的 – 错误发现与改正得越晚，所需付出的代价越高。 因此，在每个阶段都进行严格的评审，以便尽早发现在软件开 发过程的错误
3.2 瀑布模型
瀑布模型的优点：
1.强调开发的阶段性； 2.强调早期计划及需求调查； 3.强调产品测试。
3.2 瀑布模型
瀑布模型的缺点： 1. 从认识论角度看，人的认识是一个多次反复循环 的过程，不可能一次完成。但瀑布模型中划分的 几个阶段，没有反映出这种认识过程的反复性。 特别是瀑布模型过于依赖早期进行的唯一一次需 求调查，不能适应需求的变化； 2. 软件开发是一个知识密集型的开发活动，需要相 互合作完成，但瀑布模型没有体现这一点。特别 是由于瀑布模型是单一流程，开发中的经验教训 不能反馈应用于本产品的过程。
3.3 增量过程模型
• 模型应用背景：在许多情况下，初始的软件 需求有明确的定义，但整个开发过程却不宜 单纯运用线性模型。同时，可能迫切需要为 用户迅速提供一套功能有限的软件产品，然 后在后续版本中再细化和扩展功能。 • 两种增量过程模型：增量模型、RAD模型
3.3.1 增量模型
• 增量模型以迭代的方式运用瀑布模型。随着时间的 推移，增量模型在每个阶段运用线性序列。每个线 性序列生产出一个软件的可交付增量。增量模型又 称产品改进模型（Incremental Model） • 当使用增量模型时，第一个增量往往是核心的产品， 即实现了基本的需求，但很多补充的特性(其中一些 是已知的，另外一些是未知的)还没有发布。核心产 品交用户使用(或进行更详细的复审)，使用和/或评 估的结果是下一个增量的开发计划。该计划包括对 核心产品的修改，使其能更好地满足用户的需要， 并发布一些新增的特点和功能。这个过程在每一个 增量发布后不断重复，直到产生最终的完善产品。
3.4 演化过程模型
• 模型应用背景：①在开发过程中，业务和产 品需求经常发生变化，直接导致最终产品难 以实现；②严格的交付时间使得开发团
队不可能圆满地完成软件产品，但是必 须交付功能有限的版本以应对竞争或商 业压力；③很好地理解了核心产品和系 统需求，但是产品或系统扩展的细节问 题却没有定义。
6 0 - 9 0 days
3.3.2 RAD模型
RAD模型 与瀑布模型相比，RAD模型不采用传统的第3代程序 设计语言来创建软件，而是采用基于构件的开发 方法复用已有的程序结构（如果可能）或使用可 复用构件和或创建可复用的构件（如果需要）。 在所有情况下，均使用自动化工具辅助软件创造。 很显然，加在一个RAD模型项目上的时间约束需 要―一个可伸缩的范围‖。如果一个业务能够被模 块化使得其中每一个主要功能均可以在不到3个月 的时间内完成，则其是RAD的一个候选者。每一 个主要功能可由一个单独的RAD组来实现，最后 集成起来形成一个整体。
3.3.2 RAD模型
RAD模型 RAD（快速应用开发）模型是一个增量型的软件开发 过程模型，强调极短的开发周期。该模型是瀑布 模型的一个―高速‖变种，通过大量使用可复用构 件，采用基于构件的建造方法赢得了快速开发。 如果正确地理解了需求，而且约束了项目的范围， 利用这种模型可以很快创建出功能完善的信息系 统。其流程从业务建模开始，随后是数据建模、 过程建模、应用生成、测试及反复。
o d e lin g
business m odeling dat a m odeling process m odeling
C o n s t r u c t io n
Com m unicat ion
Team # 2
Mo d eling
b u si n e ss m o d e l i n g dat a m odeling p ro ce ss m o d e l i n g
co m p o n e n t re u se a u t o m a t i c co d e g e n e ra t i o n t e st i n g
Const r uct ion
component reuse aut omat ic code generat ion t est ing
瀑布模型的另一个图示
– 传统的生命周期模型 – 70年由Royce提出 – 典型瀑布模型具有顺序性 和依赖性
软件测试
维护阶段 运行维护
3.2 瀑布模型
瀑布模型的特征
1. 从上一项活动中接受该项活动的工作成果 （工作产品），作为输入。 2. 利用这一输入实施该项活动应完成的内容 3. 给出该项活动的工作成果，作为输出传给下 一项活动 4. 对该项活动实施的工作进行评审。若其工作 得到确认，则继续下一项活动。
（6） 开发小组的人员应该少而精
– 开发小组人员的素质和数量是影响软件产品质量和开发效率 的重要因素。 – 开发小组人员数目的增加，使相互交流复杂、费用增加。
（7）承认不断改进软件工程实践的必要性
– 遵循前6条基本原理，就能够按照当代软件工程基本原理实 现软件的工程化生产，但不能保证赶上时代前进的步伐。 – 积极主动采纳新的软件技术，且不断总结经验。