`
icess
  • 浏览: 252712 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

同行评审过程描述(一)——概述

阅读更多
1. Overview(概述)
        In a peer review, co-workers of a person who created a software work product examine that product to identify defects and correct shortcomings. A review:
        在同行评审中,由软件工作产品创建者的同行们检查该工作产品,识别产品的缺陷,改进产品的不足。评审:
        · verifies whether the work product correctly satisfies the specifications found in any predecessor work product, such as requirements or design documents
        · 检验工作产品是否正确的满足了以往的工作产品中建立的规范,如需求或设计文档
        · identifies any deviation from standards, including issues that may affect maintainability of the software
        · 识别工作产品相对于标准的偏差,包括可能影响软件可维护性的问题
        · suggests improvement opportunities to the author
        · 向创建者提出改进建议
        · promotes the exchange of techniques and education of the participants.
        · 促进参与者之间的技术交流和学习
        All interim and final development work products are candidates for review, including:
        所有中间和最终的开发工作产品都可以进行评审,包括:
        · requirements specifications
        · 需求规格说明书
        · user interface specifications and designs
        · 用户界面规范及设计
        · architecture, high-level design, and detailed designs and models
        · 架构,概要设计,详细设计及模型
        · source code
        · 源代码
        · test plans, designs, cases, and procedures
        · 测试计划,设计,用例及步骤
        · software development plans, including project management plan, configuration management plan, and quality assurance plan
        · 软件开发计划,包括项目管理计划,配置管理计划和质量保证计划
        This document defines an overall peer review process. It includes procedures for conducting inspections and two types of informal peer review, a walkthrough and a passaround, as well as guidance for selecting the appropriate approach for each review.
        该文档定义了一个全面的同行评审过程。包括了执行评审的步骤和两种非正式的同行评审,走查和轮查,以及对每个评审选择适当方法的指南。
        2. Work Aids(工作辅助项)
        The following peer review work aids are available from :
<场所>中,需要有如下的同行评审工作辅助项:
        · Inspection Summary Report
        · 评审总结报告
        · Issue Log
        · 问题日志
        · Typo List
        · 微错清单
        · Inspection Moderator’s Checklist
        · 评审负责人的检查表
        · Inspection Lessons Learned Questionnaire
        · 评审经验教训问卷
        · defect checklists for several types of software work products
        · 各种软件工作产品的缺陷检查表
        3. Risk Assessment Guidance(风险评估指南)
        To judge which software components (or portions of components) to review and what type of review method to use, consider the following risk criteria:
在判断哪些软件组件(或组件的部分)需要评审及使用哪种评审方法的时候,需要考虑如下的风险条件:
        · components that use new technology, techniques, or tools
        · 使用了新技术,方法,工具的组件
        · key architectural components
        · 关键的架构性的组件
        · complex logic or algorithms that are difficult to understand but must be accurate and optimized
        · 难以理解,却又必须准确和优化的复杂逻辑或算法
        · mission-, security-, or safety-critical components with dangerous failure modes
        · 具有危险失败模式的组件,而且是任务、可靠性、安全性关键的
        · components having many exception conditions or failure modes
        · 具有多个异常条件或失败模式的组件
        · exception handling code that cannot easily be tested
        · 不易测试的异常处理代码
        · components that are intended to be reused
        · 打算复用的组件
        · components that will serve as models or templates for other components
        · 将作为其他组件的模型或模板的组件
        · components that affect multiple portions of the product
        · 影响产品多个部分的组件
        · complex user interfaces
        · 复杂的用户界面
        · components created by less experienced developers
        · 由缺乏经验的开发者创建的组件
        · code modules having high cyclomatic complexity
        · 具有高度圈复杂性的代码模块
        · modules having a history of many defects or changes
        · 以往具有很多缺陷或变更的模块
        Work products that fit in one or more of these categories are considered high risk. A product is considered low risk if an undetected error will not significant affect the project’s ability to meet its schedule, quality, cost, and feature objectives. Use inspections for high-risk work products, or the high-risk portions of large products, and for major work products that are about to be baselined. Less formal reviews are acceptable for other work products
        符合这些条件中一种或几种的工作产品被认为是高风险的。如果未发现的缺陷对项目达成进度,质量,成本及特征目标的能力没有重大影响,则该工作产品被认为是低风险的。评审只用于高风险的工作产品或大产品的高风险部分或将要被基线化的主要工作产品。对其他的工作产品可以进行不太正式的评审。
        4. Participants(参与者)
        Table 1 suggests project roles who might review different work products. Not all of these perspectives need to be represented. In general, a work product should be reviewed by:
        表1列出了评审不同工作产品的项目角色。不是所有这些角度都必须表现出来。通常,一项工作产品的评审需要有:
        · the author of any predecessor document or specification
        · 以往的文档或规范的创建者
        · someone who must base their subsequent work on the work product
        · 以该工作产品为基础进行后续工作的人。
        · peers of the author
        · 创建者的同行们
        · anyone responsible for a component to which the work product interfaces
        · 使用该工作产品接口的组件的负责人
        Attendance by anyone with supervisory authority over the author is by invitation of the author only.
        对工作产品创建者具有监督权力的人只能在创建者的邀请下参加评审。
        Table 1. Review Participants for Different Types of Work Products.
        表1. 各类工作产品的参评人
Work Product Type工作产品类型 Work Product Type工作产品类型
Architecture or High-Level Design架构或概要设计 architect, requirements analyst, designer, project manager, integration test engineer架构师,需求分析师,设计师,项目经理,集成测试工程师
Detail Design详细设计 designer, architect, programmer, integration test engineer设计师,架构师,程序员,集成测试工程师
Process Documentation过程文档 process improvement group leader, process improvement working group members, management-level process owner, practitioner representatives who will use the process过程改进组负责人,过程改进工作组成员,管理级的过程拥有者,使用过程的实践者的代表
Project Plans项目计划 project manager, program manager, business sponsor, marketing or sales representative, technical lead, quality assurance manager项目经理,产品经理,需求提出者,市场或销售代表,技术负责人,质量保证工程师
Requirements Specification需求规格说明书 requirements analyst, project manager, architect, designer, system test engineer, quality assurance manager, user or marketing representative, documentation writer, subject matter expert, technical support representative需求分析师,项目经理,架构师,设计师,系统测试工程师,质量保证经理,用户或市场代表,文档编写者,业务专家,技术支持代表
Source Code源代码 programmer, designer, unit test engineer, maintainer, requirements analyst, coding standards expert程序员,设计师,单元测试工程师,维护者,需求分析师,编码标准专家
System Technical Documentation系统技术文档 author, project manager, maintainer, programmer创建者,项目经理,维护者,程序员
Test Documentation测试文档 test engineer, programmer (unit testing) or architect (integration testing) or requirements analyst (system testing), quality assurance representative测试工程师,程序员(单元测试)或架构师(集成测试)或需求分析师(系统测试),质量保证代表
User Interface Design用户界面设计 user interface designer, requirements analyst, user, application domain expert, usability or human factors expert, system test engineer用户界面设计师,需求分析师,用户,应用领域专家,可用性或人体专家,系统测试工程师
User Manual用户手册 ocumentation writer, requirements analyst, user or marketing representative, system test engineer, maintainer, designer, instructional designer, trainer, technical support representative文档编写者,需求分析师,用户或市场代表,系统测试工程师,维护人员,设计师,用户教育设计师,培训师,技术支持代表
分享到:
评论

相关推荐

    架构实战——软件架构设计的过程

    这通常包括同行评审和技术评审等多个环节。 4. **实现与测试**:基于设计文档进行编码实现,并通过各种测试方法验证软件是否达到预期的功能和性能目标。 5. **部署与维护**:完成测试后,将软件部署到生产环境,并...

    应用数学——征稿简章

    - **同行评审**:提交的论文将经过同行专家的匿名评审,以确保其质量和学术价值。 - **修改与反馈**:根据评审意见进行必要的修改,并重新提交。 6. **版权信息**:所有被接受的论文,其版权将归China Academic ...

    软件测试活动规范——软件测试活动规范

    - **过程/规范**:软件实施工作规范、同行评审规范等。 - **指南**:软件单元测试指南、软件集成测试指南等。 - **模板**:软件测试计划模板、测试用例模板等。 - **检查表**:测试计划检查表、测试过程检查表等。 -...

    上海中心结构超限审查报告第三方评审报告(正式)

    综上所述,上海中心大厦的结构设计经过了详尽的同行评审与分析,证明其能够满足中国抗震规范中规定的“小震不坏,中震可修,大震不倒”的设防目标。虽然报告中也指出了若干需要改进的地方,但整体而言,该项目结构...

    计算机界的最高奖项是图灵奖,(A.M. Turing Award,又译“杜林奖”)

    2. **严格的评审过程**:图灵奖的评审过程非常严格,由一群来自世界各地的顶尖计算机科学家组成的评审委员会负责评选工作。 3. **高额奖金与荣誉证书**:除了荣誉之外,图灵奖还附带一笔高额奖金,以及一份由美国...

    软件工程与实践研究详解

    4. **同行评审**:MSE6-同行评审.pdf强调了代码审查的重要性,通过团队成员之间的相互检查,提高代码质量和减少错误,是保证软件质量的重要手段。 5. **软件测试**:MSE7-测试系列文档详细讲解了软件测试的不同层次...

    硕士约稿单2.zip

    7. **同行评审**:如果约稿单是提交给学术期刊,那么它将经历同行评审过程,由专家评估其研究价值和学术质量。这涉及到论文的修改、反驳信的撰写以及与审稿人之间的互动。 8. **排版与格式**:最终的硕士论文需要...

    软件质量保证与管理PPT

    同行评审是发现潜在问题的有效手段,可以提前识别并修复错误。 8. **错误预防与纠正**:强调在开发早期发现和解决错误,而非等到后期。预防优于治疗,通过良好的设计、编码规范和测试实践,可以减少缺陷的产生。 9...

    信息系统项目管理师考试必过笔记第十二章项目质量管理.docx

    - 同行评审 **3. 质量控制** - **目的**: 监控项目成果是否符合质量标准,并制定有效的纠正措施以解决质量问题。 - **工具/方法**: - 检查 - 测试 - 控制图 #### 三、质量管理理论与标准 **1. 质量管理理论**...

    目录与摘要-论文.zip

    在IT行业中,撰写论文是科研和技术交流的重要环节。这篇压缩包文件“目录与摘要-论文.zip”包含了关于论文写作的关键组成部分——...在学术界,良好的目录和摘要可以提升论文的专业形象,增强其在同行评审中的竞争力。

    编写优化、高效、无错地代码

    - **代码审查**:强调了同行评审的重要性,并提供了一些实用的代码审查技巧。 - **单元测试**:介绍了如何编写有效的单元测试来确保代码的质量和稳定性。 - **调试技巧**:讲解了各种调试方法,帮助开发者快速定位和...

    论文正本 (标红).zip

    在Word文档中,通常红色高亮表示的是新添加的内容或者修改过的部分,可能是作者在多次修订后留下的痕迹,也可能是导师或同行评审的反馈,帮助读者快速识别重要的更改和讨论点。 在学术论文中,通常包括以下几个关键...

    英文科技论文写作-Scientific Writing

    - **同行评审**:在提交论文前,找同行专家进行评审,以提高论文质量。 "英文科技论文写作——Scientific Writing"这份资源很可能包含了以上各部分的详细指导,包括结构、语言、格式和常见误区等。通过深入学习和...

    2019年广州开发区财政投资评审中心招聘模拟试题及答案解析.docx

    - 与长辈同行时,晚辈应行走于人行道的外侧,以体现对长辈的尊重。 ### 6. 经济学角度解读“曲高和寡” **知识点概述**: - **经济学解释**:“曲高和寡”的经济学含义是指价格过高会导致消费者需求不足。 **详细...

    Science 20110107

    #### 会议报道:在几乎免费的度假胜地举行的同行评审会议 - **内容概述**:这篇报道讲述了在一个度假村举办的科学会议,重点在于会议组织者如何成功利用度假村资源降低参会成本,同时保持高水平的学术交流质量。 #...

    东南大学博士研究生答辩申请材料审核表共1页.pdf.zip

    【描述】描述了该文件的核心内容,即这份审核表共有1页,这意味着可能是一个简洁明了的表格或清单,概述了整个答辩申请过程的关键步骤和所需文件。通常,这样的表格会指导学生按照学校的规定和流程进行操作,确保...

    投稿指南-Robot and Comp-Integ Manuf-Guide for author

    4. **同行评审**:所有提交的论文都将经过严格的同行评审过程,以确保其质量和学术价值。 5. **版权与许可**:作者需确保所有作品的原创性,并遵守版权法规。 总的来说,向《Robotics and Computer-Integrated ...

    Program management professional credential handbook

    - **多评分人评估 (MRA)**:通过同行评审评估领导力和团队合作能力。 4. **PgMP 认证资格要求** - 教育背景:要求申请者至少拥有学士学位或同等学历。 - 经验要求:需要具有丰富的项目管理和程序管理经验。 - ...

    软件工程方法教科书电子版

    - **概述**:软件工程过程模型是描述软件开发活动如何组织和执行的一种框架,主要包括瀑布模型、增量模型、螺旋模型等。 - **瀑布模型**:一种线性的开发模型,按照需求分析、设计、实现、测试、维护等阶段顺序进行...

Global site tag (gtag.js) - Google Analytics