如何量化软件质量
本人目前在做一个计划,目的是改进软件质量
但是引起软件质量问题的原因有很多，并且改进的目标也存在许多点
于是本人就决定采用以回归分析模型作为参考,结合实际经验和组织内部情况作出合理的调整方案。抓出主次从而从重要方面改进软件质量。
但是要建立回归分析模型，就必须对目标进行统计和量化。
请问应该如何去量化?
就以BUG率为例子,BUG有严重级别,最高级别的BUG应该给予多少分值,最低又应该多少,中间的又应该多少,为什么给予这个分值等等。
在网上搜索了一番,发现介绍量化的理论知识特别多，但是几乎没有一个文章会给出一个具体实例,并且对内容进行讲解。
请各位网友帮助,最好能附上实例讲解~
[解决办法]
这个要根据需求的要求而定。
如软件的功能范围、出错率、容错性、兼容性、运行占用的内存、操作响应时间（效率）、用户学习的时间（易用性）以及安全性、可靠性等等。
[解决办法]
bug率，最常用的是每千行bug数。
bug分级后，还可统计不同级别每千行bug数
bug的发现阶段，产生阶段，产出原因都可以统计
可以看看一些专业的缺陷跟踪系统的说明
[解决办法]
BUG 数量能够基本反映软件的质量问题，至于每个 BUG 本身的严重程度，不是很重要。如果一定要评级的话，那要看是什么时候发现的。
如果是测试人员发现的，那么由测试人员来评定 BUG 的严重程度（分高中低三级就行了）；如果是发布之后发现的，那要看这个 BUG 给客户造成多大的损失来定。
[解决办法]
量化的前提是跟软件开发过程中的各位角色如经理、开发人员、测试人员、QA等达成共识。一般计划中的量化大多是有base的。如果没有可以参考的项目，则需要依据自己公司的出长标准，并在客户的标准基础上定义。bug率只能大体估计，但是你主要把握你的bug曲线是符合软件开发过程控制的。如果lz有好的版本和bug管理工具，并且QA能够密切的跟踪项目的进展，统计各阶段的数据如代码提交行数，bug数，解决速度，级别比例等，即使没有量化的计划，也可以在量化的工时基础上顺利的完成计划。量化的基础是经验值，所以没有base，请勿盲目决策。
