软件工程-第9章-软件维护-CUMT-110726课件

第9章软件维护1计算机网络》课件制作人：谢希仁整体概述THEFIRSTPARTOFTHEOVERALLOVERVIEW,PLEASESUMMARIZETHECONTENT第一部分2可行否？否是终止项目计划时期开发时期（SA,SD,SP）运行时期维护3课件制作人：谢希仁9.1软件维护的概念9.2软件维护的代价9.3维护过程9.4可维护性9.5维护的副作用4课件制作人：谢希仁9.1软件维护的概念1.软件维护的定义2.影响维护工作量的因素3.软件维护的策略4.维护成本5课件制作人：谢希仁9.1.1软件维护的定义在软件已经交付用户使用之后，为了改正错误或满足新的需求而进行修改软件的过程。维护的类型有：改正性维护适应性维护完善性维护预防性维护6课件制作人：谢希仁1.改正性维护在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。7课件制作人：谢希仁定义：运行时期为诊断、改正错误而修改软件的过程。原因：开发时期测试是不彻底的，会有部分隐藏的错误遗留到运行时期。目的：识别和改正软件错误；8课件制作人：谢希仁2.适应性维护在使用过程中，外部环境（新的硬、软件配置）数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。9课件制作人：谢希仁定义：为使软件适应变化而修改软件的过程。原因：在软件运行过程中，⑴外部环境——新的硬、软件配置。⑵数据环境数据库数据输入/输出方式数据存储介质可能发生变化。10课件制作人：谢希仁3.完善性维护在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。11课件制作人：谢希仁定义：为了满足这些要求，需要修改或再开发软件的维护活动叫做完善性维护。这种情况下进行。原因：在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。目的：扩充软件功能 增强软件性能12课件制作人：谢希仁4.预防性维护预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。预防性维护定义为：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。13课件制作人：谢希仁定义：对需要维护的软件或软件中的某一部分（重新）进行设计、编码和测试。目的：了提高软件的可维护性、可靠性等；为以后进一步改进软件打下良好基础。14课件制作人：谢希仁实践表明，在几种维护活动中，完善性维护所占的比重最大。即大部分维护工作是改变和加强软件，而不是纠错。完善性维护不一定是救火式的紧急维修，而可以是有计划、有预谋的一种再开发活动。事实证明，来自用户要求扩充、加强软件功能、性能的维护活动约占整个维护工作的50％5.各类维护工作所占的比重15课件制作人：谢希仁在整个软件维护阶段所花费的全部工作量中，完善性维护占了几乎一半的工作量。软件维护活动所花费的工作占整个生存期工作量的70%以上，这是由于在漫长的软件运行过程中需要不断对软件进行修改，以改正新发现的错误、适应新的环境和用户新的要求，这些修改需要花费很多精力和时间，而且有时会引入新的错误16课件制作人：谢希仁三类维护占维护在软件生存期

总维护比例 所占比例17课件制作人：谢希仁改正性维护(CorrectiveMaintenance)适应性维护(AdaptiveMaintenance)完善性维护(PerfectiveMaintenance)预防性维护(PreventiveMaintenance)占维护总工作量的50%不一定是救火式的紧急维修，而是有计划、有预谋的一种再开发活动。18课件制作人：谢希仁软件维护的工作占整个生存期工作量的70%以上软件生命周期问题定义可行性研究需求分析概要设计详细设计编码测试运行与维护70%以上19课件制作人：谢希仁9.1.2软件维护的代价在软件的维护过程中，需要花费大量的工作量，从而直接影响了软件维护的成本。应当考虑有哪些因素影响软件维护的工作量，相应应该采取什么维护策略，才能有效地维护软件并控制维护的成本20课件制作人：谢希仁费用代价（有形）1970年 35%~40%1980年 40%~60%1990年 70%~80%其它（无形）不能及时满足用户合理的修改要求，引起用户不满；抽调开发者去从事维护，使得开发造成混乱。引入了新的潜伏的故障，降低了软件的质量；21课件制作人：谢希仁1.维护工作量的计算模型M=P+K×exp(c-d)M是维护的总工作量P是生产性工作量K是经验系数c是复杂程度（非结构化设计和缺少文档都会增加软件的复杂程度）d是维护人员对软件的熟悉程序22课件制作人：谢希仁2.影响维护代价的非技术因素⑴应用域的复杂性需求分析工作比较完善代价低。⑵开发人员的稳定性开发者维护自己的程序代价低；⑶软件的生命周期软件生命周期越长代价越高；⑷商业操作模式变化对软件的影响商业操作模式变化越频繁代价越高；如，财务制度改变财务软件修改23课件制作人：谢希仁3.影响维护代价的技术因素⑴软件对运行环境的依赖性⑵编程语言⑶编程风格风格好可理解性好代价越低；⑷测试与改错工作⑸文档的质量清晰、正确和完整的文档降低维护的代价24课件制作人：谢希仁4.维护成本有形的软件维护成本是花费了多少钱，无形的维护成本有更大的影响。一些合理的修复或修改请求不能及时安排，使得客户不满意；变更的结果引入新的故障，使得软件整体质量下降；把软件人员抽调到维护工作中，干扰了软件开发工作。25课件制作人：谢希仁9.3软件维护活动为了有效地进行软件维护，应事先就开始做组织工作。首先建立维护的组织申明提出维护申请报告的过程及评价的过程为每一个维护申请规定标准的处理步骤建立维护活动的登记制度以及规定评价和评审的标准。26课件制作人：谢希仁1.维护组织除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构虽然不要求建立一个正式的维护机构，但是在开发部门确立一个非正式的维护机构则是非常必要的每个维护要求都通过维护管理员转交给相应的系统管理员去评价。系统管理员是被指定去熟悉一小部分产品程序的技术员。系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。27课件制作人：谢希仁软件维护的组织形式28课件制作人：谢希仁2.维护申请单软件维护人员通常给用户提供空白的维护要求表，也称软件问题报告表这个表通常由申请维护的用户填写如果遇到了一个错误，那么必须完整地描述导致出现该错误的环境（包括输入数据、全部输出数据，以及其他有关的信息）如果申请适应性或完善性维护，则仅需提出一个简要的需求说明29课件制作人：谢希仁3.维护流程用户区分维护类型评价优先级适应性要求⊕评价错误严重性改正的错误维护申请安排维护任务不严重错误维护任务目录错误分析严重错误⊕⊕维护任务复审维护计划改正后的软件问题分析高优先级维护计划⊕低优先级30课件制作人：谢希仁不同类型的维护强调的重点不同，但基本途径是相同的不管维护类型如何，都需要进行：修改软件需求说明修改软件设计设计评审对源程序做必要的修改单元测试集成测试(回归测试)

