软件工程 第8章：维护
软件工程导论PPT课件-第8章-维护
分析评价，修改设计，编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序，缺乏必要的文档说 明，难于确定数据结构、系统接口等特性的情况下，进行 的软件维高昂
明显代价：高昂的维护费用，已上升达80%左右； 无形代价：
的工作环境，或适应已变动的数据或文件； （4）为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等，或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
软件工程课件之第8章维护第6版张海潘编著
用户文档
用户文档至少应该包括下述5方面的内容：
功能描述，说明系统能做什么； 安装文档，说明怎样安装这个系统以及怎样使系统
软件维护过程
维护报告
维护要求表或称软件问题报告表，由申请维 护的用户填写。
软件修改报告，由软件组织内部制定，指明：
满足某个维护要求表中提出的要求所需要的工 作量；
维护要求的性质； 这项要求的优先级； 与修改有关的事后数据；
维护的事件流
维护的事件流
尽管维护申请的类型不同，但都要进行同样 的技术工作：
系统文档
所谓系统文档指从问题定义、需求说明到验收 测试计划这样一系列和系统实现有关的文档。
描述系统设计、实现和测试的文档对于理解程 序和维护程序极端重要
从概貌到每个方面每个特点，从抽象到具体， 有逻辑地介绍系统
可维护性复审
在需求分析阶段的复审过程中，应该对将来要 改进的部分和可能会修改的部分加以注意并指 明；应该讨论软件的可移植性问题，并且考虑 可能影响软件维护的系统界面。
维护的问题
与软件维护有关的绝大多数问题，都可归 因于软件定义和软件开发的方法有缺点：
① 理解别人写的程序通常非常困难，而且困难程 度随着软件配置成分的减少而迅速增加。
② 需要维护的软件往往没有合格的文档，或者文 档资料显著不足。
③ 当要求对软件进行维护时，不能指望由开发人 员给我们仔细说明软件。
的。
软件维护工作量
各类维护工作量 所占比例
维护工作量在软件生 命周期所占比例
第8章 软件维护
系统年龄： – 老系统随着不断的修改，结构越来越乱； – 维护人员经常更换，程序又变得越来越难于理解 – 许多老系统在当初并未按照软件工程的要求进行 开发，因而没有文档，或文档太少。 – 在长期的维护过程中文档在许多地方与程序实现 变得不一致，在维护时就会遇到很大困难。 数据库技术的应用：使用数据库，可以简单而有效 地管理和存储用户程序中的数据，还可以减少生成 用户报表应用软件的维护工作量。
24
8.4
软件的可维护性
许多软件的维护十分困难，原因在于这些软件 的文档不全、质量差、开发过程不注意采用好 的方法，忽视程序设计风格等。 许多维护要求并不是因为程序中出错而提出的， 而是为适应环境变化或需求变化而提出的。 为了使得软件能够易于维护，必须考虑使软件 具有可维护性。 软件可维护性是指纠正软件系统出现的错误和
14
1、维护机构 除了较大的软件开发公司外， 通常在软件维护工作方面，并 不保持一个正式的组织机构。 虽然不要求建立一个正式的维 护机构，但是在开发部门确立 一个非正式的维护机构则是非 常必要的。
15
每个维护要求都通过维护管理员转交给相应的系 统管理员去评价（系统管理员是被指定去熟悉一 小部分产品程序的技术人员）。 系统管理员对维护任务做出评价之后，由变化授 权人决定应该进行的活动。 16
缺陷，以及为满足新的要求进行修改、扩充或 压缩的难易程度。
25
8.4.1 决定软件可维护性的因素
1. 可理解性 2. 可测试性 3. 可修改性 4. 可移植性 5. 可重用性
26
1. 可理解性 软件可理解性表现为外来读者理解软件的结构、 功能、接口和内部处理过程的难易程度。模块化 （模块结构良好，高内聚，松耦合）、详细的设 计文档、结构化设计、程序内部的文档和良好的 高级程序设计语言等等，都对提高软件的可理解 性有重要贡献。 2. 可测试性 诊断和测试的容易程度取决于软件容易理解的程 度。良好的文档对诊断和测试是至关重要的，此 外，软件结构、可用的测试工具和调试工具，以 及以前设计的测试过程也都是非常重要的。维护 人员应该能够得到在开发阶段用过的测试方案， 以便进行回归测试。在设计阶段应该尽力把软件 设计成容易测试和容易诊断的。 对于程序模块来说，可以用程序复杂度来度量它 的可测试性。模块的环形复杂度越大，可执行的 路径就越多，因此，全面测试它的难度就越高。
软件工程导论课件第8章
5. 数据重构 对数据体系结构差的程序很难进行适应性和 完善性维护，因此，数据体系结构比源代码对程序 的长期生存力有更大影响。 数据重构是一种全范围的再工程活动。由于 数据重构对程序体系结构及程序中的算法有很大影 响，对数据的修改必然会导致程序体系结构或代码 层的改变。
3
2.适应性维护 为适应变化了的环境界面而修改软件的活动， 称为适应性维护。包括： （1）因硬件或支撑软件改变引起的变化； （2）将软件移植到新的机种上运行； （3）因数据环境的变化而做的变更。 这类维护大约占软件维护总工作量的25％。
4
3.完善性维护 为了满足用户要求，就得对软件进行修改和 扩充，我们称这种维护为完善性维护。完善性维护 主要包括： （1）提高处理效率； （2）提高性能。 在整个维护工作中， 完善性维护大约占50％ 左右，区居第一位。
3. 逆向工程 软件的逆向工程是，分析程序以便在比源代码 更高的抽象层次上创建出程序的某种描述的过程， 也就是说，逆向工程是一个恢复设计结果的过程。 4. 代码重构 某些老程序的体系结构比较合理，但是，一些 模块的编码方式却是难于理解、测试和维护的。在 这种情况下，可以重构这些模块的代码。 通常，代码重构并不修改程序的体系结构，它 只关注个体模块的设计细节以及在模块中定义的局 部数据结构。如果重构扩展到模块边界以外并涉及 软件体系结构，则重构变成了正向工程。
13
（四）软件维护过程 维护过程的实质是对软件定义和开发过程的修 改和压缩。维护过程的主要任务是：建立维护机构， 填写维护报告和评价，为每个维护要求规定一种规 范化的处理序列，建立对维护活动的登记制度及规 定评价复审的标准。 1.维护组织 机构中有一名维护管理员总负责，每项维护要 求都通过维护管理员转交给相应的系统管理员去评 价。系统管理员对维护任务做出评价之后，由变化 授权人决定应该进行的活动，最后由系统管理员去 执行维护任务。
第8章 软件维护
第8章例题分析与解答作者：不详来源：2006年9月4日发表评论进入社区一、填空题1.为了识别和纠正运行中产生的错误而进行的维护称为_________维护。
2.采用软件工程方法开发软件，各阶段均有文档，容易维护，这种维护是________。
3.为提高可维护性，要使用的先进的、强有力的、实用的软件开发方法是________。
4.在软件维护中，因修改软件而导致出现的错误或其他情况称为__________。
二、选择题1.为增加软件功能和性能而进行的软件修改维护过程是( )。
A.校正性维护B.适应性维护C.完善性维护D.预防性维护2.维护中用来指出修改的工作量、工作性质、优先权、修改的事后性质的文档是( )。
A.软件需求说明B.软件修改报告C.软件问题报告D.测试分析报告3.维护中，因修改全局或公用数据而引起的错误是( )。
A.文档副作用B.数据副作用C.编码副作用D.设计副作用4.生产性维护活动是( )。
A.修改设计B.理解设计C.解释数据结构D.理解功能答案：一、填空题1.校正性2.结构化维护3.面向对象方法4.维护的副作用二、选择题1.C2.B3.B4.A第8章自测题及参考答案作者：不详来源：2006年9月1日发表评论进入社区一、名词解释1．校正性维护2．适应性维护3．完善性维护4．预防性维护5．软件可维护性 6．软件维护的副作用二、填空题1．维护阶段是软件生存周期中时间最长的阶段，也是花费精力和费用________的阶段。
2．在软件交付使用后，由于在软件开发过程中产生的错误没有完全彻底在开发阶段发现，必然有一部分隐含错误带到_________阶段。
3．采用手工方法开发软件只有程序而无文档，维护困难，这是一种___________维护。
4．软件维护费用增加的主要原因是维护的_________非常低。
5．软件维护工作的活动分为生产性活动和__________活动。
6．所有软件维护申请报告要按规定方式提出，该报告也称_________报告。
软件工程 第8章 软件维护
8.4.2 软件可维护性的度量
3. 可测试性 4. 可修改性 5. 可移植性 6. 效率 7. 可使用性 8. 间接度量可维护性的方法
8.4.2 软件可维护性的度量
8. 间接度量可维护性的方法
(1) 了解问题的时间； (2) 行政管理拖延的时间； (3) 收集维护工具的时间； (4) 分析问题的时间； (5) 改变规格说明的时间； (6) 具体的改错或修改的时间； (7) 局部测试时间； (8) 整体测试时间； (9) 维护重审时间； (10) 总体恢复时间。
8.4 软件的可维护性
8.4.1 影响可维护性的因素 软件的可维护性可以简单定义为：纠正软件系统出现 的错误和缺陷,以满足新的要求, 能够被理解、被校正、 被修改或被改善的难易程度。可维护性不但与采用的 分析设计方法和开发人员的技术熟练程度有关，更重 要的是与软件项目的管理技术关系密切。软件的可维 护性成为软件开发阶段各个时期的关键目标。
8.1 软件维护的种类
完善性维护 50％
预防性维护5％
改正性维护 20％
适应性维护 25％
图11.1 各类维护的比重
8.2 软件维护的特点
8.2.1 软件维护面临的困难 统计资料表明，有代表性的软件开发组织用于校正性 维护、适应性维护、完善性维护及预防性维护的费用 占其开发总金额的70％至80％。 很多软件机构被束缚在维护工作上，这是软件维护所 带来的无形支出。
8.2.3 非结构化维护
无说明或者文档资料太少由于没有采用定义良好的软 件项目管理过程来开发软件，软件项目管理的缺陷导 致的叫“非结构化维护”,这会使软件维护付出较高的 代价.
8.2.4 结构化维护
存在完整的软件系列文档，那么维护任务就从分析设 计文件开始，确定软件的重要结构特性、功能特性和 接口特性，确定所要求的修改或校正可能产生的影响， 并且计划采用何种维护处理方法，修改设计并进行复 审，编制出新的源程序，利用文档中的信息进行回归 测试，然后重新交付软件。这种维护过程就叫做“结 构化维护”
软件工程第八章维护
软件工程第八章维护第一点：软件维护的定义和重要性软件维护是指在软件发布后对其进行的一系列操作和活动，旨在确保软件系统的持续可用性、可靠性和性能。
软件维护是软件开发生命周期中的一个重要环节，它涉及到对软件进行修正、优化和升级。
软件维护的重要性体现在以下几个方面：1.保障软件质量：软件在实际运行过程中可能会出现各种问题，维护可以帮助及时修复这些问题，保证软件的正常运行。
2.提高用户满意度：通过维护，可以对软件进行功能优化和界面调整，使其更加符合用户的需求，提高用户的使用体验。
3.降低风险：软件维护可以帮助提前发现并解决潜在的风险，避免因软件问题导致的损失。
4.延长软件寿命：通过不断的维护和升级，可以使软件适应不断变化的环境和需求，延长其使用寿命。
5.提高开发效率：良好的维护可以避免因软件问题导致的重复开发，提高开发团队的效率。
第二点：软件维护的类型和策略软件维护可以分为以下几种类型：1.改正性维护：这种维护类型主要是针对软件中存在的问题和错误进行修复，保证软件的正常运行。
2.适应性维护：随着环境的变化和用户需求的变化，软件需要进行相应的调整和优化，以适应新的环境和工作需求。
3.完善性维护：这种维护类型主要是针对软件的功能进行增强和扩展，以满足用户的新需求。
4.预防性维护：预防性维护是为了避免软件出现潜在的问题和风险，提前对软件进行调整和优化。
在进行软件维护时，可以采取以下策略：1.计划维护：制定详细的维护计划，包括维护的时间、内容、责任人等，确保维护工作的有序进行。
2.变更管理：对于软件的修改和更新，需要进行严格的变更管理，确保每次变更都是经过审核和评估的。
3.版本控制：通过版本控制工具，对软件的不同版本进行管理，确保软件的每个版本都是可追踪和可恢复的。
4.文档管理：对软件的维护过程和结果进行详细的文档记录，方便对软件进行管理和维护。
5.持续集成：将软件的维护工作与开发工作结合起来，通过持续集成的方式，确保软件的质量和稳定性。
第8章软件维护
软件维护步骤
4、修改程序的副作用
副作用是指因修改软件而造成的错误或其它不希望发生的情况。 1）编码副作用：在使用程序设计语言修改源代码时可能引起的错误， 如删除或修改一个标号、标识符、一个子程序，改变程序代码的时序关系， 改变逻辑运算符，改进程序的执行效率，改变程序占用存储的大小等，都 很容易引入错误，应特别小心。 2）数据副作用：在修改数据结构时，有可能造成软件设计和数据结构 的不一致，而导致软件错误。数据副作用是修改软件信息结构引起的，如 重新定义全局或局部常量，重新初始化控制标志或指针等，都容易产生设 计与数据不相容的错误，可通过详细设计文档对数据副作用加以控制。 3）文档副作用：对数据流、软件结构、逻辑模块等进行修改时，必须 对相关技术文档进行修改，否则会导致 文档与程序功能不匹配，使文档不 能反映软件当前的状态。
软件维护步骤
5、重新验证程序：
1）静态确认； 2）计算机确认； 3）维护后的验收。
软件维护步骤
第三步：维护文档整理
记录一些与维护工作有关的数据信息，这些信息 可作为估计软件维护的有效程度，确定软件产品的 质量，确定维护的实际开销等工作的原始数据。
软件维护步骤
第四步：维护活动评价
具体的评价工作可从以下几个方面考虑： （1）每次程序运行时的平均出错次数； （2）花费在每类维护活动上的总的“人时”数； （3）每个程序、每种语言、每种维护类型程序的平均修改次数； （4）维护工作中增加或删除每个源程序语句所花费的平均“人 时”数； （5）用于每种语言的平均“人时”数； （6）维护申请报告的平均处理时间； （7）各类维护申请的百分比。 一方面，可判定此次维护活动开展是否顺利、成功；另一方面， 为今面的维护工作积累经验。
2、结构化维护：进行维护 活动时，首先从评价需求开始，搞清楚 功能、性能上的改变，然后对设计说明文档进行评价、修改和复查； 根据设计的修改，再进行程序的变动；然后根据测试文档中的测试 用例进行回归测试；最后将修改后的软件再次交付使用。
软件工程考核知识点-第8章-软件维护
软件工程考核知识点-第8章-软件维护第8章软件维护软件投入使用后就进入软件维护阶段。
维护阶段是软件生存周期中时间最长的一个阶段，所花费的精力和费用也是最多的一个阶段。
8.1软件维护的内容软件维护内容有四种：校正性维护，适应性维护，完善性维护和预防性维护。
1.校正性维护在软件交付使用后，由于在软件开发过程中产生的错误并没有完全彻底的在测试中发现，因此必然有一部分隐含的错误被带到维护阶段来。
这些隐含的错误在某些特定的使用环境下会暴露出来。
为了识别和纠正错误，修改软件性能上的缺陷，应进行确定和修改错误的过程，这个过程就称为校正性维护。
校正性维护占整个维护工作的20%左右。
2.适应性维护随着计算机的飞速发展，计算机硬件和软件环境也在不断发生变化，数据环境也在不断发生变化。
为了使应用软件适应这种而修改软件的过程称为适应性维护。
这种维护活动占整个维护活动的25%。
3.完善性维护在软件漫长的运行时期中，用户往往会对软件提出新的功能要求与性能要求。
这是因为用户的业务会发生变化，组织机构也会发生变化。
为了适应这些变化，应用软件原来的功能和性能需要扩充和增强，为达到这个目的而进行的维护活动称为完善性维护，占整个维护活动的50%。
4.预防性维护为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护。
这是为以后进一步的运行和维护打好基础，占整个维护工作的4%。
8.2 维护的特点8.2.1非结构化维护和结构化维护软件的开发过程对软件的维护过程有较大的影响。
若不采用软件过程的方法开发软件，则软件只有程序而无文档，维护工作非常难，这就是一种非结构化的维护。
若采用软件工程的方法开发软件，则各阶段都有相应的文档，这容易进行维护工作，这是一种结构化的维护。
1.非结构化维护因为只有源程序，而文档很少或没有文档，维护活动只能从阅读、理解、分析源程序开始。
这是软件工程时代以前进行维护的情况。
2.结构化维护用软件工程思想开发的软件具有各阶段的文档，这对于理解和掌握软件功能、性能、系统结构、数据结构、系统接口和设计约束有很大作用。
软件工程导论 第8章 维护
应该注意，上述4类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。
软件工程的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。
8．1 软件维护的定义
所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。 因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有第一项维护活动：在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。
8．2 软件维护的特点
8．2．1 结构化维护与非结构化维护差别巨大
1.非结构化维护
如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试(即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试)。非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击)，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
上面的模型表明，如果软件的开发途径不好(即，没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
（2）并行方式
关系重大的软件一般采用同时运行新系统和 旧系统，这就是并行方式。
优点： 旧系统
① 能对系统进行全面测试，减少了新系统风险； ② 给用户熟悉新系统的时间。
缺点：
新系统 双系统要投入更多的人力财力。
工学二部计算机教研室
（3）逐步方式
分期，分部分地交付使用 克服了上面两种方式的缺点，既能防止直接转换 产生的危险性，又能减少并行方式的费用 必须考虑好新旧系统的配合问题和接口问题
工学二部计算机教研室在没有使用就解决一个 重要问题时的样子工学二部计算机教研室
向服务器上传文件时的样子
工学二部计算机教研室
当你发现上周五还非常好用， 到了周一却不能运行时的样子
工学二部计算机教研室
当所有人都在办公室挥汗如雨的加班 而你却能安然的回家度周末时的样子
工学二部计算机教研室
当听到老板说项目如果能如期完工 将会有一笔奖金时的样子
工学二部计算机教研室
文档 重构
代码 重构
逆向 工程
六、软件再工程过程
正向 工程 数据 重构 库存 目录 分析
恢复设计结果的过
文档 重构
程，从程序代码中
抽取数据结构、体
代码 重构
逆向 工程
系结构和处理过程
的设计信息。
工学二部计算机教研室
六、软件再工程过程
正向 工程 数据 分析源代码，标注 重构 库存 目录 分析
工学二部计算机教研室
（3）可修改性
与设计时采用的原则和策略相关。（耦合、内聚、
控制域和作用域、局部化程度）
（4）可移植性
（5）可重用性 决定软件可维护性的最终因素是软件设计阶段所采用
的方法，以及软件文档资料的质量。提高软件的可维护
性是软件工程的一个重要目标。
工学二部计算机教研室
2.文档
功能描述 安装文档
三、软件维护过程 1. 维护组织
维护要求 （软件问题报告） 变化授权人 维护管理员
系统管理员
…
软件系统
工学二部计算机教研室
2. 维护报告
包含信息：
① 维护的工作量
② 维护的性质
③ 优先级
④ 有关的事后数据（如测试数据等）
工学二部计算机教研室
3. 维护的事件流
维护要求
类型
⊕ 完善 评价优 先度 低 错误 ⊕ 适应 估量错 严重 分析问 题 误严重 ⊕ 程度 不严重 计划改 正进度
第8章 维护
工学二部计算机教研室
任务：维护软件的正常运行，改进性能和质 量，为进一步推广和升级做准备。 工作量：大型软件的维护成本是开发总成本的 四倍左右，软件开发组织把60%以上的工作量 用于维护自己的软件上。
工学二部计算机教研室
软件一旦交付，就意味着漫长的
维护之路的开始……
工学二部计算机教研室
当你改错一行代码的时候
工学二部计算机教研室
当你想要重构别人的代码时
工学二部计算机教研室
当你尝试想要修复一个bug时的样子
工学二部计算机教研室
当你凌晨4点还在工作时的样子
工学二部计算机教研室
星期五下午项目经理给 你分配任务时的样子
工学二部计算机教研室
当你尝试修复别人代码的时候，结果...
工学二部计算机教研室
评价设 计文档
评价性能特点 评价接口特点
修改设计
修改代码
回归测试
工学二部计算机教研室
4.软件维护的代价
有形代价：维护的费用开支
70年代，软件维护费用占总预算的 30%～ 40% ，80年代上升到60%左右，90年代达到了80%。
工学二部计算机教研室
无形代价：潜在的影响
当看起来合理的要求不能及时满足时，会引起用
数据 重构 正向 工程 库存 目录 分析
文档 重构
发现有系统。
代码 重构
逆向 工程
工学二部计算机教研室
小结：维护过程管理
◇ 软件维护手册
主要包括软件系统说明、程序模块说明、操作环境、支 持软件说明、维护过程说明等。（便于软件的维护）
◇ 软件问题报告
软件问题的登记，如日期、发现人、状态、问题所属模块 等。（为维护提供准备文档）
产品上线时发现缺陷时的样子
工学二部计算机教研室
终端用户没有你的软件使用说明的时候
工学二部计算机教研室
当你看到第一次使用CSS 美化页面的效果时的样子
工学二部计算机教研室
一夜鏖战后第一次运行脚本时的样子
工学二部计算机教研室
老板找你修复严重bug时样子
工学二部计算机教研室
没有按Ctrl-s就关闭文件时的样子
稳定的分析与设计技术（如面向对象分析、设计
技术），可以减少一定的工作量。
（ 6）其它因素。应用的类型、数学模型、任务
的难度、IF嵌套深度等。
工学二部计算机教研室
五、预防性维护
（1）反复多次做修改程序的尝试；
（2）分析掌握程序内部细节，再修改；
（3）用软件工程方法重新设计、编码和测试需要变
更的软件部分； （4）以软件工程方法为指导，对程序全部重新设计 、编码和测试。 3：是局部再工程；4：是软件再工程 / 预防性维护
护活动的50%～66%，改正性维护占17%～21%，适
应性维护占18%～25%，其它维护活动占4%左右。
工学二部计算机教研室
3.结构化维护
评价代码
评价软件结构
评价数据结构
评价系统接口
评价设计约束
非结构化维护：经常产生误解，不能回归测试
，维护代价大。
工学二部计算机教研室
结构化维护
确定软件结构
工学二部计算机教研室
预防性维护的理由：
（1）对于旧系统，维护一行原代码的代价可能是最
初开该行源代码代价的14－40倍； （2）使用最新的设计理念重新设计软件体系结构（ 程序和数据结构），对将来的维护有较大帮助； （3）旧系统可作为原型，能提高开发效率。
工学二部计算机教研室
六、软件再工程过程
分析应用系统的信息，
Байду номын сангаас
◇ 软件修改报告
针对问题处理方案、修改后的影响的详细的描述，提交
审批。
工学二部计算机教研室
其它重要的文档
◇ 开发进度月报
包括进度与实际进度的比较、阶段成果、遇到的问题和解 决的办法以及下个月的打算等。
◇ 项目开发总结报告
总结实际执行的情况（进度、成果、资源利用、成本和投入 的人力）以及开发工作的评价，经验和教训。
◇ 用户操作手册
详述软件的功能、性能和用户界面，用户如何使用软件,操作 人员具备的有关知识，操作方法的具体细节。
工学二部计算机教研室
2.软件维护的类型
（1）改正性维护
在用户使用过程中诊断、发现和改正错误的过程
称为改正性维护。
（2）适应性维护
硬件系统和外设需要时常更新和升级，造成数据 库环境、数据输入/输出方式、数据存储介质等发生变 换。为了使软件适应这些环境变化而修改软件的过程 叫做适应性维护。
工学二部计算机教研室
（3）完善性维护
11）每个改动耗费的人时数； 12）程序改动的日期；
13）软件工程师的名字； 15）维护类型； 14）维护要求表的标识； 16）维护开始和完成的日期；
17）累计用于维护的人时数； 18）与完成的维护相联系的纯效益。
工学二部计算机教研室
5. 评价维护活动
可以从以下方面度量维护工作：
1）每次程序运行平均失效的次数；
用户文档
使用手册 参考手册 操作员指南
系统文档
工学二部计算机教研室
3. 可维护性复审
测试结束时进行正式的可维护性复审，也称配置复审 目的：保证软件配置的所有成分是完整的、一致的和 可理解的。
工学二部计算机教研室
4. 影响维护工作量的因素
（1）系统大小。系统功能越复杂，理解掌握起来就
越困难，需要的维护工作量越大。
用户在使用过程中提出新的功能和性能要求， 造成功能增加和修改称为完善性维护。
（4）预防性维护
为了改进软件未来的可维护性或可靠性，或者为未来 维护方便而进行的修改，称为预防性维护。在实践中 比较少见。
工学二部计算机教研室
在各类维护中，完善性维护占软件维护工作的大
部分。
根据国外的数据统计表明，完善性维护占全部维
（2）程序设计语言。语言的功能越弱，实现同样功
能所需的语句就越多，程序就越大，维护起来就越
困难。
（3）系统年龄。老系统当初未按照软件工程的要求
进行开发，文档太少；在长期的维护中许多地方与
程序不一致，维护起来困难较大。
工学二部计算机教研室
（4）数据库技术 （ 5）先进的开发技术。使用能使软件结构比较
的难易程度。
① 可理解性 ② 可测试性
1. 决定因素
③ 可修改性 ④ 可移植性 ⑤ 可重用性
工学二部计算机教研室
（ 1 ）可理解性：软件结构、接口、功能和内部过程
的理解的难易程度。
影响因素：模块化、结构化设计、详细的设计文
档资料、源代码内部文档、良好的程序设计语言等。 （2）可测试性 设计成易测试、易诊断，能用测试工具和调试工 具进行测试和诊断的软件。
1. 软件交付使用的工作
① 数据转换（如数据库数据） ② 调试并加载，准备运行
③ 资料移交（如使用说明）
④ 用户培训
工学二部计算机教研室
意想不到的问题，程序设计错误
2.软件交付方式
（1）直接方式
旧系统
应急措施:随时能切换到旧系统
不适用关系重大的系统
新系统
优点：转换简单，费用最省 缺点：风险大