2.6 软件维护

软件维护是软件生存周期中非常重要的一个阶段。但是它的重要性往往被人们忽视。有人把维护比喻为一座冰山，显露出来的部分不多，大量的问题都是隐藏的。平均而言，大型软件的维护成本是开发成本的4倍左右。国外许多软件开发组织把60%以上的人力用于维护已投入运行的软件。这个比例随着软件数量增多和使用寿命延长，还在继续上升。学习软件工程学的主要目的之一就是研究如何减少软件维护的工作量，降低维护成本。
1．软件维护概述
投入运行的软件需要变更的原因很多，但主要原因有：
① 软件的原有功能和性能可能不再适应用户的要求；
② 软件的工作环境改变了（例如，增加了新的外部设备等），软件也要做相应的变更；
③ 软件运行中发现错误，需要修改。
由于这些原因而引发的维护活动可以归纳为4种类型，如图10-25所示。
（1）校正性维护。把诊断、校正软件错误的过程称之为校正性维护。
（2）适应性维护。由于计算机技术的发展，外部设备和其他系统元素经常变更，为适应环境的变更而修改软件的活动称之为适应性维护。
（3）完善性维护。在使用系统过程中为满足用户提出的新功能、性能要求而进行的维护。
（4）预防性维护。为进一步改进可维护性、可靠性而进行的维护活动。
2. 维护的特点
软件维护的特点表现为：
（1）结构化维护和非结构化维护的特性
非结构化维护。用手工方式开发的软件，只有源代码，这种软件的维护是一种非结构化维护。非结构化维护是从读代码开始，由于缺少必要的文档资料，所以很难搞清软件结构、全程数据结构、系统接口等系统内部的内涵；因为缺少原始资料的可比性，很难估量对源代码所做修改的后果；因为没有测试记录，不能进行回归测试。
结构化维护。用工程化方法开发的软件有一个完整的软件配置。维护活动是从评价设计文档开始，确定该软件的主要结构性能；估量所要求的变更的影响及可能的结果；确定实施计划和方案；修改原设计；进行复审；开发新的代码；用测试说明书进行回归测试；最后修改软件配置，再次发布该软件的新版本。
（2）维护的代价
在过去的几十年中，软件维护费用逐步上升。70年代用于维护软件的费用只占软件总预算的35%～40%，80年代上升为40%～60%，到了90年代则上升为70%～80%。
软件维护的代价包括有形和无形两个部分：有形代价就是上面所提到的那些统计数字；无形代价包括：
l 当看起来合理的有关变更要求不能及时满足时，引起用户的不满；
l 由于维护时的改动，在软件中引入潜在的故障，从而降低了软件的质量；
l 当必须把软件开发工程师调去从事维护工作时，对开发工作造成的影响。
3．维护问题
软件维护的绝大多数问题与软件定义和软件开发阶段所采用的设计方法、指导思想、技术手段、开发工具等有直接的关系，同时与维护工作的性质也有一定的关系。
主要问题是：
（1）理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有源代码而没有相关的文档，问题会更加严重。
（2）严格按规范化方法开发的软件系统一般不需要大的维护活动，而需要维护的软件系统却往往因为没有必需的文档或文档残缺不全，使得维护活动进展非常艰难。
（3）当需要对软件进行维护时，很难指望熟悉软件系统的原开发人员能全力以赴地亲临现场参与维护活动。
（4）绝大多数软件在设计时没有考虑将来的修改。
（5）软件维护不是一项吸引人的工作。最出色的、成功的维护也只不过是保证他人开发的系统能正常运行，而且维护别人开发的软件经常受挫，使得维护人员无成就感。
软件维护有以下主要任务：
1．维护组织机构
对于大型软件系统，建立一个专门的维护组织机构是必需的。即使是对较小的软件系统，也要委派一个专人负责软件维护工作，特别是收集、保存、整理维护活动的文档资料的工作是必须随时要做的。
在维护活动开始之前必须明确维护活动的审批制度。每个维护要求都要通过维护管理员转交给系统管理员去评价。系统管理员对维护申请做出评价后，由主管部门（人）决定是否进行软件修改。接到审批的维护申请报告后，将维护任务下达给指定的维护人员，并监控维护活动有条不紊地开展。合理的组织机构和精干的维护人员是保障维护活动顺利实施的基础。
2．维护报告
任何维护申请都应该按规范化的方式提出。通常要求用户填写维护申请表。表中必须完整地描述每个错误发生的环境，包括：输入数据、输出结果等有关信息。对于适应性或完善性的维护要求，还应该提出一份修改说明书，提出用户希望的修改。维护申请表交维护组织后，经有关人员认真分析，并根据分析结果制定软件修改报告，内容应包括：
（1）维护要求的性质；
（2）维护活动的优先顺序；
（3）计算满足维护申请表中提出的软件变更所需要的工作量；
（4）预计软件变更后的状况。
软件修改报告确定后交软件开发组织审批，经批准后交由维护组织（人）具体实施。
3．维护过程
维护活动必须按维护工作流程有序地进行。维护工作流程为：
（1）首先确定维护申请表中提出问题的类型。
（2）对每一项修改型的维护要求都要从评价错误的严重程度开始。如果是一个严重性错误，则应在系统管理员指导下分派人员，立即开始分析问题。如果错误不严重，则与其他需要软件资源开发的任务一起，统一安排进行。
（3）对突发性的软件错误，要立即进行处理，即所谓"救火"式维护。但错误造成的危机一旦消除后，应立即补充完成对维护所需要的控制和评价（软件配置、文档资料的修改，维护副作用及其影响等），以确保当前的维护活动至少不会增加或隐藏错误问题。
（4）适应性维护和改善性维护的申请工作路径大致相同；对于完善性维护，出于商业策略和市场等因素的考虑，可能会否决部分申请要求，但必须对用户进行解释。完善性维护也要分类、定位，并和其他开发工作一样，统一安排资源、统一分派人员实施。
（5）不论哪一类维护活动，都要进行下述工作：
① 修改软件设计；
② 评审修改方案；
③ 进行必要的代码修改；
④ 单元测试、组装测试（使用以前测试用例的回归测试）、确认测试；
⑤ 复审，确保维护活动真正满足软件修改报告中的要求。
4．维护记录
维护记录做的好坏与否对软件配置的更改、软件质量的控制、确定维护活动的实际开销都有直接的关系。维护记录一般认为应包含下列内容：
（1） 程序表示、源代码数、机器代码数、使用的程序设计语言；
（2） 程序安装日期、安装以来运行的次数、安装以来出故障的次数；
（3） 程序修改日期、变动的层次和标识；
（4） 由于程序修改而增加的源代码数、由于程序修改而删去的源代码数；
（5）每项修改所需要的人时数、软件工程师的名字、用于维护所需人时的累计数；
（6）维护要求表的标识、维护类型、维护开始和结束日期；
（7）与所完成维护有关的效益。
对每项维护活动都应该收集上述数据。可以利用这些数据构成一个维护数据库，进而对维护活动进行更进一步的评价。
5．维护评价
缺少可靠的数据，就无法评价维护活动。但如果从维护活动一开始就记录并保存维护数据，就可以对维护工作做一些定量的度量。可参考的度量值为：
（1） 每次程序运行时的平均出错次数；用于每种语言的平均"人时"数；
（1） 花费在每类维护上的总"人时"数；不同维护类型所占的百分比；
（2） 每个程序、每种语言、每种维护类型的程序平均修改次数；
（3） 因为维护，增加或删除每个源程序语句所花费的平均"人时"数；
（4） 维护申请报告的平均处理时间。
上述度量值提供了定量的数据，根据这些数据就可以对开发技术、语言选择、维护工作计划、资源分配等问题做出判定。
修改软件是有副作用的；每修改一次，都可能增加潜在的错误。
维护的副作用是指：由于修改而导致的错误或其他多余动作的发生。
Freedman和Weinberg 提出以下三类主要副作用：
1．修改代码的副作用
仅仅修改一个简单语句，就有可能遭致灾难性的结局，这种教训历史上曾多次发生。修改容易引发错误，与一般性语句的修改可能引发错误相比，下述修改更容易引发错误：
（1）删除或修改一个子程序；
（2）删除或改变一个语句标号；删除或改变一个标识符；
（3）为改进执行性能所做的修改；把设计修改翻译成主代码的修改；
（4）改变文件的打开或关闭；改变逻辑运算符；
（5）对边界条件的逻辑测试所做的修改。
对于修改代码的副作用，一般可用回归测试对其进行查明和更正。
2．修改数据的副作用
修改数据的副作用经常发生在下述一些修改中：
（1）重新定义局部和全程常量；重新定义记录或文件格式；
（2）增大或减小一个数组或高阶数据结构的大小；修改全程数据；
（3）重新初始化控制标记或指针；
（4）重新排列I／O或子程序的自变量。
对于数据修改的副作用可通过完善的设计文档加以限制。通常在设计文档中建立有数据元素、记录、文件和其他结构与软件模块联系起来的交叉对照表。修改数据后，也同时按交叉对照表修改文档中有关部分内容，以保证软件配置与实际修改的一致性。
3、修改文档的副作用
文档是影响软件可维护性的决定性因素。维护应该针对整个软件配置，而不只是修改源代码。如果对源代码的修改没有反映在设计文档或用户手册中，就会发生文档的副作用。每当发生修改时，必须立即更新相应的技术文档。不能准确反映软件的当前状态的文档可能比完全没有文档更坏。做任何更改后，对整个软件配置进行评审可以减少文档的副作用。