软件维护PPT课件
合集下载
软件工程导论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%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
软件维护整理ppt课件

结构化维护
• 在结构化维护的过程中,所开发的软件具有各 个阶段的文档,它对于理解和掌握软件的功能、 性能、体系结构、数据结构、系统接口和设计 约束等有很大的作用。维护时,开发人员从分 析需求规格说明开始,明白软件功能和性能上 的改变,对设计说明文档进行修改和复查,再 根据设计修改进行程序变动,并用测试文档中 的测试用例进行回归测试,最后将修改后的软 件再次交付使用。这种维护有利于减少工作量 和降低成本,大大提高软件的维护效率。
• 许多大型软件公司为维护已有软件耗费大量人 力、财力。因此,必须建立一套评估、控制和 实施软件维护的机制,这就是本章重点讨论的 内容。
内容提要
▪ 软件维护的定义 ▪ 软件维护的类型 ▪ 结构化维护VS非结构化维护 ▪ 影响软件维护工作量的因素 ▪ 软件维护的过程 ▪ 可维护性 ▪ 软件维护的管理
结构化维护 非结构化维护
文档 程序
结构化维护VS非结构化维护
结构化维护
维护要求 y 文件有吗 n
非结构化维护
分析设计
苦读代码
制定计划 修改计划
编码
复审通过 y
n
n n
交付使用
找到问题 y
编码
复审通过 y
维护要求
软件
配置
代码
评价设计
评价代码
非
结
结
构 化
计划途径
?
构 化
维 护
修改设计
维 护
重编程序
重编程序
远程维护 √ 现场维护
的测评,如管理人员只能对管理人员
软件:√ 纠错维护
进行测评,教师只能测评教师。
适应维护
维护类型
完善维护
硬件: 系统设备
外部设备
《软件维护整》课件

软件维护的重要性
确保软件质量
通过软件维护,可以发现和修复 软件中存在的问题,提高软件的 质量和可靠性。
延长软件寿命
通过及时的软件维护,可以延长 软件的寿命,使其更好地适应不 断变化的应用需求。
提高用户满意度
通过软件维护,可以改进和完善 软件的功能和性能,提高用户的 使用体验和满意度。
软件维护的分类
代码质量参差不齐
由于历史原因和技术限制,一些软件系统的代码质量可能较差,这增 加了维护的难度和风险。
文档不完整或缺失
在软件开发过程中,如果没有及时编写或更新文档,可能会给软件维 护带来困难。
依赖性高
软件系统可能依赖于许多外部因素,如硬件、其他软件或网络资源。 这些因素的变化可能会影响软件系统的正常运行。
逆向工程技术
逆向工程
通过反编译、反汇编等技术手段,将软件程序还 原成可读性更高的源代码或设计文档。
逆向工程工具
如IDA Pro、Ghidra、Hopper等,支持多种编程 语言和平台。
逆向工程流程
包括反编译、反汇编、代码分析等步骤,帮助维 护人员理解软件结构和实现逻辑。
代码审查技术
代码审查
通过多人对代码进行审核和检查,确保代码 质量符合要求。
缺陷修复
根据测试结果和用户反馈,修复软件中存在 的缺陷和错误。
功能改进
根据用户需求和软件维护计划,对软件功能 进行改进和优化。
代码重构
对软件代码进行重构,优化软件结构和代码 质量,提高软件可维护性和可扩展性。
维护测试与验收
功能测试
对修复和改进后的软件进行功能测试,确保软件 功能正常。
安全测试
对修复和改进后的软件进行安全测试,确保软件 安全性得到保障。
软件工程学概述第7讲软件维护PPT课件

