11软件维护

2020/1/2112020/1/2122、维护的内容：维护内容的多少，依赖于设计水平的高低，设计水平高，尤其设计时就注意到软件的易维护性，则维护的内容和工作量就大为减少。（4个维护活动）一、维护概述1、软件维护的定义：软件交付使用以后，为改正潜藏错误，扩充功能，完善功能，结构翻新，延长软件寿命而进行的软件修改活动，称软件维护。2020/1/213（1）改正性维护：指发现和改正潜藏的软件错误。分为：非用户因素的错误的维护；影响系统正常运行的错误的维护；不影响系统正常运行的错误的维护。约占全部维护活动的17~20%；（2）适应性维护：指在硬件环境改善，软件支撑环境改善的情况下，交付使用的软件系统做相应的修改，以适应新的系统环境。约占全部维护活动的18~25%；（3）完善性维护：交付使用后，随着对系统的功能的熟悉，对系统环境的掌握，用户提出了一些新的增加功能和性能的要求，这些要求又是合理的，尽管需求规格说明书中没有规定，但对完善系统功能2020/1/214是必要的，则必须列入维护阶段再次开发设计测试维护，以适应用户要求，完善软件的功能，提高软件质量。约占全部维护活动的50~66%；（4）预防性维护：为了改进软件的可靠性与维护性，为了适应未来的软硬件的环境变化，主动地增加预防性的新版本功能，以使软件适应市场变化而不被淘汰。与其它维护活动共占总维护的4%左右。注：①一般维护的工作量占生存周期70%以上，维护成本约为开发成本的4倍(80-20Rule)；②文档维护与代码维护同样重要。2020/1/2153、软件维护的原因：（1）测试与纠错的不彻底性；（2）需求分析的不彻底性；（3）为了延长软件寿命，保证软件质量；（4）软件维护占软件开发的比重。2020/1/216二、维护的特点1、维护的特点：维护阶段是对软件工程所涉及问题处理的如何进行全面的检验。比如结构化的维护与非结构化的维护就差别很大。如果软件配置仅是程序代码，则维护活动从艰苦的评价代码开始，评价中又经常由于程序说明文档不全是评价很难进行。很难弄清楚软件结构、数据结构、系统接口、系统性能等。所以代码的改动后果难以估量。尤其没有测试方面的文档，一旦引入新错，将导致恶性循环。如下图。2020/1/217配置选择维护要求评价设计评价代码维护计划与途径确定错误修改设计重新编程交付使用重新编程复查复查正常正常有错有错确定未确定软件代码2020/1/2182、维护的代价有形代价：费用已上升至总预算的80%；无形代价：占用资源以致延误开发；修改不及时引起用户不满；维护引入新错误，降低了软件质量；等等。维护工作量的经验模型：M=P+Kec-d其中：M=Totalmaintenanceeffort;P=Productiveefforts(e.g.Analysis,evaluation,design,coding,andtesting);K=Empiricalconstant;c=Complexity(causedbythelackofstructureddesignanddocumentation)d=Degreetowhichthemaintenanceteamisfamiliarwiththesoftware.2020/1/2193、维护的问题•别人的程序很难读懂说明性文档不可缺少!•文档与代码不一致那是给谁看呢？•开发人员往往不参加维护•大多数软件在设计时没有考虑将来的修改软件工程的思想至少部分地解决了与维护有关的每一个问题。2020/1/2110§3.维护过程——本质上是修改和压缩了的软件定义和开发过程1、建立维护组织(maintenanceteam)：在维护活动开始之前就明确维护责任是十分必要的，这样可以大大减少维护过程中可能出现的混乱2020/1/2111要求维护维护管理员系统管理员客户要求任务评价任务评价变化授权人钱太少不干！2020/1/21122、维护报告⑴维护申请报告(MaintenanceRequestForm)由用户填写的外部文件，提供错误情况说明（输入数据，错误清单等），或修改说明书等。⑵软件修改报告(SoftwareChangeReport)与MRF相应的内部文件，要求说明：①所需修改变动的性质；②申请修改的优先级；③为满足某个维护申请报告，所需的工作量；④预计修改后的状况。2020/1/2113用户类型估计错误严重程度计划改正进度错误改正目录分析问题严重维护任务复审修改后的软件配置评价优先度开始分析开发目录完善适应低高复审后供使用的软件配置3、维护的事件流2020/1/2114软件可维护性可定性地定义为：维护人员理解、改正、改动和改进这个软件的难易程度。1、用于衡量可维护性的软件特性：改正性维护运行性维护完善性维护1.可理解性2.可测试性3.可修改性4.可靠性5.可移植性6.可使用性7.效率四、可维护性2020/1/2115(1)可理解性：指对软件的结构、接口、功能、内部过程理解的难易程度。程序模块化的结构特性、详细一致的设计文档、结构化设计的模块化、源代码的选取结构化语言描述、采取良好的设计风格都对软件可理解性起决定作用。好程序的特征：模块化、结构化、代码与设计风格一致，高级语言实现。度量方法：90-10Test——读源程序10分钟，能否默写出90%？2020/1/2116（2）可测试性：指诊断和测试的难易程度主要取决于软件容易理解的程度。可理解性良好的文档软件，则容易诊断和测试。所以模块间耦合性弱，接口单一，可存取性好，通信好、结构性好、自描述性好都能提高软件的可测试性。好程序的特征：可理解、可靠、简单。度量方法：程序复杂度（第6章中已讨论）2020/1/2117（3）可修改性：指修改软件模块的相关部分引起的错误少。耦合、内聚、局部化、控制域与作用域的关系等等，都影响软件的可修改性。好程序的特征：可理解、简单、通用。度量方法：其中：D=修改难度；A=要修改的模块的复杂度；C=所有模块的平均复杂度。D1表示修改很困难。⑸可移植性(Portability)是指程序被移到一个新环境的容易程度。好程序的特征：结构好，不特别依赖于某一具体的计算机或操作系统。⑷可靠性（第七章中已讨论）CAD2020/1/2118⑹可使用性（第七章中已讨论）⑺效率(Efficiency)是指程序能执行预定功能，而又不浪费机器资源（包括内存、外存、通道容量、执行时间等等）的程度。2020/1/21192、维护的文档文档是影响软件可维护的决定因素。文档比程序代码更重要。软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。2020/1/2120软件文档应满足要求：※必须描述如何使用这个系统，没有这种描述即使是最简单的系统也无法使用；※必须描述怎样安装和管理这个系统；※必须描述系统需求和设计；※必须描述系统的实现和测试，以便使系统成为可维护的。2020/1/2121用户文档至少应该包括下述五个方面的内容；※功能描述——说明系统能做什么；※安装文档——说明怎样安装这个系统以及怎样使系统适应特定的硬件配置；（1）用户文档：用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。2020/1/21222、系统文档：指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序为来说是极端重要的。※使用手册——简要说明如何着手使用这个系统※参考手册——详尽描述用户可以使用的所有系统设施以及它们的使用方法，还应该解释系统可能产生的各种出错信息的含义；※操作员指南——说明操作员应该如何处理使用中出现的各种情况。2020/1/21233、复审分析设计编码测试验收配置复审可靠性可移植性可用性可理解性可修改性可测试性可理解性可修改性可移植性效率可靠性效率完整性一致性可理解性各阶段复审重点：