软件评审郑人杰.doc

软 件 评 审 郑人杰 2001／03 ? 目 录 一、软件评审方法 二、 软件项目评审实例 三、软件评审的定义 1、 软件缺陷 2、 评审 四、 评审在若干国际标准中的要求 l、 IS0／IEC 12207 2、 IS0 900l： 2000 3、 CMM 五、软件评审的作用 1、 及时清除开发中引入的缺陷 2、 提高软件生产率，降低消除缺陷的成本 3、 为项目监控提供信息 4、 找出测试无法发现的问题 5、 积累经验，吸取教训 六、 正式评审的实施 1、 组建评审组 2、 组长职责 3、 评审准备 4、 评审会 5、 评审原则 七、 评审实践中所显示的效益 八、 实施软件评审经常出现的问题 九、做好软件评审的建议 一、 软件评审方法 一一软件工程过程一个重要的质量保证手段 一一是软件测试不可代替的 一一最早于1972年IBM公司实施了M．E．hgan提出的代码检查法 一一实践表明了它的效果，后推广到针对需求、设计以至管理 一一许多软件工程标准都对其作了规范化要求 一一被广泛采用后，展开成各种形式和不同的称呼，但本质上无太大区别。 如： InSpeC“On， RevieW， FOYmal Rcview(正式评审)，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在软件评审和审核标准(1EEEStandard for Softwafe ReviCWS and Audits)中说：软件评审是一种对软件元素所作的正式