可能发生变化。
目的
– 适应环境变化和发展而对软件进行维护。
2020/7/27
8
(3) 改善性维护
原因
– 在软件系统运行期间,用户可能要求增加新 的功能、建议修改已有功能或提出其他改进 意见。
目的
– 为功能、增强软件性能、 改进加工效率、提高软件的可维护性。
的帮助 软件修改困难,易出错 缺乏成就感
2020/7/27
19
3 软件的可维护性
概念
– 纠正软件系统出现的错误和缺陷,以及为满 足新的要求进行修改、扩充或压缩的容易程 度。
可维护性、可使用性、可靠性是衡量软 件质量的主要质量特性。
软件的可维护性是软件开发阶段各个时 期的关键目标。
2020/7/27
20
3.1 影响软件可维护性的因素
软件开发方法
– 结构化、OO、…...
软件配置是否齐全 开发人员素质 软件系统结构是否清晰、易于理解 标准的程序设计语言 文档的结构是否标准化 …...
2020/7/27
21
3.2 衡量可维护性的质量特性
衡量软件可维护性的特性
– 可理解性 – 可使用性 – 可测试性 – 可移植性 – 可修改性 – 效率 – 可靠性
在不同的检查点,检查的重点不全相同。
(1) 需求分析的复审
– 对将来可能修改和改进的部分加注释,对软 件的可移植性加以讨论,并考虑可能影响软 件维护的系统界面
3
软件生命周期
可行性研究 需求分析 概要设计 详细设计 实现
软件定义
软件开发
2020/7/27
集成测试
确认测试
使用与维护
维护
退役
4
1.1 软件维护定义
目的
– 适应环境变化和发展而对软件进行维护。
2020/7/27
8
(3) 改善性维护
原因
– 在软件系统运行期间,用户可能要求增加新 的功能、建议修改已有功能或提出其他改进 意见。
目的
– 为功能、增强软件性能、 改进加工效率、提高软件的可维护性。
的帮助 软件修改困难,易出错 缺乏成就感
2020/7/27
19
3 软件的可维护性
概念
– 纠正软件系统出现的错误和缺陷,以及为满 足新的要求进行修改、扩充或压缩的容易程 度。
可维护性、可使用性、可靠性是衡量软 件质量的主要质量特性。
软件的可维护性是软件开发阶段各个时 期的关键目标。
2020/7/27
20
3.1 影响软件可维护性的因素
软件开发方法
– 结构化、OO、…...
软件配置是否齐全 开发人员素质 软件系统结构是否清晰、易于理解 标准的程序设计语言 文档的结构是否标准化 …...
2020/7/27
21
3.2 衡量可维护性的质量特性
衡量软件可维护性的特性
– 可理解性 – 可使用性 – 可测试性 – 可移植性 – 可修改性 – 效率 – 可靠性
在不同的检查点,检查的重点不全相同。
(1) 需求分析的复审
– 对将来可能修改和改进的部分加注释,对软 件的可移植性加以讨论,并考虑可能影响软 件维护的系统界面
3
软件生命周期
可行性研究 需求分析 概要设计 详细设计 实现
软件定义
软件开发
2020/7/27
集成测试
确认测试
使用与维护
维护
退役
4
1.1 软件维护定义
软件工程课件-第八章维护ppt

