methodology-waterfall

瀑布方法论技能

提供瀑布式软件开发的系统化实践指导,帮助团队实现有序、可预测、文档驱动的软件交付。

何时使用此技能

当用户请求以下任何内容时使用此技能:

• "瀑布方法"
• "瀑布模型"
• "阶段门控"
• "需求规格说明"
• "详细设计文档"
• "顺序开发"
• "传统项目管理"
• "瀑布式规划"

核心原则

基于传统软件工程的顺序阶段模型:

1. 线性顺序: 一个阶段完成后才进入下一个
2. 文档驱动: 每个阶段产出详细文档
3. 前期规划: 需求和设计在开发前完全确定
4. 质量门控: 每个阶段结束有正式评审
5. 变更控制: 严格的变更管理流程

瀑布模型的适用性

✅ 适用场景:
- 需求完全确定且不会变化
- 项目规模大,复杂度高
- 严格监管行业 (金融、医疗、航空)
- 需要详细文档和可追溯性
- 外包项目 (固定价格合同)
- 团队地理分布,需要明确分工

❌ 不适用场景:
- 需求不确定或频繁变化
- 需要快速反馈和迭代
- 创新性项目
- 创业公司和快速变化的市场
- 用户参与度高的项目

瀑布模型阶段

完整生命周期

需求分析 → 系统设计 → 实施/编码 → 测试 → 部署 → 维护
    ↓         ↓          ↓        ↓      ↓      ↓
  需求文档   设计文档   源代码   测试报告 部署文档 维护日志
    ↓         ↓          ↓        ↓      ↓
  ✓审批    ✓审批      ✓审批    ✓审批  ✓验收

阶段1: 需求分析 (Requirements Analysis)

目标: 明确"做什么"

活动清单:

- [ ] 干系人识别和访谈
- [ ] 业务需求收集
- [ ] 功能需求定义
- [ ] 非功能需求定义 (性能、安全、可用性)
- [ ] 用例分析
- [ ] 需求优先级排序
- [ ] 可行性研究
- [ ] 成本和时间估算

交付物:

需求规格说明书 (SRS - Software Requirements Specification)

# 需求规格说明书

## 1. 引言
### 1.1 目的
[文档的目的和预期读者]

### 1.2 项目背景
[项目启动原因、业务目标]

### 1.3 范围
[系统边界、包含和不包含的功能]

### 1.4 术语和缩写
| 术语 | 定义 |
|------|------|
| SRS | Software Requirements Specification |

## 2. 总体描述
### 2.1 产品概述
[系统总体功能描述]

### 2.2 用户特征
- 管理员: [角色描述]
- 普通用户: [角色描述]

### 2.3 运行环境
- 操作系统: [...]
- 数据库: [...]
- 依赖系统: [...]

### 2.4 约束条件
- 技术约束: [...]
- 政策约束: [...]
- 时间约束: [...]

## 3. 功能需求
### 3.1 用户管理模块
#### FR-001: 用户注册
**描述**: 系统应允许新用户注册账号

**输入**:
- 用户名 (3-20字符)
- 邮箱 (有效邮箱格式)
- 密码 (8-20字符,包含字母和数字)

**处理**:
1. 验证输入格式
2. 检查用户名和邮箱是否已存在
3. 密码加密存储
4. 生成用户ID
5. 发送验证邮件

**输出**:
- 成功: 返回用户ID,跳转到验证邮件页面
- 失败: 显示错误信息

**优先级**: P0 (必须)

**可追溯性**: 对应业务需求 BR-001

#### FR-002: 用户登录
[详细描述...]

### 3.2 [其他模块]
[...]

## 4. 非功能需求
### 4.1 性能需求
- NFR-001: 页面响应时间 < 2秒 (90%用户)
- NFR-002: 支持并发用户数 >= 10,000
- NFR-003: 数据库查询响应时间 < 500ms

### 4.2 安全需求
- NFR-004: 密码加密存储 (bcrypt)
- NFR-005: HTTPS通信
- NFR-006: SQL注入防护
- NFR-007: XSS防护

### 4.3 可用性需求
- NFR-008: 系统可用性 >= 99.9%
- NFR-009: 计划内停机 < 4小时/月

