软件工程思想——维护与再生工程
软件工程导论PPT课件-第8章-维护
分析评价，修改设计，编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序，缺乏必要的文档说 明，难于确定数据结构、系统接口等特性的情况下，进行 的软件维高昂
明显代价：高昂的维护费用，已上升达80%左右； 无形代价：
的工作环境，或适应已变动的数据或文件； （4）为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等，或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
《软件工程》第10章 软件维护
北京大学远程教育课程
Software Engineering_Chapter10－2
问题定义
计划 时期 可行性论证 及软件计划
需求分析
概要设计 开发 时期
详细设计Байду номын сангаас
编码
测试 运行时期 运行／维护
北京大学远程教育课程
Software Engineering_Chapter10－3
本章主要内容
• 10.1 软件维护的定义,目标与任务 • 10.2 软件维护的类型 • 10.3 软件的可维护性
北京大学远程教育课程
Software Engineering_Chapter10－13
10.2.1 改正性维护（续）
• 实践表明，软件测试和排错不可能完全暴露并改正一个大 型软件系统中的所有错误。 • 经过统计分析，在典型的市场销售的软件包中，还有缺陷 的代码行约占代码总行数的3％。正式投入使用的软件中 含有错误是不足为奇的，即使是已运行多年的软件。 • 改正性维护举例：
北京大学远程教育课程
Software Engineering_Chapter10－6
10.1.3 软件维护的任务
• 一个软件开发机构60％的精力用在维护现有的软件上。随 着产品的增加，这个比例还将不断提高。不仅当前的软件 版本要维护，仍在使用的旧版本和即将投入使用的新版本 也将需要维护。 • 在软件整个运行周期中，不仅要解决原有问题，还要解决 修改过程中产生的新问题。因此软件维护是一个无穷尽的 过程。
Software Engineering_Chapter10－18
10.2.4 预防性维护
• 维护人员不要单纯等待用户提出维护的请求，而应该选择 那些还能使用数年、目前虽能运行，但不久就须作重大修 改或加强的软件，进行预先的维护。预防性维护可以改善 软件的可维护性，减少今后对它们维护时所需要的工作量。
软件开发流程图介绍
软件工程开发第一章软件工程基本观念1.1 软件工程的目标与常用模型软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。
对开发人员而言，如果非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二.软件工程的主要环节如图1所示,软件开发过程一般包括可行性与需求分析、系统设计、程序设计、测试和维护。
图1 软件工程环节常见的软件工程模型有：线性模型,渐增式模型,螺旋模型，快速原型模型，形式化描述模型等等。
虽然线性模型比较简单，太理想化，但是每一个非线性的模型都能转化为一系列简单的线性模式，因此在其他模式中需要灵活运用线性模式。
1.2 软件开发的基本策略1.2。
1 复用在一个新系统中，大部分的内容是成熟的,只有小部分内容是创新的.应该把大部分的时间用在小比例的创新工作上，而把小部分的时间用在大比例的成熟工作中。
我们将具有一定集成度并可以重复使用的软件组成单元称为软构件。
软件复用可以表述为:直接使用已有的软构件，即可组装（或加以合理修改）成新的系统.这样可以提高生产率和质量。
图2应用软构件产生应用软件1.2。
2 分而治之我们可以把复杂的问题分解成N个简单的问题，再逐个寻求解决方法.但是最终的目的是要保证单个的简单问题可以通过程序实现，组装后能够使原本复杂的问题得到合理解决。
1.2.3 优化——折衷优化是用以优化软件的各个质量因素，但不能面面俱到，应折衷,其目标就是协调各个质量因素，实现整体质量最优.而不能盲目得拆东墙,补西墙。
第二章软件开发过程各个环节介绍2.1 可行性分析与需求分析2。
1。
1 可行性分析要求可行性分析是从经济、技术、市场与政策及人员方面分析这个项目做还是不做。
2。
1。
2 需求分析要求当确定做之后,我们就要与客户交流，进行需求分析,但由于客户表达不清、需求自身经常变动或分析人员理解有误，都会导致需求分析困难.因此,有必要通过请教行家或者分析同类型产品，来做进一步的分析.2.2 系统设计2.2。
软件工程第八章维护
软件工程第八章维护第一点：软件维护的定义和重要性软件维护是指在软件发布后对其进行的一系列操作和活动，旨在确保软件系统的持续可用性、可靠性和性能。
软件维护是软件开发生命周期中的一个重要环节，它涉及到对软件进行修正、优化和升级。
软件维护的重要性体现在以下几个方面：1.保障软件质量：软件在实际运行过程中可能会出现各种问题，维护可以帮助及时修复这些问题，保证软件的正常运行。
2.提高用户满意度：通过维护，可以对软件进行功能优化和界面调整，使其更加符合用户的需求，提高用户的使用体验。
3.降低风险：软件维护可以帮助提前发现并解决潜在的风险，避免因软件问题导致的损失。
4.延长软件寿命：通过不断的维护和升级，可以使软件适应不断变化的环境和需求，延长其使用寿命。
5.提高开发效率：良好的维护可以避免因软件问题导致的重复开发，提高开发团队的效率。
第二点：软件维护的类型和策略软件维护可以分为以下几种类型：1.改正性维护：这种维护类型主要是针对软件中存在的问题和错误进行修复，保证软件的正常运行。
2.适应性维护：随着环境的变化和用户需求的变化，软件需要进行相应的调整和优化，以适应新的环境和工作需求。
3.完善性维护：这种维护类型主要是针对软件的功能进行增强和扩展，以满足用户的新需求。
4.预防性维护：预防性维护是为了避免软件出现潜在的问题和风险，提前对软件进行调整和优化。
在进行软件维护时，可以采取以下策略：1.计划维护：制定详细的维护计划，包括维护的时间、内容、责任人等，确保维护工作的有序进行。
2.变更管理：对于软件的修改和更新，需要进行严格的变更管理，确保每次变更都是经过审核和评估的。
3.版本控制：通过版本控制工具，对软件的不同版本进行管理，确保软件的每个版本都是可追踪和可恢复的。
4.文档管理：对软件的维护过程和结果进行详细的文档记录，方便对软件进行管理和维护。
5.持续集成：将软件的维护工作与开发工作结合起来，通过持续集成的方式，确保软件的质量和稳定性。
软件工程学维护
20-40倍。 ② 使用现代设计概念重新设计软件体系结构，对未来的维护
工作将有很大的帮助。 ③ 由于软件原型已经存在，软件开发生产率将远远高于平均
水平。 ④ 由于用户已经有较丰富的软件使用经验，所以很容易确定
为了使软件和变化了的环境（如软/硬件升级、新数据库 等）适当地配合而修改软件的活动。约占全部维护活动的18 % ~25%。
§1. 软件维护的定义
③ 完善性维护(perfective maintenance) 为了增加软件新功能、改已有功能（如改造界面）、增强软
件性能、提高运行效率等，而修改软件的活动。 约占全部维护活动的50% ~66%。
④ 预防性维护(preventive maintenance)
为了改进未来的可维护性或可靠性，或为了给未来的改进奠 定更好的基础而主动修改软件的活动。与其它维护活动共占总 维护的4%左右。
注：① 一般维护的工作量占生存周期70%以上，维护成本约 为开发成本的4倍；
② 文档维护与代码维护同样重要。
§2. 软件维护的特点
1、建立维护组织(maintenance team)
在维护活动开始之前就明确维护责任是十分必要的，这样可 以大大减少维护过程中可能出现的混乱。
§3. 软件维护过程
钱太少 要
任务评价
变
不干！
求 维
客户要求
化
护
授
权
人
任务评价
维护管理员
系 统 管 理 员
2、维护报告
§3. 软件维护过程
⑴ 维护要求表(Maintenance Request Form)
软件再工程
软件维护
4
图10-3 软件再工程过程模型
逆向工程是一个恢复原设计的过程。通过分析现存的
程序，从中抽取出数据、体系结构和过程的设计信息。
代码重构是在保持系统完整的体系结构基础上，对应
用系统中难于理解、测试和维护的模块重新进行编码，同
时更新文档。
数据重构是重新构建系统的数据结构。正向工程也称
革新或改造，它根据现存软件的设计信息，改变或重构现
软件维护
2
再生工程的三种类型——重构
•重构 •逆向工程 •前向工程
软件维护
3
1. 软件再工程过程模型
Pressman建议的一个软件再工程过程模型 为软件再工程定义了6类活动。 一般情况下，这些活动是顺序发生的，但每个活动都可能重复，
形成一个循环的过程。 这个过程可以在任意一个活动之后结束。 以下从信息库分析开始，依次对各类活动作简要说明。
软件工程
软件再工程
再生工程主要出于如下愿望： （1）在商业上要提高产品的竞争力；
（2） 在技术上要提高产品的质量。但这种愿望无法靠软 件的维护来实现，因为：
a) 软件的可维护性可能极差，实在不值得去做； b) 即使软件的可维护性比较好，但也只是治表不治 本。再生工程干脆对已有软件进行全部或部分的改造， 赋予软件新的活力。
存系统，以达到改善其整体软件质维护量的目的。
5
软件维护
6
2. 逆向工程
“逆向工程”起源
软件的逆向工程定义:指从源代码出发，重新恢
复设计文档和需求规格文档。
已经出现了一些CASE工具来帮助实现逆向工程，
它们或使源代码能以更清晰的方式显示，或直接从源
代码中产生流程图或结构图之类的图表。
软件工程各阶段的工作内容及特征
软件工程各阶段的工作内容及特征软件工程的目标是提高软件质量，质量因素有正确性、性能、可靠性、容错性、易用性、灵活性、可扩充性、可理解性、可维护性等等。
开发常用模型有：线性模型、渐增式模型、螺旋模型、快速原型模型、形式化描述模型等等。
“套用固定的模型不是程序员的聪明之举”。
比如“程序设计”与“测试”之间的关系，习惯上总以为程序设计在先，测试在后，而对于一些复杂的程序，将测试分为同步测试与总测试更有效。
软件开发中的三种基本策略：“复用”“分而治之”“优化—折衷”。
软件复用是将具有一定集成度并可以重复使用的软件组成单元，称为软构件。
分而治之是指把一个复杂的问题分解成若干个简单的问题，然后逐个解决。
软件的优化是指优化软件的各个质量因素，如提高运行速度，提高对内存资源的利用率，使用户界面更加友好等等。
优化工作的复杂之处是很多目标之间存在千丝万缕的关系，当不能够使所有的目标都得到优化时，就需要“折衷”策略。
软件中的折衷策略是指通过协调各个质量因素，实现整体质量的最优。
软件折衷的重要原则是不能使某一方损失关键的职能，更不可以像“舍鱼而取熊掌”那样抛弃一方。
下面从需求分析、系统分析、系统实现、测试与改错、维护与再生这五个方面逐一阐述。
2.1 需求分析阶段需求分析是项目成败与否的第一步，对需求把握得越准确，软件的修修补补就越少。
有些需求在一开始时很难确定，在开发过程中要不断地加以改正。
软件修改越早代价越少，修改越晚代价越大。
需求分析要关注到每一个最终使用者，避免遗漏使用方的需求。
需求分析尽量从多个角度进行。
需求分析需要与使用者进行多次反复沟通，开发者做到真正领会使用者的需求。
做可行性分析不能以偏盖全，也不可以什么鸡毛蒜皮的细节都加以权衡。
可行性分析必须为决策提供有价值的证据。
需要分析的工作要点有：1）完成问题整理、收集；2）走访使用部门，进行询问、沟通；3）交流中的心态定位是我们在为编辑、为业务工作；4）我们要为用户考虑。
软件工程基础之 软件维护
可维护性改进
代码重构
对代码进行重新组织和优化，使其更易于阅读、理解和维护 。
文档更新
更新软件文档，以反映软件的新功能、性能优化和修复的缺 陷，方便后续维护和开发。
05
适应性维护
环境变化处理
操作系统升级
当操作系统升级时，软件也需要进行相应的调整以适应新的操作系统。这可能涉及到修改软件与操作系统的接口、更 新系统调用等。
软件版本控制
为了确保软件的版本兼容性和升级的顺利进行，需要进行软件版本的控制和管理 。这可能涉及到版本号的分配、版本升级流程的制定和实施等。
兼容性测试
在软件升级后，需要进行兼容性测试以确保新版本软件与旧版本软件的兼容性。 这可能涉及到测试用例的设计、测试环境的搭建和测试执行等。
THANKS
感谢观看
04
完善性维护
功能增强
增加新功能
根据用户需求或市场需求，对软 件进行功能扩展或升级，增加新 的特性和功能。
优化现有功能
对现有功能进行改进和调整，提 高其性能、稳定性和用户体验。
性能优化
提升运行速度
通过优化算法、减少冗余计算或使用 更高效的存储结构等方式，提高软件 的运行速度。
降低资源消耗
优化软件对内存、CPU等资源的利用 ，降低软件运行成本和维护成本。
文档化与标准化
文档是软件维护的重要依据，包 括系统架构、系统功能、接口协
议等方面的文档。
标准化则是指遵循统一的编码规 范、命名规范、接口规范等，提
高代码的可读性和可维护性。
文档化和标准化有助于提高软件 的可维护性和可扩展性，降低维
护成本。
03
改正性维护
错误识别与定位
错误报告
01
软件工程第九章
9.4.2、再生工程 、
3. 软件再生工程的风险 软件再生工程是一种软件工程活动，它与 任何软件工程项目一样，可能遇到各种风 险 (1) 过程风险(2) 人员风险(3) 应用风险 (4) 技术风险(5) 工具风险(6) 策略风险
9.1.3、软件维护的特点 、
3. 维护的特点 －－非结构化维护。因为只有源程序，而 文档很少或没有文档，维护活动只能从阅 读、理解、分析源程序开始 －－结构化维护。用软件工程思想开发的 软件具有各个阶段的文档，对于理解和掌 握软件功能、性能、系统结构、数据结构、 系统接口和设计约束有很大的作用
9.1.3、软件维护的特点 、
9.4.2、再生工程 、
再生工程综合了逆向工程的分析和设计抽 象的特点，具有对程序数据、体系结构和 逻辑的重构能力。执行重构可生成一个设 计，它产生与原来程序相同的功能，但具 有比原来程序更高的质量。
9.4.2、再生工程 、
1. 实施软件再生工程的目的 软件再生工程能够帮助软件机构降低软件演化的 风险。 再生工程可帮助软件机构补偿软件的投资。 再生工程可使得软件易于进一步变更。。 再生工程有着广阔的市场，可以取得良好的社会 效益和经济效益。 再生工程是推动自动软件维护发展的动力，因此 研究再生工程有十分重要的意义
1. 建立明确的软件质量目标和优先级，这样做有 助于提高软件的质量，降低软件生存周期的费用 。 2. 使用提高软件质量的技术和工具 (1) 模块化 (2) 结构化程序设计 (3) 使用结构化程序设计技术，提高现有系统的 可维护性
9.3.3、提高软件可维护性的方法 、
浅谈计算机软件工程的维护措施与方法
浅谈计算机软件工程的维护措施与方法计算机软件工程的维护是指在软件产品投入使用之后，为了保证软件系统的正常运行和不断改进软件功能与性能，对软件进行错误修正、功能扩展、性能优化等工作。
维护是软件工程的一个重要环节，能够提高软件系统的稳定性和用户满意度。
本文将从维护的定义、分类、措施和方法等方面进行较为详细的讨论。
一、维护的定义和分类维护是指为了保证软件系统的正常运行和不断改进软件功能与性能，对软件进行错误修正、功能扩展、性能优化等工作。
根据维护的对象和性质，可以对维护进行不同的分类，常见的分类如下：1.硬件设备维护：主要指对计算机硬件设备进行维护，如更换损坏的硬盘、内存等。
2.软件环境维护：主要指对软件运行环境进行维护，如对操作系统、数据库等进行升级或修复。
3.软件功能维护：主要指对软件功能进行扩展或改进，如增加新的功能模块或优化已有功能。
4.软件性能维护：主要指对软件性能进行优化，如提高系统的响应速度、降低资源占用等。
二、维护的措施和方法1.定期巡检和检测：定期对软件系统进行巡检，检测可能存在的问题和潜在的隐患。
可以通过观察系统日志、分析性能指标、进行功能测试等手段，及时发现并解决问题。
2.错误修复：对已经发现的错误进行修复，包括逻辑错误、算法错误、界面错误等。
可以通过修改代码、更换组件或重新设计等方式解决。
3.功能扩展：根据用户需求或市场变化，进行新功能的开发和添加。
需要进行需求分析、设计、编码和测试等全过程的工作。
4.性能优化：对软件性能进行分析和优化，包括缩短响应时间、减少资源占用等。
可以通过代码优化、算法优化、系统调整等方式提高软件的性能。
5.更新和升级：对软件进行更新和升级，包括修复已知问题、提供新功能、改进用户体验等。
可以通过发布新版本、自动更新等方式进行软件的升级。
6.维护文档更新：根据软件的变化和维护工作的记录，及时更新维护文档，保持文档与软件的一致性。
维护文档包括操作手册、用户指南、技术文档等。
《软件工程》第八章 软件维护与再工程
软件可维护性－主要影响因素
可移植性：指程序转移到一个新的计算环境的难易 程度。
影响软件可移植性的因素有：信息隐蔽原则；模块 独立；模块化；高内聚低耦合；良好的程序结构； 不用标准文本以外的语句等
一个可移植的程序应具有结构良好、灵活、不依赖 于某பைடு நூலகம்具体计算机或操作系统的性能
软件可维护性－主要影响因素
软件维护的概念－维护成本
其它一些因素：如应用的类型、数学模型、 任务的难度、IF嵌套深度、索引或下标数等， 对维护工作量也有影响
软件维护的过程－维护组织
维护组织结构图
软件维护的过程－维护组织
系统监督员一般都是对程序(某一部分)特别熟 悉的技术人员。 在维护人员对程序进行修改的过程中，由配 置管理员严格把关，控制修改的范围，对软 件配置进行审计 。 维护管理员、系统监督员、修改控制决策机 构等，均代表维护工作的某个职责范围 。
如果已经开始保存维护记录，可以对维护工作做 一些定量度量，至少可以从如下7方面进行评价：
每次程序运行平均失败的次数； 用于每一类维护活动的总人时数； 平均每个程序、每种语言、每种维护类型所必需的程序 变动数； 维护过程中增加或删除源语句平均花费的人时数； 维护每种语言平均花费的人时数； 一张维护请求表的平均周转时间； 不同维护类型所占的比例；
软件维护的过程－维护记录
软件修改报告指明：为满足维护申请报告提 出的需求所需的工作量、本次维护活动的类 别、本次维护请求的优先级、本次修改的背 景数据。在拟定进一步维护计划前，软件修 改报告要提交给修改决策机构，供进一步规 划维护活动使用 保存维护记录的第一个问题就是哪些数据值 得保存？
软件维护的过程－维护评价
软件维护的概念－维护问题
《软件工程学》第8章 维护-答案
1．软件生命周期的（ D ）工作与软件可维护性有着密切的关系。
A．编码阶段B．设计阶段C．测试阶段D．每个阶段
2．软件维护的四类维护活动是：（A）
A．改正性维护，适应性维护，完善性维护和预防性维护。
B．适应性维护，完善性维护，抢救性维护和辅助性维护。
C．改正性维护，适应性维护，完善性维护和辅助性维护。
D．适应性维护，完善性维护，抢救性维护和预防性维护。
3．一个软件产品开发完成投入使用后，常常由于各种原因需要对它做适当的变更，通常把软件交付使用后所做的变更称为（A）。
A．维护B．设计C．软件再工程D．逆向工程
4．维护的副作用可分三类，不包括（D）。
A．代码副作用B．数据副作用C．文档副作用D．人员副作用5．在整个软件维护阶段所花费的全部工作中，（C）所占的比例最大。
A．改正性维护B．适应性维护C．完善性维护D．预防性维护6．在软件维护的实施过程中，为了正确、有效地修改，需要经历以下三个步骤：分析和理解程序、修改程序和重新验证程序。
（A）是决定维护成败和质量好坏的关键。
A．分析和理解程序B．重新验证程序C．修改程序D．验收程序
7．人们称在软件运行／维护阶段对软件产品所进行的修改就是维护。
（A）是由于开发时测试的不彻底、不完全造成的。
A．改正性维护B．适应性维护C．完善性维护D．预防性维护8．黑盒测试法可有效的检查模块的内部逻辑结构的正确性。
……………………（×）9．在进行需求分析时同时考虑维护问题。
……………………（√）
10．尽可能在软件开发过程中保证各阶段文档的正确性。
……………………（√）。
软件工程导论 第8章 维护
意见。为了满足这类要求，需要进行完善性维护。这项维护活动通常占软件维护工作的大部分。
当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，出现了第四项维护活动。这项维护活动通常称为预防性维护，目前这项维护活动相对比较少。
8．2 软件维护的特点
8．2．1 结构化维护与非结构化维护差别巨大
1.非结构化维护
如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试(即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试)。非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击)，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息：
(1)满足维护要求表中提出的要求所需要的工作量；
(2)维护要求的性质；
(3)这项要求的优先次序；
(4)与修改有关的事后数据。
在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。
保存维护记录遇到的第一个问题就是，哪些数据是值得记录的?Swanson提出了下述内容：①程序标识；②源语句数；③机器指令条数；④使用的程序设计语言；⑤程序安装的日期；⑥自从安装以来程序运行的次数；⑦自从安装以来程序失效的次数；⑧程序变动的层次和标识；⑨因程序变动而增加的源语句数；⑩因程序变动而删除的源语句数；⑾每个改动耗费的人时数；⑿程序改动的日期；⒀软件工程师的名字；⒁维护要求表的标识；⒂维护类型；⒃维护开始和完成的日期；⒄累计用于维护的人时数；⒅与完成的维护相联系的纯效益。
软件工程第9章软件维护
9.2 软件维护的过程
1. 维护组织 除大的软件公司外，通常的在软件维护工作方面，并不保
持一个正式的组织。在软件开发部门，确立一个非正式的维 护组织即非正式的维护管理员来负责维护工作却是绝对必要 的。
2、维护工作的流程
用户
修改过 的软件 确定更
改要求
维护
维护人员
纠错性
严重 评价错误 严重程度
或
不严重
进行问 题分析
理解分析程序
安排计划 修改程序
要求 确认维 或
安排改正
维护实施
护类型
完
适
性维护
人
测试程序
美 或应
员
低
性 评价优
先级
性
将改正错误列入计划 安
高 进行问 排
复审 交付使用
将安排好的工
或
题分析
的软件
作量列入计划
软件维护的工作流程图
3、维护工作的组织管理
软件维护工作不仅是技术性的，它还需要大量的管理 工作与之相配合，才能保证维护工作的质量。管理部门 应对提交的修改方案进行分析和审查，并对修改带来的 影响作充分的估计，对于不妥的修改予以撤销。需修改 主文档时，管理部门更应仔细审查。
完善性 维护
50%
纠错性 维护 25%
适应性 维护21%
纠错性维护 适应性维护 完善性维护 预防性维护
9.1 .3 软件维护的特性
1.时间长、工作量大、成本高 软件的维护过程是软件生存期中最长，并且相当困难的
阶段，软件维护的工作量占整个软件生存期的70%以上， 而且还在逐年增加。因此，如何减少软件维护的工作量， 降低软件维护的成本，就成为提高软件维护效率和质量的 关键。 2.维护的副作用 （1）修改代码的副作用。在修改源代码时，由于软件的内 在结构等原因，任何一个小的修改都可能引起的错误。因 此在修改时必须特别小心。
软件工程(填空题)
1、软件工程的基本原则包括__分解__、__独立_、一致性、确定性等。
2、软件生存周期一般定义为问题定义、(可行性分析)、(总体描述)、设计、( 编码)、测试、运行与维护阶段。
3、HIPO图是由一组IPO_和一张HC__图组成。
4、UML的定义包括__UML语义_ 和__UML表示法___两个部分5、软件测试的方法有__结构测试_和_功能测试____(又称黑盒法)6、成本估算方法主要有___ 、_ 和____三种类型7、详细设计的工具有图示工具、设计语言和表格工具8、为了使用流程图描述结构化程序,限制流程图有五种基本的控制结构,即顺序型、选择型_、while型循环_、until循环、多情况选择。
9、大型软件测试包括单元测试;集成测试、确认测试和系统测试10.详细设计的工具有三种类型分别为___、__和语言工具11软件工程是从( 软件开发技术 )和( 软件工程 )两个方面研究如何运用工程学的基本原理和方法来更好地开发和维护计算机软件的一门学科。
12.数据流图的基本符号包括(1)数据源点或终点(外部实体) (2)加工(数据处理) (3)数据存储(文件) (4)数据流。
把程序从一个硬件或软件环境转移到另一种配置环境称为软件的( 可移植性)12,Jackson图除了可以表达程序结构外,还可以表达(程序结构、),它首先要分析_(数据结构_),并用适当的工具来描述。
13.白盒法包括多种具体设计程序测试用例的方法,主要目的是提高测试的_(效率).14.设计测试方案中最困难的问题是__设计测试用的输入数据__,通常的做法是用设计基本的测试方案_(设计基本的测试方案),再用_(白盒法补充一些方案_)补充一些方案。
19、在软件开发过程中要产生大量的信息,要进行大量的修改软件配置管理能协调软件开发,并使混乱减到最低程度。
20、规定功能的软件,在一定程度上对自身错误的作用(软件错误)具有屏蔽能力,则称此软件具有容错功能的软件。
软件工程电子课件第6章 软件维护及软件再工程
2021/1/17
4
6.1.2 软件维护的分类
软件需要进行维护的原因很多，归结起来主要有以下 三种：
Ø (1)故障 Ø (2)环境变化 Ø (3)用户和维护人员的要求
2021/1/17
5
6.1.2 软件维护的分类
由这些原因引进的软件维护活动分为四类，每类维护活 动的任务各不相同。 Ø (1)改正性维护(Corrective maintenance) Ø (2)适应性维护(Adaptive maintenance)
变更的范围能够容易地搞清。 Ø (5)逆向工程和再工程的工具可以使一部分作业自动化。 Ø (6)软件配置将可以在完成预防性维护的基础上建立起来。
2021/1/17
26
6.4.2 软件的逆向工程和再工程
逆向工程是从源代码中抽取出来的设计信息。作为逆向工 程的评价，要求抽取出来的信息的抽象程度越高越好。
结构化维护是在软件开发的早期应用软件工
程方法学的结果。虽然有了软件的完整配置并不
能保证维护中没有问题，但是确实能减少精力的
浪费并且能提高维护的总体质量。
Ø (2)非结构化维护
非结构化维护需要付出很大代价(浪费精力并
且遭受挫折的打击)，这种维护方式是没有使用
良好定义的方法学开发出来的软件的必然结果。
2021/1/17
逆向工程中得到的信息抽象层次(从低到高)；软件过程的 设计表示、程序和数据结构信息、数据和控制流模型和实体、 关系模型。
2021/1/17
27
6.4.2 软件的逆向工程和再工程
再工程(reengineering)，它不仅能从已存在的程序中重新 获得设计信息，而且还能使用这些信息来改建或重构现有的系 统．以改进它的综合质量。一般软件人员利用再工程重新实现 已存在的程序，同时加进新的功能或改善它的性能。
软件工程第四版复习要点答案
8.3.4故障发现发现技术包括什么【P304】
原型化、需求评审、设计评审、代码审查、单元测试
8.4集成测试（回归测试也要看）测试的方法、什么是等价类划分【P305】
8.8.1故障播种【P317】
第十一章
11.1.1S系统、P系统、E系统【P385-P386】
S系统是由规格说明形式化定义的，并且是由规格说明导出的。在S系统中，特定问题是由它应用的整个环境来规定的。它是静态的，不容易适应问题中产生的变化，常用来定义抽象的问题。
3、形成需求规格：生成需求模型构建的精确的形式化描述，作为用户和开发者之间的一个协约。
4、需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性。
5、需求管理：支持系统的需求演进、如需求变化和可跟踪性问题。
4.5UML建模面向对象用例图时序图活动图状态图类图【P112】
当对一个系统进行文档重构时，我们对源代码进行静态分析，给出更多的信息，以帮助维护人员理解和引用代码。静态分析不对实际的代码进行任何转换，仅仅是导出信息。但是，重组通过将结构不好的代码转换为结构良好的代码，真正地改变了代码。这两种技术都仅仅集中于源代码。对一个系统进行逆向工程，是指从源代码返回到它之前的产品，根据代码重新创建设计和规格说明信息。再进一步就是再工程，它是指首先对现有系统进行逆向工程，接着再对其进行“正向工程”，改变规格说明和设计以完成逻辑模型。
关键路径【P63】
关键路径是一条每个节点的时差都为零的路径，它决定了这个项目是否按进度完成。
甘特图【P65】
3.4风险【P84】
风险是一种具有负面后果的、人们不希望发生的事件。
3.6挣值【P91】
软件工程学科的四个层次
软件工程学科的四个层次
软件工程学科的四个层次分别是：软件需求阶段、软件设计阶段、软件开发阶段和软件维护阶段。
软件需求阶段是软件工程的第一个阶段，该阶段需要收集用户需求、分析需求并转化为软件系统的要求，同时明确软件系统的功能和
性能等特性。
软件设计阶段是在软件需求阶段之后的阶段，该阶段需要设计软
件系统的架构、模块、接口和数据结构等，确定软件系统的实现方式
和实现细节。
软件开发阶段是在软件设计阶段之后的阶段，该阶段需要将软件
设计转化为实际可运行的软件程序。
在这个阶段需要编写代码、进行
开发、测试和调试，并对系统进行整体验证和修正。
软件维护阶段是在软件开发阶段之后的阶段，该阶段需要对软件
系统进行修复、更新和升级等，以满足用户需求和适应新的环境。
软
件维护阶段是软件工程中最长期的阶段，需要持续不断地对软件系统
进行改进和维护。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
个人收集整理文档勿用做商业用途
维护与再生工程
编程大师曾说：“哪怕程序只有三行长，总有一天你也不得不对它维护.”
很多软件产品不是一次性地买卖.比如在电信、金融等领域，有些软件系统要用十几年，对软件进行维护是必不可少地.8.1节将介绍“软件维护地常识”，对维护活动进行分类，并解释为什么维护比较困难.
软件公司地经理们没有哪一个喜欢被维护地费用吓一跳，但软件维护地代价通常是高昂地.7.2节将说明影响维护代价地一些主要技术因素与非技术因素.
如果希望提高已有软件地质量并且提高商业竞争力，却又无法靠维护来实现，只好对已有软件进行全部或者部分地改造，这种活动叫再生工程（Reengineering）.7.3节将解释什么是再生工程，并论述再生工程地三种类型：重构（Restructure）、逆向工程（Reverse Engineering）和前向工程（Forward Engineering）.
8.1 软件维护地常识
对软件而言，“维护”是个不太直观地术语，因为软件产品在重复使用时不会被磨损，并不需要进行像对车辆或电器那样地维护.软件维护是人们对既丰富多彩又会令人心酸地活动地统称.其中丰富多彩地活动是指那些反映客观世界变化、能使软件系统更加完善地修改和扩充工作.令人心酸地活动是指那些永无修止、并且改了旧错却引起新错让人欲哭无泪地工作.
一些学者将软件维护划分为主要地三类：纠错性维护（Corrective maintenance）、适应性维护（Adaptive maintenance）和完善性维护（Perfective maintenance）：
（1）纠错性维护.由于前期地测试不可能揭露软件系统中所有替在地错误，用户在使用软件时仍将会遇到错误，诊断和改正这些错误地过程称为纠错性维护.
（2）适应性维护.由于新地硬件设备不断推出，操作系统和编译系统也不断地升级，为了使软件能适应新地环境而引起地程序修改和扩充活动称为适应性维护.
（3）完善性维护.在软件地正常使用过程中，用户还会不断提出新地需求.为了满足用户新地需求而增加软件功能地活动称为完善性维护.
Lientz 和Swanson调查发现（1980年），完善性维护约占65%，适应性维护约占18%，纠错性维护约占17%[Sommerville 1992].上述调查已是20年前地事了，我们不必太关心具体地比例，心里有数即可.
以下一些因素将导致维护工作变得困难：
（1）软件人员经常流动，当需要对某些程序进行维护时，可能已找不到原来地开发人员.只好让新手去“攻读”那些程序.
（2）人们一般难以读懂他人地程序.在勉强接受这类任务时，心里不免嘀咕：“我又不是他肚子里地虫子，怎么知道他如何编程.”
（3）当没有文档或者文档很差时，你简直不知道如何下手.
（4）很多程序在设计时没有考虑到将来要改动，程序之间相互交织，触一而牵百.即使有很好地文档，你也不敢轻举妄动，否则你有可能陷进错误堆里.
（5）如果软件发行了多个版本，要追踪软件地演化非常困难.
（6）维护将会产生不良地副作用，不论是修改代码、数据或文档，都有可能产生新地错误. （7）维护工作毫无吸引力.高水平地程序员自然不愿主动去做，而公司也舍不得让高水平地程序员去做.带着低沉情绪地低水平地程序员只会把维护工作搞得一塌糊涂.
8.2 维护地代价及其主要因素
软件维护是既破财又费神地工作.看得见地代价是那些为了维护而投入地人力与财力.而看不见地维护代价则更加高昂，我们称之为“机会成本”，即为了得到某种东西所必须放弃地东西[Mankiw 1999].把很多程序员和其它资源用于维护工作，必然会耽误新产品地开发甚至会丧失机遇，这种代价是无法估量地.
影响维护代价地非技术因素主要有：
（1）应用域地复杂性.如果应用域问题已被很好地理解，需求分析工作比较完善，那么维护代价就较低.反之维护代价就较高.
（2）开发人员地稳定性.如果某些程序地开发者还在，让他们对自己地程序进行维护，那么代价就较低.如果原来地开发者已经不在，只好让新手来维护陌生地程序，那么代价就较高.（3）软件地生命期.越是早期地程序越难维护，你很难想像十年前地程序是多么地落后（设计思想与开发工具都落后）.一般地，软件地生命期越长，维护代价就越高.生命期越短，维护代价就越低.
（4）商业操作模式变化对软件地影响.比如财务软件，对财务制度地变化很敏感.财务制度一变动，财务软件就必须修改.一般地，商业操作模式变化越频繁，相应软件地维护代价就越高.
影响维护代价地技术因素主要有：
（1）软件对运行环境地依赖性.由于硬件以及操作系统更新很快，使得对运行环境依赖性很强地应用软件也要不停地更新，维护代价就高.
（2）编程语言.虽然低级语言比高级语言具有更好地运行速度，但是低级语言比高级语言难以理解.用高级语言编写地程序比用低级语言编写地程序地维护代价要低得多（并且生产率高得多）.一般地，商业应用软件大多采用高级语言.比如，开发一套Windows环境下地信息管理系统，用户大多采用Visual Basic、Delphi或Power Builder来编程，用Visual C++地就少些，没有人会采用汇编语言.
（3）编程风格.良好地编程风格意味着良好地可理解性，可以降低维护地代价.
（4）测试与改错工作.如果测试与改错工作做得好，后期地维护代价就能降低.反之维护代价就升高.
（5）文档地质量.清晰、正确和完备地文档能降低维护地代价.低质量地文档将增加维护地代价（错误百出地文档还不如没有文档）.
8.3 再生工程
再生工程主要出于如下愿望：（1）在商业上要提高产品地竞争力；（2）在技术上要提高产品地质量.但这种愿望无法靠软件地维护来实现，因为：（1）软件地可维护性可能极差，实在不值得去做；（2）即使软件地可维护性比较好，但也只是治表不治本.再生工程干脆对已有软件进行全部或部分地改造，赋予软件新地活力.
在对待一个不良之徒时，可以进行思想教育并给予他关心和帮助，这种方式类似于“软件维护”；也可以把他关进监狱，送去劳改，这种方式相当于软件地“再生工程”；如果此人坏透顶了，就毙掉算了.
再生工程与维护地共同之处是没有抛弃原有地软件.如果把维护比作“修修补补”，那么再生工程就算是“痛改前非”.再生工程并不见得一定比维护地代价要高，但再生工程在将来获取地利益却要比通过维护得到地多.
再生工程主要有三种类型：重构、逆向工程和前向工程.
8.3.1重构
重构一般是指通过修改代码或数据以使软件符合新地要求.重构通常并不推翻原有软件地体系结构，主要是改造一些模块和数据结构.重构地一些好处如下：
（1）使软件地质量更高，或使软件顺应新地潮流（标准）.
（2）使软件地后续（升级）版本地生产率更高.
（3）降低后期地维护代价.
要注意地是，在代码重构和数据重构之后，一定要重构相应地文档.
8.3.2逆向工程
逆向工程来源于硬件世界.硬件厂商总想弄到竞争对手产品地设计和制造“奥秘”.但是又得不到现成地档案，只好拆卸对手地产品并进行分析，企图从中获取有价值地东西.我地很多同学从事集成电路设计工作，他们经常解剖国外地集成电路，甚至不作分析就原封不动地复制该电路地版图，然后投入生产，并美其名曰“反向设计”（Reverse Design）.
软件地逆向工程在道理上与硬件地相似.但在很多时候，软件地逆向工程并不是针对竞争对手地，而是针对自己公司多年前地产品.期望从老产品中提取系统设计、需求说明等有价值地信息.
8.3.3前向工程
前向工程也称预防性维护，由Miller倡导.他把这个术语解释成“为了明天地需要，把今天地方法应用到昨天地系统上”.[Pressman 1999]
乍看起来，主动去改造一个目前运行得正常地软件系统简直就是“惹事生非”.但是软件技术发展如此迅速，与其等待一个有价值地产品逐渐老死，还不如主动去更新，以获取更大地收益.其道理就同打预防性针一样.所以，预防性维护是“吃小亏占大便宜”地事.
8.4 小结
大学科研机构里地软件维护工作恐怕是做得最差地了.几乎每一批新地研究生都会把毕业生留下地软件臭骂一通，然后全部推到重做.到他毕业该走时，就轮到别人骂他地工作了.如此轮回，最终没有什么成果留下.
如果希望软件系统能活下，必须要对它进行维护.如果希望软件系统有效益，则必须设法降低维护地代价.。