第六章 软件维护

第六章软件维护第一页，共四十八页，编辑于2023年，星期四软件维护大型软件维护成本甚至高达开发成本的四倍左右。国外软件开发组织把60%左右的人力用于维护，并有上升趋势。增强功能大约占软件维护成本的60%，错误更正仅占17%。因此，软件维护的主题是在旧软件中加入新功能，而不是更正错误。维护是解决方案，而不是问题。比较软件开发和软件维护中的工作，除了维护中“理解现有的产品”这项工作之外，其他工作都一样。这项工作占据了大约30%的维护时间，是主要的维护活动。因此可以说维护比开发更难。第二页，共四十八页，编辑于2023年，星期四软件维护编程大师曾说过：“哪怕程序只有三行长，总有一天你也不得不对它进行维护。”软件维护是软件生命周期的最后一个阶段，软件从部署完毕到退役的整个时间内对软件的改动所做的工作都是维护的内容。在项目的各个阶段对项目的可维护性进行充分考虑、对可维护性的严格评审以及在维护阶段有效地组织和管理维护活动，则是保证软件可维护性和降低维护费用的关键。第三页，共四十八页，编辑于2023年，星期四第六章软件维护6.1软件维护的定义和分类6.2软件维护的特点6.3可维护性6.4维护过程与维护活动6.5软件维护的副作用6.6软件再工程6.7小结第四页，共四十八页，编辑于2023年，星期四6.1软件维护的定义和分类软件维护：是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。维护的目的：保证软件系统能持续地与用户环境、数据处理操作、政府或其他有关部门的请求取得协调。第五页，共四十八页，编辑于2023年，星期四软件维护的分类按照维护的起因分类：纠错性维护适应性维护改善性维护预防性维护四类第六页，共四十八页，编辑于2023年，星期四1.纠错性维护在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做纠错性维护。第七页，共四十八页，编辑于2023年，星期四2.适应性维护

适应性维护——为适应软件运行环境的变化而修改软件的活动。在使用过程中，外部环境（新的硬、软件配置）数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。第八页，共四十八页，编辑于2023年，星期四3.改善性维护改善性维护——根据用户在软件使用过程中提出的建设性意见而进行的维护活动。主要是针对用户提出的新的软件需求或修改原有的软件需求而进行的维护，该种维护通常占所有维护工作量的一半以上。软件在部署之后一段时间内，用户的改善性维护应该是递减的。第九页，共四十八页，编辑于2023年，星期四4.预防性维护预防性维护——为了进一步改善软件系统的可维护性和可靠性，并为以后的改进奠定基础。预防性维护可以采取逆向工程（reverseengineering）和重构工程（re-engineering）方式。第十页，共四十八页，编辑于2023年，星期四6.2软件维护的特点6.2.1软件工程方法对维护的影响6.2.2维护的代价高昂6.2.3软件维护中的一些典型问题第十一页，共四十八页，编辑于2023年，星期四6.2.1软件工程方法对维护的影响软件的开发过程对软件的维护产生较大的影响。如果采用软件工程的方法进行软件开发，保证每个阶段都有完整且详细的文档，这样维护会相对容易，被称为结构化的维护。反之，如果不采用软件工程方法开发软件，软件只有程序而欠缺文档，则维护工作变得十分困难，被成为非结构化的维护。结构化维护非结构化维护程序文档第十二页，共四十八页，编辑于2023年，星期四结构化维护与非结构化维护交付使用分析设计制定计划修改计划重新编码复审通过文件有吗苦读代码找到问题重新编码复审通过维护请求nyyyynnn结构化维护

非结构化维护

