接评审技术在高质量软件开发中的应用分析（上）
三、评审在高质量软件开发的实际应用
3.1 高质量软件开发项目介绍
高质量软件，如电信软件、金融证券类软件等，有较严格的要求：可用性要求非常高，并且不会因为系统维护和扩展而带来运营中断；支持使用现有管理工具和标准进行远程管理；能够提供更出色的性能以及运营在高可用性集群上的能力，减少任何单点的软硬件失效现象。五个九（99.999%）意味着一个系统的宕机时间一年不超过5分26秒。因此高质量软件项目是一种对可用性、可靠性、稳定性要求非常高的软件项目，要求软件能够每周7*24工作。
因此高质量软件开发一般采用严格的软件开发过程，明确定义每个阶段的质量目标和要求，严格项目软件开发过程控制。
我们在多个高质量软件开发项目中成功地采用了评审技术，并发挥了巨大的作用。从这些项目的实际开发过程中，我们针对于规模从30人月——300人月，代码行数从5万行——30万行的运营支撑系统项目制定了项目评审流程和相关要求。
3.2 软件过程定义
软件过程主要分为项目立项阶段、需求分析阶段、设计阶段、编码实现阶段、测试阶段（包括集成测试、系统测试和用户验收测试）、实施阶段和维护阶段，项目管理工作横贯于所有的阶段。详细流程见流程图。
在软件过程中，我们定义了以下角色：
1）客户
2）销售人员
3）项目经理
4）系统分析员
5）系统架构师
6）开发工程师
7）质量工程师
8）技术支持人员
在规划质量体系时，我们参考PMBOK对项目质量管理的要求，将项目质量管理过程设计为三个阶段：
1）质量规划——确定质量活动的流程和标准，如软件过程定义，质量达标定义等；
2）实施质量保证——编写相应的测试计划、执行测试和评审活动；
3）实施质量控制——监控质量保证活动的结果，判断是否达标，如不达标，则采取相应的风险防范措施。
3.3 软件评审过程及标准定义
我们在整体软件过程中明确定义了需要软件评审的过程及实施的方法。
3.3.1 采用审查的过程
采用最严格最系统的评审方法——审查的软件过程有：
1）《软件需求规格说明书》的评审
2）《概要设计说明书》的评审
3）《详细设计说明书》的评审
4）代码评审
5）《单元测试计划》的评审
6）《集成测试计划》的评审
7）《系统测试计划》的评审
对于文档评审以文档页数为基数，要求每页发现的缺陷数有一个目标值，并规定了上下限的范围。对于代码评审以代码行数为基数，要求每千行代码发现的缺陷数有一个目标值，并规定了上下限的范围。这个审查的缺陷数标准如下表。
软件过程审查的质量目标
质量目标 目标 下限 上限
SRS文档Review缺陷发现密度（个/页） 0.80 0.50 1.10
HLD文档Review缺陷发现密度（个/页） 0.70 0.50 0.90
LLD文档Review缺陷发现密度（个/页） 0.43 0.22 0.64
代码检视缺陷发现密度（个/KLOC） 10.62 7.43 13.81
单元测试计划Review缺陷发现密度（个/页） 0.43 0.22 0.64
集成测试计划Review缺陷发现密度（个/页） 0.70 0.50 0.90
系统测试计划Review缺陷发现密度（个/页） 0.80 0.50 1.10
如果发现的缺陷密度低于或高于质量目标范围，则我们需要分析其原因，然后根据原因进行返工或相应处理流程。这要和实际情况相结合，具体情况具体分析：如某个开发工程师的水平和素质非常高，他的代码一般很少出错，这样他的代码检视缺陷密度低是属于正常的；而另外一个工程师水平一般，但发现的缺陷密度也很低，但原因是属于检视的过程不严格，大家没有时间来进行严格的评审，则此时需要重新进行检视。
3.3.2 采用小组评审的过程
采用小组评审的软件过程主要包括对客户需求的评审、项目计划的评审和维护计划的评审。
对客户需求的评审参加人员有项目经理、系统分析员、系统架构师、质量部主管等。
项目计划的评审主要由项目经理、系统分析员、系统架构师、质量部主管和部门经理等参加，对人力资源、进度和质量管控等进行评审。
维护计划由项目经理、技术支持人员、质量部主管和客户服务人员参加，对人力资源、管控流程等进行评审。
3.3.3 采用走查评审的过程
需求分析过程中，系统分析员、系统架构师相互之间的走查；
设计过程中，系统分析员、系统架构师相互之间的走查；
在进入维护阶段时，作者需和维护人员进行走查，让维护人员能够维护作者的工作产品。
3.3.4 采用桌查的过程
采用桌查的过程主要集中在代码提交阶段，主要是经验丰富的开发人员对提交的代码进行检查，合格的产品才会提交到CVS上面。
具体实施方法为：开发经验较少（8年以下开发经验）的开发人员在提交代码时，请经验丰富（10年以上开发经验）的开发人员进行桌查，没有明显问题后才允许提交；经验丰富的开发人员提交代码时也需另一名经验丰富的开发人员桌查后方可提交。
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%。
最主要的是，我们采用了软件评审技术，规范了软件开发过程的标准，并积累了实际的软件开发过程数据，为后面的项目管理和过程控制提供了宝贵的软件过程财富。
四、总结和展望
在实际工作中，我们以前掌握的过程数据不多，基本上一步一步摸索着前进，对于过程数据也在不断的收集及整理中。对于评审技术而言，其中最重要的一点是采用多种实际工具和手段，如针对每个过程进行评审的《缺陷检查表》等，我们也在逐步地完善这套体系和过程数据，从而为我们的过程改进不断提供支持。
相关链接：
评审技术在高质量软件开发中的应用分析（上）