在软件工程管理中一种用来评审开发过程和它是否成功的途径是察看与和单个程序模块的质量及运行有关的一些标准。但是当最初的开发过程完成以后，项目经理开始把他们的注意力转移到整个应用程序在实际运行过程中的表现上来。

不幸的是，一些企业使用开发过程中的标准来评估处在运行和维护阶段的应用程序，这无法提供对你的程序和团队的描述。要避免使用不准确的或者不相关的数据衡量你开发的软件－－而且要避免你的团队不必为超出他们控制泛围的情况负责－－你需要分析当你的程序投入运行以后所使用的评审标准。下面介绍一些你在评估你的企业使用的运行和维护标准的时候应该注意的东西。

应用程序运行的过程取决于什么

开发者有时会注意诸如系统正常运行时间的长度（以应用程序能否使用的形式出现），软件故障投诉服务级别（SLAs），以及项目完成度之类的数据而不是其它时间和预算上的数据。但是，这些数据并无法最好的说明你所做的一切。例如，如果你发布了一个加强的发布版本，而这个发布版本中的问题导致了应用程序有时停止运行，那么即使在没有人找你麻烦的情况下，你的团队是否也应该对这些负责呢？更进一步的说，在开发过程中，你可能把注意力投向估计生成一个发布版本所需的时间。但是在维护过程中，特别是对已运行程序的修补过程中，你没有时间来作准确的估计。而且如果你正在处理已经运行的代码，那么你优先考虑的东西可能就是软件发布的速度而不需要再考虑其它的东西。你只需要确保你的注意力不要分散到一些低优先级的因素上去。 为了帮助你确定使用的标准是否正确，其目的是否明确，你应该就你的程序运行性能评审标准回答下面的问题：

软件维护和新软件的开发过程是否使用的是不同的标准？

• 软件维护和新软件的开发过程是否使用的是不同的标准？
• 你是否知道复杂的评审标准的哪些部分，比方与SLA相关的标准直接或者间接的影响了你？
• 软件持续运行时间的SLA标准是否包括了对开发者的警告？例如，在程序运行的过程中出现错误你是否应该负责？对于一个由外部软件承包商所应负的责任你是否也应该负连带的责任呢？
• 对于快速的软件修补过程应该评审些什么？应该在什么时候应该将复杂和泛滥的问题正式定为一个项目并指定相应的项目评审数据？什么时候在特定应用程序中出现的问题应该成为原始设计的改进，还是应该将它作为一个新的版本发布？程序中已知的错误是否仍然出现在了改进后的项目里？
• 故障处理响应时间的评估是如何计算的？你是否要根据处理这个故障所花的时间而负责还是只为你所“赚”到的这份故障投诉书负责？
• 如果你的错误造成了“成批”的修改过程而导致了时间上的耽搁你是否会受到处罚？
  程序持续运行的SLA是否现实？要完成软件开发目标所需的费用是否经过核实？如果你的程序一开始持续运行的能力就很强，那么要延长它所需的费用就会呈指数增长。考虑到这个因素以后，那么你有可能搞到完成目标所需的资源么（不管它是时间还是人手）？
• 项目的评审方案是否反映了项目的开发方法学？例如，如果你使用一种极端的编程方式，那么项目的管理过程有没有修改性能指数来反映这种改变？
• 谁来掌握评审标准的发展？市场效益的评审标准是如何影响你的？对于这些评审标准的结果你有什么样的控制权力？
• 软件信息结构中出现的错误将如何负责？对于造成软件故障或者延迟但又无法改变的部分，你是否要做最后的努力？
• 你是否有一个设计良好的软件修改控制系统？因为对软件的修改通常是软件故障的原因，所以你投入运行的程序能否容易的被恢复到以前的版本？
• QA在应用程序和架构的开发过程起了多大的作用？当一个应用程序在投入使用并处于维护状态的时候QA还能扮演什么样的角色？
• 你的企业在容量计算和灾难恢复方面做的工作如何？当这些方面出现问题的时候你要不要负责？

总结

什么评审标准的真正价值在于快速收集合适的信息并很快投入使用来提高开发工作，不论对于IT业的哪个部分来说都是如此。要确保用来衡量你维护工作的质量（和数量）的评审标准准确的反映了你和你团队的表现。