一个软件项目除了进度目标外，另外一个最重要的目标就是质量目标，而质量目标并不是简单指版本发布的时候测试问题全部解决，而更多关注的是你版本发布后的缺陷泄露情况，这个质量目标在项目完成的时候无法马上得到数据和进行验证的。所以一般是通过间接控制的方式，即可以去估计我们期望的缺陷和BUG的发现情况，当质量目标高的时候，就期望在评审和测试阶段近可能多的发现BUG，自然泄露到版本发布后的缺陷就少。

由于一个项目版本的总缺陷数量应该是一定的，只是在交付后发现出来还是在交付前发现出来。如果能够在交付前发现出来我们软件的质量就高。BUG缺陷密度，总缺陷数，交付后缺陷数，代码行这些指标间有着相互影响和作用。在作一个项目版本的时候，应该对这些关系有比较明确的了解，具体关系如下图(中间为交付前BUG比重)

你缺陷密度是10，但你期望交付后缺陷密度是0.8这显然是很难做到的，所以上表中的绿色底纹数据是我们可以参考和借鉴的数据。

对于项目历史版本数据统计，缺陷密度一般在4-6之间，因此交付密度采用0.8或1都是可行的。对于交付后的软件的缺陷数据，CMMI三级的企业一般在0.5-1.5个/千行代码，CMMI四级企业在0.5个/千行代码。所以根据业界这个标准和组织级的建议，项目V4.0版本采用的交付后缺陷密度为0.8个/千行。

在项目 V2.6版本，项目就根据组织级的规程仔细进行了复盘，其中得出的需求规模是39用例，产出的代码行是30068，实际的缺陷总数是319个，测试阶段的BUG数量为115个。因此可以得出的总缺陷密度为8.17个/UC，而跟测试BUG相关的测试缺陷密度为3.8。因此在项目V4.0版本项目的估算中也采用了这些数据，并取得了较好的效果，具体的对比和偏差如下：

如果项目某个版本用户提出特殊的质量要求，就需要对项目的质量目标进行调整，质量目标在确定后将直接影响到估算的工作量分布，因此在制定项目计划的时候一定是先制定出项目的质量目标，然后在根据质量目标去指导和约束估算过程。

质量目标预计出来的数据在项目执行和跟踪过程中也有用处，我们时刻要使用该数据去检查我整个项目过程是否出现偏离，如当预计的需求缺陷是160个时候，如果需求阶段实际完成缺陷只有50个或更少，这个时候就要进行分析是否是同行评审过程有问题，该发现的缺陷没有发现出来，是否需要重新组织评审或增加预审时间，只有这样才能够真正保证上游缺陷不泄露到后续工作中。

需要注意的是项目质量目标的确认过程不仅仅是项目组成员自己确定，更多的是需要和QA和测试负责人根据该版本的业务需求共同讨论和确定，QA可以根据其它项目情况或业界的一些标准给出有建设性的意见，测试也可以根据项目前续版本的测试情况来确认项目是否可以达到制定的质量目标。

项目质量目标确认后，还要进一步的确认项目的质量策略，质量策略就是你为了达到这些质量目标而需要采用的方法或手段。如质量目标要求高的时候，推算出评审需要发现100个缺陷，如果采用单人复审或多人复审就根本做不到发现这么多缺陷，这个时候就要考虑哪些要采用审查的方式以及审查的比例。

在项目质量目标确认后，在后续的项目执行过程中要时刻关注这些目标的执行情况，如评审是否充分，测试是否发现了预计多的BUG，当出现较大偏差的时候要及时分析原因和采用相关的应对措施。