搜索
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需求评审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）文档是否符合有关标准规定评审报告项目名称项目编号评审日期评审性质评审复审阶段名：（请在需要评审的内容左侧“”内打“”）合同评审立项开发计划需求规格分析概要设计详细设计编码测试验收变更评审评审材料：《概要设计说明书》评审内容：根据评审材料《概要设计说明书》以及系统开发已经完成的模型，对总的监控调度中心子项目的概要设计工作进行评审，主要从包括几个方面：可追溯性：确认该设计是否覆盖了所有已确定的软件需求，且可追溯到某一项目需求；接口：确认该软件的内部接口与外部接口是否已经明确定义；风险：确定该设计在现有技术条件下和预算范围内是否能按时实现；实用性：确认该设计对于需求的解决方案是否实用；可维护性：确认该设计是否考虑了方便未来的维护。评审小组意见职务姓名评审意见签名组长成员成员成员详细设计评审检查表项目名称评委姓名评审检查日期评审检查用时（小时）主要检查内容意见详细设计书每一个单元的关键算法，关键数据结构是否清楚详细设计是否覆盖了所有的总体设计条目详细设计和总体设计之间是否存在冲突总体设计是否经过相应的变更设计是否可以实现的设计是否有遗漏和缺陷单元测试样例是否形成样例是否合理单元测试方案是否可行需求追溯表详细设计中的每一条目是否都能追溯到总体设计中对应条目问题编号12......评审检查结论（邮件评审时填）通过有条件通过不通过3.4数据库设计评审在数据库设计阶段结束后必须进行数据库设计评审，以评价数据库的结构设计及运用设计的合适性。一般应考察以下几个方面：1）概念结构设计；2）逻辑结构设计；3）物理结构设计；4）数据字典设计；5）安全保密设计。数据库设计评审内容表序号检查项目通过不通过1数据库设计是否满足软件设计的一般要求注：数据库设计应该满足软件设计的一般要求。2数据库设计是否与其他设计内容一致注：作为软件设计的一部分，数据库设计应该与其他设计内容保持一致。3设计是否充分考虑了新系统与现有系统