《软件项目产品技术评审实施指南》.docxVIP

软件项目产品技术评审实施指南 文件编号 文件状态 ［J］草稿［］正式发布 ［］正在修改 当前版本 VI. 0 拟制 胡珊珊 日期 2007-11-21 审核 口期 批准 口期 发布日期 生效日期  修订历史记录 A■增加M■修订D ■删除 变更版本号 日期 变更类型 (A*M*D) 修改人 摘 要 备注 1.0 2007-11-21 A 胡珊珊 建立 TOC \o 1-5 \h \z HYPERLINK \l bookmark4 \o Current Document 引言 4 目的 4 范围 4 HYPERLINK \l bookmark6 \o Current Document 技术评审的方式和级别 4 评审方式 4 评审级别 4 HYPERLINK \l bookmark8 \o Current Document 推荐的工作产品评审方式与级别 5 HYPERLINK \l bookmark10 \o Current Document 软件项目实施技术评审注意事项 5 1引言 目的 指导项冃经理和技术评审小组如何进行有效的技术评审，以便尽早发现并消除工作产品 的缺陷。 范围 本文主要描述技术评审的评审方式及评审级别，推荐的软件产品评审方式和级别，技术 评审的其他规定。 本指南适合公司技术部门的所有软件项目。 2 技术评审的方式和级别 评审方式 软件项目产品的技术评审方式分为正式技术评审和非正式技术评审。 1） 、正式技术评审 对软件项目的重要技术成果必须进行正式技术评审，正式技术评审比较严格，需要 举行评审会议，参加评审会议的人员比较多。 2） 、非正式技术评审 由于软件项目的阶段工作产品非常多，进行正式技术评审的成本很高，因此，对于 质量要求不是很高的产品或需求非常明确的产品可以采取非正式技术评审的方式进行技术 评审。非正式技术评审的形式比较灵活，通常在同伴或组内之间展开，不必举行评审会议， 评审人员比较少。常见的非正式技术评审方式有如下几种： Email会签”：当评审成员无法集中吋，可通过Email方式收集意见，由评审负责 人汇总意见，并给出评审结论。 “走查”：如代码的审核。 “项冃组裁决”：非决策类的评审和要求比较明确的产品可在项目组内组织讨论决 定。 2. 2 评审级别 评审级别分“事业部级”、“子部门级”和“项目组内” “事业部级”：指各事业部，这个级别的技术评审成员需要覆盖大多数子部门。 “子部门级”：指各事业部的子部门，如公共安全事业部开发一部； “项目组内”：指评审人员来自项目组内部成员，如代码的审核。 3推荐的工作产品评审方式与级别 项目过程 丁作产品 不同项目级别的评审方式 不同项目级别的评审级别 A类 B类 C类 A类 B类 C类 项冃规划 项冃计划 正式 正式 事业部级 事业部级 子部门级 需求开发 用户需求说明书 正式 事业部级 软件需求规格说明书 正式 正式 事业部级 事业部级 系统设计 概要设计说明书 正式 正式 事业部级 事业部级 详细设计说明书 项冃组内 项FI组内 系统设计说明书 项冃组内 项FI组内 数据库设计说明书 项目组内 项目组内 实现与 测试 代码 项冃组内 项FI组内 单元测试计划 项目组内 项目组内 单元测试用例 项目组内 项目组内 单元测试总结 项目组内 项目组内 集成测试计划 项目组内 项目组内 集成测试用例 项目组内 项目组内 集成测试总结 项目组内 项目组内 系统测试 系统测试计划 正式 事业部级 项目组内 系统测试用例 正式 事业部级 项目组内 系统测试总结 事业部级 项目组内 培训 培训计划 培训教材 研发验收 研发验收计划 研发验收报告 正式 正式 事业部级 事业部级 子部门级 用户手册 项目组内 项目组内 安装手册 项目组内 项目组内 产品说明书 项目组内 项目组内 实施计划 项目组内 项目组内 掩膜定型测试报告 事业部级 事业部级 平台个人化操作手册 事业部级 事业部级 平台应用开发手册 事业部级 事业部级 Patch使用手册 事业部级 事业部级 产品描述文档 事业部级 事业部级 客户验收 实施计划 正式 正式 事业部级 事业部级 用户手册 项目组内 项目组内 安装于?册 项冃组内 项冃组内 4软件项目实施技术评审注意事项 ＞软件项目技术评审的工作量应占整个软件生命周期的10%以上，对风险较大或规模较大 的工作产品，其开发过程屮的技术评审工作量应适当加大。 ＞正式技术评审的人员不少于三人（含评审负责人），如果不能满足条件，不能进入评审 准备过程。 ＞项目计划中应包含《技术评审计划》，在计划中预留技术评审的工作量。项FI计划评审 时，同时对技术评审计划进行评审。 正式技术评审应以外部评审人员为主（同行）。 技术评审吋，按《IASPEC-SP