搜索
1情景2.2软件维护2第7章软件维护7.1软件维护的定义软件维护----就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。维护的类型有四种：改正性维护适应性维护扩充与完善性维护预防性维护3改正性维护---CorrectiveMaintenance•在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。•这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。•为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，所进行的诊断和改正错误的过程就叫做改正性维护。4适应性维护---AdaptiveMaintenance•在使用过程中，–外部环境（新的硬、软件配置）–数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。•为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。5扩充与完善性维护---PerfectiveMaintenance•在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。•为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。•这种情况下进行的维护活动叫做扩充与完善性维护。6预防性维护---PreventiveMaintenance•预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。•预防性维护定义为：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。7各种维护所占比例:其它维护4%适应性维护18%～25%改正性维护17%～21%扩充与完善性维护50%～60%87.2软件维护的特点--影响维护工作量的因素•在软件的维护过程中，需要花费大量的工作量，从而直接影响了软件维护的成本。•应当考虑有哪些因素影响软件维护的工作量，相应应该采取什么维护策略，才能有效地维护软件并控制维护的成本。•系统大小：系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。因而需要更多的维护工作量。•程序设计语言：使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。9•系统年龄：–老系统随着不断的修改，结构越来越乱；–维护人员经常更换，程序又变得越来越难于理解–许多老系统在当初并未按照软件工程的要求进行开发，因而没有文档，或文档太少。–在长期的维护过程中文档在许多地方与程序实现变得不一致，在维护时就会遇到很大困难。•数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可以减少生成用户报表应用软件的维护工作量。10•先进的软件开发技术：在软件开发时，若使用能使软件结构比较稳定的分析与设计技术，及程序设计技术，如面向对象技术、复用技术等，可减少大量的工作量。•其它：–应用的类型–数学模型–任务的难度–开关与标记、IF嵌套深度、索引或下标数等对维护工作量都有影响。•许多软件在开发时并未考虑将来的修改，为软件的维护带来许多问题。11维护成本•有形的软件维护成本是花费了多少钱，无形的维护成本有更大的影响。–一些合理的修复或修改请求不能及时安排，使得客户不满意；–变更的结果引入新的故障，使得软件整体质量下降；–把软件人员抽调到维护工作中，干扰了软件开发工作。12维护工作量的模型•M是维护中消耗的总工作量•P是生产性工作量•K是一个经验常数•c是因缺乏好的设计和文档而导致复杂性的度量•d是维护人员对软件熟悉程度的度量•模型指明，如果使用了不好的软件开发方法（未按软件工程要求做），原来参加开发的人员或小组不能参加维护，则工作量（及成本）将按指数级增加。dcKepM137.2.3维护中的典型问题(1)难以跟踪软件版本的进化过程,软件的变化未在文档中反映出来.(2)难以跟踪软件的创建过程.(3)难以读懂他人程序.(4)无文档或不全.(5)软件人员流动性大.(6)设计时未考虑修改需要,修改困难.(7)维护工作无吸引力,缺乏成就感.采用软件工程方法至少可部分地解决与维护有关的每一个问题。147.3软件维护过程•维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。•为了有效地进行软件维护，应事先就开始做组织工作。–首先建立维护的机构–申明提出维护申请报告的过程及评价的过程–为每一个维护申请规定标准的处理步骤–建立维护活动的记录保管，并规定复审的标准151、维护机构•除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构。•虽然不要求建立一个正式的维护机构，但是在开发部门确立一个非正式的维护机构则是非常必要的。16•每个维护要求都通过维护管理员转交给相应的系统管理员去评价（系统管理员是被指定去熟悉一小部分产品程序的技术人员）。•系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。172.维护报告•应该用标准化的格式表达所有软件维护申请（要求）。•维护申请报告或称软件问题报告，由申请维护的用户填写。•用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其它有关材料。•如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。18•维护申请报告将由维护管理员和系统管理员来研究处理。•他们应相应地做出软件修改报告，指明：–所需修改变动的性质；–申请修改的优先级；–为满足某个维护申请报告，所需的工作量–预计修改后的状况.•软件修改报告应提交给变化授权人（修改负责人），经批准后才能开始进一步安排维护工作。193.维护的事件流20•尽管维护申请的类型不同，但都要进行同样的技术工作。–修改软件需求说明–修改软件设计–设计评审–对源程序做必要的修改–单元测试–集成测试(回归测试)–确认测试–软件配置评审等。21在每次软件维护任务完成后进行情况评审，对以下问题做一总结：(1)在目前情况下，设计、编码、测试中的哪一方面可以改进?(2)哪些维护资源应该有但没有?(3)工作中主要的或次要的障碍是什么?(4)从维护申请的类型来看是否应当有预防性维护?情况评审对将来的维护工作如何进行会产生重要的影响。224、维护档案记录①程序标识；②源语句数；③机器指令条数；④使用的程序设计语言；⑤程序安装的日期；⑥自从安装以来程序运行的次数；⑦自从安装以来程序失效的次数；⑧程序变动的层次和标识；⑨因程序变动而增加的源语句数；⑽因程序变动而删除的源语句数；⑾每个改动耗费的人时数；⑿程序改动的日期；⒀软件工程师的名字；⒁维护要求表的标识；⒂维护类型；⒃维护开始和完成的日期；⒄累计用于维护的人时数；⒅与完成的维护相联系的纯效益。235、维护评价•评价维护活动比较困难，因为缺乏可靠的数据。•如果维护的档案记录做得比较好，可以得出一些维护“性能”方面的度量值。(1)每次程序运行平均失效的次数；(2)用于每一类维护活动的总人时数；(3)平均每个程序、每种语言、每种维护类型所做的程序变动数；(4)维护过程中增加或删除一个源语句平均花费的人时数；(5)维护每种语言平均花费的人时数；(6)一张维护要求表的平均周转时间；(7)不同维护类型所占的百分比。•根据对维护工作定量度量的结果，可以做出关于开发技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定，而且可以利用这样的数据去分析评价维护任务。246、程序修改的步骤及修改的副作用•在软件维护时，必然会对源程序进行修改。•通常对源程序的修改不能无计划地仓促上阵，为了正确、有效地修改,需要经历以下三个步骤。•分析和理解程序•修改程序•重新验证程序25分析和理解程序经过分析，全面、准确、迅速地理解程序是决定维护成败和质量好坏的关键。在这方面，软件的可理解性和文档的质量非常重要。理解程序的功能和目标；掌握程序的结构信息，即从程序中细分出若干结构成分。如程序系统结构、控制结构、数据结构和输入／输出结构等；26了解数据流信息，即涉及到的数据来源何处，在哪里被使用；了解控制流信息，即执行每条路径的结果；理解程序的操作(使用)要求；为了容易地理解程序，要求自顶向下地理解现有源程序的程序结构和数据结构，为此可采用如下几种方法：271.分析程序结构图(1)搜集所有存储该程序的文件，阅读这些文件，记下它们包含的过程名，建立一个包括这些过程名和文件名的清单；(2)分析各个过程的源代码，建立一个直接调用矩阵D或调用树。若过程i调用过程j，则D[i][j]＝1，否则D[i][j]＝0。28(3)建立过程的间接调用矩阵I，即直接调用矩阵D的传递闭包I＝D1∪D2∪D3∪…∪Dn其中，n是所包含的过程总数.例如，过程i调用j，j调用k，则D[i][j]＝1，D[j][k]＝1，I[i][k]＝1。(4)分析各个过程的接口，估计更改的复杂性。292.数据跟踪(1)建立各层次的程序级上的接口图，展示各模块或过程的调用方式和接口参数；(2)利用数据流分析方法，对过程内部的一些变量进行跟踪。可获得有关数据在过程间如何传递，在过程内如何处理等信息。对于判断问题原因特别有用。在跟踪的过程中可在源程序中间插入自己的注释。303.控制跟踪控制流跟踪可采用符号执行或实际动态跟踪的方法，了解数据如何从一个输入源到达输出点的。4.充分阅读和使用源程序清单和文档，分析现有文档的合理性。5.充分使用由编译程序或汇编程序提供的交叉引用表、符号表、以及其它有用的信息。6.如有可能，积极参加开发工作。31修改程序对程序的修改，必须事先做出计划，有预谋地、周密有效地实施修改。1.设计程序的修改计划程序的修改计划要考虑人员和资源的安排。小的修改可以不需要详细的计划，而对于需要耗时数月的修改，就需要计划立案。32在编写有关问题解决的方案时，必须充分描述修改作业的规格说明。规格说明信息：数据修改、处理修改、作业控制语言修改、系统之间接口的修改等；维护资源：新程序版本、测试数据、所需软件、计算机时间等；人员；支持：纸面、计算机媒体等。33通常，可采用自顶向下的方法，在理解程序的基础上，(1)研究程序的各个模块、模块的接口、及数据库，从全局的观点，提出修改计划。(2)依次地把要修改的、以及那些受修改影响的模块和数据结构分离出来。为此，要识别受修改影响的数据；识别使用这些数据的程序模块；34对于上面程序模块，按是产生数据、修改数据、还是删除数据进行分类；识别对这些数据元素的外部控制信息；识别编辑和检查这些数据元素的地方；隔离要修改的部分；35(3)详细地分析要修改的、以及那些受变更影响的模块和数据结构的内部细节，设计修改计划，标明新逻辑及要改动的现有逻辑。(4)向用户提供回避措施。用户的某些业务因软件中发生问题而中断，为不让系统长时间停止运行，需把问题局部化，在可能的范围内继续开展业务。可以采取的措施有：36①查找问题原因，可能情况有：意外停机安装的期限到期系统运行中发现错误②如果弄清了问题的原因，可通过临时修改或改变运行控制以回避在系统运行时产生的问题。372.修改代码，以适应变化在修改时，要求：(1)正确、有效地编写修改代码；(2)要谨慎地修改程序，尽量保持程序的风格及格式，要在程序清单上注明改动的指令；(3)不要删除程序语句，除非完全肯定它是无用的；(4)不要试图共用程序中已有的临时变量或工作区，为了避免冲突或混淆用途，应设置自己的变量；38(5)插入错误检测语句；(6)在修改过程中做好修改的详细记录，消除变更中任何有害的副作用（波动效应）；3.修改程序的副作用所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况。副作用有三种：修改代码的副作用、修改数据的副作用、文档的副作用。39在修改源代码时，都可能引入错误。例如，删除或修改一个子程序、删除或修改一个标号、删除或修改一个标识符、改变程序代码的时序关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效率，以及把设计上的改变翻译成代码的改变时，都容