软件工程-第6章第3节

6.3软件维护的实施6.3.1维护的组织1.临时维护小组

临时维护小组是非正式的机构，它执行一些特殊的或临时的维护任务。例如，对程序排错的检查，检查完善性维护的设计和进行质量控制的复审等。临时维护小组采用“同事复审”或“同行复审”等方法来提高维护工作的效率。6.3.1维护的组织2.长期维护小组对长期运行的复杂系统需要一个稳定的维护小组。维护小组由以下成员组成。1)组长维护小组组长是该小组的技术负责人，负责向上级主管部门报告维护工作。组长应是一个有经验的系统分析员，具有一定的管理经验，熟悉系统的应用领域。6.3.1维护的组织2)副组长

副组长是组长的助手。在组长缺席时完成组长的工作，具有与组长相同的业务水平和工作经验。副组长还执行同开发部门或其他维护小组联系的任务。在系统开发阶段，收集与维护有关的信息；在维护阶段，他同开发者继续保持联系，向他们传送程序运行的反馈信息。因为大部分维护要求是由用户提出的，所以副组长同用户保持密切联系也是非常重要的。3)维护负责人

维护负责人是维护小组的行政负责人。他通常管理几个维护小组的人事工作，负责维护小组成员的人事管理工作。4)维护程序员

维护程序员负责分析程序改变的要求和执行修改工作。维护程序员不仅具有软件开发方面的知识和经验，也应具有软件维护方面的知识和经验，还应熟悉程序应用领域的知识。6.3.1维护的组织6.3.2维护的流程软件维护的流程如下：(1)制定维护申请报告。(2)审查申请报告并批准。(3)进行维护并做详细记录。(4)复审。6.3.2维护的流程1.制定维护申请报告

所有软件维护申请报告应按规定的方式提出。该报告也称为软件问题报告。它是维护阶段的一种文档，由申请维护的用户填写。当遇到一个错误时，用户必须完整地说明错误产生的情况，包括输入数据、错误清单、源程序清单以及其他有关材料，即导致该错误的环境的完整描述。对于适应性或完善性的维护要求，要提交一份简要的维护规格说明。6.3.2维护的流程

维护申请报告是一种由用户产生的文档，是用作计划维护任务的基础。在软件维护组织内部还要制定一份软件修改报告，该报告是维护阶段的另一种文档，用来指出：(1)为满足软件问题报告实际要求的工作量。(2)要求修改的性质。(3)请求修改的优先权。(4)关于修改的事后数据。6.3.2维护的流程2.维护过程

一个维护申请提出之后，经评审需要维护的，则按下列过程实施维护：(1)首先确定要进行维护的类型。有许多情况，用户可以把一个请求看作校正性维护，而软件开发者可以把这个请求看作适应性或完善性维护，此时，对不同观点就要协商解决。(2)对校正性维护从评价错误的严重性开始。如果存在一个严重的错误，例如一个系统的重要功能不能执行，则由管理者组织有关人员立即开始分析问题。如果错误并不严重，则校正性维护与软件其他任务一起进行，统一安排，按计划进行维护工作。甚至会有这样一种情况，申请是错误的。因此经审查后发现并不需要修改软件。6.3.2维护的流程(3)对适应性和完善性进行维护。如同它是另一个开发工作一样，建立每个请求的优先权，安排所要求的工作。若设置一个极高的优先权，当然也就意味着要立即开始此项维护工作了。(4)实施维护任务。不管维护类型如何，大体上要开展相同的技术工作。这些工作包括修改软件设计、必要的代码修改、单元测试、集成测试、确认测试以及复审，每种维护类型的侧重点不一样。6.3.2维护的流程(5)“救火”维护。实际中存在着并不完全适合上面所述的经过仔细考虑的维护申请，这时申请的维护称为“救火”维护，在发生重大的软件问题时，就会出现这种情况。例如，一个造纸厂的流程控制系统出现一个使压出的纸越出建筑物的故障，这时要立即组织有关人员去“救火”，必须立即解决问题。显然，如果一个软件开发机构经常“救火”，就必须要认真检查一下该机构的管理和技术存在什么重大问题。6.3.2维护的流程3.维护的复审在维护任务完成后，要对维护任务进行复审。进行复审时要回答下列问题：(1)给出当前情况，即设计、代码和测试的哪些方面已经完成？(2)各种维护资源已经用了哪些？还有哪些未用？(3)对于这个工作，主要的、次要的障碍是什么？(4)复审对维护工作能否顺利进行有重大影响，对一个软件机构来说也是有效的管理工作的一部分。6.3.3维护技术1.面向维护的技术面向维护的技术涉及软件开发的所有阶段。在需求分析阶段，对用户的需求进行严格的分析定义，使之没有矛盾和易于理解，可以减少软件中的错误。例如美国密执安大学的ISDOS系统就是需求分析阶段使用的一种分析与文档化工具，可以用它来检查需求说明书的一致性和完备性。在设计阶段，划分模块时应充分考虑将来改动或扩充的可能性。使用结构化分析和结构化设计方法，采用容易变更的、不依赖于特定硬件和特定操作系统的设计。在编码阶段，采用灵活的数据结构，使程序相对独立于数据的物理结构，养成良好的程序设计风格。在测试阶段，尽可能多地发现错误，保存测试用例和测试数据等。6.3.3维护技术2.维护支援技术维护支援技术包括下列各方面的内容：(1)信息收集。(2)错误原因分析。(3)软件分析与理解。(4)维护方案评价。(5)代码与文档修改。(6)修改后的确认。(7)远距离的维护。6.3.4维护的副作用维护的目的是为了延长软件的寿命并让其创造更多的价值，经过一段时间的维护，软件中的错误减少了，功能增强了。但修改软件是危险的，每修改一次，潜伏的错误就可能增加一份。这种因修改软件而造成的错误或其他不希望出现的情况称为维护的副作用。维护的副作用有编码副作用、数据副作用和文档副作用三种。6.3.4维护的副作用1.编码副作用在使用程序设计语言修改源代码时可能引入如下错误：(1)删除或修改一个子程序、一个标号和一个标识符。(2)改变程序代码的时序关系，改变占用存储的大小，改变逻辑运算符。(3)修改文件的打开或关闭。(4)改进程序的执行效率。(5)把设计上的改变翻译成代码的改变。(6)为边界条件的逻辑测试做出改变。6.3.4维护的副作用2.数据副作用在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件错误。数据副作用是修改软件信息结构导致的结果,有以下几种：(1)重新定义局部或全局的常量，重新定义记录或文件格式。(2)增加或减少一个数组或高层数据结构的大小。(3)修改全局或公共数据。(4)重新初始化控制标志或指针。(5)重新排列输入/输出或子程序的参数。6.3.4维护的副作用3.文档副作用对数据流、软件结构、模块逻辑或任何其他有关特性进行修改时，必须对相关技术文档进行相应修改。否则会导致文档与程序功能不匹配、缺省条件改变和新错误信息不正确等错误，使文档不能反映软件当前的状态。如果对可执行软件的修改没有反映在文档中，就会产生如下文档副作用：6.3.4维护的副作用(1)修改交互输入的顺序或格式没有正确地记入文档中。(2)过时的文档内容、索引和文本可能造成冲突等。因此，