RMDC系统设计文档 整体转换为SKILL
This commit is contained in:
285
99-项目模板/软件开发流程说明.md
Normal file
285
99-项目模板/软件开发流程说明.md
Normal file
@@ -0,0 +1,285 @@
|
||||
## 一、典型的软件开发流程(中国境内常见实践)
|
||||
|
||||
在中国,软件开发流程通常是**“类瀑布 + 敏捷迭代”的混合模式**,尤其在互联网公司最为常见。
|
||||
|
||||
整体流程可抽象为 8 个阶段:
|
||||
|
||||
```
|
||||
立项 → 需求分析 → 产品设计 → 技术设计 → 开发 → 测试 → 上线 → 运维/迭代
|
||||
```
|
||||
|
||||
下面逐阶段展开。
|
||||
|
||||
---
|
||||
|
||||
## 二、各阶段说明 + 核心文档
|
||||
|
||||
### 1️⃣ 立项阶段(项目启动)
|
||||
|
||||
**目标**:决定“做不做、为什么做、值不值得做”。
|
||||
|
||||
**参与角色**
|
||||
|
||||
* 业务负责人 / 产品负责人
|
||||
* 技术负责人
|
||||
* 管理层(评审)
|
||||
|
||||
**常见文档**
|
||||
|
||||
| 文档 | 说明 |
|
||||
| ----- | -------------- |
|
||||
| 项目立项书 | 项目背景、目标、范围、ROI |
|
||||
| 可行性分析 | 技术、成本、周期、风险 |
|
||||
| 项目章程 | 角色分工、里程碑 |
|
||||
|
||||
👉 政企项目中尤为正式,互联网内部项目可能简化。
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ 需求分析阶段(需求澄清)
|
||||
|
||||
**目标**:搞清楚“用户要什么、业务怎么跑”。
|
||||
|
||||
**核心角色**
|
||||
|
||||
* 产品经理(主导)
|
||||
* 业务方
|
||||
* 技术、测试参与评审
|
||||
|
||||
**关键文档**
|
||||
|
||||
* **PRD(重点,见下文详解)**
|
||||
* 需求评审纪要
|
||||
* 原型图(Axure / 墨刀 / Figma)
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ 产品设计阶段(方案细化)
|
||||
|
||||
**目标**:把“需求”变成“可交付的产品形态”。
|
||||
|
||||
**文档**
|
||||
|
||||
| 文档 | 内容 |
|
||||
| ------ | --------- |
|
||||
| 交互原型 | 页面跳转、流程 |
|
||||
| UI 设计稿 | 视觉规范 |
|
||||
| 业务流程图 | 状态流转、业务规则 |
|
||||
|
||||
> 在很多公司,**产品设计与需求分析阶段是合并的**。
|
||||
|
||||
---
|
||||
|
||||
### 4️⃣ 技术设计阶段(系统设计)
|
||||
|
||||
**目标**:回答“技术上怎么实现”。
|
||||
|
||||
**核心角色**
|
||||
|
||||
* 技术负责人 / 架构师
|
||||
* 后端 / 前端 / 客户端
|
||||
|
||||
**关键文档**
|
||||
|
||||
| 文档 | 说明 |
|
||||
| ----------------- | --------------- |
|
||||
| **DDS(重点,见下文详解)** | 详细设计说明 |
|
||||
| 架构设计说明 | 系统拆分、技术选型 |
|
||||
| 接口文档 | API 定义(Swagger) |
|
||||
| 数据库设计 | 表结构、索引 |
|
||||
|
||||
---
|
||||
|
||||
### 5️⃣ 开发阶段(编码实现)
|
||||
|
||||
**目标**:把设计变成代码。
|
||||
|
||||
**常见产物**
|
||||
|
||||
* 代码仓库(Git)
|
||||
* Code Review 记录
|
||||
* 开发自测说明
|
||||
|
||||
**中国公司特点**
|
||||
|
||||
* 强调 **PR / MR 审核**
|
||||
* 常配合 Jira / TAPD / 禅道
|
||||
|
||||
---
|
||||
|
||||
### 6️⃣ 测试阶段
|
||||
|
||||
**目标**:验证功能、稳定性、安全性。
|
||||
|
||||
**文档**
|
||||
|
||||
| 文档 | 说明 |
|
||||
| ---- | ------------ |
|
||||
| 测试计划 | 测什么、怎么测 |
|
||||
| 测试用例 | 功能 / 异常 / 边界 |
|
||||
| 缺陷单 | Bug 记录 |
|
||||
|
||||
---
|
||||
|
||||
### 7️⃣ 上线发布阶段
|
||||
|
||||
**目标**:安全、可控地交付生产环境。
|
||||
|
||||
**文档**
|
||||
|
||||
* 上线方案
|
||||
* 回滚方案
|
||||
* 变更单(政企尤其严格)
|
||||
|
||||
---
|
||||
|
||||
### 8️⃣ 运维与迭代阶段
|
||||
|
||||
**目标**:稳定运行 + 持续优化。
|
||||
|
||||
**文档**
|
||||
|
||||
* 运维手册
|
||||
* 监控指标说明
|
||||
* 复盘文档
|
||||
|
||||
---
|
||||
|
||||
## 三、重点详解:PRD 是什么?
|
||||
|
||||
### 1️⃣ PRD 全称与含义
|
||||
|
||||
> **PRD = Product Requirements Document**
|
||||
> 中文常称:**产品需求文档**
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ PRD 是“做什么”,不是“怎么做”
|
||||
|
||||
**PRD 解决的问题:**
|
||||
|
||||
* 用户是谁?
|
||||
* 解决什么问题?
|
||||
* 产品功能是什么?
|
||||
* 业务规则是什么?
|
||||
* 成功标准是什么?
|
||||
|
||||
**PRD 不关心:**
|
||||
|
||||
* 用什么语言
|
||||
* 表怎么建
|
||||
* 接口怎么拆
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ PRD 的典型结构(中国公司常见)
|
||||
|
||||
```text
|
||||
1. 背景与目标
|
||||
2. 用户画像
|
||||
3. 使用场景
|
||||
4. 功能需求列表
|
||||
5. 业务规则
|
||||
6. 非功能需求(性能、权限)
|
||||
7. 异常与边界
|
||||
8. 数据埋点(互联网常见)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4️⃣ PRD 的作者 & 读者
|
||||
|
||||
| 角色 | 是否主要使用 |
|
||||
| ---- | ------ |
|
||||
| 产品经理 | ✅ 编写 |
|
||||
| 技术 | ✅ 理解需求 |
|
||||
| 测试 | ✅ 编写用例 |
|
||||
| 业务 | ✅ 验收 |
|
||||
|
||||
---
|
||||
|
||||
### 5️⃣ 中国语境下的特点
|
||||
|
||||
* PRD **非常详细**
|
||||
* 常被当作“需求合同”
|
||||
* 政企项目中甚至作为验收依据
|
||||
|
||||
---
|
||||
|
||||
## 四、重点详解:DDS 是什么?
|
||||
|
||||
### 1️⃣ DDS 全称与含义
|
||||
|
||||
> **DDS = Detailed Design Specification**
|
||||
> 中文常称:**详细设计说明书**
|
||||
|
||||
⚠️ 注意:
|
||||
不要和“数据分发服务(Data Distribution Service)”混淆。
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ DDS 是“怎么做”,不是“做什么”
|
||||
|
||||
**DDS 解决的问题:**
|
||||
|
||||
* 系统架构怎么拆?
|
||||
* 模块职责是什么?
|
||||
* 接口参数、返回值?
|
||||
* 数据表怎么设计?
|
||||
* 关键算法逻辑?
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ DDS 的典型结构
|
||||
|
||||
```text
|
||||
1. 总体技术架构
|
||||
2. 模块划分说明
|
||||
3. 核心流程时序图
|
||||
4. 接口设计(API)
|
||||
5. 数据库设计(ER 图)
|
||||
6. 异常与容错设计
|
||||
7. 性能与并发考虑
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4️⃣ DDS 的作者 & 读者
|
||||
|
||||
| 角色 | 是否主要使用 |
|
||||
| ----- | -------- |
|
||||
| 技术负责人 | ✅ 主导 |
|
||||
| 开发工程师 | ✅ 实现依据 |
|
||||
| 测试 | ◯ 理解技术边界 |
|
||||
| 产品 | ◯ 辅助理解 |
|
||||
|
||||
---
|
||||
|
||||
### 5️⃣ 中国公司 DDS 的现实情况
|
||||
|
||||
| 公司类型 | DDS 情况 |
|
||||
| --------- | ------- |
|
||||
| 政企 / 传统软件 | 必须,极其正式 |
|
||||
| 大厂 | 视项目而定 |
|
||||
| 创业公司 | 常弱化或口头 |
|
||||
|
||||
---
|
||||
|
||||
## 五、PRD 与 DDS 的对比总结(重点)
|
||||
|
||||
| 维度 | PRD | DDS |
|
||||
| ---- | ----------------------------- | ----------------------------- |
|
||||
| 全称 | Product Requirements Document | Detailed Design Specification |
|
||||
| 关注点 | 业务 & 产品 | 技术 & 实现 |
|
||||
| 回答问题 | 做什么 | 怎么做 |
|
||||
| 作者 | 产品经理 | 技术负责人 |
|
||||
| 面向对象 | 产品 / 技术 / 测试 | 开发 / 架构 |
|
||||
| 是否必须 | 几乎必须 | 视项目规模 |
|
||||
| 中国特点 | 偏详细 | 偏重形式化 |
|
||||
|
||||
---
|
||||
|
||||
## 六、一句话总结(非常重要)
|
||||
|
||||
> **PRD 是业务视角的“需求合同”,DDS 是技术视角的“实现蓝图”。**
|
||||
|
||||
Reference in New Issue
Block a user