软件开发过程

演化软件过程模型
人们已经越来越认识到软件就象所有复杂系统一样要经过 一段时间的演化。业务和产品需求随着开发的发展常常发 生改变，想找到最终产品的一条直线路径是不可能的。
紧迫的市场期限使得难以完成一个完善的软件产品，但可 以先提交一个有限的版本以对付竞争或商业的压力；只要 核心产品或系统需求能够很好地理解，而产品或系统的细 节部分可以进一步定义。
演化模型是利用一种迭代的思想方法，它的特征是使软件 工程师渐进地开发逐步完善的软件版本。
快速原型模型
鉴于瀑布型软件开发的不足，人们设想一种制造“样机” 的思路，抓住系统主要功能或部分功能以及主要接口，向 用户提供一个引导性版本，以解决其需求模糊的问题。其 开发过程示意如下：
原型需求分析 原型开发 原型评价 最终系统设计 最终目标系统
核心工作流
需求获取 分析 设计 实现 测试
先启阶段 精化阶段
构建阶段
产品化阶 段
制 定 测 试 计 划
测 试 体 系 结 构
测 试 系 统 提 交
用 户 测 试
初始迭代
迭代 迭代 #1 #2
迭代 迭代 迭代 #n #n+1 #n+2 迭代
迭代 #m
迭代 #m+1
RUP的相关资源
IBM，RUP学堂
沟通 策划 建模
• 分析——需求获取、分析、规格说明、评审 • 设计——数据设计、体系结构设计、接口设计和构件层设计
构建 部署
本章主题
软件过程基本概念 软件过程模型 个人过程模型与团队过程模型 软件过程管理
软件过程模型
过程模型定义了包含活动、动作、任务、里程碑和工作产 品在内的明确的集合，是高质量软件开发所必须的。
RUP的三大特点
用例驱动
用例驱动旨在为到最终产品为止的每个阶段都可以回溯到用户的真正需求。
以架构为中心
以架构为中心是指关注体系结构模式的开发，以引导后续系统，保证系统 的平滑演进。
迭代和增量开发
每一次迭代包括迭代计划、迭代评价和一些具体活动
迭代核心工作流
需求
分析
设计
实现
测试
计划
一次 迭代
评价准则
迭代 迭代 迭代 #n #n+1 #n+2 迭代
迭代 #m
迭代 #m+1
核心工作流----设计
核心工作流
需求获取
先启阶段 精化阶段
过程阶段
构建阶段
产品化阶 段
分析
主要任务是设计
体系结构并建立实现蓝图
设计
主要集中在细化 后期和构造早期
实现
测试
初始迭代
迭代 迭代 #1 #2
迭代 迭代 迭代 #n #n+1 #n+2 迭代
这些框架活动可广泛应用于所有的软件开发项目，无论这 些项目的规模和复杂性如何。
软件过程的框架
计划 时期
问题定义
可行性论证 及软件计划
开发 时期
运行时期
需求分析 概要设计 详细设计 编码 测试 运行／维护
通用过程框架
下面介绍的通用过程框架（generic process framework） 可适用于绝大多数的软件项目：
工作量 先启阶段 精化阶段
过程阶段
构造阶段
产品化阶段
精化阶段的一次迭代
初始迭代
迭代 迭代 #1 #2
迭代 迭代 迭代 #n #n+1 #n+2 迭代
迭代 #m
迭代 #m+1
核心工作流----需求获取
核心工识确别作定细约系流化5统0不%的超~范7过0围%1先和0的启%边需5阶界%求段~1细0捕%化获构精大8成0化部%基阶的分线段需需体求求系结构构过建剩程捕阶余阶获段的该并2段0阶细%需如 段需化求果 没求不从 有再构 需产有造 求品变阶 捕化动段 获阶，活动
炒菜 （30分钟）
煮饭 （30分钟）
煲汤 （120分钟）
结束
开始
煲汤 （120分钟）
煮饭 （30分钟）
结束
洗菜 （10分钟）
切菜 （20分钟）
炒菜 （30分钟）
开始 煮饭 （30分钟）
结束
洗菜 （10分钟）
切菜 （20分钟）
炒菜 （30分钟）
难题
任何事物都有过程，但是我们通常不了解 如何找到一个最佳或者最适合的过程 循规蹈矩还是推陈出新
是一个过程产品。 有自己的过程框架，这个框架可以被改造和扩展以适应采
纳此方法的组织。
RUP吸收了现代软件开发中6项最佳实 践
被证明是解决软件开发过程中根本问题的方法
迭代开发，提前认知风险
管理需求 及早达成共识
基于构件搭 建弹性构架
可视化建模 打破沟通壁垒
持续质量验证 降低缺陷代价
控制变更，有序积累资产
http://www.ibm.com/developerworks/cn/rational/theme/rationalrup/index.html
敏捷过程
敏捷软件开发是从90年代开始逐渐引起广泛关注的一些新 型软件开发方法，是一种应对快速变化的需求的软件开发 技术。
相对于“非敏捷”，更强调程序员团队与业务专家之间的紧 密协作、面对面 的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组 织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也 更注 重软件开发中人的作用。
软件开发过程
本讲主题
软件过程基本概念 软件过程模型 个人过程模型与团队过程模型 软件过程管理
过程
过程是指为了达到给定目标而执行的一系列活动的有序集 合。
过程定义了谁做，做什么，什么时候做以及如何达到预定 目标的一系列活动
对过程的认识
一切事物的发生、发展、消亡都离不开过程，都寓于过程 之中
以上三点是瀑布型软件开发的指导思想，它比阶段的具体 划分更为根本。
瀑布型软件开发的不足
由于连续无反馈，严格而有些僵化，所以在开发过中，越 早隐蔽的错误暴露越晚，排除故障的代价越高。开发周期 过长可能导致预先定义的需求过时。
许多软件项目，在设计之前要求对系统需求进行完整、周 全的确定几乎是不可能的。瀑布型很难适应需求的动态改 变。特别是用户对需求处于模糊认识时更为困难。
试
维
护
改进后的瀑布模型
瀑布模型把软件生存周 期划分为计划、开发、 运行/维护三个时期， 每个时期又划分为若干 阶段。
如瀑布一样奔流不息， 拾阶而下，故此得名。
每个阶段可以向上个阶 段反馈
计划 时期
问题定义
可行性论证 及软件计划
开发 时期
需求分析 概要设计 详细设计 编码
测试
运行时期
运行／维护
提交
RUP的整体架构
RUP
RUP是以用例为驱动、体系结构为中心、迭代和增量的过程。 RUP包括四个阶段，每个阶段又分为若干次迭代，每次迭代 都有一个核心工作流（包括5个活动）。
关于核心工作流中的五个活动：需求、分析、设计、实现 和测试较好理解，这里不再赘述。
迭代和工作流
核心工作流
需求获取 分析 设计 实现 测试
敏捷宣言（2001年）
个体和交互胜过过程和工具 可工作的软件胜过宽泛的文档 客户合作胜过合同谈判 响应变化胜过遵循计划
为什么叫敏捷（agile）
能够快速的有效的响应变化
敏捷过程的4个关键问题
具有控制力的自我组织的团队 团队成员之间、开发参与者与客户之间的交流与合作 强调快速软件交付以让客户满意 欢迎变更，并且能够很好的适应变更
传统过程模型，是人们在实践中不断创造出来的过程模型， 我们通常把统一过程出现之前的过程模型称为传统过程模 型。
历史证明这些过程模型为软件工程工作增加了大量有用的 结构化设计，并为软件团队提供了有效的路线图。
传统过程模型——瀑布模型
问题定义
定义阶段
可行性研究
需求分析
开发阶段
软件设计
编
码
维护阶段
测
制定计划──确定软件目标，选定实施方案，弄清项目开发的限制条件 风险分析──分析所选方案，考虑如何识别和消除风险 实施工程──实施软件开发 客户评估──评价开发工作，提出修正建议
不同版本、不同形式的不断进化； 需要高水平的风险评估技术；
螺旋模型（续）
用户通信
计划
风险 分析
用户评估
概念开发项目 新产品开发项目 产品增强项目 产品维护项目
段
需求获取
分析
设计
实现
测试
初始迭代
迭代 迭代 #1 #2
迭代 迭代 迭代 #n #n+1 #n+2 迭代
迭代 #m
迭代 #m+1
核心工作流----分析
核心工作流
需求获取
主先要启集主阶中要段在目标是精建化立阶段 细化的初稳始固阶的段体系结构
过程阶段
构建阶段
产品化阶 段
分析
设计
实现
பைடு நூலகம்
测试
初始迭代
迭代 迭代 #1 #2
快速原型模型（续）
原型开发一般都用快速原型。它须要借助工具和现成的程 序组件来缩短开发周期。
原型开发有：抛弃型、演化型、增量型、螺旋型等。 原型开发的不足在于反复分析评价，可能会引起计划的改
变，无规律地增加需求而增大系统的风险性。
螺旋模型
螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方 面的活动
建造及发布
工程 实施
统一软件开发过程RUP
UML是一种建模语言，不是一种方法，它独立于过程。利用 它建模时，可遵循任何类型的建模过程。该建模语言的作 者们给出了一种推荐性的建模过程指导，即RUP（Rational Unified Process ）。
RUP是什么
是一种软件工程过程，它提供了如何在开发组织中严格分 配任务和职责的方法。（地位等同于瀑布模型）
项目计划和经验验证的软件 质量工程原理的完美结合
在一个国际会议中首次发布
“ Modeling Implications of the Personal Software Process”
5th International Software Process Workshop, 1989
Watts Humphrey
软件过程
软件过程是指为建造高质量软件而执行的一系列活动的有 序集合。
一个真正有效的软件过程的特点:
从根本上说，软件过程必须可以预测：成本估计和进度承诺必须能满足合理的 一致性，产品必须满足用户对其功能和质量的期望。
用户需求
过程
产品
过程框架
过程框架（process framework）定义了若干小的框架活动 （framework activity），为完整的软件开发过程建立了 基础。
过程也是客观事物运动规律的体现，只有符合客观事物运 动规律的过程才是正确的过程
过程的好坏由结果状态与预期状态的差异决定，也就是目 标成果质量的好坏
讨论：举例
举出日常生活中或工作中过程的例子？ 遇到那些难解决的问题？
就诊流程
新车上牌流程
做饭的过程
开始
洗菜 （10分钟）
切菜 （20分钟）
软件过程模型：“软件过程框架的一个特定的体现”
软件过程模型 可以在任何适当的抽象层次上建立 将软件过程构架的标准元素适当地裁减得到
过程模型分类
传统过程模型
瀑布模型、增量模型、原型模型、螺旋模型等
统一过程模型
RUP
敏捷过程模型
XP，Scrum，Crystal
传统过程模型
最早提出过程模型是为了改变软件开发的混乱状态，使软 件开发更加有序。
敏捷过程模型——极限编程
极限编程（eXtreme Programming，XP）是敏捷软件开发使 用最广泛的一个方法。
本章主题
软件过程基本概念 软件过程模型 个人过程模型与团队过程模型 软件过程管理
个人过程模型（PSP）的由来
由 Watts Humphrey 在 1989 创建，是他从IBM 的17年最 佳实践的形式化的总结
迭代 #m
迭代 #m+1
核心工作流----实现
核心工作流
需求获取 分析 设计 实现 测试
先启阶段 精化阶段
过程阶段
构建阶段
产品化阶 段
构造可执行的 体系结构
主要集中在 构造阶段
解决系统缺陷
初始迭代
迭代 迭代 #1 #2
迭代 迭代 迭代 #n #n+1 #n+2 迭代
迭代 #m
迭代 #m+1
核心工作流----测试
增量和迭代
使用瀑布模型，可以运行的产品很迟才能看到，这就潜伏 了巨大的风险：很可能，集成之日也就是爆炸之日。为了 提早获得可以运行的版本，可以先实现一些功能，再实现 一些功能……每个增量交付一个可以运行的版本。
增量模型
分析 设计 编码 测试 增量1 分析 设计 编码 测试 增量2 分析 设计 编码 测试 增量3
瀑布型软件的开发特点
⑴.阶段的顺序性和依赖性（连续性），只有前一阶段的工 作完成后，后一阶段的工作才能开始，前阶段的输出文档 即为后一阶段的输入文档。
⑵.推迟实现的观点：把逻辑设计与物理实现清楚地划分开 来，尽可能地推迟程序的物理实现。
⑶.质量保证的观点：
Ⅰ）每一阶段都要完成规定的文档。 Ⅱ）每一阶段都要求对已完成的文档进行复审。复审的目的在于避免将错误带 入下阶段。
CMM之父Watts Humphrey于美国时间10月28日逝世，享年83岁。 Watts Humphrey在软件工程领域享有盛誉，被美国国防软件工程杂志