技术评审.doc

完整word)技术评审
技术评审
在工作中，我们经常可以听到以下的声音：
“我们不进行评审，是因为我们项目比较特殊，没有时间……”。
“我们的项目已经进行了测试，不需要再进行评审了”。
“评审都是在走过场，没有效果……”。
业界公认评审是质量控制最有效的手段之一，但评审在很多公司却没能很好地实施，甚至没有实施，公司也未能从中获益.一方面因为员工不清楚评审的目的、评审和测试的区别，认为评审只不过是除了测试以外的锦上添花的过场.另一方面也因为许多公司制定的评审流程流于形式，缺乏可操作性，也未对员工进行评审流程的培训，未能在评审流程执行过程中提供适当的指导和监督。
Why-为什么要技术评审？
测试无疑是质量控制最常用的方法之一，因此很多公司认为对产品进行了测试就万事大吉了。而评审是一种在产品开发过程中尽早发现缺陷的手段。根据IBM的统计数据显示：大多数企业的产品开发中,2/3的缺陷都是在需求和设计阶段引入的。因此,通过评审尽早发现的缺陷的修复成本远低于在产品开发后期测试中发现的缺陷的修复成本。
缺乏技术评审，或未严格进行技术评审的后果往往会导致测试阶段发生缺陷的“井喷”,开发人员不得不拼命加班“救火”，而最终由于缺陷越来越多，产品上市时间也所剩无几，不得不遗憾地放弃——产品只能带着缺陷发布给客户，听天由命了。
案例：某产品由于未经严格评审,而匆促上市，结果发现设计指标不符合规格书要求，设计中未考虑工程和维护的问题，产品质量问题多多，生产的单板直通率低，生产效率不高,结果开发工作重新回炉，导致客户投诉不断，用户怨声载道，严重影响用户关系和公司产品形象;导致所有开发人员全部出去救火，开发周期大大加长,开发投入增加，库存积压占用资金.
评审的目的在于:越早发现问题，总体成本越低，因此要评审,评审，再评审！等到测试已经太迟了！
What—什么是技术评审？
测试和技术评审都是有效的质量控制手段，但也有明显的区别。
类似地，技术评审和测试的目的都是为了寻找缺陷，寻找缺陷的目标不是证明它是正确的，而是证明产品不能工作.
测试是在产品运行时进行的动态分析测试的对象为原型、中间产品和最终产品.相对地，评审是一种静态分析,评审对象通常是技术文档、计划、测试用例和测试数据、测试结果等.
How- 如何做好技术评审？
1. 技术评审常见的问题
许多公司虽然执行了技术评审,但却未能从中获益，这往往是因为以下的原因导致的：
。没有评审计划，没有充分的准备
.专家选择不合适
.评审会议偏离主题和重点,过多争论占用大量时间
.没有使用Checklist作为指导
.问题修改后跟踪不力……
由此可见，评审效率不高的原因主要是因为缺乏可操作的评审规程、评审执行和跟踪不力导致的。因此，针对不同类型的工作产品，应制定包括多种评审类型的规程并借助检查单的使用来提高评审的可操作性.
2。 常见的技术评审的类型
常见的技术评审包括了走查（Walkthrough)、轮查（Pass Around）、正式的同行评审（Peer Reviews）等。
1) 走查(Walkthrough）：是大名鼎鼎的面向对象方法学的开发者之一Yourdon 定义的方法,它由作者启动和主持评审，作者向评审者展示文档。优点是启动快，成本低，缺点是容易被作者误导过程。
2) 轮查(Pass Around）:作者向评审者作简要介绍，但不参加评审过程；评审者独立进行评审，并记录发现结果、准备报告。
3) 同行评审：评审者与作者是地位平等的同行/专家，而不是领导对员工的评价；是最为结构化的评审方法；可以作为同行之间学习和分享经验的机会.
3。 同行评审简介
在软件CMM中首次提出了同行评审（Peer Reviews）这个概念，它的目标是在产品开发过程中尽早发现缺陷，从而以较低的成本尽早解决缺陷。这种方法借鉴了IBM的范根检查法（Fagan Inspection）的优点，是一种结构化的正式的评审方法.
同行评审有明确的角色定义:
。协调员（Moderator）：保证评审按流程进行。
.朗读者（Reader):评审的技术领导，把焦点放在有争议的问题方面。
.记录员(Recorder）：负责记录缺陷.
。评审员（Reviewer)：负责发现缺陷，除了作者外，所有的其他角色都可以担任评审员。
。作者（Author）：负责修正缺陷.
同行评审通常包括六个步骤：制定计划、召开准备会议、评审人员独立预审、召开评审会议、返工、跟进返工结果。各个步骤的活动说明如下：
1) 计划：选择参与者;准备检查单。
2) 准备会：分配各参与人员的角色；作者对产品作概要介绍.
3） 个人预审:评审者研究评审文档，使用检查单寻找缺陷，记录发现结果。
4) 评审会议：读者阅读评审文档，评审员发现缺陷,对有争议的问题进行讨论；作者一般保持沉默，除非读者要求对产品作解释。
5) 返工：作者修正错误.
6） 跟进：检查修正工作的进展；分析错误原因；分析评审过程，补充完善检查单.
附：做好技术评审的小贴士
.不因为时间紧迫和缺少预算而省略评审
。评审前充分准备和沟通
.安排合理的预审时间以便评审人员阅读评审材料
。技术评审应当“就是论事”，不要把评审会开成“批斗会”,不要打击有失误的开发人员的工作积极性，更不准搞人身攻击，如挖苦、讽刺等
.评审人员的职责是发现工作成果中的缺陷,并帮助开发人员给出消除缺陷的办法，而不是替开发人员消除缺陷
.把技术评审作为交流、提高的机会
。记录评审中出现的问题，跟踪改进
。定期改进技术评审检查单，把检查单作为持续改进的重要载体
。评审者必须是领域内的专家
When—常见的技术评审点举例
在对工作产品建立基线之前进行评审,目的是发现缺陷。
常见的技术评审点举例:
产品开发中,TR是技术评审节点。

