北京理工大学软件工程实践..pptVIP

北京理工大学软件工程实践 汤铭端 中国航天科工集团公司204所 第九讲 软件维护和软件重用 内容和目的 了解软件维护的概念 掌握软件维护的种类 了解再工程的概念 了解逆向工程的概念 了解软件重用的内容和方法 维护的必要性 改正在运行中新发现的错误和缺陷 改进设计，以增强功能，提高性能 要求已运行的软件适应特定的工作环境，或已变动的数据和文件 使投入运行的软件与其它相关系统有良好的接口 使运行的软件的应用范围得到必要的补充 维护的起因 故障——改正错误 新要求——增加功能和优化 环境变化——迁移 软件维护 软件维护是在软件产品交付之后，为纠正故障，改进性能和其它属性，或使产品适应改变了的环境所进行的修改活动。 软件的维护不完全同于硬件的维护。对软件的维护就意味着修改，它不存在如硬件那样更换备件的维护工作。 软件维护一般分为完善性维护、适应性维护和改正性维护三种类型。 四类维护 完善性维护是为扩充功能和改善性能而进行修改和扩充，以满足用户变化了的需求。 适应性维护是为适应软件运行环境的变化而作的修改。例如因为硬件配置、系统软件的变化而要求进行的修改。 改正性维护是为了维持系统操作运行，针对在开发过程产生但在测试和验收时没有发现的错误而进行的改正。 第四种维护预防性维护，是为了进一步改进软件的维护性和可靠性，或者为进一步的提高提供一种更好的基础，而对软件进行的更改。 维护面临的问题 技术人员重开发、轻维护 维护缺乏创造自由 维护是“无期”的 用户对维护了解不多，问题被搁置 将维护和开发混为一谈 如何维持旺盛士气，改善支援环境 影响维护各种的因素 系统大小 系统年龄 输入/输出数据项个数 应用类型 程序设计语言 结构化程度 维护任务 建立维护机构 提出维护申请报告 进行维护 记录和保持维护信息 维护评价 维护机构 正式和非正式的维护机构 维护管理员：管理维护工作 修改负责人：评价维护申请 系统监督员：决定如何进行修改 维护报告 外部：维护申请表（软件问题报告），由申请维护的用户填写，说明错误情况或新需求规格说明 内部：软件修改报告，指出 为满足某个维护申请表所需的工作量 所需修改变动的性质 申请的优先级 预计修改后的状态 维护工作流程 维护记录保持 程序名称 源程序的数目 机器代码指令的数目 使用的编程语言 程序投入使用的日期 从投入使用以来，程序运行过的数目 与上有关的故障处理次数 程序改变的级别及名称 修改程序所增加的源语句数 修改程序所减少的源语句数 每次修改所付出的人时数 修改程序的日期 软件工程师的姓名 维护申请表名称 维护类型 维护开始和结束的日期 累计花费在维护上人时数 维护工作的净收益 维护评价 根据以下度量对维护进行评价： 每次程序运行的平均出错次数 花费在每类维护上的总人时数 每个程序、每个语言、每种维护类型的平均修改次数 花费在由于维护所增加或删除的每条源语句上的平均人时数 用于每个语言的平均人时数 一个维护申请表的平均处理时间 各类维护申请的百分比 结构性维护 维护策略 减少改正性维护工作量的策略 减少适应性维护工作量的策略 减少完善性维护工作量的策略 将维护成本和延误减少到最低限度的措施 改正性维护策略 通过采用新技术，可大大提高软件的可靠性，减少进行改正性维护的需要 可在开发时考虑如下的方法： 利用应用软件包，所开发出的程序比用户完全自己开发的系统可靠性更高 使用结构化技术所开发的软件系统易于理解和测试 假如防错性程序设计 适应性维护策略 在进行配置管理时，把硬件、操作系统及其相关环境因素的可能变化考虑在内，可以减少某些适应性维护工作量 如果把硬件、操作系统、各种外围设备的相关程序都归到特定的程序模块中，则可将因环境变化而需要修改的程序局限于一些特定模块，减少适应性维护工作量 使用内部程序列表、外部文件等，可为维护提供方便 完善性维护策略 使用数据库管理系统、程序生成系统、应用软件包等，可以减少维护工作量 开发时使用原型，让用户先期对系统进行评价，可以减少完善性维护的需求 将维护成本和延误减少到最低限度的措施 对于不断变化着的应用问题，要明确区分哪些是预先规定的，哪些是由用户支配的，懂得随着应用的变化，需要完全不同的技术 理解数据库技术的重要性 理解第四带语言对维护过程的作用 在作出一个系统的计划时，要估计长期维护的费用，并选择一种能将这一费用降低到最小程度的技术 估计出用户在完善性维护方面潜在的作用 在最后进行程序设计之前，使用原型技术，以确保系统尽可能地适应用户的要求 维护的成本 软件维护的费用不断增加 典型的占结构的40%-60% 不及时合理的修改降低用户满意度 引发新问题降低重量 占用资源影响开发 维护的生产性活动 维护的“兜圈子”活动 M=p+K×ec-d M=用于维护的总工作量 p=生产性工作