### 4.4 可维护性需求
- NFR-010: 代码遵循编码规范
- NFR-011: 关键模块测试覆盖率 >= 80%

### 4.5 兼容性需求
- NFR-012: 支持浏览器: Chrome, Firefox, Safari, Edge (最新2个版本)

## 5. 数据需求
### 5.1 数据实体
#### 用户 (User)
| 字段名 | 类型 | 长度 | 必填 | 描述 |
|--------|------|------|------|------|
| user_id | INT | - | Y | 用户ID (主键) |
| username | VARCHAR | 20 | Y | 用户名 (唯一) |
| email | VARCHAR | 100 | Y | 邮箱 (唯一) |
| password_hash | VARCHAR | 255 | Y | 密码哈希 |
| created_at | TIMESTAMP | - | Y | 创建时间 |

## 6. 外部接口需求
### 6.1 用户界面
- 登录页面: [线框图引用]
- 注册页面: [线框图引用]

### 6.2 硬件接口
[如果需要]

### 6.3 软件接口
- 支付网关API: [接口规范]
- 短信服务API: [接口规范]

## 7. 质量属性
### 7.1 可测试性
[如何验证需求]

### 7.2 可追溯性矩阵
| 需求ID | 业务需求 | 设计文档 | 测试用例 |
|--------|---------|---------|---------|
| FR-001 | BR-001 | DD-001 | TC-001 |

## 8. 附录
### 8.1 用例图
[UML用例图]

### 8.2 流程图
[关键业务流程图]

阶段门控标准:

需求评审检查清单:
- [ ] 所有功能需求清晰、完整、可测试
- [ ] 非功能需求量化且可验证
- [ ] 需求无矛盾和冲突
- [ ] 所有干系人确认需求
- [ ] 可行性研究通过
- [ ] 成本和时间估算合理
- [ ] 风险识别和缓解计划
- [ ] SRS文档完整且通过评审

审批:
- [ ] 产品经理签字
- [ ] 架构师签字
- [ ] 项目经理签字
- [ ] 客户/业务方签字

阶段2: 系统设计 (System Design)

目标: 明确"怎么做"

活动清单:

高层设计 (HLD):
- [ ] 系统架构设计
- [ ] 技术选型
- [ ] 系统分解 (模块/子系统)
- [ ] 接口定义
- [ ] 数据库设计 (概念模型)
- [ ] 部署架构

详细设计 (LLD):
- [ ] 类图设计
- [ ] 序列图设计
- [ ] 数据库详细设计 (ER图、表结构)
- [ ] 算法设计
- [ ] 接口详细定义
- [ ] 错误处理设计

交付物:

系统设计文档 (SDD - System Design Document)

# 系统设计文档

## 1. 引言
### 1.1 目的
[文档目的]

### 1.2 范围
[设计覆盖的系统范围]

### 1.3 参考文档
- 需求规格说明书 (SRS) v1.0

## 2. 系统架构
### 2.1 架构概述
[系统总体架构图 - 三层架构/微服务/...]

┌─────────────────────────────────┐ │ Presentation Layer │ │ (Web UI / Mobile App) │ └───────────┬─────────────────────┘ │ HTTPS/REST API ┌───────────▼─────────────────────┐ │ Application Layer │ │ (Business Logic / Services) │ └───────────┬─────────────────────┘ │ SQL/JDBC ┌───────────▼─────────────────────┐ │ Data Layer │ │ (MySQL Database / Cache) │ └─────────────────────────────────┘

### 2.2 技术选型
| 层次 | 技术 | 版本 | 理由 |
|------|------|------|------|
| 前端 | React | 18.x | 组件化、生态丰富 |
| 后端 | Java Spring Boot | 3.x | 企业级、成熟稳定 |
| 数据库 | MySQL | 8.0 | 事务支持、可靠性 |
| 缓存 | Redis | 7.0 | 高性能、支持多数据结构 |
| Web服务器 | Nginx | 1.24 | 反向代理、负载均衡 |

### 2.3 系统分解
#### 2.3.1 模块划分
- **用户管理模块** (User Management)
  - 用户注册
  - 用户登录
  - 个人信息管理

