第9章软件维护(免费阅读).pptVIP

软 件 维 护 学习内容 软件维护的定义 软件维护的特点 软件维护过程 软件可维护性 软件的逆向工程与再工程 一 软件维护的定义 Q：什么是维护？ A：在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。 Q：维护做什么？ A: ① 诊断和改正错误 —— 改正性维护，约占全部维护活动的 17~20%； ② 为了和变化了的环境（如软\硬件升级、新数据库等）适当地配合而修改软件 —— 适应性维护，约占全部维护活动的18~25%； 软件维护的定义 ③为了增加新功能，修改已有功能，改造界面，增加HELP等，而修改软件 —— 完善性维护，约占全部维护活动的50~66% ； ④为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件 —— 预防性维护，约占总维护的4%左右。 三类维护占 维护在软件生存期 总维护比例 所占比例 软件维护的特点 ? 有形代价： ? 无形代价： ? 占用资源以致延误开发； ? 修改不及时引起用户不满； ? 维护引入新错误，降低了软件质量；等等。 ? 维护工作量的经验模型： 软件维护的特点 三 维护过程 建立维护组织 维护报告 维护实施 保存维护记录 评价维护活动 软件可维护性 可维护性的度量 用于衡量可维护性的软件特性 提高可维护性的方法 文档 软件的逆向工程与再工程 案例分析 版本实际上是一个动态概念 ，要有版本的演变图和每个版本的详细信息（包括源代码、对应的文档及数据）。版本演变图对于了解版本的形成过程和变种过程非常有帮助。 总结 * * 注：① 一般维护的工作量占生存周期70%以上，维护成本约为开发成本的4倍； ② 文档维护与代码维护同样重要。 二 软件维护的特点 结构化维护与 非结构化维护的对比 软件结构、系统接口、 约束条件……？？？ 不知道！ 维护要求 软件配置 只有代码 评价代码 重编程序 复 查 完整配置 评价设计文档 估计改动影响，计划实施途径 修改设计 重编程序 复 查 交付使用 维护的代价 M = P + K ec-d 其中：M = 维护用的总工作量； P = 生产性活动 (如. 分析,评价，修改设计, 编码, 测试等); K = 经验系数 ; c = 复杂度 ( 非结构化设计和缺少文档会增加复杂度) d = 维护人员对软件的熟悉程度. 理解别人的程序非常困难。 维护的困难性 人员流动性大！ 软件工程的思想至少部分地解决了与维护有关的每一个问题。 工资不一样嘛！ 文档不合格：文档间不一致；文档必须可理解，且与源代码相一致。 软件开发和软件维护在人员与时间上的差异。 大多数软件在设计时没有考虑将来的修改。 维护不是一项吸引人的工作。 —— 本质上是修改和压缩了的软件定义和开发过程 首先建立维护的机构 申明提出维护申请报告的过程及评价的过程 为每一个维护申请规定标准的处理步骤 建立维护活动的登记制度以及规定评价和评审的标准。 虽然不要求建立一个正式的维护机构，但是在开发部门确立一个非正式的维护机构则是非常必要的。 尽管没有专门机构也要明确职责 避免混乱――随意修改 改善流程――减少抵触情绪 要求维护 维护管理员 系统管理员 客户要求 任务评价 任务评价 变化授权人 钱太少 不干！ 变化授权人 系统管理员 ⑴ 维护申请报告 由用户填写的外部文件，提供错误情况说明（输入数据，错误清单等），或修改说明书等。 ⑵ 维护评价报告 与维护申请报告相应的内部文件，要求说明： ①所需修改变动的性质； ②申请修改的优先级； ③为满足某个维护申请报告，所需的工作量； ④预计修改后的状况。 软件维护工作流程 尽管维护申请的类型不同，但都要进行同样的技术工作。 修改软件需求说明 修改软件设计 设计评审 对源程序做必要的修改 单元测试 集成测试( 回归测试) 确认测试 软件配置评审等。 程序名称 程序安装的日期 程序改变的层次 修改程序的日期 软件维护人员的姓名 维护申请报告的名称 维护类型 维护开始时间和维护结束时间 如果维护的档案记录做得比较好，可以得出一些维护“性能”方面的度量值。根据度量结果，对开发技术、语言选