确认测试软件配置评审等维护流程的一般任务31课件制作人：谢希仁维护任务修改软件设计设计评审代码修改单元测试集成测试确认测试修改需求说明32课件制作人：谢希仁4.维护评价每次程序运行平均失效的次数；用于每一类维护活动的总人时数；平均每个程序、每种语言、每种维护类型所做的程序变动数；维护过程中增加或删除一个源语句平均花费的人时数；维护每种语言平均花费的人时数；一张维护申请表的平均周转时间；不同维护类型所占的百分比。33课件制作人：谢希仁9.4可维护性所谓软件的可维护性，就是衡量纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度的一种软件属性提高软件的可维护性是支配软件工程方法论所有步骤的重要目标。34课件制作人：谢希仁维护就是在软件交付使用后进行的修改，修改之前必须理解修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。如果是改正性维护，还必须预先进行调试以确定故障。影响软件可维护性主要有下述的三个因素：可理解性可修改性可测试性9.4.1可维护性的决定因素

35课件制作人：谢希仁1.可理解性理解一个程序，包括理解程序的结构、功能、接口和内部过程模块化、结构化、详细的设计文档、源代码内部的文档说明和良好的高级程序设计语言等，都对改进软件的可理解性有重要的贡献在多数情况下，维护者并不是软件的开发者,而读懂别人写的程序是困难的如果文档不全，或仅有程序而无文档，则难度更大36课件制作人：谢希仁维护者并不是软件的开发者，而读懂别人写的程序是困难的。详细的设计文档、源代码内部的注释说明和良好的高级程序设计语言等，都对改进软件的可理解性有重要的贡献如果文档不全，或仅有程序而无文档，降低软件的可理解性。37课件制作人：谢希仁2.可修改性可修改性表明程序容易修改的程度。维护过程中，要对源代码和有关文档进行修改。在修改的过程中，可能引入新的错误，也可能把程序和文档改错。可修改性好的程序，在修改时出错的概率也小一些。模块设计时的内聚、耦合、作用范围/控制范围等因素都会影响软件的可修改性。38课件制作人：谢希仁可修改性表明程序容易修改的程度。模块设计时的内聚、耦合、作用范围/控制范围等因素都会影响软件的可修改性。可修改性好的程序，在修改时出错的概率也小一些。39课件制作人：谢希仁3.可测试性可测试性代表一个软件容易被测试的程度它一方面与源代码有关，要求程序有良好的可理解性和较低的结构复杂度同时要求有齐全的测试文档，包括开发时期用过的测试用例与结果，以便进行回归测试40课件制作人：谢希仁可测试性代表一个软件容易被测试的程度要求程序有良好的可理解性和结构不复杂要求有齐全的测试文档开发时期用过的测试用例与结果41课件制作人：谢希仁9.4.2提高可维护性的方法建立明确的软件质量目标和优先级使用提高软件质量的技术和工具进行明确的质量保证审查选择可维护的程序设计语言提供完整和一致的文档42课件制作人：谢希仁9.5维护的副作用在软件维护时，必然会对源程序进行修改。所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况。副作用有三种：修改代码的副作用修改数据的副作用文档的副作用43课件制作人：谢希仁(1)修改代码的副作用在修改源代码时，都可能引入错误删除或修改一个子程序删除或修改一个标号删除或修改一个标识符改变程序代码的时序关系改变占用存储的大小改变逻辑运算符修改文件的打开或关闭改进程序的执行效率对策：一般在回归测试过程中发现并纠正44课件制作人：谢希仁(2)修改数据的副作用在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。修改数据副作用就是修改软件信息结构导致的结果。对策：修改数据的副作用可以通过完善设计文档来加以控制文档描述了数据结构，并提供了一种把数据元素、记录、文件以及其他结构与软件模块联系起来的交叉对照表45课件制作人：谢希仁(3)修改文档的副作用如果源代码的修改没有反映在设计文档或用户手册中，就会出现文档的副作用。不能正确反映软件当前状态的文档可能比完全没有文档更坏在以后的维护工作中单纯地阅读这些文档会导致对软件特性的不正确理解和评价，这样就产生了文档的副使用对策：在软件再次交付使用之前，对整个文档进行复审将能减少文档的副作用46课件制作人：谢希仁软件再工程

正向工程信息库分析文档重构逆向工程