2. 软件过程
Software Engineering
引言
建造一个房屋的过程
相同的生命周期
不同的过程
引言
任务思维模式
• 问题
– 假设：软件需求可以在开发初期完全确定下来
– 与用户的交互只是发生在确定需求之时和发布产品之后 – 现实情况很少符合上述假设
过程
产品 用户需求
3
引言
过程思维模式
• 好处
– 通过提高可见性来降低开发风险
– 允许在项目进展过程中基于用户的反馈进行项目变更
过程
产品 用户需求
反馈
2.1 软件过程概念
2.2 传统软件过程模型
2.3 现代软件过程模型
2.4 模型选择
软件生命周期
软件生命周期 Software Life Cycle
软件产品或软件系统从设计、投
入使用到被淘汰的全过程
软件生命周期
问题定义
可行性研究
需求分析
总体设计
详细设计
编码
测试
维护
项目计划 报告
可行性研 究报告
需求规格 说明书
总体设计 说明书
详细设计 说明书
源程序 软件测试 报告
软件维护
说明
软件过程
软件过程是在工作产品构建过程中，所需完成的工作活动、动作和任务的集合。
活动主要实现宽泛的目标，与应用领 域、项目大小、结果复杂性或者实施 软件工程的重要程度没有直接关系。
动作包含了主要工作产品生产过程 中的一系列任务。
任务关注小而明确的目标，能够产 生实际产品。
动作
任务
活动
软件过程
软件过程模型
是软件开发全部过程、活动和任 务的结构框架。它能直观表达软 件开发全过程，明确规定要完成 的主要活动、任务和开发策略。
软件过程模型
• 软件开发模型
• 软件生存周期模型
• 软件工程范型
软件过程模型
也常称为
软件过程评估
CMM
ISO 9000
SPICE
能力成熟度模型
ISO 9000
质量标准体系
ISO/IEC 15504 SPICE
信息技术软件过 程评估
• Capability Maturity Model
• CMU-SEI
• 迄今为止学术界和工业 界公认的有关软件工程 和管理实践的最好的软 件过程评估模型
• 为评估软件组织的生产 能力提供了标准
• 为提高软件组织的生产 过程指明了方向
能力成熟度模型CMM
5 优化级
4 量化管理级
3 已定义级
有能力的人和个人英雄主义 2 可重复级
1 初始级
基本项目管理 过程标准化 量化管理
持续的过程改进
2.1 软件过程概念
2.2 传统软件过程模型
2.3 现代软件过程模型
2.4 模型选择
瀑布模型（Waterfall model）
可行性研究
需求分析
总体设计
详细设计
编码
系统测试
验收测试
运行与维护 单元测试
• Winston Royce1970年提出
• 第一个软件过程模型
规定了各项软件工程 活动，以及它们自上 而下，相互衔接的固 定次序，如同瀑布流 水，逐级下落
• 软件开发过程与软件生命周 期一致
• 也称经典生命周期模型
瀑布模型（Waterfall model）
可行性研究
需求分析
总体设计
详细设计
编码
系统测试
验收测试
运行与维护 单元测试
• 线性模型
• 阶段间具有顺序性和依赖性
• 推迟实现的观点
• 一直被用来规范软件开发活动
• 很多其它模型都是在瀑布模型 基础上的改进
• 是一种使用广泛，以文档 为驱动的模型
• 每个阶段都有与其相关联 的里程碑和可交付产品
• 每个阶段结束前完成文档 审查，及早改正错误
实际（带反馈）的瀑布模型
• 当后面阶段发现前面阶 段的错误，则沿反馈线 返回并修正
可行性研究
需求分析
总体设计
详细设计
编码
系统测试
验收测试
运行与维护 单元测试
• 对软件的维护，则反馈 到相应的阶段。
瀑布模型的缺点
早期错误发现晚
早期的错误可能要等到开发 后期的测试阶段才能发现，
进而带来严重的后果
增加工作量
各个阶段的划分完全固定，
阶段之间产生大量的文档，
极大地增加了工作量
开发风险大
由于开发模型是线性的，
用户只有等到整个过程的 末期才能见到开发成果，
从而增加了开发的风险
不适应需求变化
不能反映实际的开发方式，
软件开发需要迭代；无法 适应需求不明确和需求的 变化
瀑布模型的适用场合
瀑布模型适用于系统需求明确且稳
定、技术成熟、工程管理较严格的
场合，如军工、航天、医疗。
V 模型（V-model）：瀑布模型的变种
可行性研究
需求分析
总体设计
详细设计
系统测试
验收测试
运行与维护
单元测试
分析
设计
验证设计测试
确认需求
验证设计
编码
V 模型：单元测试发现问题
可行性研究
需求分析
总体设计
详细设计
编码
系统测试
验收测试
运行与维护
单元测试
分析
设计
验证设计测试
V 模型：系统测试发现问题
可行性研究
需求分析 验收测试
运行与维护
分析
设计 测试
系统测试 总体设计
详细设计
编码
单元测试 验证设计
V 模型：验收测试发现问题
可行性研究 运行与维护
分析
设计 测试
验收测试 需求分析
总体设计 系统测试
详细设计
编码
单元测试 确认需求
原型模型（Prototype model）
也称为
• 原型化模型、快速原型模型
原型（prototype）
• 一个部分开发的产品，使客户和 开发人员能够对计划开发的系统 的相关方面进行检查。
举例1
• 图书借阅系统：主要界面
举例2
• 智能家居系统：少量的室内信息 监视和电器控制
• 明确并完善需求，如演示原型
• 研究技术选择方案，如技术验证原型
• 抛弃原型
• 把原型发展成最终产品
原型化的目的 原型结果
原型模型（Prototype model）
策划/修 改 原型需 求
构建/修 改 原型系 统
部署原型 系统
和客户沟 通
① ②
③
④
原型构建
用户 满意
系统开发
原型模型的优缺点
优点
减少需求不明 确带来的风险
• 构造原型采用的技术和工具不一 定主流
• 快速建立起来的系统加上连续的 修改可能导致原型质量低下
• 设计者在质量和原型中进行折中
• 客户意识不到一些质量问题
缺点
原型模型的适用场合
增量模型（Incremental model）
• 第一个增量：创建文本
• 第二个增量：组织文本
• 第三个增量：格式化文本
• 增量：满足用户需求的一个子集，能够完成一定功能、小而可用的软件
• 举例：
– 文字处理软件：创建文本、组织文本、格式化文本
增量 发布
• 第一个发布：创建文本
• 第二个发布：创建文本、组织文本
• 第三个发布：创建文本、组织文本、
格式化文本
增量模型（Incremental model）
需求分析 体系结构 设计
设计 编码 测试 交付
增量1
（创建文本）
设计 编码 测试 交付
增量2
（组织文本）
设计 编码 测试 增量n
（格式化文本）
最终产品 发布1
发布2
交付 发布n 开放式结构
增量模型（Incremental model）
增量可能无法集成 最终产品 风险较大
增量1
（创建文本）
增量2
（组织文本）
增量n
（格式化文本） 设计 编码 测试 交付 发布n 发布1
需求分析
发布2 设计 编码 测试 交付
需求分析
设计 编码 测试 交付 需求分析
增量的方式
创建文本 创建文本
组织文本
创建文本 格 组织文本 式
化 文 本
增 量 方 式
迭 代 方 式
创建文本 创建文本 创建文本
格 组织文本 式
化 文 本
实际使用中，常常是两种方式的结合
增加 新功能
增加 新功能
格 组织文本 改进 格 组织文本
式 功能 式
化 化
文 文
本 本
改进 功能
增量模型的特点
• 增量模型是一种非整体开发的模型，是一种进化式的开发过程
• 增量模型从部分需求出发，先建立一个不完整的系统，通过测试运行这个系统 取得经验和反馈，进一步使系统扩充和完善
• 如此反复进行，直至软件人员和用户对所设计的软件系统满意为止
• 增量模型结合了原型模型的基本要素和迭代的特征，采用了基于时间的线性序 列，每个线性序列都会输出该软件的一个“ 增量”
• 每个增量的开发可用瀑布或快速原型模型
增量模型的优点
•
产品逐步交付，软件开发能 够较好地适应需求的变化；•
能够看到软件中间产品，提 出改进意见，减少返工，降 低开发风险；• 在项目的初始阶段不需要投 入太多的人力资源；
• 增量概念的引入，
不需要提供完整的 需求，只要有一个 增量出现 ，开 发 就可以进行；
• 软件能够更早投入市场；
• 开放式
体系结构，
便于维护
增量模型的缺点
易退化成边做边改的 方式，使软件过程控 制失去整体性
软件必须具备开放式 体系结构（困难）
每个增量必须提供一 些系统功能，这使得 开发者很难根据客户 需求给出大小适合的 增量
增量模型的适用场合
适用于软件开发中需求可能发生变化、具有较
大风险、或者希望尽早进入市场的项目。
螺旋模型（Spiral model）
• 软件开发普遍存在风险
• 交付的产品用户不满意
• 产品不能按时交付
• 开发成本超过预算
• 产品开发期间关键开发人员离职
• 产品投入市场前竞争对手发布功能相近价格更低产品
…
• 把开发活动和风险管理结合起来控制风险
螺旋模型（Spiral model）
•
开发过程分成若干次迭代，每次迭代代表 开发的一个阶段，对应模型中一条环线•
每次迭代分成四个方面的活动，对应笛卡 尔坐标的四个象限：①
确定本阶段目标，选定实施方案，弄 清项目开发的限制条件；②
评估所选方案，通过构造原型和风险 分析识别和消除风险；③
实施软件开发和验证；④
评价本阶段的工作成果，提出修正建 议，并计划下一阶段工作。•
模型结合了瀑布模型和原型模型的特点开发进度顺时针为进展 明确目标、 方向
选择方案、
设定约束条件
评估方案 风险分析 构造原型
开发与验证 评价本阶段
计划下一阶段
螺旋模型（Spiral model）
生命周期计划 需求计划
原型1 原型2 原型3 可运行 的原型 操作概念 软件需求
风险分析 风险分析
风险分析 风险分析
软件设计 需求确认
设计验证与确认
详细设计
单元 编码 集成 测试 验收 测试
软件 测试 实现
开发进度顺时针为进展方向
明确目标、
选择方案、
设定约束条件
评估方案 风险分析 构造原型
开发与验证 评价本阶段
计划下一阶段
开发计划 集成和测试计划 预算、方案、约束
螺旋模型的优点
螺旋模型强调原型的可扩 充性和可修改性，原型的 进化贯穿整个软件生存周 期，这将有助于目标软件 的适应能力，支持用户需 求的动态变化；
螺旋模型为项目管理人员 及时调整管理决策提供了 方便，进而可降低开发风 险。
原型可看作可执行的需求规格 说明，易于为用户和开发人员 共同理解，还可作为继续开发 的基础，并为用户参与所有关 键决策提供了方便；
螺旋模型的缺点
使用该模型需要有相当丰 富的风险评估经验和专门 知识，要求开发队伍水平 较高，否则会带来更大风 险。
如果每次迭代的效率 不高，致使迭代次数 过多，将会增加成本 并推迟交付时间；
螺旋模型的适用场合
▪ 适用于需求不明确或者需求可能发生变 化的大 型复杂的软件系统。
▪ 支持面向过程、面向对象等多种软件开发
方法， 是一种具有广阔前景的模型。
喷泉模型（Fountain model）
• 喷泉模型是一种以用户需求为动力，以对象 为驱动的模型，主要用于描述面向对象的软 件开发过程
• 软件开发早期定义对象，整个开发过程充实 和扩充对象
• 各个阶段使用统一的概念和表示方法，生命 周期各阶段无缝连接
• 各个开发步骤多次反复迭代
喷泉模型的优缺点及适用场合
缺点
由于喷泉模型在各个开发阶 段是重叠的，在开发过程中 需要大量的开发人员，因此 不利于项目的管理。
喷泉模型要求严格管理文档，
使得审核的难度加大，尤其 是面对可能随时加入的各种 信息、需求与资料的情况。
优点
喷泉模型的各个阶段没 有明显的界限，开发人 员可以同步进行开发，
可以提高软件项目开发 效率，节省开发时间，
适应于面向对象的软件 开发过程。
适用场合
适用于面向对象开发
2.1 软件过程概念
2.2 传统软件过程模型
2.3 现代软件过程模型
2.4 模型选择
基于构件的开发模型
• Component-based development model
• 近年来得到广泛应用，改变大型软件开发方式
• 考虑的焦点是集成，而非实现
• 构件/组件（Component）
– 系统中模块化的、可更换的部分 – 实现特定的功能
– 对实现进行封装，暴露一组接口
– 例如：动态链接库（.dll），浏览器插件
基于构件的开发模型
需求 分析
构件检索 与分析
设计体系 结构
复用与集 成构件
系统 测试
构件库
开发新构件
系统 维护
购买新构件
构件开发
与维护
构件选取 需求修改
系统开发
基于构件的开发模型
• 与其它过程 模型相同
• 根据需求搜索构件
• 如果没有完全匹配 的构件，则需要修 改构件或者修改需 求
同
• 考虑重用和集成
• 如果没有可重用的 构件，则设计新软 件
02. 构件分析
01. 需求分析 03. 系统设计
• 与其它过程模型不
04. 开发集成
• 将构件集成到系 统中
• 开发新软件
基于构件的开发模型的优缺点
缺点
• 模型复杂
• 商业构件不能修改，会 导致修改需求，进而导 致系统不能完全符合客 户需求
• 无法完全控制所开发系 统的演化
• 项目划分的好坏直接影 响项目结果的好坏
优点
• 软件复用思想
• 降低开发成本和风险，
加快开发进度，提高 软件质量
适用场合
适用于系统之间有共性的情况。
Rational统一过程模型
• Rational Unified Process - RUP
• 由Rational公司（现已被IBM收购）推出的完整且完美的软件工程方法
• 获得广泛使用
• 基于面向对象方法学
• 使用统一建模语言UML（Unified Modeling Language）
Rational统一过程模型
• 从3个视角描述软件开发过程
– 动态视角：随时间变化的各个阶段 – 静态视角：所进行的活动
– 实践视角：可采用的良好实践建议
Rational统一过程模型
1. 迭代式开发
• 需求变更不可避免
• 每次迭代产生一个可交 付版本，用户反馈，减 少风险
• 根据客户的轻重缓急来 规划增量，先开发和交 付优先级最高的增量
2. 管理需求
• 采用用例分析来捕获需 求，由用例驱动设计和 实现
• 对需求及其变更进行管 理
Rational统一过程模型
3. 基于构件体系结构
• 采用基于构件的体系结构
• 提高软件复用率
4. 可视化建模
• 使用统一建模语言
（UM L）对系统进行可 视化建模
5. 验证软件质量
• 软件质量评估贯穿整个 开发过程的所有活动
• 全体成员参与
6. 控制软件变更
• 描述如何控制和跟踪软 件的变更
Rational统一过程模型
初始：项目计划
、评估风险；
精化：设计系统 的体系结构、制 定项目计划、确 定资源需求；
构建：开发出所 有组件和应用程 序，集成并进行 详尽测试；
产品化：将产品 移交给用户。
动态视角 静
态 视 角
统一过程的静态结构
“ 谁” 来做？
做“ 某事” ？
“ 何时” 做？
“ 如何” 做？
活动
角色
工作流 产物
• 6个核心工程工作流：
• 业务建模工作流
• 需求工作流
• 分析设计工作流
• 实现工作流
• 测试工作流
• 部署工作流
• 3个核心支持工作流：
• 项目管理工作流
• 配置与变更管理工作流
• 环境工作流。
统一过程的动态结构
构建阶段
产品化阶段 精化阶段
初始阶段
敏捷软件开发
•
Agile software development•
虽然右边的项有价值，但我们更重视左边的项•
高效工作、快速响应变化 个体和交互胜过过程和工具
可以工作的软件胜过 客户合作胜过合同谈 面面俱到的文档 判
•
2001年2月，17位编程大师发表敏捷软件开发宣言01. 个体交互 02. 可工作软件 03. 客户合作 04. 响应变化
响应变化胜过遵循 计划
敏捷开发方法
• 极限编程：eXtreme Programming/XP
• 自适应软件开发
Adaptive Software Development/ASD
• 并列争球法：Scrum
• 动态系统开发方法
Dynamic System Development Method/DSDM
• 水晶法：Crystal
• 特征驱动开发：Feature-Driven Development/FDD
• 精益软件开发：Lean Software Development/LSD
• …
敏捷软件开发
• 敏捷软件过程是基本原理和开发准则的结合
基本原理强调
• 客户满意度和较早的软 件增量交付
• 小但有激情的团队
• 非正式的方法
• 最小的软件工程产品
• 简化整体开发
开发准则强调
• 分析和设计的交付
• 开发者和客户之间积极 持续的交流
极限编程
• eXtreme Programming – X P
• 把好的开发实践运用到极致
为当前版本选择 故事情节/需求
（Scenario）
将故事情节分 解成任务
规划版本
开发/集成/测试 发布软件
评估系统
软件
• 结对编程
• 先写测试用例再 编程
极限编程的有效实践
• 增量式开发
• 小版本短周期交付
• 结对编程
• 代码集体所有
• 开放的工作空间
• 可 持 续 的 开 发 速 度 ：
<40小 时/周，连续加 班不超过两 周
• 重构
• 简单的设计
• 测试驱动开发
• 持续集成
• 及时调整计划
• 客户作为开发团队成员
敏捷开发的优缺点
缺点
• 测试驱动开发可能 导致通过测试但非 用户期望
• 重构而不降低质量 困难
优点
• 快速响应变化和不确定性
• 可持续开发速度
• 适应商业竞争环境下的有 限资源和有限时间
适用场合
适用于需求模糊且经常改变的场合，
适合商业竞争环境下的项目。
2.1 软件过程概念
2.2 传统软件过程模型
2.3 现代软件过程模型
2.4 模型选择
如何选择软件过程模型
• 软件过程模型是不断发展的
• 各种软件过程模型各有优缺点和适用场合
• 不同软件往往需要不同软件过程模型
• 选用时不必拘泥于某种模型
• 可组合多种模型
• 可根据实际创造新的模型
如何选择软件过程模型
1.前期需求明确的情况下，尽量采用瀑布模型
2.用户无系统使用经验，需求分析人员技能不足的情况下，尽量借助原型模型
3.不确定因素很多，很多东西无法提前计划的情况下，尽量采用增量模型或螺旋模型 4.需求不稳定的情况下，尽量采用增量模型
5.资金和成本无法一次到位的情况下，可采用增量模型
6.对于完成多个独立功能开发的情况，可在需求分析阶段就进行功能并行，每个功能内部 都尽量遵循瀑布模型
7.全新系统的开发必须在总体设计完成后再开始增量或并行 8.编码人员经验较少的情况下，尽量不要采用敏捷或迭代模型
9.增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口原则
案例1：医疗设备控制软件
• 案例分析：
– 需求明确且稳定
– 可靠性和安全性要求极高
– 对软件错误和故障的控制和跟踪能力强 – 需要对软件开发过程严格控制
– 需要大量严格的文档
• 模型选择：瀑布模型
案例2：校园一卡通系统
• 案例分析：
– 包括若干相对独立的功能
– 系统具体需求不明确且会发生变化 – 系统需要具有可扩充性
– 用户需要熟悉和适应新的系统 – 项目复杂程度中等、有一定风险 – 产品和文档的再使用率较高
• 模型选择：增量模型
案例3：智能化小区
• 智能家庭
– 家居信息的实时和远程监视 – 家用电器的远程和自动控制 – 家庭安防报警和远程通知
• 智能小区
– 安防门禁、可视对讲等
– 物业管理
– 一卡通系统
– 缴费、包裹、公告、便民信息等发布到户
– 家政相关服务，如送水、送餐等
案例3：智能化小区
• 案例分析：
– 包括若干相对独立的业务管理功能 – 系统具体需求不明确且会发生变化 – 部分技术方案可行性不确定
– 系统需要具有可扩充性
– 用户需要熟悉和适应新的系统 – 项目复杂程度较大、风险较大 – 希望尽早投入市场
• 模型选择：原型化模型+增量模型
思考与讨论
• 以下系统适合采用什么样的软件过程模型？为什么？
– 汽车防抱死刹车控制系统
– 支持软件维护的软件工程工具
– 大学教务管理系统，准备替换现有的系统 – 位于火车站的交互式火车车次查询系统
