软件评审郑人杰.docx
《软件评审郑人杰.docx》由会员分享，可在线阅读，更多相关《软件评审郑人杰.docx（26页珍藏版）》请在冰点文库上搜索。
软件评审郑人杰
软件评审
郑人杰
2001／03
一、软件评审方法
二、软件项目评审实例
三、软件评审的定义
1、软件缺陷
2、评审
四、评审在若干国际标准中的要求
l、IS0／IEC12207
2、IS0900l：
2000
3、CMM
五、软件评审的作用
1、及时清除开发中引入的缺陷
2、提高软件生产率，降低消除缺陷的成本
3、为项目监控提供信息
4、找出测试无法发现的问题
5、积累经验，吸取教训
六、正式评审的实施
1、组建评审组
2、组长职责
3、评审准备
4、评审会
5、评审原则
七、评审实践中所显示的效益
八、实施软件评审经常出现的问题
九、做好软件评审的建议
一、软件评审方法
一一软件工程过程一个重要的质量保证手段
一一是软件测试不可代替的
一一最早于1972年IBM公司实施了M．E．hgan提出的代码检查法
一一实践表明了它的效果，后推广到针对需求、设计以至管理
一一许多软件工程标准都对其作了规范化要求
一一被广泛采用后，展开成各种形式和不同的称呼，但本质上无太大区别。
如：
InSpeC“On，RevieW，FOYmalRcview（正式评审），PeerReview（同行评审），Buddy
check，Walkthrough（走查）。
以下着重介绍正式评
软件评审不充分导致系统灾难性事故的实例
一一时间：
1996年6月4日
一一事件：
欧洲宇航局ESA首次发射阿丽亚娜5型运载火箭
（ARIANA501）失败
一一现象：
在发射现场火箭点火升空37秒后，突然偏离飞行路
线，并迅速解体爆炸
一一损失：
●发射基地当场6名法国士兵死亡
●昂贵的研制和发射费用
●推迟了原定的航天计划．
一一事故调查：
●由欧洲宇航局长为首组织了9位英、法、德、意等国专家组成调查委员会
●提出调查报告。
一一事故原因：
●火箭惯性导航系统控制软件设计存在缺陷，
●设计评审进行得不够充分，未能发现阿丽亚娜5型的惯性导航控制软件沿用阿丽亚娜4型的部分控制软件是不恰当的一一教训：
报告总结分析事故原因后，提出14项建议，其中多处提到评审，如：
●对每一个与软件相关的项目，都要组织专门的软件合格性评审
●要评审所有飞行软件，包括嵌入软件
●评审应吸收项目以外的人员参与
一一借鉴：
我国航天部门对此事故十分重视，专门发布一期《故障和事故信息通报》，题为：
“阿丽亚娜501飞行失败的启示”。
三、软件评审的定义
1、软件缺陷（Defect）
（1）缺陷是对软件产品预期属性的偏离现象：
一一对产品规格说明（Specifications）的偏离。
如：
规格说明规定：
a+b：
>c，而实际产品不是。
一一对客户／用户期望的偏离，客户／用户要求未纳入产品中（可能是规格说明疏漏，也可能实现有问题）。
一一Fau“在硬件中称为故障，在软件中它和Defect同义。
（2）缺陷有三种：
。
一一错误（Wrong）：
未将规格说明正确实现（对规格说明的偏离）。
一一遗漏（Missing）：
规定的或预期的需求未体现在产品中（可能未将规格说明全面实现，也可能在开发过程中，甚至在其后追加了客户需求）。
一一额外的实现（extra）：
规格说明未规定的需求被纳入产品加以实现（也许是用户期望的属性，但只能被当作缺陷）。
（3）缺陷和事故（Failures）
一一机械与建筑的比喻
一一缺陷是软件内部的“裂缝”。
在未影响到用户和系统运行时，并未表现出来。
一一当缺陷引发运行错误（hror）或产生负面影响时，构成事故，对我们造成伤害。
2、评审（Review）
一一IEEE定义：
评审是软件开发组之外的人员或小组对软件需求、设计或代码进行详细审查的一种正式评价方法。
其目的在于发现其中的缺陷，找出违背执行标准的情况以及其它问题。
一一1994年，IEEE在软件评审和审核标准（1EEEStandardforSoftwafeReviCWSandAudits）中说：
软件评审是一种对软件元素所作的正式的、同行间的评审活动，其目的在于验证软件元素满足其规格说明，并能符合标准的要求。
一一与通过评审会来实施的正式评审不同，走查通常是非正式的，特别是针对程序而言。
一一软件评审通常针对技术产品，如需求规格说明、系统设计文档、详细设计、代码或测试计划等。
过程名
对评审（评价）要求的摘要
5．1
获取过程
需方对供方交付的软件产品和服务进行验收评审
5．2
供应过程
供方应与需方共同对交付的软件产品和服务进行验收评审
5．3
开发过程
对各项开发活动进行评审或评价
5．5
维护过程
维护者与授权修改的组织一起实施评审，以确定修改后系统的完整性
6．1
文档编制过程
编制的文档对照文档编制标准进行评审，以达到格式、技术内容和表达方式的要求
6．6
联合评审过程
项目管理评审：
针对计划、进度、标准和指南等对项目状态作出评价
技术评审：
评价产品和服务的完整性、变更的正确性等
6．8
问题解决过程
对问题解决的结果进行评价，其中一种评价方式是评审
7．1
管理过程
管理者评价产品能满足需求，能达到预期目标，完成项目计划
7．3
改进过程
组织评价过程的适合性、有效性
7．4
培训过程
组织对培训要求进行评审
国际标准IS09001：
2000质量管理体系一一要求中对评审
章节号
标题
对评审要求的摘要
5.1
管理承诺
最高管理者应通过管理评审等活动对其建立和改进质量管理体系的承诺提供证据
5.3
质量方针
最高管理者应确保质量方针，提供制定和评审质量目标的框架
5.5.6
文件控制
质量管理体系所要求的文件应得到评审
5.6
管理评审
最高管理者应按计划的时间间隔评审质量管理体系
7.2.2
产品要求的评审
组织应对已识别的顾客要求连同组织确定的附加要求实施评审
7.2.1
设计和／或开发的策划
组织应在产品设计和／或开发的策划中确定，适合每个设计和／或开发阶段的评审活动
7.3.4
设计和／或开发的评审
在适当阶段，对设计和／或开发应进行系统的评审；评审的参加者应包括与所评审的设计和／或开发阶段有关职能的代表；评审的结果应予以记录
7.2.7
设计和／或开发更改的控制
设计和／或开发更改评审的结果应形成丈件
8.5.1
持续改进的策划
组织应通过管理评审促进质量管理体系的持续改进
8.5.2
纠正措施
组织应评审所采取的纠正措施
8.5.3
预防措施
组织应评审所采取的预防措施
软件过程能力成熟度模型CMM
（1）CMM2级KPA中对评审的要求
关键过程域
共同特点
评审负责人
评审内容
需求管理
活动
SEPC
分配的需求
SEPC
分配需求的更改
验证
高级管理者
管理分配需求的活动
项目经理
管理分配需求的活动
SOAC
管理分配需求的活动和工作产品
软件项目
策划
能力活动
项目经理
工作描述（SOW）
SEPG
项目计划
高级管理者
软件项目的约定
项目经理等
软件开发计划
项目规模估计
软件进度表
对关键计算机资源的估计
受影响组
项目软件工程设施和支持工具计划
验证
高级管理者
软件项目策划活动
项目经理
软件项目策划活动
SQAG
软件项目策划活动和工作产品
软件项目跟踪与监督
活动
高级管理者
软件项目约定以及约定的更改
项目经理
软件风险
SEPC
软件开发计划进展、完成情况和结果
验证
高级管理者
软件项目跟踪和监督活动
项目经理
SQAG
软件子合同管理
活动
项目经理等
子合同上作描述
选择子承包商计划
子合同投标者的能力
承包商
子承包商软件开发计划
子承包商
约定得到满足
子承包商软件工程完成情况和结果
主承包商
批准的规程和标准得到遵循
子承包商SCM计划、资源、规程和标准
主、子承包商
产品验收规程和验收准则
评价软件子承包商的工作
验证
高级管理者
软件子合同管理的活动
项目经理
软件子合同管理的活动
SQAG
软件子合同管理的活动和工作产品
软件
质量保证
活动
受影响
组和人员
软件项目SQA计划
SQAC
项目的软件开发计划、规程和标准
软件工程活动
SQAG与顾客
SQA活动与发现的问题
验证
高级管理者
SQA活动
项目经理
SQA活动
独立于SQAC的专家
SQA活动和工作产品
软件配置
管理
能力
SCCB
软件基线的更改
活动
受影响的组
SCM计划
配置项或单元的更改请求和问题报告
验证
高级管理者
SCM活动
项目经理
SCM活动
SQAC
SCM活动及工作产品
注：
SEPG：
软件工程过程组
SQA：
软件质量保证
SQAG：
软件质量保证组
SCM：
软件配置管理
SCCB：
软件配置控制委员会
（2）Cbm：
3级关键过程域：
同行评审（PcerReview）
目的
1、及时。
高效地从软件工作产品中消除缺陷
2、同时可对软件工作产品及可避免的缺陷有更好的了解
目标
l、按计划实施
2、识别和消除在软件工作产品中的缺陷
共同特征
约定
项目要遵循实施同行评审的组织方针
能力
1、为评审提供足够的资源和资金
2、同行评审的负责人接受如何领导同行评审的培训
3、同行评审的参加者接受评审要求（对象、原则、方法）的培训
活动
1、对评审进行策划，计划形成文件
2、根据丈件化的规程实施同行评审
3、记录有关同行评审的执行情况和结果的数据
测量
进行测量并将测量结果用于确定同行评审活动的状态
验证
软件质量保证组评审和（或）审核同行评审的活动和工作产品，并报告其结果
`
升级会员 