例如,在软件交付用户使用之后,解决在开发时没有测 试所有可能的执行通路而带来的问题;
2. 适应性维护
计算机科学技术领域的各个方面都在迅速进步,大约每 过38个月就有新一代的硬件宣告出现;另一方面,应用软 件的使用寿命却很容易超过十年,远远长于最初开发这个 软件时的运行环境的寿命。因此,适应性维护就是为了和 变化了的环境适当地配合而进行的修改软件的活动,是既 必要又经常的维护活动。
4. 预防性维护
当为了提高未来的可维护性或可靠性,或为了给未来的 改进工作奠定更好的基础而修改软件时,就出现了第四类维 护活动,这类维护活动称为预防性维护。通常,把预防性维 护定义为:“把今天的方法学应用于昨天的系统以满足明天 的需要”。也就是说,预防性维护就是采用先进的软件工程 方法对需要维护的软件或软件中的某一部分,主动地进行重 新设计、编码和测试。
8.3.1 维护组织 虽然通常并不需要建立正式的维护组织,但是,即使对
于一个小的软件开发团体而言,非正式地委托责任也是绝 对必要的。维护机构成员一般包括:配置管理员、维护控 制员、系统管理员、一般维护工作人员。
每个维护要求都通过维护管理员转交给相应的系统管理 员去评价,见下页图示。
维护机构
维护要求 (软件问题报告)
● 当必须把软件工程师调去从事维护工作时,将在开发 过程中造成混乱。
8.1.2.3 维护的问题很多
与软件维护有关的绝大多数问题,都可归因于软件定 义和软件开发的方法有缺点。在软件生命周期的头两个时 期没有严格而又科学的管理和规划,几乎必然会导致在最 后阶段出现问题。下面列出和软件维护有关的部分问题:
8.1.2.2 维护的代价高昂 8.1.2.3 维护的问题很多
8.1.2.1 结构化维护与非结构化维护差别悬殊
2. 适应性维护
计算机科学技术领域的各个方面都在迅速进步,大约每 过38个月就有新一代的硬件宣告出现;另一方面,应用软 件的使用寿命却很容易超过十年,远远长于最初开发这个 软件时的运行环境的寿命。因此,适应性维护就是为了和 变化了的环境适当地配合而进行的修改软件的活动,是既 必要又经常的维护活动。
4. 预防性维护
当为了提高未来的可维护性或可靠性,或为了给未来的 改进工作奠定更好的基础而修改软件时,就出现了第四类维 护活动,这类维护活动称为预防性维护。通常,把预防性维 护定义为:“把今天的方法学应用于昨天的系统以满足明天 的需要”。也就是说,预防性维护就是采用先进的软件工程 方法对需要维护的软件或软件中的某一部分,主动地进行重 新设计、编码和测试。
8.3.1 维护组织 虽然通常并不需要建立正式的维护组织,但是,即使对
于一个小的软件开发团体而言,非正式地委托责任也是绝 对必要的。维护机构成员一般包括:配置管理员、维护控 制员、系统管理员、一般维护工作人员。
每个维护要求都通过维护管理员转交给相应的系统管理 员去评价,见下页图示。
维护机构
维护要求 (软件问题报告)
● 当必须把软件工程师调去从事维护工作时,将在开发 过程中造成混乱。
8.1.2.3 维护的问题很多
与软件维护有关的绝大多数问题,都可归因于软件定 义和软件开发的方法有缺点。在软件生命周期的头两个时 期没有严格而又科学的管理和规划,几乎必然会导致在最 后阶段出现问题。下面列出和软件维护有关的部分问题:
8.1.2.2 维护的代价高昂 8.1.2.3 维护的问题很多
8.1.2.1 结构化维护与非结构化维护差别悬殊
软件工程软件维护课件

二、软件维护分类
按照维护的起因分类四类: 纠错性维护 适应性维护 完善性维护 预防性维护
2024/7/26
1. 纠错性维护(Corrective Maintenance)
——为改正软件系统中潜藏的错误而进行的活动。
纠错性维护是指在系统开发阶段已发生而系统测试阶段尚未发 现的错误。这方面的维护工作量占整个维护工作量的17%21%。所发现的错误有的不太重要,不影响系统的正常运行 ,其维护工作可随时进行;而有的错误非常重要,甚至影响整 个系统的正常运行,其维护工作必须制定计划,进行修改,并 且要进行复查和控制。
2024/7/26
(2)数据副作用 数据副作用是由于修改数据结构带来的副作用。容
易引起数据副作用的修改包括: ①局部和全局常量的再定义; ②记录或文件格式的再定义; ③增减数据或是由于修改数据结构的定义导致 数据结构长度的改变; ④修改全局数据; ⑤重新初始化控制标志和指针; ⑥重新排列I/O表或子程序参数表。。
2.熟悉软件系统
熟悉所维护软件的功能是非常重要的,也是进行软件维护工作的第 一步。首先阅读现有的文档,最好能对文档中提到的内容亲自进 行测试。掌握现实中软件的使用方法,确保你要知道最常用的使 用情形。有时候用户会要求提供一些已经存在的功能特性,只是 因为他们不知道软件中已经具有了这些功能。
最后只能研究代码了,试着去理解函数、模块和组件在软件中所扮 演的角色。使用调试器单步执行程序中不同的分支,查看当代码 的不同部分执行时将会发生什么。要把熟悉软件的体系结构当做 一个持续进行的过程,而不是一次就能完成的事情。当你修改bug 或添加新的特性时,可能对系统有更好的理解。以上过程一定要 记录结果,这样对维护工作有巨大的帮助。
y 队列中还有维护请求吗?
软件工程——软件维护课件

