第10章 软件维护.ppt

第10章软件维护 1 第10章软件维护 软件维护 软件维护是软件生命周期的最后一个阶段 它处于 系统投入生产性运行以后的时期中 因此不属于系 统开发过程 软件维护需要的工作量非常大 虽然在不同应用领 域维护成本差别很大 但是 平均说来 大型软件 的维护成本高达开发成本的四倍左右 目前国外许 多软件开发组织把60 以上的人力用于维护已有的 软件 而且随着软件数量增多和使用寿命延长 这 个百分比还在持续上升 将来维护工作甚至可能会 束缚住软件开发组织的手脚 使他们没有余力开发 新的软件 前面各章讲述的软件工程方法学的主要目的就是要 提高软件的可维护性 减少软件维护所需要的工作 量 降低软件系统的总成本 前一页 休息 2 第10章软件维护 10 1软件维护的概念 前一页 休息 3 第10章软件维护 软件维护的定义 所谓软件维护就是在软件已经交付使用之后 为了改正错误或满足新的需要而修改软件的 过程 通常可以通过描述软件交付使用后可能进行 的四项活动 具体地定义软件维护 因为软件测试不可能暴露出一个大型软件系 统中所有潜藏的错误 所以必然会有第一项 维护活动 在任何大型程序的使用期间 用 户必然会发现程序错误 并且把他们遇到的 问题报告给维护人员 我们把诊断和改正错 误的过程称为改正性维护 前一页 休息 4 第10章软件维护 软件维护的定义 计算机科学技术领域的各个方面都在迅速进 步 大约每过若干个月就有新一代的硬件宣 告出现 经常推出新操作系统或旧系统的修 改版本 时常增加或修改外部设备和其他系 统部件 另一方面 应用软件的使用寿命却 很容易超过十年 远远长于最初开发这个软 件时的运行环境的寿命 因此 适应性维护 也就是为了和变化了的环境适当地配合而进 行的修改软件的活动 是既必要又经常的维 护活动 前一页 休息 5 第10章软件维护 软件维护的定义 当一个软件系统顺利地运行时 常常出现第三项维 护活动 在使用软件的过程中用户往往提出增加新 功能或修改已有功能的建议 还可能提出一般性的 改进意见 为了满足这类要求 需要进行完善性维 护 这项维护活动通常占软件维护工作的大部分 当为了改进未来的可维护性或可靠性 或为了给未 来的改进奠定更好的基础而修改软件时 出现了第 四项维护活动 这项维护活动通常称为预防性维护 目前这项维护活动相对说比较稀少 从上述关于软件维护的定义不难看出 软件维护绝 不仅限于纠正使用中发现的错误 事实上在全部维 护活动中一半以上是完善性维护 国外的统计数字 表明 完善性维护占全部维护活动的50 66 改正性维护占17 21 适应性维护占18 25 其他维护活动只占4 左右 前一页 休息 6 第10章软件维护 影响维护工作量的因素 1 软件的老化 老软件随着不断的修改 结构越来 越乱 经常出现系统故障 严重影响了系统的性能 发挥 2 软件过大 系统越大 理解掌握起来越困难 系 统越大 所执行功能越复杂 这直接影响着软件的 维护工作量 3 模块或单个子程序过大 模块越大 程序的结构 和逻辑流越复杂 维护起来难度就越大 4 软件对运行环境的依赖性 由于硬件以及操作系 统更新很快 使得对运行环境依赖性很强的应用软 件也要不停地更新 导致较高的维护代价 前一页 休息 7 第10章软件维护 影响维护工作量的因素 5 将易变的参数编在代码中 这种处理将使得程序 经常要修改 以适应变化 增加了维护的频度 为 了减少频繁地修改 要求对程序改造 让它能从输 入模块或一个数据表中读入参数 6 维护人员的专业技能 用低级语言编写的程序 尤其是汇编语言 需要大量的时间和人力去维护 7 编程语言 虽然低级语言比高级语言具有更好的 运行速度 但是低级语言比高级语言难以理解 8 先进的软件开发技术 在软件开发时 若使用能 使软件结构比较稳定的分析与设计技术及程序设计 技术 如面向对象技术 复用技术等 可减少大量 的维护工作量 9 其他 前一页 休息 8 第10章软件维护 软件维护的策略 1 改正性维护 通常要生成100 可靠的软件并不一定合算 成本太高 但通过使用新技术 可大大提高 可靠性 并减少进行改正性维护的需要 减少改正性维护的方法 利用应用软件包和API 直接复用现成的 可 靠的 可复用构件以降低维护难度 采用结构化和模块化的开发方法 降低理解 和测试的难度 采用防错性编程技术 把自检能力引入程序 通过非正常状态的检查 提供审查跟踪能力 通过周期性维护审查 在形成维护问题之前 就可确定质量缺陷 前一页 休息 9 第10章软件维护 软件维护的策略 2 适应性维护 这一类的维护不可避免 但可以控制 在配置管理时 把硬件 操作系统和其他相 关环境因素的可能变化考虑在内 可以减少某些 适应性维护的工作量 采用信息隐蔽的原则 把与硬件 操作系统 以及其他外围设备有关的程序归到特定的程序模 块中 尽可能避免直接与它们交互 这样 一旦 环境变化 可把必须修改的程序局限到某些程序 模块之中 使用内部程序列表 外部文件 以及处理的 例行程序包 可为维护时修改程序提供方便 前一页 休息 10 第10章软件维护 软件维护的策略 3 完善性维护 利用前两类维护中列举的方法 也可以减少 这一类维护 特别是数据库管理系统 程序 生成器 应用软件包 可减少系统或程序员 的维护工作量 前一页 休息 11 第10章软件维护 维护成本 在过去的几十年中 软件维护的费用稳步上升 1970年用于维护已有软件的费用只占软件总预算的 35 40 1980年上升为40 60 1990年 上升为70 80 维护费用只不过是软件维护的最明显的代价 其他 一些现在还不明显的代价将来可能更为人们所关注 因为可用的资源必须供维护任务使用 以致耽误甚 至丧失了开发的良机 这是软件维护的一个无形的 代价 其他无形的代价还有 当看来合理的有关改错或修改的要求不能及 时满足时将引起用户不满 由于维护时的改动 在软件中引入了潜伏的 故障 从而降低了软件的质量 当必须把软件工程师调去从事维护工作时 将在开发过程中造成混乱 前一页 休息 12 第10章软件维护 维护成本 软件维护的最后一个代价是生产率的大幅度下降 这种情况 在维护旧程序时常常遇到 例如 据Gausler在1976年的报 道 美国空军的飞行控制软件每条指令的开发成本是75美元 然而维护成本大约是每条指令4000美元 也就是说 生产 率下降了50倍以上 用于维护工作的劳动可以分成生产性活动 例如 分析评价 修改设计和编写程序代码等 和非生产性活动 例如 理解 程序代码的功能 解释数据结构 接口特点和性能限度等 下述表达式给以维护工作量的一个模型 M P十K e c d 其中 M是维护用的总工作量 P是生产性工作量 K是经验常数 c是复杂程度 非结构化设计和缺少文档都会增加软件的复 杂程度 d是维护人员对软件的熟悉程度 上面的模型表明 如果软件的开发途径不好 即 没有使用 软件工程方法论 而且原来的开发人员不能参加维护工作 那么维护工作量 和费用 将指数地增加 前一页 休息 13 第10章软件维护 维护成本 维护成本还需要追加下列的费用 到用户处的差旅费用 对维护人员以及用户的培训费用 软件工程环境和软件测试环境的成本和年度 维护费用 薪金及津贴之类的人员费用 前一页 休息 14 第10章软件维护 10 2软件维护的活动 前一页 休息 15 第10章软件维护 维护活动 维护过程本质上是修改和压缩了的软件定义 和开发过程 而且事实上远在提出一项维护 要求之前 与软件维护有关的工作已经开始 了 首先必须建立一个维护组织 随后必须 确定报告和评价的过程 而且必须为每个维 护要求规定一个标准化的事件序列 此外 还应该建立一个适用于维护活动的记录保管 过程 并且规定复审标准 前一页 休息 16 第10章软件维护 维护机构 虽然通常并不需要建立正式的维护组织 但 是 即使对于一个小的软件开发团体而言 非正式地委托责任也是绝对必要的 每个维 护要求都通过维护管理员转交给相应的系统 管理员去评价 系统管理员是被指定去熟悉 一小部分产品程序的技术人员 系统管理员 对维护任务做出评价之后 由变化授权人决 定应该进行的活动 前一页 休息 17 第10章软件维护 维护机构 前一页 休息 18 第10章软件维护 软件维护申请报告 应该用标准化的格式表达所有软件维护要求 软件维护 人员通常给用户提供空白的维护要求表 有时称为软件 问题报告表 这个表格由要求一项维护活动的用户填写 如果遇到了一个错误 那么必须完整描述导致出现错误的 环境 包括输入数据 全部输出数据 以及其他有关信 息 对于适应性或完善性的维护要求 应该提出一个简 短的需求说明书 如前所述 由维护管理员和系统管理员 评价用户提交的维护要求表 维护要求表是一个外部产生的文件 它是计划维护活动 的基础 软件组织内部应该制定出一个软件修改报告 它 给出下述信息 前一页 满足维护要求表中提出的要求所需要的工作量 维护要求的性质 这项要求的优先次序 与修改有关的事后数据 休息 19 第10章软件维护 软件维护过程模型 1 快速修改模型 此模型是一种软件维护的临时定制方法 是 一种 救火式 的方法 一旦问题出现 尽 可能迅速解决 前一页 休息 20 第10章软件维护 软件维护过程模型 2 Boehm模型 Boehm把维护过程表示为闭合环路 如图所 示 在此模型中 管理层基于成本和时间考 虑的决策是很多过程背后的主要推动力量 前一页 休息 21 第10章软件维护 软件维护过程模型 3 Osborne模型 模型可以被当做开 发生存周期的持续 迭代 但在每个阶 段都将可维护性考 虑在内 采取相应 的措施 前一页 休息 22 第10章软件维护 软件维护过程模型 4 面向复用的Basili模型 面向复用的模型将维护看做是一组复用现有 程序构件的活动 主要有4个步骤 标识可供复用的老系统部件 理解这些系统部件 修改这些系统部件 以适应新的需求 将修改后的系统部件集成到新系统中 前一页 休息 23 第10章软件维护 软件维护的工作流程 前一页 休息 24 第10章软件维护 软件维护的工作流程 第一步是确认维护要求 这需要维护人员与 用户反复协商 弄清错误概况以及对业务的 影响大小 以及用户希望做什么样的修改 并把这些情况存入故障数据库 然后由维护 组织管理员确认维护类型 前一页 休息 25 第10章软件维护 软件维护的工作流程 在完成软件维护任务之后 进行复查常常是 有好处的 一般说来 这种复查试图回答下述 问题 在当前处境下设计 编码或测试的哪些方 面能用不同方法进行 哪些维护资源是应该有而事实上却没有的 对于这项维护工作什么是主要的 以及次 要的 障碍 要求的维护类型中有预防性维护吗 复查对将来维护工作的进行有重要影响 而 且所提供的反馈信息对有效地管理软件组织十 分重要 前一页 休息 26 第10章软件维护 维护记录文档 对于软件生命周期的所有阶段而言 以前记 录保存都是不充分的 而软件维护则根本没 有记录保存下来 由于这个原因 我们往往 不能估价维护技术的有效性 不能确定一个 产品程序的 优良 程度 而且很难确定维 护的实际代价是什么 前一页 休息 27 第10章软件维护 维护记录文档 Swanson提出了下述内容 程序标识 源语句数 机器指令条数 使用的程序设计语言 程序安装的日期 自从安装以来程序运行的次数 自从安装以来程序失效的次数 程序变动的层次和标识 因程序变动而增加的源语句数 前一页 休息 28 第10章软件维护 维护记录文档 Swanson提出了下述内容 每个改动耗费的人时数 因程序变动而删除的源语句数 程序改动的日期 软件工程师的名字 维护要求表的标识 维护类型 维护开始和完成的日期 累计用于维护的人时数 与完成的维护相联系的纯效益 前一页 休息 29 第10章软件维护 评价维护活动 缺乏有效的数据就无法评价维护活动 如果已经开 始保存维护记录了 则可以对维护工作做一些定量度 量 至少可以从下述七个方面度量维护工作 每次程序运行平均失效的次数 用于每一类维护活动的总人时数 平均每个程序 每种语言 每种维护类型所做的程序 变动数 维护过程中增加或删除一个源语句平均花费的人时数 维护每种语言平均花费的人时数 一张维护要求表的平均周转时间 不同维护类型所占的百分比 根据对维护工作定量度量的结果 可以做出关于开 发技术 语言选择 维护工作量规划 资源分配及其 他许多方面的决定 而且可以利用这样的数据去分析 评价维护任务 前一页 休息 30 第10章软件维护 10 3程序修改的步骤及修改的副作用 前一页 休息 31 第10章软件维护 结构化维护与非结构化维护 如果软件配置的唯一成分是程序代码 那么维护活 动从艰苦地评价程序代码开始 而且常常由于程序 内部文档不足而使评价更困难 诸如软件结构 全 程数据结构 系统接口 性能和 或 设计约束等 微妙的特点是难于搞清的 而且常常误解了这一类 特点 最终对程序代码所做的改动的后果是难于估 量的 因为没有测试方面的文档 所以不可能进行 回归测试 即为了保证所做的修改没有在以前可以 正常使用的软件功能中引入故障而重复过去做过的 测试 可惜 我们正在进行非结构化维护 并且 正在为此而付出代价 浪费精力和受挫折 这种 维护方式是没有使用良好定义的方法论开发出来的 软件的必然结果 前一页 休息 32 第10章软件维护 结构化维护与非结构化维护 如果有一个完整的软件配置存在 那么维护工作从 评价设计文档开始 确定软件重要的结构特点 性 能特点以及接口特点 估量要求的改动将带来的影 响 并且计划实施途径 然后首先修改设计并且对 所做的修改进行仔细复查 接下来编写相应的源程 序代码 使用在测试说明书中包含的信息进行回归 测试 最后 把修改后的软件再次交付使用 刚才描述的事件构成结构化维护 它是在软件开发 的早期应用软件工程方法论的结果 虽然有了软件 的完整配置并不能保证维护中没有问题 但是确实 能减少精力的浪费并且能提高维护的总体质量 前一页 休息 33 第10章软件维护 结构化维护与非结构化维护 前一页 休息 34 第10章软件维护 软件维护面临的问题 与软件维护有关的绝大多数问题 都可归因于软件定义和软 件开发的方法有缺点 在软件生命周期的头两个时期没有严 格而又科学的管理和规划 几乎必然会导致在最后阶段出现 问题 下面列出和软件维护有关的部分问题 理解别人写的程序通常非常困难 而且困难程度随着软 件配置成分的减少而迅速增加 如果仅有程序代码没有说明 文档 则会出现严重的问题 需要维护的软件往往没有合格的文档 或者文档资料显 著不足 认识到软件必须有文档仅仅是第一步 容易理解的 并且和程序代码完全一致的文档才真正有价值 当要求对软件进行维护时 不能指望由开发人员给我们 仔细说明软件 由于维护阶段持续的时间很长 因此 当需 要解释软件时 往往原来写程序的人已经不在附近了 绝大多数软件在设计时没有考虑将来的修改 除非使用 强调模块独立原理的设计方法论 否则修改软件既困难又容 易发生差错 软件维护不是一项吸引人的工作 形成这种观念很大程 度上是因为维护工作经常遭受挫折 前一页 休息 35 第10章软件维护 维护过程中软件人员的安排 要使全体软件人员认识到维护与开发同等重要 同 样具有难度 安排的维护人员应是技术合格的 有责任心的人 不能把维护工作看做对初级人员的 放任自流 式 的培训 全体软件人员应当轮流分配去做维护和开发工作 出色的维护工作应同出色的开发工作一样受到奖励 必须强调对维护人员进行良好的培训 轮换分配 不应让一个系统或一个系统的主要部分 成为某个人的专有领地 前一页 休息 36 第10章软件维护 分析和理解程序 经过分析 全面 准确 迅速地理解程序是 决定维护成败和质量好坏的关键 在这方面 软件的可理解性和文档的质量非常重要 理解程序的功能和目标 掌握程序的结构信息 即从程序中细分出若干结 构成分 如程序系统结构 控制结构 数据结 构和输入 输出结构等 了解数据流信息 即涉及到的数据来源何处 在 哪里被使用 了解控制流信息 即执行每条路径的结果 理解程序的操作 使用 要求 37 前一页 休息 第10章软件维护 分析和理解程序 为了容易地理解程序 要求自顶向下地理解 现有源程序的程序结构和数据结构 可采用 以下方法 分析程序结构图 数据跟踪 控制跟踪 在分析过程中 充分阅读和使用程序清单 和文档 分析文档的合理性 充分使用由编译或汇编程序提供的交叉引 用表 符号表及其他有用信息 如有可能 积极参加开发工作 前一页 休息 38 第10章软件维护 分析程序结构图 搜集所有存储该程序的文件 阅读这些文件 记下 它们包含的过程名 建立一个包括这些过程名和文 件名的清单 分析各个过程的源代码 建立一个直接调用矩阵D 或调用树 若过程i调用过程j 则D i j 1 否则 D i j 0 建立过程的间接调用矩阵I 即直接调用矩阵D的传 递闭包 2 D3 Dn I D D 其中 n是所包含的过程总数 例如 过程i调用j j调用k 则D i j 1 D j k 1 I i k 1 分析各个过程的接口 估计更改的复杂性 前一页 休息 39 第10章软件维护 数据跟踪 建立各层次的程序级上的接口图 展示各 模块或过程的调用方式和接口参数 利用数据流分析方法 对过程内部的一些 变量进行跟踪 可获得有关数据在过程间如 何传递 在过程内如何处理等信息 对于判 断问题原因特别有用 在跟踪的过程中可在 源程序中间插入自己的注释 前一页 休息 40 第10章软件维护 控制跟踪 控制流跟踪可采用符号执行或实际动态跟踪 的方法 了解数据如何从一个输入源到达输 出点的 前一页 休息 41 第10章软件维护 评估修改范围 通常 可采用自顶向下的方法 在理解程序的基础上 研究程序的各个模块 模块的接口 及数据库 从全局的观点 提出修改计划 依次地把要修改的 以及那些受修改影响的模块 和数据结构分离出来 为此 要 识别受修改影响的数据 识别使用这些数据的程序模块 对于上面程序模块 按是产生数据 修改数据 还是删除数据进行分类 识别对这些数据元素的外部控制信息 识别编辑和检查这些数据元素的地方 隔离要修改的部分 前一页 休息 42 第10章软件维护 评估修改范围 详细地分析要修改的 以及那些受变更影响的模 块和数据结构的内部细节 设计修改计划 标明 新逻辑及要改动的现有逻辑 如果涉及与性能 安全性与保密性有关的算法 要对算法做分析 确定算法的适用性和正确性 可能的影响和效果 确定修改的规模 可以用源代码行数或功能点来 度量 然后 凭借维护人员或管理者的经验或 依据COCOMO模型等进一步估算需要的工作量 从而估算出修改需要的成本和时间 将以上的结果形成修改请求文档 提交维护管理 员批准 前一页 休息 43 第10章软件维护 评估修改范围 5 确定修改的规模 可以用源代码行数或功 能点来度量 然后 凭借维护人员或管理 者的经验或依据COCOMO模型等进一步估算 需要的工作量 从而估算出修改需要的成本 和时间 6 将以上的结果形成修改请求文档 提交维 护管理员批准 前一页 休息 44 第10章软件维护 修改程序 对程序的修改 必须事先做出计划 有预谋 地 周密有效地实施修改 1 设计程序的修改计划 程序的修改计划要考虑人员和资源的安排 对于需 要耗时数月的修改 就需要计划立案 在编写有关问题解决的方案时 必须充分描述修改 作业的规格说明 规格说明信息 数据修改 处理修改 作业控 制语言修改 系统之间接口的修改等 维护资源 新程序版本 测试数据 所需软件 计算机时间等 人员 支持 纸面 计算机媒体等 前一页 休息 45 第10章软件维护 修改程序 2 向用户提供回避措施 用户的某些业务因软件中发生问题而中断 为不让系统长时间停止运行 需把问题局部化 在可能的范围内继续开展业务 可以采取的措施有 查找问题原因 可能情况有 意外停机 安装的期限到期 系统运行中发现错误 如果弄清了问题的原因 可通过临时修改或改 变运行控制以回避在系统运行时产生的问题 前一页 休息 46 第10章软件维护 修改程序 3 修改代码 以适应变化 在修改时 要求 正确 有效地编写修改代码 要谨慎地修改程序 尽量保持程序的风格及格式 要在程序清单上注明改动的指令 不要删除程序语句 除非完全肯定它是无用的 不要试图共用程序中已有的临时变量或工作区 为了避免冲突或混淆用途 应设置自己的变量 插入错误检测语句 在修改过程中做好修改的详细记录 消除变更中 任何有害的副作用 波动效应 47 前一页 休息 第10章软件维护 修改程序 4 修改程序的副作用 所谓副作用是指因修改软件而造成的错误或 其它不希望发生的情况 副作用有三种 修改 代码的副作用 修改数据的副作用 文档的副 作用 前一页 休息 48 第10章软件维护 修改代码的副作用 在修改源代码时 都可能引入错误 例如 删除或修改一个子程序 删除或修改一个标 号 删除或修改一个标识符 改变程序代码 的时序关系 改变占用存储的大小 改变逻 辑运算符 修改文件的打开或关闭 改进程 序的执行效率 以及把设计上的改变翻译成 代码的改变时 都容易引入错误 前一页 休息 49 第10章软件维护 修改数据的副作用 在修改数据结构时 有可能造成软件设计与数据结 构不匹配 因而导致软件出错 数据副作用就是修改软件信息结构导致的结果 容易导致设计与数据不相容的错误可以有 重新定义局部的或全局的常量 重新定义记录或文件的格式 增大或减小一个数组或高层数据结构的大小 修改全局或公共数据 重新初始化控制标志或指针 重新排列输入 输出或子程序的参数 数据副作用可以通过交叉引用表加以控制 把数据 元素 记录 文件和其它结构联系起来 50 前一页 休息 第10章软件维护 文档的副作用 对数据流 软件结构 模块逻辑或任何其它有关特性进行 修改时 必须对相关技术文档进行相应修改 否则会导致文 档与程序功能不匹配 缺省条件改变 新错误信息不正确等 错误 使得软件文档不能反映软件的当前状态 对于用户来说 软件事实上就是文档 如果对可执行软件的修改不反映在文档里 就会产生文档的 副作用 对交互输入的顺序或格式进行修改 如果没有正确地记 入文档中 就可能引起重大的问题 过时的文档内容 索引和文本可能造成冲突 引起用户 失败和不满 因此 必须在软件交付之前对整个软件配置进行评审 以减 少文档的副作用 前一页 休息 51 第10章软件维护 控制因修改而引起的副作用 为了控制因修改而引起的副作用 要做到 按模块把修改分组 自顶向下地安排被修改模块的顺序 每次修改一个模块 对于每个修改了的模块 在安排修改下一 个模块之前 要确定这个修改的副作用 可 以使用交叉引用表 存储映象表 执行流程 跟踪等 前一页 休息 52 第10章软件维护 重新验证程序 将修改后的程序交付用户之前 需要用以下 的方法进行充分的确认和测试 以保证整个修 改后的程序的正确性 静态确认 回归测试 维护后的验收 前一页 休息 53 第10章软件维护 静态确认 修改软件 伴随着引起新的错误的危险 为 了能够做出正确的判断 验证修改后的程序 至少需要两个人参加 要检查 修改是否涉及到规格说明 修改结果是否 符合规格说明 有没有歪曲规格说明 程序的修改是否足以修正软件中的问题 源程序代码有无逻辑错误 修改时有无修补 失误 修改部分对其它部分有无不良影响 副作 用 对软件进行修改 常常会引发别的问题 有 必要检查修改的影响范围 前一页 休息 54 第10章软件维护 回归测试 在进行了以上确认的基础上 用计算机对修 改程序进行确认测试 确认测试顺序 先对修改部分进行测试 然后隔离修改部分 测试程序的未修改部分 最后再把它们集成起来进行测试 这种测试 称为回归测试 准备标准的测试用例 充分利用软件工具帮助重新验证过程 在重新确认过程中 需邀请用户参加 前一页 休息 55 第10章软件维护 维护后的验收 在交付新软件之前 维护主管部门要检验 全部文档是否完备 并已更新 所有测试用例和测试结果已经正确记载 记录软件配置所有副本的工作已经完成 维护工序和责任已经确定 前一页 休息 56 第10章软件维护 10 4面向对象软件的维护 前一页 休息 57 第10章软件维护 10 5软件可维护性 前一页 休息 58 第10章软件维护 软件可维护性的定义 软件可维护性是指纠正软件系统出现的错误 和缺陷 以及为满足新的要求进行修改 扩 充或压缩的容易程度 可维护性 可使用性 可靠性是衡量软件质 量的主要质量特性 也是用户十分关心的几 个方面 软件的可维护性是软件开发阶段各个时期的 关键目标 前一页 休息 59 第10章软件维护 决定软件可维护性的因素 1 可理解性 软件可理解性表现为外来读者理解软件的结构 接口 功能 和内部过程的难易程度 模块化 详细的设计文档 结构化 设计 源代码内部的文档和良好的高级程序设计语言等等 都对改进软件的可理解性有重要贡献 2 可靠性 可靠性表明一个程序按照用户的要求和设计目标 在给定的 一段时间内正确执行的概率 3 可测试性 诊断和测试的难易程度主要取决于软件容易理解的程度 良 好的文档对诊断和测试是至关重要的 此外 软件结构 可 用的测试工具和调试工具 以及以前设计的测试过程也都是 非常重要的 维护人员应该能够得到在开发阶段用过的测试 方案 以便进行回归测试 在设计阶段应该尽力把软件设计 成容易测试和容易诊断的 休息 前一页 60 第10章软件维护 决定软件可维护性的因素 4 可修改性 软件容易修改的程度和本书第四章讲述的设计原理和规则直 接有关 耦合 内聚 局部化 控制域与作用域的关系等等 都影响软件的可修改性 5 可移植性 可移植性表明程序转移到一个新的计算环境的可能性大小 或者它表明程序可以容易地 有效地在各种各样的计算环境 中运行的容易程度 6 效率 效率表明一个程序执行预定功能而又不浪费机器资源的程 度 7 可使用性 从用户观点出发 把可使用性定义为程序方便 实用 及易 于使用的程度 8 其他间接定量度量可维护性方法 前一页 休息 61 第10章软件维护 10 6提高可维护性的方法 前一页 休息 62 第10章软件维护 建立明确的软件质量目标和优先级 一个可维护的程序应是可理解的 可靠的 可测试 的 可修改的 可移植的 效率高的 可使用的 要实现这所有的目标 需要付出很大的代价 而且 也不一定行得通 某些质量特性是相互促进的 例如可理解性和可测 试性 可理解性和可修改性 另一些质量特性是相互抵触的 如效率和可移植性 效率和可修改性等 每一种质量特性的相对重要性应随程序的用途及计 算环境的不同而不同 例如 对编译程序来说 可 能强调效率 但对管理信息系统来说 则可能强调 可使用性和可修改性 应当对程序的质量特性 在提出目标的同时还必须 规定它们的优先级 前一页 休息 63 第10章软件维护 使用提高软件质量的技术和工具 模块化 如果需要改变某个模块的功能 则只要改变这个模块 对其它模块影响很小 如果需要增加程序的某些功能 则仅需增加完成这些功 能的新的模块或模块层 程序的测试与重复测试比较容易 程序错误易于定位和纠正 结构化程序设计 程序被划分成分层的模块结构 模块调用控制必须从模块的入口点进入 从其出口点退 出 模块的控制结构仅限于顺序 选择 重复三种 且没有 GOTO语句 每个程序变量只用于唯一的程序目的 而且变量的作用 范围应是明确的 有限制的 前一页 休息 64 第10章软件维护 使用提高软件质量的技术和工具 使用结构化程序设计技术 提高现有系统的 可维护性 采用备用件的方法 用一个新的结构良好的 模块替换掉整个要修改的模块 采用自动重建结构和重新格式化的工具 结构更 新技术 把非结构化代码转换成良好结构代 码 改进现有程序的不完善的文档 建立或补充 系统说明书 设计文档 模块说明书 以及在 源程序中插入必要的注释 前一页 休息 65 第10章软件维护 进行明确的质量保证审查 质量保证审查对于获得和维持软件的质量 是一个 很有用的技术 审查可以用来检测在开发和维护阶段内发生的质量 变化 一旦检测出问题来 就可以采取措施来纠正 以控 制不断增长的软件维护成本 延长软件系统的有效 生命期 1 在检查点进行复审 保证软件质量的最佳方法是在软件开发的最初阶段把质量要求考虑 进去 并在开发过程每一阶段的终点 设置检查点进行检查 检查的目的是要证实 已开发的软件是否符合标准 是否满足规定 的质量需求 在不同的检查点 检查的重点不完全相同 在设计阶段 检查重点是可理解性 可修改性 可测试性 可理解性检查的重点是程序的复杂性 对每个模块可用McCabe环路 来计算模块的复杂性 若大于10 则需重新设计 可以使用各种质量特性检查表 或用度量标准来检查可维护性 审查小组可以采用人工测试一类的方式 进行审查 休息 前一页 66 第10章软件维护 进行明确的质量保证审查 2 验收检查 验收检查是一个特殊的检查点的检查 是交付使用前的 最后一次检查 验收检查实际上是验收测试的一部分 只不过它是从维 护的角度提出验收的条件和标准 验收检查必须遵循的最小验收标准 1 需求和规范标准 需求应当以可测试的术语进行书写 排列优先次序 和定义 区分必须的 任选的 将来的需求 包括对系统运行时的计算机设备的需求 对维护 测试 操作 以及维护人员的需求 对测试工具等的需 求 前一页 休息 67 第10章软件维护 进行明确的质量保证审查 2 设计标准 程序应设计成分层的模块结构 每个模块应完成唯 一的功能 并达到高内聚 低耦合 通过一些知道预期变化的实例 说明设计的可扩充 性 可缩减性和可适应性 3 源代码标准 尽可能使用最高级的程序设计语言 且只使用语言 的标准版本 所有的代码都必须具有良好的结构 所有的代码都必须文档化 在注释中说明它的输入 输出 以及便于测试 再测试的一些特点与风格 前一页 休息 68 第10章软件维护 进行明确的质量保证审查 4 文档标准 文档中应说明 程序的输入 输出 使用的方法 算法 错误恢复方法 所有参数的范围 缺省条件等 前一页 休息 69 第10章软件维护 进行明确的质量保证审查 3 周期性地维护审查 检查点复查和验收检查 可用来保证新软件系统的可维 护性 对已有的软件系统 则应当进行周期性的维护检查 软件在运行期间进行修改 会导致软件质量有变坏的危 险 破坏程序概念的完整性 必须定期检查 对软件做周期性的维护审查 以跟踪软 件质量的变化 周期性维护审查实际上是开发阶段检查点复查的继续 并且采用的检查方法 检查内容都是相同的 维护审查的结果可以同以前的维护审查的结果 以前的 验收检查的结果 检查点检查的结果相比较 任何一种 改变都表明在软件质量上或其它类型的问题上可能起了 变化 对于改变的原因应当进行分析 前一页 休息 70 第10章软件维护 进行明确的质量保证审查 4 对软件包进行检查 软件包是一种标准化的 可为不同单位 不同用户使用 的软件 一般源代码和程序文档不会提供给用户 对软件包的维护采取以下方法 使用单位的维护人员首先要仔细分析 研究卖主提供的用户手册 操作手册 培训教程等 以及卖方提供的验收测试报告等 在此基础上 深入了解本单位的希望和要求 编制软件包的检验 程序 检查软件包程序所执行的功能是否与用户的要求和条件相一致 为了建立这个程序 维护人员可以利用卖方提供的验收测试实例 还可以自己重新设计新的测试实例 根据测试结果 检查和验证软件包的参数或控制结构 以完成软 件包的维护 前一页 休息 71 第10章软件维护 选择可维护的程序设计语言 程序设计语言的选择 对程序的可维护性影 响很大 前一页 休息 72 第10章软件维护 改进程序的文档 程序文档是对程序总目标 程序各组成部分之间的关系 程 序设计策略 程序实现过程的历史数据等的说明和补充 即使是一个十分简单的程序 要想有效地 高效率地维护它 也需要编制文档来解释其目的及任务 对于程序维护人员来说 要想按程序编制人员的意图重新改 造程序 并对今后变化的可能性进行估计 缺了文档是不行 的 因此 为了维护程序 人们必须阅读和理解文档 另外 在软件维护阶段 利用历史文档 可以大大简化维护 工作 通过了解原设计思想 可以判断出错之处 指导维护 人员选择适当的方法修改代码而不危及系统的完整性 历史文档有三种 系统开发日志 错误记载 系统维护日志 前一页 休息 73 第10章软件维护 10 7遗留系统的再工程 前一页 休息 74 再工程 什么是再工程 再工程 SoftwareReengineering 指在逆向工程所获信息的基础上修改或重构已有的系统 产生系统的一个新版本 再工程是一类软件工程活动 是一个工程过程 它将逆向工程 重构和正向工程组合起来 将现存系统重新构造为新的形式 再工程的基础是系统理解 包括对运行系统 源代码 设计 分析 文档等的全面理解 但在很多情况下 由于各类文档的丢失 只能对源代码进行理解 即程序理解 它能够使我们 增进对软件的理解 提高软件自身的可维护性 复用性或演化性 为什么要实施软件再工程 再工程可帮助降低软件演化风险再工程可帮助补偿软件投资再工程可使得软件易于进一步变更再工程有广阔市场再工程扩大了CASE工具集再工程是推动自动软件维护的动力 在软件复用中 有问题是与现有系统密切相关的例如 现有软件系统如何适应当前技术的发展及需求的变化 采用更易于理解的 适应变化的 可复用的系统软件构架并提炼出可复用的软件构件 现存大量的遗产软件系统 LegacySoftware 由于技术的发展 正逐渐退出使用 如何对这些系统进行挖掘 整理 得到有用的软件构件 已有的软件构件随着时间的流逝会逐渐变得不可使用 如何对它们进行维护 以延长其生命期 充分利用这些可复用构件 软件再工程正是解决上述问题的主要技术手段 再工程的概念 通常再工程包含 业务过程再工程 软件再工程业务过程再工程 BPR BusinessProcessRe engineering 也称业务过程重组 定义业务目标 标示并评估现有的业务过程以及修订业务过程以更好满足业务目标 这一部分通常由咨询公司的业务专家完成软件再工程包含库存目录分析 文档重构 逆向工程 程序和数据重构以及正向工程 这一部分通常由软件工程师完成 1 业务过程再工程 MichaelHammer的 是业务过程和计算管理革命的奠基性文章 Hammer在文章中大力呼吁使用业务过程再工程技术 不过 到21世纪初 对于业务过程再工程的宣传已经不太常见 但是这种过程已经在很多公司中得到使用 业务过程是一组 逻辑相关的任务 它们被执行以达到符合预定义的业务结果 2 软件再工程 在业务过程被分析清楚后 可以对软件实施再工程 整个软件再工程过程模型如下图 软件再工程过程模型 代码重构 数据重构 正向工程 库存目录分析 文档重构 逆向工程 软件再工程过程 续 1 库存目录分析包含关于每个应用系统的基本信息 例如 应用系统的名字 最初构建它的日期 已做过的实质性修改次数 过去18个月报告的错误 用户数量 安装它的机器数量 它的复杂程度 文档质量 整体可维护性等级 预期寿命 在未来36个月内的预期修改次数 业务重要程度等 下述3类程序有可能成为预防性维护的对象 预定将使用多年的程序 当前正在成功地使用着的程序和在最近的将来可能要做重大修改或增强的程序 软件再工程过程 续 2 文档重构建立文档非常耗费时间 不可能为数百个程序都重新建立文档 如果一个程序是相对稳定的 而且可能不会再经历什么变化 那么 让它保持现状 为了便于今后的维护 必须更新文档 但只针对系统中当前正在修改的那些部分建立完整文档 如果某应用系统是完成业务工作的关键 而且必须重构全部文档 则仍然应该设法把文档工作减少到必需的最小量 软件再工程过程 续 3 逆向工程软件的逆向工程是分析程序以便在比源代码更高的抽象层次上创建出程序的某种表示的过程 逆向工程工具从现存的程序代码中抽取有关数据 体系结构和处理过程的设计信息 逆向工程是把软件源程序还原为软件文档或软件设计的过程 通过逆向工程 可以从更高的抽象度来观察软件 抽象度的多少可由抽象的层次 文档的完整性 工具等因素决定 逆向工程来源于硬件世界 硬件厂商总想弄到竞争对手产品的设计和制造 奥秘 但是又得不到现成的档案 只好拆卸对手的产品并进行分析 企图从中获取有价值的东西 软件的逆向工程在道理上与硬件相似 但在很多时候 软件的逆向工程并不是针对竞争对手的 而是针对自己公司多年前的产品 期望从老产品中提取系统设计 需求说明等有价值的信息 逆向工程 反推工程reverseengineering 从现有软件恢复设计信息 有用的维护信息 设计的恢复过程 非结构化 无文档的源代码或目标代码 软件的全部文档 逆向工程 源程序 目标代码 反汇编 反编译程序分析技术 程序结构分析工具