软件评审规范.ppt

软件评审规范.ppt

《软件评审规范.ppt》由会员分享，可在线阅读，更多相关《软件评审规范.ppt（34页珍藏版）》请在冰点文库上搜索。

第7章软件评审,7.1软件评审概述7.1.1评审目的评审的目的是检验软件开发、软件评测各阶段的工作是否齐全、规范，各阶段产品是否达到了规定的技术要求和质量要求，以决定是否可以转入下一阶段的工作。

7.1软件评审概述,7.1.2评审阶段的划分

（1）系统分析与设计；

（2）软件需求分析；（3）软件概要设计；（4）软件详细设计；（5）编码和单元测试；（6）软件部件测试；（7）软件配置项测试；（8）软件系统测试；（9）系统验收。

7.1软件评审概述,7.1.3评审的组织与管理1内部评审内部评审是由承办方组织的评审。

2外部评审外部评审是由交办方组织的评审，特殊情况下，交办方可委托其他单位代理组织外部评审。

7.2需求评审,7.2.1需求评审概述软件需求是软件开发的最重要的一个步骤，需求的质量很大程度上决定了项目质量或产品质量。

需求评审是所有的评审活动中最难的一个，也是最容易被忽视的一个评审。

深入的问题。

以下是一些失败的需求评审案例,失败的需求评审:

案例,某领域专家A先生就某企业的成本管理系统做用户需求报告的评审工作在评审会开始时间不长，就被在场的某企业的一位副总B先生打断，认为A先生提出的方案不适合本企业，A先生提出的管理改进方案在企业中无法实施该副总提完意见后，与会的用户方人员纷纷跟随B先生的提出了他们的反对意见，致使评审会无法再进行下去，最终该报告被用户否决。

失败的需求评审:

案例,某软件公司内部举行产品的需求评审会，主要是公司内部的相关领域的专家参加在评审会开始后不久，某领域专家就对需求报告中的某个具体问题提出了自己的不同意见与会人员纷纷就该问题发表自己的意见大家争执不下，结果，致使会议出现了混乱状况，主持人无法控制局面，会议大大超出了计划评审时间。

失败的需求评审:

案例,某软件公司为某公司A做业务流程管理系统的需求评审会当项目组人员在会议上宣读多达上百页的需求报告时，用户明确提出听不懂，致使会议不得不改日进行。

失败的需求评审:

案例,某软件公司在用户处开完物资管理系统的需求评审会后，与会人员在离开会议室时纷纷摇头，认为本次会议没有多少实际效果，完全是在走过场。

某软件公司在公司内部举行产品的需求评审会时，需求报告的执笔人与产品策划的主要策划人员的想法差别很大，致使需求评审会没有必要继续进行下去。

问题总结,以上的现象可以在很多项目中都可以看到。

概括起来，在需求评审中经常存在以下问题：

需求报告很长，短时间内评审者根本不能把需求报告读懂，想清楚没有作好前期准备工作，需求评审的效率很低需求评审的节奏无法控制找不到合格的评审员，与会的评审员无法提出深入的问题,7.2需求评审,7.2.2如何做好需求评审

（1）分层次评审

（2）正式评审与非正式评审结合（3）分阶段评审（4）精心挑选评审员（5）对评审员进行培训（6）充分利用需求评审检查单（7）建立标准的评审流程（8）做好评审后的跟踪工作（9）充分准备评审,分层次评审,用户的需求层次：

目标性需求：

定义了整个系统需要达到的目标（高层管理人员关注）功能性需求：

定义了整个系统必须完成的任务（中层管理人员关注）操作性需求：

定义了完成每个任务的具体的人机交互（具体操作人员关注）,正式评审与非正式评审结合,正式评审：

开评审会，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责非正式评审：

不需要将人员集合在一起，通过电子邮件、网络聊天等多种形式有时，非正式的评审比正式的评审效率更高，更容易发现问题,分阶段评审,在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审将原本需要进行的大规模评审拆分成各个小规模的评审降低了需求返工的风险，提高了评审的质量,精心挑选评审员,需求评审可能涉及的人员：

需方：

高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管供方：

市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等,精心挑选评审员,这些人员所处的立场不同，对同一个问题的看法是不相同的，不同的观点可能形成互补的关系要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则使评审的效率降低,对评审员进行培训,很多情况下，评审员是领域专家而不是进行评审活动的专家，没有掌握进行评审的方法、技巧、过程等，需要培训对于主持评审的管理者也需要进行培训，使参与评审的人员能够围绕评审的目标来进行，能控制评审节奏，提高评审效率,充分利用需求评审检查单,需求检查单：

需求形式检查单和需求内容检查单。

需求形式检查：

由QA人员负责，主要是针对需求文挡的格式是否符合质量标准需求内容检查：

是由评审员负责，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等检查单可以帮助评审员系统全面地发现需求中的问题检查单随着工程经验的积累逐渐丰富和优化,建立标准的评审流程,需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程,做好评审后的跟踪工作,根据评审人员提出的问题进行评价：

确定哪些问题必须纠正（给出理由与证据）：

书面的需求变更申请，进入需求变更的管理流程，并确保变更的执行。

在变更完成后，要进行复审。

切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流,充分准备评审,评审质量与评审会议前的准备活动关系密切。

常见问题：

（1）需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。

（2）没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误评审准备，应当定义一个检查单，在评审之前对照检查单落实每项准备工作。

7.3概要设计评审,开始时间：

软件概要设计结束后评审内容：

（1）总体结构

（2）外部接口（3）主要部件功能分配（4）全局数据结构（5）各主要部件之间的接口,一般应考察以下几个方面：

（1）概要设计说明书是否与软件需求说明书的要求一致

（2）概要设计说明书是否正确、完整、一致（3）系统的模块划分是否合理（4）接口定义是否明确（5）文档是否符合有关标准规定,7.4详细设计评审,开始时间：

软件详细设计阶段结束后一般应考察以下几个方面：

（1）详细设计说明书是否与概要设计说明书的要求一致

（2）模块内部逻辑结构是否合理，模块之间的接口是否清晰（3）数据库设计说明书是否完全，是否正确反映详细设计说明书的要求（4）测试是否全面、合理（5）文档是否符合有关标准规定,7.5数据库设计评审,在数据库设计阶段结束后必须进行数据库设计评审，以评价数据库的结构设计及运用设计的合适性。

一般应考察以下几个方面：

（1）概念结构设计；

（2）逻辑结构设计；（3）物理结构设计；（4）数据字典设计；（5）安全保密设计。

7.6测试评审,测试评审主要对测试的各个环节进行评审，包括：

（1）“软件测试需求规格说明”评审；

（2）“软件测试计划”评审；（3）“软件测试说明”评审；（4）“软件测试报告”评审；（5）“软件测试记录”评审。