软件工程第15章
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件的运行环境包括两个方面，硬件和 软件，软件则大体上包括操作系统、中 间件、虚拟机等等。
15.2 软件维护的分类
3. 改善性维护——根据用户在软件使用过 程中提出的建设性意见而进行的维护活 动。 主要是针对用户提出的新的软件需求或 修改原有的软件需求而进行的维护，该 种维护通常占所有维护工作量的一半以 上。软件在部署之后一段时间内，用户 的改善性维护应该是递减的。
15.2 软件维护的分类
4. 预防性维护——为了进一步改善软件系 统的可维护性和可靠性，并为以后的改 进奠定基础。 预防性维护可以采取逆向工程（reverse engineering）和重构工程（reengineering）方式。
15.2 软件维护的分类
严格按照软件工程标准生产的软件产品 在维护过程中纠错性维护的工作量很低， 不到总维护工作量的1／5。 由于改善性维护和适应性维护需要修改 需求规格说明书，应按照需求变更来进 行管理，相当于螺旋模型中的又一次迭 代过程，因此工作量很大。
修改控制决策机构
维护申请单
维护 管理员
系统 管理员
配置 管理员
维护员
图15-4-1 维护组织信息流图
维护流程
用户的维护请求激发了一次维护活动，用户 将维护申请提交给维护管理员，维护管理员 将该维护请求交给系统管理员对维护活动可 能引起的软件修改进行评估，并将评估结果 反馈给维护管理员，维护管理员按照维护请 求单制定软件修改报告单并提交给修改决策 机构进行维护决策。修改决策机构根据情况 决定采取的行动（拒绝请求还是接收请求）， 并把结果反馈给维护管理员，如果允许维护， 维护管理员将通知维护员执行该次维护。
15.2 软件维护的分类
按照维护的起ቤተ መጻሕፍቲ ባይዱ分类：
纠错性维护
四类
适应性维护 改善性维护
预防性维护四类。
1. 纠错性维护——为改正软件系统中潜藏
的错误而进行的活动。
用户在使用软件过程中发现软件的错误 是激发该种维护的起因。
15.2 软件维护的分类
2. 适应性维护——为适应软件运行环境的 变化而修改软件的活动。
15.4 软件维护过程
15.4.1 维护组织
维护组织一般由维护员，维护管理员，系统管 理员，修改控制决策机构，配置管理员组成。
维护员——真正执行维护的人员； 维护管理员——协调维护活动的人员； 系统管理员——系统的管理者； 修改控制决策机构——决定一次维护的走向。 修改控制和决策机构、用户、系统管理员、维 护人员之间不能跨越维护管理员进行沟通和采 取行动。
维护请求 配置
代码 理解代码功能 理解 ？ 修改代码 测试复审
交付使用
图15-3-1 非结构化维护和结构化维护
15.3.2 维护成本
20世纪70年代，软件的维护费用约占软 件总预算的35~40%。 80年代时，软件维护费用进一步增加， 约占软件总预算的60%。 近年来，该值已上升到80%左右。 随着软件复杂性的不断提高，软件的维 护难度越来越大。这不仅导致维护成本 不断增高，软件生产率急剧下降，还会 带来其他方面的负面影响。
可见维护工作量同软件的维护复杂度成指数关系。
15.3.3 维护可能存在的问题
1）无法追踪软件的整个创建过程。 2）无法追踪软件版本的进化过程。
软件交付使用后对软件不断修复和完善的 过程，就是软件版本的进化过程，每一次 进化都会使软件的主、次版本号增大。 3）理解别人的程序非常困难。 4）得不到开发人员的帮助。 5）软件配置不完整或不正确。 6）分析和设计的缺陷。 7）维护工作让人没有成就感。
维护工作量的估算模型
M＝P+Ke(c-d) 其中： M：维护所用工作量； P：生产性工作量 — 分析评价、修改设计和代码； Ke(c-d)：助动性工作量 — 理解文档和代码； K：经验常数； c：软件的维护复杂度，由软件本身的复杂度，软
件的设计质量以及文档化的程度等因素决定； d：维护人员对软件的熟悉程度；
在项目的各个阶段对项目的可维护性进行充分 考虑、对可维护性的严格评审以及在维护阶段 有效地组织和管理维护活动，则是保证软件可 维护性和降低维护费用的关键。
本章重点内容：维护的主要内容、维护的流程、 如何在软件的生产过程各个阶段保证软件的可 维护性目标。
15.1 软件维护的基本内容
软件维护的主要目标是使已部署的软件 按照需求规格说明书的要求（或用户的 新需求）运行，这要求软件不仅要满足 用户所需要的各项功能需求，同时还要 满足用户对软件的非功能需求。软件维 护的基本内容则包含了实现这些目标所 做的全部工作。
15.3 软件维护的特点
软件维护是一种繁琐而又不可或缺 的工作，由于维护通常要求维护人 员在用户现场进行，而且维护任务 可能非常紧急，因此对现场维护人 员的压力很大。而且没有丝毫的成 就感。
15.3.1 结构化维护与非结构化维护
非结构化维护——软件的配置中只有源 代码。 由于没有分析和设计文档，无法对程序 的功能进行反向追踪，理解别人的代码 是很痛苦的事情。 由于配置中没有测试文档，所以维护后 的代码无法进行回归测试。因而导致程 序的结构化被不断的破坏，维护的质量 无法得到保证。
15.3.1 结构化维护与非结构化维护
结构化维护——待维护的软件的配置是 完整的。 用户提出的维护申请用正向追踪很容易 从分析设计文档追踪直至代码中，从而 使维护人员很容易定位代码的维护点。 所以这种维护不会破坏软件的结构。 结构化维护不仅能减少维护的工作量， 还能提高维护的质量。
软件 理解设计 方案规划 修改设计 修改代码 测试复审
15.4.2 维护的报告与审核
用户提出的维护申请必须采用标准的格式，须填写由 维护人员制定的： 维护申请单（Maintenance Request Form，MRF） 或 软件问题报告单（Software Problem Report，SPR）。 如果是纠错性维护，应填写SPR。在填写SPR时，用 户必须完整地记录出错信息（什么错误）和出错场景 （在什么情况下出现的错误）。 其他种类的维护，要填MRF。在MRF中应该附加简 短的修改规格说明，也就是在需求规格说明书中应作 哪些改动，比如增加功能或修改功能等。
课程名称：软件工程
第25讲
班 级：
日 期：
教 室：
教学题目：第15章 软件维护
教学目的：了解维护的概念，掌握四类维护，
了解维护过程、软件的可维护性。
教学重点：维护的概念、维护过程、可维护性。
教学难点：维护过程。
教 具：多媒体教室、电子教案
作 业：
第15章 软件维护
软件维护是软件生命周期的最后一个阶段，软 件从部署完毕到退役的整个时间内对软件的改 动所做的工作都是维护的内容。
15.2 软件维护的分类
3. 改善性维护——根据用户在软件使用过 程中提出的建设性意见而进行的维护活 动。 主要是针对用户提出的新的软件需求或 修改原有的软件需求而进行的维护，该 种维护通常占所有维护工作量的一半以 上。软件在部署之后一段时间内，用户 的改善性维护应该是递减的。
15.2 软件维护的分类
4. 预防性维护——为了进一步改善软件系 统的可维护性和可靠性，并为以后的改 进奠定基础。 预防性维护可以采取逆向工程（reverse engineering）和重构工程（reengineering）方式。
15.2 软件维护的分类
严格按照软件工程标准生产的软件产品 在维护过程中纠错性维护的工作量很低， 不到总维护工作量的1／5。 由于改善性维护和适应性维护需要修改 需求规格说明书，应按照需求变更来进 行管理，相当于螺旋模型中的又一次迭 代过程，因此工作量很大。
修改控制决策机构
维护申请单
维护 管理员
系统 管理员
配置 管理员
维护员
图15-4-1 维护组织信息流图
维护流程
用户的维护请求激发了一次维护活动，用户 将维护申请提交给维护管理员，维护管理员 将该维护请求交给系统管理员对维护活动可 能引起的软件修改进行评估，并将评估结果 反馈给维护管理员，维护管理员按照维护请 求单制定软件修改报告单并提交给修改决策 机构进行维护决策。修改决策机构根据情况 决定采取的行动（拒绝请求还是接收请求）， 并把结果反馈给维护管理员，如果允许维护， 维护管理员将通知维护员执行该次维护。
15.2 软件维护的分类
按照维护的起ቤተ መጻሕፍቲ ባይዱ分类：
纠错性维护
四类
适应性维护 改善性维护
预防性维护四类。
1. 纠错性维护——为改正软件系统中潜藏
的错误而进行的活动。
用户在使用软件过程中发现软件的错误 是激发该种维护的起因。
15.2 软件维护的分类
2. 适应性维护——为适应软件运行环境的 变化而修改软件的活动。
15.4 软件维护过程
15.4.1 维护组织
维护组织一般由维护员，维护管理员，系统管 理员，修改控制决策机构，配置管理员组成。
维护员——真正执行维护的人员； 维护管理员——协调维护活动的人员； 系统管理员——系统的管理者； 修改控制决策机构——决定一次维护的走向。 修改控制和决策机构、用户、系统管理员、维 护人员之间不能跨越维护管理员进行沟通和采 取行动。
维护请求 配置
代码 理解代码功能 理解 ？ 修改代码 测试复审
交付使用
图15-3-1 非结构化维护和结构化维护
15.3.2 维护成本
20世纪70年代，软件的维护费用约占软 件总预算的35~40%。 80年代时，软件维护费用进一步增加， 约占软件总预算的60%。 近年来，该值已上升到80%左右。 随着软件复杂性的不断提高，软件的维 护难度越来越大。这不仅导致维护成本 不断增高，软件生产率急剧下降，还会 带来其他方面的负面影响。
可见维护工作量同软件的维护复杂度成指数关系。
15.3.3 维护可能存在的问题
1）无法追踪软件的整个创建过程。 2）无法追踪软件版本的进化过程。
软件交付使用后对软件不断修复和完善的 过程，就是软件版本的进化过程，每一次 进化都会使软件的主、次版本号增大。 3）理解别人的程序非常困难。 4）得不到开发人员的帮助。 5）软件配置不完整或不正确。 6）分析和设计的缺陷。 7）维护工作让人没有成就感。
维护工作量的估算模型
M＝P+Ke(c-d) 其中： M：维护所用工作量； P：生产性工作量 — 分析评价、修改设计和代码； Ke(c-d)：助动性工作量 — 理解文档和代码； K：经验常数； c：软件的维护复杂度，由软件本身的复杂度，软
件的设计质量以及文档化的程度等因素决定； d：维护人员对软件的熟悉程度；
在项目的各个阶段对项目的可维护性进行充分 考虑、对可维护性的严格评审以及在维护阶段 有效地组织和管理维护活动，则是保证软件可 维护性和降低维护费用的关键。
本章重点内容：维护的主要内容、维护的流程、 如何在软件的生产过程各个阶段保证软件的可 维护性目标。
15.1 软件维护的基本内容
软件维护的主要目标是使已部署的软件 按照需求规格说明书的要求（或用户的 新需求）运行，这要求软件不仅要满足 用户所需要的各项功能需求，同时还要 满足用户对软件的非功能需求。软件维 护的基本内容则包含了实现这些目标所 做的全部工作。
15.3 软件维护的特点
软件维护是一种繁琐而又不可或缺 的工作，由于维护通常要求维护人 员在用户现场进行，而且维护任务 可能非常紧急，因此对现场维护人 员的压力很大。而且没有丝毫的成 就感。
15.3.1 结构化维护与非结构化维护
非结构化维护——软件的配置中只有源 代码。 由于没有分析和设计文档，无法对程序 的功能进行反向追踪，理解别人的代码 是很痛苦的事情。 由于配置中没有测试文档，所以维护后 的代码无法进行回归测试。因而导致程 序的结构化被不断的破坏，维护的质量 无法得到保证。
15.3.1 结构化维护与非结构化维护
结构化维护——待维护的软件的配置是 完整的。 用户提出的维护申请用正向追踪很容易 从分析设计文档追踪直至代码中，从而 使维护人员很容易定位代码的维护点。 所以这种维护不会破坏软件的结构。 结构化维护不仅能减少维护的工作量， 还能提高维护的质量。
软件 理解设计 方案规划 修改设计 修改代码 测试复审
15.4.2 维护的报告与审核
用户提出的维护申请必须采用标准的格式，须填写由 维护人员制定的： 维护申请单（Maintenance Request Form，MRF） 或 软件问题报告单（Software Problem Report，SPR）。 如果是纠错性维护，应填写SPR。在填写SPR时，用 户必须完整地记录出错信息（什么错误）和出错场景 （在什么情况下出现的错误）。 其他种类的维护，要填MRF。在MRF中应该附加简 短的修改规格说明，也就是在需求规格说明书中应作 哪些改动，比如增加功能或修改功能等。
课程名称：软件工程
第25讲
班 级：
日 期：
教 室：
教学题目：第15章 软件维护
教学目的：了解维护的概念，掌握四类维护，
了解维护过程、软件的可维护性。
教学重点：维护的概念、维护过程、可维护性。
教学难点：维护过程。
教 具：多媒体教室、电子教案
作 业：
第15章 软件维护
软件维护是软件生命周期的最后一个阶段，软 件从部署完毕到退役的整个时间内对软件的改 动所做的工作都是维护的内容。