所有软件维护的申请都应该采用标准的形式提出。软件开发人员应填写维护申请表（Maintenance Request Form，MRF），也称软件问题报告（Software Problem Report，SPR），它由用户根据维护活动的要求来完成。如果遇到错误，要对产生错误的环境进行完整的描述，其中必须包括输入数据、源程序列表及其他支持材料。对适应性或完善性的维护申请，则要提出一个简明的修改规格说明，这些维护申请必须按上述规定进行评价。
　　维护申请表是外部产生的文档，以它作为维护工作计划的基础。软件机构内部要写出软件修改报告，其中包括：

　　在拟定详细维护计划之前，应将软件修改报告提交修改控制部门批准。
　　对于每一项维护申请，需要进行如图6.2所示的工作。首先，要求确定即将进行维护工作的类型。在多数情况下，用户把维护申请看成是软件错误的一个征状，即改正性维护，而开发人员将此维护申请当作适应性维护或完善性维护。如果存在不同意见，必须经过协商解决。
　　在图6.2中，改正性维护工作是从评价错误的严重程度开始的，如果存在某个关键功能不能运行，这样的错误就应在系统管理员的指导下分派人员，立即开始分析问题；对于错误不严重的改正性维护，则要与其他需要软件开发资源的任务一起，统一安排进行。
　　在有些情况下，有的错误非常严重，以致不得不临时放弃正常的维护控制工作程序，即不对修改可能带来的副作用作出评价，也不对文档作相应的更新，而立即进行代码的修改。这是一种救火式的改正性维护，只有在非常紧急的情况下才使用，这种维护在全部维护中只占很小的比例。应当说明的是，救火式不是取消，只是推迟了维护所需要的控制和评价。一旦危机取消，这些控制和评价活动必须进行，以确保当前的修改不会增加更为重要的问题。
　　适应性维护和完善性维护的申请则采用不同的路线。对于适应性维护，首先进行评价和按优先次序分类，然后排出在维护活动中的位置。对于完善性维护，同样要进行评价。但出于商业的策略、当今和今后软件产品的方向等方面的考虑，不是所有完善性维护都被接受。被接受的完善性维护也要在维护的队列中确定它们的位置。每一个维护申请的优先次序确定之后，就像另一项开发工作一样安排它们所需的工作。如果有的优先级很高，就应立即着手工作。

图6.2 软件维护工作流程

　　不论是哪一种类型的维护，都要进行相同的技术工作，这些工作包括：

　　事实上，软件维护就是实际的软件工程的循环应用，不同是维护类型不同，重点不同，但整个方法是相同的。在维护流程中，最后一项工作是评审，即重新验证和确认软件配置所有成分的有效性，并确保在实际上完全满足维护申请的要求。