- **订单管理模块** (Order Management)
  - 创建订单
  - 订单查询
  - 订单取消

- **支付模块** (Payment)
  - 支付集成
  - 支付回调处理

#### 2.3.2 模块依赖关系

用户管理 ←── 订单管理 ←── 支付模块

## 3. 详细设计
### 3.1 类图
#### 用户管理模块类图

┌───────────────────┐ │ UserService │ ├───────────────────┤ │ + register() │ │ + login() │ │ + updateProfile() │ └────────┬──────────┘ │ uses ┌────────▼──────────┐ │ UserRepository │ ├───────────────────┤ │ + save() │ │ + findById() │ │ + findByEmail() │ └───────────────────┘

### 3.2 序列图
#### 用户注册序列图

用户 → 前端 → UserController → UserService → UserRepository → 数据库 │ │ │ │ │ │ │ 提交表单│ │ │ │ │ │────────>│ │ │ │ │ │ │ validate() │ │ │ │ │ │───────────>│ │ │ │ │ │ │ register() │ │ │ │ │ │──────────────>│ │ │ │ │ │ │ checkExist() │ │ │ │ │ │───────────────>│ │ │ │ │ │ │ SELECT │ │ │ │ │ │──────────>│ │ │ │ │ │<──────────│ │ │ │ │ save() │ │ │ │ │ │───────────────>│ │ │ │ │ │ │ INSERT │ │ │ │ │ │──────────>│ │<────────────────────────────────────────────────────────────│

### 3.3 数据库设计
#### 3.3.1 ER图
[实体关系图]

#### 3.3.2 表结构
```sql
-- 用户表
CREATE TABLE users (
    user_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '用户ID',
    username VARCHAR(20) NOT NULL UNIQUE COMMENT '用户名',
    email VARCHAR(100) NOT NULL UNIQUE COMMENT '邮箱',
    password_hash VARCHAR(255) NOT NULL COMMENT '密码哈希',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
    INDEX idx_email (email),
    INDEX idx_username (username)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

-- 订单表
CREATE TABLE orders (
    order_id INT PRIMARY KEY AUTO_INCREMENT COMMENT '订单ID',
    user_id INT NOT NULL COMMENT '用户ID',
    total_amount DECIMAL(10,2) NOT NULL COMMENT '订单总金额',
    status ENUM('pending', 'paid', 'cancelled') NOT NULL COMMENT '订单状态',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    FOREIGN KEY (user_id) REFERENCES users(user_id),
    INDEX idx_user_id (user_id),
    INDEX idx_status (status)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';

3.4 接口设计

RESTful API定义

#### POST /api/v1/users/register
**描述**: 用户注册

**请求头**:

Content-Type: application/json

**请求体**:
```json
{
  "username": "testuser",
  "email": "[email protected]",
  "password": "password123"
}

响应 (成功 - 201 Created):

{
  "code": 0,
  "message": "注册成功",
  "data": {
    "user_id": 12345,
    "username": "testuser",
    "email": "[email protected]"
  }
}

响应 (失败 - 400 Bad Request):

{
  "code": 4001,
  "message": "用户名已存在",
  "data": null
}

### 3.5 算法设计
[关键算法的伪代码或流程图]

### 3.6 错误处理设计
#### 错误码定义
| 错误码 | 描述 | HTTP状态码 |
|--------|------|-----------|
| 0 | 成功 | 200 |
| 4001 | 用户名已存在 | 400 |
| 4002 | 邮箱已存在 | 400 |
| 4003 | 密码格式错误 | 400 |
| 5001 | 数据库错误 | 500 |

## 4. 非功能设计
### 4.1 性能优化设计
- 数据库索引: [...]
- 缓存策略: [...]
- CDN: [...]

### 4.2 安全设计
- 认证机制: JWT
- 授权机制: RBAC
- 数据加密: [...]

### 4.3 高可用设计
- 负载均衡: Nginx
- 数据库主从复制: [...]
- Redis集群: [...]

## 5. 部署架构
[部署图 - 服务器配置、网络拓扑]

## 6. 开发规范
### 6.1 编码规范
[参考具体语言规范]

