软件工程课件第八章.ppt

2020 3 25 软件工程概论 第八章软件维护 2020 3 25 软件维护 软件维护是软件生命周期的最后一个阶段 它处于系统投入生产性运行以后的时期中 因此不属于系统开发过程 大型软件的维护成本高达开发成本的四倍左右 目前国外许多软件开发组织把60 以上的人力用于维护已有的软件 而且随着软件数量增多和使用寿命延长 这个百分比还在持续上升 软件工程的主要目的就是要提高软件的可维护性 减少软件维护所需要的工作量 降低软件系统的总成本 2020 3 25 软件维护的定义 软件投入运行后 解决发生的各种故障 增强其功能 使之适应新的环境的活动称为软件维护 2020 3 25 软件维护分类 前一页 1 改正性维护 对运行阶段暴露出来的软件错误进行测试 判断 定位 纠错及验证的过程 2 适应性维护 使软件系统适应不断变化的运行环境而进行修改的过程 3 完善性维护 以满足用户新的要求而对软件进行修改和维护 4 预防性维护 自动修改和扩充已有软件的功能 性能 结构等 以适应将来可能变化的情况 统计表明 完善性维护占全部维护活动的50 66 改正性维护占17 21 适应性维护占18 25 其他维护活动只占4 左右 2020 3 25 软件维护的特点 1 完整的软件配置是进行有效维护的重要保证 若维护的依据只有程序代码 维护活动靠阅读程序代码进行 这是相当困难的 所做改动的后果难以估量 因为没有测试文档 不可能进行回归测试 修改原有错误 可能引出新的错误 有完整的软件配置 维护工作从评价设计文档开始 确定引起错误的原因 估计修改可能带来的影响 并且计划实施途径 有了软件的完整配置 不能保证维护中没有问题 但确实能减少精力的浪费 并能提高维护的总体质量 2020 3 25 软件维护的特点 2 维护代价稳步上升维护已有软件的费用占软件总预算 明显代价 1970年 35 40 1980年 40 60 1990年 70 80 需维护软件增加 软件复杂度增加 维护困难程度增加 无形代价 人力 物力资源用于维护任务 耽误甚至丧失开发新软件的良机 不能及时改正程序错误 从而引起用户不满 2020 3 25 软件维护的特点 前一页 维护工作量 M p k exp c d P 生产性工作量 分析 评价 设计 修改和编码 K 经验系数C 程序复杂性系数 文档少都会引起复杂程度增加 D 维护人员对软件的熟悉程度软件开发途径不对 开发人员不参与维护工作 维护工作量 和费用 将指数地增加 B P lientz曾对美国69个软件开发机构的调查结果表明 69 1 的单位在软件维护方面分配的人力和资源高于新系统的研制 89 9 的单位认为软件维护比新系统的研制更重要 至少同等重要 2020 3 25 软件维护的特点 3 软件维护中的一些典型问题 理解别人编的程序非常困难 缺少文档就更困难 需要维护的软件往往没有合适的文档 或文档资料显著不足 容易理解的 并且与程序代码完全一致的文档才有意义 软件开发者常常不参与维护 设计时 不强调模块化和模块独立性 任何一个小小的改动都可能孕育着很大的危险 不重视维护 在软件项目规划中 软件维护没有提到重要位置 软件维护不会产生新的成果 因而不吸引人 2020 3 25 维护过程 维护过程本质上是修改和压缩了的软件定义和开发过程 必须有组织 有步骤地进行 首先必须建立一个维护组织 随后必须确定报告和评价的过程 而且必须为每个维护要求规定一个标准化的事件序列 此外 还应该建立一个适用于维护活动的记录保管过程 并且规定复审标准 2020 3 25 维护过程 主要内容 维护组织维护报告维护的事件流保存维护记录评价维护活动 2020 3 25 维护过程 维护组织 软件维护必须要有专门的机构或被授权的管理人员来组织维护活动 其职能是 授权用户维护请求 组织维护实施 并对维护进行评价 一般过程是 用户将维护请求提交给维护管理员 维护管理员将维护请求转交给系统管理员 系统管理员对维护任务进行评价后 由变化授权人决定应该进行的活动 2020 3 25 维护过程 维护组织 2020 3 25 维护过程 维护报告 应该用标准化的格式表达所有软件维护要求 这个表格由要求维护活动的用户填写 如果遇到了一个错误 那么必须完整描述导致出现错误的环境 包括输入数据 全部输出数据 以及其他有关信息 对于适应性或完善性的维护要求 应该提出一个简短的要求说明书 由维护管理员评价用户提交的维护要求表 2020 3 25 维护过程 维护报告 维护要求表是一个外部产生的文件 是计划维护活动的基础 软件组织内部应该制定出一个软件修改报告 它给出下述信息 1 满足维护要求表中提出的要求所需要的工作量 2 维护要求的性质 3 这项要求的优先次序 4 与修改有关的事后数据 维护修改报告应提交给变化授权人审核批准 2020 3 25 维护事件流图 2020 3 25 维护过程 维护事件流 校正性维护 首先评价错误的严重程度 根据错误的严重性 进行不同的组织 适应性和完善性维护 必须先确定每个维护要求的优先次序 若某个维护要求的优先级非常高 应立即开始维护工作 否则排队等待 无论哪一种维护 都首先要进行同样的技术工作 这些工作包括 软件设计的修改 复查 必要的代码修改 单元测试 集成测试 验收测试 以及最后的复审 2020 3 25 前一页 维护过程 保存维护记录 为了确定软件维护的有效程度 确定软件产品的质量 同时确定维护活动的开销 详细记录维护中进行的工作及工作量 主要内容包括 18项 程序标识源程序语句数机器指令条数使用的程序设计语言程序安装的日期安装以来运行的次数安装以来的失效次数程序变动的层次和标识每个改动耗费的人时数程序改动的日期程序变动增加的源语句数维护人员名字程序变动而删除的源语句数维护要求表的标识维护类型维护开始时间和完成时间累计用于维护的人时数与完成的维护相联系的纯效益 2020 3 25 维护过程 评价维护活动 对维护活动进行度量 内容包括 1 每次程序运行平均失效次数 2 用于每一类维护活动的总人时数 3 平均每个程序 每种语言 每种维护类型所作的程序变动次数 4 维护过程中增加或删除一个源语句平均花费的人时数 5 维护每种语言花费的人时数 6 一张维护要求表的平均周转时间 7 不同维护类型所占的百分比维护记录和维护评价数据是一个软件开发组织应该收集的软件过程数据 它对于改进软件组织的工作 提高软件过程能力有重要意义 2020 3 25 可维护性 前一页 软件可维护性可以定性地定义为 维护人员理解 改正 改动和改进这个软件的难易程度 即衡量维护容易程度的一种软件属性 2020 3 25 软件可维护性 主要内容 决定软件可维护性的因素文档可维护性复审 2020 3 25 决定软件可维护性的因素 1 可理解性 软件可理解性表现为外来读者理解软件的结构 接口 功能和内部过程的难易程度 2 可测试性 诊断和测试的难易程度主要取决于软件容易理解的程度 良好的文档对诊断和测试是至关重要的 可用的测试工具和调试工具 以及以前设计的测试过程也都是非常重要的 3 可修改性 软件容易修改的程度设计原理和规则直接有关 耦合 内聚 局部化 控制域与作用域的关系等等 都影响软件的可修改性 2020 3 25 决定软件可维护性的因素 4 可移植性 一个程序被移植到一个新的计算环境的可能性的大小 或表明程序可以容易地 有效地在各种各样的计算环境中运行的程度 可以把因环境变化而必须修改的程序局限在很少的模块中 从而降低修改的难度 5 可重用性 重用指同一事物不作修改或稍加改动就在不同环境中多次重复使用 大量使用可重用的软件构件来开发软件 可以明显提高软件可维护性 1 可重用的软件构件经过严格的测试 可靠性比较高 软件中使用的可重用构件越多 软件的可靠性越高 改正性维护需求越少 2 很容易修改可重用的软件构件使之再次应用到新的环境中 软件中使用的可重用构件越多 适应性和完善性维护也越容易 2020 3 25 可维护性 文档 文档是影响软件可维护性的决定因素 其作用是 1 帮助维护人员读懂程序 2 方便被维护软件的测试 由于长期使用的大型软件系统在使用过程中必然会经受多次修改 所以文档比程序代码更重要 软件系统的文档可以分为用户文档和系统文档两类 用户文档主要描述系统功能和使用方法 系统文档描述系统设计 实现和测试等各方面的内容 2020 3 25 可维护性 文档 软件文档应该满足下述要求 1 必须描述如何使用这个系统 没有这种描述即使是最简单的系统也无法使用 2 必须描述怎样安装和管理这个系统 3 必须描述系统需求和设计 4 必须描述系统的实现和测试 以便使系统成为可维护的 2020 3 25 文档 用户文档 用户文档是用户了解系统的第一步 它应该能使用户获得对系统的准确的初步印象 用户文档包括 1 功能描述 说明系统能做什么 2 安装文档 说明怎样安装这个系统以及怎样使系统适应特定的硬件配置 3 使用手册 简要说明如何着手使用这个系统 应该通过丰富例子说明怎样使用常用的系统功能 还应该说明用户操作错误时怎样恢复和重新启动等 4 参考手册 详尽描述用户可以使用的所有系统设施以及它们的使用方法 5 操作员指南 说明操作员应该如何处理使用中出现的各种情况 2020 3 25 文档 系统文档 前一页 系统文档指从问题定义 需求说明到验收测试计划这样一系列和系统实现有关的文档 描述系统设计 实现和测试的文档对于理解程序和维护程序来说是非常重要的 2020 3 25 前一页 可维护性复审 可维护性是所有软件应该具备的基本特点 提高软件的可维护性是软件工程过程的每一阶段都应考虑并为之奋斗的目标 在每一阶段结束时的技术审查和管理复审中 应着重对软件可维护性进行复审 2020 3 25 可维护性复审 需求分析阶段 应对将来要改进或修改的部分加以注意并指明 要考虑可能影响软件维护的系统界面 增加功能后操作可能发生的变化 设计阶段 应从容易修改 模块化和功能独立的目标出发 评价软件的结构和过程 代码复审 应强调编码风格和内部文档 测试复审 配置复审 其目的是保证软件配置的所有成分是完整的 一致的 可理解的 在测试结束后 进行最正式的可维护性复审 配置复审 维护应针对软件配置 不应该只修改源程序代码 代码修改而文档不修改 将会产生严重后果 每当对数据 软件结构 模块过程或其它任何软件特点作了改动时 必须立即修改相应的文档 2020 3 25 软件位置管理 SCM 软件开发过程中 变化是不可避免的 变化往往会加深软件开发人员之间的不理解程度 从而造成开发工作的混乱 协调软件开发以使不理解性达到最小程度的技术称为配置管理 配置管理是一种标识