软件项目阶段评审管理办法

软件项目阶段评审管理办法一、总则阶段评审是切断软件项目「缺陷向后传递」的关键阀门，而非走过场的文档批注环节。本办法旨在通过设立强制性的质量门禁，确保项目在进入下一生命周期前，其需求、设计、代码或交付物已达到预设的质量基线。1.1适用范围本办法适用于公司内部所有自研及对外交付的软件项目，包括但不限于Web应用、移动端App、后台服务系统及SaaS平台。对于纯外包项目的驻场研发环节，参照本办法执行；对于工期小于2周的紧急修复或运营活动类项目，经研发总监批准后可精简评审流程，但必须保留上线前验收评审。1.2评审分级项目评审分为「常规评审」与「关键评审」。常规评审由项目经理（PM）组织，技术负责人主持；关键评审（包括需求基线化评审、架构设计评审、上线发布评审）必须由质量保证（QA）部门独立监督，且未经QA签字的评审结论一律无效。二、组织与职责评审的效力来源于权责的绝对对等，任何模糊的「共同负责」都将导致最终的无人负责。以下角色定义及职责边界在评审全过程具有最高约束力。2.1评审委员会评审委员会为临时性组织，由以下角色构成：•项目经理（PM）：负责发起评审、协调资源、跟踪遗留问题闭环。对项目进度与评审合规性负责。•技术负责人（TL）：负责技术方案把关、代码质量审查。对技术架构的合理性与可维护性负责。•质量保证工程师（QA）：负责评审流程合规性检查、测试用例审查。对产品发布质量底线负责，拥有一票否决权。•产品经理（PO）：负责需求解释与验收标准确认。对需求文档的完整性负责。2.2责权矩阵•必须由TL批准的动作：技术选型变更、数据库表结构重构、核心接口契约变更。•必须由QA批准的动作：测试准入判定、上线发布门禁通过判定。•严禁越权审批：任何未通过安全评审的功能模块，严禁直接合并至主干分支（将导致生产环境暴露注入攻击面）。三、评审阶段划分与准入准出标准本阶段划分以软件生命周期为骨架，各阶段的准入准出标准必须量化，严禁使用「基本完成」「大部分通过」等模糊表述。所有指标未达标的评审申请，评审委员会必须直接驳回。3.1需求评审阶段需求评审决定了后续所有开发动作的方向。方向偏移1度，在交付期将被放大为100度的灾难。3.1.1评审类型：软件需求规格说明书（SRS）评审•准入条件：1.SRS文档已完成内部初审，无错别字及排版错误。2.原型图/交互稿已全部提供，且与文字描述一致。3.业务流程图、状态机图已覆盖所有正常与异常分支。•准出标准（必须全部满足）：1.评审委员会对需求理解无二义性，所有阻塞性疑问已在会议中澄清。2.需求范围基线化，冻结本期迭代的需求清单，形成带有版本号的《需求基线表》。3.遗留问题总数≤5•动作机理与禁忌：◦机理：建立需求基线的目的，是给后续的变更提供一个明确的对比锚点。没有基线，变更管理就无从谈起。◦禁忌：严禁在需求评审未通过的情况下，提前进入技术设计阶段（将导致需求一旦变更，设计全部推倒重来，造成人天浪费）。◦替代方案：若市场紧急需要技术预研，必须以《技术预研任务书》形式单独立项，其产物不得直接作为正式项目的设计基线。3.2设计评审阶段设计评审是系统可扩展性与高可用性的最后防线。此阶段引入的缺陷，在运行期排查成本将是设计期的50倍以上。3.2.1评审类型：概要设计与详细设计评审•准入条件：1.需求基线已建立。2.《概要设计说明书》及《详细设计说明书》已按公司模板撰写完毕。3.数据库ER图、核心时序图、系统部署架构图已产出。•准出标准：1.接口契约（Swagger/YApi）已定义并由前后端共同确认。2.架构设计满足非功能性需求（并发量预估偏差≤153.安全设计已覆盖（如敏感数据加密存储方案、越权访问防范机制）。•动作机理与禁忌：◦机理：要求定义接口契约，是为了利用Mock机制解耦前后端开发依赖。若接口未定，前端只能阻塞等待后端，导致项目串行延期。◦禁忌：严禁在设计方案中省略异常处理流程与时序图（只画正常流程）。◦后果与替代方案：若发现设计方案遗漏异常分支，必须当场标记为「不通过」，要求设计人员补充完整后重新评审。严禁以「后续口头补充」为由放行。3.3代码评审阶段代码评审是质量内建的核心环节，旨在通过同行审查将低级逻辑错误扼杀在构建期。3.3.1评审类型：合并请求评审•准入条件：1.开发人员已完成单元测试编写，且单元测试覆盖率达到≥802.静态代码扫描工具无阻断级告警。3.代码已合并至测试分支。•准出标准：1.核心业务逻辑代码必须至少由1名同级别或高级开发人员Review通过。2.无未解决的SonarQube阻断级漏洞。3.涉及资金、权限校验的代码必须由TL亲自审查通过。•动作机理与禁忌：◦机理：单元测试覆盖率要求达80%，是为了保证后续重构时有回归测试网兜底，防止「牵一发而动全身」的关联性退化。◦禁忌与替代方案：严禁在主干分支直接提交代码（破坏版本可追溯性，且易导致CI/CD构建被污染）。必须通过PullRequest/MergeRequest流程合并代码。3.4测试验收评审测试验收评审判定系统是否具备移交生产环境的条件，是上线前的最后一道质量门禁。3.4.1评审类型：上线准入评审•准入条件：1.测试用例执行率100%。2.致命缺陷与严重缺陷修复率100%，一般缺陷修复率≥953.性能压测报告已产出，满足设计指标。•准出标准：1.残留的轻微缺陷（≤52.上线回滚方案已编写并验证可行。3.生产环境发布清单（包含配置项变更、数据库DDL脚本）已核对完毕。•风险演化叙事：◦风险：未经验证的数据库DDL脚本直接在生产执行。◦演化路径：生产环境执行耗时超长的DDL锁表→上层应用数据库连接池迅速耗尽→服务线程阻塞→级联触发全站服务雪崩。◦阻断点：必须在准出标准中强制要求DBA在预发环境使用同等数据量级演练DDL，出具锁表时长报告，超过1秒的DDL必须重写为pt-online-schema-change方案。四、评审执行流程评审流程必须形成「计划-执行-检查-处理」的闭环，缺一环则评审失效。任何未按流程流转的评审，不作为项目考核的有效产出。4.1计划与准备•评审发起：项目经理在评审会议预定日期前3个工作日，在项目管理系统中发起评审申请，并上传待评审物料。•物料预审：评审委员会成员必须在会议前1个工作日完成物料阅读，并在系统中提交预审意见。未提交预审意见的成员，不得在评审会议上否决方案（防止临时拍脑门决策）。4.2会议与执行•会议时长：单次评审会议严格控制在2小时以内。若议题过多，拆分为多次会议。•讨论原则：会议聚焦于「决策是否可行」及「是否存在遗漏」，严禁在会议上进行代码级细节纠错或需求重新头脑风暴（偏离主题，浪费全员时间）。4.3检查与处理•会议纪要：PM必须在评审会议结束后24小时内发布会议纪要，明确列出「通过/不通过结论」「遗留问题清单」「责任人」「预计闭环时间」。•闭环验证：责任人整改完成后，由QA验证遗留问题。QA验证通过后，更新系统状态为「评审闭环」。若超过承诺闭环时间48小时未整改，系统自动升级至PMO处理。五、异常处理与升级机制当评审偏离预定轨道时，必须依靠机制而非个人判断来阻断风险扩散。异常情况按严重程度分为三级，各级处置权限严格固化。5.1异常分级与处置原则异常等级判定标准启动权限处置原则与替代方案一级（一般）评审材料不完整、格式不规范、非核心逻辑存在分歧评审会议主持人限期整改。给予责任人1个工作日补充材料，不中止后续非关联流程二级（严重）核心需求未闭环、架构存在单点故障隐患、压测未达标研发总监/QA总监阻断流程。必须驳回当前阶段，退回上一阶段重做，并记录项目延期三级（致命）评审委员会发现存在数据泄露风险、资金漏洞、违反法规要求公司VP及以上紧急熔断。立即冻结相关代码库权限，由安全部门介入专项审计5.2紧急变更绕行机制•适用场景：生产环境突发严重故障需紧急修复，无法按常规流程组织评审。•操作规程：必须由TL向研发总监申请「绿色通道」，获批后可通过Hotfix分支直接修复发布。•事后追溯：紧急发布完成后的3个工作日内，必须补齐代码评审、测试用例及变更评审流程。严禁利用「绿色通道」规避正常需求评审（经查实扣除当月绩效）。六、评审记录与归档要求未被记录的评审等同于未发生评审，所有评审产物必须可追溯，作为后续质量事故定责的直接依据。6.1归档清单每次评审闭环后，PM必须在2个工作日内将以下材料上传至公司配置库（Confluence/语雀）的对应项目空间：1.带有版本号的评审文档（SRS/HLD/LLD等）。2.评审会议签到表及会议纪要（须包含所有评审委员会成员的电子签名或系统审批记录）。3.《遗留问题跟踪表》（闭环状态必须更新为已完成）。6.2存储与保护•归档材料保留期限不得少于项目下线后3年。•涉及核心商业机密的设计文档，必须设置访问权限，仅限项目核心成员及高管查阅。七、附则1.本办法由公司PMO（项目管理办公室）与QA部门联合解释与修订。2.本办法自发布之日起执行，原《软件研发评审规范》同时废止。执行过程中如遇与公司更高层级制度冲突，以上级制度为准。八、附件8.1软件项目阶段评审检查表本表供QA在进入评审会议前进行准入检查使用，任一项不达标即驳回评审申请。阶段检查项量化标准检查结果责任人需求评审SRS文档完整性包含背景、范围、功能清单、非功能需求[]通过[]驳回PM需求评审原型覆盖率核心业务流程原型覆盖率100%[]通过[]驳回PO设计评审接口契约文档核心接口定义完毕且评审通过率100%[]通过[]驳回TL设计评审数据库DDL脚本核心表结构已定，且无未决索引设计问题[]通过[]驳回TL测试准入单元测试覆盖率语句覆盖与分支覆盖综合≥[]通过[]驳回开发负责人上线评审严重缺陷清理致命、严重Bug修复率100%[]通过[]驳回QA上线评审回滚演练回滚方案已在预发环境验证通过1次[]通过[]驳回运维负责人8.2阶段评审会议纪要模板#[项目名称]-[阶段名称]评审会议纪要

##1.会议基本信息

-会议时间：YYYY-MM-DDHH:MM至HH:MM

-会议地点：[会议室名称/线上链接]

-主持人：[姓名]

-参会人员：[姓名列表，需区分评审委员与列席人员]

##2.评审物料

-《XXX需求说明书》v1.2

-《XXX架构设计文档》v1.0

##3.评审结论

-[]评审通过，直接进入下一阶段

-[