### 6.2 命名约定
- 类名: PascalCase (UserService)
- 方法名: camelCase (getUserById)
- 常量: UPPER_SNAKE_CASE (MAX_RETRY_COUNT)

### 6.3 代码审查标准
[Code Review Checklist]

## 7. 附录
### 7.1 设计模式
[使用的设计模式及理由]

### 7.2 第三方库和框架
[依赖清单]

阶段门控标准:

设计评审检查清单:
- [ ] 架构设计满足所有非功能需求
- [ ] 技术选型合理且团队熟悉
- [ ] 模块划分清晰且低耦合
- [ ] 接口定义完整且一致
- [ ] 数据库设计符合范式
- [ ] 设计可扩展和可维护
- [ ] 关键算法经过验证
- [ ] 安全和性能设计充分
- [ ] SDD文档完整且通过评审

审批:
- [ ] 架构师签字
- [ ] 技术负责人签字
- [ ] DBA签字
- [ ] 项目经理签字

阶段3: 实施/编码 (Implementation)

目标: 将设计转换为代码

活动清单:

- [ ] 开发环境搭建
- [ ] 编码规范培训
- [ ] 模块分配给开发人员
- [ ] 编码实现
- [ ] 单元测试编写
- [ ] 代码审查
- [ ] 代码集成
- [ ] 技术文档编写

编码规范:

- [ ] 遵循设计文档
- [ ] 代码注释完整
- [ ] 每个函数/方法有单元测试
- [ ] 异常处理完善
- [ ] 日志记录规范
- [ ] 性能考虑 (避免N+1查询等)

代码审查清单:

功能性:
- [ ] 代码实现与设计文档一致
- [ ] 功能完整性
- [ ] 边界条件处理

代码质量:
- [ ] 命名规范
- [ ] 代码可读性
- [ ] 无重复代码
- [ ] 函数复杂度合理 (圈复杂度<10)

安全性:
- [ ] 输入验证
- [ ] SQL注入防护
- [ ] XSS防护
- [ ] 敏感信息不硬编码

性能:
- [ ] 数据库查询优化
- [ ] 避免不必要的计算
- [ ] 资源释放 (连接、文件)

测试:
- [ ] 单元测试覆盖率 >= 80%
- [ ] 测试用例充分

交付物:

• 源代码 (Git仓库)
• 单元测试代码
• 技术文档 (API文档、部署文档)

阶段门控标准:

代码审查通过标准:
- [ ] 所有模块代码完成
- [ ] 单元测试覆盖率 >= 80%
- [ ] 代码审查无P0/P1问题
- [ ] 代码符合编码规范
- [ ] 技术文档完整

审批:
- [ ] 技术负责人签字
- [ ] 质量保证经理签字

阶段4: 测试 (Testing)

目标: 验证系统满足需求

测试层次:

1. 单元测试 (Unit Testing)
   - 开发人员负责
   - 测试独立函数/方法

2. 集成测试 (Integration Testing)
   - 测试团队负责
   - 测试模块间接口

3. 系统测试 (System Testing)
   - 测试团队负责
   - 测试完整系统功能

4. 验收测试 (Acceptance Testing)
   - 用户/客户负责
   - 验证业务需求满足

测试活动清单:

测试计划:
- [ ] 编写测试计划文档
- [ ] 定义测试范围和目标
- [ ] 识别测试环境需求
- [ ] 估算测试资源和时间

测试用例设计:
- [ ] 根据需求编写测试用例
- [ ] 等价类划分
- [ ] 边界值分析
- [ ] 错误推测法

测试执行:
- [ ] 搭建测试环境
- [ ] 执行测试用例
- [ ] 记录测试结果
- [ ] 缺陷跟踪和管理

测试类型:
- [ ] 功能测试
- [ ] 性能测试
- [ ] 安全测试
- [ ] 兼容性测试
- [ ] 可用性测试

交付物:

测试计划文档

# 测试计划

## 1. 测试概述
### 1.1 测试目标
[验证系统满足SRS所有需求]

### 1.2 测试范围
- 包含: [所有功能模块]
- 不包含: [第三方组件内部逻辑]

