可行性分析
这个一般都是做战略的专家来做的，他们更加有市场的前瞻性，俗话说就是看的更远一些，搞市场分析、调研，看看我们的想法到底是否可行，可行性有多大，可能会遇到的问题，我们的优势在哪里，可以利用的资源有哪些，需要引进那些资源，有多少对手，他们都进行到了什么程度等等。
这个阶段的文档成果是：可行性分析报告等
需求分析
这个已经开始具体操作，经过可行性分析，我们有机会，可以进入这个领域。这时候，需要领域专家参与进来，架构师也要参与进来，还有就是需求分析的专业人士，和最少一名文档员，用来记录开发讨论的结果并形成文档。
工作就是分解项目的需求，到底要做些什么，要实现什么功能，就是功能的范围和功能的细节，主要还是业务方面的梳理。
这个阶段的文档成果是：需求分析说明书等
概要设计
经过前面的需求分析，形成了需求分析说明书。这个阶段应该是业务建模，形成业务用例，进一步形成业务用例。这个阶段是分解需求，可以使用PD(Power Designer)、 Rational等工具来辅助一下。
这个阶段的文档成果是：概要设计说明书、业务用例文档等
详细设计
有了概要设计，有了模型，可以定义出数据库模型，甚至是可以定义数据库的字段，然后可以让高级程序员来辅助架构师进行架构设计，普通程序员先写实现的技术用例。或者让他们先看看业务用例，熟悉一下业务流程和项目的目标。
这个阶段的文档成果是：概要设计说明书、技术用例文档等
具体开发
这个阶段就是具体的代码编写了，考验程序员的基本功的时候到了。
关于开发的分工的话，我趋向于分层来分工，这样有以下几个好处：
- 不用每个人从数据访问写到界面表现，可以集中精力，精益求精，便于后期优化
- 中间层可拔插，可替换，可以优化，增加可扩展性
- 可以享受ORM带来的一些好处
- 增加可测试性，做得好，甚至可以测试外包
- 这个阶段的文档成果是：接口文档，关键算法文档等
可能会有人说，怎么没有测试呢？其实测试时贯穿整个流程的，在需求分析的时候，可以让他们熟悉业务，出来需求之后，他们就可以编写一些手动测试的测试用例，后面产品出来就可以测试了。开发人员的开发的时候，他们就要进行自动化测试的准备。
还有就是一定要形成文档，每个阶段都会有开会，开会大家都有讨论，都需要有结论，有纸质的文档进行保存，可以买录音笔，先录下来，然后整理成文档，因为每个阶段都是后面阶段的基础，如果基础出了问题，后面都会是有问题的，所以后面备查。
来源：https://www.cnblogs.com/sunchuankui/archive/2010/04/18/1714583.html