IT项目计划中质量目标的确定.doc

IT 项目计划中质量目标的确定 一个软件项目除了进度目标外，另外一个最重要的目标就是质量目标，而质量目标并不是简单指版本发布的时候测试问题全部解决，而更多关注的是你版本发布后的缺陷泄露情况，这个质量目标在项目完成的时候无法马上得到数据和进行验证的。所以一般是通过间接控制的方式，即可以去估计我们期望的缺陷和 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 个或