## 2. 测试策略
### 2.1 测试层次
- 单元测试: 开发团队负责
- 集成测试: 测试团队负责
- 系统测试: 测试团队负责
- 验收测试: 客户负责

### 2.2 测试类型
- 功能测试: 100%需求覆盖
- 性能测试: 并发10,000用户
- 安全测试: OWASP Top 10
- 兼容性测试: 主流浏览器

## 3. 测试环境
- 操作系统: Ubuntu 22.04
- 数据库: MySQL 8.0
- 应用服务器: Tomcat 10
- 测试工具: Selenium, JMeter

## 4. 测试进度
| 阶段 | 开始日期 | 结束日期 | 负责人 |
|------|---------|---------|--------|
| 测试用例编写 | 2026-03-10 | 2026-03-20 | 张三 |
| 集成测试 | 2026-03-21 | 2026-04-05 | 李四 |
| 系统测试 | 2026-04-06 | 2026-04-20 | 王五 |
| 验收测试 | 2026-04-21 | 2026-04-30 | 客户 |

## 5. 缺陷管理
- P0: 阻塞测试,24小时内修复
- P1: 主要功能缺陷,3天内修复
- P2: 次要功能缺陷,1周内修复
- P3: 优化建议,可延后

## 6. 测试完成标准
- [ ] 所有测试用例执行完毕
- [ ] P0/P1缺陷全部修复
- [ ] P2缺陷修复率 >= 90%
- [ ] 测试覆盖率 >= 95%

测试用例文档

# 测试用例

## TC-001: 用户注册成功
**测试目标**: 验证用户能成功注册账号

**前置条件**:
- 系统正常运行
- 测试数据库已清理

**测试步骤**:
1. 打开注册页面
2. 输入用户名: "testuser123"
3. 输入邮箱: "[email protected]"
4. 输入密码: "password123"
5. 点击"注册"按钮

**预期结果**:
- 显示"注册成功"消息
- 跳转到验证邮件页面
- 数据库users表新增一条记录

**实际结果**: [测试时填写]

**状态**: 通过/失败
**缺陷ID**: [如果失败,关联缺陷]

---

## TC-002: 用户名已存在
**测试目标**: 验证系统拒绝重复用户名

**前置条件**:
- 已存在用户名"testuser123"

**测试步骤**:
1. 打开注册页面
2. 输入用户名: "testuser123" (已存在)
3. 输入邮箱: "[email protected]"
4. 输入密码: "password456"
5. 点击"注册"按钮

**预期结果**:
- 显示错误消息"用户名已存在"
- 不跳转页面
- 数据库无新增记录

**实际结果**: [测试时填写]

**状态**: 通过/失败

阶段门控标准:

测试完成标准:
- [ ] 所有测试用例执行完毕
- [ ] P0缺陷: 0个
- [ ] P1缺陷: 0个
- [ ] P2缺陷修复率 >= 90%
- [ ] 需求覆盖率 >= 95%
- [ ] 性能测试通过
- [ ] 安全测试通过
- [ ] 测试报告完成

审批:
- [ ] 测试经理签字
- [ ] 质量保证经理签字
- [ ] 项目经理签字

阶段5: 部署 (Deployment)

目标: 将系统部署到生产环境

活动清单:

- [ ] 部署计划编写
- [ ] 生产环境准备
- [ ] 数据迁移 (如果需要)
- [ ] 系统部署
- [ ] 冒烟测试
- [ ] 用户培训
- [ ] 文档移交

部署计划文档:

# 部署计划

## 1. 部署概述
- **部署日期**: 2026-05-01 00:00-06:00
- **部署窗口**: 6小时
- **回滚截止时间**: 05:00

## 2. 部署前准备
### 2.1 环境检查
- [ ] 服务器资源充足 (CPU, 内存, 磁盘)
- [ ] 网络连通性正常
- [ ] 数据库备份完成
- [ ] 配置文件准备

### 2.2 人员准备
- 部署负责人: 张三
- DBA: 李四
- 运维工程师: 王五
- 应急联系人: 赵六

