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