软件质量管理实践.doc

软件质量管理实践.doc

ID:53868509

大小:685.50 KB

页数:50页

时间:2020-04-10

软件质量管理实践.doc_第1页
软件质量管理实践.doc_第2页
软件质量管理实践.doc_第3页
软件质量管理实践.doc_第4页
软件质量管理实践.doc_第5页
资源描述:

《软件质量管理实践.doc》由会员上传分享,免费在线阅读,更多相关内容在应用文档-天天文库

1、软件质量管理实践4同行评审24.1同行评审与测试的关系34.2同行评审的种类和对象44.2.1同行评审的种类44.2.2同行评审的对象54.3 同行评审过程54.3.1 正式评审流程64.3.2 技术审查流程74.3.3 走查流程74.4  同行评审方式的选84.4.1  三种同行评审方式的比较84.4.2 同行评审的结果84.4.3 正式评审的特征94.4.4 工作产品的同行评审方式94.5迭代生命周期的审查104.6同行评审的注意事项114.6.1同行评审遵循的原则124.6.2同行评审关注的问题13

2、4.6.3同行评审通过的准则134.6.4同行评审的经验共享144.6.5文档审查重点144.7  同行评审的度量154.7.1 常用度量元154.7.2 同行评审的质量准则164.7.3  建议的同行评审效率174.8  评审常见问题184.8.2 准备问题184.8.3 焦点问题194.8.4 人员问题204.8.5  效率问题214.8.6 效果问题214.9  小结227软件度量227.1  软件度量及其方针247.2  度量活动257.2.1  度量目标257.2.2  度量元287.2.3  

3、度量模型297.2.4  基本过程317.2.5 度量方法与采集327.3.1  资源模型的定义337.3.2 项目级资源模型347.3.3 组织级资源模型357.3.4 软件质量度量367.4  数据质量377.4.1  数据的真实性377.4.2  数据的同步性387.5  软件度量相关问题387.5.1  增加度量正确性的措施387.5.2  软件过程性能397.5.3  度量过程的常见问题397.6  缺陷度量407.6.1  什么是缺陷度量407.6.2  缺陷度量元417.6.3  缺陷密度的

4、定义427.6.4  缺陷密度的用途427.6.5  缺陷管理库437.7  缺陷分析447.7.1  缺陷种类分析457.7.2  缺陷根源分析467.7.3  缺陷注入-发现矩阵467.7.4  收敛趋势分析477.7.5  回归分析494同行评审在IBM、微软等很多公司都有一个很好的实践,那就是代码复审。这种代码审查的过程,不是将代码发给某一个人或某几个人去看,而是强调程序员自己定期走上台,向其他人讲解自己源程序的活动。因为要向大家讲解自己的程序,程序员会极其重视自己的工作进度、代码质量,在写代码时

5、,就时刻想着——可能随时会被选中去做代码复审,所以会非常认真地对待每一行代码。  公司为某省交通厅开发并实施了一套多层级公文交换系统。在平稳运行了3个月之后,出现了经常性地死机、公文流转串件现象。  重新组织大规模测试,将近10天时间,仍没有很好地定位错误。  “王哥,有时间吗?耽误您几分钟。这段代码有点问题,始终搞不定,您能帮我看下吗?”  “好的,是什么问题?”  “公文流转系统里经常串件,在正常情况下,发给王处长的文件跑到高局长那里去了。”  “咱们看看啊”  ……  “这段代码没有什么大问题,可能

6、是使用了这个全局变量的事,通常它是个捣蛋鬼。”  小张仔细检查了一下自己的代码,的确,轻易地使用全局变量,导致了这样一个很严重的问题。  下面一组数据是软件工程中常用到的:  AT&T的贝尔实验室在其开发中引入审查后的成功案例:生产率提高了14%,质量提高了10倍。有一个大型电力交换系统,发现错误的成本降低了10倍,在发现错误方面,审查的成效是测试的20倍。TRW对一个大型软件进行了研究,发现2019个由用户发现的错误导致代码变更。  分析结果表明,在这些错误中,通过代码审查可以发现62.7%,通过设计审

7、查可以发现57.7%。  本书中研究的同行评审,定义为“由软件工作产品生产者的同行遵循已定义的规程对产品进行的技术评审”。其目的是为了及早和高效地从软件工作产品中识别并消除缺陷,让软件变得更易读和维护,同时减少最终泄漏到产品发布时的缺陷。主要工作第一是发现工作产品中的具体错误,第二是通过对这些错误的分类和统计,发现共同的错误类型和将来避免这类错误的方法,提供今后对所发现的同类错误进行控制的数据。通过对开发过程中的反馈和从错误中汲取教训,避免今后类似的缺陷和错误发生。4.1同行评审与测试的关系发现缺陷的手段

8、为什么要引入同行评审而不是继续完全使用测试呢?  有些工作产品在早期阶段就可以进行同行评审去发现缺陷,但无法对其进行测试;即使到了编码阶段,测试活动也不能发现某些特定类型的缺陷(例如违反编程规范)。  从图4-1(开发各阶段缺陷放大图)可以看出,随着开发的不断开展,缺陷不断泄漏和放大,最终形成的产品是一个灰色的距离用户真正需求很远的一个“东西”。这就需要在开发的过程中不断进行同行评审,减少泄漏到下一个阶段的缺陷。  成功的同行

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。