第十三页，共四十八页，编辑于2023年，星期四非结构化维护在非结构化维护过程中，开发人员只能通过阅读、理解和分析源程序来了解系统功能、软件结构、数据结构、系统接口和设计约束等，这样做是十分困难的，也容易产生误解。要弄清楚整个系统，势必要花费大量的人力和物力，对源程序修改产生的后果难以估计。在没有文档的情况下，也不可能进行回归测试，很难保证程序的正确性。第十四页，共四十八页，编辑于2023年，星期四结构化维护在结构化维护的过程中，所开发的软件具有各个阶段的文档，它对于理解和掌握软件的功能、性能、体系结构、数据结构、系统接口和设计约束等有很大的作用。维护时，开发人员从分析需求规格说明开始，明白软件功能和性能上的改变，对设计说明文档进行修改和复查，再根据设计修改进行程序变动，并用测试文档中的测试用例进行回归测试，最后将修改后的软件再次交付使用。这种维护有利于减少工作量和降低成本，大大提高软件的维护效率。第十五页，共四十八页，编辑于2023年，星期四6.2.2维护的代价高昂维护费用只不过是软件维护最明显的代价，其他一些还不明显的代价将来可能更为人们关注。其他无形的代价还有：可用的资源被软件维护所占用。未能及时满足用户的维护要求时引起用户不满。维护时改动软件，引入了潜在故障，降低了软件质量。抽调人员从事维护工作，对新的开发过程造成混乱。导致生产率的大幅下降。第十六页，共四十八页，编辑于2023年，星期四软件维护的代价高昂用于维护工作的劳动可以划分成：生产性活动（如，分析评价、修改设计、编写程序代码等）非生产性活动（例如，理解程序代码功能、解释数据结构、接口特点、性能限度等）第十七页，共四十八页，编辑于2023年，星期四维护工作量的计算模型M＝P+Ke(c-d)其中：M：维护所用工作量；

P：生产性工作量—分析评价、修改设计和代码；

Ke(c-d)：助动性工作量—理解文档和代码；

K：经验常数；

c：软件的维护复杂度，由软件本身的复杂度，软件的设计质量以及文档化的程度等因素决定；

