软件过程基础_设计和代码评审.ppt

1、,Chaoying Wu,软件过程基础 Software Process foundation 第六讲：代码评审lecture Six: code review,北京航空航天大学 软件工程研究所 吴超英,2,为什么要进行软件审查（评审） Why do we need software inspection?,真正的聪明者并非“从来不犯错误”， 而是决不再犯同样的错误。,？,or,主题,评审类型 评审的原则 设计评审 评审检查单 缺陷预防 TSP质量准则 评审的注意事项,PSP7：评审,1 评审类型,审查（Inspection) 走查 (Walkthrough) 个人复查(Personal re

2、view),PSP7：评审,5,软件Inspection的历史History of software inspection,最初开始于 IBM 的 Michael Fagan First began in IBMs Michael Fagan 在70年代早期使用；在1976年发表论文 首先在IBM内部传授，然后向外部推广 首先应用于编码，然后扩展到需求和构架 包含了其他人的工作成果 Contains other peoples work AT establish explicit prevention actions. 结合过程脚本、检查单和表格 Incorporate these actio

3、ns into your process scripts, checklists, and forms.,51,分析原因 鱼骨图示例 Cause analysis-fishbone diagram example,名称/类型,忘记声明,不知道需要声明,不理解,他人误导,拼写错误,缺陷,52,TSP侧重于开发项目的组织与协调，并通过采集必要的数据，使项目组在进入集成和系统测试之前，就能够通过“模块质量剖面图”分析模块的质量。根据这些数据，开发人员就可在集成和系统测试之前就能够确定哪个模块中可能潜伏的错误。该模块质量剖面图是根据这五条准则计算出来的。,6 TSP质量准则 TSP quality c

4、riterion,软件设计时间不小于软件实现时间 Design time should not less than the implementation time of software. 设计评审（复查）时间至少应占一半的设计时间 More than a half design time should be the time of design review. 代码评审（复查）时间至少应占一半的代码编制时间 More than a half code time should be the time of code review. 在编译阶段发现的缺陷不应超过 10 个/KLOC The de

5、fect found in the compile stage should less than 10/KLOC. 在测试阶段发现的缺陷不应超过 5 个/KLOC。 The defect found in the test stage should less than 5/KLOC.,53,过程质量指数（PQI）Process quality index,设计/编码时间=设计时间/编码时间，范围是0.01.0 设计评审（复查）时间=2*设计评审（复查）时间/设计时间，范围是0.01.0 代码评审（复查）时间=2*代码评审（复查）时间/编码时间，范围是0.01.0 编译缺陷数/KLOC=20/（

6、10+编译缺陷数/KLOC），范围是0.01.0 单元测试缺陷数/KLOC=10/（5+单元测试缺陷数/KLOC），范围是0.01.0 过程质量指数可通过将这5个值相乘得到。图8.11显示了六个程序的PQI值的轮廓图。最差质量的两个程序的轮廓图（第5和第6）是在单元测试后仍有缺陷的仅有的两个程序。图8.12中的数据显示了PQI值大于0.4的程序在单元测试后没有找到缺陷。然而，它的目标应该是1.0。,54,模块质量剖面图 Module Quality Profiles,设计时间/编码时间,代码评审（复查）时间,单元测试阶段的缺陷密度,编译阶段的缺陷密度,设计评审（复查）时间,当每个元素满足时值为

7、1，围成的质量面积为正五边形,55,TSP Quality Profiles,4 评审的注意事项,在编译前或编译后进行评审 评审和审查的关系 缺陷预防,PSP7：评审,在编译之前进行评审,当你的开发环境有编译这一步时，那么在编译之前进行代码评审就更加有效率 原因是： 在编译之前和编译之后进行评审的评审时间大致相同 如果在编译之前进行评审，编译的时间会显著地减少 在编译和测试中节省的时间常常大于评审时间 代码评审中发现的语法和印刷缺陷编译器可能会忽视 已编译代码的代码评审效果更差 在评审之前和评审之后编译器效果是相等的 有很多编译缺陷的程序往往有很多测试缺陷,PSP7：评审,PSP7：评审,%

8、5 test defects/KLOC,% 25 test defects/KLOC,% 50 test defects/KLOC,7,246 PSP programs,测试 vs. 编译缺陷/KLOC,PSP7：评审,评审（复查）与审查,审查的主要焦点应该是发现你忽视的问题 当程序中有很多简单的缺陷，检查者就会受到很多干扰而往往忽视更多的重要的问题 评审（复查）代码首先要 提供一个达到检查标准的产品来进行检查 表现出对检查者时间的尊重 进行更高质量的检查 产生更高质量的产品,PSP7：评审,61,小结,可以通过以下手段改进产品质量，促进开发工作 Improve product quality

9、 and accelerate development work by 在测试前进行评审（复查）和检查来排除缺陷doing reviews and inspections to remove defects before test 使用测试来检查产品质量，而不是减少缺陷数量using testing to check product quality, not to remove volumes of defects 设计和代码评审（复查）可以 Design and code reviews 提高你的程序质量improve the quality of your programs 节省开发时间save development time 要进行有效的评审（复查），你必须 To do effective reviews, you must 建立评审（复查）目标establish review goals 遵循一个规范的评审（复查）流程follow a disciplined review p