实施过程
需求分析、修改设计、修改代码、测试与验 证。
技术
模块化设计、面向对象设计、设计模式、重 构技术等。
04
完善性维护
定义与目的
定义
完善性维护是对软件系统进行修改和增强,以改进其性能、可维护性、可靠性和安全性 的过程。
目的
完善性维护旨在提高软件系统的质量,使其更好地满足用户需求,并增强系统的适应性 和稳定性。
软件工程——软件维护课件
目录
• 软件维护概述 • 改正性维护 • 适应性维护 • 完善性维护 • 软件维护的挑战与解决方案 • 软件维护最佳实践
01
软件维护概述
软件维护的定义
软件维护是指在软件运行过程中,为 了改正错误、满足新的需求或改进性 能等目的,对软件进行的修改、完善 和优化活动。
软件维护是软件生命周期中一个重要 的阶段,包括改正性维护、适应性维 护、完善性维护和预防性维护等类型 。
适应性维护
定义与目的
定义
适应性维护是指对软件系统进行修改, 使其适应软件环境的变化和满足新的要 求。
VS
目的
确保软件系统在变化的环境中能够正常运 行,提高软件的可维护性和可扩展性。
常见问题与原因
问题
软件系统无法适应环境变化或新需求。
原因
软件设计不够灵活、缺乏有效的维护机制、 代码质量差等。
实施过程与技术
定义
改正性维护是指在软件发布后,为了识别和纠正软件中的错误、缺陷或不符合需求的地方所进行的维护活动。
目的
确保软件能够满足用户的需求,修复已知的错误,提高软件的质量和可靠性。
常见问题与原因
常见问题
软件崩溃、数据丢失、功能异常、界面错误等。
原因
需求分析、修改设计、修改代码、测试与验 证。
技术
模块化设计、面向对象设计、设计模式、重 构技术等。
04
完善性维护
定义与目的
定义
完善性维护是对软件系统进行修改和增强,以改进其性能、可维护性、可靠性和安全性 的过程。
目的
完善性维护旨在提高软件系统的质量,使其更好地满足用户需求,并增强系统的适应性 和稳定性。
软件工程——软件维护课件
目录
• 软件维护概述 • 改正性维护 • 适应性维护 • 完善性维护 • 软件维护的挑战与解决方案 • 软件维护最佳实践
01
软件维护概述
软件维护的定义
软件维护是指在软件运行过程中,为 了改正错误、满足新的需求或改进性 能等目的,对软件进行的修改、完善 和优化活动。
软件维护是软件生命周期中一个重要 的阶段,包括改正性维护、适应性维 护、完善性维护和预防性维护等类型 。
适应性维护
定义与目的
定义
适应性维护是指对软件系统进行修改, 使其适应软件环境的变化和满足新的要 求。
VS
目的
确保软件系统在变化的环境中能够正常运 行,提高软件的可维护性和可扩展性。
常见问题与原因
问题
软件系统无法适应环境变化或新需求。
原因
软件设计不够灵活、缺乏有效的维护机制、 代码质量差等。
实施过程与技术
定义
改正性维护是指在软件发布后,为了识别和纠正软件中的错误、缺陷或不符合需求的地方所进行的维护活动。
目的
确保软件能够满足用户的需求,修复已知的错误,提高软件的质量和可靠性。
常见问题与原因
常见问题
软件崩溃、数据丢失、功能异常、界面错误等。
原因
软件维护PPT课件

