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章_软件维护(徐东升)
西安文理学院
软件学院
8.2 软件维护的特点 8.2.1 结构化维护与非结构化维护差别巨大
1. 非结构化维护 如果软件配置的惟一成分是程序代码，那么维护 活动从艰苦地评价程序代码开始，对软件结构、数据 结构、系统接口、设计约束等常产生误解，不能进行 回归测试，维护代价大。 非结构化维护需要付出很大代价，这种维护方式 是没有使用良好定义的方法学开发出来的软件的必然 结果。也就是就说在设计时未采用结构化程序设计方 法。
最后，把修改后的软件再次交付使用。
西安文理学院
软件学院
8.2.2 软件维护的代价
1. 有形代价与无形代价
软件维护的代价表现为有形代价和无形代价。 有形代价指软件维护的费用开支。在过去的几十年中，软
件维护的费用稳步上升。
70年代，用于软件维护的费用只占软件总预算的30%～ 40%，80年代上升到60%左右，90年代许多软件项目的维护 经费预算达到了80%。
西安文理学院
软件学院
该模型描述了影响维护的诸多因素中重要的
关系。如果一个系统开发没有遵循软件工程原 则，软件结构不好，c的值就会很高，再加上 维护人员对软件的不熟悉，原来参加开发的人 员或小组不能参加维护，d的值很低。结果是， 维护的工作量和成本将呈指数级增加。
西安文理学院
软件学院
8.2.3 程序修改的步骤及修改的副作用
西安文理学院
软件学院
实际应用中，常常是混合以上几种方法。对 系统不重要的部分采用直接方式，对系统重要部 分采用并行方式，使系统平稳交付使用。
西安文理学院
软件学院
8.1 软件维护的定义
8.1.1 软件维护的基本内容 所谓软件维护就是在软件已经交付使用 之后，为了改正错误或满足新的需要而修改 软件的过程。
软件工程 第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. 纠错，软件维护的最基本工作是纠正软件中出现的错误或缺陷。
这包括修复bug、解决程序逻辑错误、修正数据处理错误等，
确保软件系统的稳定性和可靠性。
2. 适应性维护，随着业务需求的变化，软件需要不断进行适应
性维护，以满足新的功能需求或适应新的环境。
这可能涉及修改现
有功能、添加新功能、调整界面设计等。
3. 完善性维护，软件维护还包括对软件系统进行完善，以提高
系统的性能、可用性和可维护性。
这包括优化算法、改进代码结构、提高系统的响应速度和稳定性等。
4. 预防性维护，软件维护也包括对系统进行预防性维护，以防
止潜在的问题发生。
这包括对系统进行定期的检查、优化和清理，
以确保系统长期稳定运行。
5. 管理性维护，软件维护还包括对软件开发过程和维护过程的
管理。
这包括对软件文档的更新、版本控制、变更管理、问题跟踪
和团队协作等工作。
总的来说，软件维护的工作内容是多方面的，需要维护人员对
软件系统有深入的了解，同时具备良好的沟通能力和问题解决能力，以确保软件系统能够持续稳定、高效地运行。
第8章软件维护
软件维护步骤
4、修改程序的副作用
副作用是指因修改软件而造成的错误或其它不希望发生的情况。 1）编码副作用：在使用程序设计语言修改源代码时可能引起的错误， 如删除或修改一个标号、标识符、一个子程序，改变程序代码的时序关系， 改变逻辑运算符，改进程序的执行效率，改变程序占用存储的大小等，都 很容易引入错误，应特别小心。 2）数据副作用：在修改数据结构时，有可能造成软件设计和数据结构 的不一致，而导致软件错误。数据副作用是修改软件信息结构引起的，如 重新定义全局或局部常量，重新初始化控制标志或指针等，都容易产生设 计与数据不相容的错误，可通过详细设计文档对数据副作用加以控制。 3）文档副作用：对数据流、软件结构、逻辑模块等进行修改时，必须 对相关技术文档进行修改，否则会导致 文档与程序功能不匹配，使文档不 能反映软件当前的状态。
软件维护步骤
5、重新验证程序：
1）静态确认； 2）计算机确认； 3）维护后的验收。
软件维护步骤
第三步：维护文档整理
记录一些与维护工作有关的数据信息，这些信息 可作为估计软件维护的有效程度，确定软件产品的 质量，确定维护的实际开销等工作的原始数据。
软件维护步骤
第四步：维护活动评价
具体的评价工作可从以下几个方面考虑： （1）每次程序运行时的平均出错次数； （2）花费在每类维护活动上的总的“人时”数； （3）每个程序、每种语言、每种维护类型程序的平均修改次数； （4）维护工作中增加或删除每个源程序语句所花费的平均“人 时”数； （5）用于每种语言的平均“人时”数； （6）维护申请报告的平均处理时间； （7）各类维护申请的百分比。 一方面，可判定此次维护活动开展是否顺利、成功；另一方面， 为今面的维护工作积累经验。
2、结构化维护：进行维护 活动时，首先从评价需求开始，搞清楚 功能、性能上的改变，然后对设计说明文档进行评价、修改和复查； 根据设计的修改，再进行程序的变动；然后根据测试文档中的测试 用例进行回归测试；最后将修改后的软件再次交付使用。
软件维护流程
软件维护流程软件维护是软件开发生命周期中非常重要的一个环节，它包括对软件进行修改、优化、更新和完善，以确保软件能够持续稳定地运行。
软件维护流程是指对软件进行维护的一系列步骤和方法，下面将详细介绍软件维护的流程及相关注意事项。
1. 接收问题反馈。
软件维护流程的第一步是接收用户或客户的问题反馈。
这些问题反馈可以来自于软件使用过程中出现的错误、漏洞、性能问题，也可以是用户对软件功能和界面的建议和需求。
在接收问题反馈时，需要及时记录问题描述、问题出现的环境、重现步骤等信息，并对问题进行分类和优先级排序。
2. 分析问题原因。
接收到问题反馈后，需要对问题进行分析，找出问题的根本原因。
这一步需要软件开发人员、测试人员和客户服务人员等多方共同参与，通过分析日志、调试代码、复现问题等方式来深入了解问题的本质。
在分析问题原因时，需要注意综合考虑软件的功能、性能、安全性等方面的因素，确保找出问题的真正原因。
3. 制定维护计划。
在分析清楚问题原因后，需要制定针对性的维护计划。
维护计划包括对问题的修复方案、优化方案、更新方案等内容，同时需要考虑到维护的时间节点、风险评估、资源分配等方面。
制定维护计划时，需要与相关部门和人员进行充分沟通，确保计划的可行性和有效性。
4. 实施维护措施。
制定好维护计划后，需要开始实施维护措施。
这包括对软件进行修改、更新、优化等操作，同时需要进行相应的测试和验证，确保维护后的软件能够正常运行并且问题得到解决。
在实施维护措施时，需要严格按照计划进行，并及时跟进和反馈维护的进展情况。
5. 验收和发布。
维护措施实施完成后，需要进行验收和发布。
验收是指对维护后的软件进行全面的测试和验证，确保软件的功能、性能、安全性等方面都符合要求。
如果验收通过，就可以进行软件的发布，让用户和客户可以使用到最新的软件版本。
6. 监控和反馈。
维护流程的最后一步是监控和反馈。
在软件发布后，需要对软件进行持续的监控和跟踪，及时发现和解决新的问题和Bug。
软件工程导论 第8章 维护
应该注意，上述4类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。
软件工程的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。
8．1 软件维护的定义
所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。 因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有第一项维护活动：在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。
8．2 软件维护的特点
8．2．1 结构化维护与非结构化维护差别巨大
1.非结构化维护
如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试(即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试)。非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击)，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
上面的模型表明，如果软件的开发途径不好(即，没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。
《软件工程》第八章 软件维护与再工程
软件可维护性－主要影响因素
可移植性：指程序转移到一个新的计算环境的难易 程度。
影响软件可移植性的因素有：信息隐蔽原则；模块 独立；模块化；高内聚低耦合；良好的程序结构； 不用标准文本以外的语句等
一个可移植的程序应具有结构良好、灵活、不依赖 于某பைடு நூலகம்具体计算机或操作系统的性能
软件可维护性－主要影响因素
软件维护的概念－维护成本
其它一些因素：如应用的类型、数学模型、 任务的难度、IF嵌套深度、索引或下标数等， 对维护工作量也有影响
软件维护的过程－维护组织
维护组织结构图
软件维护的过程－维护组织
系统监督员一般都是对程序(某一部分)特别熟 悉的技术人员。 在维护人员对程序进行修改的过程中，由配 置管理员严格把关，控制修改的范围，对软 件配置进行审计 。 维护管理员、系统监督员、修改控制决策机 构等，均代表维护工作的某个职责范围 。
如果已经开始保存维护记录，可以对维护工作做 一些定量度量，至少可以从如下7方面进行评价：
每次程序运行平均失败的次数； 用于每一类维护活动的总人时数； 平均每个程序、每种语言、每种维护类型所必需的程序 变动数； 维护过程中增加或删除源语句平均花费的人时数； 维护每种语言平均花费的人时数； 一张维护请求表的平均周转时间； 不同维护类型所占的比例；
软件维护的过程－维护记录
软件修改报告指明：为满足维护申请报告提 出的需求所需的工作量、本次维护活动的类 别、本次维护请求的优先级、本次修改的背 景数据。在拟定进一步维护计划前，软件修 改报告要提交给修改决策机构，供进一步规 划维护活动使用 保存维护记录的第一个问题就是哪些数据值 得保存？
软件维护的过程－维护评价
软件维护的概念－维护问题
i第8章 软件维护
得客户不满意； 变更的结果引入新的故障，使得软件整体质量 下降； 把软件人员抽调到维护工作中，干扰了软件开 发工作。
8.3 软件维护任务的实施
为了有效地进行软件维护，应事先就开始做组织 工作。
首先建立维护的组织 申明提出维护申请报告的过程及评价的过程 为每一个维护申请规定标准的处理步骤 建立维护活动的登记制度以及规定评价和评审
3.完善性维护
ቤተ መጻሕፍቲ ባይዱ
在软件的使用过程中，用户往往会对软件提出 新的功能与性能要求。 为了满足这些要求，需要修改或再开发软件， 以扩充软件功能、增强软件性能、改进加工效 率、提高软件的可维护性。 这种情况下进行的维护活动叫做完善性维护。 例如，完善性维护可能是修改一个计算工资的 程序，使其增加新的扣除项目；缩短系统的应 答时间，使其达到特定的要求等。
三类维护占 总维护比例
维护在软件生存期 所占比例
8.2 维护的特点
8.2.1 非结构化维护和结构化维护 1. 非结构化维护 只有源程序，没有文档，维护活动只能从阅读、理 解分析源程序开始，来了解系统功能、软件结构、 数据结构、系统接口、设计约束等。
维护工作非常困难，要花费大量的人力、物力，最 终对源程序修改的后果是难以估量的。
8.2.2 维护的困难性 1. 读懂别人的程序是困难的 修改别人的程序不如自己重新编写程序 2. 文档的不一致性 各种文档之间不一致 文档与程序之间不一致 主要是开发过程中文档管理不严造成： 修改程序忘了修改与其相关的文档 某一文档改了，没有修改与其相关的另一文档
3. 软件开发和软件维护在人员和时间上的差异 软件维护工作由软件开发人员来进行，维护工作就 变得容易 通常开发人员和维护人员不同，导致维护的困难。 维护阶段持续时间很长，正在运行的软件可能是十 几、二十几年前开发的，开发工具、方法、技术与 当前的工具、方法、技术差异很大，导致维护困难。 3. 软件维护不是一项吸引人的工作。
第八章 软件维护
软件维护的机构10软件维 的事件流1112
软件维护工作流程
必要的技术工作 修改软件需求说明 修改软件设计 设计评审 对源程序做必要修改 单元测试 集成测试（回归测试） 确认测试 软件配置评审等。
13
8 .4 软件的可维护性
衡量软件质量的几个主要质量特性： 可维护性 可使用性 可靠性 一、软件可维护性的定义 指纠正软件系统出现的错误和缺陷，以及为 满足新的要求进行修改、扩充或压缩的容 易程度。
22
进行明确的质量保证审查
检查点复审、验收检查、周期性地维护审查、 对软件包进行检查。
选择可维护的程序设计语言 改进程序的文档 开发软件时考虑到维护
23
相关习题 1．某些软件工程师不同意“目前国外许多 软件开发组织把60%以上的人力用于维护已 有的软件”的说法，他们争论说：“我并没 有花费我的60%的时间去改正我所开发的程 序中的错误”。 请问，你对上述争论有何看法？ 2．为什么大型软件的维护成本高达开发成 本的4倍左右？
7
8.2.3 维护的问题很多 ( 1 ）理解别人写的程序通常非常困难． ( 2 ）需要维护的软件无文档或不全． ( 3 ）软件人员流动性大． ( 4 ）设计时未考虑将来修改需要，修改困难． ( 5 ）维护工作无吸引力，缺乏成就感．
8
8. 3 软件维护过程
首先建立维护组织，确定报告和评价过程， 为每个维护要求规定一个标准化的事件序 列，并记录维护活动和规定复审标准。 一、维护组识 所有软件维护申请应按规定的方式提出 维护机构通常提供“维护申请报告”或称 “软件问题报告”由申请维护的用户填写。 维护机构内部要写“软件修改报告”
26
4．假设你的任务是对一个已有的软件做重 大修改，而且只允许你从下述文档中选取两 份：(a)程序的规格说明；(b)程序的详细设 计结果（自然语言描述加上某种设计工具表 示);（c)源程序清单（其中有适当数量的注 解)。 你将选取哪两份文档？为什么这样选取？
第8章 软件维护
08 软件维护一、选择题(1)一般来说，在软件生命周期中成本最高的阶段是( D )。
A.详细设计B.软件编码C.软件测试D.软件维护(2)为软件的运行增加监控设施以应对将来可能出现的问题，这种维护的维护类型是( D )。
A．改正性维护 B．适应性维护 C．完善性维护 D．预防性维护(3)在整个软件维护阶段所花费的全部工作中，哪种维护所占比例最大？（ C ）A．改正性维护 B．适应性维护 C．完善性维护 D．预防性维护(4)产生软件维护的副作用，是指 ( C )A．开发时的错误 B．隐含的错误C．因修改软件而造成了新的错误 D．运行时误操作(5)维护的副作用可分三类，不包括（D ）。
A. 代码副作用B. 数据副作用C. 文档副作用D.人员副作用(6)下列属于维护阶段的文档是 ( C )。
A.软件规格说明B.用户操作手册C.软件问题报告D.软件测试分析报告(7)维护活动必须应用于（ B ）A．软件文档 B．整个软件配置 C．可执行代码 D．数据(8)为了提高软件的可维护性，在编码阶段应注意( D )。
A.保存测试用例和数据B.提高模块的独立性C.文档的副作用D.养成好的程序设计风格(9)为了提高软件的可维护性，在总体设计阶段应注意( B )。
A.保存测试用例和数据B.提高模块的独立性C.文档的副作用D.养成好的程序设计风格(10)以下哪些问题是维护人员经常面对的问题？（ D ）。
A．理解别人的程序非常困难 B．文档不合格C．设计时没考虑未来的修改维护 D．以上都是(11)决定软件可维护性的因素包括（ B ）。
A．可理解性，可测试性，可修改性，可移植性，可用性B．可理解性，可测试性，可修改性，可移植性，可重用性C．可理解性，可靠性，可测试性，可修改性，可移植性D．可理解性，可扩展性，可测试性，可修改性，可升级性(12)软件维护是保证软件正常、有效的重要手段，软件的下述特性中，( D )有利软件的维护。
《软件工程实用教程》第8_章_软件维护技术
第8 章 軟體維Βιβλιοθήκη 技術8.2 軟體維護類型8.2.1 改正性維護 1. 利用應用軟體包，可開發出比由用戶完全 自己開發的系統可靠性更高的軟體。 2. 結構化技術，用它開發的軟體易於理解和 測試。 3. 防錯性程式設計。把自檢能力引入程式， 通過非正常狀態的檢查，提供審查跟蹤。 4. 通過週期性維護審查，在形成維護問題之 前就可確定品質缺陷。可理解性
第8 章 軟體維護技術
8.2.2 完善性維護 為了滿足日益增長的新要求，需要修改或再 開發軟體，以擴充軟體功能，增強軟體性能， 改進加工效率，提高軟體的可維護性，這些 維護活動稱為完善性維護。 8.2.3 適應性維護 為了使軟體適應新的變化而去修改軟體的維 護活動稱為適應性維護。 8.2.4 預防性維護 為以後進一步使用軟體打下良好基礎的維護 活動稱為預防性維護活動。
第8 章 軟體維護技術
8.4.2 軟體維護的副作用 1．修改代碼的副作用 2．修改數據的副作用 3．修改文檔的副作用
（1）確認維護類型 （2）實施維護 （3）維護評審
第8 章 軟體維護技術
4．整理軟體維護文檔 程式名稱； 使用的程式設計語言； 根源程式語句條數，機器代碼指令條數； 程式安裝的日期； 程式安裝後的運行次數； 與程式安裝後運行次數有關的處理故障次數； 程式改變的層次，名稱和日期； 修改程式所增加的根源程式語句條數； 修改程式所減少的根源程式語句條數；
第8 章 軟體維護技術
8.3 軟體維護技術
8.3.1 軟體維護過程 1．建立維護機構
第8 章 軟體維護技術
2．編寫軟體維護申請報告 軟體變更報告包括的內容： 所需修改變動的性質； 申請修改的優先順序； 為滿足該維護申請報告，所需的工作量（人 員數，時間數）； 預計修改後的結果。 3．確定軟體維護工作流程
软件维护工作规划
一、前言随着信息技术的发展，软件产品在企业中的应用越来越广泛，软件维护成为保障软件正常运行、提高用户满意度的重要环节。
为了确保软件维护工作的顺利进行，提高工作效率和质量，特制定以下软件维护工作规划。
二、规划目标1. 提高软件稳定性，降低故障率；2. 优化用户体验，提升软件易用性；3. 保障数据安全，确保业务连续性；4. 提高维护团队的专业能力，提升整体维护水平。
三、工作内容1. 故障响应与处理（1）建立故障响应机制，确保在接到用户反馈后，及时响应并处理；（2）对故障进行分类，制定相应的处理流程；（3）对故障原因进行分析，总结经验，预防类似故障再次发生。
2. 软件升级与优化（1）根据用户需求和市场变化，制定软件升级计划；（2）对软件进行优化，提高性能和稳定性；（3）更新软件文档，方便用户了解和使用。
3. 数据安全与备份（1）建立数据安全管理制度，确保数据安全；（2）定期进行数据备份，防止数据丢失；（3）对备份数据进行验证，确保备份数据的完整性。
4. 用户培训与支持（1）开展用户培训，提高用户对软件的使用能力；（2）建立用户支持渠道，及时解答用户疑问；（3）收集用户反馈，不断改进软件。
5. 团队建设与培训（1）加强团队协作，提高团队凝聚力；（2）组织技术培训，提升团队成员的专业能力；（3）关注行业动态，紧跟技术发展趋势。
四、工作流程1. 故障响应：用户反馈→ 故障记录→ 故障分类→ 分配处理→ 故障处理→ 验收→ 总结经验2. 软件升级：需求分析→ 设计评审→ 开发实施→ 测试验证→ 发布上线→ 用户培训3. 数据备份：定期备份→ 备份验证→ 数据恢复4. 用户培训：需求分析→ 讲师准备→培训实施→ 反馈收集→ 改进措施五、保障措施1. 建立完善的软件维护管理制度，明确各部门职责；2. 加强团队协作，提高工作效率；3. 关注行业动态，及时调整工作方向；4. 定期对软件维护工作进行总结，不断优化工作流程；5. 提供充足的资源支持，保障软件维护工作的顺利进行。
软件维护报告内容包括哪些方面
软件维护报告内容包括哪些方面1. 引言本报告是对软件维护工作进行总结和分析的报告。
在本报告中，将详细介绍软件维护的目标、工作内容、工作量、团队成员、工作周期等方面的内容。
2. 软件维护目标软件维护的目标是确保软件持续运行和改进，以满足用户需求和提高软件系统的可靠性、可用性和可维护性。
具体目标包括：- 修复软件中的错误和缺陷，确保软件的功能正常运行；- 改进软件的用户体验，提高软件的易用性；- 优化软件性能，提升软件的运行效率；- 扩展软件功能，满足新增的用户需求；- 更新软件技术和平台，适应不断变化的环境。
3. 软件维护工作内容软件维护工作主要包括以下几个方面的内容：3.1 错误和缺陷修复软件维护团队需要定期排查软件中的错误和缺陷，并进行修复。
这包括通过分析用户反馈、日志记录等方式发现问题，并对问题进行跟踪、复现和修复。
3.2 新功能开发随着用户需求的不断变化，软件需要不断更新和改进。
维护团队需要将用户的新需求转化为具体的功能需求，并进行开发和测试。
3.3 性能优化软件在长时间运行后可能会出现性能下降的问题，维护团队需要通过对软件进行性能监控和分析，找出性能瓶颈，并进行优化和改进，提高软件的运行效率。
3.4 技术更新随着软件技术和平台的不断发展，维护团队需要对软件进行技术更新和升级。
这包括对软件的技术架构、开发语言、数据库等方面进行更新，以提高软件的稳定性和可维护性。
3.5 文档维护维护团队还需要对软件的文档进行维护和更新。
这包括用户手册、开发文档、系统架构文档等方面的内容，以确保相关文档与软件的实际情况保持一致。
4. 软件维护工作量和周期软件维护的工作量和周期取决于软件的规模和复杂度，以及用户需求和团队资源的情况。
通常来说，软件维护是一个持续进行的过程，需要进行定期的检查和修复。
对于常规的错误修复和新功能开发，可以设置每月一次的维护周期；对于紧急的错误修复和重大功能更新，可以进行紧急维护。
5. 软件维护团队软件维护需要一个专业的团队来进行管理和执行。
一般软件开发过程中的八个阶段
一般软件开发过程中的八个阶段Boehm：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。
IEEE：软件工程是开发、运行、维护和修复软件的系统方法。
Fritz Bauer：建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。
软件工程学的内容软件工程学的主要内容是软件开发技术和软件工程管理.软件开发技术包含软件工程方法学、软件工具和软件开发环境；软件工程管理学包含软件工程经济学和软件管理学。
软件工程基本原理著名软件工程专家B.Boehm综合有关专家和学者的意见并总结了多年来开发软件的经验，于1983年在一篇论文中提出了软件工程的七条基本原理。
(1)用分阶段的生存周期计划进行严格的管理。
(2)坚持进行阶段评审。
(3)实行严格的产品控制。
(4)采用现代程序设计技术。
(5)软件工程结果应能清楚地审查。
(6)开发小组的人员应该少而精。
(7)承认不断改进软件工程实践的必要性。
B.Boehm指出，遵循前六条基本原理，能够实现软件的工程化生产；按照第七条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。
软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。
(1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。
正确性指软件产品达到预期功能的程度。
可用性指软件基本结构、实现及文档为用户可用的程度。
开销合宜是指软件开发、运行的整个开销满足用户要求的程度。
这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。
(2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。
软件工程过程主要包括开发过程、运作过程、维护过程。
它们覆盖了需求、设计、实现、确认以及维护等活动。
需求活动包括问题分析和需求分析。
问题分析获取需求定义，又称软件需求规约。
软件维护计划书
软件维护计划书1. 引言软件维护是软件生命周期中非常重要的一个环节，它包括对软件系统的修复缺陷、改进功能、适应环境变化以及确保系统长期稳定运行等任务。
本文档旨在制定一个详细的软件维护计划，以确保软件系统始终能够满足用户的需求，并保持良好的性能和稳定性。
2. 维护目标本软件维护计划的主要目标是： - 及时响应用户提交的问题和意见，并提供相应的解决方案； - 定期对软件系统进行检查和维护，包括缺陷修复和性能优化等；- 针对新的需求和功能改进，制定相应的计划并逐步实施； - 确保软件系统与不同的硬件和软件环境兼容，并及时更新以适应环境变化。
3. 维护流程软件维护流程通常包括问题报告、问题分析、问题解决、发布更新等环节。
具体流程如下：3.1 问题报告用户可以通过官方渠道提交软件问题报告，包括功能异常、界面问题、使用困难等。
问题报告应包含足够的描述、文档、截图等信息，以方便开发人员进行分析和定位。
3.2 问题分析开发团队收到问题报告后，会进行问题分析工作。
根据问题报告的描述和相关信息，团队会进行问题定位和根本原因分析，并分配相应的开发人员进行处理。
3.3 问题解决开发人员根据问题分析的结果，制定相应的解决方案并逐步实施。
在解决问题的过程中，可能需要对软件代码进行修改、测试和验证。
3.4 发布更新在问题解决后，开发团队会对软件进行测试和验证，并进行版本控制，确保解决方案能够有效地解决问题。
然后，将更新的版本发布给用户，供其下载和安装。
4. 维护周期为了保证软件系统的稳定运行，本维护计划将制定一个合理的维护周期，确保软件系统得到定期检查和维护。
维护周期根据软件系统的特点和使用情况来确定，一般推荐每个季度进行一次维护。
5. 维护人员和责任软件维护需要一支专业的团队来进行管理和实施。
在本维护计划中设立以下几个角色：•维护经理：负责制定维护计划、协调维护工作，确保维护任务的顺利执行；•开发人员：负责分析和解决软件问题，制定相应的解决方案；•测试人员：对解决方案进行验证，确保修复的问题得到有效解决；•发布人员：负责将更新的版本发布给用户并进行相应的文档更新。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件维护基础
软件维护过程
软件测试过程
8.1 软件维护的类型
一、定义：软件维护是指软件系统交付使用，要求进行维护的原因大致有以下几种： （1）改正程序中的错误和缺陷。
（2）改进设计以适应新的软、硬件环境。
（3）增加新的应用范围。 按照不同的维护目的，维护工作可分成4类。
在检查点进行复审
• 保证软件质量的最佳方法是在软件开发的最初阶
段把质量要求考虑进去，并在开发过程每一阶段 的终点，设臵检查点进行检查。 • 检查的目的是要证实，已开发的软件是否符合标 准，是否满足规定的质量需求。在不同的检查点，
检查的重点不完全相同。
软件开发期间各个检查点的检查重点
周期性地维护审查
适应性 评估后按优先 级在队列排队
类型
完善性 评估后分类
“救火行动”,当 排在队列之首 接受
拒绝 通知请求者 并说明原因
采取的行动
按优先级在 队列中排队
从维护请求队列之首取出一任务 按SE方法学规划、组织、实施工程 队列中还有维护请求吗？ n 资源用于开发新的软件。 y
软件维护工作流程
• 尽管维护申请的类型不同，但都要进行同样的技术工作。
软件修改报告(SCR)
软件名称 源程序名称 相关文档列表 维护描述： 日期 修改内容 修改原因 特别说明 备份程序名称
增加代码行数 注释修改
删除代码行数 相关文档修改 修改完成日期
修改代码行数
修改开始日期
维护人
维护请求
其他 类型 改正性 非常严重 严重性 并不严重 评估后按优先 级在队列排队
软 件 维 护 的 工 作 流
基于构件/构架的软件开发方式结构图
8.5软件再生工程过程
正向工程
数据重构
库存目录分析
代码重构
文挡重构
逆向工程
逆向工程
一、软件的逆向工程定义 分析已有的程序，寻求比源代码更高级的抽象表现形式。 二、相关概念： * 重构：转换系统描述； * 设计恢复：抽象出有关数据设计、总体设计等信息； * 再生工程：产生新版本；
对软件包进行检查
• 软件包是一种标准化的，可为不同单位、不同用户使用的 软件。 • 一般源代码和程序文档不会提供给用户。 • 对软件包的维护采取以下方法。
– 使用单位的维护人员首先要仔细分析、研究卖主提供 的用户手册、操作手册、培训教程等，以及卖方提供的 验收测试报告等。
– 在此基础上，深入了解本单位的希望和要求，编制软件 包的检验程序。 检查软件包程序所执行的功能是否与用户的要求和条件相 一致。 – 为了建立这个程序，维护人员可以利用卖方提供的验收 测试实例，还可以自己重新设计新的测试实例。 – 根据测试结果，检查和验证软件包的参数或控制结构， 以完成软件包的维护。
– 修改软件需求说明 – 修改软件设计 – 设计评审 – 对源程序做必要的修改
– 单元测试
– 集成测试( 回归测试) – 确认测试
– 软件配臵评审等。
在每次软件维护任务完成后进行情况评审，对以下问题做
一总结： (1) 在目前情况下，设计、编码、测试中的哪一方面可以改 进? (2) 哪些维护资源应该有但没有? (3) 工作中主要的或次要的障碍是什么? (4) 从维护申请的类型来看是否应当有预防性维护? 情况评审对将来的维护工作如何进行会产生重要的影响。
√ 批准 评价负责人：***
软件修改报告(SCR)
• 依据维护请求表，软件组织内部应该制定出一个软 件修改报告，它给出下述信息： – 满足维护请求表中提出的要求所需的工作量； – 维护要求的性质； – 维护要求的优先次序； – 与修改有关的背景数据。 • 在拟定进一步维护计划前，把软件修改报告提交控 制决策机构审查批准。
• 检查点复查和验收检查，可用来保证新软件系统的可维护 性。
• 对已有的软件系统，则应当进行周期性的维护检查。
• 软件在运行期间进行修改，会导致软件质量有变坏的危险， 破坏程序概念的完整性。
• 必须定期检查，对软件做周期性的维护审查，以跟踪软件 质量的变化。
• 周期性维护审查实际上是开发阶段检查点复查的继续，并 且采用的检查方法、检查内容都是相同的。 • 维护审查的结果可以同以前的维护审查的结果，以前的验 收检查的结果、检查点检查的结果相比较，任何一种改变 都表明在软件质量上或其它类型的问题上可能起了变化。 • 对于改变的原因应当进行分析。
重构例子（Extract Method）
void printOwing(double amount) { printBanner();
// print details. System.out.println(“name: “ + _name); System.out.println(“amount” + _amount); void printDetails(double amount) { } System.out.println(“name: “ + _name); System.out.println(“amount” + _amount); }
软件维护记录
记录编号：eval_wh_012 计划编号：eval_wh_012 日期：****年**月**日 项目名称：网络测评系统
初始状态描述：不同类型的人员可以进行交叉测评。按需求：各类人员只进行自 身类型的测测评，如管理人员只能对管理人员进行测评，教师只能测评教师。 模块名称：测评控制管理 源程序行数：210 编程语言：PHP 失效次数：3 编号：evalobject_01 机器指令长度：25Kb 程序安装日期：****年**月**日 程序运行时间：
可修改性
在各类维护中的侧重点
改正性修改 适应性修改 完善性修改 可理解性 可测试性 可修改性 @ @ @ @ @
可靠性
可移植性
@ @ @
@
可使用性
效率
8.4提高可维护性的方法
• 建立明确的软件质量目标和优先级
• 使用提高软件质量的技术和工具
• 进行明确的质量保证审查
• 选择可维护的程序设计语言
• 改进程序的文档
系统本身 的因素
人的因素
开发环境
维护工具的 因素
开发方法
8.3可维护性
2、量化的度量
收集维护工具 时间 发现问题的 时间
度量
分析问题、形成修改 说明书时间
系统完全 恢复时间 局部、整体 测试时间
纠错时间
维护评审时间
8.3可维护性
衡量的质量特性
可使用性 可理解性
可维护性
可测试性
可靠性
可移植性
高效率性
选择可维护的程序设计语言
机器语言
汇编语言
高级语言
查询语言 报表生成语言 图像语言 应用生成语言
构件工程
领域工程
设计软件 体系结构 开发可重用 的软件成分
领域分析
领域 模型
结构 模型
中心库
可重用软件 成分／构件
软件工程
用户 需求
系统分析
规格说明 与设计
系统规 格说明
建造
分析与 设计模型
应用 软件
8.1 软件维护的类型
完善性维护
改正性维护
软件维护
预防性维护
适应性维护
四类软件维护的比例
三类维护占维护比例
维护在软件生存期所占比例
二、维护成本
有形的软件维护成本
无形维护 成本
三、维护工作量的模型
M=p
• • • • •
c -d + K*exp
M是维护中消耗的总工作量 p是生产性工作量 K是一个经验常数 c是因缺乏好的设计和文档而导致复杂性的度量 d是对软件熟悉程度的度量。
文档
程序
非结构化维护
软件维护分类
维护要求
软件 配置
代码
结 构 化 维 护
评价设计
评价代码
计划途径 ？ 修改设计 重新编码 重新编码
非 结 构 化 维 护
复查
复查
交付使用
8.2软件维护活动
维护机构 维护申请报告 标准的处理步骤 维护记录 维护评价
维护团队组织
软件维护的机构
软件维护请求报告
项目名称 网络测评系统 项目编号 预计维护的结果： 修正程序中的人员权限，使得每种类 型的人员只能进行自身类型的测评。 问题说明：(数据输入、错误现 象)不同类型的人员可以进行交叉测 远程维护 维护安排 评。 √ 现场维护 按需求：各类人员只进行自身类 软件： 纠错维护 √ 型的测评，如管理人员只能对管理人 适应维护 员进行测评，教师只能测评教师。 维护类型 完善维护 硬件： 系统设备 外部设备 维护要求及优先级： 维护时间 在测评之前必须修正，否则会造成测 评结果的不准确 环境 申请人：****** 申请评价结果：修正错误 自 ****年**月**日 至 *****年**月**日 共计 0.5 人月 拒绝
四、影响维护工作量的因素 • • • • • 系统大小 程序设计语言 系统年龄 数据库技术的应用 结构化的软件开发技术
结构化维护VS非结构化维护
• 软件的开发过程对软件的维护产生较大的影响。 – 如果采用软件工程的方法进行软件开发，保证每个 阶段都有完整且详细的文档，这样维护会相对容易， 被称为结构化的维护。 – 反之，如果不采用软件工程方法开发软件，软件只 有程序而欠缺文档，则维护工作变得十分困难，被 成为非结构化的维护。 结构化维护
日期
**月**日 ……
维护内容
查错，确定错误位臵
增/删/改
修改部分源程序
工作量
0.2个人月
维护人员
****
维护结果：经过对需求的进一步确认，对指定编号的模块进行了修改，纠正了源 程序中出现的错误。 维护人员：*****