软件维护

软件产品交付用户使用后 软件生存周期中的重要阶段 软件维护随之而来 软件维护是使软件能产生良好的经济效益与社会效益的前提与保证 据统计 软件维护占整个软件生存周期总工作量的10 至70 不等 由此可见软件维护的重要性 软件维护意义重大 第12章软件维护 12 1概述软件维护是指已完成开发工作 交付使用以后 对软件产品所进行的一些软件工程活动 做好软件的维护工作不仅能排除障碍 使它能够正常工作 还可以使它扩充功能 提高性能 12 1 1软件维护工作的必要性原因有以下几个方面 1 改正在运行中新发现的软件错误和设计上的缺陷之处 这些错误和缺陷是在开发后期的测试阶段未能发现的 2 改进设计 以便增强软件的功能 提高软件的性能 3 要求已运行的软件能适应特定的硬件 软件 外部设计和通信设备等 4 为使投入运行的软件与其他相关的程序有良好的接口 5 为使运行软件的应用范围得到必要的扩充 软件维护概念 是指在软件的运行 维护阶段由软件厂商向客户所提供的服务工作 三层含义 1 软件的维护总是针对某一种软件产品在软件生存周期内所进行的活动 2 当今的软件维护更强调的是服务 在激烈的市场竞争中 同类软件产品的价格 功能 性能和接口等都差不多 而服务就会成为用户选购软件的重要依据 即 卖软件就是卖服务 3 软件维护的时间是有限度的 一般而言目前软件产品的免费服务时间为两年左右 两年以后软件厂商总会推出更新的版本以适应用户在功能 性能 接口等方面所提出的新需求 从而软件厂商也会找到新的利润增长点 维护工作面临的主要问题包括 许多技术人员重开发 轻维护 不少用户对软件维护的知识了解得很少 也有人以为 运行中发生的问题都应该由原开发人员或原开发部门来解决 把维护阶段的工作与开发阶段的工作混为一谈 如何维持旺盛士气 改善支持环境 软件维护困难的原因 软件人员经常流动 当需要对某些程序进行维护时 可能已找不到原来的开发人员 人们一般难以读懂他人的程序 当没有文档或者文档很差时 你不知道如何下手 很多程序在设计时没有考虑到将来要改动 程序之间相互交织 触一而牵百 如果软件发行了多个版本 要追踪软件的演化非常困难 维护将会产生不良的副作用 不论是修改代码 数据或文档 都有可能产生新的错误 维护工作毫无吸引力 12 1 2软件维护的内容 维护的起因一般分为三种基本类型 1 故障2 环境变化3 用户和维护人员的要求12 1 2 1改正 纠错 性维护改正性维护 CorrectiveMaintenance 是在软件运行中发生异常或故障时进行的 改正性维护可能是 改正原来程序中未使开发复原的错误 解决开发时未能测试各种可能条件带来的问题 解决原来程序中遗漏处理文件中最后一个记录的问题 12 1 2 2适应性维护适应性维护 AdaptiveMaintenance 是要使运行的软件能适应外部环境的变动 适应性维护可能是 为现有的某个应用问题实现一个数据库管理系统 对某个指定编码进行修改 从3个字符改成4个字符 缩短系统的应答时间 使其达到特定要求 修改程序 时期适用于另外的终端 12 1 2 3完善性维护完善性维护 PerfectiveMaintenance 是为扩充软件的功能 提高原有软件性能而开展的软件工程活动 修改计算机工资程序 使其增加新的扣除项目 在已有的性能分析程序中增加包括若干属性的新报告 把现有程序的终端对话方式加以改造 使其具有方便用户使用的界面 改进图形输出 增加联机求助 Help 命令 为软件的运行增加监控设施 软件维护分四类 纠错性维护占17 20 适应性维护占18 25 完善性维护 占50 60 预防性维护占4 左右 改正在特定的使用条件下软件中暴露出来的错误与缺陷 这些错误或缺陷在测试时并未被发现 使软件产品能够适应变化了的运行环境 如操作系统版本的升级 机器配置的变化 软件使用对象的变化等 为适应用户对软件功能 性能或接口方面提出的新要求以使产品更加完善与合理而进行的修改 提高产品的可靠性和可维护性 减少今后维护的工作量 有利于系统和进一步改造或升级换代而进行的维护 从软件配置看维护分类 结构化维护 非结构化维护 基于完整的软件配置而进行的维护 从评价设计文档开始 根据文档来确定该软件的结构特性 性能特性和接口特性 借此来估计改正或修改可能带来的影响 根据影响准备相应的处理办法 然后修改设计 进行评审 编写新的程序代码并进行回归测试 成功后交付使用 使用软件工程的方法开发的软件 虽然不能保证维护没有问题 但可以减少维护的工作量 并提高维护的效率与质量 如果软件项目的开发没有遵循软件工程的方法 那么这种软件的维护就是非结构化的维护非结构化维护基于的惟一成份只有程序代码 这种维护是非常困难而又艰苦的 12 1 3维护工作的过程 整个维护工作包括以下几个依次进行的阶段 1 接受提出的维护要求 2 对所要求的内容进行分析 3 对现有系统进行调查 确定修改范围 4 决定维护作业的内容 5 修改现行系统 6 对修改部分进行测试 7 对整个系统进行测试 确定其品质 8 修改后的系统投入正常的运行 12 1 4影响维护工作的因素 影响一个软件系统维护的困难程序 主要的有以下几个程序因素 1 系统大小 2 系统年龄 3 输入 输出数据项个数 4 应用类型 5 程序设计语言 6 结构化程度 12 1 5维护策略 程序维护技术水平发展的现状可以用以下几点来概括 1 多数单位留有的维护历史资料很少 2 维护问题既包括技术问题 又包括非技术问题 3 尽管现行软件开发技术作为开发工具时 可以提高软件的质量 特别是可靠性 但他们不涉及软件可维护性的所有方面 4 因为几乎一半的维护工作与持续的开发任务有关 维护工作比通常所设想的更类似于开发工程 5 一半以上的维护工作属于完善性维护 6 软件系统的维护工作量取决于系统的大小 年龄 质量以及维护人员的开发经验等变量 7 程序质量常常随时间而老化变坏 12 1 5 1控制维护问题和成本的策略用语解决控制维护问题和成本的策略包括有 1 通过生产出尽量可靠的系统来基本消除纠错性维护 2 适应性维护不能完全避免 但可能能够控制 3 使用上述用于纠错性及适应性维护的方法也可以减少完善性维护 还可以通过使用如下方法来减少支援性的维护 最新用户文件联机用户文件适当的用户培训专门的维护人员 影响维护代价因素 技术性因素 非技术性因素 软件对运行环境的依赖性 编程语言 编程风格 文档的质量清晰 正确和完备的文档能降低维护的代价 测试与改错工作 应用领域的复杂性 开发人员的稳定性 软件的生命期 商业操作模式变化对软件的影响 12 1 5 2将维护成本和延误减少到最低限度的措施 1 对于不断变化着的应用问题 要明确区分哪些是预先规定的 哪些是由用户支配的 懂得随着应用的变化 需要完全不同的技术 2 理解数据库技术的重要性 3 理解新的程序语言对维护过程的作用 4 在做出一个系统的计划时 要估计出长期维护的费用 并选择一种能将这一费用降低到最小程度的技术 5 估计出用户在完善性维护方面潜在的作用 6 在最后进行程序设计之前 使用原型建立工具 以确保系统尽可能地适应用户的要求 为使维护工作和费用减到最少的方法更为广泛 这些方法大致可分为七大类型 1 软件选择2 可维护性程序设计3 数据考虑4 系统考虑5 终端用户6 执行维护功能7 总的管理方法 维护策略 为维护工作制订流程 所有维护必须先提交维护申请 维护申请必须规范 软件维护要有计划 在维护过程中需做维护记录 对源程序进行修改 软件配置的修改 12 2软件的可维护性 所谓软件的可维护性是指纠正软件系统出现的错误或缺陷 以及为满足新的要求进行扩充或压缩的容易程度 12 2 1可维护性的度量为度量一个软件系统的可维护性 通常可考虑采用下列3种方法 1 质量检查表 2 质量测试 3 质量标准 12 2 1 1可靠性12 2 1 2可移植性12 2 1 3效率12 2 1 4可适用性12 2 1 5可测试性12 2 1 6可理解性12 2 1 7可修改性 12 2 2提高软件的可维护性 12 2 2 1建立明确的软件质量目标12 2 2 2利用先进的软件技术和工具12 2 2 3建立明确的质量保证工作12 2 2 4选择可维护的程序设计语言12 2 2 5改进程序的文件12 2 2 6历史文件 12 3软件维护的副作用 修改软件是危险的 因为如果在复杂的逻辑过程中进行一个修改 则潜在错误的可能性就将增加 12 3 1修改代码的副作用 下属修改会比其他修改更容易引入错误 删除或修改一个子程序 删除或改变一个语句标号 删除或改变一个标识符 为改进执行性能所作的修改 改变文件的打开或关闭 改变逻辑运算符 把设计的修改翻译成主代码的修改 对边界测试所作的修改 12 3 2修改数据的副作用 修改数据的副作用经常发生在下属一些数据修改中 重新定义局部或全程的常量 重新定义记录或文件的格式 增大或减小一个数组或高阶数据结构的大小 修改全程数据 如FORTRAN的COMMON 重新初始化控制标记或指针 重新排列I O或子程序的自变量 12 3 3文件的副作用 对数据流 软件结构 模块过程或任何其他有关特性进行修改时 必须对支持的技术文件进行更新 否则设计文件不能正确的反映软件的当前状态 甚至可能比完全没有文件情况更糟 因为在以后的维护工作中阅读这些技术文件时 将导致对软件特性不正确的评价 这样就会产生文件的副作用 12 4软件维护工具 软件维护工具可以分成两类 一类是属于维护技术方面的 另一类是属于维护管理方面的 12 4 1维护技术方面的工具按功能水平分 维护技术方面的工具可分为三类 第一 分析现有系统 第二 具有逆向工程功能的工具 第三 具有再建工程功能的工具 12 4 2维护管理方面的工具主要有以下几种 问题报告编辑器维护状态报告编辑器程序改变报告编辑器文件管理工具数据收集和统计工具维护日志 12 5软件维护的管理 软件产品的维护工作不仅是技术性的 它还需要大量的管理工作与之配合 才能保证维护工作的质量 维护工作从理解软件开始 对被维护的软件没有很好的理解 也就谈不到维护 这种理解包括对功能 性能的分析和理解 对原设计的分析和理解 以及对源程序的分析和理解 为确保维护中修改的正确性 消除因修改不当给拥护带来的不良影响 要求对修改工作持谨慎的态度 软件工程的实践表明 维护工作远不如开发工作对软件人员有吸引力 人们常常宁愿参加 开拓性 的开发工作 而不愿做修修补补的维护工作 一 为维护工作制订流程 软件维护活动必须在一定的监控下进行 一旦失控就有可能造成整个软件报废 软件维护的步骤 二 所有维护必须先提交维护申请 维护申请必须规范 提出申请 填写申请报告 用户 系统维护者 报告中写明维护的原因 缓急程度 改正性维护 用户必须完整地说明出现错误的情况 包括输入数据 输出信息 错误清单以及其它相关信息 如果是适应性维护 用户要说明软件要适应的新环境 对于完善性维护 用户必须详细说明需求变化和性能要求 对于新增加的需求 仍然要进行需求分析 设计 编程和测试 相当于一个二次开发的工程 维护机构对申请进行评价 将评价结果填写在申请表的评价结果栏内 或 批准拒绝 远程维护 现场维护 软件 纠错维护适应维护完善维护 硬件 系统设备外部设备 批准拒绝 批准拒绝 软件维护请求报告 案例 三 软件维护要有计划 如果维护申请通过了审批 维护主管要负责制订维护方案和维护计划 维护计划应包括已经确认的问题 维护范围 维护工作安排 维护优先级 预计维护工作量及用户与维护方各自的责任等 四 在维护过程中需做维护记录 维护记录是维护主管用来检查维护计划完成情况 监督维护过程 保障软件质量的基本信息 所有维护人员必须按规定格式和内容填写维护过程和记录 案例文档之十九给出了本书案例的一个软件维护记录 五 对源程序进行修改 在进行软件维护时 必然要对源程序进行修改 对源程序的修改不能无计划地仓促进行 必须要按照一定的步骤进行 分析与理解程序 修改程序 对修改进行验证 六 软件配置的修改 为了保持文档的完整性 可以采用一些CASE工具或联机的文档形式 在采用联机文档时 相同的内容不要在多处复制 应该采用链接引用的方式 避免造成文档不一致 事实上 如果在软件日常的运行和维护过程中生成一些历史文档 会对软件维护非常有利 三种重要历史文档 系统开发日志 错误记载 系统维护日志 七 维护结束后将软件重新交付用户 并对维护的效果及其对系统的影响进行评价 案例维护记录 记录编号 eval wh 012日期 年 月 日 软件维护 最终落实在修改源程序和文档上 为了正确 有效地修改源程序 通常要先分析和理解源程序 然后修改源程序 最后重新检查和验证源程序 一 分析与理解程序 目标 1 理解程序的功能和目标 2 掌握程序的结构信息 将程序分解出程序系统结构 控制结构 数据结构和输入 输出结构等 3 了解数据流信息 清楚所涉及的数据来源为何处 在哪里被使用 4 了解控制流信息 即执行每条路径的结果 5 理解程序的操作要求 阅读程序技巧 1 在阅读源程序之前 首先应该阅读与源程序相关的说明性文档 如 程序功能 数据结构 输入输出格式 文件格式 程序使用说明等 2 在精读源程序之前要泛读源程序 3 画出软件的数据流程图 4 分析程序中涉及的数据库表的结构 数据文件结构 如果能够确定数据结构及数据项的含义就在此写出 5 仔细阅读源程序的每个过程 比较有效的方法是画出每个过程的程序流程图 分析过程中定义的局部数据结构 同时 做一张过程引用全局数据结构表 维护人员可以清晰地了解程序中对全局数据结构的访问情况 二 修改系统 修改系统 做修改计划 分离受影响的模块与数据结构 提供回避措施 修改 是 主要是考虑人员和资源的安排 修改规格的说明信息 维护的资源 维护人员安排 所需提供的条件等 1 在问题的原因还未找到时 先就问题的现象 提供回避的操作方法 如 1 意外停机 系统完全不能工作 2 安装的期限到期 而系统又要求延迟变更 2 了解了问题的原因 可以通过临时修改或改变运行控制以回避在系统运行时产生问题 减少修改时产生副作用 应解决问题 1 修改前做好备份 以便比较 2 正确有效编写代码 尽量保持原风格 简注原因与日期 3 不要共用原已定义临时变量与工作区 4 不轻易删除程序语句 5 边修改边做好记录 有无 有无 程序修改记录模板 三 验证修改 常用的三种验证方法 静态确认 动态确认 维护的评审 检查修改对规格说明的影响 有没有涉及到 是否符合 有无歪曲等 检查修改是否已经修正了软件中的问题 程序代码有无逻辑错误等 修改部分对其他部分是否会有不良影响 文档是否完备并已经更新 所有测试用例是否已经完成并通过 记录软件配 检查 测试修改与未修改部分 最后对整个程序进行测试 可邀请用户参与 三种类型副作用 代码的副作用 数据副作用 文档的副作用 对代码的修改最容易发生副作用 修改会使程序混乱 结构不清晰 可读性变差 而且会产生连锁反应 代码的副作用有时通过回归测试可以发现 一经发现应立即采取补救措施 数据结构是程序的骨架 在维护阶段一旦修改了数据结构 软件设计与数据可能就不再吻合 错误随即出现 容易产生数据副作用的修改包括 局部常量与全局常量的再定义 记录与文件格式的改变 增减数据结构的容积 修改全局数据 重新初始化控制标志与指针 重新排列I O表或子程序的参数表 修改用户数据等 对软件的任何修改都应在相应的技术文档中反映出来 如果设计文档不能与软件当前的状况对应 则会比没有文档更糟 因为用户很多情况下都按照使用说明来使用软件 经验 减少维护防止副作用 使用CMM框架体系的思想来改善软件企业的软件过程管理 在开发与维护过程中尽量采用有效的CASE工具 维护完成以后 一定要进行回归测试 一 面向对象的软件维护 面向对象的软件易于修改 但不易理解 因此维护的难度较大 但对于已理解的程序则修改较结构化程序容易得多 措施 特点 1 研制针对面向对象软件特点的维护工具 帮助人们分析 理解软件 2 软件开发人员在使用面向对象的某些技术 如继承 动态联接等 时要特别小心 3 有关权威机构或软件的开发组织应尽快建立一个控制 规范动态联接和多态性使用的标准 最大限度地减少这方面的任意性 4 开发人员要在文档中作好记录 特别要记录好具有密切关系的类集的活动及测试过程 使文档能尽量全面地反映软件的情况 二 多层结构软件的维护 多层结构的软件大多属于C S结构 比较多的有客户机 服务器的二层结构和客户机 应用服务器 数据库服务器三层结构 这些结构目前是 今后仍然是主要的应用软件结构 对这类软件结构的维护一般是采用客户端和服务器端分开维护的方法 客户机上的软件修改完成后