第2章软件过程模型
合集下载
软件工程第二章-软件过程
编码
运行 时期
1. 瀑布模型
瀑布模型(waterfall model)是软件工程最早的范例，
也称经典生命周期，它提出了一个系统的、顺序的软 件开发方法，从用户需求规格说明开始，通过计划、 建模、构建和部署的过程，最终提供一个完整的软件 并提供持续的技术支持。
沟通 项目启动 需求获取 策划 项目估算 进度计划 项目跟踪
… 框架活动 # n 动作 # n.1 任务集 …… 动作 # n.m 任务集 工作任务、工作产品、 质量保证点、项目里程碑
工作任务、工作产品、 质量保证点、项目里程碑
只有一种软件过程吗？
软件过程的种类很多，区别主要体现在几个方面： 组成过程的各个活动(包括普适性活动)、动作和任务，及其相互依 赖的关系都可能不同； 动作和任务的细化程度可能不同； 工作产品的定义和要求可能不同； 质量保证活动的应用方式可能不同； 项目跟踪和控制活动的应用方式可能不同； 过程描述的详细程度和严谨程度可能不同； 客户和利益相关者对项目参与的程度可能不同； 软件团队所赋予的自主权可能不同； 队伍组织和角色的明确程度可能不同。
下优先级进行增量开发：
第一个增量实现基本的文件管理、编辑和文档生成功能
； 第二个增量实现更加完善的编辑和文档生成功能； 第三个增量实现拼写和文法检查功能； 第四个增量完成高级的页面布局功能； ……
增量模型的特点
增量过程模型综合了线性、并行、演化三种过程流的
特征。
对于每个增量，使用的是线性过程流；
过程流
过程流(process flow)：描述了在执行顺序和执行时
间上，如何组织框架中的活动、动作和任务。 大致有四大类不同的过程流：
2-1 软件过程模型
原型需求
系统需求
沟通 快速策划 建模 快速设计
提交系统
部署交付 及反馈
构建原型
2-1 软件过程模型
快速原型法的步骤
Step 1：双方通过沟通，明确已知的需求，并大致勾画出以后 再进一步定义的东西。 Step 2：迅速策划一个原型开发迭代并进行建模，主要集中于 那些最终用户所能够看到的方面，如人机接口布局或者输出
2-1 软件过程模型
瀑布模型
也叫做鲑鱼模型(Salmon model)：向前一阶段回溯，很难。
2-1 软件过程模型
瀑布模型
优点——追求效率 – 它提供了一个模板，这个模板使得分析、设计、编码、测试和 支持的方法可以在该摸板下有一个共同的指导；
– 简单、易懂、易用、快速；
– 为项目提供了按阶段划分的检查点，项目管理比较容易；每个
2-1 软件过程模型
增量模型
举例1：开发一个类似于Word的文字处理软件 – 增量1：提供基本的文件管理、编辑和文档生成功能； – 增量2：提供高级的文档编辑功能； – 增量3：实现拼写和语法检查功能；
– 增量4：完成高级的页面排版功能；
举例2：开发一个教务管理系统 – 增量1：提供基本的学籍管理和成绩管理功能； – 增量2：提供选课功能； – 增量3：提供查询教室使用情况的功能；
– 增量4：提供课表生成、上课名单生成、成绩录入等功能。
2-1 软件过程模型
增量模型
优点：
– 在时间要求较高的情况下交付产品：在各个阶段并不交付一 个可运行的完整产品，而是交付满足客户需求的一个子集的 可运行产品，对客户起到“镇静剂”的作用； – 人员分配灵活：如果找不到足够的开发人员，可采用增量模 型：早期的增量由少量人员实现，如果客户反响较好，则在 下一个增量中投入更多的人力； – 逐步增加产品功能可以使用户有较充裕的时间来学习和适应 新产品，避免全新软件可能带来的冲击；
软件工程-软件过程模型
4 演化模型-螺旋模型
Evolutionary Model
螺旋模型的基本思想
每一个螺旋周期（Spiral model sectors）包 含四个部分： （1）确定目标，选择方案，设定约束条件， 选定完成本周期所定目标的策略。 （2）分析该策略可能存在的风险。 （3）在排除风险后，实现本螺旋周期的目标。 （4）评价前一步的结果，并且计划下一轮的 工作。
第二章 软件过程模型
软件生存周期 软件开发模型 瀑布模型 进化式模型 演化模型 形式化开发
第一节 软件生存周期
软件生存周期的概念： 一个软件从计划起，到废弃不用止。
软件生存周期包括：计划、开发、运行。
第二节 软件开发模型概念
软件开发模型的概念：
为整个软件生存期建立的模型。
交付客户
构件n
规格说明
设计
实现和集成
交付客户
增量模型的基本思想
每个增量提供系统功能的一个子集，一个增 量完成并交付，部分系统功能可以提前交付 使用。 对增量中服务的分配取决于服务优先次序。 最高优先权的服务首先被交付。 第一个增量往往是核心的产品。 开发者能通过对系统的经验帮助理解后面的 增量需求和目前增量后续版本的需求变更。
思考题
为以下各系统提出合适的软件过程模型，阐 述理由： （1） 汽车防锁死刹车控制系统 （2）一个支持软件维护的虚拟现实系统 （3）大学记账系统，准备替换一个已存在的 系统 （4）一个位于火车站的交互式火车车次查询 系统
建立原型系统的方法
原型系统仅包括未来系统的主要功能，以及 系统重要的接口。 开发原型系统尽可能使用能缩短开发周期的 语言和工具。
3 演化模型-增量模型
Evolutionary Model
软件过程的定义与模型
过程定义了运用方法的顺序，应该交付的文档资料，为保证软件质量和 协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里 程碑。通常，使用生命周期模型简洁地描述软件过程。生命周期模型规定了 把生命周期划分为哪些阶段及各个阶段的执行顺序，因此也称为过程模型。
5
第二节
软件生命周期
• 软件生命周期的概念 • 传统软件生命周期的各个阶段
统一软件开发过程模型适用的范围极为广泛，但是对开发人员的素质要求较高。
29
敏捷过程与极限编程
随着计算机技术的迅猛发展和全球化进程的加快，软件需求常 常发生变化，强烈的市场竞争要求更快速的开发软件，同时软件 也能够以更快的速度更新。传统的方法在开发时效上时常面临挑 战，因此，强调快捷、小文档、轻量级的敏捷开发方法开始流行。 敏捷方法是一种轻量级的软件工程方法，相对于传统的软件工程 方法，它更强调软件开发过程中各种变化的必然性，通过团队成 员之间充分的交流与沟通以及合理的机制来有效地响应变化。
11
几种模型之间的关系
5．软件测试 软件测试是保证软件质量的关键步骤。软件测试的目的是发现软件产品中存在的 软件缺陷，进而保证软件产品的质量。在软件开发的实践中，软件缺陷的产生是必然 的。软件缺陷发现得越晚，弥补缺陷所需的成本就越高，损失也就越大。为了尽早发 现软件缺陷，有效地进行软件测试是必须的。按照测试点的不同，测试可以分为单元 测试、集成测试、系统测试和验收测试。
17
快速原型模型
快速原型的基本思想是快速建 立一个能反映用户主要需求的原型系 统，让用户在计算机上试用它，通过 实践来了解目标系统的概貌。通常， 用户试用原型系统之后会提出许多修 改意见，开发人员按照用户的意见快 速地修改原型系统，然后再次请用户 试用……反反复复地改进，直到原型 系统满足用户的要求。
5
第二节
软件生命周期
• 软件生命周期的概念 • 传统软件生命周期的各个阶段
统一软件开发过程模型适用的范围极为广泛，但是对开发人员的素质要求较高。
29
敏捷过程与极限编程
随着计算机技术的迅猛发展和全球化进程的加快，软件需求常 常发生变化，强烈的市场竞争要求更快速的开发软件，同时软件 也能够以更快的速度更新。传统的方法在开发时效上时常面临挑 战，因此，强调快捷、小文档、轻量级的敏捷开发方法开始流行。 敏捷方法是一种轻量级的软件工程方法，相对于传统的软件工程 方法，它更强调软件开发过程中各种变化的必然性，通过团队成 员之间充分的交流与沟通以及合理的机制来有效地响应变化。
11
几种模型之间的关系
5．软件测试 软件测试是保证软件质量的关键步骤。软件测试的目的是发现软件产品中存在的 软件缺陷，进而保证软件产品的质量。在软件开发的实践中，软件缺陷的产生是必然 的。软件缺陷发现得越晚，弥补缺陷所需的成本就越高，损失也就越大。为了尽早发 现软件缺陷，有效地进行软件测试是必须的。按照测试点的不同，测试可以分为单元 测试、集成测试、系统测试和验收测试。
17
快速原型模型
快速原型的基本思想是快速建 立一个能反映用户主要需求的原型系 统，让用户在计算机上试用它，通过 实践来了解目标系统的概貌。通常， 用户试用原型系统之后会提出许多修 改意见，开发人员按照用户的意见快 速地修改原型系统，然后再次请用户 试用……反反复复地改进，直到原型 系统满足用户的要求。
软件测试 第2章软件测试过程模型及标准
第2章软件测试过程模型及标准第一节回顾1.软件过程模型：软件开发全部过程、活动和任务的结构框架也称软件开发模型或软件生存周期模型2.典型的软件过程模型：瀑布模型，演化模型，增量模型，原型模型，螺旋模型，喷泉模型，基于构件的开发模型，形式方法模型3.瀑布模型（包含计算机系统工程）（如图所示）将软件放在计算机系统工程中，考察软件在计算机系统扮演什么角色，软件做什么，区分哪些事情由硬件完成，哪些事情软件完成，哪些事情由人完成。
4.瀑布模型（不包含计算机系统工程）（如图所示）第二节软件测试过程模型1.模型：描述软件测试全部过程、活动和任务的结构框架2.典型的软件测试模型：2.1V模型2.2W模型2.3H模型2.4TMap模型第三节V模型1.V模型描述软件开发各阶段与软件测试类别的关系2.V模型的左分支展示了软件开发的活动（和传统瀑布模型的开发步骤相一致），右分支展示了软件测试的类别特点：3.可根据V模型确定各软件测试阶段的测试要求4.可针对开发活动的不同特点为不同的测试类别设计不同的测试用例5.体现测试人员参与开发的全过程6.V模型（含计算机系统工程）（如图所示）7.V模型（不含计算机系统工程）（如图所示）8.V模型右侧的测试级别随软件开发程度的加深而对应不同级别的测试阶段a)单元测试：主要针对详细设计和编码的测试b)集成测试：主要针对概要设计的测试c)系统测试：主要针对软件系统或计算机系统的测试d)验收测试：主要由用户进行的测试缺点：V模型把测试过程作为在需求定义、需求分析、系统概要设计、系统详细设计及编码之后的一个阶段。
容易使人理解为测试是软件开发的最后阶段，测试主要针对程序进行，而需求定义、需求分析、系统概要设计、详细设计阶段隐藏的问题一直到后期的系统测试和验收测试才被发现。
第四节W模型1.V模型中增加各开发阶段应同步进行的验证和确认活动，演化成W模型2.W模型由两个V组成，一个V代表开发过程，另一个V代表测试过程优点：3.体现了尽早地、不断地进行软件测试4.体现了测试对象不仅是程序代码，还包括需求分析、设计等阶段的工作产品，测试与开发同步进行。
软件工程第二章软件过程
第二章：软件过程目标：软件工程和软件过程模型的概念；了解3个一般的软件过程模型及何时使用它们；了解软件需求工程，软件开发，测试和进化中所涉及的基本过程活动；理解为什么软件过程要有效地组织以应对软件需求和设计上的变更；了解Rational统一过程是如何集成好的软件过程实践来产生一个可适应的软件过程。
所有的软件过程都必须具有4种对软件工程来说是基本的活动。
它们是：1.软件描述：必须定义软件的功能以及软件操作上的约束。
2.软件设计和实现：必须生产符合描述的软件。
3.软件有效性验证：软件必须得到有效性验证，即确保软件是客户所想要的。
4.软件进化：软件必须进化以满足不断变化的客户需要。
2.1软件过程模型一软件过程模型一般有1.瀑布模型：该模型将基本的过程活动，描述，开发，有效性验证和进化，看成是一些界限分明的独立的过程阶段，例如，需求描述阶段，软件设计阶段，实现阶段，测试阶段，等等。
2.增量式开发：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统的开发是建立一系列的版本（增量），每个版本添加部分功能到先前的版本中。
3.面向复用的软件工程：该方法使得描述活动，开发活动和有效性验证活动交织在一起。
系统开发过程着重于集成这些组件到新系统中，而非从头开发。
2.1.1瀑布模型一瀑布模型中的主要阶段直接映射基本的开发活动：1.需求分析和定义2.系统和软件设计3.实现和单元测试4.集成和系统测试5.运行和维护二适合采用瀑布模型的时候瀑布模型是与其他工程过程模型相一致的，在它的每个阶段都要生成文档。
这使得过程是可见的，项目经理能够根据项目计划监控项目的过程。
它的主要问题在于它将项目生硬地分解成这些清晰的阶段。
关于需求的责任和义务一定要在过程的早期阶段清晰界定，而这又意味它对用户需求变更的响应较困难。
所以只有在对需求了解的好，而且在系统开发过程中不太可能发生重大改变的时候，适合采用瀑布模型。
瀑布模型的一个重要变形是形式化系统开发。
02-第二章-软件开发模型-软件工程教案-海南大学(共15章)
值得注意的是，首先必须有由单位领导签发
的系统开发任务书，任务书的内容应简洁明了、
全面完整而具体，以作为系统需求分析和开发工作 的依据。 可行性研究报告批准之后，便可着手进行软件 计划工作。对软件作用范围、工作环境和基本功能、 特性加以研究，确定要做什么，不要做什么，做到 什么程序。同时，估算出所需的资金、工作量、费 用和进度。编制系统开发初步进度计划表。
瀑布模型各个阶段的任务与文档
瀑布模型法明确规定了每个阶段的任务。 上一阶段完成确定的任务后就产生一定格式 的文档交给下一阶段。不同阶段的任务一般 由不同级别的软件人员来承担。 瀑布模型法适合于在软件需求比较明确、 开发技术比较成熟、工程管理比较严格的场 合下使用。 例如工资管理、会计系统软件的需求比较 明确，就适合于使用瀑布模型法进行开发。
快速原型模型包含的内容 ⑴ 功能选择 要恰当选择原型实现的功能。根据 用户基本需求，对系统给出初步定义。 用户的基本需求包括各种功能的要求、 数据结构、菜单和屏幕、报表内容和格 式等要求。这些要求虽是概略的，但是 最基本的，易于描述和定义。原型和最 终的软件系统不同，两者在功能范围上 的区别主要有以下两个方面：
• 问题定义——系统解决什么问题、目标、范围 • 可行性分析——了解用户要求及观察环境、收集资料、数据流程、技术、
经济、操作可行性、组织、人力、物力、效益
开发时期 • 需求分析——弄清用户的全部需求，用“需求规格说明书”准确地表达出来；
建立系统目标逻辑模型——即“做什么”
• 软件设计——分为总体设计与详细设计，产生软件结构、数据结构、用户界
快速原型模型的基本思想
在获得用户基本需求说明的基础上，投入少量人 力和物力，快速建立一个原始模型，使用户及时运 行和看到模型的概貌和使用效果，并对需求说明进 行补充和精化，提出改进意见，开发人员进一步修 改完善，如此循环迭代，直到得到一个用户满意的 模型为止。 从原型法的基本思想中可以看到，用户能及早 看到系统模型，在循环迭代修改和完善过程中，使 用户的需求日益明确，从而消除了用户需求的不确 定性，同时从原型到模型的生成，周期短、见效 快，对环境变化的适应能力较强。
的系统开发任务书，任务书的内容应简洁明了、
全面完整而具体，以作为系统需求分析和开发工作 的依据。 可行性研究报告批准之后，便可着手进行软件 计划工作。对软件作用范围、工作环境和基本功能、 特性加以研究，确定要做什么，不要做什么，做到 什么程序。同时，估算出所需的资金、工作量、费 用和进度。编制系统开发初步进度计划表。
瀑布模型各个阶段的任务与文档
瀑布模型法明确规定了每个阶段的任务。 上一阶段完成确定的任务后就产生一定格式 的文档交给下一阶段。不同阶段的任务一般 由不同级别的软件人员来承担。 瀑布模型法适合于在软件需求比较明确、 开发技术比较成熟、工程管理比较严格的场 合下使用。 例如工资管理、会计系统软件的需求比较 明确，就适合于使用瀑布模型法进行开发。
快速原型模型包含的内容 ⑴ 功能选择 要恰当选择原型实现的功能。根据 用户基本需求，对系统给出初步定义。 用户的基本需求包括各种功能的要求、 数据结构、菜单和屏幕、报表内容和格 式等要求。这些要求虽是概略的，但是 最基本的，易于描述和定义。原型和最 终的软件系统不同，两者在功能范围上 的区别主要有以下两个方面：
• 问题定义——系统解决什么问题、目标、范围 • 可行性分析——了解用户要求及观察环境、收集资料、数据流程、技术、
经济、操作可行性、组织、人力、物力、效益
开发时期 • 需求分析——弄清用户的全部需求，用“需求规格说明书”准确地表达出来；
建立系统目标逻辑模型——即“做什么”
• 软件设计——分为总体设计与详细设计，产生软件结构、数据结构、用户界
快速原型模型的基本思想
在获得用户基本需求说明的基础上，投入少量人 力和物力，快速建立一个原始模型，使用户及时运 行和看到模型的概貌和使用效果，并对需求说明进 行补充和精化，提出改进意见，开发人员进一步修 改完善，如此循环迭代，直到得到一个用户满意的 模型为止。 从原型法的基本思想中可以看到，用户能及早 看到系统模型，在循环迭代修改和完善过程中，使 用户的需求日益明确，从而消除了用户需求的不确 定性，同时从原型到模型的生成，周期短、见效 快，对环境变化的适应能力较强。
软件工程(第3版)第2章 人民邮电出版社PPT课件
用于成功开发软件的一组基本观念和原则
6条“最佳实践” 10个“流程要素”
可重用方法内容及流程构建块的框架
可以在定义自己的开发方法和过程
底层方法及流程定义语言
统一方法架构元模型 UML
RUP最佳实践
迭代式开发 需求管理 使用基于组件的架构 可视化建模 验证软件质量 控制软件变更
问题定义 可行性研究 需求分析 概要设计 详细设计 编码和单元测试 集成测试（综合测试） 软件维护
瀑布模型
收集需求 分析 设计 编码 测试 维护
瀑布模型 - 加入迭代过程
收集需求 分析 设计 编码 测试 维护
快速原型法
快速建立一个反映用户 主要需求的原型系统
可视化编程工具的广泛 使用
架构和组件
软件架构（Software Architecture）
构成系统的组件 组件之间的关联和交互
架构刻画了系统的整体设计
去掉了细节部分 突出了系统的重要特征
可视化建模
由于应用领域不同，模型可以有文字、图形或数学 表达式等多种形式，一般说来，使用可视化的图形 更容易令人理解。
验证软件质量
用户故事 需求
测试用例 新用户故事
差错
隐喻 架构试探
制定交付 交付计划 计划
不确定的估计
确定的估计
最新版本
用户认可
迭代开发
验收测试
下一次迭代
小交付
难点试探
XP(极限编程Extreme Programming)的整体开发过程
极限编程
未完成的任务 用户故事 交付计划 项目速率
新用户故事 新项目速率
共享的信息
能力成熟度模型的结构
能力成熟度等级
初始级 可重复级 已定义级 已管理级 优化级
6条“最佳实践” 10个“流程要素”
可重用方法内容及流程构建块的框架
可以在定义自己的开发方法和过程
底层方法及流程定义语言
统一方法架构元模型 UML
RUP最佳实践
迭代式开发 需求管理 使用基于组件的架构 可视化建模 验证软件质量 控制软件变更
问题定义 可行性研究 需求分析 概要设计 详细设计 编码和单元测试 集成测试（综合测试） 软件维护
瀑布模型
收集需求 分析 设计 编码 测试 维护
瀑布模型 - 加入迭代过程
收集需求 分析 设计 编码 测试 维护
快速原型法
快速建立一个反映用户 主要需求的原型系统
可视化编程工具的广泛 使用
架构和组件
软件架构（Software Architecture）
构成系统的组件 组件之间的关联和交互
架构刻画了系统的整体设计
去掉了细节部分 突出了系统的重要特征
可视化建模
由于应用领域不同，模型可以有文字、图形或数学 表达式等多种形式，一般说来，使用可视化的图形 更容易令人理解。
验证软件质量
用户故事 需求
测试用例 新用户故事
差错
隐喻 架构试探
制定交付 交付计划 计划
不确定的估计
确定的估计
最新版本
用户认可
迭代开发
验收测试
下一次迭代
小交付
难点试探
XP(极限编程Extreme Programming)的整体开发过程
极限编程
未完成的任务 用户故事 交付计划 项目速率
新用户故事 新项目速率
共享的信息
能力成熟度模型的结构
能力成熟度等级
初始级 可重复级 已定义级 已管理级 优化级
第2章 软件生存期模型
➢ 每个构件由多个相互作用的模块构成，并且能够 完成特定的功能。
2.3 增量模型
➢ 增量模型如图所示。
2.3 增量模型
• 增量模型的优点
(1)能在较短时间内向用户提交可完成一些有用的工作产品， 即从第1个构件交付之日起，用户就能做一些有用的工作。
(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适 应新产品，从而减少一个全新的软件可能给用户组织带来 的冲击。
在维护和开发之间并没有本质区别。
2.4 螺旋模型
• 螺旋模型的缺点
➢ 螺旋模型是风险驱动的，因此要求软件开发人员 必须具有丰富的风险评估经验和这方面的专门知 识，否则将出现真正的风险：当项目实际上正在 走向灾难时，开发人员可能还以为一切正常。
2.4
➢ 多数场合，软件开发过程是沿螺旋线的路径连 续进行的。
2.6 统一过程
• 统一过程的阶段
③ 构造阶段。构造阶段是建立系统，构造信息系统 的第1个具有操作质量的版本，以能够交付给客户 进行测试的版本结束，有时称为测试版本。
④ 移交阶段。移交阶段包含测试时期，以发布完 整的系统而终止，其目标是确保信息系统真正满 足客户的需求。
2.6 统一过程
• 主要工作产品
➢ 原型建造模型和螺旋模型既是迭代模型，又是进 化模型。
➢ 实践中，客户利用迭代或增量模型尽快开发第一 个版本的软件制品，占领市场的有利商机，然后 再逐步扩展系统功能，不断推出后续版本。
2.5 喷泉模型
• 喷泉模型是典型的面向 对象生命周期模型。
➢ “喷泉”一词体现了迭 代和无间隙特性。图中 代表不同阶段的圆圈相 互重叠，这明确表示两 个活动之间存在重叠。
2.3 增量模型
• 采用增量模型需注意的问题
2.3 增量模型
➢ 增量模型如图所示。
2.3 增量模型
• 增量模型的优点
(1)能在较短时间内向用户提交可完成一些有用的工作产品， 即从第1个构件交付之日起，用户就能做一些有用的工作。
(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适 应新产品，从而减少一个全新的软件可能给用户组织带来 的冲击。
在维护和开发之间并没有本质区别。
2.4 螺旋模型
• 螺旋模型的缺点
➢ 螺旋模型是风险驱动的，因此要求软件开发人员 必须具有丰富的风险评估经验和这方面的专门知 识，否则将出现真正的风险：当项目实际上正在 走向灾难时，开发人员可能还以为一切正常。
2.4
➢ 多数场合，软件开发过程是沿螺旋线的路径连 续进行的。
2.6 统一过程
• 统一过程的阶段
③ 构造阶段。构造阶段是建立系统，构造信息系统 的第1个具有操作质量的版本，以能够交付给客户 进行测试的版本结束，有时称为测试版本。
④ 移交阶段。移交阶段包含测试时期，以发布完 整的系统而终止，其目标是确保信息系统真正满 足客户的需求。
2.6 统一过程
• 主要工作产品
➢ 原型建造模型和螺旋模型既是迭代模型，又是进 化模型。
➢ 实践中，客户利用迭代或增量模型尽快开发第一 个版本的软件制品，占领市场的有利商机，然后 再逐步扩展系统功能，不断推出后续版本。
2.5 喷泉模型
• 喷泉模型是典型的面向 对象生命周期模型。
➢ “喷泉”一词体现了迭 代和无间隙特性。图中 代表不同阶段的圆圈相 互重叠，这明确表示两 个活动之间存在重叠。
2.3 增量模型
• 采用增量模型需注意的问题
第2章 软件过程成熟度
软件过程成熟度
软件过程成熟度是指对具体软件过程进行明 确定义、管理、度量和控制的有效程度。成熟 意味着软件过程能力持续改善的过程，成熟度 代表软件过程能力改善的潜力。成熟度等级用 来描述某一成熟度等级上的组织特征，每一等 级都为下一等级奠定基础，过程的潜力只有在 一定的成熟度基础之上才能够被充分发挥。
2.2.1 CMM基本内容介绍
CMM描述一条从无序的、混乱的过程到成熟的、 有纪律的过程的改进途径，描绘出软件组织如何 增加对软件开发和维护的过程控制，如何向软件 工程和管理的优秀文化演变等方面的指导。
CMM还包含了有关软件开发和维护的策划、工 程化和管理的关键实践。遵循这些关键实践，就 能改进组织在实现有关成本、进度、功能和产品 质量等目标上的能力。
软件过程成熟度
成熟度级别的改善，包括管理者和软件从业 者基本工作方式的改变。组织成员依据建立的软 件过程标准执行并监控软件过程，一旦来自组织 和管理上的障碍被清除后，有关技术和过程的改 善进程就能迅速推进。
2.1 过程成熟度标准
为了清楚理解软件过程成熟度标准，首先可 以从反面来看过程成熟度，也就是了解不成熟 软件过程的特点。不成熟软件过程特点的对立 面，就是获得过程成熟度要求的出发点，从而 最终定义出过程成熟度标准。
CMM自问世以来备受关注，在一些发达国家和 地区得到了广泛应用，成为衡量软件公司软件 开发管理水平的重要参考因素和软件过程改进 领域之事实上的工业标准。
2.2 能力成熟度模型概述
2.2.1 CMM的基本内容介绍 2.2.2 系统工程能力模型 2.2.3 集成化产品开发模型 2.2.4 CMMI介绍
2.2.1 CMM基本内容介绍
设计CMM，还出于下列目的考虑。
(1) 基于现实的实践、反映最好的实践状态。 (2) 反映从事软件过程改进、软件过程评估或软
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
单元测试 系统测试 验收测试 运行与维护
12
瀑布模型
可行性研究
需求分析
总体设计
详细设计
• 是一种使用广泛，以文 档为驱动的模型
• 一直被用来规范软件开 发活动
• 很多其它模型都是在瀑 布模型基础上的改进
编码 单元测试 系统测试 验收测试 运行与维护
13
瀑布模型的特点和优点
可行性研究 需求分析 总体设计 详细设计
1. 构造原型采用的技术和 工具不一定主流
2. 快速建立起来的系统加 上连续的修改可能导致原 型质量低下
系统的具体需求不明确或者开发者不确定技术方案或者算 法是否可行的情况
42
小结：传统软件过程模型
增量模型
1. 软件作为一系列增量开发和交付 2. 能够看到软件的中间产品，降低开 发风险 3. 逐步交付，软件开发能够较好地适 应需求的变化 4. 软件能够更早投入市场 5. 开放式体系结构，便于维护
11
瀑布模型（Waterfall model）
可行性研究 需求分析 总体设计 详细设计
• 规定了各项软件工程活动， 以及它们自上而下，相互 衔接的固定次序，如同瀑 布流水，逐级下落
编码
• Winston Royce在1970年 提出
• 第一个软件过程模型 • 软件开发过程与软件生命
周期是一致的，也称经典 生命周期模型
编码
20
V模型：验收测试发现问题
可行性研究 需求分析
确认需求
运行与维护 验收测试
分析 设计
总体设计 详细设计
系统测试 单元测试
测试
编码
21
原型化模型（Prototype model）
• 快速原型模型（Rapid prototype model） • 原型（prototype）：
– 一个部分开发的产品，使客户和开发人员能够对计划开 发的系统的相关方面进行检查。
• 使用该模型需要有相当丰富的风险评估经验和专门 知识，要求开发队伍水平较高，否则会带来更大风 险。
适用场合 适用于需求不明确或者需求可能 发生变化的大型复杂的软件系统。
39
喷泉模型（Fountain model）
• 面向对象开发过程 • 开发早期定义对象，整个
开发过程充实和扩充对象 • 各个阶段使用统一的概念
• 举例1：
– 图书馆管理系统 – 所有主要界面
• 举例2：
– 智能家居系统 – 少量的室内信息监视和电器控制
22
原型化模型
• 原型化的目的：
– 明确并完善需求，如演示原型 – 研究技术选择方案，如技术验证原型
• 原型结果
– 抛弃原型 – 把原型发展成最终产品
23
原型化模型
①
策划/修改 原型需求
• 无法适应需求不明确和需求的变化； • 不能反映实际的开发方式，软件开发需要迭代。
16
瀑布模型的适用场合
适用场合 瀑布模型适用于系统需求明确且稳 定、技术成熟、工程管理较严格的 场合，如军工、航天、医疗。
17
V模型（V-model）：瀑布模型的变种
可行性研究
运行与维护
需求分析
确认需求
验收测试
分析 设计
④
和客户沟 通
用户 满意
需求分析
②
构建/修改 原型系统
③
部署原型 系统
快！ Rapid！
设计
实现
测试
维护
24
原型化模型的优点和缺点
• 优点：
– 减少需求不明确带来的风险
• 缺点：
– 构造原型采用的技术和工具不一定主流 – 快速建立起来的系统加上连续的修改可能导致原型质量
低下 – 设计者在质量和原型中进行折中
2. 产生大量文档，极大地增 加了工作量
3. 无法适应需求不明确和需 求的变化
适合系统 需求明确 且稳定、 技术成熟、 工程管理 较严格的 场合
其它软件过程模型的基础
41
小结：传统软件过程模型
原型化模型
1. 通过建立原型明确并 完善需求或者研究技术 方案的可行性
2. 减少需求不明确或者 方案不可行带来的风险
运行 计算机：我做了什么
6
软件生命周期
• Software life cycle • 软件定义：做什么 • 软件开发：怎么做 • 软件维护
• 问题定义 • 可行性研究 • 需求分析
• 总体设计 • 详细设计 • 编码 • 测试
设计 实现
7
软件生命周期
问题定义 可行性研究 需求分析 总体设计 详细设计 编码 测试 维护
需求分析
设计
编码
测试
交付 发布n
增量可能无法集成 风险较大
最终产品
29
增量模型
开
发 构建增量1 系 统
构建增量2 构建增量3 …
时间
运
行
发布1
发布2
发布3
…
系
统
• 把软件作为一系列增量来设计、编码、测试和交付 • 每个增量的开发可用瀑布模型或者原型模型 • 增量模型是一种进化式的开发过程
30
增量的方式
总体设计
验证设计
系统测试
验证设计
详细设计
单元测试
测试
编码
18
V模型：单元测试发现问题
可行性研究
运行与维护
需求分析
验收测试
分析 设计
总体设计
系统测试
验证设计
详细设计
单元测试
测试
编码
19
V模型：系统测试发现问题
可行性研究
运行与维护
需求分析
验收测试
分析 设计
总体设计
验证设计
系统测试
详细设计
单元测试
测试
4
软件开发过程
客户要求 客户：我想要什么
需求分析 分析员：我能让软件提供什么
设计 设计员：我让软件怎么做
实现 程序员：我让计算机怎么做
测试 测试员：计算机做得正确吗
运行 计算机：我做了什么
5
过程的含义
• 过程（Process)：一组有序的 任务，产生某种输出
– 规定了所有主要的活动； – 遵从一组约束，产生中间结果和
开发进度 顺时针为进展方向
评估方案 风险分析 构造原型
风险分析
风险分析
预算、方案、约束
风险分析
风险分析 原型1
原型2
生命周期计划 需求计划 开发计划
操作概念 需求确认
软件需求
集成和测试计划
设计验收 测试
集成 测试
原型3
可运行 的原型
软件设计 详细设计
单元 编码
测试
开发与验证
增 量 方 式
创建文本
增加 新功能
组织文本 创建文本
格 增加 式 新功能 化
文 本
组织文本 创建文本
迭 格 组织文本 改进 格 组织文本 改进 格 组织文本
代式
功能 式
功能 式
方化
化
化
式 文 创建文本
文 创建文本
文 创建文本
本
本
本
实际使用中，常常是两种方式的结合
31
增量模型优点和缺点
• 优点：
– 产品逐步交付，软件开发能够较好地适应需求的变化 – 能够看到软件的中间产品，提出改进意见，减少返工，
• 每个阶段都有与其相关联 的里程碑和可交付产品；
• 每个阶段结束前完成文档 审查,及早改正错误。
编码
• 阶段间具有顺序性和依赖 性；
单元测试 系统测试
• 推迟实现的观点；
验收测试
运行与维护
14
实际（带反馈）的瀑布模型
可行性研究
需求分析
总体设计
详细设计
编码
• 当后面阶段发现前面阶 段的错误，则沿反馈线
27
增量模型
需求分析
体系结构 设计
开放式结构
增量1
设计
（创建文本）
编码
测试
交付
发布1
增量2
设计
（组织文本）
编码
测试
交付
发布2
增量n
设计
（格式化文本）
编码
测试
交付 发布n
最终产品
28
增量模型
增量1 （创建文本）
需求分析
设计
编码
测试
交付 发布1
增量2 （组织文本）
需求分析
设计
编码
测试
交付 发布2
增量n （格式化文本）
降低开发风险 – 软件能够更早投入市场 – 开放式体系结构，便于维护
• 缺点：
– 软件必须具备开放式体系结构（困难） – 易退化成边做边改的方式，使软件过程控制失去整体性
32
增量模型的适用场合
适用场合 适用于软件开发中需求可能发生变 化、具有较大风险、或者希望尽早 进入市场的项目。
33
螺旋模型（Spiral model）
• 原型可作为继续开发的基础； • 螺旋模型特别强调原型的可扩充性和可修改性，原
型的进化贯穿整个软件生存周期，这将有助于目标 软件的适应能力，支持用户需求的动态变化； • 螺旋模型为项目管理人员及时调整管理决策提供了 方便，进而可降低开发风险。
38
螺旋模型的缺点
• 如果每次迭代的效率不高，致使迭代次数过多，将 会增加成本并推迟提交时间；
1. 软件必须具 备开放式体系 结构
2. 易退化成边 做边改的方式
软件开发中需求可能发生变化、具有较大风险、或者希望 尽早进入市场的项目
43
小结：传统软件过程模型
螺旋模型
1. 把开发活动和风险管理结合起来 2. 开发过程分成若干次迭代，每一次迭代都进 行风险分析，并通过原型化降低或消除风险