软件工程第八章(维护)

由维护管理员和系统管理员评价用户提交的维护要 求表。
8.3 软件维护过程
3. 维护的事件流
8.3 软件维护过程
4.

保存维护记录
应该为每项维护工作都收集下述数据：
（2）源语句数； （4）使用的程序设计语言； （6）自从安装以来程序运行的次数；
（1）程序标识； （3）机器指令条数； （5）程序安装的日期；
（7）自从安装以来程序失效的次数；（8）程序变动的层次和标识； （9）因程序变动而增加的源语句数；（10）因程序变动而删除的源语句数； （11）每个改动耗费的人时数； （13）软件工程师的名字； （15）维护类型； （17）累计用于维护的人时数； （12）程序改动的日期； （14）维护要求表的标识； （l6）维护开始和完成的日期； （18）与完成的维护相联系的纯效益。
三．维护的问题 与软件维护有关的绝大多数问题，都可归因于 软件定义件生命周期的头两个时期没有严格而又科 学的管理和规划，几乎必然会导致在最后阶段 出现问题。
8.2 维护的特点
和软件维护有关的部分问题：
理解别人写的程序通常非常困难，而且困难程度随着 软件配置成分的减少而迅速增加。如果仅有程序代码 没有说明文档，则会出现严重的问题。
8.2 维护的特点
绝大多数软件在设计时没有考虑将来的修改。除非使 用强调模块独立原理的设计方法论，否则修改软件既 困难又容易发生差错。 软件维护不是一项吸引人的工作。形成这种观念很大 程度上是因为维护工作经常遭受挫折。
8.3 软件维护过程
维护过程本质上是修改和压缩了的软件定义和开 发过程。 为了有效地进行软件维护，应事先就开始做组织 工作。 首先建立一个维护组织 确定报告及评价的过程
8.1.1 软件维护定义 所谓软件维护就是在软件已经交付使用之后，为 了改正错误或满足新的需要而修改软件的过程。 软件维护包括下述4项活动。
诊断和改正错误的过程：改正性维护 为了和变化了的环境适当地配合而进行的修改软件的 活动：适应性维护 为了满足在使用软件的过程中用户的建议和改进意见 而作的维护：完善性维护 为了给未来的改进奠定更好的基础而修改软件：预防 性维护

2、适应性维护


适应性维护，也就是为了和变化了的环 境适当地配合而进行的修改软件的活动 ，是既必要又经常的维护活动。 外部环境（新的硬、软件配置） 数据环境（数据库、数据格式、数 据输入/输出方式、数据存储介质） 可能发生变化。 适应性维护的工作量占全部维护活动的 18%～25%
3、完善性维护
需要维护的软件往往没有合格的文档，或者文档资料 显著不足。认识到软件必须有文档仅仅是第一步，容 易理解的并且和程序代码完全一致的文档才真正有价 值。
当要求对软件进行维护时，不能指望由开发人员给我 们仔细说明软件。由于维护 “阶段持续的时间很长， 因此，当需要解释软件时，往往原来写程序的人已经 不在附近了。
从下述七个方面度量维护工作：
8.4程序修改的步骤及修改的副作用
在软件维护时，必然会对源程序 进行修改。 通常对源程序的修改不能无计划 地仓促上阵，为了正确、有效地修 改,需要经历以下三个步骤。 分析和理解程序 修改程序 重新验证程序
分析和理解程序
经过分析，全面、准确、迅速地理 解程序是决定维护成败和质量好坏 的关键。在这方面，软件的可理解 性和文档的质量非常重要。
为每一个维护要求规定一个标准化的事件序列
建立一个适用于维护活动的记录保管过程，并 且规定复审标准
8.3 软件维护过程
1. 维护组织
维护组织
维护申请提交给维护管理员，他把申请交给 某个系统监督员去评价。 一旦做出评价，由修改负责人确定如何进行 修改。 在修改程序的过程中，由配臵管理员严格把 关，控制修改的范围，对软件配臵进行审计 。 在维护之前，就把责任明确下来，可以减少 维护过程中的混乱。
结构化维护能减少精力浪费并且能提高维护的 总体质量。
8.2 维护的特点
二、维护成本
有形的软件维护成本是花费了多少钱 ，无形的维护成本有更大的影响。 一些合理的修复或修改请求不能及时 安排，使得客户不满意； 变更的结果引入新的故障，使得软件 整体质量下降； 把软件人员抽调到维护工作中，干扰 了软件开发工作。
修改程序
对程序的修改，必须事先做出计划 ，有预谋地、周密有效地实施修改 。 1. 设计程序的修改计划 程序的修改计划要考虑人员和资源 的安排。小的修改可以不需要详细 的计划，而对于需要耗时数月的修 改，就需要计划立案。
2. 修改代码，以适应变化 在修改时，要求： (1) 正确、有效地编写修改代码； (2) 要谨慎地修改程序，尽量保持程序 的风格及格式，要在程序清单上注明 改动的指令； (3) 不要删除程序语句，除非完全肯定 它是无用的； (4) 不要试图共用程序中已有的临时变 量或工作区，为了避免冲突或混淆用 途，应设臵自己的变量；
软件维护的代价是降低了生产率 ，在做老程序的维护时非常明显。 例如，开发每一行源代码耗资25 美元，维护每一行源代码需要耗资 1000美元。
8.2 维护的特点
维护工作量的一个模型： M＝ P＋ K * exp（c - d）
其中： M是维护用的总工作量， P是生产性工作量， K是经验常数， c是因缺乏好的设计和文档而导致复杂性的度量）， d是维护人员对软件的熟悉程度。
软件维护的管理流程
维护修改建议 分析修改建议 是否合理 进行测试
提交管理部门审批
N
是否批准
N
修改
Y
提交管理部门审查
Y
更新主文档 更新其他文档 撤销
N
是否同意
Y
修改
提交使用
8.3 软件维护过程
2.

