1、先确认维护要求。
这需要维护人员与用户反复协商，弄清错误概况以及对业务的影响大小，以及用户希望做什么样的修改。然后由维护组织管理员确认维护类型。
2、对于改正性维护申请，从评价错误的严重性开始。
如果存在严重的错误，则必须安排人员，在系统监督员的指导下，进行问题分析，寻找错误发生的原因，进行"救火"性的紧急维护；
对于不严重的错误，可根据任务、机时情况、视轻重缓急，进行排队，统一安排时间。
��所谓"救火"式的紧急维护，是指如果发生的错误非常严重，不马上修理往往会导致重大事故，这样就必须紧急修改，暂不再顾及正常的维护控制，不必考虑评价可能发生的副作用。在维护完成、交付用户之后再去做补偿工作。
3、对于适应性维护和完善性维护申请，需要先确定每项申请的优先次序。
若某项申请的优先级非常高，就可立即开始维护工作，否则，维护申请和其它的开发工作一样，进行排队，统一安排时间。
��并不是所有的完善性维护申请都必须承担，因为进行完善性维护等于是做二次开发，工作量很大，所以需要根据商业需要、可利用资源的情况、目前和将来软件的发展方向、以及其它的考虑，决定是否承担。
4、实施维护：
尽管维护申请的类型不同，但都要进行同样的技术工作。这些工作有：修改软件需求说明、修改软件设计、设计评审、对源程序做必要的修改、单元测试、集成测试(
回归测试)、确认测试、软件配置评审等。
5、在每次软件维护任务完成后，最好进行一次情况评审，确认：
��・ 在目前情况下，设计、编码、测试中的哪一方面可以改进？
��・ 各种维护资源哪些已经使用，哪些没有使用？
��・ 工作中主要的或次要的障碍是什么？
��・ 从维护申请的类型来看是否应当有预防性维护？
��情况评审对将来的维护工作如何进行会产生重要的影响，并可为软件机构的有效管理提供重要的反馈信息。
�� |
|