软件工程课件 软件维护
合集下载
软件工程导论PPT课件-第8章-维护
改错或修改的要求不能及时满足引起的用户不满； 维护时的改动，引入潜伏错误，导致软件质量降低； 软件工程师从事维护工作造成的开发过程混乱。 生产率的大幅下降 维护工作量：生产性劳动+非生产性劳动。
分析评价，修改设计，编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序，缺乏必要的文档说 明，难于确定数据结构、系统接口等特性的情况下，进行 的软件维高昂
明显代价：高昂的维护费用，已上升达80%左右； 无形代价：
的工作环境，或适应已变动的数据或文件； （4）为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等，或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
分析评价，修改设计，编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序，缺乏必要的文档说 明，难于确定数据结构、系统接口等特性的情况下，进行 的软件维高昂
明显代价：高昂的维护费用，已上升达80%左右； 无形代价：
的工作环境，或适应已变动的数据或文件； （4）为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等，或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
软件工程 软件维护(共10张PPT)
预防性 维护4%
完善性 维护
50%
纠错性 维护 25%
适应性 维护21%
纠错性维护 适应性维护 完善性维护 预防性维护
用户
维护人员
严重
进行问
修改过
涉主及要到 用软到件测的开试软发阶的段件所的有技确阶术段。定。更
结构化维护 结构化维护
— —
指指软软件件开开改发发要过过程程求是是按按照照软软件件工工纠错性
评价错误
严重程度
或
不严重
安排改正 性维护
题分析 理解分析程序
安排计划修 改程序
维护实施 人
测试程序
适应性 完美性
或 确定数据结构、系统接口等特性。
适应性维护（Adaptive Maintenance）
员
主要用到测试阶段的技术。 涉及到软件开发的所有阶段。
低
评价优
先级
将改正错误列入计划 安
高
排
进行问
复审
软件维护的管理流程如图所示：
软件维护的管理流程
N
Y
N
Y
N Y
9.2 软件维护的特性
一、结构化维护与非结构化维护
M=P+K*EXP（C - D） M=P+K*EXP（C - D）
— 指软件开发过程是按照软件工
程方法，软件的维护过程，有一整套完整的方案、 管理部门应对提交的修改方案进行分析和审查，并对修改带来的影响作充分的估计，对于不妥的修改予以撤销。
二、软件支援技术
在软件维护阶段用于提高维护工作的效率和质 量的技术。主要用到测试阶段的技术。
（信息收集、错误原因分析、软件分析与理解、 维护方案评价、代码与文档的修改、修改后的确认。）
软件工程课件(第八章 维护)
第八章 维护8.1 软件维护的定义所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
四类维护活动： 改正性维护 适应性维护扩充与完善性维护 预防性维护⏹改正性维护(corrective maintenance)诊断和改正软件中存在的错误的活动。
通常占整个维护活动的17-21%。
⏹适应性维护(adaptive maintenance)为了和变化了的环境适当地配合而进行的修改软件的活动。
通常占整个维护活动的18-25%。
⏹完善性维护(perfective maintenance)为了满足用户在使用软件的过程中提出的增加新功能、修改已有功能或其它一般性改进的要求而进行的软件修改活动。
通常占整个维护活动的50-66%。
⏹预防性维护(preventive maintenance)为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件的活动。
通常占整个维护活动的4%。
各类维护活动的根本目的是延长软件生存期8.2 维护的特点⏹非结构化维护在软件配置的唯一成分只有程序代码的情况下所进行的维护 。
⏹结构化维护在软件配置完整的情况下所进行的维护。
8.2.2 维护的成本⏹用于维护已有软件的费用占软件总预算的比例：1970年为35-40%,1980年为40-60%,1990年为70-80%。
各类维护活动的根本目的是延长软件生存期软件 生存 周期软件诞生1年-10年个月-2年重构软件工程周期常规软件生成周期时间的估计⏹其它无形的代价：* 因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发新软件的良机。
* 当看来合理的有关错误修改或其他要求不能及时满足时将引起用户不满。
* 由于维护时的改动，在软件中引入了潜伏的故障，从而降低了软件的质量。
* 当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。
8.2.3 影响维护工作量的因素⏹系统大小⏹程序设计语言⏹系统年龄⏹数据库技术的应用⏹先进的软件开发技术⏹其它8.2.4 维护中的典型问题(1)难以跟踪软件版本的进化过程,软件的变化未在文档中反映出来.(2)难以跟踪软件的创建过程.(3)难以读懂他人程序.(4)无文档或文档不全.(5)软件人员流动性大.(6)设计时未考虑修改需要,修改困难.(7)维护工作无吸引力,缺乏成就感.8.2.5 维护的副作用(side effects)⏹由于维护或在维护过程中其它一些不期望的行为引入的错误，称为维护的副作用。
软件工程课件第9章 软件维护
安排计划 修改程序
维护实施
第 九 章
确认维 护类型 适 应 性
安排改正 性维护 员
人
测试程序
软 件 维 护
将改正错误列入计划 安
高 进行问 题分析 排 复审 交付使用 的软件
软件维护的工作流程图
9.2.3 维护工作的组织管理
软 件 工 程 软件维护工作不仅是技术性的，它还需要大量的管理工作与之相 配合，才能保证维护工作的质量。管理部门应对提交的修改方案进行 分析和审查，并对修改带来的影响作充分的估计，对于不妥的修改予 以撤销。需修改主文档时，管理部门更应仔细审查。
第 九 章
对软件进行全面、准确、迅速地理解，这是决定维护工作成败 和质量好坏的关键。
软 件 维 护
软 件 工 程
维护管理员可以是某个人，也可以是一个包括管理人员、高 级技术人员等在内的小组。维护管理员将提交的维护申请交给系 一般维护需要保持一个正式的组织机构，但委派一个非正式的 统管理员进行评价，然后由修改批准人员决定如何修改，交维护 维护管理员来负责维护工作却是绝对必要的。下图给出了一种典型 人员在系统管理人员的指导下对软件进行修改。在修改过程中， 的维护组织方式。 配置管理员对软件配置进行审查。
第 九 章
软 件 维 护
软件维护工作处于软件生命期的最后阶段，维护阶段是软 件生存期中最长的一个阶段，其费用高达整个软件生命期花费 的约60%-70％。因此，应充分认识到维护工作的重要性和迫切 性，提高软件的可维护性，减少维护的工作量和费用，延长已 开发软件的生命期，以发挥其应有的效益。
2、软件维护的目的
第 九 章
软 件 维 护
软 件 工 程
9.3.1 面向维护的技术
在软件开发阶段用来减少错误，提高软件可维护性的技术。 面向维护的技术涉及到软件开发的所有阶段。 在需求分析阶段：对用户的需求进行严格的分析定义，使 之没有矛盾和易于理解，可以减少软件 中的错误。 在设计阶段：划分模块时充分考虑将来改动或扩充的可能 性。 在编码阶段：采用灵活的数据结构，使程序相对独立于数 据的物理结构，养成良好的程序设计风格。 在测试阶段：尽可能多发现错误，保存测试用例和测试数 据等。
新版第九章-软件维护课件
• 为了满足这些要求，需要修改或再 开发软件，以扩充软件功能、增强 软件性能、改进加工效率、提高软 件的可维护性。
• 这种情况下进行的维护活动叫做完 善性维护。
精选
6
• 实践表明，在几种维护活动中，完 善性维护所占的比重最大。即大部 分维护工作是改变和加强软件，而 不是纠错。
• 完善性维护不一定是救火式的紧急 维修，而可以是有计划、有预谋的 一种再开发活动。
软件可维护性的定义
• 软件可维护性是指纠正软件系统 出现的错误和缺陷，以及为满足 新的要求进行修改、扩充或压缩 的容易程度。
• 可维护性、可使用性、可靠性是 衡量软件质量的主要质量特性。
• 软件的可维护性是软件开发阶段
各个时期的关键目标。
精选
43
• 目前广泛使用的是用如下的七 个特性来衡量程序的可维护性。 可理解性 可使用性 可测试性 可移植性 可修改性 效率 可靠性
这些技术包括：数据库管理系统、 软件开发环境、程序自动生成系 统、较高级(第四代)的语言。以 及新的开发方法、软件复用、防 错程序设计及周期性维护审查等。
精选
16
• 适应性维护 这一类维护不可避免，可以控制。 (1) 在配置管理时，把硬件、操 作系统和其它相关环境因素的可 能变化考虑在内。 (2) 把与硬件、操作系统，以及 其它外围设备有关的程序归到特 定的程序模块中。
精选
27
• 维护申请报告将由维护管理员和 系统监督员来研究处理。
• 他们应相应地做出软件修改报告， 指明：
– 所需修改变动的性质；
– 申请修改的优先级；
– 为满足某个维护申请报告，所需的 工作量；
– 预计修改后的状况.
精选
28
• 软件修改报告应提交修改负 责人，经批准后才能开始进 一步安排维护工作。
• 这种情况下进行的维护活动叫做完 善性维护。
精选
6
• 实践表明，在几种维护活动中，完 善性维护所占的比重最大。即大部 分维护工作是改变和加强软件，而 不是纠错。
• 完善性维护不一定是救火式的紧急 维修，而可以是有计划、有预谋的 一种再开发活动。
软件可维护性的定义
• 软件可维护性是指纠正软件系统 出现的错误和缺陷，以及为满足 新的要求进行修改、扩充或压缩 的容易程度。
• 可维护性、可使用性、可靠性是 衡量软件质量的主要质量特性。
• 软件的可维护性是软件开发阶段
各个时期的关键目标。
精选
43
• 目前广泛使用的是用如下的七 个特性来衡量程序的可维护性。 可理解性 可使用性 可测试性 可移植性 可修改性 效率 可靠性
这些技术包括：数据库管理系统、 软件开发环境、程序自动生成系 统、较高级(第四代)的语言。以 及新的开发方法、软件复用、防 错程序设计及周期性维护审查等。
精选
16
• 适应性维护 这一类维护不可避免，可以控制。 (1) 在配置管理时，把硬件、操 作系统和其它相关环境因素的可 能变化考虑在内。 (2) 把与硬件、操作系统，以及 其它外围设备有关的程序归到特 定的程序模块中。
精选
27
• 维护申请报告将由维护管理员和 系统监督员来研究处理。
• 他们应相应地做出软件修改报告， 指明：
– 所需修改变动的性质；
– 申请修改的优先级；
– 为满足某个维护申请报告，所需的 工作量；
– 预计修改后的状况.
精选
28
• 软件修改报告应提交修改负 责人，经批准后才能开始进 一步安排维护工作。
软件工程 第8章 软件维护 ppt
3. 维护的事件流
图8.2 维护阶段的事件流
4. 保存维护记录 ◆ 哪些数据是值得记录的? Swanson 提出了下述内容： ① 程序标识； ② 源语句数； ③ 机器指令条数； ④ 使用的程序设计语言； ⑤ 程序安装的日期； ⑥ 自从安装以来程序运行的次数； ⑦ 自从安装以来程序失效的次数； ⑧ 程序变动的层次和标识； ⑨ 因程序变动而增加的源语句数； 因程序变动而删除 的源语句数； 每个改动耗费的人时数； 程序改动的 日期； 软件工程师的名字； 维护要求表的标识； 维 护类型； 维护开始和完成的日期； 累计用于维护的 人时数； 与完成的维护相联系的纯效益。
2. 文档重构
◆ 老程序固有的特点是缺乏文档。具体情况不同，处理这
个问题的方法也不同： 1）如果一个程序是相对稳定的，正在走向其有用生命的终 点，而且可能不会再经历什么变化，那么，让它保持现 状。 2）为了便于今后的维护，必须更新文档，不是一下子把某 应用系统的文档全部都重建起来，而是只针对系统中当 前正在修改的那些部分建立完整文档。随着时间流逝， 将得到一组有用的和相关的文档。 3）如果某应用系统是完成业务工作的关键，而且必须重构 全部文档，则仍然应该设法把文档工作减少到必需的最 小量。
5. 评价维护活动 ◆根据保存的维护记录，至少可以从下述7个方面 度量维护工作：
(1) 每次程序运行平均失效的次数； (2) 用于每一类维护活动的总人时数； (3) 平均每个程序、每种语言、每种维护类型所做的程序 变动数； (4) 维护过程中增加或删除一个源语句平均花费的人时数； (5) 维护每种语言平均花费的人时数； (6) 一张维护要求表的平均周转时间； (7) 不同维护类型所占的百分比。
5. 数据重构 ◆ 与代码重构不同，数据重构发生在相当低的抽象 层次上，它是一种全范围的再工程活动。 ◆ 在大多数情况下，数据重构始于逆向工程活动， 分解当前使用的数据体系结构，必要时定义数据 模型，标识数据对象和属性，并从软件质量的角 度复审现存的数据结构。 ◆ 当数据结构较差时，应该对数据进行再工程。 ◆ 由于数据体系结构对程序体系结构及程序中的算 法有很大影响，对数据的修改必然会导致体系结 构或代码层的改变。
《软件工程》课件——第7章-软件维护
软件维护概述
（1）代码副作用。删除、修改子程序，语句符 号，标示符。修改文件的open、close时才会出现 ，修改逻辑操作符和边界条件的测试等。
（2）数据副作用。修改全局数据，重新排列I/O 表或子程序参数表和初始化控制标志和指针以及全 局常量和局部常量的再定义
（3）文档副作用。维护除了考虑源代码外，还 要考虑整个软件的配置。
软件维护类型
（4）预防性维护 预防性维护用以提高应用软件的可靠性和可
” 维护性，为了去适应未来软硬件环境的变化，我
们应主动增加新的预防性功能，使应用系统适应 各种变化而不被消除。这一维护的工作量约占整 个维护工作的4%。
软件维护类型
随着软件开发方面的进展，软件维护方法也得到了 发展，这首先体现在软件维护的分类。目前，软件企业 将自己的软件产品进行维护，基本上分为如下两类。
软件维护过程
在结构化维护方面，软件维护文档，就是对 已经存在的实现文档、设计文档、测试文档、 分析文档、用户指南进行修改，形成新的开发 文档。新的开发文档的组织方式有两种格式。
软件维护过程
（1）保存好原来的开发文档之后，直接修改原 文档，修改后形成新的小版本文档，就是在原版本 中小圆点的右一位或右二位上加1。
软件维护类型
02
软件维护类型
维护阶段是软件生存周期的最后阶段，该阶段 是花费时间最长、投入人力财力最多且难度系数最
” 大的一个阶段，不同的维护种类应该采取不同的
策略。角度不同导致分类方法不同，从而分类 结果也不同。传统的软件维护一般分为四大类 ，如表7.1所示。
表7.1 软件的4类维护
软件维护类型
第7章 软件维护
软件工程教程 电子科技大学出版社
学习目标
《软件工程》教学课件09软件维护等
完善性维护
为了满足用户新的需求或改进软件性 能而进行的修改和增强。
预防性维护
为了预防软件可能出现的问题而进行 的修改，如优化代码结构、提高系统 稳定性等。
常用软件维护技术
程序理解技术
通过阅读源代码和相关文档，理解软件的内部结构和功能。
重构技术
在不改变软件外部行为的前提下，对软件内部结构进行调整和优化， 提高软件的可维护性。
代码重构
通过对代码进行重构，提高代码的可 读性、可维护性和可扩展性，降低未 来维护的难度。
03 软件维护策略与技术
软件可维护性度量指标
可理解性
软件内部逻辑结构、 数据结构和代码的可 读性。
可测试性
软件进行测试的难易 程度，包括测试数据 的准备和执行测试的 自动化程度。
可修改性
软件进行修改、增加 或删除功能的容易程 度。
错误来源
错误可能来源于需求分析、设计、编码、测试等 各个阶段，因此需要在整个软件开发生命周期中 持续进行错误跟踪和管理。
纠正措施
纠正措施可能包括修改源代码、更新文档、重新 进行测试等，以确保错误得到彻底修复。
适应性维护
01
02
03
适应环境变化
随着外部环境的变化，如 操作系统升级、数据库迁 移等，软件需要进行适应 性维护以适应新的环境。
软件维护分类
根据维护的性质和目的，软件维护可 分为改正性维护、适应性维护、完善 性维护和预防性维护。
软件维护目标与意义
软件维护目标
确保软件的持续可用性、可靠性和效率，同时满足用户和业务需求的变化。
软件维护意义
延长软件生命周期，提高软件质量，降低软件总成本，增强用户满意度。
软件维护过程模型
软件工程软件维护课件
二、软件维护分类
按照维护的起因分类四类： 纠错性维护 适应性维护 完善性维护 预防性维护
2024/7/26
1. 纠错性维护（Corrective Maintenance）
——为改正软件系统中潜藏的错误而进行的活动。
纠错性维护是指在系统开发阶段已发生而系统测试阶段尚未发 现的错误。这方面的维护工作量占整个维护工作量的17%21%。所发现的错误有的不太重要，不影响系统的正常运行 ，其维护工作可随时进行；而有的错误非常重要，甚至影响整 个系统的正常运行，其维护工作必须制定计划，进行修改，并 且要进行复查和控制。
2024/7/26
（2）数据副作用 数据副作用是由于修改数据结构带来的副作用。容
易引起数据副作用的修改包括： ①局部和全局常量的再定义； ②记录或文件格式的再定义； ③增减数据或是由于修改数据结构的定义导致 数据结构长度的改变； ④修改全局数据； ⑤重新初始化控制标志和指针； ⑥重新排列I/O表或子程序参数表。。
2.熟悉软件系统
熟悉所维护软件的功能是非常重要的，也是进行软件维护工作的第 一步。首先阅读现有的文档，最好能对文档中提到的内容亲自进 行测试。掌握现实中软件的使用方法，确保你要知道最常用的使 用情形。有时候用户会要求提供一些已经存在的功能特性，只是 因为他们不知道软件中已经具有了这些功能。
最后只能研究代码了，试着去理解函数、模块和组件在软件中所扮 演的角色。使用调试器单步执行程序中不同的分支，查看当代码 的不同部分执行时将会发生什么。要把熟悉软件的体系结构当做 一个持续进行的过程，而不是一次就能完成的事情。当你修改bug 或添加新的特性时，可能对系统有更好的理解。以上过程一定要 记录结果，这样对维护工作有巨大的帮助。
y 队列中还有维护请求吗？
软件工程——软件维护课件
实施过程
需求分析、修改设计、修改代码、测试与验 证。
技术
模块化设计、面向对象设计、设计模式、重 构技术等。
04
完善性维护
定义与目的
定义
完善性维护是对软件系统进行修改和增强，以改进其性能、可维护性、可靠性和安全性 的过程。
目的
完善性维护旨在提高软件系统的质量，使其更好地满足用户需求，并增强系统的适应性 和稳定性。
软件工程——软件维护课件
目录
• 软件维护概述 • 改正性维护 • 适应性维护 • 完善性维护 • 软件维护的挑战与解决方案 • 软件维护最佳实践
01
软件维护概述
软件维护的定义
软件维护是指在软件运行过程中，为 了改正错误、满足新的需求或改进性 能等目的，对软件进行的修改、完善 和优化活动。
软件维护是软件生命周期中一个重要 的阶段，包括改正性维护、适应性维 护、完善性维护和预防性维护等类型 。
适应性维护
定义与目的
定义
适应性维护是指对软件系统进行修改， 使其适应软件环境的变化和满足新的要 求。
VS
目的
确保软件系统在变化的环境中能够正常运 行，提高软件的可维护性和可扩展性。
常见问题与原因
问题
软件系统无法适应环境变化或新需求。
原因
软件设计不够灵活、缺乏有效的维护机制、 代码质量差等。
实施过程与技术
定义
改正性维护是指在软件发布后，为了识别和纠正软件中的错误、缺陷或不符合需求的地方所进行的维护活动。
目的
确保软件能够满足用户的需求，修复已知的错误，提高软件的质量和可靠性。
常见问题与原因
常见问题
软件崩溃、数据丢失、功能异常、界面错误等。
原因
需求分析、修改设计、修改代码、测试与验 证。
技术
模块化设计、面向对象设计、设计模式、重 构技术等。
04
完善性维护
定义与目的
定义
完善性维护是对软件系统进行修改和增强，以改进其性能、可维护性、可靠性和安全性 的过程。
目的
完善性维护旨在提高软件系统的质量，使其更好地满足用户需求，并增强系统的适应性 和稳定性。
软件工程——软件维护课件
目录
• 软件维护概述 • 改正性维护 • 适应性维护 • 完善性维护 • 软件维护的挑战与解决方案 • 软件维护最佳实践
01
软件维护概述
软件维护的定义
软件维护是指在软件运行过程中，为 了改正错误、满足新的需求或改进性 能等目的，对软件进行的修改、完善 和优化活动。
软件维护是软件生命周期中一个重要 的阶段，包括改正性维护、适应性维 护、完善性维护和预防性维护等类型 。
适应性维护
定义与目的
定义
适应性维护是指对软件系统进行修改， 使其适应软件环境的变化和满足新的要 求。
VS
目的
确保软件系统在变化的环境中能够正常运 行，提高软件的可维护性和可扩展性。
常见问题与原因
问题
软件系统无法适应环境变化或新需求。
原因
软件设计不够灵活、缺乏有效的维护机制、 代码质量差等。
实施过程与技术
定义
改正性维护是指在软件发布后，为了识别和纠正软件中的错误、缺陷或不符合需求的地方所进行的维护活动。
目的
确保软件能够满足用户的需求，修复已知的错误，提高软件的质量和可靠性。
常见问题与原因
常见问题
软件崩溃、数据丢失、功能异常、界面错误等。
原因
软件工程课件：软件维护
软件维护
5．评价维护活动 缺乏有效的数据就无法评价维护活动。如果已经开始保 存维护记录了，则可以对维护工作做一些定量度量。至少可 以从下述7个方面度量维护工作： • 每次程序运行平均失效的次数； • 用于每一类维护活动的总人时数； • 平均每个程序、每种语言、每种维护类型所做的程序 变动数； • 维护过程中增加或删除一个源语句平均花费的人时数；
软件维护
2．适用性维护 适用性维护是为了使系统适应环境的变化而进行的维护 工作。一方面，信息系统要能够适应新的软硬件环境，以提 高系统的性能和运行效率；另一方面，应用对象在不断发生 变化，机构的调整，管理体制的改变、数据与信息需求的变 更等都将导致系统不能适应新的应用环境。如代码改变、数 据结构变化、数据格式以及输入/输出方式的变化、数据存 储介质的变化等，都将直接影响系统的正常工作。因此，有 必要对系统进行调整，使之适应应用对象的变化，满足用户 的需求。
软件维护
• 程序名称； • 源程序语句条数； • 机器代码指令条数； • 所用的程序设计语言； • 程序安装的日期； • 程序安装后的运行次数； • 与程序安装后运行次数有关的处理故障次数； • 程序改变的层次及名称； • 修改程序增加的源程序语句条数；
软件维护
• 修改程序减少的源程序语句条数； • 每次修改所付出的人时数； • 修改程序的日期； • 软件维护人员的姓名； • 维护申请报告的名称、维护类型； • 维护开始时间和维护结束时间； • 花费在维护上的累计人时数； • 维护工作的净收益等。
17%～21%
改正性 维护
预防性 维护 4%
完善性维护 50%～66%
图6-1 各种维护的比例
软件维护
需要注意的是，上述4种维护活动都必须应用于整个软 件配置，维护软件文档和维护软件的可执行代码是同样重要 的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
维护的代价高昂
软件维护的特点
维护的问题很多 —理解别人的程序很难 —文档资料不齐全 —人员组成结构变更 —模块独立性不强 —软件维护不是一项吸引人的工作
维护的组织形式
维护 请求
变更控制 管理机构
维护管理员
维护负责人
维护人员
配置管理员
维护的过程
维护申请 维护分类 影响分析 版本规划 错误修正
返回
完善性修改
确定是否采纳维护请求 确定软件维护的优先次序 和其他开发任务一起规划
返回
数据重构
程序1
程序2
程序3
……
程序m
文件1
文件2
……
文件n
程序1
程序2
程序3
……
程序m
DBMS
软件维护 （Evolvement）
内容提纲
软件演化不可避免 软件演化的处过程
软件再工程
软件演化是不可避免的
软件的缺陷需要修复 软件在使用过程中，新的需求不断出现 商业环境在不断地变化 计算机软件、硬件环境升级，需要更新现有系 统 软件的性能和可靠性需要改进
采取适当的策略，有效地处理软 件演化引起的各种问题
软件演化的处理策略
软件维护 —为了修改软件缺陷或增加新的功能而 对软件的组件进行变更 —不对软件的体系结构做重大改变 软件再工程方法 —为了避免软件退化而对软件的一部 分、甚至全部重新设计、编码和测 试，提高软件的可维护性、可靠性 等
软件维护的分类
软件维护的分类
适应性维护（Adaptive Maintenance） 要使运行的软件能适应运行环境的变动而修改 软件的过程。 预防性维护（Preventive Maintenance） 为了进一步改善软件的可靠性和易维护性，或 者为将来的维护奠定更好的基础而对软件进行 修改。
四类维护的比例
预防性 维护4%
环境适应
新功能开发
变更实施
软件发布
软件再工程
定义 —针对遗留系统，进行维护的过程 —选取整个软件或软件中的核心部分，采用先进的软 件工程方法进行设计、编写和测试的过程。 目的 —提高软件的可维护性、可靠性，以保证系统正常运 行。 优势 —减少风险 —降低成本
软件再工程——正向、逆向
软件再工程的过程模型
完善性维护（Perfective Maintenance） 扩充原有系统的功能，提高原有系统的性 能， 或满足用户的实际需要 纠错性维护（Corrective Maintenance） 对在测试阶段未能发现的，在软件投入使用 所逐渐暴露出来的错误的测试、诊断、定位、 纠错以及验证、修改的回归测试过程。
遗留系统
对象选择
反向工程
文档重构 代码重构
数据重构
正向工程
再工程系统
返回
错误修正
救火式改正 —错误十分严重，优先级高 —立即实施维护 —事后，补充副作用评价和更新文档 一般性改正 —事前，评价改正的副作用 —和其他开发任务一起，规划维护工作 —事后，更新文档
返回
适应性修改
确定软件维护的优先次序 和其他开发任务一起规划
纠错性维 护25%
完善性 维护50%
适应性 维护21%
纠错性维护 适应性维护 完善性维护 预防性维护
软件维护的特点
软件维护受开发过程影响大
结构化维护 —采用软件工程方法进行开发，保证每个阶段有完 整且详细的文档 非结构化维护 —不采用软件工程方法开发软件，软件只有程序而 欠缺文档。
软件维护的特点