软件评审机制.docx
《软件评审机制.docx》由会员分享，可在线阅读，更多相关《软件评审机制.docx（20页珍藏版）》请在冰豆网上搜索。
软件评审机制
1.软件评审概述
1.1简介/软件评审
软件评审是以提高软件质量为目的的技术活动。
缺乏质量概念的技术评审是一种拘于形式的为评审而评审的盲目工作。
通常，把质量定义为用户的满意程度。
为使用户满意，有两个必要条件：
设计质量：
设计的规格说要符合用户的要求。
程序质量：
程序要按照软件规格说明所规定的情况正确执行。
与上述质量的观点相对应，软件的规格说明可以分为外部规格说和内部规格说明。
外部规格说明是从用户角度来看的规格，包括硬件与软件系统设计（在分析阶段进行）、功能设计（在需求分析阶段与总体设计阶段进行），而内部规格说明是为了实现外部规格说明的更详细的规格，即程序模块结构与模块加工的设计（在总体设计和详细设计阶段进行）。
因此，内部规格说明是从开发者角度来看的规格说明。
将上述两个概念联系起来，则可以说明设计质量是由外部规格说明决定的，程序质量是由内部规格说明决定的。
软件评审原理
1.2评审的目的
评审的目的是检验软件开发、软件评测各阶段的工作是否齐全、规范，各阶段产品是否达到了规定的技术要求和质量要求，以决定是否可以转入下一阶段的工作。
1.3评审阶段的划分；
1）系统分析与设计；
2）软件需求分析；
3）软件概要设计；
4）软件详细设计；
5）编码和单元测试；
6）软件部件测试；
7）软件配置项测试；
8）软件系统测试；
9）系统验收。
1.4评审的组织与管理
1）内部评审
内部评审是由公司研发部门组织的评审
2）外部评审
外部评审是由交办组织的评审，特殊情况下，交办方委托其他单位代理组织外部评审。
2.评审内容/软件评审
2.1设计质量
设计质量的评审对象是在需求分析阶段产生的软件需求规格说明、数据要求规格说明，在软件总体设计阶段产生的软件总体设计说明书等。
通常，需要从12个方面进行评审。
（1）评价软件的规格说明是否合乎用户的要求。
（2）评审可靠性。
（3）评审保密措施实现情况。
（4）评审操作特性实施情况。
（5）评审性能实现情况。
（6）评审软件是否具有可修性。
（7）评审软件是否有可扩充性。
（8）评审软件是否具有互换性。
（9）评审软件是否具有可移植性。
（10）评审软件是否具有可测试性。
（11）评审软件是否具有复用性。
（12）评审软件是否具有互连性。
2.2程序质量的评审内容
程序质量评审着眼与软件本身的结构、与运行环境的接口、变更带来的影响而进行的评审活动。
通常它是从开发者的角度进行评审，直接与开发技术有关。
（1）软件的结构。
为了使得软件能够满足设计规格说明中的要求，软件的结构本身必须是优秀的。
①功能结构。
在软件的各种结构中，功能结构是用户惟一能见到的结构。
因此，功能结构可以说是联系用户和开发者的规格说明，它在软件的设计中占有极其重要的地位。
软件功能的本质是把输入信息变换为输出信息。
因此，在讨论软件的功能结构时，必须明确软件的数据结构。
需要检查的项目有以下几项：
数据结构、功能结构、数据结构和功能结构之间的对应关系。
②功能的通用性。
在软件的功能结构中，某些功能有时可以作为通用功能反复出现多次。
从功能便于理解、增强软件的通用性及降低开发的工作量等观点出发，希望尽可能多地使功能通用化。
实现功能通用化的最一般方法是通过提取公用功能来实现通用模块化。
而进一步的功能通用化方法就是信息隐蔽或数据抽象。
它的基础就是抽象数据类型。
在实现功能通用性方面，检查项目是：
抽象数据结构：
包括抽象数据的名称和含义、抽象数据构成元素的定义。
抽象功能结构：
包括①中的抽象数据进行操作的各个功能的一览表、上述各功能的定义及各个功能之间的关系。
（2）与运行环境的接口。
运行环境包括硬件、其他软件和用户。
与运行环境的接口应设计得较理想，要预见到环境改变，并且当一旦要变更时，应尽量限定其变更范围和变更所影响的范围。
主要检查项目如下：
①与其他软件的接口：
包括与上层软件的接口，如与操作系统等控制该软件的那些软件的接口；与同层软件的接口，如通过文件连接起来的那些软件的接口；与下层软件的接口，如编译程序与作为其输入的源程序之间的接口。
②与硬件的接口：
包括与硬件的接口约定（即根据硬件的使用说明等所做出的规定）和硬件故障时的处理和超载时的处理。
③与用户的接口。
2.3模块的层次
模块的层次就是指程序模块结构。
由于模块是功能的具体体现，所以模块层次应当根据功能层次来设计。
模块层次中保有一部分功能层次，但模块层次并不全与功能层次系统，重要的是应明确模块层次与功能层次之间的关系。
为此，要检查以下项目。
1）模块层次：
模块层次的定义，包括各层次的含义、各层次物理容量的上限；模块的层次结构，包括各模块间的联系、各模块与层次的对应关系。
2）与功能层次的对应关系：
功能与模块的对应关系；功能层次与模块层次的匹配程度。
2.4模块结构
以上所述的模块层次结构是模块的静态结构，现在要检查模块间的动态结构。
模块分为处理模块和数据模块两类。
模块间的动态结构也与这些模块分类有关。
对这样的模块结构进行检查的项目有以下几项。
1）控制流结构：
这种结构规定了处理模块与处理模块之间的流程关系。
因此，要检查处理模块之间的控制转移关系和控制转移形式（调用方式）。
2）数据流结构：
这种结构规定了数据模块是如何被处理模块进行加工的流程关系。
因此，要检查处理模块与数据模块之间的对应关系和处理模块与数据模块之间的存取关系（建立、删除、查询、提取、修改等）。
3）模块结构与功能结构之间的对应关系：
包括功能结构与控制流结构的对应关系和功能结构与数据流结构的对应关系。
4）每个模块的定义：
包括功能，输入与输出数据。
3.5处理过程的结构
处理过程是指模块划分到最底层的那些模块的实现方式，也就是最基本的加工逻辑过程。
对它的检查项目有以下几项。
1）要求模块的功能结构与实现这些功能的处理过程的结构应明确对应。
2）要求控制流应是结构化的。
3）数据的结构与控制流之间的对应关系应是明确的，并且可依这种对应关系来明确数据流程的关系。
4）用于描述的术语标准化。
3.软件阶段评审
3.1需求评审
3.1.1需求评审的概述
1）软件需求是软件开发的最重要的一个步骤，需求的质量很大程度上决定了项目质量或产品质量。
2）需求评审是所有的评审活动中最难的一个，也是最容易被忽视的一个评审。
评审内容：
软件需求说明书是否覆盖了用户的所有要求（用户需求调研报告，软件需求说明书）；软件需求说明书和数据要求说明书的明确性、完整性、一致性、可测试性、可跟踪性（软件需求说明书数据流图数据字典）；项目开发计划的合理性（用户方公司技术委员会项目组等）；文档是否符合有关标准规定。
3.1.2如何做好需求评审
1）分层次评审
用户的需求层次
目标性需求：
定义了整个系统需要达到的目标
功能性需求：
定义了整个系统必须完成的任务（中层管理人员关注）
操作性需求：
定义了完成每个任务的具体的人机交互（具体操作人员关注）
2）正式评审与非正式评审结合
正式评审：
开评审会，将需求涉及到人员集合在一起，并定义好参与评审人员的角色和职责
非正式评审：
不需要将人员集合在一起，通过电子邮件、网络聊天等多种形式。
3）分阶段评审
在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。
将原来需要进行的大规模评审拆分成各个小规模的评审。
降低了需求返工的风险，提高了评审的质量。
4）精心挑选评审人员
需求评审可能涉及的人员：
需方：
高层管理人员，中层管理人员、具体操作人员、IT主管、采购主管。
供方：
市场人员、需求分析人员、设计人员、测试人员、实施人员、项目经理等等。
这些人员所处的立场不同，对同一个问题的看法是不相同的，不同的观点可能形成互补的关系。
要保证不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。
不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则使评审的效率降低。
5）对评审员进行培训
很多情况下，评审员是领域专家而不是进行评审活动的专家，没有掌握进行评审的方法、技巧、过程等，需要培训。
对于主持评审的管理者也需要进行培训，使参与评审的人员能够围绕评审的目标来进行，能控制评审节奏，提高评审效率。
6）充分利用需求评审检查单
需求检查单：
需求形式检查单和需求内容检查单。
需求形式检查：
由QA人员负责，主要是针对需求文档的格式是符合质量标准。
需求内容检查：
是由评审员负责，主要检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等。
检查单可以帮助评审员系统全面地发现需求中的问题，检查单随着工程经验的积累逐渐丰富和优化。
7）建立标准的评审流程
需求评审需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。
8）做好评审后的跟踪工作
根据评审人员提出的问题进行评价：
确定那些问题必须纠正（给出理由与证据）：
书面的需求变更申请，进入需求变更的管理流程，并确定变更的执行。
在变更完成后，进行复审。
切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。
9）充分准备评审
评审质量与评审会议前的准备活动关系密切。
常见问题：
需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多的时间让参与评审的人员阅读需求文档。
没有执行需求评审的进入条件，在评审文档中在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误。
评审准备，应当定义一个检查单，在评审之前对照检查单落实每项准备工作。
3.2概要设计评审
开始时间：
软件概要设计结束后
评审内容：
1）总体结构
2）外部接口
3）主要部件功能分配
4）全局数据结构
5）各主要部件之间的接口
一般应考察以下几个方面：
1）概要设计说明书是否与软件需求说明书的要求一致
2）概要设计说明书是否正确、完整、一致
3）系统的模块划分是否合理
4）接口定义是否明确
5）文档是否符合有关标准规定
软件产品概要设计评审报告
中文名称
英文名称
英文简称
版本
项目时间
年月日至年月日
评审状态
初审
复审
评审会成员
技术评估
评审会结论：
评审组长签名：
日期：
年月日
3.3详细设计评审
开始时间：
软件详细设计阶段结束后
一般应考察以下几个方面：
1）详细设计说明书是否与概要设计说明书要求一致
2）模块内部逻辑结构是否合理，模块之间的接口是否清晰
3）数据库设计说明书是否完全，是否正确反映详细设计说明书的要求
4）测试是否全面、合理
5）文档是否符合有关标准规定
评审报告
项目名称
项目编号
评审日期
评审性质
评审复审
阶段名：
（请在需要评审的内容左侧“”内打“”）
合同评审立项开发计划需求规格分析概要设计
详细设计编码测试验收变更评审
评审材料：
《概要设计说明书》
评审内容：
根据评审材料《概要设计说明书》以及系统开发已经完成的模型，对总的监控调度中心子项目的概要设计工作进行评审，主要从包括几个方面：
可追溯性：
确认该设计是否覆盖了所有已确定的软件需求，且可追溯到某一项目需求；
接口：
确认该软件的内部接口与外部接口是否已经明确定义；
风险：
确定该设计在现有技术条件下和预算范围内是否能按时实现；
实用性：
确认该设计对于需求的解决方案是否实用；
可维护性：
确认该设计是否考虑了方便未来的维护。
评
审
小
组
意
见
职务
姓名
评审意见
签名
组长
成员
成员
成员
详细设计评审检查表
项目名称
评委姓名
评审检查日期
评审检查用时（小时）
主要检查内容
意见
详
细
设
计
书
每一个单元的关键算法，关键数据结构是否清楚
详细设计是否覆盖了所有的总体设计条目
详细设计和总体设计之间是否存在冲突？
总体设计是否经过相应的变更？
设计是否可以实现的？
设计是否有遗漏和缺陷？
单元测试样例是否形成？
样例是否合理？
单元测试方案是否可行？
需求追溯表
详细设计中的每一条目是否都能追溯到总体设计中对应条目？
问题
编号
1
2
......
评审检查结论（邮件评审时填）
通过有条件通过不通过
3.4数据库设计评审
在数据库设计阶段结束后必须进行数据库设计评审，以评价数据库的结构设计及运用设计的合适性。
一般应考察以下几个方面：
1）概念结构设计；
2）逻辑结构设计；
3）物理结构设计；
4）数据字典设计；
5）安全保密设计。
数据库设计评审内容表
序号
检查项目
通过
不通过
1
数据库设计是否满足软件设计的一般要求？
注：
数据库设计应该满足软件设计的一般要求。
2
数据库设计是否与其他设计内容一致？
注：
作为软件设计的一部分，数据库设计应该与其他设计内容保持一致。
3
设计是否充分考虑了新系统与现有系统的关系，与现有系统的接口是否被充分考虑？
注：
在数据库设计中应该充分考虑新系统与现有系统的关系，与现有系统的接口应被充分考虑。
4
如果基础数据的一部分来源于其他系统，那么是否有工具或方案实现快速导入？
注：
如果有必要，应该设计工具或者方案将来源于其他系统的数据快速导入数据库。
5
反规范化（违反3NF）的设计是否有明确的说明，理由是否充分？
注：
反规范化的设计有时是必要的，但是要注明理由。
通常的理由包括：
1、为了提高查询效率，在频繁查询但不频繁更新的表中增加冗余列；
2、为了提高查询效率，将大容量表作水平分割（分割列）；
3、为了方便进行统计，引入派生列；
4、......
如无恰当理由，所有设计均应遵循3NF。
6
对反规范化（违反3NF）设计部分的数据完整性是否进行了充分的考虑？
注：
反规范化的设计可能产生数据冗余，因此应该视具体情况建立一定的机制（如触发器、过程）保证反规范化数据的完整性。
7
孤立表的设计理由是否充分？
注:
设计中应该对孤立表的设计理由作出明确的说明。
8
为保证查询和更新效率，是否对大容量表（千万行以上或100列以上）作了必要的设计？
注：
通常在打容量表上采用的设计包括：
1、将大容量表设计成分区表；
2、将大容量表作水平分割（分割行）或垂直分割（分割列）；
3、......
9
是否避免深度超过三层的视图？
注：
为了保证效率，视图的深度一般不超过三层。
可以建立临时表降低视图的深度。
10
是否遵循统一的命名规范？
注：
对所有数据库元素应该采用统一的命名规范。
11
表、列、视图、触发器、过程的注释是否完整？
注：
应在表和列上建立中文说明；应在复杂视图的脚本中增加注释；应该在触发器和过程脚本中增加注释。
12
命名是否避免使用数据库的保留字？
注：
命名应绝对避免使用数据库的保留字。
13
数据类型是否存在溢出的可能？
注：
检查数据的逻辑取值范围是否超出数据的设计类型，重点检查integer,smallint,char型字段。
14
数据类型的长度是否保留了未来扩展的余量？
注：
数据类型应保留一定的扩展余量。
由此产生的典型问题包括：
电话号码升位、身份证升位、千年虫等。
15
在作为查询条件的列上是否建立了NOTNULL约束？
若果没有，理由是否充分。
注：
如果把为建立notnull约束的列作为查询条件，查询结果中往往会漏掉取值为null的列。
16
是否谨慎地使用日期型字段？
注：
外部输入或导入的日期应使用varchar型或char型字段。
典型的问题是：
如果有的日期精确到日，有的日期只精确到年，那么这些数据在日期型字段中得不到准确的记录。
17
主键是否采用系统生成的键？
如果不是，理由是否充分。
注：
现在的设计越来越倾向于使用系统生成的键作为主键，而不使用带有业务含义的主键，由系统生成的主键字段通常包括：
自增长列、序列、GUID。
18
是否尽量避免将可能变动的字段作为主键？
注：
如果不使用系统生成的键，那么应该避免将可能变动的键作为主键。
19
如果外键字段未建立NOTNULL约束。
那么理由是否充分。
注：
外键字段要么引用关联的主键，要么置空的外键字段有确定的业务含义，那么最好将这样的“业务含义”定义在外键关联表中，并且在外键字段上建立notnull约束。
20
是否尽量使用数据库的约束机制实现数据的完整性？
注：
应该尽量利用数据库的约束机制（例如键、非空、唯一、check、触发器等），而不是应用程序，保证数据的完整性。
21
索引是否正确地建立在查询操作频繁的表上？
注：
应该索引建立在查询操作频繁的表上。
建立索引的常用原则还包括：
1、使索引最可能被用在where子句中；
2、查询时不应对索引列作为函数运算，否则应建立函数索引；
3、在大型表上建立索引有可能降低查询效率，可以将大表建立分区索引；
4、......
22
索引是否尽量避免建立在大容量字段上？
注：
应尽量避免将索引建立在name，lob或大文本这样的大容量字段上。
23
索引是否避免建立在小数据表（少于5个块）上？
注：
在小容量表上建立索引没有意义。
24
是否将索引建立在独立的表空间上？
如果不是，理由是否充分。
注：
将索引建立在独立的表空间上能够提高查询效率。
25
是否依据一定的原则，恰当地划分了表空间
注：
划分表空间的一般原则包括:
1、将访问方式相同的字段（例如lob字段）储存在一起
2、将系统数据和业务数据分开存储
3、将数据和索引分开存储
4、将频繁增长变化和相对静止的数据分开存储
......
26
是否有系统级和程序级的用户、角色和权限的设计？
注：
应该在数据库系统和应用程序级分别设计用户、角色和权限。
27
是否进行了必要的设计，保证应用程序的数据库连接参数（包括用户名、密码等）独立、安全？
注：
应用程序通过数据库连接参数访问数据库。
数据库连接参数应分别独立与应用程序和业务数据库，密码应加密。
数据库连接参数的独立性和安全性应在设计中体现。
28
是否建立了数据库的备份和恢复策略？
注：
应该建立数据库的备份和恢复策略。
通常即可以使用数据库的功能实现，也可以用应用程序实现。
29
如果有移植的要求，那么是否对移植性作了充分的考虑？
注：
如果有移植需求，那么应该慎重使用函数、过程、触发，并且要单独的移植方案。
30
其他检查的内容
3.5测试评审
测试评审主要对测试的各个环节进行评审，包括：
1）“软件测试需求规格说明”评审；
2）“软件测试计划”评审；
3）“软件测试说明”评审；
4）“软件测试报告”评审
5）“软件测试记录”评审
测试评审的主要内容：
1、测试是否全面、合理（测试计划）；2、文档是否符合有关标准规定；3、软件测试说明对各测试用力进行详细的定义和说明，审核测试用例、环境、测试软件、测试工具等准备工作是否全面、到位；4、在测试过程中，填写“软件测试记录”。
发现软件问题，则填写“软件问题报告单”。
5、测试记录包括测试的时间、地点、操作人、参加人、测试输入数据、期望测试结果、实际测试结果及测试规程
3.6验收评审（鉴定）
验收评审是评审的最后一个阶段，是对产品的最终评定。
评审人员：
软件开发人员、项目经理、用户、管理人员、承办方与交办方上级领导。
评审内容：
开发的软件系统是否已达到软件需求说明书规定的各项技术指标；使用手册是否完整、正确；文档是否齐全，是否符合有关标准。
升级会员 