根据项目的实际情况将项目分为几个里程碑，并以一定的产出作为里程碑作为结束的标志。
1. 需求分析阶段: 至少要有一份FRD(除功能描述外，格式和内容也是很重要的)
2. 设计阶段:
a) 物理架构： 最后系统要被布置到的硬件架构。
b) 软件架构
1. 层次结构定义、Configuration、Exception Handling、Logging and Instrument、Security、Cache、Cryptography、 OR Mapping等。
这方面Martin Fowler的那本PEAA非常值的学习。如果是.NET项目的话MS Patterns & Practice里面关于企业应用程序架构的文章和Enterprise Library都是很好的参考。如果是J2EE项目的话Struts + Spring + Hibernate一套做下来也是不错的，只是感觉配置比较多，配置工具集成度不高，用起来不是很方便。对于一个经验丰富的设计人员来说合理的设计模式应用将对应用程序的开发模式产生很大的影响。
2. 设计文档中应包含：层次与职责分配说明、构件说明与关系图、架构相关类的类图,活动图,时序图与说明等。
c) 业务模型
1. 现在很多人还是在做完需求分析后做Prototype接着开始做数据库设计，然后OR Mapping -> 编写业务类 -> Business Façade -> Presentation这里面有些当然是可以并发的。可是对于ERP系统来说业务非常复杂，很多时候按那样的模式做可能在实现业务时有冲突，这时要反过头来修改DB,ORM, DA的一些东西，还是比较麻烦的。如果是先有业务外观模型 -> 进一步的业务类设计 -> Domain Object 然后再生成DB。可惜目前自己也没完整的走过这种开发模式，有待进一步实践。
2. 设计文档中应包含：业务外观类（option可抽象分析时还是比较有用的）， 具体业务类的组织图与说明，典型业务的活动图，时序图以及说明。
d) 数据模型
1.一般是E-R Model，用Power Design做这些还是非常爽的， CDM -> PDM -> 生成DB， 还可反向工程。
2. 设计文档中应包含：局部E-R, 集成E-R, 表与字段定义说明等。
e) UI描述
其实这部分是非常难搞的， 一是多，二是很多设计阶段做出来的UI与最后出来的UI可能相差很大，一是技术实现上的， 二是实际上有很多东西是在开发实现过程中才发现和认识到的。个人觉得UI的设计可以分配给实现者， 设计人员负责协调，保证最后出来的风格一致。我想这也是为什么有不少说要把实现阶段也要做为设计的一部分。
3. 实现阶段
4. 实施阶段
5. 维护阶段
