软件工程教案(软件维护).ppt

软件工程,软件维护,可行性研究,需求分析,概要设计,详细设计,实 现,集成测试,确认测试,使用与维护,退役,软件定义,软件开发,软件使用与维护,软件生命周期,软件维护主要任务是在软件使用/维护阶段，为了改正错误或满足新的需要而修改软件,大型软件的维护成本高达开发成本的4倍左右目前国外许多软件开发组织把60以上的人力用于维护已有的软件而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升,1.软件维护的定义,Q：什么是维护？A：在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。Q：维护做什么？A:诊断和改正错误 改正性维护(corrective maintenance),约占全部维护活动的 1720%；为了和变化了的环境（如软硬件升级、新数据库等）适当地配合而修改软件 适应性维护(adaptive maintenance)，约占全部维护活动的1825%；,例如：MySQL-SQL Server 低冗余DB存储方案,为了增加新功能，修改已有功能，改造界面，增加HELP等，而修改软件 完善性维护（perfective maintenance),约占全部维护活动的5066%；为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件 预防性维护(preventive maintenance)，与其它维护活动共占总维护的4%左右。,注：一般维护的工作量占生存周期70%以上，维护成本约为开发成本的4倍(80-20 Rule)；文档维护与代码维护同样重要。,例如：Zigbee无线采集管理系统,软件结构、系统接口、约束条件？,不知道！,(1)结构化维护与非结构化维护的对比,评价代码,评价设计文档,交付使用,2.软件维护的特点,(2)维护的代价 有形代价：费用已上升至总预算的80%；无形代价：占用资源以致延误开发；修改不及时引起用户不满；维护引入新错误，降低了软件质量，等等。维护工作量的经验模型：,M=P+K ec-d其中：M=维护用的总工作量;P=生产性工作量(e.g.分析,评估,设计,编码,and 测试);K=经验常数;c=复杂度(主要来自缺乏结构化设计和必要的文档)d=维护人员对软件的熟悉程度.,软件维护的费用逐年上升,(3)维护的问题,别人的程序很难读懂,说明性文档不可缺少!,文档与代码不一致,那是给谁看呢？,开发人员往往不参加维护,工资不一样嘛！,大多数软件在设计时没有考虑将来的修改,所以不是人人能发财,软件工程的思想至少部分地解决了与维护有关的每一个问题。,3.软件维护过程,软件维护过程本质上是修改和压缩了的软件定义和开发过程有效的维护需要建立一个维护组织确定报告和评价的过程为每个维护要求规定一个标准化的事件序列建立一个适用于维护活动的记录保管过程，并且规定复审标准,(1)建立维护组织(maintenance team)：在维护活动开始之前就明确维护责任是十分必要的，这样可以大大减少维护过程中可能出现的混乱,维护管理员,系统管理员,客户要求,任务评价,任务评价,变化授权人,钱太少不干！,(2)维护报告维护申请报告(Maintenance Request Form)由用户填写的外部文件，提供错误情况说明（输入数据，错误清单等），或修改说明书等。软件修改报告(Software Change Report)与MRF相应的内部文件，要求说明：所需修改变动的性质；申请修改的优先级；为满足某个维护申请报告，所需的工作量；预计修改后的状况。,用户,类型,维护要求,估计错误严重程度,改错,计划改正进度,不严重,分析问题,严重,维护任务,分配的人员,复审,修改后的软件配置,评价优先度,开始分析,完善,适应,低,高,分配的人员,复审后供使用的软件配置,(3)维护的事件流,(4)保存维护记录先要确定哪些数据是值得记录，下述内容：程序标识；源语句数目；机器指令条数；使用的程序设计语言；程序安装日期；从安装以来程序运行的次数、失效的次数；程序变动的层次和标识；因程序变动而增加的源语句数、删除的源语句数；每个改动耗费的人时数；修改程序的日期；软件工程师的名字；维护要求表的标识；维护类型；维护开始和结束日期；累计用于维护的人时数；与完成的维护相联系的纯效益。,(5)评价维护活动 可以对维护工作从以下几个方面进行度量。每次程序运行平均失效的次数；用于每类维护活动的总人时数；平均每个程序、每种语言、每种维护类型所做的程序变动数；维护过程中增加或删除一个源语句平均花费的人时数；维护每种语言源程序花费的人时数；一张维护申请表的平均周转时间；不同维护类型所占的百分比。,软件可维护性：维护人员理解、改正、改动和改进这个软件的难易程度。(1)用于衡量可维护性的软件特性：,4.软件的可维护性,可理解性(Understandability)是指由文档代码理解功能运行的容易程度。对外又称 user friendliness.好程序的特征：模块化、结构化、代码与设计风格一致，高级语言实现。度量方法：90-10 Test 读源程序10分钟，能否默写出90%？可测试性(Testability)是指论证程序正确性的容易程度。好程序的特征：可理解、可靠、简单。度量方法：程序复杂度,可修改性(Reparability)是指程序容易修改的程度。好程序的特征：可理解、简单、通用。度量方法：,可移植性(Portability)是指程序被移到一个新环境的容易程度。好程序的特征：结构好，不特别依赖于某一具体的计算机或操作系统。,其中：D=修改难度；A=要修改模块的复杂度 C=所有模块的平均复杂度。D 1表示修改很困难。,可靠性,可使用性,效率(Efficiency)是指程序能执行预定功能，而又不浪费机器资源（包括内存、外存、通道容量、执行时间等等）的程度。,(2)文档 影响可维护性的决定因素，比代码更重要。用户文档：功能描述 说明系统能做什么；,安装文档 说明安装系统的方法及适应特定的硬件配置的方法；,使用手册 说明使用方法以及错误挽救方法；,参考手册 详尽描述用户可使用的所有系统设施以及它们的使用方法；给出错误信息注解表；,操作员指南（如果需要有系统操作员的话）说明操作员处理使用中出现的各种情况的方法。,系统文档：即软件生产过程中每一步产生的文档。,分析,设计,编码,测试,验收,配置复审,可靠性可移植性可用性,可理解性可修改性可测试性,可理解性可修改性可移植性效率,可靠性效率,完整性一致性可理解性,各阶段复审重点：,(3)复审,5.预防性维护,如何应对“老程序”反复多次地做修改程序的尝试尽可能多地掌握程序的内部细节应用软件工程对程序重新设计、编码、测试预防性维护的认识维护一行源代码的代价是开发的14-20倍重新设计软件体系结构的必要性现有软件可作为“原型”使用，提高开发效率容易明确“变更需求和变更的范围”可利用逆向工程和再工程工具，使部分工作自动化可以建立起完善的软件配置,