软件工程 第8章：维护.ppt

* 特定条件下会暴露出缺陷； 环境变化的适应性修改（数据环境、使用环境和处理环境） 新需求的出现（功能改进和增加、性能要求） 二、软件维护 1.软件维护的原因 （1）改正性维护 在用户使用过程中诊断、发现和改正错误的过程称为改正性维护。 2.软件维护的类型 （2）适应性维护 硬件系统和外设需要时常更新和升级，造成数据库环境、数据输入/输出方式、数据存储介质等发生变换。为了使软件适应这些环境变化而修改软件的过程叫做适应性维护。 （3）完善性维护 用户在使用过程中提出新的功能和性能要求，造成功能增加和修改称为完善性维护。 （4）预防性维护 为了改进软件未来的可维护性或可靠性，或者为未来维护方便而进行的修改，称为预防性维护。在实践中比较少见。 在各类维护中，完善性维护占软件维护工作的大部分。 根据国外的数据统计表明，完善性维护占全部维护活动的50%～66%，改正性维护占17%～21%，适应性维护占18%～25%，其它维护活动占4%左右。 非结构化维护：经常产生误解，不能回归测试，维护代价大。3.结构化维护 评价代码 评价软件结构 评价数据结构 评价系统接口 评价设计约束 结构化维护 评价设计文档 确定软件结构 评价性能特点 评价接口特点 修改设计 修改代码 回归测试 有形代价：维护的费用开支70年代，软件维护费用占总预算的30%～40%，80年代上升到60%左右，90年代达到了80%。 4.软件维护的代价 无形代价：潜在的影响 当看起来合理的要求不能及时满足时，会引起用户的不满； 修改可能会引入新的错误，使软件质量下降； 大量工程师从事维护工作，会影响开发工作。 Belady和Lehman的维护工作量模型M=P+Ke(c-d) 其中：M：用于维护工作的总工作量P：生产性工作量K：经验常数c：因缺乏好的设计和文档而导致软件复杂性的度量d：维护人员对软件熟悉程度的度量复杂度-熟悉度 5. 软件维护工作量模型 6.软件维护的典型问题 只有代码而没有注释，维护就相当困难； 维护人员经常变化与流动，维护工作量增加； 没有足够的文档资料，或者资料不一致； 软件在设计时没有考虑将来的修改（模块化设计原则）； 维护常常受挫，吃力不讨好，没有挑战，很多人不愿意从事这样的工作。 三、软件维护过程 1. 维护组织 … 维护要求 （软件问题报告） 维护管理员 系统管理员 软件系统 变化授权人 包含信息： 维护的工作量 维护的性质 优先级 有关的事后数据（如测试数据等） 2. 维护报告 3. 维护的事件流 分析问题 开始分析 计划改正进度 错误改正目录 开发目录 分配的人员 维护任务 分配的人员 复审 修改后的软件配置 复审后新的的软件配置 类型 维护要求 错误 适应 完善 ⊕ ⊕ 估量错误严重程度 严重 不严重 ⊕ 评价优先度 高 低 ⊕ 4. 保存维护记录 1）程序标识；2）源语句数； 3）机器指令数；4）使用的程序设计语言； 5）安装的日期；6）自安装以来程序运行次数； 7）自安装以来程序失效次数 8）程序变动的层次和标识； 9）因程序变动而增加的源语句数；10）因程序变动而删除的源语句数； 11）每个改动耗费的人时数； 12）程序改动的日期； 13）软件工程师的名字；14）维护要求表的标识； 15）维护类型；16）维护开始和完成的日期； 17）累计用于维护的人时数； 18）与完成的维护相联系的纯效益。 5. 评价维护活动 可以从以下方面度量维护工作： 1）每次程序运行平均失效的次数； 2）用于每一类维护活动的总人时数； 3）平均每个程序、每种维护类型所做的程序变动数； 4）维护过程中增加或删除一个源语句平均花费的人时数； 5）维护每种语言平均花费的人时数； 6）一张维护要求表的平均周转时间； 7）不同维护类型所占的百分比。 四、软件的可维护性 可理解性 可测试性 可修改性 可移植性 可重用性 1. 决定因素 软件可维护性是维护人员理解、改正和改进软件的难易程度。 （2）可测试性 设计成易测试、易诊断，能用测试工具和调试工具进行测试和诊断的软件。 （1）可理解性：软件结构、接口、功能和内部过程的理解的难易程度。 影响因素：模块化、结构化设计、详细的设计文档资料、源代码内部文档、良好的程序设计语言等。 （3）可修改性 与设计时采用的原则和策略相关。（耦合、内聚、控制域和作用域、局部化程度） （4）可移植性 （5）可重用性 决定软件可维护性的最终因素是软件设计阶段所采用的方法，以及软件文档资料的质量。提高软件的可维护性是软件工程的一个重要目标。 2.文档 用户文档 系统文档 功能描述 安装文档 使用手册 参考手册 操作员指南 3. 可维护性复审 测试结束时进行正式的可维护性复审，也称配置复审