d：维护人员对软件的熟悉程度；上述模型表明，如果软件开发没有运用软件工程方法学，而且原来的开发人员未能够参与到维护工作之中，则维护工作量和费用将指数增加。第十八页，共四十八页，编辑于2023年，星期四6.2.3软件维护中的一些典型问题与软件维护有关的大多数问题都可归因于软件定义和开发方法上的不足。软件开发时采用急功近利，还是放眼未来的态度，对软件维护影响极大。一般说来，软件开发若不严格遵循软件开发标准，软件维护就会遇到许多困难。第十九页，共四十八页，编辑于2023年，星期四维护的问题（1）理解他人编写的程序一般都有一定的困难性。（2）软件配置的文档严重不足甚至没有，或者没有合格的文档。（3）当需要对软件进行维护时，由于软件人员经常流动，维护阶段持续的时间又很长，所以一般不能指望由原来的开发人员来完成或提供软件的解释。（4）绝大多数软件在设计时没有考虑到将来的修改问题。（5）软件维护可以说是一项毫无吸引力的工作。之所以形成这样一种观念，一方面是因为软件维护工作量大，看不到什么“成果”，更主要的原因是因为维护工作难度大，又经常遭受挫折。第二十页，共四十八页，编辑于2023年，星期四6.3可维护性6.3.1决定软件可维护性的因素6.3.2可维护性的若干量化的测度6.3.3提高软件的可维护性方法第二十一页，共四十八页，编辑于2023年，星期四6.3可维护性软件可维护性可以定性地定义为：维护人员理解、改正、改动和改进这个软件的难易程度。软件的可维护性是软件开发的目标之一。可维护性、可用性、可靠性是软件质量的主要质量特征。第二十二页，共四十八页，编辑于2023年，星期四6.3.1决定软件可维护性的因素决定软件可维护性的因素主要有下述5个：(1)可理解性(2)可测试性(3)可修改性(4)可移植性(5)可重用性第二十三页，共四十八页，编辑于2023年，星期四6.3.2可维护性的若干量化的测度软件可维护性与软件质量和可靠性一样是难于量化的概念，然而借助维护活动中可以定量估算的属性，能间接地度量可维护性:(1)问题识别时间。(2)管理延迟时间。(3)收集维护工具所用的时间。(4)分析问题所需时间。(5)形成修改说明书所需时间。(6)纠错（或修改）所用时间。(7)局部测试所用时间。(8)整体测试所用时间。(9)维护复审所用时间。(10)完全恢复所用时间。第二十四页，共四十八页，编辑于2023年，星期四6.3.3提高软件的可维护性方法(1)建立软件质量目标和优先级(2)使用提高软件质量的技术和工具(3)进行明确的质量保证审查(4)选择可维护性好的程序设计语言(5)建立维护文档第二十五页，共四十八页，编辑于2023年，星期四6.4维护过程与维护活动6.4.1软件维护工作的内容6.4.2建立维护机构6.4.3软件维护流程6.4.4维护报告第二十六页，共四十八页，编辑于2023年，星期四6.4维护过程与维护活动为了有效地进行软件维护，应事先就开始做组织工作。首先建立维护的机构申明提出维护申请报告的过程及评价的过程为每一个维护申请规定标准的处理步骤建立维护活动的登记制度以及规定评价和评审的标准。第二十七页，共四十八页，编辑于2023年，星期四6.4.1软件维护工作的内容（1）评价系统的升级要求，在对软件功能和运行环境分析的基础上，提出升级报告。（2）评价系统的改正问题请求，提出对请求改正的解决办法。（3）程序的紧急排错。（4）制定系统的维护更新计划。（5）维护更新版本需求分析，编写更新需求文档。（6）维护更新版本设计，设计维护更新版本的程序及数据结构，完成设计。第二十八页，共四十八页，编辑于2023年，星期四6.4.1软件维护工作的内容（7）维护更新版本编码和测试，产生新的版本。（8）发布新版本。（9）实施预防性维护。（10）人员培训。（11）周期性系统评估，写出评估报告。（l2）系统运行一定时间后，对系统进行全面评审，写出报告。第二十九页，共四十八页，编辑于2023年，星期四6.4.2建立维护机构维护决策机构维护管理员系统管理员维护人员配置管理员维护申请每个维护申请通过维护管理员转告给系统管理员，系统管理员一般都是对程序(某一部分)特别熟悉的技术人员，他们对维护申请及可能引起的软件修改进行评估，并向修改控制决策机构(一个或一组管理者)报告，由它最后确定是否采取行动。在维护活动开始之前就明确维护责任是十分必要的，可以大大地减少维护过程中可能出现的混乱。第三十页，共四十八页，编辑于2023年，星期四6.4.3软件维护流程第三十一页，共四十八页，编辑于2023年，星期四6.4.4维护报告编写维护报告要填写两项文件：（1）维护申请报告（MaintenanceRequestForm）。（2）软件维护记录常用的软件维护档案可参见表6-1。第三十二页，共四十八页，编辑于2023年，星期四维护申请报告MRF应该用标准的格式来表达维护要求。软件维护人员通常提供给用户空白的维护请求表（报告）即软件问题报告，该报告（表）由要求一项维护活动的用户填写。如遇到什么错误，用户需要详细描述错误出现的现场信息(包括输入数据、列表文件和其他有关信息)；对适应性维护、完善性维护应该给出一个简短的需求规格说明书。最终由维护管理员和系统管理员评价用户用户提出的维护请求表。一个维护申请被核准后，维护请求表就成为外部文档，视作规划本次维护任务的依据。第三十三页，共四十八页，编辑于2023年，星期四例子：软件维护申请报告评价负责人：***申请评价结果：修正错误 批准拒绝申请人：******环境自****年**月**日至*****年**月**日共计