下面是某产品的技术评审点，供参考:
TR2中使用的检查要素节选:
TR1-—概念阶段技术评审点：产品需求和概念技术评审（业务需求评审)
TR2——计划阶段技术评审点1：需求分解和需求规格评审（功能需求评审，产品级规格)
TR3-—计划阶段技术评审点2:总体方案评审（系统设计，架构设计，概要设计）
TR4—-开发阶段技术评审点1：模块/系统评审（详细设计,BBFV测试结果)
TR4A—-开发阶段技术评审点2：原形机的质量SDV结果和初始产品的准备情况
TR5——开发阶段技术评审点3：初始产品的质量（SIT结果)（SIT Alpha测试技术评审）
TR6——验证阶段技术评审点：发布评审(SVT Beta测试、制造系统验证等)

SDV就是system design verification，即系统设计验证
BBFV就是building block fuction verification，即编译模块功能验证
SIT就是system integration testing,即系统集成测试
SVT就是system verification testing,系统验证测试

正规技术评审
正规技术评审（Formal Technical Review），是一种的同行审查技术。其主要特点是由一组评审者按照规范的步骤对软件需求、设计、代码或其他技术文档进行仔细地检查，以找出和消除其中的缺陷.正规技术评审也称作“正规审查”（Formal Inspection）或简称“审查”（Inspection）。
　　正规技术评审目的
　　（1）发现软件在功能、逻辑、实现上的错误；
　　（2）验证软件符合它的需求规格；
　　（3）确认软件符合预先定义的开发规范和标准;
　　（4)保证软件在统一的模式下进行开发；
　　（5）便于项目管理。
　　此外,正规技术评审为新手提供软件分析、设计和实现的培训途经，后备、后续开发人员也可以通过正规技术评审熟悉他人开发的软件.
　　评审小组成员
　　评审小组至少由3人组成(包括被审材料作者），一般为4至7人。通常，概要性的设计文档需要较多评审人员,涉及详细技术的评审只需要较少的评审人员。
　　评审小组应包括下列角色：
　　评审员（Reviewer、Inspector）
　　评审小组中的每一成员，无论他（她）是否是主持人、作者、宣读员、记录员,都是评审员。他们的职责是在会前准备阶段和会上检查被审查材料,找出其中的缺陷。
　　合适的评审员人选包括被审材料在生命周期中的前一阶段、本阶段和下一阶段的相关开发人员。例如，需求分析评审员可以包括客户和概要设计者，详细设计和代码的评审员可以包括概要设计者、相关模块开发人员、测试人员。
　　主持人（Moderator）
　　支持人的主要职责,在评审会前负责正规技术评审计划和会前准备的检查；在评审会中负责调动每一个评审员在评审会上的工作热情,把握评审会方向,保证评审会的工作效率；在评审会后负责对问题的分类及问题修改后的复核。
　　宣读员（Reader)
　　宣读员的任务是在评审会上通过朗读和分段来引导评审小组遍历被审材料.除了代码评审可以选择作者作为宣读员外，其他评审最好选择直接参与后续开发阶段的人员作为宣读员。
　　记录员(Recorder）
　　记录员负责将评审会上发现的软件问题记录在技术评审问题记录表”.在评审会上提出的但尚未解决的任何问题以及前序工作产品的任何错误都应加以记录。
　　作者（Author）
　　被审材料的作者负责在评审会上回答评审员提出的问题,以避免明显的误解被当作问题。此外，作者须负责修正在评审会上发现的问题。
　　正规技术评审活动过程
　　计划
　　由项目经理指定的主持人检查作者提交的被审材料是否齐全，是否满足评审条件，例如，代码应通过编译后才能参加评审。主持人确定评审小组成员及职责，确定评审会时间、地点。主持人向评审小组成员分发评审材料。评审材料应包括：被审材料、检查要点列表（Checklist）和相关技术文档。
　　预备会
　　如果评审小组不熟悉被审材料和有关背景,主持人可以决定是否召开预备会。在预备会上,作者介绍评审理由、被审材料的功能、用途及开发技术。
　　会前准备
　　在评审会之前,每一位评审员应根据检查要点逐行检查被审材料，对发现的问题做好标记或记录。主持人应了解每一位评审员会前准备情况，掌握在会前准备中发现的普遍问题和需要在评审会上加以重视的问题.会前准备是保证评审会效率的关键之一.如果会前准备不充分，主持人应重新安排评审会日程.
　　评审会
　　评审会由主持人主持,由全体评审员共同对被审材料进行检查。宣读员逐行朗读或逐段讲解被审材料.评审员随时提出在朗读或讲解过程中发现的问题或疑问，记录员将问题写入“技术评审问题记录表".必要时，可以就提出的问题进行简短的讨论.如果在一定时间内（由主持人控制）讨论无法取得结果，主持人应宣布该问题为“未决"问题,由记录员记录在案。在评审会结束时，由全体评审员作成评审结论。主持人在评审会结束后对“技术评审问题记录表”中问题进行分类。
　　修正错误
　　作者对评审会上提出的问题进行修正。
　　复审
　　如果被审材料存在较多的问题或者较复杂的问题，主持人可以决定由全体评审员对修正后的被审材料再次举行评审会。
　　复核
　　主持人或主持人委托他人对修正后的被审材料进行复核,检查评审会提出的并需要修正的问题是否得到解决.主持人完成“技术评审总结报告”。
　　正规技术评审注意事项
　　（1）评审应针对被审材料而不是被审材料的作者。评审会的气氛应该保存轻松、愉快，指出问题的语气应该温和。
　　（2）每次评审会的时间最好不要超过2小时。当被审材料较多时，应将被审材料分为若干部分分别进行评审。
　　（3)限制争论和辩驳.在评审会上，对于一时无法取得一致意见的问题，应先记录在案，另行安排时间进行深入讨论。
　　（4)阐明问题而不要试图解决问题。不要在评审会上解决发现的问题，可以在会后由作者自己或在个别人的帮助下解决这些问题.

