软件质量,如何评价?采用什么手段?
一谈评价必谈度量:理论、体系、指标,着实让非专业人士头痛。无论是ISO还是CMMI,也都是在高等级:有序、自治后,才提到度量以及基于度量的持续改进。
CMMI 4,量化管理级:分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据,管理能够在定量的范围内预测性能。
度量过程和产品,给我的感觉更多的是对过程进行评价:检视过程及其产出,静态方法。
过程产出物更多是以模版的符合度为准则,产出物实际的输出内容检查的并不多,想来原因应该有三:
1)过程产出物数量较多,逐一逐点细致查看并不现实;
2)过程产出物与业务紧密相连,不参与到真实的项目中很难了解真相;
3)行业产出技术相对专业,没有一定的技术基础很难窥见存在的问题,更不要说进行评价。
好的过程不一定有好的结果,但是不好的过程一定不会有好的结果,这是过程管理的基本观点。
过程的制定是对操作及产出进行规范,通过规范来约束行为,以减少风险、提升预期质量。
那么如何有效的对产出进行评价和度量呢,特别是软件的最终产物:软件系统。
2010年前后,从事软件项目监理行业,一项重要的工作就是对采购软件的质量进行评价,当时评价的策略包含两个方面:
1)软件系统正式上线前的交付质量;
2)软件系统实际业务应用的质量。
第2)点侧重软件系统与实际业务的匹配度,可以直接从业务流程实现的符合度 + 终端用户的使用难易度/接受度进行实际调研、反馈中得到。
而第1)点的交付软件质量的评价着实让我费了些心思。软件交付方提供了完备的软件过程产出:
1)原始需求文档;
2)合同文本中的功能及非功能性要求,及相应的补充条款;
3)需求分析与功能拆解说明;
4)设计文件,包括架构说明、概要设计、详细设计、数据库设计、服务器设计;
5)编码规范,源代码及代码评审记录;
6)内部测试,包括测试分析、测试用例设计及评审记录、测试用例执行、缺陷记录及跟踪;
7)软件环境配置、性能验证和业务流程验证记录;
8)相关软件评价机构给出的评审盖章文件。
所有软件研发过程要求的过程及输出都不缺少,交付产出物工整而且全部评价通过,但是软件购买方仍对交付方的软件系统不放心,希望能从其他不同的角度对交付的软件产品进行质量评价。
过程标准、产出物完备,如何评价?
以测待评。
基于静态方法,增加动态验证过程。
从对过程及过程产出的识别,到最终交付软件系统的测试验证。完成对交付软件系统的功能和性能验证。
设计有针对性的测试用例和测试场景:基于软件需求、参照软件交付合同文本中的功能和非功能要求、参考软件交付方的测试用例、配合软件购买方的实际业务流程 。
测试执行:使用实际业务数据、实际的业务环境,执行测试用例,验证软件系统功能在实际业务操作中的功能正确性、易用性。
性能验证:通过性能测试,验证软件系统在实际硬件环境、实际运行环境下的运行表现,确认交付软件系统的可用性、软件运行的硬件环境的最佳配置,完成对合同中非功能性要求的验证。
静态评审:过程完整、交付完备,是软件质量评价的重要方式。
以测代评:执行实际数据、业务场景验证,为软件正式运行前的质量提供了更有力的评价。
如果时间充分、希望尽可能早的暴露问题及时纠正,不妨在关注过程及产出的同时,更多的关注软件系统的真实运行表现,在最终用户发现问题、解决问题。
以测代评,有效评价软件系统的方法。
至于评价指标是什么,这是另一个问题。。。。。。