vault backup: 2026-11-07 16:33:44

2026-11-07 16:33:55 +08:00
commit 7015312702
1208 changed files with 132432 additions and 0 deletions
@@ -0,0 +1,2 @@
+按功能评估
+按模块评估
@@ -0,0 +1,77 @@
+# 项目概要设计文档
+
+## 1. 文档概述
+- 1.1 项目背景与目标
+- 1.2 文档范围与读者
+- 1.3 术语定义
+- 1.4 参考资料
+
+## 2. 系统总体设计
+- 2.1 系统架构图
+  ├─ 逻辑架构
+  ├─ 物理部署架构
+  ├─ 数据流图
+- 2.2 技术选型
+  ├─ 开发语言与框架
+  ├─ 数据库与中间件
+  ├─ 第三方服务
+- 2.3 模块划分与职责
+  ├─ 模块清单与功能描述
+  ├─ 模块间依赖关系
+
+## 3. 核心功能设计
+- 3.1 关键业务流程
+  ├─ 流程图与时序图
+  ├─ 异常处理流程
+- 3.2 接口设计
+  ├─ 内部接口（RPC/REST）
+  ├─ 外部接口（API文档）
+  ├─ 消息格式（协议定义）
+- 3.3 数据库设计
+  ├─ ER图与表结构
+  ├─ 索引策略
+  ├─ 分库分表方案
+
+## 4. 非功能性设计
+- 4.1 性能设计
+  ├─ QPS/TPS目标
+  ├─ 响应时间要求
+  ├─ 缓存策略
+  ├─ 异步处理设计
+- 4.2 可用性设计
+  ├─ 容灾方案（多活/异地）
+  ├─ 降级熔断策略
+  ├─ 监控告警设计
+- 4.3 安全性设计
+  ├─ 身份认证与授权
+  ├─ 数据加密
+  ├─ 防攻击策略
+- 4.4 可扩展性设计
+  ├─ 水平扩展方案
+  ├─ 插件化架构
+
+## 5. 部署与运维
+- 5.1 环境规划
+  ├─ 开发/测试/生产环境
+  ├─ 资源预估（服务器/存储/带宽）
+- 5.2 部署架构
+  ├─ 容器化方案
+  ├─ 配置管理
+  ├─ 自动化部署流水线
+- 5.3 监控方案
+  ├─ 监控指标清单
+  ├─ 日志收集方案
+  ├─ 告警规则
+
+## 6. 项目计划与风险
+- 6.1 里程碑计划
+- 6.2 团队分工
+- 6.3 风险评估与应对
+  ├─ 技术风险
+  ├─ 资源风险
+  ├─ 时间风险
+
+## 7. 附录
+- 7.1 设计评审记录
+- 7.2 变更记录
+- 7.3 待定问题
@@ -0,0 +1,81 @@
+项目进度计划管理在项目管理中至关重要，项目进度计划的制定应分为以下四步：
+
+## 第一步：了解项目目标范围等基本情况
+>对应禅道中的需求管理、人员安排、阶段规划等
+
+明确项目成本；
+明确项目实施范围；
+明确项目实施周期要求；**就是时间**
+明确项目投入人员情况；包括设备。**就是资源**
+明确项目合同中收款及验收情况。
+
+## 第二步：项目制约因素分析，策划最优项目实施计划
+>对应禅道中的任务安排、测试管理、问题风险管理等
+
+分析项目在本年度能否上线及验收；
+分析项目在本年度能否收 60%的款项（上线款）；
+本年度能收 60%款项（上线款）不能完成验收的项目，验收计划需控制在第二年一季度或上半年；
+项目本年度必须验收（考虑压缩周期，增加人力，成本是否可控）；
+了解客户在项目上的紧迫程度，需求人员支持情况等；
+了解项目标准的实施周期，投入人数；
+考虑上线到验收的时长，即试运行周期；
+分析项目实施风险、规避方案、解决措施等；
+了解测试范围，测试轮次，测试严格程度等。
+
+## 第三步：项目实施计划制定
+>直接参照模板，在禅道中各个阶段创建关键任务
+
+基于项目基本情况和制约因素确定项目的实施周期，先初步规划项目重要里程碑，再列出各里程碑阶段的关键事项，最后对关键事项分解形成具体任务，通过合理的排期形成项目实施计划，各阶段关键事项如下：
+
+## 第四步：项目实施计划评审
+【对应禅道中的评审——项目计划】
+邀请项目总监，区域负责人一起评审；
+针对项目实施计划合理性，成本可控性，人员投入情况进行审核；
+针对项目实施计划风险，解决措施，规避方案，保障计划有效落地进行审核。
+
+
+
+
+
+
+产品型项目需要关联产品
+![[a5ad93c5bc48c150209b4aee3433454.png]]
+
+
+
+
+
+用户在互联网端的应用客户端运行在各种环境里，包括PC端Windows与Mac系统等、移动终端Android与iOS系统等，而传统的数字签名方案一般都是用USBKey或者BluetoothKey等硬件数字证书应用方案，由此带来的问题是不便捷、兼容性差、用户采购成本高。所以传统的数字证书应用方案已经不能适应当前密码安全的发展需求。
+
+因此在用户无需任何额外硬件介质的条件下，为用户在互联网端提供安全合规的数字签名解决方案，有助于提升信雅达安全产品的综合竞争力，同时也有利于拓展非金融领域的安全产品市场，所以开发一套协同签名安全服务平台有着非常重要的意义。
+
+支持PC端的Windows、Linux客户端，移动端的Android、 IOS系统的客户端，
+
+客户端协同签名安全模块SDK：
+
+1) 客户端协同签名安全模块 SDK 兼容 WEB。
+
+2) 客户端协同签名安全模块 SDK 兼容文件操作
+
+3) 客户端协同签名安全模块 SDK 兼容HMAC-SM3
+
+4) 客户端协同签名安全模块 SDK 兼容HTTPS协议
+
+协同签名安全服务平台：
+
+5) 协同签名安全服务平台兼容信创数据库OceanBase？
+
+6) 协同签名安全服务平台兼容HTTPS协议；
+
+7) 协同签名安全服务平台web管理新增客户端证书存储、查询、删除
+
+8) 协同签名安全服务平台web管理新增证书最大下载书配置，证书CA信息配置
+
+9) 认证模块配置
+
+10) 协同签名安全服务平台web管理支持非对称密钥的产生、分发、更换、使用、备份、恢复、销毁
+
+11) 支持SNMP、SYSLOG等标准协议配置
+
+12) 服务端支持keepalive功能
+
@@ -0,0 +1,29 @@
+一、必须体现的核心内容：
+1. 系统架构设计
+- 清晰绘制分层架构图（展示表现层 / 业务层 / 数据层）
+- 关键技术选型说明（如 Spring Cloud 微服务框架、MySQL 集群方案）
+- 模块间通信机制（RESTful API/gRPC/ 消息队列等）
+
+2. 模块划分规范
+- 模块功能矩阵表（含模块名称、责任人、接口数量、预计代码量）
+- 模块依赖关系图（使用 PlantUML/C4 模型呈现）
+- 接口定义模板（包含版本号、输入输出示例、错误码规范）
+
+3. 数据模型设计
+- 实体关系图（ER 图需包含主外键约束）
+- 数据库分表策略（如用户表按 UID 范围分表）
+- 缓存设计方案（Redis 集群拓扑 + 缓存穿透解决方案）
+
+二、关键注意事项：
+1. 设计约束明确
+- 标注不可变更的硬性限制（如必须兼容旧系统 SOAP 协议）
+- 第三方依赖清单（包含版本号及对接负责人）
+
+2. 非功能指标量化
+- 性能指标：明确 TPS 要求（如支付接口≥3000 次 / 秒）
+- 可靠性：定义 SLA 等级（如核心服务 99.99% 可用性）
+- 安全基线：加密算法标准（如 RSA 2048 位密钥）
+
+3. 扩展性设计
+- 预留扩展点标识（如插件机制扩展接口）
+- 容量弹性方案（自动扩缩容触发阈值）