业务调研

主要是完全跟技术无关，站在业务的角度去定义系统要干嘛

组织结构图

部门+岗位

业务流程图

泳道图，一级业务流程+二级业务流程
系统多个模块的整体业务流程
每个模块内部的业务流程

业务需求

需求分析

站在技术的角度，去分析系统要干嘛

用例图

用例表：用例名称+多个参与者+每个参与者对这个用例做的事情

用例图

参与者+用例，一个用例就是一个功能需求

用例划分

每个模块都划分出对应的用例来
从业务流程图的运行节点中，抽取用例

领域类图

主要根据业务表单来抽象

• 非功能需求
• 物理部署需求
• 实施需求
• 易用性需求
• 性能需求
• 可靠性需求

概要设计

架构师一个人去做的

逻辑架构图

根据需求，画出来逻辑上，系统要长成什么样子

运行架构图

时序图、活动图（可选）、状态图（可选），系统的逻辑架构有了，系统跑起来是什么流程

物理架构图

组件图、配置图，系统长什么样子，系统跑起来流程是什么，系统真正怎么去部署
3.4 概要设计评审

详细设计

详细设计：下推给项目组里的每个人去做

数据架构图

• 数据库ER模型图
• 数据库逻辑设计图
• 数据库物理设计图

接口设计

开发架构图

实现类图、包图

系统运行流程图（活动图）

测试用例设计

单元测试用例设计

冒烟测试用例设计

日志设计

详细设计评审

项目管理计划

每个人给出自己的排期计划

活动图

网络图

进度计划（甘特图）

资源配置

工程初始化

每个人本地的开发环境搭建

资源申请

机器、数据库、缓存、MQ，包含了各个环境的资源申请

数据库初始化

代码初始化和上传

版本控制

确定版本管理的工作流

编码开发

系统测试

单元测试（白盒测试）

冒烟测试

静态代码扫描

代码审查

集成测试

联调测试，也可能是RD自己干，不是QA干

系统测试（QA去干，黑盒测试）

验收测试

业务需求方来试用一下，验收一下，一般来说，互联网行业里做验收测试的，一般是产品经理，PM

关键点

1. 概要设计评审：其它架构师一起评审概要设计
2. 详细设计评审：每个同学各自设计需要研发的设计文档
3. 代码审查：高工仔细审查代码
4. 集成测试–>系统上线–>验收测试：仔细查看每个步骤的报告
5. 系统上线：仔细审查同学写的上线文档步骤，高工带着一起上线

项目管理计划

就是在完成所有的技术设计之后，我们已经知道要怎么做这个系统了，但是现在的问题再于，按照什么样的节奏、步骤、和进度去完成所有的开发、测试及上线？

普通排期弊端：

1. 排期比较粗糙、粒度比较大，排期是静态，很多时候这个排期没有组成动态的情况（存在项目间依赖的情况，会导致排期混乱的情况）
2. 排期不透明，项目的执行进度完全不透明，每个人工作内容不清晰
3. 外界因素，Dba搭建Mysql的版本问题导致上线延期
4. PM修改修改需求、需求变更因素

项目管理规范

活动清单

根据经验判断一下每个人工作评估一下有没有多排期，保证排期的合理性，根据28法则，用80%的经历去排期，留下20%的buffer

网络图

甘特图

资源配置表

风险管理

风险识别

风险分析

风险预案

风险监控

项目需求变更

不靠谱的需求变更

态度强硬，直接反驳回去，实在要做升级到总监级别，项目一定会delay

需求变更模板

1. xxx系统功能
2. 原有功能
3. 现在改动
4. 改动原因

RD评估

1. 评估需求改动后要做哪些事？
2. 需要耗费多少人日?
3. 需要改动的步骤
4. 调研和评估（索引的情况，性能的情况，其它服务提供的接口情况），1人日
5. 设计实现方案（详细设计文档），1人日
6. 重新开发，1人日
7. 单元测试，1人日
8. 冒烟测试，1人日
9. 静态代码扫描，1人日
10. 集成测试，1人日
11. 系统测试，1人日
12. 改动持续的时间
13. 9.1 – 9.5日
14. 耗费的成别
15. 耗费总人日10天
16. 对项目进度的影响
17. 导致项目整体delay达到10天

靠谱的需求变更

对需求变更进行审核

架构师负责对需求变更的申请和评估报告提交给总监，技术总监负责对这个delay的时间进行考评，考量过后，确认通过审批