维护报告 应该用标准化的格式表达所有软件维护要求。
软件维护人员给用户提供空白的维护要求——有时 称为软件问题报告表，由要求一项维护活动的用户 填写。 如果遇到了一个错误，那么必须完整描述导致出现 错误的环境（包括输入数据，全部输出数据，以及 其他有关信息）。 对于适应性或完善性的维护要求，应该提出一个简 短的需求说明书。
数据库技术的应用：使用数据库，可以 简单而有效地管理和存储用户程序中的 数据，还可以减少生成用户报表应用软 件的维护工作量。 先进的软件开发技术：在软件开发时， 若使用能使软件结构比较稳定的分析与 设计技术，及程序设计技术，如面向对 象技术、复用技术等，可减少大量的工 作量。
8.2 维护的特点
系统大小：系统越大，理解掌握起来 越困难。系统越大，所执行功能越复 杂。因而需要更多的维护工作量。 程序设计语言：使用强功能的程序设 计语言可以控制程序的规模。语言的 功能越强，生成程序的模块化和结构 化程度越高，所需的指令数就越少， 程序的可读性越好。
系统年龄： 老系统随着不断的修改，结构越来越乱； 维护人员经常更换，程序又变得越来越难 于理解。 许多老系统在当初并未按照软件工程的要 求进行开发，因而没有文档，或文档太少 。 在长期的维护过程中文档在许多地方与程 序实现变得不一致，在维护时就会遇到很 大困难。
(5) 插入错误检测语句； (6) 在修改过程中做好修改的详细记录 ，消除变更中任何有害的副作用（波动 效应）； 3. 修改程序的副作用 所谓副作用是指因修改软件而造成的错 误或其它不希望发生的情况。副作用有 三种：修改代码的副作用、修改数据的 副作用、文档的副作用。
(1) 修改代码的副作用
在修改源代码时，都可能引入错误。例 如，删除或修改一个子程序、删除或修 改一个标号、 删除或修改一个标识符 、改变程序代码的时序关系、改变占用 存储的大小、改变逻辑运算符、修改文 件的打开或关闭、改进程序的执行效率 ，以及把设计上的改变翻译成代码的改 变时，都容易引入错误。
4、预防性维护
预防性维护是为了提高软件的可维护 性、可靠性等，为以后进一步改进软 件打下良好基础。 预防性维护定义为：采用先进的软件 工程方法对需要维护的软件或软件中 的某一部分（重新）进行设计、编制 和测试。 在整个维护活动中，预防性维护占很 小的比例，只占5%。

综述

在整个软件维护阶段所花费的全部工作量中 ，完善性维护占了几乎一半的工作量。
第8章 维护 软件维护是软件生命周期的最后一个阶段，它处 于系统投入生产性运行以后的时期中，因此不属 于系统开发过程。
软件维护的基本任务是保证软件在一个相当长的 时期能够正常运行。
软件维护需要的工作量非常大，虽然在不同应用 领域维护成本差别很大，但是，平均说来，大型 软件的维护成本高达开发成本的四倍左右。

软件维护活动所花费的工作占整个生存期工 作量的70%以上，这是由于在漫长的软件运 行过程中需要不断对软件进行修改，以改正 新发现的错误、适应新的环境和用户新的要 求，这些修改需要花费很多精力和时间，而 且有时会引入新的错误。
8.1.1 软件维护定义 三类维护占 总维护比例 维护在软件生 存期所占比例


在软件的使用过程中，用户往往会对 软件提出新的功能与性能要求。 为了满足这些要求，需要修改或再开 发软件，以扩充软件功能、增强软件 性能、改进加工效率、提高软件的可 维护性。 这种情况下进行的维护活动叫做完善 性维护。
3、完善性性维护



实践表明，在几种维护活动中，完善性 维护所占的比重最大。即大部分维护工 作是改变和加强软件，而不是纠错。 完善性维护不一定是救火式的紧急维修 ，而可以是有计划、有预谋的一种再开 发活动。 事实证明，来自用户要求扩充、加强软 件功能、性能的维护活动约占整个维护 工作的50％以上。
8.2 维护的特点
2.结构化维护 如果有一个完整的软件配置存在，那么维护工 作从评价设计文档开始，确定软件重要的结构特 点、性能特点以及接口特点；估量要求的改动将 带来的影响，并且计划实施途径。然后首先修改 设计并且对所做的修改进行仔细复查。接下来编 写相应的源程序代码；使用在测试说明书中包含 的信息进行回归测试；最后，把修改后的软件再 次交付使用。