3.3.5 采用临时评审的过程
代码编写阶段开发工程师之间的临时评审；
其他开发阶段，开发人员相互之间的临时评审。
3.3.6 采用结队编程的过程
针对于需求不明确、采用迭代增量开发过程的小规模项目，采用极限编程时，建议采用结队编程，但一般不做强制规定。
我们实际采用极限编程思想进行了两个项目（一个内部项目和一个外部项目）的开发，实际上取得了非常好的效果。开发人员实际产出值达到了5000行代码/人月以上。当然这些项目不太大，同时文档编写比较简单。
3.4 审查流程定义
我们规定了审查流程的定义，其他评审技术只是采用了其中的流程和管理思想。
3.5 软件评审效果分析
我们强化了软件评审技术后，在实际过程中取得了非常好的效果。以一个网络流量分析的项目为实例，在第一期没有严格实施软件评审技术，而第二期严格实施了软件评审技术，其中审查数据如下表。
评审过程数据及质量分析实例
文件/模块 计算基数（页数/KLOC） 致命 严重 一般 提示 总和 标准（目标/下限-上限） 比例 达标与否
SRS 42 1 1 29 10 31 0.8 / 0.5~1.1 0.738 OK
STP 58 22 15 12 37 0.8 / 0.5~1.1 0.638 OK
HLD 34 4 15 29 19 0.7 / 0.5~0.9 0.559 OK
LLD 205 11 59 29 70 0.43 / 0.22~0.64 0.341 OK
UTP 217 15 80 15 95 0.43 / 0.22~0.64 0.438 OK
CodeReview 50 7 372 151 379 10.62 / 7.43~13.8 7.580 OK
SITP 50 6 98 112 30 216 5.65/3.86~8.44 4.320 OK
产生的效果为：
1）产出量：单位开发人员的产出量由950行代码/人月（全流程）增长到1320行代码/人月（全流程），增长量为38.9%。关键原因在于大在减少了项目后期返工的工作量。考虑由于项目熟悉和学习曲线等的原因，实际的产出增长量应该超过20%。
2）产品质量（遗留缺陷密度）：我们从软件系统的遗留缺陷率来分析系统的质量情况。在半年的维护时间内，第一期代码行为4万行，严重缺陷有5个，一般缺陷有32个，严重缺陷发现密度为0.125个缺陷/千行代码，总遗留缺陷发现密度为0.925个缺陷/千行代码；第二期代码行数为5万行，严重缺陷有1个（属于客户需求问题引发的设计缺陷），一般缺陷有15个，严重缺陷发现密度为0.02个缺陷/千行代码，总遗留缺陷发现密度为0.32个缺陷/千行代码。因此严重缺陷发现密度改进了84%，一般缺陷发现密度改进了65.4%。
3）客户满意度：第一期客户严重不满意，称我们在做玩具，满意度只有22%；第二期客户满意度大幅上升，称我们是专业人士，非常敬业，为他们所钦佩，满意度达到了91%。因此满意度提高了314%。
最主要的是，我们采用了软件评审技术，规范了软件开发过程的标准，并积累了实际的软件开发过程数据，为后面的项目管理和过程控制提供了宝贵的软件过程财富。
四、总结和展望
在实际工作中，我们以前掌握的过程数据不多，基本上一步一步摸索着前进，对于过程数据也在不断的收集及整理中。对于评审技术而言，其中最重要的一点是采用多种实际工具和手段，如针对每个过程进行评审的《缺陷检查表》等，我们也在逐步地完善这套体系和过程数据，从而为我们的过程改进不断提供支持。
相关链接：
