软件评审规范 PPT课件
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
该副总提完意见后，与会的用户方人员纷纷跟 随B先生的提出了他们的反对意见，致使评审 会无法再进行下去，最终该报告被用户否决。
失败的需求评审:案例
某软件公司内部举行产品的需求评审会，主要 是公司内部的相关领域的专家参加
在评审会开始后不久，某领域专家就对需求报 告中的某个具体问题提出了自己的不同意见
7.1软件评审概述
7.1.3评审的组织与管 外部评审是由交办方组织的评审，特
殊情况下，交办方可委托其他单位代理组 织外部评审。
7.2需求评审
7.2.1 需求评审概述
软件需求是软件开发的最重要的一个步骤，需求的质 量很大程度上决定了项目质量或产品质量。
第7章 软件评审
7.1软件评审概述
7.1.1评审目的 评审的目的是检验软件开发、软件评测
各阶段的工作是否齐全、规范，各阶段产品 是否达到了规定的技术要求和质量要求，以 决定是否可以转入下一阶段的工作。
7.1软件评审概述
7.1.2评审阶段的划分 （1）系统分析与设计； （2）软件需求分析； （3）软件概要设计； （4）软件详细设计； （5）编码和单元测试； （6）软件部件测试； （7）软件配置项测试； （8）软件系统测试； （9）系统验收。
分阶段评审
在需求形成的过程中进行分阶段的评审，而 不是在需求最终形成后再进行评审
将原本需要进行的大规模评审拆分成各个小 规模的评审
降低了需求返工的风险，提高了评审的质量
精心挑选评审员
需求评审可能涉及的人员： 需方：高层管理人员、中层管理人员、具体
操作人员、IT主管、采购主管 供方：市场人员、需求分析人员、设计人员、
7.5 数据库设计评审
在数据库设计阶段结束后必须进行数据库设计 评审，以评价数据库的结构设计及运用设计的合适 性。
一般应考察以下几个方面： （1）概念结构设计； （2）逻辑结构设计； （3）物理结构设计； （4）数据字典设计； （5）安全保密设计。
7.6测试评审
测试评审主要对测试的各个环节进行评审，包括： （1）“软件测试需求规格说明”评审 ； （2）“软件测试计划”评审 ； （3）“软件测试说明”评审 ； （4）“软件测试报告”评审 ； （5）“软件测试记录”评审 。
问题总结
以上的现象可以在很多项目中都可以看到。概 括起来，在需求评审中经常存在以下问题： 需求报告很长，短时间内评审者根本不能把需 求报告读懂，想清楚 没有作好前期准备工作，需求评审的效率很低 需求评审的节奏无法控制 找不到合格的评审员，与会的评审员无法提出 深入的问题
7.2需求评审
7.2.2 如何做好需求评审
务 （中层管理人员关注 ） 操作性需求：定义了完成每个任务的具体的
人机交互 （具体操作人员关注）
正式评审与非正式评审结合
正式评审：开评审会，组织多个专家，将需 求涉及到的人员集合在一起，并定义好参与 评审人员的角色和职责
非正式评审：不需要将人员集合在一起，通 过电子邮件、网络聊天等多种形式
有时，非正式的评审比正式的评审效率更高， 更容易发现问题
失败的需求评审:案例
某软件公司在用户处开完物资管理系统 的需求评审会后，与会人员在离开会议 室时纷纷摇头，认为本次会议没有多少 实际效果，完全是在走过场。
某软件公司在公司内部举行产品的需求 评审会时，需求报告的执笔人与产品策 划的主要策划人员的想法差别很大，致 使需求评审会没有必要继续进行下去。
常见问题： （1）需求文档在评审会议前并没有提前下发给参与评审会议的
人员，没有留出更多更充分的时间让参与评审的人员阅读需 求文档。 （2）没有执行需求评审的进入条件，在评审文档中存在大量的 低级的错误或者没有在评审前进行沟通，文档中存在方向性 的错误
评审准备，应当定义一个检查单，在评审之前对照检查单落 实每项准备工作。
测试人员、质量保证人员、实施人员、项目 经理以及第三方的领域专家等等
精心挑选评审员
这些人员所处的立场不同，对同一个问题的看法是 不相同的，不同的观点可能形成互补的关系
要保证使不同类型的人员的都要参与进来，否则很 可能会漏掉了很重要的需求
不同类型的人员中要选择那些真正和系统相关的， 对系统有足够了解的人员参与进来，否则使评审的 效率降低
需求评审是所有的评审活动中最难的一个，也是最容 易被忽视的一个评审。深入的问题。
以下是一些失败的需求评审案例
失败的需求评审:案例
某领域专家A先生就某企业的成本管理系统做 用户需求报告的评审工作
在评审会开始时间不长，就被在场的某企业的 一位副总B先生打断，认为A先生提出的方案不 适合本企业，A先生提出的管理改进方案在企 业中无法实施
7.3概要设计评审
开始时间：软件概要设计结束后 评审内容： （1）总体结构 （2）外部接口 （3）主要部件功能分配 （4）全局数据结构 （5）各主要部件之间的接口
一般应考察以下几个方面： （1）概要设计说明书是否与软件需求说明书
的要求一致 （2）概要设计说明书是否正确、完整、一致 （3）系统的模块划分是否合理 （4）接口定义是否明确 （5）文档是否符合有关标准规定
与会人员纷纷就该问题发表自己的意见 大家争执不下，结果，致使会议出现了混乱状
况，主持人无法控制局面，会议大大超出了计 划评审时间。
失败的需求评审:案例
某软件公司为某公司A做业务流程管理系 统的需求评审会
当项目组人员在会议上宣读多达上百页 的需求报告时，用户明确提出听不懂， 致使会议不得不改日进行。
对评审员进行培训
很多情况下，评审员是领域专家而不是进行 评审活动的专家，没有掌握进行评审的方法、 技巧、过程等，需要培训
对于主持评审的管理者也需要进行培训，使 参与评审的人员能够围绕评审的目标来进行， 能控制评审节奏，提高评审效率
充分利用需求评审检查单
需求检查单：需求形式检查单和需求内容检查单。 需求形式检查：由QA人员负责，主要是针对需求文
挡的格式是否符合质量标准 需求内容检查：是由评审员负责，主要是检查需求
内容是否达到了系统目标、是否有遗漏、是否有错 误等等 检查单可以帮助评审员系统全面地发现需求中的问 题 检查单随着工程经验的积累逐渐丰富和优化
建立标准的评审流程
需求评审会需要建立正规的需求评审流程， 按照流程中定义的活动进行规范的评审过程
做好评审后的跟踪工作
根据评审人员提出的问题进行评价： 确定哪些问题必须纠正（给出理由与证据）：书面
的需求变更申请，进入需求变更的管理流程，并确 保变更的执行。在变更完成后，要进行复审。
切忌评审完毕后，没有对问题进行跟踪，而无法保 证评审结果的落实，使前期的评审努力付之东流
充分准备评审
评审质量与评审会议前的准备活动关系密切。
（1）分层次评审 （2）正式评审与非正式评审结合 （3）分阶段评审 （4）精心挑选评审员 （5）对评审员进行培训 （6）充分利用需求评审检查单 （7）建立标准的评审流程 （8）做好评审后的跟踪工作 （9）充分准备评审
分层次评审
用户的需求层次： 目标性需求：定义了整个系统需要达到的目
标 （高层管理人员关注） 功能性需求：定义了整个系统必须完成的任
7.4详细设计评审
开始时间：软件详细设计阶段结束后 一般应考察以下几个方面： （1）详细设计说明书是否与概要设计说明书的要求
一致 （2）模块内部逻辑结构是否合理，模块之间的接口
是否清晰 （3）数据库设计说明书是否完全，是否正确反映详
细设计说明书的要求 （4）测试是否全面、合理 （5）文档是否符合有关标准规定
失败的需求评审:案例
某软件公司内部举行产品的需求评审会，主要 是公司内部的相关领域的专家参加
在评审会开始后不久，某领域专家就对需求报 告中的某个具体问题提出了自己的不同意见
7.1软件评审概述
7.1.3评审的组织与管 外部评审是由交办方组织的评审，特
殊情况下，交办方可委托其他单位代理组 织外部评审。
7.2需求评审
7.2.1 需求评审概述
软件需求是软件开发的最重要的一个步骤，需求的质 量很大程度上决定了项目质量或产品质量。
第7章 软件评审
7.1软件评审概述
7.1.1评审目的 评审的目的是检验软件开发、软件评测
各阶段的工作是否齐全、规范，各阶段产品 是否达到了规定的技术要求和质量要求，以 决定是否可以转入下一阶段的工作。
7.1软件评审概述
7.1.2评审阶段的划分 （1）系统分析与设计； （2）软件需求分析； （3）软件概要设计； （4）软件详细设计； （5）编码和单元测试； （6）软件部件测试； （7）软件配置项测试； （8）软件系统测试； （9）系统验收。
分阶段评审
在需求形成的过程中进行分阶段的评审，而 不是在需求最终形成后再进行评审
将原本需要进行的大规模评审拆分成各个小 规模的评审
降低了需求返工的风险，提高了评审的质量
精心挑选评审员
需求评审可能涉及的人员： 需方：高层管理人员、中层管理人员、具体
操作人员、IT主管、采购主管 供方：市场人员、需求分析人员、设计人员、
7.5 数据库设计评审
在数据库设计阶段结束后必须进行数据库设计 评审，以评价数据库的结构设计及运用设计的合适 性。
一般应考察以下几个方面： （1）概念结构设计； （2）逻辑结构设计； （3）物理结构设计； （4）数据字典设计； （5）安全保密设计。
7.6测试评审
测试评审主要对测试的各个环节进行评审，包括： （1）“软件测试需求规格说明”评审 ； （2）“软件测试计划”评审 ； （3）“软件测试说明”评审 ； （4）“软件测试报告”评审 ； （5）“软件测试记录”评审 。
问题总结
以上的现象可以在很多项目中都可以看到。概 括起来，在需求评审中经常存在以下问题： 需求报告很长，短时间内评审者根本不能把需 求报告读懂，想清楚 没有作好前期准备工作，需求评审的效率很低 需求评审的节奏无法控制 找不到合格的评审员，与会的评审员无法提出 深入的问题
7.2需求评审
7.2.2 如何做好需求评审
务 （中层管理人员关注 ） 操作性需求：定义了完成每个任务的具体的
人机交互 （具体操作人员关注）
正式评审与非正式评审结合
正式评审：开评审会，组织多个专家，将需 求涉及到的人员集合在一起，并定义好参与 评审人员的角色和职责
非正式评审：不需要将人员集合在一起，通 过电子邮件、网络聊天等多种形式
有时，非正式的评审比正式的评审效率更高， 更容易发现问题
失败的需求评审:案例
某软件公司在用户处开完物资管理系统 的需求评审会后，与会人员在离开会议 室时纷纷摇头，认为本次会议没有多少 实际效果，完全是在走过场。
某软件公司在公司内部举行产品的需求 评审会时，需求报告的执笔人与产品策 划的主要策划人员的想法差别很大，致 使需求评审会没有必要继续进行下去。
常见问题： （1）需求文档在评审会议前并没有提前下发给参与评审会议的
人员，没有留出更多更充分的时间让参与评审的人员阅读需 求文档。 （2）没有执行需求评审的进入条件，在评审文档中存在大量的 低级的错误或者没有在评审前进行沟通，文档中存在方向性 的错误
评审准备，应当定义一个检查单，在评审之前对照检查单落 实每项准备工作。
测试人员、质量保证人员、实施人员、项目 经理以及第三方的领域专家等等
精心挑选评审员
这些人员所处的立场不同，对同一个问题的看法是 不相同的，不同的观点可能形成互补的关系
要保证使不同类型的人员的都要参与进来，否则很 可能会漏掉了很重要的需求
不同类型的人员中要选择那些真正和系统相关的， 对系统有足够了解的人员参与进来，否则使评审的 效率降低
需求评审是所有的评审活动中最难的一个，也是最容 易被忽视的一个评审。深入的问题。
以下是一些失败的需求评审案例
失败的需求评审:案例
某领域专家A先生就某企业的成本管理系统做 用户需求报告的评审工作
在评审会开始时间不长，就被在场的某企业的 一位副总B先生打断，认为A先生提出的方案不 适合本企业，A先生提出的管理改进方案在企 业中无法实施
7.3概要设计评审
开始时间：软件概要设计结束后 评审内容： （1）总体结构 （2）外部接口 （3）主要部件功能分配 （4）全局数据结构 （5）各主要部件之间的接口
一般应考察以下几个方面： （1）概要设计说明书是否与软件需求说明书
的要求一致 （2）概要设计说明书是否正确、完整、一致 （3）系统的模块划分是否合理 （4）接口定义是否明确 （5）文档是否符合有关标准规定
与会人员纷纷就该问题发表自己的意见 大家争执不下，结果，致使会议出现了混乱状
况，主持人无法控制局面，会议大大超出了计 划评审时间。
失败的需求评审:案例
某软件公司为某公司A做业务流程管理系 统的需求评审会
当项目组人员在会议上宣读多达上百页 的需求报告时，用户明确提出听不懂， 致使会议不得不改日进行。
对评审员进行培训
很多情况下，评审员是领域专家而不是进行 评审活动的专家，没有掌握进行评审的方法、 技巧、过程等，需要培训
对于主持评审的管理者也需要进行培训，使 参与评审的人员能够围绕评审的目标来进行， 能控制评审节奏，提高评审效率
充分利用需求评审检查单
需求检查单：需求形式检查单和需求内容检查单。 需求形式检查：由QA人员负责，主要是针对需求文
挡的格式是否符合质量标准 需求内容检查：是由评审员负责，主要是检查需求
内容是否达到了系统目标、是否有遗漏、是否有错 误等等 检查单可以帮助评审员系统全面地发现需求中的问 题 检查单随着工程经验的积累逐渐丰富和优化
建立标准的评审流程
需求评审会需要建立正规的需求评审流程， 按照流程中定义的活动进行规范的评审过程
做好评审后的跟踪工作
根据评审人员提出的问题进行评价： 确定哪些问题必须纠正（给出理由与证据）：书面
的需求变更申请，进入需求变更的管理流程，并确 保变更的执行。在变更完成后，要进行复审。
切忌评审完毕后，没有对问题进行跟踪，而无法保 证评审结果的落实，使前期的评审努力付之东流
充分准备评审
评审质量与评审会议前的准备活动关系密切。
（1）分层次评审 （2）正式评审与非正式评审结合 （3）分阶段评审 （4）精心挑选评审员 （5）对评审员进行培训 （6）充分利用需求评审检查单 （7）建立标准的评审流程 （8）做好评审后的跟踪工作 （9）充分准备评审
分层次评审
用户的需求层次： 目标性需求：定义了整个系统需要达到的目
标 （高层管理人员关注） 功能性需求：定义了整个系统必须完成的任
7.4详细设计评审
开始时间：软件详细设计阶段结束后 一般应考察以下几个方面： （1）详细设计说明书是否与概要设计说明书的要求
一致 （2）模块内部逻辑结构是否合理，模块之间的接口
是否清晰 （3）数据库设计说明书是否完全，是否正确反映详
细设计说明书的要求 （4）测试是否全面、合理 （5）文档是否符合有关标准规定