维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。首先必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列。此外，还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。

1．维护组织

虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。每个维护要求都通过维护管理员转交给相应的系统管理员去评价。系统管理员是被指定去熟悉一小部分产品程序的技术人员。系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。

在维护活动之前就明确维护责任是十分必要的，这样做可以大大减少维护过程中可能出现的混乱。

2．维护报告

应该用标准化的格式表达所有软件维护要求。软件维护人员通常给用户提供空白的维护要求表——有时称为软件问题报告表，这个表格由要求一项维护活动的用户填写。如果遇到了一个错误，那么必须完整描述导致出现错误的环境（包括输入数据、全部输出数据以及其他有关信息）。对于适应性或完善性的维护要求，应该提出一个简短的需求说明书。如前所述，由维护管理员和系统管理员评价用户提交的维护要求表。

维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息。

（1）满足维护要求表中提出的要求所需要的工作量。

（2）维护要求的性质。

（3）这项要求的优先次序。

（4）与修改有关的事后数据。

在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。

3．维护的事件流

图7.1描绘了由一项维护要求而引出的一串事件。首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误（改正性维护），而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。

从图7.1描绘的事件流看到，对一项改正性维护要求（图中“错误”通路）的处理，从估量错误的严重程度开始。如果是一个严重的错误（例如，一个关键性的系统不能正常运行），则在系统管理员的指导下分派人员，并且立即开始问题分析过程。如果错误并不严重，那么改正性的维护和其他要求软件开发资源的任务一起统筹安排。

适应性维护和完善性维护的要求沿着相同的事件流通路前进。应该确定每个维护要求的优先次序，并且安排要求的工作时间，就好像它是另一个开发任务一样（从所有意图和目标来看，它都属于开发工作）。如果一项维护要求的优先次序非常高，可能立即开始维护工作。 不管维护类型如何，都需要进行同样的技术工作。这些工作包括修改软件设计、复查、必要的代码修改、单元测试和集成测试（包括使用以前的测试方案的回归测试）、验收测试和复审。不同类型的维护强调的重点不同，但是基本途径是相同的。维护事件流中最后一个事件是复审，它再次检验软件配置的所有成分的有效性，并且保证事实上满足了维护要求表中的要求。

当然，也有并不完全符合上述事件流的维护要求。当发生恶性的软件问题时，就出现所谓的“救火”维护要求，这种情况需要立即把资源用来解决问题。如果对一个组织来说，“救火”是常见的过程，那么必须怀疑它的管理能力和技术能力。

在完成软件维护任务之后，进行处境复查常常是有好处的。一般说来，这种复查试图回答下述问题。

（1）在当前处境下设计、编码或测试的哪些方面能用不同方法进行？

（2）哪些维护资源是应该有而事实上却没有的？

（3）对于这项维护工作什么是主要的（以及次要的）障碍？

（4）要求的维护类型中有预防性维护吗？

处境复查对将来维护工作的进行有重要影响，而且所提供的反馈信息对有效地管理软件组织十分重要。

4．保存维护记录

对于软件生命周期的所有阶段而言，以前记录保存都是不充分的，而软件维护则根本没有记录保存下来。由于这个原因，往往不能估价维护技术的有效性，不能确定一个产品程序的“优良”程度，而且很难确定维护的实际代价是什么。

保存维护记录遇到的第一个问题就是，哪些数据是值得记录的？Swanson提出了下述内容：（1）程序标识；（2）源语句数；（3）机器指令条数；（4）使用的程序设计语言（5）程序安装的日期；（6）自从安装以来程序运行的次数；（7）自从安装以来程序失效的次数；（8）程序变动的层次和标识；（9）因程序变动而增加的源语句数；（10）因程序变动而删除的源语句数；（11）每个改动耗费的人时数；（12）程序改动的日期；（13）软件工程师的名字；（14）维护要求表的标识；（15）维护类型；（16）维护开始和完成的日期；（17）累计用于维护的人时数；（18）与完成的维护相联系的纯效益。

应该为每项维护工作都收集上述数据。可以利用这些数据构成个维护数据库的基础，并且像下面介绍的那样对它们进行评价。

5．评价维护活动

缺乏有效的数据就无法评价维护活动。如果已经开始保存维护记录了，则可以对维护工作做一些定量度量。至少可以从下述7个方面度量维护工作。

（1）每次程序运行平均失效的次数。

（2）用于每一类维护活动的总人时数。

（3）平均每个程序、每种语言、每种维护类型所做的程序变动数。

（4）维护过程中增加或删除一个源语句平均花费的人时数。

（5）维护每种语言平均花费的人时数。

（6）一张维护要求表的平均周转时间。

（7）不同维护类型所占的百分比。

根据对维护工作定量度量的结果，可以做出关于开发技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定，而且可以利用这样的数据去分析评价维护任务。