评审技术在高质量软件开发中的运用.docx
《评审技术在高质量软件开发中的运用.docx》由会员分享，可在线阅读，更多相关《评审技术在高质量软件开发中的运用.docx（9页珍藏版）》请在冰豆网上搜索。
评审技术在高质量软件开发中的运用
评审技术在高质量软件开发中的应用
作者/转载者:
郭华 发表时刻:
2007-5-3118:
48:
02
评审技术在高质量软件开发中的应用
郭华
摘要
软件质量和开发进度一直是软件开发成功关键的因素，而在实际工作中只有少量项目能按打算完成，进度要求往往迫使开发组无法保证软件质量，最终许多项目因为质量问题无法投入使用。
软件评审作为一种软件产品验证的活动，能够及早地从软件产品中识不并消除缺陷，从而减少后期的返工，加快开发进度，提高产品质量。
作为一种十分有效值得推广的评审方法，在软件过程改进中起到了特不大的作用，同时软件评审也是CMM等级3的关键过程域。
本文描述了正式和非正式的多种软件评审技术，包括临时评审、桌查、轮查、结队编程、走查、小组评审和审查等，并系统地介绍了最正式、最严格、最有效的软件评审——审查的整个过程，包括制定评审打算、指定评审角色、做评审预备、召开评审会议和验证分析等过程。
高质量要求的软件，如电信软件、银行证券软件等，它们对可用性要求特不，因此对软件质量的要求特不严格。
作者通过将评审技术应用在高质量软件开发过程中，在实际开发过程中确定了评审的质量标准和准入、准出条件，并针对数据采集、分析做了严格的控管，建立了质量可预测的软件开发过程体系，为有效地项目评估、质量保证和项目治理提供了可靠依据，从而保证了软件项目的成功。
关键词：
软件评审、审查、开发过程、软件、质量、定量
一、软件评审
1.1缺陷的产生
缺陷指软件工作产品中的一种情况，它将导致软件产生不令人中意或非预期的结果。
在开发过程中缺陷随时可能产生，问题在于什么时候发觉它，并为此产生多少纠正成本。
。
依照一些企业返工度量的报导，缺陷返工率可达到整个开发工作量的40%~60%。
缺陷在软件开发的任何时期都可能会被引入。
项目质量治理过程包含了许多能够识不缺陷、消除缺陷的过程。
“识不缺陷”和“消除缺陷”本来是两个不同的过程，但在那个地点为了简便统一用“消除”来代表它们。
潜在的缺陷越大，用来消除它所花的费用越高。
因此成熟的软件开发过程在每一个可能会引入潜在缺陷的时期完成之后都会开展质量操纵活动。
这些为了消除缺陷的活动包括：
需求评审、设计评审、代码走查、单元测试、集成测试、系统测试以及验收测试等。
一个缺陷假如保持没有被发觉的时刻越长，则以后纠正此缺陷的花费越大。
缺陷越早发觉、越早解决，则所花费的成本越低。
因此我们应该尽量在前期发觉、识不并解决缺陷问题。
2、缺陷的识不
依照一些企业返工度量的报导，缺陷返工率可达到整个开发工作量的40%~60%。
在软件开发过程中，软件评审和软件测试是保证软件质量的两种要紧手段和方法。
测试能够识不可执行系统中的缺陷，而评审不仅可识不可执行系统中的缺陷，且能识不不能被执行的文档或人为产物。
测试和评审的比较
1）表现形式
测试的表现形式有：
单元测试、集成测试、系统测试、用户验收测试
评审的表现形式有：
审查、小组评审、走查、结对编程、同级桌查、轮查、临时评审
2）工作对象
测试的工作对象为：
可执行系统（指编译后可运行的程序）
评审的工作对象为：
需求规格讲明书、架构（概要）设计文档、详细设计文档、项目打算、项目过程文档、源代码、系统界面、测试打算、测试用例和数据、用户手册
3）识不缺陷的时期
测试识不缺陷的时期：
测试时期（编码完成后）
评审识不缺陷的时期：
需求时期、设计时期、编码时期、测试时期
4）识不缺陷的成效
测试的成效：
最多识不软件所有缺陷中30-35%的缺陷
评审的成效：
最多识不软件所有缺陷中70-75%的缺陷
5）识不缺陷的成本
测试的成本：
识不一个重要缺陷平均花费15-25小时
评审的成本：
需求时期识不一个重要缺陷平均花费2-3小时；
设计时期识不一个重要缺陷平均花费3-4小时；
代码评审时期识不一个重要缺陷3-5小时；
测试打算评审识不一个重要缺陷3-5小时
6）解决缺陷的成本
测试的成本：
消除一个重要缺陷平均花费30-80小时（包括识不缺陷时刻）
在开发后期才能识不缺陷，成本较高
评审的成本：
需求及设计时期消除一个重要缺陷5-10小时；
代码评审时期消除一个重要缺陷5-15小时
更倾向于在开发前期识不缺陷，成本较低
7）投入回报比较
（1）航天飞机搭乘项目：
在设计或代码评审时消除一个缺陷的成本为1美元，在系统测试时为13美元，交付使用后为92美元（Paulketal,1995）。
即13~92:
1
（2）电信公司审查发觉和纠正一个缺陷的平均费用为200美元，客户验收测试发觉的缺陷平均花费4200美元（BoehmandBasili2001）。
即21:
1
某研究表明，客户使用过程中发觉、纠正与需求相关的缺陷的费用是比需求开发时期发觉和纠正同样缺陷的费用的68~110倍（Boehm1981;Grady1999）。
即68~110:
1
（3）印度Infosys公司经验表明：
在代码审查上多花费一天，那个产品就有期望在后期修改缺陷节约3-6天。
即3~6:
1
3、软件评审概念
1.3.1定义
软件评审，是指在软件开发过程中，由参与评审的人员对软件开发文档或代码进行评审或检查，关心查找缺陷和改进。
软件评审的工作包括：
1）检验产品是否满足往常的规范，如需求或设计文档；
2）识不产品相关于标准的偏差；
3）向作者提出改进建议；
4）促进技术交流和学习。
软件评审涉及评审的组织机构、治理、准则、类不、内容、文件和要求等。
一般要求在软件研制时期的里程碑点进行软件评审。
评审的要紧类不有：
软件定义评审、软件需求评审、概要设计评审、详细设计评审、软件实现评审和软件验收评审等。
1.3.2软件评审的分类
自从25年前，IBM的MichaelFagan提出软件审查技术以来，许多组织使用这项技术得到了特不卓有成效的结果。
这些组织包括IBM、HP、Motorola、Raytheon、BullHN等。
通过几十年的进展，软件评审技术和多种项目治理理论相结合，差不多进展成一个庞大的体系。
就总体而言，软件评审要紧分为六类：
审查、小组评审、走查、结队编程、同级桌查和轮查、临时评审。
其中审查是最系统化、最严密的评审技术，严格规定了每个时期的角色及各自职责，在质量要求特不高的软件开发项目中得到了较广泛的应用。
在推断采纳哪种评审方法时，需考虑以下风险因素：
1）使用了新技术，方法，工具的组件
2）关键的架构性的组件
3）难以理解，却又必须准确和优化的复杂逻辑或算法
4）具有危险失败模式的组件，而且是任务、可靠性、安全性关键的
5）具有多个异常条件或失败模式的组件
6）不易测试的异常处理代码
7）打算复用的组件
8）将作为其他组件的模型或模板的组件
9）阻碍产品多个部分的组件
10）复杂的用户界面
11）由缺乏经验的开发者创建的组件
12）具有高度圈复杂性的代码模块
13）以往具有专门多缺陷或变更的模块
1.3.4审查的角色、职责及步骤
审查的角色要紧分为评审组长、作者、读者、评审人员、记录者和验证者。
部分专家认为审查的角色还有：
评审协调人。
依照治理的原则，评审协调人的角色应归入评审组长，其职责由评审组长负责。
审查的角色及职责
1）评审组长
（1）打算、安排和组织评审活动；
（2）和作者一起选择评审人，并分配角色；
（3）主持总体会议和评审会议；
（4）提交需评审的产品给每一个评审人；
（5）检查评审会议的预备是否充分，从而决定是否召开评审会议；
（6）领导小组确定评审效果；
（7）提交《评审总结报告》；
（8）维护每次评审的评审记录及来自评审总结报告中的数据；
（9）依照评审数据形成报告，提交给治理层、过程改进组及评审过程的拥有者。
2）作者
（1）作为被评审产品的作者或维护者，提交工作产品；
（2）协助评审组长选择评审人，并分配角色；
（3）陈述评审目标；
（4）初步讲解产品；
（5）返工；
（6）向评审组长报告返工时刻和缺陷数；
3）读者
将工作产品在评审会议上用自己的语言进行解讲，测试工作产品的可理解性，暴露产品的二义性、隐含假设等各种缺陷；
4）评审人员
（1）在评审会议之前检查工作产品，发觉其缺陷，为参加评审会议做预备；
（2）记录预备时刻；
（3）参加评审，识不缺陷，提出问题，给出改进建议。
5）记录者
记录评审会议中提出的问题并分类。
6）验证者
进行跟踪，确认返工工作被正确执行。
审查的要紧步骤有：
1）评审打算；
2）总体会议；
3）评审预备；
4）评审会议；
5）修改、验证。
二、软件开发模型
2.1软件生命周期
软件生命周期指软件的产生直到报废的生命周期，周期内有系统定义、需求分析、系统设计、编码实现、系统/验收测试、运行维护到废弃等时期。
组织软件开发过程的规则，就能够称为软件生命周期模型。
一个定义良好的软件生命周期模型，能够专门好的指导我们的开发工作，使漫长的开发工作易于操纵。
事实上，我们能够任意定义自己喜爱的软件生命周期模型。
然而，假如生命周期模型定义不合理，却会制约我们的开发过程。
软件开发人员在长期开发过程差不多总结出了几种常用的软件生命周期模型，我们能够依照项目的特点来选择一个合适的模型，然后在此基础上再加以裁减。
这些生命周期模型是：
1）瀑布模型，
2）快速原型模型，
3）渐增模型，
4）演进模型。
其中瀑布模型是所有生命周期模型的核心和基础，其他模型差不多上基于瀑布模型进展和衍化而来。
瀑布模型分为六个时期：
系统定义、需求分析、系统设计、编码实现、系统验收测试、运行维护。
在瀑布模型中每个时期都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。
2.2项目开发V模型
在瀑布模型的基础上，衍生出了强调测试活动的V模型。
它把瀑布模型的测试时期进行细分，并于前面的时期进行对应。
细分出来的这些时期分不为：
单元测试时期、集成测试时期和系统测试时期。
在V模型中，我们能够明白：
1）在需求分析时期，《系统需求规格讲明书》确认后，编写《系统测试打算》，预备系统测试用例、数据，对需求进行验证；对应的系统测试时期，执行系统测试打算；
2）在概要设计时期，《概要设计讲明书》确认后，编写《集成测试打算》，预备集成测试用例、数据等，对概要设计进行验证；然后在对应的集成测试时期，执行集成测试打算；
3）在详细设计时期，《详细设计讲明书》确认后，编写《单元测试打算》，预备单元测试用例、数据等，对详细设计进行验证，然后在对应的单元测试时期，执行单元测试打算。
三、评审在高质量软件开发的实际应用
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.800.501.10
HLD文档Review缺陷发觉密度（个/页）：
0.700.500.90
LLD文档Review缺陷发觉密度（个/页）：
0.430.220.64
代码检视缺陷发觉密度（个/KLOC）：
10.627.4313.81
单元测试打算Review缺陷发觉密度（个/页）：
0.430.220.64
集成测试打算Review缺陷发觉密度（个/页）：
0.700.500.90
系统测试打算Review缺陷发觉密度（个/页）：
0.800.501.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）致命严峻一般提示总和标准（目标/下限-上限）比例达标与否
SRS42112910310.8/0.5~1.10.738OK
STP58221512370.8/0.5~1.10.638OK
HLD3441529190.7/0.5~0.90.559OK
LLD205115929700.43/0.22~0.640.341OK
UTP217158015950.43/0.22~0.640.438OK
CodeReview50737215137910.62/7.43~13.87.580OK
SITP50698112302165.65/3.86~8.444.320OK
产生的效果为：
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%。
最要紧的是，我们采纳了软件评审技术，规范了软件开发过程的标准，并积存了实际的软件开发过程数据，为后面的项目治理和过程操纵提供了宝贵的软件过程财宝。
四、总结和展望
在实际工作中，我们往常掌握的过程数据不多，差不多上一步一步摸索着前进，关于过程数据也在不断的收集及整理中。
关于评审技术而言，其中最重要的一点是采纳多种实际工具和手段，如针对每个过程进行评审的《缺陷检查表》等，我们也在逐步地完善这套体系和过程数据，从而为我们的过程改进不断提供支持。
升级会员 