下载掌阅APP，畅读海量书库
立即打开
2.4 软件维护
软件正式交付用户以后，即进入漫长的维护期。在这一阶段，基本任务是保证软件在这段相当长的时期内能够正常运行。软件维护需要的工作量很大，随着时间的推移，软件维护对开发商带来的成本压力也越来越大。现在许多软件开发商要把70%的工作量用在维护已有的软件上。平均来说，大型软件的维护成本高达开发成本的4倍左右。
软件的维护活动是基于软件是可维护的这一前提，软件的可维护性考虑应该贯穿于软件开发的各个阶段。
原则上，任何人造系统，都是可维护的。可见的实体，如桌椅板凳、车子、房子、计算机等，因为我们知道如何组装它们，知道它们的结构，所以可以维护。软件虽然是不可见的，我们在开发的时候，是非常清楚它们是如何组成的，如何活动的，不管是多么复杂的软件，开发者同样了解它，可以维护它。
依据软件本身的特点，软件具有可维护性主要由以下三个因素决定：
（1）可理解性。 软件通常是沿着“子系统—模块—功能—内部处理过程”这样的思路逐步细化的，软件维护人员通过了解同样的思路，可以理解软件。
（2）可测试性。 借助人工的经验或者先进的测试工具，维护人员可以对运行的软件进行测试，找出问题所在。
（3）可修改性。 任何软件都是通过某种开发工具来完成的，都有源码，运用同样的工具，维护人员可以对现有软件进行修改、编译，使之重新运行起来。
软件危机从某种意义上可以看成是软件维护的危机，由此诞生的软件工程也可以看成是提高软件可维护性的工程。软件工程的采用，使得软件开发过程进一步规范，强制性产生了一系列的文档，因为这些文档从各个阶段、各个方面对软件结构、原理加以说明，极大地丰富了维护所需的资源，增加了软件的可维护性。所以，对于维护人员来说文档比程序源码更为重要。
软件系统的文档可分为用户文档和系统文档两大类。
用户文档主要是描述软件功能和使用方法。至少应包括以下几个方面。
（1）功能说明：说明系统能做什么。
（2）安装文档：说明系统安装过程及所需软硬件配置。
（3）用户使用手册：通过详尽的例子向终端用户介绍如何使用这个系统。
（4）参考手册：从技术的角度对系统进行形式化的描述。
（5）管理员指南：说明系统管理人员如何处理使用中出现的各种情况。
系统文档则关心实现细节，描述系统需求、设计、实现和测试等各个方面。
软件开发过程中的绝大多数文档都属于系统文档，如需求分析报告、系统设计报告、源码、测试计划等。
随着软件规模的不断增大，维护活动耗费的成本急剧攀升，甚至有人预言，假如再不重视软件的可维护性，总有一天，开发商将不得不投入所有的资源进行软件维护，而无力开发新的软件。这虽然有些危言耸听，但在需求分析、设计、编码各阶段加入灵活应变因素的做法还是得到越来越多的开发者的认可，如此一来，既可以降低维护难度，从而降低维护成本，又可以提高软件的可维护性。
要在开发过程中提高软件的可维护性，必须从如何使软件易于理解、易于测试、易于修改出发进行考虑。具体如下：
我们从软件的内部和外部两个方面来度量可维护性。
在软件外部，可以用平均修复时间（Mean Time To Repair，MTTR）来度量软件的可维护性，它是指处理一个有错误的软件组件需要花费的平均时间。如果我们用 M 表示可维护指标，那么
M = 1/(1+MTTR)
为此，我们需要每一个问题详细记录以下信息：
在软件内部，可以通过度量软件的复杂性来间接度量可维护性。与软件复杂性相关的因素有以下几个方面。
（1）环路数。 这是McCabe于1976年提出的。环路数可以反映源代码结构的复杂度。环路数的计算过程是：分析源码，绘制出等效的控制流图；运用图论的知识计算出控制流图的线性无关路径数，用这个数度量和比较复杂程度。通过观察环路数的增长幅度，我们可以比较多种维护方案的优劣，选择出对环路数影响最小的作为最优的方案。
（2）软件规模。 通常，可以认为软件包含的组件越多，软件就越复杂，可维护性就越差；
（3）其他因素。 包括嵌套深度、系统用户数等。
对于软件内部的可维护性，迄今还没有一个突出的、全面的、通用的模型，需要结合不同开发组织自身的经验，建立合适的经验模型。一般情况下，可以按如下步骤建立经验模型：
这个模型最常用的是其比较特性，也就是说，可以据此对问题的维护难度进行排序。
软件的维护从性质上分为：纠错型维护、适应型维护、预防型和完善型维护。
尽管经过严格的测试，但并不能保证软件中彻底没有错误，随着运行时间的延续，数据量的积累，各种应用环境的变化，错误仍会顽固地暴露出来，此时就要进行纠错型维护。
伴随着计算机硬件的新产品、操作系统的新版本的不断推出，正在运行的软件必须进行适应型维护。
用户逐渐熟悉软件以后，会提出一些改进需求，为了满足这些需求，必须进行完善型维护，这样的维护几乎占到维护工作量的一半以上。比如，打印格式的调整、统计口径的增加、业务流程的完善等。
以上三种维护都是用户驱动的，用户是维护需求的提出者，而开发商“为了明天的需要，把今天的方法应用到昨天的系统中”，目的是为了使旧系统焕发新活力，这样的维护是预防型维护，这种维护所占的比例很小，因为它耗资巨大。
Lientz和Swanson调查发现（1980年），完善性维护约占50%，适应性维护约占25%，纠错性维护约占21%，其他维护只占4%。这个调查已是二十几年前的事了，具体的比例数我们不必深究，现在的情况并没有多大变化。
维护活动可以分成生产类（比如，确认维护需求、设计、编码、测试、培训等）和非生产类（比如，熟悉原有软件的代码，理解原有软件的结构等）。
维护工作量可以用这样一个模型表示：
其中： M 是维护用的总工作量， P 是生产类活动的工作量， K 是经验常数， c 是软件的复杂程度， d 是维护人员对软件的熟悉程度。
对于一次具体的维护，确认需求和设计的工作量与问题的难易程度和大小有关，相对来说，工作量比较稳定。编码工作则与软件本身的质量有很大的关系，如果原来的编码格式混乱，注释不清，就会使生产类活动的工作量 P 增大；在软件的复杂度 c 一定的前提下，维护人员对软件的熟悉程度 d 越低，则维护工作量呈指数规律增加；同样，如果由于开发混乱，导致软件复杂度 c 增加，从而使维护人员理解软件的难度增加，对软件的熟悉程度 d 也降低，那么维护工作量会以更快的速度上升。
除了原有软件本身的质量（包括设计质量、代码质量、文档质量和测试质量）对维护工作量有影响外，还有如下一些因素也会影响到维护工作量：
（1）维护工作本身是否规范，是否按软件工程的正确方法进行，对后续的维护工作量的影响同样不可忽视。 如果维护工作不规范，代码修改与文档修改不同步，会导致维护后的软件更加复杂，更加难以理解，难以熟悉，维护工作量也会以指数速度增加。
（2）软件系统的类型不同，维护工作量也有区别。 通常，一个系统越依赖于真实世界，就越可能发生变化，也就需要更大的维护工作量。按照对真实世界的依赖程度，软件系统可以分为：抽象系统、近似系统和模拟系统。抽象系统描述的问题具有形式化的精确定义，比如涉及标准数值计算方法的计算软件；近似系统是对于真实世界的一个简化的近似方案的描述，比如围棋软件，虽然围棋的规则是精确的，但由于由此衍生的走步方案和对弈模拟则几乎是无穷尽的，因此一般的设计都有计算深度的限定；模拟系统则包括广泛的行业应用软件，系统本身就承担着全部或部分业务，是嵌入真实世界中运行的，比如管理信息系统、ERP系统、计费系统等。因此可见，抽象系统的维护工作量最小，模拟系统的维护工作量最大。
（3）硬件因素。 不可靠的硬件系统会使软件系统产生一些令人恼火的随机性的问题，使追踪问题的根源变得更加困难。
上面所讲的都是客观因素，还有维护人员本身的因素，基本上在软件开发队伍中，维护被认为是出力不讨好的工作，维护人员作为软件企业中长期面对用户的角色，经常得承担来自其他开发人员和用户的双重压力，情绪低落，热情不高；同时部分软件企业对维护不够重视，认为维护是个无底洞，因而在人力和成本的投入上采取敷衍的态度，安排进行维护的人员大多是技术不够扎实的员工，甚至把维护作为培训新员工的渠道，导致维护人员技术素质一般，又缺乏热情，维护工作量岂有不大之理。
好在这种局面正在改观，随着软件企业的数量的激增，导致竞争加剧，在某些领域甚至到了白热化的程度，巩固已有的客户，开发已有的客户，从已有的客户身上寻找新的商机变得越来越重要，维护人员作为服务的窗口，逐渐被重视，因为只有维护做好了，才能巩固已有客户。
不管是哪种类型的维护，都需要类似开发的过程，本质上说，维护过程是修改和压缩了的开发过程。
有实力的软件企业应该建立专业的维护部门，对大多数的中小软件企业，虽然没有专门的维护组织，但非正式的明确责任却是非常必要的，需要指定维护负责人，组建临时的维护小组，明确维护流程及各人的职责，可以专设维护配置员，也可由维护负责人兼任。如果同时有多个系统需要维护，可再设维护管理员，监督协调各维护小组，结构大致如图2-24所示。
对于大型软件系统的维护，设置维护管理员是非常必要的，由其协调和同步各维护小组的工作。
图2-24 维护的组织结构
维护配置员则对维护活动需要的资源，以及维护过程中产生的各种文档进行标志和配置。由于维护必然会带来变动，因此需要维护配置员至少做好如下的变动控制：
维护需求通常由用户提出，维护人员应该给用户提供空白的软件问题报告，并用具体的例子向用户说明如何记录碰到的软件问题，以便规范用户完整描述其维护需求。
软件问题报告通常包括如下内容：
用户把填好的软件问题报告提交给维护管理员，维护管理员再根据各维护小组的分工，把软件问题报告转给相应的维护小组，由其负责人组织实施维护作业，同时由维护配置员进行维护资源配置管理。
如果同时有多个维护需求，维护管理员则应根据对用户的影响程度，首先确定维护的优先顺序，再依次安排维护活动。
每一次维护活动的实施都要经历如下的步骤：
维护作业中各阶段的参与人及其活动如图2-25所示。
图2-25描述的是一个符合软件工程思想和规范的维护流程。其中，维护计划包括维护的人员、时间安排、维护需求描述、维护设计及相关测试文档。另外，制订维护风险控制计划对保证维护按时保质的完成非常重要。
虽然维护所带来的副作用是客观存在的，不可能完全消除。但这样的工作流程可以大幅降低因管理因素产生的维护副作用（例如，因为配置混乱造成的文档更新不及时等），保证每一次维护活动都有据可查。
完善的维护设计文档，可以有效降低因修改数据结构带来的副作用，保证与该数据结构有关的代码段的修改不被遗漏。
回归测试则可以有效地查明修改程序代码对原有软件的影响。
当然，并非所有的维护活动都得完全按照上述流程进行。例如，如果需要维护的软件系统是支撑客户核心业务的系统，必须7×24小时运行，这样的系统一旦发生恶性软件问题（比如数据库崩溃等）时，维护组织就会以“救火队”的方式迅速展开维护，没有时间进行计划评审，此时软件开发商应派出技术过硬的维护小组，最大限度地降低风险。
图2-25 维护作业实施
在维护活动中需要及时记录维护的有关信息，用以考查维护技术的有效性，估计软件的“优良”程度，确定维护的实际代价，同时这些记录将作为后续评价活动的依据。
那么需要记录哪些信息呢？Swanson提出了信息内容，主要如下：
对于每项维护工作，都要收集上述数据，而且可以基于这些数据建立起维护数据库。
借助于维护记录，可以对维护工作做一些定量的统计。通常从以下几个方面进行度量：
度量的结果可以作为以后调整维护工作的参考，对于合理规划维护工作量、优化资源分配、有针对性地强化对参与某类维护的人员的技术培训等方面可以起到积极的作用。
软件的再生工程在软件开发现状中应用得很多，比如“单机版”改造为“网络版”、“客户-服务器模式（C/S）”改造为“浏览器-服务器模式（B/S）”、“非结构化”改造为“结构化”、“组件化改造”等软件行为，这些行为有的是全部再生，有的是局部再生。对于很久以前开发的软件，由于“未采用软件工程思想”等各种原因，导致文档缺失，甚至只剩下能运行的软件系统，这种情况大多考虑进行局部再生；对于近期采用软件工程思想开发的软件，由于文档相对齐全，则可以进行全部再生。
通常，软件的再生工程包括以下六类活动（可根据具体情况取舍）。
这是局部再生工程中首先要进行的活动，需要选出现有的软件系统中需要进行再生的模块，通常应该着重对以下三类模块进行考查：
（1）确定将使用多年的；
（2）正在成功运行的；
（3）近期将做重大变更的。
对于早期的软件，这项活动非常耗费精力，应分轻重缓急分别对待：
（1）对于相对稳定的程序，暂且使其保持现状；
（2）对于当前正在修改的部分建立完整的文档，其他部分则在使用中逐步建立文档；
（3）对于支撑用户核心业务的程序，必须建立完整的文档，但也最好想方设法地降低建立文档的工作量。
软件的逆向工程就是指分析一个程序的过程，最大程度地建立比源码更抽象的高级表达，它也是一个恢复设计结果的过程。逆向工程工具可以从现有的软件代码中抽取有关的数据、体系结构和处理过程的设计信息。
这是最常见的再生工程活动。首先用重构工具分析源码，标出非结构化的部分，然后自动重构问题代码，经过复审和测试生成最终的重构代码，同时更新有关文档。
指重构数据结构。这是一项全范围的活动。首先进行逆向工程，分解出当前的数据结构，再进行重构。数据结构是软件的基础信息，对其进行重构必然会导致代码重构。
基于上面几个活动的结果，应用软件工程的原理、概念、技术和方法重新开发现有系统。