### 2.3 部署检查清单
- [ ] 代码打包 (WAR/JAR)
- [ ] 数据库脚本 (DDL, DML)
- [ ] 配置文件 (application.properties)
- [ ] 部署脚本 (deploy.sh)
- [ ] 回滚脚本 (rollback.sh)

## 3. 部署步骤
### 3.1 停止服务 (00:00-00:10)
```bash
# 停止应用服务器
systemctl stop tomcat
# 停止Nginx
systemctl stop nginx

3.2 数据库迁移 (00:10-01:00)

# 备份数据库
mysqldump -u root -p mydb > backup_$(date +%Y%m%d).sql

# 执行DDL脚本
mysql -u root -p mydb < schema_v2.0.sql

# 执行数据迁移
mysql -u root -p mydb < data_migration.sql

3.3 应用部署 (01:00-02:00)

# 备份旧版本
mv /opt/app/myapp.war /opt/app/myapp.war.bak

# 部署新版本
cp myapp-v2.0.war /opt/app/myapp.war

# 更新配置
cp config/application.properties /opt/app/config/

3.4 启动服务 (02:00-02:30)

# 启动应用服务器
systemctl start tomcat

# 等待服务就绪
sleep 60

# 启动Nginx
systemctl start nginx

3.5 冒烟测试 (02:30-03:30)

• 登录页面可访问
• 用户登录成功
• 关键功能正常
• 数据库连接正常
• 日志无严重错误

3.6 监控观察 (03:30-06:00)

• CPU/内存使用率正常
• 响应时间正常
• 错误率 < 0.1%
• 无用户投诉

4. 回滚计划

4.1 回滚触发条件

• 关键功能不可用
• 错误率 > 5%
• 性能严重下降 (响应时间 > 5秒)

4.2 回滚步骤

# 停止服务
systemctl stop tomcat

# 恢复应用
mv /opt/app/myapp.war.bak /opt/app/myapp.war

# 恢复数据库
mysql -u root -p mydb < backup_20260501.sql

# 启动服务
systemctl start tomcat

5. 通知计划

• 部署开始: 邮件 + Slack
• 部署完成: 邮件 + Slack
• 部署失败: 电话 + 邮件 + Slack

**阶段门控标准**:
```markdown
部署验收标准:
- [ ] 所有部署步骤成功执行
- [ ] 冒烟测试全部通过
- [ ] 系统监控指标正常
- [ ] 用户培训完成
- [ ] 文档移交完成
- [ ] 客户验收签字

审批:
- [ ] 运维经理签字
- [ ] 项目经理签字
- [ ] 客户代表签字

阶段6: 维护 (Maintenance)

目标: 修复缺陷、增强功能、保持系统运行

维护类型:

1. 纠正性维护 (Corrective)
   - 修复生产环境缺陷

2. 适应性维护 (Adaptive)
   - 适应环境变化 (OS升级、依赖更新)

3. 完善性维护 (Perfective)
   - 性能优化、功能增强

4. 预防性维护 (Preventive)
   - 代码重构、技术债务偿还

活动清单:

- [ ] 缺陷跟踪和修复
- [ ] 用户支持
- [ ] 性能监控
- [ ] 日常备份
- [ ] 定期巡检
- [ ] 文档更新

交付物:

• 维护日志
• 变更记录
• 更新后的文档

变更管理流程

瀑布模型中变更管理尤为重要:

变更请求 (CR - Change Request)流程:

1. 提交变更请求
   - [ ] 填写CR表单
   - [ ] 描述变更原因和影响

2. 影响分析
   - [ ] 需求影响分析
   - [ ] 设计影响分析
   - [ ] 成本和时间影响
   - [ ] 风险评估

3. 变更评审委员会 (CCB - Change Control Board)
   - [ ] 评审变更必要性
   - [ ] 评估影响和成本
   - [ ] 批准或拒绝

4. 变更实施
   - [ ] 更新需求文档
   - [ ] 更新设计文档
   - [ ] 更新测试用例
   - [ ] 执行变更

5. 变更验证
   - [ ] 测试变更
   - [ ] 文档更新验证

6. 变更关闭
   - [ ] 记录变更结果
   - [ ] 存档变更文档

中文输出格式

所有输出必须使用中文,遵循以下结构:

