软件质量管理实践.doc

软件质量管理实践4同行评审  同行评审过程  正式评审流程  技术审查流程  走查流程   同行评审方式的选   三种同行评审方式的比较  同行评审的结果  正式评审的特征  工作产品的同行评审方式   同行评审的度量  常用度量元  同行评审的质量准则   建议的同行评审效率   评审常见问题  准备问题  焦点问题  人员问题   效率问题  效果问题   小结 227软件度量   软件度量及其方针   度量活动   度量目标   度量元   度量模型   基本过程  度量方法与采集   资源模型的定义  项目级资源模型  组织级资源模型  软件质量度量   数据质量   数据的真实性   数据的同步性   软件度量相关问题   增加度量正确性的措施   软件过程性能   度量过程的常见问题   缺陷度量   什么是缺陷度量   缺陷度量元   缺陷密度的定义   缺陷密度的用途   缺陷管理库   缺陷分析   缺陷种类分析   缺陷根源分析   缺陷注入-发现矩阵   收敛趋势分析   回归分析 494同行评审在IBM、微软等很多公司都有一个很好的实践,那就是代码复审。这种代码审查的过程,不是将代码发给某一个人或某几个人去看,而是强调程序员自己定期走上台,向其他人讲解自己源程序的活动。因为要向大家讲解自己的程序,程序员会极其重视自己的工作进度、代码质量,在写代码时,就时刻想着——可能随时会被选中去做代码复审,所以会非常认真地对待每一行代码。公司为某省交通厅开发并实施了一套多层级公文交换系统。在平稳运行了3个月之后,出现了经常性地死机、公文流转串件现象。重新组织大规模测试,将近10天时间,仍没有很好地定位错误。“王哥,有时间吗?耽误您几分钟。这段代码有点问题,始终搞不定,您能帮我看下吗?”“好的,是什么问题?”“公文流转系统里经常串件,在正常情况下,发给王处长的文件跑到高局长那里去了。”“咱们看看啊”……“这段代码没有什么大问题,可能是使用了这个全局变量的事,通常它是个捣蛋鬼。”小张仔细检查了一下自己的代码,的确,轻易地使用全局变量,导致了这样一个很严重的问题。下面一组数据是软件工程中常用到的: AT&T的贝尔实验室在其开发中引入审查后的成功案例:生产率提高了14%,质量提高了10倍。有一个大型电力交换系统,发现错误的成本降低了10倍,在发现错误方面,审查的成效是测试的20倍。TRW对一个大型软件进行了研究,发现2019个由用户发现的错误导致代码变更。分析结果表明,在这些错误中,%,%。本书中研究的同行评审,定义为“由软件工作产品生产者的同行遵循已定义的规程对产品进行的技术评审”。其目的是为了及早和高效地从软件工作产品中识别并消除缺陷,让软件变得更易读和维护,同时减少最终泄漏到产品发布时的缺陷。主要工作第一是发现工作产品中的具体错误,第二是通过对这些错误的分类和统计,发现共同的错误类型和将来避免这类错误的方法,提供今后对所发现的同类错误进行控制的数据。通过对开发过程中的反馈和从错误中汲取教训,避免今后类似的缺陷和错误发生。? 有些工作产品在早期阶段就可以进行同行评审去发现缺陷,但无法对其进行测试;即使到了编码阶段,测试活动也不能发现某些特定类型的缺陷(例如违反编程规范)。从图4-1(开发各阶段缺陷放大图)可以看出,随着开发的不断开展,缺陷不断泄漏和放大,最终形成的产品是一个灰色的距离用户真正需求很远的一个“东西”。这就需要在开