7.3.3　记录维护流程

对于一项维护流程来说，首先应确认维护要求。这要求维护人员与用户反复的协商，找出错误的情况和对于业务影响的大小，以及用户想要做什么更改，并将这些内容放入问题数据库，然后要求确定将要执行的维护工作的类型。在大多数情况下，用户将维护请求视为软件错误的症状，而开发人员则将此维护请求视为自适应维护或细化维护。如果有意见分歧，需要通过商量解决。

软件维护工作从评估错误的严重程度开始。如果有一个关键的特性无法操作，应该在系统管理员的指导下分配处理这样错误的人员，立即开始分析问题。对于不严重的纠正错误，需要与其他需要软件开发资源的任务一起工作，以统一的方式安排。

在某些情况下，有些错误非常严重，以至于不得不暂时放弃正常的维护过程，即不评估修改可能产生的副作用，也不相应更新文档，并立即修改代码。这是一种只在非常关键的情况下使用的灭火矫正维护。此维护只占所有维护的一小部分。应说明的是，这种维护不是取消，而是对维护所需控制和评估的拖延。一旦危机消除了，这些控制和评估活动必须继续确保当前的维护不会增加更严重的问题。

对于维护应用程序，所需的工作如图7.2所示。(https://www.daowen.com)

图7.2　维护阶段的事件流

如果要进行适应性维护和完善性维护申请则需要采取不一样的路线。在适应性维护方面，先对维护申请和优先次序做出评价，然后在维护活动中排出位置。完善性维护方面，也是需要做出评价的。考虑到商业策略、当今以及今后软件产品等因素，不是所有的完善维护都会被接受。已经可以接受的完善性维护依然需要在维护队列中确定他们的位置。确认了维护申请的优先次序后，就要安排符合他需要的工作。对于优先级高的申请维护应该尽快着手工作。