l第8章软件维护.pptVIP

第八章  软 件 维 护 改正性维护 --- Corrective Maintenance 在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。 这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。 为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，所进行的诊断和改正错误的过程就叫做改正性维护。 8.2 软件维护的特点 -- 影响维护工作量的因素 在软件的维护过程中，需要花费大量的工作量，从而直接影响了软件维护的成本。 应当考虑有哪些因素影响软件维护的工作量，相应应该采取什么维护策略，才能有效地维护软件并控制维护的成本。 系统大小：系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。因而需要更多的维护工作量。 程序设计语言：使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。 先进的软件开发技术：在软件开发时，若使用能使软件结构比较稳定的分析与设计技术，及程序设计技术，如面向对象技术、复用技术等，可减少大量的工作量。 其它： 应用的类型 数学模型 任务的难度 开关与标记、IF嵌套深度、索引或下标数等 对维护工作量都有影响。 许多软件在开发时并未考虑将来的修改，为软件的维护带来许多问题。 8.2.3 维护中的典型问题 (1) 难以跟踪软件版本的进化过程,软件的变化未在文档中反映出来. (2) 难以跟踪软件的创建过程. (3) 难以读懂他人程序. (4) 无文档或不全. (5) 软件人员流动性大. (6) 设计时未考虑修改需要,修改困难. 维护工作无吸引力,缺乏成就感. 采用软件工程方法至少可部分地解决与维护有关的每一个问题。 8.3 软件维护过程 维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。 为了有效地进行软件维护，应事先就开始做组织工作。 首先建立维护的机构 申明提出维护申请报告的过程及评价的过程 为每一个维护申请规定标准的处理步骤 建立维护活动的记录保管，并规定复审的标准 每个维护要求都通过维护管理员转交给相应的系统管理员去评价（系统管理员是被指定去熟悉一小部分产品程序的技术人员）。 系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。 2. 维护报告 应该用标准化的格式表达所有软件维护申请（要求）。 维护申请报告或称软件问题报告，由申请维护的用户填写。 用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其它有关材料。 如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。 维护申请报告将由维护管理员和系统管理员来研究处理。 他们应相应地做出软件修改报告，指明： 维护要求的性质； 这项要求的优先次序； 为满足某个维护申请报告，所需的工作量 与修改有关的事后数据. 软件修改报告应提交给变化授权人（修改负责人）审查批准，经批准后才能开始进一步安排维护工作。 3. 维护的事件流 尽管维护申请的类型不同，但都要进行同样的技术工作。 修改软件需求说明 修改软件设计 设计评审 对源程序做必要的修改 单元测试 集成测试( 回归测试) 确认测试 软件配置评审等。 在每次软件维护任务完成后进行处境复查，处境复查试图回答下述问题：(1) 在目前情况下，设计、编码、测试中的哪一方面可以改进?(2) 哪些维护资源应该有但没有?(3) 对于这项维护工作什么是主要的或次要的障碍?(4) 要求的维护类型中有预防性维护吗?处境评审对将来的维护工作如何进行会产生重要的影响。 4、保存维护记录 便于评价产品及维护代价 5、评价维护活动 评价维护活动比较困难，因为缺乏可靠的数据。 如果维护的档案记录做得比较好，可以得出一些维护“性能”方面的定量的度量值。 (1) 每次程序运行平均失效的次数； (2) 用于每一类维护活动的总人时数； (3) 平均每个程序、每种语言、每种维护类型所做的程序变动数； (4) 维护过程中增加或删除一个源语句平均花费的人时数； (5) 维护每种语言平均花费的人时数； (6) 一张维护要求表的平均周转时间； (7) 不同维护类型所占的百分比。 根据对维护工作定量度量的结果，可以做出关于开发技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定，而且可以利用这样的数据去分析评价维护任务。 6、程序修改的步骤及修改的副作用 在软件维护时，必然会对源程序进行修改。 通常对源程序的修改不能无计划地仓