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

“在交付使用后，为改正错误或满足新需要而修改软件的过程！” 分类 改正性维护 适应性维护 完善性维护 预防性维护 8.2.1 软件维护的分类 （1）非结构化维护 前提：仅有程序代码 过程：艰难评价程序代码;对软件结构、数据结构、接口和性能设计约束的误解;无法进行回归测试；高昂代价 结论：没有使用良好定义的方法学开发软件的必然结果。 8.2.1 软件维护的分类 （2）结构化维护 前提：完整的软件配置 过程：评价设计文档（确定重要的结构/功能/性能特点+估量影响+计划实施途径）+修改设计并复查+编写代码+回归测试 结论：软件开发早期使用软件工程法法学很重要。 8.2.1 软件维护代价 ? 明显代价：高昂的维护费用，80%左右； ? 无形代价： 用户的不满； 软件质量降低； 人员调动引起的混乱。 ? 生产率的大幅下降； ? 维护工作量：生产性劳动+非生产性劳动。 软件维护工作量 M=P+k×ec-d 其中，M 是维护用的总工作量，P 是生产性工作量，k 是经验常数，c 是复杂程度，d 是维护人员对软件的熟悉程度。 软件维护的问题 ? 文档的需要：理解别人的程序 ? 文档与程序的一致性 ? 等待开发人员的说明 ? 设计时未考虑维护工作 ? 维护经常受挫 1. 维护组织——明确维护责任 维护机构成员一般包括：配置管理员，维护管理员，系统管理员，一般维护工作人员。 2. 维护报告 ? 维护要求表（用户填写） 必须完整地说明产生错误的情况，包括输入数据、错误清单以及其它有关材料。如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。 申请报告将由维护管理员和系统管理员来研究处理。 ? 软件修改报告（开发者填写） 指明： 所需修改变动的性质； 申请修改的优先级； 为满足某个维护申请报告，所需的工作量； 预计修改后的状况。 修改报告提交变化授权人批准后才能开始进一步安排维护工作。 3. 维护事件流 在每次软件维护任务完成后进行处境复查，对以下问题做一总结：(1) 在目前情况下，设计、编码、测试中的哪一方面可以改进?(2) 哪些维护资源应该有但没有?(3) 工作中主要的或次要的障碍是什么?(4) 从维护申请的类型来看是否应当有预防性维护?处境复查对将来的维护工作如何进行会产生重要的影响。 4. 保存维护记录 ? 软件问题报告 ? 软件变动报告 ? 软件维护记录(Swanson项目表) 5. 评价维护活动 ? 程序运行的平均失效次数 ? 每一个维护活动的总人时数 ? 平均每个程序/语言/维护类型中的程序变动数 ? 每增加/删除一个源语句花费的人时数 ? 维护每种语言平均花费的人时数 ? 维护要求表的平均周转时间 ? 不同维护类型所占的比例 定义： 维护人员理解、改正、改动或改进这个软件的难易程度 8.4.1决定可维护性的因素 维护就是在软件交付使用后进行的修改，修改之前必须理解待修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。如果是改正性维护，还必须预先进行调试以确定错误的具体位置。因此，决定软件可维护性的因素主要有下述5个： 可理解性 可测试性 可修改性 可移植性 可重用性 8.4.1决定可维护性的因素 (1) 可理解性：表现为外来读者理解软件结构、功能、接口和内部处理过程的难易程度。 提高可理解性：模块化、详细的设计文档、结构化设计、程序内部文档、良好的高级程序设计语言。 8.4.1决定可维护性的因素 (1) 可理解性：表现为外来读者理解软件结构、功能、接口和内部处理过程的难易程度。 提高可理解性：模块化、详细的设计文档、结构化设计、程序内部文档、良好的高级程序设计语言。 8.4.1 可维护性决定因素 (2) 可测试性：诊断和测试的难易程度，其取决于软件容易理解的程度。 提高可测试性：良好的文档、软件结构、可用的测试工具和调试工具、设计的测试过程。 8.4.1 可维护性决定因素 (3) 可修改性：软件修改的难易程度。 提高可修改性：耦合、内聚、信息隐藏、局部化、控制域与作用域的关系。 8.4.1 可维护性决定因素 (4) 可移植性：把程序从一种计算环境转移到另一种计算环境的难易程度。 它表明程序可以容易地、有效地在各种各样的计算环境中运行的容易程度。 一个可移植的程序应具有结构良好、灵活、不依赖于某一具体计算机或操作系统的性能。 (5) 可重用性：同一事物不做修改或稍加改动就在不同环境中多次重复使用。