质量小议12 -- 以测代评

    软件质量，如何评价？采用什么手段？

    一谈评价必谈度量：理论、体系、指标，着实让非专业人士头痛。无论是ISO还是CMMI，也都是在高等级：有序、自治后，才提到度量以及基于度量的持续改进。
    CMMI 4，量化管理级：分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。

    度量过程和产品，给我的感觉更多的是对过程进行评价：检视过程及其产出，静态方法。
    过程产出物更多是以模版的符合度为准则，产出物实际的输出内容检查的并不多，想来原因应该有三：
    1）过程产出物数量较多，逐一逐点细致查看并不现实；
    2）过程产出物与业务紧密相连，不参与到真实的项目中很难了解真相；
    3）行业产出技术相对专业，没有一定的技术基础很难窥见存在的问题，更不要说进行评价。

     好的过程不一定有好的结果，但是不好的过程一定不会有好的结果，这是过程管理的基本观点。
     过程的制定是对操作及产出进行规范，通过规范来约束行为，以减少风险、提升预期质量。
     那么如何有效的对产出进行评价和度量呢，特别是软件的最终产物：软件系统。

     2010年前后，从事软件项目监理行业，一项重要的工作就是对采购软件的质量进行评价，当时评价的策略包含两个方面：
     1）软件系统正式上线前的交付质量；
     2）软件系统实际业务应用的质量。
     第2）点侧重软件系统与实际业务的匹配度，可以直接从业务流程实现的符合度 + 终端用户的使用难易度/接受度进行实际调研、反馈中得到。
     而第1）点的交付软件质量的评价着实让我费了些心思。软件交付方提供了完备的软件过程产出：
      1）原始需求文档；
      2）合同文本中的功能及非功能性要求，及相应的补充条款；
      3）需求分析与功能拆解说明；
      4）设计文件，包括架构说明、概要设计、详细设计、数据库设计、服务器设计；
      5）编码规范，源代码及代码评审记录；
      6）内部测试，包括测试分析、测试用例设计及评审记录、测试用例执行、缺陷记录及跟踪；
      7）软件环境配置、性能验证和业务流程验证记录；
      8）相关软件评价机构给出的评审盖章文件。
      所有软件研发过程要求的过程及输出都不缺少，交付产出物工整而且全部评价通过，但是软件购买方仍对交付方的软件系统不放心，希望能从其他不同的角度对交付的软件产品进行质量评价。

      过程标准、产出物完备，如何评价？ 

      以测待评。
      基于静态方法，增加动态验证过程。
      从对过程及过程产出的识别，到最终交付软件系统的测试验证。完成对交付软件系统的功能和性能验证。
      设计有针对性的测试用例和测试场景：基于软件需求、参照软件交付合同文本中的功能和非功能要求、参考软件交付方的测试用例、配合软件购买方的实际业务流程 。
      测试执行：使用实际业务数据、实际的业务环境，执行测试用例，验证软件系统功能在实际业务操作中的功能正确性、易用性。
      性能验证：通过性能测试，验证软件系统在实际硬件环境、实际运行环境下的运行表现，确认交付软件系统的可用性、软件运行的硬件环境的最佳配置，完成对合同中非功能性要求的验证。

      静态评审：过程完整、交付完备，是软件质量评价的重要方式。
      以测代评：执行实际数据、业务场景验证，为软件正式运行前的质量提供了更有力的评价。

      如果时间充分、希望尽可能早的暴露问题及时纠正，不妨在关注过程及产出的同时，更多的关注软件系统的真实运行表现，在最终用户发现问题、解决问题。
      以测代评，有效评价软件系统的方法。
      至于评价指标是什么，这是另一个问题。。。。。。