维护评价度量值.ppt

第八章 软件维护 内容 软件维护的类型和策略 软件维护的过程与管理方法 软件可维护性的概念 提高可维护性的方法 软件逆向工程与再工程的概念 软件维护知识域主题的本体结构 软件维护的十大基本原则 背景原则 过程原则 文档原则 信息原则 谨慎原则 确认原则 冲突原则 记录原则 重编原则 检验原则 软件开发要考虑到维护问题 需求分析阶段：明确维护范围及责任；审查系统要求；研究运行/维护的支持；明确性能要求及变更；明确扩充或收缩；检验关键资源的可扩充性。 设计阶段：考虑系统的扩展、压缩和变更及设计通用性等。 编程阶段：查找源程序错误，度量源程序可理解性等。 测试阶段：维护人员参与集成测试，统计分析错误等。 影响维护工作量的因素 系统大小 程序设计语言 系统年龄 数据库技术应用 先进的软件开发技术 其它 维护工作量模型 M=p+kec-d M：维护中消耗的总工作量；p：上面描述的生产性工作量；k：经验常数；c：复杂性的度量；d：对软件熟悉程度的度量。 模型表明，如果使用了不好的软件开发方法（未按软件工程要求做），原来参加开发的人员或小组不能参加维护，则工作量（及成本）将按指数增加。 软件维护的原因 改正在特定的使用条件下暴露出的一些潜在程序错误或设计缺陷。 因为在软件使用过程中数据环境发生变化（例如一个事务处理代码发生改变）或处理环境发生变化（例如安装了新的硬件或操作系统），需要修改软件以适应这种变化。 用户和数据处理人员在使用时常提出改进现有功能，增加新的功能，以及改善总体性能要求，就需要修改软件把这些要求归纳到软件中。 软件维护机构 软件修改报告 所需修改变动的性质 申请修改的优先级 为满足某个维护申请报告，所需的工作量 预计修改后的状况 软件维护工作过程 软件维护总结 在目前情况下，设计、编码、测试中的哪一方面可以改进？ 哪些维护资源应该有但没有？ 工作中主要的或次要的障碍是什么？ 从维护申请的类型来看是否应当有预防性的措施？ 分析和理解程序 理解程序的功能和目标 掌握程序的结构信息，即从程序中细分出若干结构成分。如程序系统结构图、控制结构、数据结构和输入输出结构等 了解数据流信息，即所涉及到数据来源何处，在哪里被使用 了解控制流信息，即执行每条路径的结果 理解程序的操作（使用）要求 维护后的验收 全部文档是否完备，并已更新 所有测试用例和测试结果已经正确记载 记录软件配置所有副本的工作已经完成 维护工序和责任已经确定 维护所需测试种类 对修改事务的测试 对修改程序的测试 操作过程的测试 应用系统运用过程的测试 使用过程的测试 系统各部分之间接口的测试 作业控制语言的测试 与系统软件接口的测试 软件系统之间的接口测试 安全性测试 后备/恢复过程的测试 系统变更验收标准度量表 维护评价度量值 每次程序运行的平均出错次数 花费在每类维护上的总“人时”数 每个程序、每种语言、每种维护类型的程序平均修改次数 因为维护，增加或删除每个源程序语句所花费的平均“人时”数 用于每种语言的平均“人时”数 维护申请报告的平均处理时间 各类维护申请的百分比 各类维护中的侧重点 其它间接定量度量（Gilb） 问题识别的时间 因管理活动拖延的时间 收集维护工具的时间 分析、诊断问题的时间 修改规格说明的时间 具体的改错或修改的时间 局部测试的时间 集成或回归测试的时间 维护的评审时间 恢复时间 使用提高软件质量的技术和工具 模块化 结构程序设计 使用结构程序设计技术，提高现有系统的可维护性 软件开发期间各个检查点的检查重点 软件开发过程的质量保证与审查 语言与维护性 好的文档是可维护性的基本条件 文档好的程序比没有文档的程序容易操作 好的文档意味着简洁、风格一致、且易于更新 程序应当成为其自身的文档 历史文档 系统开发日志 错误记载 系统维护日志 结构化翻新 维持一行源代码的代价可能是14～50倍于初始开发该行源代码的代价 软件体系结构（程序及数据结构）的重新设计使用了现代设计概念，它对将来的维护可能有很大的帮助 由于软件的原型已经存在，开发生产率应当大大高于平均水平 现行用户具有较多有关该软件的经验，因此，新的变更需求和变更的范围能够很容易地搞清楚 逆向工程和再工程工具可以在完成预防性维护的基础上建立起来 软件配置将可以在完成预防性维护的基础上建立起来 软件再工程 实施软件再工程的原因 再工程可帮助软件机构降低软件演化的风险 再工程可帮助机构补偿软件投资 再工程可使得软件易于进一步变革 软件再工程有着广阔的市场 再工程能力扩大CASE工具集 再工程是推动自动软件维护发展的动力 软件再工程技术 软件再工程的风险 过程风险 人员风险 应用问题风险 技术风险 工具风险 策略风险 要点 在SWEBOK