论评审在项目质量管理过程中的重要作用
评审工作贯穿信息系统项目始终.评审是确保项目质量的重要手段之一，在项目管理过程中，系统地运用评审方法可以起到事半功倍的效果。
作业
请围绕“评审在项目质量管理过程中的重要作用”论题，分别从以下三个方面进行论述：
1、 什么是技术评审？什么是阶段管理评审？简要论述技术评审和阶段管理评审对保证项目质量的重要作用。
2、 质量保证人员（QA）的角色和职责有哪些？
3、 结合你的项目管理经验，系统地论述你是如何运用评审方法来确保项目质量的，着重介绍评审活动的组织、人员构成和评审过程.

设计评审
出自 MBA智库百科（http：//wiki.mbalib。com/）
设计评审(Design Reviews)
什么是设计评审
　　所谓设计评审，是指对设计所作的正式的、综合性的和系统性的审查，并写成文件，以评定设计要求与设计能力是否满足要求，识别其中的问题，并提出解决办法.设计评审是对一项设计进行正式的、按文件规定的、系统的评估活动，由不直接涉及开发工作的人执行。设计评审可采用向设计组提建议或帮助的形式，或就设计是否满足客户所有要求进行评估。在产品开发阶段通常进行不只一次的设计评审。
设计评审主要解决的问题
　　设计评审主要解决下列几个问题：
　　1、纠正设计质量“至善论”；
　　2、打破产品设计垄断；
　　3、防止产品设计的片面性.
[编辑］
实施设计评审的作用
　　①评价设计是否满足合同要求,是否符合设计规范及有关标准、准则
　　②发现和确定设计的薄弱环节和可靠性风险较高的区域，研 讨并提出改进意见；
　　③对研制试验、程序和维修资源进 行预先的考虑；
　　④检查和监督可靠性大纲的全面实施;
　　⑤减少设计更改，缩短研制周期,降低寿命周期费用。

软件配置管理中的三个基线概念：
功能基线（Functional Baseline）
　　功能基线指在系统分析与软件定义阶段结束时，在经过正式评审和批准的系统设计规格说明书中对开发系统的规格说明;或是指在经过项目委托单位和项目承办单位双方签字同意的协议书或合同中，所规定的对开发软件系统的规格说明;或是由下级申请并经上级同意或直接由上级下达的项目任务书中所规定的对开发软件系统的规格说明。功能基线是最初批准的功能配置标识。

分配基线(Allocated Baseline）

　　分配基线指在软件需求分析阶段结束时,经过正式评审和批准的软件需求规格说明。分配基线是最初批准的分配配置标识。

　产品基线（Product Baseline）

产品基线指在软件组装与系统测试阶段结束时，经过正式评审和批准的有关软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。
产品基线是指在软件集成与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。
产品基线是最初批准的产品配置标识
几点说明：
1、产品基线由一系列配置项组成；
2、产品基线往往是通过“功能测试"来验证；
3、产品基线是对一系列配置项的说明，是一份清单；
4、产品基线是产品发布的依据;
软件开发生命周期模型决定产品基线发布的频率和时机。一般，一个RDCT（Requirement-Design—Coding-Test）产生一个Release的产品基线。

RUP原文：
建立基线的三大原因是:重现性、可追踪性和报告。
重现性是指及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。可追踪性建立项目工件之间的前后继承关系.其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。报告来源于一个基线内容同另一个基线内容的比较。基线比较有助于调试并生成发布说明。

建立基线后,需要标注所有组成构件和基线，以便能够对其进行识别和重新建立.
建立基线有以下几个优点：

基线为开发工件提供了一个定点和快照。
新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
各开发人员可以将建有基线的构件作为他在隔离的私有工作区中进行更新的基础。
当认为更新不稳定或不可信时,基线为团队提供一种取消变更的方法。
您可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现已报告的错误。
使用

定期建立基线以确保各开发人员的工作保持同步。但是，在项目过程中，应该在每次迭代结束点（次要里程碑），以及与生命周期各阶段结束点相关联的主要里程碑处定期建立基线：
生命周期目标里程碑（先启阶段）
生命周期构架里程碑（精化阶段)
初始操作性能里程碑（构建阶段）
产品发布里程碑(产品化阶段）