个人见解,如有不足请批评指正。
需求分析 --》 概要设计 --》详细设计 --》编码 --》测试 --》交付 --》验收 --》维护
- 了解基本业务需求
- 如何定义?(将自己定义成一个黑盒,名字就根据业务自己编一个)
- 这个黑盒存在的意义?(脑子让屁憋了?当然是有人需要使用它才有存在的价值)
- 谁会用呢?(确定具体用户及用户组,这个要非常清楚,不然没办法继续。换言之,都不知道有没有或者有谁会用,用什么功能,我还做这个干嘛)
- 这群呆B需要什么功能呢?(根据用户抽取所有接口)
- 抽取之后呢?(内部/外部接口归纳、抽象、整理出一个接口文档)
- ========================== 系统边界已明确 ↑ *** 日后如果有需求变动应该是这一环节出了问题
- 模块分析,根据接口设计分析一下,需要多少个模块(子系统),可以满足用户的需求
- 这些模块(子系统)如何组装成一个整体,之间的层级关系是怎样?(整理出系统架构图,可以画图说明)
- 继续分析这些模块(子系统)之间的通信方式(http、https、soap、mq等),以及对外的通信方式
- 针对这些通信方式需要有规范,创建通信模型(可以用图说明每种模型)
- 数据设计,大致设计即可,无需过细(例如,一份数据对速度要求较高我可以存到内存或redis等非关系型数据库,如果对安全性要求较高我可以存postgresql,如果需要轻量化存储我可以存在sqlite)
- 根据已定内容进行框架选取(有的人是先选框架,后设计,这种方法是不可取的)
- 还可以完善一部分,测试、性能、部署、容灾 等内容的说明,但是模块分析要做好
- ========================== 概要设计已完成↑ *** 概要设计不能过度考虑细节实现和业务流程,这些内容应该在详细设计中进行详细设计和描述,如果多方面掺杂在一起考虑,就不能把一件事做好
- 细化概要设计中的业务流程和细节实现,概要设计之后的内容基本就是需要看着能落下代码的内容了
- 针对每个模块进行实现的具体设计(可以使用类图或包图进行类描述有哪些功能或已经定义好的方法和依赖关系;使用时序图描述每个类之间的调用关系、调用顺序;使用流程图进行具体流程、分支、异常的描述)
- 继续细化流程图,根据流程中使用到的数据类型,选定一些合适的算法进行描述,反之针对一些特殊的场景需要指定一些特定数据结构以满足系统要求
- 具体的数据库选定,表结构,字段,关系的描述
- 根据模块(子系统)的难度进行工时估算
- 说明代码版本管理工具(一般是SVN和Git)
- ========================== 详细设计已完成↑ *** 这一步需要详细,可以抠到具体实现逻辑,数据结构,算法等
- 码人,开会分赃,讲清楚工作内容,干活,代码评审,功能测试,压力测试,交付