1、1第八章 系统的维护2概况1您的内容打在这里，或者通过复制您的文本后。概况2您的内容打在这里，或者通过复制您的文本后。概况3您的内容打在这里，或者通过复制您的文本后。+整体概况3 什么是维护 所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需求而修改软件的过程。维护的目的 保证软件系统能持续的与用户环境、数据处理操作、政府或其他有关部门的请求取得协调。48.1 软件维护的类型软件维护是指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程。按照不同的维护目的，维护工作可分成4 4类。完善性维护（Perfective MaintenancePerfective Main
2、tenance）扩充原有系统的功能，提高原有系统的性能，满足用户的实际需要。纠错性维护（Corrective MaintenanceCorrective Maintenance）对在测试阶段未能发现的，在软件投入使用后才逐渐暴露出来的错误的测试、诊断、定位、纠错以及验证、修改的回归测试过程。5软件维护的类型适应性维护（Adaptive MaintenanceAdaptive Maintenance）要使运行的软件能适应运行环境的变动而修改软件的过程。预防性维护（Preventive MaintenancePreventive Maintenance）为了进一步改善软件的可靠性和易维护性，或者为
3、将来的维护奠定更好的基础而对软件进行修改。6各种维护所占比例:其它维护 5%5%适应性维 护 25%25%改正性维 护 20%20%扩充与完善性维护 50%50%改正性维护占全部维护量的比率已从8080年代初的20%20%大幅度下降,90,90年代初一些公司的产品差错率已接近于零7二、维护的步骤用户维护人员安排改正性维护确认维护类型维护实施评价优先级进行问题分析复审评价错误严重程度进行问题分析确定更改要求维护要求完 美 性 适 应 性将安排好的工作量列入计划低高纠错性严重不严重将改正错误列入计划 人 员 安排人 员 安 排交付使用的软件理解分析程序安排计划修改程序测试程序或或或或软件维护的工作
4、流程图修改过的软件8三、维护工作的组织管理软件维护工作不仅是技术性的，它还需要大量的管理工作与之相配合，才能保证维护工作的质量。管理部门应对提交的修改方案进行分析和审查，并对修改带来的影响作充分的估计，对于不妥的修改予以撤销。需修改主文档时，管理部门更应仔细审查。软件维护的管理流程如图所示：9 维护修改建议 分析修改建议是否合理提交管理部门审查是否同意修改撤销NYNY进行测试 提交管理部门审批是否批准更新主文档Y 更新其他文档 提交使用修改N108.2 8.2 软件维护的特性一、结构化维护与非结构化维护结构化维护 指软件开发过程是按照软件工程方法，软件的维护过程，有一整套完整的方案、技术、审定
5、过程。非结构化维护 缺乏必要的文档说明，难于确定数据结构、系统接口等特性。维护工作令人生畏，事倍功半。11二、软件维护的代价维护费用高达开发费用的55%70%，而且逐年上涨。维护中还可能引入新的潜在错误。Belady 和 Lehman 提出软件维护工作模型：M=P+K*EXP（C-D）其中：M维护总工作量P生产性活动K经验常数C程序复杂度（由非结构化维护引起的）D对维护软件熟悉程度的度量。128.3 8.3 软件维护的内容根据使用的要求，对程序进行全面或部分修改；修改以后，必须书写修改报告数据维护指对数据有较大的变动。如：安装与转换新的数据库；或者某些数据文件或数据库出现异常时的维护工作，如文
6、件容量太大而出现数据溢出等。硬件人员应加强设备的保养以及定期检修，并做好检验记录和故障登记工作。13维护中的典型问题 与软件维护有关的绝大多数问题的根源在于计划阶段和开发阶段的工作有缺点。(1)(1)难以跟踪软件版本的进化过程,软件的变化未在文档中反映出来.(2)(2)难以跟踪软件的创建过程.(3)(3)难以读懂他人程序.(4)(4)无文档或不全.(5)(5)软件人员流动性大.(6)(6)设计时未考虑修改需要,修改困难.(7)(7)维护工作无吸引力,缺乏成就感.14维护过程中作应记录的数据程序标识源程序语句数目机器代码指令条数.以收集的数据为基础构造维护数据库,供维护评价使用.15 8.2.3
7、 8.2.3 软件维护的实施修改源程序的三个步骤分析和理解程序修改程序重新验证程序16软件维护的副作用 由于软件被修改而导致的错误或其它多于动作的发生，称为是软件维护的副作用。软件副作用的类型：修改代码的副作用修改数据的副作用修改文档的副作用17o 为确保编码修改没有引入新的错误，应进行严格的回归测试。一般情况下，通过回归测试，可以发现并纠正修改编码所带来的副作用。o 修改数据的副作用可以通过完善的设计文档来加以限制。这种文档描述了数据结构，并且提供了一种把数据元素、记录、文件及其它结构与软件模块联系起来的交叉对照功能。18o维护应该着眼于整个软件配置，而不只是源程序代码的修改。如果源代码的修
8、改没有反映在设计文档或用户文档中时，就会发生修改文档的副作用。每当对数据流程图、软件结构、模块算法过程和其他有关的特征进行修改时，必须同时对相应的文档资料进行更新。在软件再次交付使用之前，对整个软件配置进行评审将大大减少修改文档的副作用。实际上某些维护申请的提出只是由于用户文档不够清楚。这时只需对文档进行维护即可，并不需要修改软件设计或源程序。19重新验证程序o静态确认o计算机确认o维护后的验收20 从维护角度所需的测试种类：(1)(1)对修改事务的测试(2)(2)对修改程序的测试(3)(3)操作过程的测试(4)(4)应用系统运行过程的测试(5)(5)使用过程的测试(6)(6)系统各部分间接口
9、的测试(7)(7)与系统软件接口的测试(8)(8)安全性测试(9)(9)后备/恢复过程测试 218.3软件可维护性 软件可维护性的定义：软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。可维护性的控制因素u 与开发方法有关的因素，如采用什么方法u 与开发环境有关的因素 22 与开发环境有关的因素 1.1.合格的软件开发人员 2.2.可理解的系统结构 3.3.系统处理容易 4.4.使用标准的编程语言 5.5.使用标准的操作系统 6.6.标准化的文档结构 7.7.测试用例的有效性 8.8.系统自身拥有的纠错工具 9.9.易于维护的计算机 10.10.开
10、发该软件的个人或组织23衡量软件可维护性的几个度量特性：可理解性 可测试性 可修改性 可移植性24 可维护性的度量 各类维护中的侧重点可理解性可测试性可修改性可靠性可移植性可使用性效 率度量程序可维护性的7 7个特性258.3.2 8.3.2 提高可维护性的方法建立明确的软件质量目标和优先级 使用提高软件质量的技术和工具 进行明确的质量保证审查 选择可维护的程序设计语言 改进程序的文档 开发软件时考虑到维护268.3.3 预防性维护 开发和维护者不应等待用户的维护申请,可先选择以下类型程序作为预防性维护对象:预计若干年内将继续使用的程序当今正成功使用的程序最近的将来要进行大修改和完善的程序27
11、8.4 软件维护过程1.1.建立维护组织 -一般软件公司没有专门的软件维护机构，除非大型的软件。-维护机构成员一般包括：配置管理员、维护控制员、系统管理员、一般维护工作人员。28软件的维护任务 修改负责人维护申请系统监督员配置管理员维护机构维护人员维护管理员29 2.2.安排计划 -维护工作不应采用“一次改一个错”的零打细敲的方法，而应当有计划、有步骤地统筹安排。-维护报告应包括的内容：该维护工作的范围、所需资源、确认的要求、维护费用及维护进度安排。3.3.软件维护实施 -软件维护任务与新软件开发的过程基本上一致并且是并行的。-软件修改完成后由维修主管进行验收 4.4.软件维护文档 -除一般文
12、档外还包括：软件问题报告、软件变动报告、软件维护记录308.38.3软件再工程(Software Reengineering)(Software Reengineering)8.3.1 8.3.1 什么是软件再工程 软件再工程也成为更新或改造工程，它不仅恢复设计信息，而且去完善或重建一个系统，使质量得到提高。软件再工程比其它系统进化方法具有的绝对优势减少软件演化风险降低成本31 软件再工程过程模型代码重构数据重构正向工程库存目录分析文档重构逆向工程32再工程过程示意图 需求新需求设计设计代码代码正向工程反向工程（重构）（重构）（重构）33逆向工程(反向工程reverse engineering
13、)reverse engineering)设计的恢复过程非结构化、无文档的源代码或目标代码软件的文档 通过检验产品的实际样品，获得产品的有关设计或制造的规格说明34 逆向工程过程 将要再工程的系统自动分析手工加注释系统信息库文档生成数据结构图程序结构图可追溯矩阵35逆向工程恢复信息的级别:(1)(1)实现级:程序的抽象语法树、符号表等信息(2)(2)结构级:反映程序分量之间相互依赖关系的信息，如调用图、结构图等.(3)(3)功能级:反映程序段功能和段间关系的信息(4)(4)领域级:反映程序分量与应用领域概念间对应关系的信息抽象级别低高信息的抽象级别越高,它与代码距离越远,通过逆向工程恢复的难度
14、越大,自动工具支持的可能性变小36逆向工程源程序目标代码反汇编、反编译程序分析技术:程序结构分析工具 程序功能分析工具 源程序概要设计详细设计概要设计需求分析37一、软件工程管理的重要性先进的管理技术往往是大型软件开发成功的关键。二、软件工程管理技术38开发计划安排表达计划安排的三种主要工具：（1）一般表格工具进度表39（2 2）甘特图（Gantt ChartGantt Chart）实线 已完成虚线 未完成任务时间 5 10 15 20 时标网状图改进的 Gantt ChartGantt Chart任务 5 10 15 20 A1B1B240（3）PERT图Program Evaluation
15、 Review Technique 进度计划与评审技术，是一种网络图。调查研究2020天系统分析3030天系统设计6060天系统调试3030天子系统1 1编调4040天建立文件库3030天子系统2 2编调3030天用户培训2020天建立硬件系统3030天通过计算可以找出一条关键路径，计算出完成系统总时间。界面设计2525天界面调试1010天41人员组织安排一、人员组织原则1 1、专人负责、有责、有权。2 2、切忌开发过程中增加人员。例：一组4 4个软件工程师，独立开发 50005000行/年，每条联系路径降低工作生产率250250行/年。小组生产率为：20000-25020000-250 6=
16、185006=18500行/年新增加2 2人，生产率为840840行/年，联系路径增加到1515条。小组生产率为：20000+840 20000+840 2-250 2-250 15=1793015=1793042提问与解答环节Questions and answers43结束语 CONCLUSION感谢参与本课程，也感激大家对我们工作的支持与积极的参与。课程后会发放课程满意度评估表，如果对我们课程或者工作有什么建议和意见，也请写在上边，来自于您的声音是对我们最大的鼓励和帮助，大家在填写评估表的同时，也预祝各位步步高升，真心期待着再次相会！44谢谢聆听THANK YOU FOR LISTENING演讲者：XX 时间：202X.XX.XX
