软件开发质量与交付规范

一、先把交付要求说清楚

项目负责人应与客户确认做哪些功能、哪些内容不在本次范围、何时交付，以及客户怎样验收。每项需求应能找到对应的设计、实现版本和测试结果。需求改变时，先说明对费用、工期、数据和安全的影响，再由有权人员确认。

演示成功不等于全部验收完成。临时数据、模拟接口和仍待验证的功能，应在演示和交付材料中讲清楚。

二、设计时安排好安全措施

研发负责人应说明用户、管理员、不同客户和外部系统分别能做什么，并画清数据从哪里进入、保存在哪里、会发给谁、如何导出和删除。生产、测试、备份和远程运维所在地区也要写清楚。

账号登录、文件权限、客户隔离、敏感操作、操作日志、备份恢复和退出删除，都应成为具体的设计及验收项目。例如，不只写“有权限管理”，还应写“甲客户不能下载乙客户的附件”，并安排实际测试。

涉及等保建设的系统，应在设计阶段确定适用要求、责任人和验证方法。接入AI或其他外部服务时，还要先核对客户授权和服务商条款。

三、代码、依赖与开发环境

源码和构建配置应纳入版本管理，限制主分支和正式发布权限。重要修改应说明原因、影响和测试结果；涉及登录、授权、资金、数据删除、迁移及对外发送资料的代码，必须重点审查。审查发现的问题处理后才能进入正式发布。

项目应保存实际使用的第三方软件名称、版本、来源、许可和已知风险。依赖版本要能够确定，避免每次构建自动取到不同版本；不得从来源不明的链接安装可执行软件。交付版本应能从受控源码和依赖重新构建。

生产密码、密钥和客户原始数据不得提交到代码仓库，也不得写入普通文档、测试样本或构建日志。开发和测试环境原则上使用模拟或脱敏数据；确需真实数据时，按客户授权设置范围、人员和删除期限。

AI生成的代码也必须经过审查和测试，检查逻辑、安全、资料外发及第三方许可，不能直接复制上线。

四、测试要覆盖实际失败情况

研发负责人应按功能和修改风险安排测试，既检查正常使用，也检查错误输入、权限不足、服务故障和并发操作。下列场景存在时必须验证；不适用的，记录原因。

扫描工具、单元测试和构建检查各有作用，关键业务仍要按实际流程验证。数据迁移、权限变更和备份恢复，应在隔离环境或受控窗口实际演练。测试记录要说明环境、版本、步骤、结果和未覆盖范围。

五、哪些问题必须阻止发布

发现可以绕过登录、跨客户读取资料、有效密钥泄露、关键数据丢失、不可控删除或其他可直接利用的重大安全问题时，修复并复验前不得正式发布。

其他缺陷应记录影响、临时办法、责任人和期限，由有权人员决定是否接受。影响客户验收或合同要求的，应由客户确认；内部批准不能免除法律义务。

关闭缺陷前，应验证原问题和类似入口。仅有代码提交记录，不足以证明运行环境中的问题已解决。

六、发布和数据库变更

发布负责人应在发布单写明版本、目标环境、执行人、批准人、时间、配置差异、数据变更、影响及通知安排。操作前再次确认目标，防止把本地测试命令误用于生产环境。

发布前检查备份、可用恢复点、磁盘容量、外部服务和所需权限。数据库变更尤其要说明是否可以撤回。例如，删除字段后仅退回旧程序，可能无法恢复字段中的数据，必须提前验证数据备份或其他恢复办法。

发布单还应规定什么情况必须停止、谁作决定、如何恢复。出现约定的异常时，停止后续操作，按方案回退或恢复，并核对新产生的数据是否丢失或重复。

发布后实际检查登录、权限、关键查询和写入、后台任务、日志及告警。清理临时账号、调试开关和临时访问权限，保留开始结束时间、操作结果和异常处理记录。紧急修复也要保留授权及必要保护措施，事后补做复核。

七、验收与后续维护

交付材料应按项目范围包含：功能说明、软件及依赖版本、部署与配置说明、运维和备份恢复方法、安全控制、测试和验收记录、已知限制及维护责任。源码、知识产权和第三方许可按合同交接。密码与密钥使用单独的受控渠道传递。

项目负责人应让客户清楚管理员职责、故障及安全联系人、数据导出方法和服务结束后的交接安排。尚未解决的问题，应写明影响、负责人和下一步。

后续维护继续执行相应的审查、测试和发布步骤。一次验收不代表客户预先同意以后改变数据用途或增加外部服务。

本规范与网络与系统安全控制规范、客户数据保护规则及AI使用规则配合执行。