软件工程第二章-软件过程
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
可以在不同抽象层次上定义模式，比如针对整个过程
的、针对框架活动的、针对动作的、针对任务的等。
一个过程模式的例子
模式名称。需求不清。 目的。该模式描述了一种构建模型（或原型系统）的方法，使得利益相关者
可以反复评估，以便识别和确定软件需求。 类型。阶段模式。
启动条件。①确定利益相关者；②已经建立起利益相关者和软件开发队伍之
下优先级进行增量开发：
第一个增量实现基本的文件管理、编辑和文档生成功能
； 第二个增量实现更加完善的编辑和文档生成功能； 第三个增量实现拼写和文法检查功能； 第四个增量完成高级的页面布局功能； ……
增量模型的特点
增量过程模型综合了线性、并行、演化三种过程流的
特征。
对于每个增量，使用的是线性过程流；
常见的几种传统过程模型：瀑布模型、V模型、增量
过程模型、原型开发模型、螺旋模型、协同模型。
附：软件生命周期
软件生命周期(Life Cycle)，也称生存周期，指软件
产品从提出、产生、发展到成熟，直至衰亡的整个 时间段。 软件生命周期的组成阶段：
1. 软件定义阶段：做什么？
问题定义→可行性研究→需求分析
件工程产品，如模型、文档、数据、报告、表格等。
软件过程的作用
软件开发过程的作用是：
成为开发组活动顺序的向导。 2. 详细说明需要开发哪些制品，何时开发。 3. 指导每一个成员及整个开发组的工作。 4. 提供监控、度量产品和活动所依据的准则。
1.
软件过程是软件项目管理控制的基础，它为项目提 供稳定性、可控性和有组织性，能有效避免混乱。 若没有一个良好定义的过程，开发组将各行其是， 成功与否完全依赖个别优秀的人才，这不是能够长 久的。
建模 分析 设计
构建 编码 测试
部署 交付 支持 反馈
瀑布模型的特点
在瀑布模型中，相邻二阶段之间存在因果关系，上
一阶段的结果是下一阶段的输入。
瀑布模型推迟了软件实现，强调在软件实现前必须
进行分析和设计工作。 瀑布模型非常规范：
1. 强迫开发人员采用规范的技术方法； 2. 严格规定每个阶段必须提交的文档(这些文档往往成为
间的沟通方式；③利益相关者确定了需要解决的主要问题；④对项目范围、 基本业务需求和项目约束条件有了初步了解。
问题。需求模糊或者不存在，但都清楚地认识到项目存在问题，且该问题需
要通过软件解决。利益相关者不确认他们想要什么；即他们无法详细描述软 件需求。 解决办法。描述了原型开发过程。
结束条件。开发了软件原型，识别了基本的需求（例如，交互模式、计算特
… 框架活动wk.baidu.com# n 动作 # n.1 任务集 …… 动作 # n.m 任务集 工作任务、工作产品、 质量保证点、项目里程碑
工作任务、工作产品、 质量保证点、项目里程碑
只有一种软件过程吗？
软件过程的种类很多，区别主要体现在几个方面： 组成过程的各个活动(包括普适性活动)、动作和任务，及其相互依 赖的关系都可能不同； 动作和任务的细化程度可能不同； 工作产品的定义和要求可能不同； 质量保证活动的应用方式可能不同； 项目跟踪和控制活动的应用方式可能不同； 过程描述的详细程度和严谨程度可能不同； 客户和利益相关者对项目参与的程度可能不同； 软件团队所赋予的自主权可能不同； 队伍组织和角色的明确程度可能不同。
征、处理功能等），并获得了利益相关者的认可。随后，可能有两种结果： ①原型系统可以通过一系列的增量开发，演化成为软件产品；或是②原型系 统被抛弃，采用其他过程模式建立产品软件。 相关的模式。客户沟通、迭代设计、迭代开发、客户评价、需求抽取。 已知应用和实例。当需求不确定时，推荐原型开发方法。
准确需求？困难！
事实上，完整而准确的需求是很难得到的，因为：
在开发早期，用户往往对系统只有一个模糊的想法，很
难完全准确地表达对系统的全面要求；
随着开发工作的推进，用户可能会产生新的要求； 开发者有可能在设计与实现的过程中遇到一些没有预料
到的实际困难，需要以改变需求来解脱困境。
因此，在很多实际项目中很难直接采用这种一次性的
W模型
制定计划 用户需求V&V 验收测试准备 用户需求获取 交付 验收测试
系统和软件需求分析
系统和软件需求 V&V，系统测试准备
部署
系统测试
概要设计
概要设计V&V 组装测试准备
组装
组装测试
详细设计
详细设计V&V 单元测试准备
单元测试
编码
评价：瀑布模型
适用条件：需求明确而稳定，如 对已有系统仅做适应性调整或增强性工作。 需求明确的新系统。 优点： 具有系统性、可控性，克服了软件开发的随意性。 以阶段评审和文档控制为手段，能及时发现并纠正缺陷。 问题： 实际项目很少按照该模型给出的顺序进行。 客户常常难以清楚地给出需求，模型缺乏灵活性。 客户须要有耐心，只有在项目接近尾声时才能得到可执行程序。 若在可执行程序评审之前没有发现系统中存在的重大缺陷，将可 能造成惨重损失。 线性流程，开发人员常需要等待，造成“阻塞状态”。 若每个阶段规定了过多的文档，会极大地增加工作量。 若管理人员以文档的完成情况来评估项目完成进度，往往会产生 错误的结论。
（路线图）是非常重要的，它有助于及时交付高质量 的产品。 所遵循的路线图就称为“软件过程”。
软件过程贯穿软件开发的各阶段，并建立阶段里程碑
（Milestones）； 管理者在软件工程过程中需要对软件开发的质量、进度、 成本进行评估、管理和控制；
技术人员在软件过程中需采用相应的方法和工具生成软
——实践者的研究方法
第二章 软件过程 (Process)
本章内容
软件过程的含义。 软件过程中有哪些共同的、基本的活动？
如何建立过程模型？什么是过程模式？
惯用(传统)过程模型 统一过程
敏捷软件开发
第一节 软件过程概述
软件过程的定义
当开发产品或构建系统时，遵循一系列可预测的步骤
该阶段的里程碑)——“由文档驱动”；
3. 每个阶段结束前必须进行正式的、严格的技术审查和
管理复审。
在实际应用时，往往会添加上“反馈”机制。
V模型
V模型是瀑布模型
的一个变体，它的 过程流和瀑布模型 一致，但V模型描 述了质量保证动作 同沟通、建模相关 动作以及早期构建 相关的动作之间的 关系。
编码
运行 时期
1. 瀑布模型
瀑布模型(waterfall model)是软件工程最早的范例，
也称经典生命周期，它提出了一个系统的、顺序的软 件开发方法，从用户需求规格说明开始，通过计划、 建模、构建和部署的过程，最终提供一个完整的软件 并提供持续的技术支持。
沟通 项目启动 需求获取 策划 项目估算 进度计划 项目跟踪
过程流
过程流(process flow)：描述了在执行顺序和执行时
间上，如何组织框架中的活动、动作和任务。 大致有四大类不同的过程流：
通用过程模型
软件过程常使用“过程模型”来表述。 一个通用的软件过程模型，包括以下工作：
选择一种过程流。 2. 定义框架活动：针对给定的问题、开发人员和利益相 关者，制定每个框架活动中需要完成哪些动作。
技术评审：评估软件工程的产品，尽量在错误传播到下一个活动
之前发现并清除错误。 测量：定义和收集过程、项目和产品的度量。 软件配置管理：管理变更所带来的影响。 可复用管理：定义产品复用标准，建立构件复用机制。 工作产品的准备和生产
软件过程框架
软 件 过 程 框 架
普适性活动 框架活动 # 1 动作 # 1.1 任务集 …… 动作 # 1.k 任务集 工作任务、工作产品、 质量保证点、项目里程碑 工作任务、工作产品、 质量保证点、项目里程碑
架活动，及一些适用于整个软件过程的普适性活动。
基本框架活动
一个通用的软件工程过程框架通常会包含以下5个基 本的框架活动：
1.
沟通：在技术工作开始前，先和利益相关者进行沟通 与协作，以理解项目目标，并收集需求。
2. 策划：制定项目计划，包括需要执行的技术任务、可
能的风险、资源需求、工作产品、工作进度计划等。 3. 建模：构思软件的体系结构、构件如何结合等。 4. 构建：包括编码和测试。
2. 软件开发阶段：如何做？
总体设计→详细设计→编码和单元测试→综合测试
3. 运行维护阶段：纠错、适应性修改、增强性修改、预
防性修改
计划 时期
问题定义 可行性研究
项目任务书 可行性报告 需求规格说明书 总体设计文档 详细设计文档 程序代码文本 测试 维护 测试报告
需求分析
开 发 时 期 总体设计
详细设计
1.
例如在沟通活动中，可能包括启动、需求获取、需求系统、 谈判、规格说明、确认等动作。
3.
明确任务集：为每个动作制定所需要的任务集。
任务集由工作任务、相关工作产品、质量保证点和项目里程 碑等部分组成。 对于不同的软件项目，即便是相同的动作，确定的任务集也 可能不一样。
4. 编写或查找过程模式。
过程模式
开发团队在软件过程里会遇到很多问题，如果团队能
得到已有的经过验证的解决方案，将有助于快速地分 析和解决问题。
因此在软件过程中，最好能将遇到的过程问题、问题
环境、解决方案等记录下来，形成过程模式(process pattern) 。 过程模式提供了一个模板——一种在软件过程的背景 下，统一描述问题解决方案的方法。
增量之间有并行；
整个过程类似于演化，本质上也是迭代的。
每一个增量都应提交一个可以运行的产品。
每次增量得到的产品要交由客户使用或仔细评价，并
根据使用或评价的结果制定下一个增量计划。
每次增量需求的划分与增量实现的集成是以不影响系
统体系结构为前提的。
评价：增量模型
优点： 适用于人手不足的情况：早期的增量可以由少量人员实 现，若核心产品的口碑不错，则再投入更多人力。 客户的需求可以逐步提出来。 能在较短时间内提交可运行产品，增强了客户的信心。 可以规避技术风险：例如，系统需要利用某个正在开发 的新硬件，则可以在早期的增量中避免使用这个硬件， 以保证部分功能按时交付，不至于造成过分的延期。 缺点： 增量粒度难以选择； 确定所有的基本业务服务比较困难。
5.
部署：交付全部软件或部分增量，由用户使用并反馈 意见。
典型的普适性活动
在软件过程中，还需要补充一些贯穿始终的普适性活动，可帮
助团队管理和控制进度、质量、变更和风险。
软件项目跟踪与控制：根据计划评估当前进度，并采取必要的措
施保证项目按进度计划进行。 风险管理：对可能影响项目成果或质量的风险进行评估。 软件质量保证
第二节 惯用过程模型 (传统过程模型)
惯用过程模型的含义
软件工程发展到现在，已经出现了很多不同的过程模
型，其中有一些可归属为“传统过程模型”。
传统过程模型以秩序和一致性作为主要问题，规定了
一整套的过程元素，包括：过程流、框架活动、软件 工程动作、任务、工作产品、质量保证、变更控制机 制等。
瀑布模型过程。
2. 增量模型
该模型先对系统最核心或最清晰的需求进行分析、设
计、实现、测试，再按优先级逐步对后续需求进行上 述工作，并集成到系统中，逐步形成一个完整系统。
一个例子
第一个增量往往是核心产品（基本需求），其他功能
和特性由后续的增量添加进去。
例如，使用增量模型开发字处理软件时，可以按照以
软件过程的组成要素
软件过程是工作产品构建时所执行的一系列活动、动
作和任务的集合。
活动(activity)：实现宽泛的大目标。 动作(action)：阶段目标。 任务(task)：关注小而明确的目标，产生实际产品。
软件过程由活动组成，活动由动作组成，动作由任务
组成。
软件过程框架(process framework)定义了若干个框
过程模型的选择要点
无论要开发软件的大小，都应选择一个合适的软件过
程模型。
选择何种软件过程模型，依赖于项目的性质、所构造
软件的特点、采用的方法、需要的控制，以及项目团 队，不同类型的软件或系统可能需要采用完全不同的 软件过程。
软件过程不是教条，它不是对如何构建软件的严格规
定，而应是一种可适应性调整的方法，要让软件过程 适合于项目团队和要开发的产品。
的、针对框架活动的、针对动作的、针对任务的等。
一个过程模式的例子
模式名称。需求不清。 目的。该模式描述了一种构建模型（或原型系统）的方法，使得利益相关者
可以反复评估，以便识别和确定软件需求。 类型。阶段模式。
启动条件。①确定利益相关者；②已经建立起利益相关者和软件开发队伍之
下优先级进行增量开发：
第一个增量实现基本的文件管理、编辑和文档生成功能
； 第二个增量实现更加完善的编辑和文档生成功能； 第三个增量实现拼写和文法检查功能； 第四个增量完成高级的页面布局功能； ……
增量模型的特点
增量过程模型综合了线性、并行、演化三种过程流的
特征。
对于每个增量，使用的是线性过程流；
常见的几种传统过程模型：瀑布模型、V模型、增量
过程模型、原型开发模型、螺旋模型、协同模型。
附：软件生命周期
软件生命周期(Life Cycle)，也称生存周期，指软件
产品从提出、产生、发展到成熟，直至衰亡的整个 时间段。 软件生命周期的组成阶段：
1. 软件定义阶段：做什么？
问题定义→可行性研究→需求分析
件工程产品，如模型、文档、数据、报告、表格等。
软件过程的作用
软件开发过程的作用是：
成为开发组活动顺序的向导。 2. 详细说明需要开发哪些制品，何时开发。 3. 指导每一个成员及整个开发组的工作。 4. 提供监控、度量产品和活动所依据的准则。
1.
软件过程是软件项目管理控制的基础，它为项目提 供稳定性、可控性和有组织性，能有效避免混乱。 若没有一个良好定义的过程，开发组将各行其是， 成功与否完全依赖个别优秀的人才，这不是能够长 久的。
建模 分析 设计
构建 编码 测试
部署 交付 支持 反馈
瀑布模型的特点
在瀑布模型中，相邻二阶段之间存在因果关系，上
一阶段的结果是下一阶段的输入。
瀑布模型推迟了软件实现，强调在软件实现前必须
进行分析和设计工作。 瀑布模型非常规范：
1. 强迫开发人员采用规范的技术方法； 2. 严格规定每个阶段必须提交的文档(这些文档往往成为
间的沟通方式；③利益相关者确定了需要解决的主要问题；④对项目范围、 基本业务需求和项目约束条件有了初步了解。
问题。需求模糊或者不存在，但都清楚地认识到项目存在问题，且该问题需
要通过软件解决。利益相关者不确认他们想要什么；即他们无法详细描述软 件需求。 解决办法。描述了原型开发过程。
结束条件。开发了软件原型，识别了基本的需求（例如，交互模式、计算特
… 框架活动wk.baidu.com# n 动作 # n.1 任务集 …… 动作 # n.m 任务集 工作任务、工作产品、 质量保证点、项目里程碑
工作任务、工作产品、 质量保证点、项目里程碑
只有一种软件过程吗？
软件过程的种类很多，区别主要体现在几个方面： 组成过程的各个活动(包括普适性活动)、动作和任务，及其相互依 赖的关系都可能不同； 动作和任务的细化程度可能不同； 工作产品的定义和要求可能不同； 质量保证活动的应用方式可能不同； 项目跟踪和控制活动的应用方式可能不同； 过程描述的详细程度和严谨程度可能不同； 客户和利益相关者对项目参与的程度可能不同； 软件团队所赋予的自主权可能不同； 队伍组织和角色的明确程度可能不同。
征、处理功能等），并获得了利益相关者的认可。随后，可能有两种结果： ①原型系统可以通过一系列的增量开发，演化成为软件产品；或是②原型系 统被抛弃，采用其他过程模式建立产品软件。 相关的模式。客户沟通、迭代设计、迭代开发、客户评价、需求抽取。 已知应用和实例。当需求不确定时，推荐原型开发方法。
准确需求？困难！
事实上，完整而准确的需求是很难得到的，因为：
在开发早期，用户往往对系统只有一个模糊的想法，很
难完全准确地表达对系统的全面要求；
随着开发工作的推进，用户可能会产生新的要求； 开发者有可能在设计与实现的过程中遇到一些没有预料
到的实际困难，需要以改变需求来解脱困境。
因此，在很多实际项目中很难直接采用这种一次性的
W模型
制定计划 用户需求V&V 验收测试准备 用户需求获取 交付 验收测试
系统和软件需求分析
系统和软件需求 V&V，系统测试准备
部署
系统测试
概要设计
概要设计V&V 组装测试准备
组装
组装测试
详细设计
详细设计V&V 单元测试准备
单元测试
编码
评价：瀑布模型
适用条件：需求明确而稳定，如 对已有系统仅做适应性调整或增强性工作。 需求明确的新系统。 优点： 具有系统性、可控性，克服了软件开发的随意性。 以阶段评审和文档控制为手段，能及时发现并纠正缺陷。 问题： 实际项目很少按照该模型给出的顺序进行。 客户常常难以清楚地给出需求，模型缺乏灵活性。 客户须要有耐心，只有在项目接近尾声时才能得到可执行程序。 若在可执行程序评审之前没有发现系统中存在的重大缺陷，将可 能造成惨重损失。 线性流程，开发人员常需要等待，造成“阻塞状态”。 若每个阶段规定了过多的文档，会极大地增加工作量。 若管理人员以文档的完成情况来评估项目完成进度，往往会产生 错误的结论。
（路线图）是非常重要的，它有助于及时交付高质量 的产品。 所遵循的路线图就称为“软件过程”。
软件过程贯穿软件开发的各阶段，并建立阶段里程碑
（Milestones）； 管理者在软件工程过程中需要对软件开发的质量、进度、 成本进行评估、管理和控制；
技术人员在软件过程中需采用相应的方法和工具生成软
——实践者的研究方法
第二章 软件过程 (Process)
本章内容
软件过程的含义。 软件过程中有哪些共同的、基本的活动？
如何建立过程模型？什么是过程模式？
惯用(传统)过程模型 统一过程
敏捷软件开发
第一节 软件过程概述
软件过程的定义
当开发产品或构建系统时，遵循一系列可预测的步骤
该阶段的里程碑)——“由文档驱动”；
3. 每个阶段结束前必须进行正式的、严格的技术审查和
管理复审。
在实际应用时，往往会添加上“反馈”机制。
V模型
V模型是瀑布模型
的一个变体，它的 过程流和瀑布模型 一致，但V模型描 述了质量保证动作 同沟通、建模相关 动作以及早期构建 相关的动作之间的 关系。
编码
运行 时期
1. 瀑布模型
瀑布模型(waterfall model)是软件工程最早的范例，
也称经典生命周期，它提出了一个系统的、顺序的软 件开发方法，从用户需求规格说明开始，通过计划、 建模、构建和部署的过程，最终提供一个完整的软件 并提供持续的技术支持。
沟通 项目启动 需求获取 策划 项目估算 进度计划 项目跟踪
过程流
过程流(process flow)：描述了在执行顺序和执行时
间上，如何组织框架中的活动、动作和任务。 大致有四大类不同的过程流：
通用过程模型
软件过程常使用“过程模型”来表述。 一个通用的软件过程模型，包括以下工作：
选择一种过程流。 2. 定义框架活动：针对给定的问题、开发人员和利益相 关者，制定每个框架活动中需要完成哪些动作。
技术评审：评估软件工程的产品，尽量在错误传播到下一个活动
之前发现并清除错误。 测量：定义和收集过程、项目和产品的度量。 软件配置管理：管理变更所带来的影响。 可复用管理：定义产品复用标准，建立构件复用机制。 工作产品的准备和生产
软件过程框架
软 件 过 程 框 架
普适性活动 框架活动 # 1 动作 # 1.1 任务集 …… 动作 # 1.k 任务集 工作任务、工作产品、 质量保证点、项目里程碑 工作任务、工作产品、 质量保证点、项目里程碑
架活动，及一些适用于整个软件过程的普适性活动。
基本框架活动
一个通用的软件工程过程框架通常会包含以下5个基 本的框架活动：
1.
沟通：在技术工作开始前，先和利益相关者进行沟通 与协作，以理解项目目标，并收集需求。
2. 策划：制定项目计划，包括需要执行的技术任务、可
能的风险、资源需求、工作产品、工作进度计划等。 3. 建模：构思软件的体系结构、构件如何结合等。 4. 构建：包括编码和测试。
2. 软件开发阶段：如何做？
总体设计→详细设计→编码和单元测试→综合测试
3. 运行维护阶段：纠错、适应性修改、增强性修改、预
防性修改
计划 时期
问题定义 可行性研究
项目任务书 可行性报告 需求规格说明书 总体设计文档 详细设计文档 程序代码文本 测试 维护 测试报告
需求分析
开 发 时 期 总体设计
详细设计
1.
例如在沟通活动中，可能包括启动、需求获取、需求系统、 谈判、规格说明、确认等动作。
3.
明确任务集：为每个动作制定所需要的任务集。
任务集由工作任务、相关工作产品、质量保证点和项目里程 碑等部分组成。 对于不同的软件项目，即便是相同的动作，确定的任务集也 可能不一样。
4. 编写或查找过程模式。
过程模式
开发团队在软件过程里会遇到很多问题，如果团队能
得到已有的经过验证的解决方案，将有助于快速地分 析和解决问题。
因此在软件过程中，最好能将遇到的过程问题、问题
环境、解决方案等记录下来，形成过程模式(process pattern) 。 过程模式提供了一个模板——一种在软件过程的背景 下，统一描述问题解决方案的方法。
增量之间有并行；
整个过程类似于演化，本质上也是迭代的。
每一个增量都应提交一个可以运行的产品。
每次增量得到的产品要交由客户使用或仔细评价，并
根据使用或评价的结果制定下一个增量计划。
每次增量需求的划分与增量实现的集成是以不影响系
统体系结构为前提的。
评价：增量模型
优点： 适用于人手不足的情况：早期的增量可以由少量人员实 现，若核心产品的口碑不错，则再投入更多人力。 客户的需求可以逐步提出来。 能在较短时间内提交可运行产品，增强了客户的信心。 可以规避技术风险：例如，系统需要利用某个正在开发 的新硬件，则可以在早期的增量中避免使用这个硬件， 以保证部分功能按时交付，不至于造成过分的延期。 缺点： 增量粒度难以选择； 确定所有的基本业务服务比较困难。
5.
部署：交付全部软件或部分增量，由用户使用并反馈 意见。
典型的普适性活动
在软件过程中，还需要补充一些贯穿始终的普适性活动，可帮
助团队管理和控制进度、质量、变更和风险。
软件项目跟踪与控制：根据计划评估当前进度，并采取必要的措
施保证项目按进度计划进行。 风险管理：对可能影响项目成果或质量的风险进行评估。 软件质量保证
第二节 惯用过程模型 (传统过程模型)
惯用过程模型的含义
软件工程发展到现在，已经出现了很多不同的过程模
型，其中有一些可归属为“传统过程模型”。
传统过程模型以秩序和一致性作为主要问题，规定了
一整套的过程元素，包括：过程流、框架活动、软件 工程动作、任务、工作产品、质量保证、变更控制机 制等。
瀑布模型过程。
2. 增量模型
该模型先对系统最核心或最清晰的需求进行分析、设
计、实现、测试，再按优先级逐步对后续需求进行上 述工作，并集成到系统中，逐步形成一个完整系统。
一个例子
第一个增量往往是核心产品（基本需求），其他功能
和特性由后续的增量添加进去。
例如，使用增量模型开发字处理软件时，可以按照以
软件过程的组成要素
软件过程是工作产品构建时所执行的一系列活动、动
作和任务的集合。
活动(activity)：实现宽泛的大目标。 动作(action)：阶段目标。 任务(task)：关注小而明确的目标，产生实际产品。
软件过程由活动组成，活动由动作组成，动作由任务
组成。
软件过程框架(process framework)定义了若干个框
过程模型的选择要点
无论要开发软件的大小，都应选择一个合适的软件过
程模型。
选择何种软件过程模型，依赖于项目的性质、所构造
软件的特点、采用的方法、需要的控制，以及项目团 队，不同类型的软件或系统可能需要采用完全不同的 软件过程。
软件过程不是教条，它不是对如何构建软件的严格规
定，而应是一种可适应性调整的方法，要让软件过程 适合于项目团队和要开发的产品。