2、酊剂(Tinctura,Tr.):系指药材或化学药物用不 同浓度的乙醇浸出或溶解而制得的澄清液体制剂,亦 可用流浸膏加适量乙醇稀释制成,多数酊剂供内服, 少数供外用。
含有剧毒药物的酊剂浓度为10%,而非剧毒药物的 酊剂度为20%(即100ml酊剂中含药物20克),如碘酊 (即碘酒)含碘与碘化钾。
可供参考的国外药典
日本药局方(第14改正本)JP(14) 欧洲药典(第3版)
(European Pharmacopoeia,Ph.Eup) 国际药典(第3版)
(The International Pharmacopoeia,Ph.Int) ——分三卷:第一卷(1977)收载一般分析方
法,第二卷(1981)和第三卷(1998)均收 载质量标准规格。
(4)来源或有机化合物 (12)类别;
的化学名称;
(13)规格;
(5)含量或效价规定; (14)贮藏;
(6)处方;
(15)制剂等。
(7)制法;
可供参考的国外药典
美国药典 (第24版,2000年)(The United Pharmacopoeia,USP)
美国国家处方集 (19版)(the national Formulary,NF) USP(24)-NF(19) 英国药典 (1998年版),British Pharmacopoeia, BP(1998)
9.3.3 维护的工作流程
改正性 维护要求
确定类型
完善性 或适应性
评价 优先次序 低
开发目录
评价错误 严重程度
严重
开始 问题分析
不严重 安排改正 性维护
错误改正目录 高
开始分析
人员安排
维护任务 修改后的软件
人员安排
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
• 系统管理员对维护任务做出评价之后,由变化授
权人决定应该进行的活动。
16
2. 维护报告
• 应该用标准化的格式表达所有软件维护 申请(要求)。
• 维护申请报告或称软件问题报告,由申 请维护的用户填写。
• 用户必须完整地说明产生错误的情况, 包括输入数据、错误清单以及其它有关 材料。
• 如果申请的是适应性维护或完善性维护, 用户必须提出一份修改说明书,列出所 有希望的修改。
第9章 软件维护
1
第9章 软件维护
9.1 软件维护的定义
软件维护 ---- 就是在软件已经交付使用之后,
为了改正错误或满足新的需要而修改软件的过 程。
维护的类型有四种: 改正性维护 适应性维护 扩充与完善性维护 预防性维护
2
1.改正性维护 --- Corrective Maintenance
• 在软件交付使用后,因开发时测试的不 彻底、不完全,必然会有部分隐藏的错 误遗留到运行阶段。
13
9.3 软件维护过程
• 维护过程本质上是修改和压缩了的软件定义和开 发过程,而且事实上远在提出一项维护要求之前,
与软件维护有关的工作已经开始了。 • 为了有效地进行软件维护,应事先就开始做组织
工作。 – 首先建立维护的机构 – 申明提出维护申请报告的过程及评价的过程 – 为每一个维护申请规定标准的处理步骤 – 建立维护活动的记录保管,并规定复审的标准
17
• 维护申请报告将由维护管理员和系统管理员 来研究处理。
• 他们应相应地做出软件修改报告,指明: – 所需修改变动的性质; – 申请修改的优先级; – 为满足某个维护申请报告,所需的工作量 – 预计修改后的状况.
数据输入/输出方式、数据存储介 质) 可能发生变化。
• 为使软件适应这种变化,而去修改 软件的过程就叫做适应性维护。
4
3.扩充与完善性维护 --- Perfective
Maintenance
• 在软件的使用过程中,用户往往会对软 件提出新的功能与性能要求。
• 为了满足这些要求,需要修改或再开发 软件,以扩充软件功能、增强软件性能、 改进加工效率、提高软件的可维护性。
级增加。
12
维护中的典型问题
(1) 难以跟踪软件版本的进化过程,软件 的变化未在文档中反映出来.
(2) 难以跟踪软件的创建过程. (3) 难以读懂他人程序. (4) 无文档或不全. (5) 软件人员流动性大. (6) 设计时未考虑修改需要,修改困难. (7) 维护工作无吸引力,缺乏成就感.
采用软件工程方法至少可部分地解决 与维护有关的每一个问题。
对维护工作量都有影响。 • 许多软件在开发时并未考虑将来的修改,为软件
的维护带来许多问题。 10
维护成本
• 有形的软件维护成本是花费了多少 钱,无形的维护成本有更大的影响。 – 一些合理的修复或修改请求不 能及时安排,使得客户不满意; – 变更的结果引入新的故障,使 得软件整体质量下降; – 把软件人员抽调到维护工作中, 干扰了软件开发工作。
6
各种维护所占比例:
改正性维护 பைடு நூலகம்应性维护 17%~ 21%
18%~ 25%
其它维护 4 %
扩充与完善性维护
50% ~ 60%
7
9.2 软件维护的特点 -- 影响维护工作量的因素
• 在软件的维护过程中,需要花费大量的工作量, 从而直接影响了软件维护的成本。
• 应当考虑有哪些因素影响软件维护的工作量, 相应应该采取什么维护策略,才能有效地维护 软件并控制维护的成本。
• 数据库技术的应用:使用数据库,可以简单而有效 地管理和存储用户程序中的数据,还可以减少生成 用户报表应用软件的维护工作量。
9
• 先进的软件开发技术:在软件开发时,若使用能 使软件结构比较稳定的分析与设计技术,及程序 设计技术,如面向对象技术、复用技术等,可减 少大量的工作量。
• 其它:
– 应用的类型 – 数学模型 – 任务的难度 – 开关与标记、IF嵌套深度、索引或下标数等
• 系统大小:系统越大,理解掌握起来越困难。 系统越大,所执行功能越复杂。因而需要更多 的维护工作量。
• 程序设计语言:使用强功能的程序设计语言可 以控制程序的规模。语言的功能越强,生成程 序的模块化和结构化程度越高,所需的指令数 就越少,程序的可读性越好。
8
• 系统年龄: – 老系统随着不断的修改,结构越来越乱; – 维护人员经常更换,程序又变得越来越难于理解 – 许多老系统在当初并未按照软件工程的要求进行 开发,因而没有文档,或文档太少。 – 在长期的维护过程中文档在许多地方与程序实现 变得不一致,在维护时就会遇到很大困难。
11
M p Kecd
维护工作 量的模型
• M 是维护中消耗的总工作量
• P 是生产性工作量
• K 是一个经验常数
• c 是因缺乏好的设计和文档而导致复杂性的度量
• d 是维护人员对软件熟悉程度的度量
• 模型指明,如果使用了不好的软件开发方法(未
按软件工程要求做),原来参加开发的人员或小
组不能参加维护,则工作量(及成本)将按指数
• 这些隐藏下来的错误在某些特定的使用 环境下就会暴露出来。
• 为了识别和纠正软件错误、改正软件性 能上的缺陷、排除实施中的误使用,所
进行的诊断和改正错误的过程就叫做改 正性维护。
3
2.适应性维护 --- Adaptive Maintenance • 在使用过程中,
– 外部环境(新的硬、软件配置) – 数据环境(数据库、数据格式、
• 这种情况下进行的维护活动叫做扩充与 完善性维护。
5
4.预防性维护 --- Preventive Maintenance • 预防性维护是为了提高软件的可维
护性、可靠性等,为以后进一步改 进软件打下良好基础。 • 预防性维护定义为:采用先进的软 件工程方法对需要维护的软件或软 件中的某一部分(重新)进行设计、 编制和测试。
14
1、维护机构
• 除了较大的软件开发公司外, 通常在软件维护工作方面,并 不保持一个正式的组织机构。
• 虽然不要求建立一个正式的维 护机构,但是在开发部门确立 一个非正式的维护机构则是非 常必要的。
15
• 每个维护要求都通过维护管理员转交给相应的系 统管理员去评价(系统管理员是被指定去熟悉一 小部分产品程序的技术人员)。