1、交付物
1.1软件
实现需求明细列表需求功能，业务验收人员完成业务验收。
文档
| 编号 | 文档 | 验收形式 | 备注 | 验收角色 | 负责人 |
|---|---|---|---|---|---|
| 1 | 总体设计说明书 | 文档 | 必须提供 | 研发 | 刘佳辉 |
| 2 | 需求明细列表及需求变更记录 | 文档 | 必须提供 | 产品经理研发 | 刘鸳 刘佳辉 |
| 3 | PRD 与原型文档 | 文档 | 必须提供 | 产品经理研发 | xxx |
| 4 | 代码文件结构说明书 | 文档 | 如涉及，必须提供 | 研发 | xxx |
| 5 | 数据库设计说明书 | 文档 | 必须提供 | 研发 | |
| 6 | 接口使用说明书 | 文档 | 必须提供 | 研发 | |
| 7 | 系统业务参数配置说明 | 文档 | 如涉及，必须提供 | 产品经理研发 | |
| 8 | 服务器软件硬件环境配置说明书 | 文档 | 如涉及，必须提供 | 研发 | |
| 9 | 浏览器， 手机与机型适配清单 | 文档 | 如涉及，必须提供 | 研发 | |
| 10 | 测试用例 | 文档 | 必须提供 | 测试 | |
| 11 | BUG历史记录表 | 文档 | 必须提供 | 测试 | |
| 12 | 质量分析报告 | 文档 | 必须提供 | 测试 | |
| 13 | 系统使用手册 | 文档 | 必须提供 | 产品经理研发 | |
| 14 | 开发环境搭建文档 | 文档 | 如涉及，必须提供 | 研发 |
2、项目验收
2.1 验收方式
| 1. 将要交付的软件安装于指定服务器，并完成调试和上线；
- 完成培训后，业务验收人员根据需求明细列表实现情况进行验收评价，研发验收人员根据以下内容进行验收评价。 | | ------------------------------------------------------------------------------------ |
2.2 文档验收
| 1. 文档齐全（参考如上文档清单）；
- 文档内容描述准确, 没有歧义和错误的表达；
- 文档内容容易理解, 通过使用适当的术语、图形表示、详细的解释来表达；
- 文档对主要功能和关键操作尽量提供应用实例。 | | -------------------------------------------------------------------------------------------------------------- |
2.3 界面验收
| 1. 涉及手机端系统中外包团队需提供与软件适配的手机与版本号清单 ；
- 涉及手机端系统中各界面需要做好手机、UI兼容与机器适配；
- 原则上，浏览器至少需适配Chrome、Safari、火狐；
- 原则上，手机至少需适配苹果、小米、华为、vivo、OPPO、三星等主流机型。 | | ------------------------------------------------------------------------------------------------------------------------------------------------- |
2.4 功能验收
| 1. 功能验收范围覆盖：接口、数据库存取、页面功能等；
- 提供系统测试用例；
- 提供BUG管理跟踪记录表；
- 提供质量分析报告。 | | -------------------------------------------------------------------------- |
2.5 性能验收
| 1. 提供性能测试报告；
- 相关重要指标达到以下要求C端系统：| 分类 | 接口可用率 | 响应90线 | 响应99线 | 并发量 | | ------ | ------ | -------- | --------- | ------ | | API接口 | 99.99% | < 100 ms | < 1000 ms | >1500 | | 系统操作 | 99.99% | < 100 ms | < 1000 ms | >1500 | | ------ | ------ | ------ | ------ | ------ |B端系统：| 分类 | 接口可用率 | 响应90线 | 响应99线 | 并发量 | | ----- | ------ | -------- | --------- | ---- | | API接口 | 99.99% | < 100 ms | < 1000 ms | >150 | | 系统操作 | 99.99% | < 200 ms | < 2000 ms | >150 | | 报表 | 99.99% | < 500 ms | < 4000 ms | >50 | | 定时任务 | 99.99% | -- | -- | |备注： 不同业务系统需要按业务场景设计性能指标， 上述为建议指标。 | | | | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - | - | - | - |
2.6 安全验收
| 1. 【强制】软件中的敏感数据需以密文方式存储；
- 【强制】软件需有留痕功能，即保存用户的操作日志、系统异常日志、接口调用数据日志等；
- 【强制】软件中各种用户的权限分配合理；
- 【强制】扫描出的安全漏洞（包含但不限于：越权访问、XSS跨站攻击、SQL注入、文件上传漏洞、跨站请求伪造等）外包团队需修复完毕。
- 【推荐】等保3.0、ISO27001、ISO9001证书等安全资质证明
- 【强制】内部安全评审报告
- 【强制】系统安全测试报告（内/外部）
- 【强制】产品本身的安全功能点 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
2.4 用户验收
| 1. 外包团队需提供稳定的用户验收环境；
- 业务场景功能测试不通过数的比例<1.5%；
- 不存在严重等级为1的错误；
- 不存在严重等级为2的错误；
- 严重等级为3的错误数量≤5；
- 所有提交的问题都已得到修复；
- 以上功能，用户验收测试通过后，由用户负责人签署验收通过确认书。| 级别 | 描述 | | ---- | ------------------------------------------- | | 1-严重 | 导致系统崩溃，异常死机，服务停止， 数据库混乱及系统不能正常运行等 | | 2-关键 | 需求说明书中要求的重要功能没有实现， 功能不完整，有问题影响核心流程等 | | 3-一般 | 功能存在缺陷； 存在数据控制错误； 影响单个功能运行的问题 | | 4-轻微 | 不影响业务运行的问题，对非法数据没有进行有效控制，不会有业务影响的，功能可以进一步改进 | | 5-微小 | 建议性缺陷； 满足需求功能， 使用方便， 不合理，界面不友好 | | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - |
3、源码交接
如涉及到源码交接，按下列规范进行验收和交接。
3.1 交接前提条件
| 1. 需提供用户验收通过确认书；
- 涉及交接的软件，原则上建议接受交接软件所有功能，不建议交接软件部分功能模块；
- 跟薪资类无关的软件或功能，所有功能需在线上稳定运行不少于3个月；跟薪资类相关的软件或功能，所有功能需在线上稳定运行不少于6个月；
- 线上稳定运行既线上可用率，需满足：最近3至6个月内，线上没有出现影响20人以上或数据错误的严重bug，且每月线上bug数不超过3个。 | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
3.2 交接规则
| 1、交接过程指的是在外包团队完成版本上线，本公司技术人员进接收工作后到系统验收完成的过程。 2、本过程中发现的线上遗留问题外包团队需负责处理修改，完成问题修复，本公司技术协助给于外包团队所需的日志查询权限，数据查询权限等支持。 3、发现系统与交付验收资料说明不符的设计，需要说明原由，本公司技术负责决定是否需要外包团队修改。 4、出现的偶发性线上问题，包外团队需要负责排查， 不得以无法重现回避排查。 5、对于性能达不到要求的设计，需重新提供方案重新设计，不得提出不合理的硬件资源扩展要求以推诿责任。 6、此期间外包团队所需要排查处理问题的时间：影响严重的不得超过1天； 影响一般不得超过3天； 7、在此期间外包团队有责任给于本公司技术所需的技术支持，明确外包团队支持责任人，如需更换需得到本公司确认； 影响程度以对本公司业务影响来确定:| 序号 | 影响程度 | 影响范围 | | -- | ---- | ---------------------------------------------------- | | 1 | 严重 | 造成公司资金损失>=1000元影响核心业务运转；影响使用人员>=10人系统不可用存在严重问题隐患... | | 2 | 一般 | 造成公司资金损失影响业务运转；影响业务人员使用一般性系统Bug存在问题隐患... | | | | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - | - |
3.3 源码验收
| 1. 代码应只保留跟本项目相关的代码，无效代码应一律去除；
- 数据库应只保留跟本项目相关的表，无效内容应一律去除；
- 【建议】特别注意合理做好数据表结构设计，适当冗余提升性能；
- 代码结构清晰无冗余，注释完整有效，避免硬编码；
- 但凡不符合源码验收规范的，外包团队需修复完毕。
- 系统中使用的非外包团队开发，需要有使用授权的系统组件，需要提供相关使用授权
- 交付环境需要包括 “开发”、“测试”、“生产”等运行环境， 交付代码放到本公司提供的代码仓库中，涉及的jar包需入到本公司的Maven仓库中； | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
3.4 其他注意点
| 1. 对于外包团队的软硬件选型，建议业务部门邀请本公司IT团队一起参与决策；
- 与外包团队商签署的商务合同和补充协议等，建议业务部门邀请本公司IT团队一起参与制定；
- 外包团队使用的环境、数据库、网络、语言、框架、技术、组件等需事先获得本公司IT团队认可；
- 如外包项目不符合或无法满足上述验收规范的，建议商务层面延长付款周期、扣除相应款项或终止合同；
- 每一笔合同款在支付给外包团队之前，除了需获得用户验收通过确认书之外，还应通过IT团队验收；
- 以上内容建议附加进商务合同，成为其中一部分。 | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
4、交接完成
以上所有项交接完成，由上级领导审核通过后，整个交接仪式完成
