软件评审机制Word文档格式.docx
- 文档编号:15853645
- 上传时间:2022-11-16
- 格式:DOCX
- 页数:20
- 大小:63.88KB
软件评审机制Word文档格式.docx
《软件评审机制Word文档格式.docx》由会员分享,可在线阅读,更多相关《软件评审机制Word文档格式.docx(20页珍藏版)》请在冰豆网上搜索。
4)软件详细设计;
5)编码和单元测试;
6)软件部件测试;
7)软件配置项测试;
8)软件系统测试;
9)系统验收。
1.4评审的组织与管理
1)内部评审
内部评审是由公司研发部门组织的评审
2)外部评审
外部评审是由交办组织的评审,特殊情况下,交办方委托其他单位代理组织外部评审。
2.评审内容/软件评审
2.1设计质量
设计质量的评审对象是在需求分析阶段产生的软件需求规格说明、数据要求规格说明,在软件总体设计阶段产生的软件总体设计说明书等。
通常,需要从12个方面进行评审。
MJTMK。
(1)评价软件的规格说明是否合乎用户的要求。
(2)评审可靠性。
(3)评审保密措施实现情况。
(4)评审操作特性实施情况。
(5)评审性能实现情况。
(6)评审软件是否具有可修性。
(7)评审软件是否有可扩充性。
(8)评审软件是否具有互换性。
(9)评审软件是否具有可移植性。
(10)评审软件是否具有可测试性。
(11)评审软件是否具有复用性。
(12)评审软件是否具有互连性。
2.2程序质量的评审内容
程序质量评审着眼与软件本身的结构、与运行环境的接口、变更带来的影响而进行的评审活动。
通常它是从开发者的角度进行评审,直接与开发技术有关。
00i7R。
(1)软件的结构。
为了使得软件能够满足设计规格说明中的要求,软件的结构本身必须是优秀的。
①功能结构。
在软件的各种结构中,功能结构是用户惟一能见到的结构。
因此,功能结构可以说是联系用户和开发者的规格说明,它在软件的设计中占有极其重要的地位。
软件功能的本质是把输入信息变换为输出信息。
因此,在讨论软件的功能结构时,必须明确软件的数据结构。
需要检查的项目有以下几项:
数据结构、功能结构、数据结构和功能结构之间的对应关系。
jWkHA。
②功能的通用性。
在软件的功能结构中,某些功能有时可以作为通用功能反复出现多次。
从功能便于理解、增强软件的通用性及降低开发的工作量等观点出发,希望尽可能多地使功能通用化。
实现功能通用化的最一般方法是通过提取公用功能来实现通用模块化。
而进一步的功能通用化方法就是信息隐蔽或数据抽象。
它的基础就是抽象数据类型。
在实现功能通用性方面,检查项目是:
mmi4x。
抽象数据结构:
包括抽象数据的名称和含义、抽象数据构成元素的定义。
抽象功能结构:
包括①中的抽象数据进行操作的各个功能的一览表、上述各功能的定义及各个功能之间的关系。
(2)与运行环境的接口。
运行环境包括硬件、其他软件和用户。
与运行环境的接口应设计得较理想,要预见到环境改变,并且当一旦要变更时,应尽量限定其变更范围和变更所影响的范围。
主要检查项目如下:
nMMGg。
①与其他软件的接口:
包括与上层软件的接口,如与操作系统等控制该软件的那些软件的接口;
与同层软件的接口,如通过文件连接起来的那些软件的接口;
与下层软件的接口,如编译程序与作为其输入的源程序之间的接口。
Gtkge。
②与硬件的接口:
包括与硬件的接口约定(即根据硬件的使用说明等所做出的规定)和硬件故障时的处理和超载时的处理。
3xiCS。
③与用户的接口。
2.3模块的层次
模块的层次就是指程序模块结构。
由于模块是功能的具体体现,所以模块层次应当根据功能层次来设计。
模块层次中保有一部分功能层次,但模块层次并不全与功能层次系统,重要的是应明确模块层次与功能层次之间的关系。
为此,要检查以下项目。
mjfQ0。
1)模块层次:
模块层次的定义,包括各层次的含义、各层次物理容量的上限;
模块的层次结构,包括各模块间的联系、各模块与层次的对应关系。
EXjHb。
2)与功能层次的对应关系:
功能与模块的对应关系;
功能层次与模块层次的匹配程度。
2.4模块结构
以上所述的模块层次结构是模块的静态结构,现在要检查模块间的动态结构。
模块分为处理模块和数据模块两类。
模块间的动态结构也与这些模块分类有关。
对这样的模块结构进行检查的项目有以下几项。
BKlZh。
1)控制流结构:
这种结构规定了处理模块与处理模块之间的流程关系。
因此,要检查处理模块之间的控制转移关系和控制转移形式(调用方式)。
AWs3n。
2)数据流结构:
这种结构规定了数据模块是如何被处理模块进行加工的流程关系。
因此,要检查处理模块与数据模块之间的对应关系和处理模块与数据模块之间的存取关系(建立、删除、查询、提取、修改等)。
GoYIB。
3)模块结构与功能结构之间的对应关系:
包括功能结构与控制流结构的对应关系和功能结构与数据流结构的对应关系。
5LMmo。
4)每个模块的定义:
包括功能,输入与输出数据。
3.5处理过程的结构
处理过程是指模块划分到最底层的那些模块的实现方式,也就是最基本的加工逻辑过程。
对它的检查项目有以下几项。
vwhQC。
1)要求模块的功能结构与实现这些功能的处理过程的结构应明确对应。
2)要求控制流应是结构化的。
3)数据的结构与控制流之间的对应关系应是明确的,并且可依这种对应关系来明确数据流程的关系。
4)用于描述的术语标准化。
3.软件阶段评审
3.1需求评审
3.1.1需求评审的概述
1)软件需求是软件开发的最重要的一个步骤,需求的质量很大程度上决定了项目质量或产品质量。
2)需求评审是所有的评审活动中最难的一个,也是最容易被忽视的一个评审。
评审内容:
软件需求说明书是否覆盖了用户的所有要求(用户需求调研报告,软件需求说明书);
软件需求说明书和数据要求说明书的明确性、完整性、一致性、可测试性、可跟踪性(软件需求说明书数据流图数据字典);
项目开发计划的合理性(用户方公司技术委员会项目组等);
文档是否符合有关标准规定。
oUkVC。
3.1.2如何做好需求评审
1)分层次评审
用户的需求层次
目标性需求:
定义了整个系统需要达到的目标
功能性需求:
定义了整个系统必须完成的任务(中层管理人员关注)
操作性需求:
定义了完成每个任务的具体的人机交互(具体操作人员关注)
2)正式评审与非正式评审结合
正式评审:
开评审会,将需求涉及到人员集合在一起,并定义好参与评审人员的角色和职责
非正式评审:
不需要将人员集合在一起,通过电子邮件、网络聊天等多种形式。
3)分阶段评审
在需求形成的过程中进行分阶段的评审,而不是在需求最终形成后再进行评审。
将原来需要进行的大规模评审拆分成各个小规模的评审。
降低了需求返工的风险,提高了评审的质量。
Z4P8l。
4)精心挑选评审人员
需求评审可能涉及的人员:
需方:
高层管理人员,中层管理人员、具体操作人员、IT主管、采购主管。
供方:
市场人员、需求分析人员、设计人员、测试人员、实施人员、项目经理等等。
这些人员所处的立场不同,对同一个问题的看法是不相同的,不同的观点可能形成互补的关系。
要保证不同类型的人员的都要参与进来,否则很可能会漏掉了很重要的需求。
不同类型的人员中要选择那些真正和系统相关的,对系统有足够了解的人员参与进来,否则使评审的效率降低。
5HiuW。
5)对评审员进行培训
很多情况下,评审员是领域专家而不是进行评审活动的专家,没有掌握进行评审的方法、技巧、过程等,需要培训。
A5omc。
对于主持评审的管理者也需要进行培训,使参与评审的人员能够围绕评审的目标来进行,能控制评审节奏,提高评审效率。
rnLY8。
6)充分利用需求评审检查单
需求检查单:
需求形式检查单和需求内容检查单。
需求形式检查:
由QA人员负责,主要是针对需求文档的格式是符合质量标准。
需求内容检查:
是由评审员负责,主要检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等。
检查单可以帮助评审员系统全面地发现需求中的问题,检查单随着工程经验的积累逐渐丰富和优化。
7)建立标准的评审流程
需求评审需要建立正规的需求评审流程,按照流程中定义的活动进行规范的评审过程。
8)做好评审后的跟踪工作
根据评审人员提出的问题进行评价:
确定那些问题必须纠正(给出理由与证据):
书面的需求变更申请,进入需求变更的管理流程,并确定变更的执行。
在变更完成后,进行复审。
0DGWF。
切忌评审完毕后,没有对问题进行跟踪,而无法保证评审结果的落实,使前期的评审努力付之东流。
9)充分准备评审
评审质量与评审会议前的准备活动关系密切。
常见问题:
需求文档在评审会议前并没有提前下发给参与评审会议的人员,没有留出更多的时间让参与评审的人员阅读需求文档。
11we4。
没有执行需求评审的进入条件,在评审文档中在大量的低级的错误或者没有在评审前进行沟通,文档中存在方向性的错误。
zGxvm。
评审准备,应当定义一个检查单,在评审之前对照检查单落实每项准备工作。
3.2概要设计评审
开始时间:
软件概要设计结束后
1)总体结构
2)外部接口
3)主要部件功能分配
4)全局数据结构
5)各主要部件之间的接口
一般应考察以下几个方面:
1)概要设计说明书是否与软件需求说明书的要求一致
2)概要设计说明书是否正确、完整、一致
3)系统的模块划分是否合理
4)接口定义是否明确
5)文档是否符合有关标准规定
软件产品概要设计评审报告
中文名称
英文名称
英文简称
版本
项目时间
年月日至年月日
评审状态
初审
复审
评审会成员
技术评估
评审会结论:
评审组长签名:
日期:
年月日
3.3详细设计评审
软件详细设计阶段结束后
1)详细设计说明书是否与概要设计说明书要求一致
2)模块内部逻辑结构是否合理,模块之间的接口是否清晰
3)数据库设计说明书是否完全,是否正确反映详细设计说明书的要求
4)测试是否全面、合理
5)文档是否符合有关标准规定
评审报告
项目名称
项目编号
评审日期
评审性质
评审复审
阶段名:
(请在需要评审的内容左侧“”内打“”)
合同评审立项开发计划需求规格分析概要设计
详细设计编码测试验收变更评审
评审材料:
《概要设计说明书》
根据评审材料《概要设计说明书》以及系统开发已经完成的模型,对总的监控调度中心子项目的概要设计工作进行评审,主要从包括几个方面:
可追溯性:
确认该设计是否覆盖了所有已确定的软件需求,且可追溯到某一项目需求;
接口:
确认该软件的内部接口与外部接口是否已
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 评审 机制