0.5人月维护时间维护要求及优先级：在测评之前必须修正，否则会造成测评结果的不准确软件： 纠错维护 适应维护 完善维护硬件： 系统设备 外部设备维护类型 远程维护 现场维护维护安排预计维护的结果：修正程序中的人员权限，使得每种类型的人员只能进行自身类型的测评。问题说明：(数据输入、错误现象)不同类型的人员可以进行交叉测评。按需求：各类人员只进行自身类型的测评，如管理人员只能对管理人员进行测评，教师只能测评教师。项目编号网络测评系统项目名称√√√第三十四页，共四十八页，编辑于2023年，星期四软件维护记录的保存有效的保存维护记录是极端重要的。保存维护记录的第一个问题就是那些数据值得保存？Swanson给出了下述的项目表：（1）程序名称；（2）源程序语句条数；（3）机器代码指令条数；（4）使用的程序设计语言；（5）程序的安装日期；（6）程序安装后的运行次数；（7）与程序安装后运行次数有关的处理故障的次数；第三十五页，共四十八页，编辑于2023年，星期四软件维护记录（8）程序修改的层次和名称；（9）由于程序修改而增加的源程序语句条数；（10）由于程序修改而删除的源程序语句条数；（11）每项修改所付出的“人时”数；（12）程序修改的日期；（13）软件维护人员的姓名；（14）维护申请报告的名称；（15）维护类型；（16）维护开始时间和维护结束时间；（17）用于维护的累计“人时”数；（18）维护工作的净收益。第三十六页，共四十八页，编辑于2023年，星期四例子：软件维护记录维护结果：经过对需求的进一步确认，对指定编号的模块进行了修改，纠正了源程序中出现的错误。维护人员：*****……****0.2个人月修改部分源程序查错，确定错误位置**月**日维护人员工作量增/删/改维护内容日期编号：evalobject_01机器指令长度：25Kb程序安装日期：****年**月**日程序运行时间：模块名称：测评控制管理源程序行数：210编程语言：PHP失效次数：3初始状态描述：不同类型的人员可以进行交叉测评。按需求：各类人员只进行自身类型的测测评，如管理人员只能对管理人员进行测评，教师只能测评教师。项目名称：网络测评系统计划编号：eval_wh_012日期：****年**月**日记录编号：eval_wh_012第三十七页，共四十八页，编辑于2023年，星期四6.4.5维护评价一般来说，可以从以下七个方面来评价维护工作：（1）每次程序运行时的平均出错次数；（2）用于每一类维护活动的总“人时”数；（3）每个程序、每种语言、每种维护类型所做的平均修改数；（4）维护过程中，增加或删除每条源程序语句花费的平均“人时”数；（5）用于每种语言的平均“人时”数；（6）一张维护申请报告的平均处理时间；（7）各类维护类型所占的百分比。第三十八页，共四十八页，编辑于2023年，星期四6.5软件维护的副作用软件修改是一项很危险的工作,对一个复杂的逻辑过程,那怕做一项微小的改动,都可能引入潜在的错误,虽然设计文档化和细致的回归测试有助于排除错误,但是维护仍然会产生副作用。软件维护的副作用指，由于维护或在维护过程中其他一些不期望的行为引入的错误,副作用大致可分为三类:代码副作用数据副作用文档的副作用第三十九页，共四十八页，编辑于2023年，星期四代码的副作用修改或删除子程序;修改或删除语句标号;修改或删除标识符;为提高执行效率而做的修改;修改文件的open、close操作;修改逻辑操作符;由设计变动引起的代码修改;修改对边界条件的测试。第四十页，共四十八页，编辑于2023年，星期四数据的副作用局部和全局常量的再定义;记录或文件格式的再定义;增减数据或其他复杂数据结构的体积;修改全局数据;重新初始化控制标志和指针;重新排列I/O表或子程序参数表。第四十一页，共四十八页，编辑于2023年，星期四文档的副作用维护应统一考虑整个软件配置,而不仅仅是源代码。否则,由于在设计文档和用户手册中未能准确反映修改情况而引起文档副作用。对软件的任何修改都应在相应的技术文档中反映出来,如果设计文档不能与软件当前的状况对应则比没有文档更糟。对用户来说,若使用说明中未能反映修改后的状况,那么用户在这些问题上必定出错。一次维护完成之后,再次交付软件之前应仔细复审整个配置,有效地减少文档副作用。某些维护申请不必修改设计和代码,只需整理用户文档便可达到维护的目的。第四十二页，共四十八页，编辑于2023年，星期四6.6软件再工程6.6.1软件再工程过程模型6.6.2逆向工程6.6.3软件重构第四十三页，共四十八页，编辑于2023年，星期四6.6软件再工程所谓软件再工程（SoftwareReengineering），就是将新技术和新工具应用于老的软件的一种较“彻底”的预防性维护。软件再工程不同于一般的软件维护。后者是局部的，以完成纠错或适应需求变化为目的；而软件再工程则是运用逆向工程（ReverseEngineering）、重构（Restructure）等