# 瀑布式项目规划: [项目名称]

## 项目概述
- **项目名称**: [名称]
- **项目周期**: [开始日期] - [结束日期]
- **总预算**: ¥[金额]
- **项目经理**: [姓名]

## 阶段规划

### 阶段1: 需求分析 (X周)
**时间**: [开始] - [结束]

**关键活动**:
- [ ] 干系人访谈
- [ ] 需求收集和分析
- [ ] 编写SRS文档
- [ ] 需求评审

**交付物**:
- 需求规格说明书 (SRS) v1.0

**里程碑**:
- 需求评审通过并签字

### 阶段2: 系统设计 (Y周)
[类似结构]

### [其他阶段...]

## 里程碑甘特图
| 里程碑 | 计划日期 | 负责人 | 状态 |
|--------|---------|--------|------|
| 需求评审通过 | 2026-03-15 | 张三 | 待开始 |
| 设计评审通过 | 2026-04-10 | 李四 | 待开始 |
| 编码完成 | 2026-06-01 | 王五 | 待开始 |
| 测试完成 | 2026-06-30 | 赵六 | 待开始 |
| 系统上线 | 2026-07-15 | 项目组 | 待开始 |

## 风险管理
| 风险 | 影响 | 概率 | 缓解措施 | 负责人 |
|------|------|------|---------|--------|
| 需求变更频繁 | 高 | 中 | 严格变更控制流程 | PM |
| 技术选型失误 | 高 | 低 | 技术PoC验证 | 架构师 |
| 资源不足 | 中 | 中 | 提前招聘培训 | HR |

## 质量保证
- [ ] 每个阶段都有质量门控
- [ ] 所有文档通过评审
- [ ] 代码审查覆盖率100%
- [ ] 测试覆盖率 >= 80%

## 沟通计划
- 周例会: 每周一 10:00
- 阶段评审: 每阶段结束后
- 月度汇报: 每月最后一个周五

## 项目团队
| 角色 | 姓名 | 职责 |
|------|------|------|
| 项目经理 | 张三 | 整体协调 |
| 系统架构师 | 李四 | 技术架构 |
| 开发组长 | 王五 | 开发管理 |
| 测试经理 | 赵六 | 质量保证 |

语言要求

• ✅ 所有文档: 必须使用中文
• ✅ 技术术语: 首次使用提供英文,后续使用中文
• ✅ 阶段名称: 使用中文,首次出现括号注英文
• ✅ 缩写: 首次使用全称+缩写,后续使用缩写

质量标准

• 每个阶段有明确的交付物
• 所有文档模板化且内容完整
• 阶段门控标准明确且严格执行
• 变更管理流程严格
• 可追溯性完整 (需求→设计→代码→测试)
• 所有干系人签字确认

瀑布模型优缺点

优点 ✅

- 结构清晰,易于理解和管理
- 阶段明确,便于计划和跟踪
- 文档完整,可追溯性强
- 适合需求稳定的大型项目
- 合同固定,风险可控
- 便于人员分工和外包

缺点 ❌

- 灵活性差,难以应对需求变化
- 反馈周期长,问题发现晚
- 前期投入大,风险集中在后期
- 用户参与少,可能偏离实际需求
- 文档负担重
- 不适合创新性项目

改进建议

迭代式瀑布

将瀑布阶段缩短并迭代:
- 第一次迭代: 核心功能 (需求→设计→开发→测试)
- 第二次迭代: 增强功能
- 第三次迭代: 辅助功能

优点: 保留瀑布结构,增加反馈机会

V模型

强调测试与开发阶段的对应:
需求分析 ←→ 验收测试
系统设计 ←→ 系统测试
详细设计 ←→ 集成测试
编码    ←→ 单元测试

优点: 测试驱动,质量保证更好

参考文档

详细实践指南请参考:

• references/WATERFALL_FRAMEWORK.md - 瀑布框架详解

版本历史

• v1.0.0 (2026-03-03): 初始版本
  • 6个瀑布阶段详解
  • 阶段门控标准
  • 文档模板 (SRS, SDD, 测试计划)
  • 变更管理流程
  • 中文输出格式