做一个java项目要经过那些正规的步骤（请项目经理指点）
因为公司规模不大，基本上我什么事都要做，但是我不了解一个项目开发要经过哪些具体步骤，所以对上级给的任务没有准备，也不知道会有什么任务来，像个无头的苍蝇。。
我不想打没有把握、没有目标的仗
请项目经理们指教。
谢谢

------解决方案--------------------
首先，需求分析---总体规划---详细设计---项目实施。
大致就分这几步，前三步都需要很详细的文档的，项目实施阶段的文档就是代码注释啦，程序员要做的。
要给客户的就是项目的介绍，操作说明等。
------解决方案--------------------
以上这些从调研开始一直到项目封版，都得有文档跟上，所以你最好在每做一项之前先把文档格式定下来，事半功倍!
------解决方案--------------------
需求分析---总体规划---详细设计---项目实施
------解决方案--------------------
需求调研--技术论证--框架选取--快速原型--再次需求调研--详细设计--编码阶段。
------解决方案--------------------
理论上应该是：
一、立项
1、项目的功能的范围、实现技术方法和细节
2、需要多少人，需要的开发周期（根据客户的需求）
3、分析成本和风险
4、有相应的利润，可以立项
二、需求调研；
三、需求评审、确定；
四、概要设计（对技术框架、模块、功能的确定）；
五、详要设计（对表、业务联系的确定）；
六、架构师整体架构软件、布置开发任务；
七、整合软件；
八、测试；
九、试运行、维护；
十、正式运行
在实际中跟过二个项目，都是具体和用户交涉，和理论还是有出入的。
------解决方案--------------------
需求分析文档 详细设计文档 数据库文档 测试文档 用户操作手册

还有好多好多
------解决方案--------------------
实实在在地和你说吧。
你说你们是小公司，应该做的Java项目也不大，
无非也就是对数据操纵型的系统，

其实都用不上Rose,viso。。这些东西

你就用PowerDesigner12创建好数据库，关键就在于你把DB中所有的表，及他们之间的关系设计好了
做出一个模型出来。

然后搭一个SSH/SSH2/SSI之类的框架足够用了，
后台Oracle，前台Jsp,或用一些Ajax框架（Jquery/Ext....）也就可以了

业务逻辑就要看你自己的需要了，用Spring把业务类管理好了，就差不多了，

就想出这么多，小项目还可以，大项目我也没做过。。。
------解决方案--------------------

探讨

实实在在地和你说吧。
你说你们是小公司，应该做的Java项目也不大，
无非也就是对数据操纵型的系统，

其实都用不上Rose,viso。。这些东西

你就用PowerDesigner12创建好数据库，关键就在于你把DB中所有的表，及他们之间的关系设计好了
做出一个模型出来。

然后搭一个SSH/SSH2/SSI之类的框架足够用了，
后台Oracle，前台Jsp,或用一些Ajax框架（Jquery/Ext....）也就可以了

业务逻辑就要看你自己的需要了，用Spring…

------解决方案--------------------
参考CMMI，不过建议如果你是小公司就直接挑几个重点的吧，例如需求、详细设计、数据库设计、测试报告、用户手册等等
------解决方案--------------------

探讨

需求调研--技术论证--框架选取--快速原型--再次需求调研--详细设计--编码阶段。

------解决方案--------------------
需求分析(文档、uml)-》概要设计(文档、uml)-》详细设计(文档、uml、伪代码....)-》编码-》测试-》交付
通常大致是这个样子，但对于越小的公司，越是要求速成
如果楼主心里有底，能对整个软件架构有所把握的话，或许可以不写任何文档，不作任何uml，因为，通常新手写出来的文档也大多没多大用，uml也常常到了编码阶段被推翻，根本就不按文档和uml来。
但有几步是绝对跳不过去的，一是尽可能明确的需求(这是最最根本的，要尽量确定更多的需求部分)，二是做好一些需求、设计上的琐碎的记录(全身心的投入开发时，我们将以惊人的速度忘却曾经一时想到而又没能以书面形式记下的事务)之后多多思考如何设计，进而直接转入编码，三是一定要尽量设计的易于扩展，层次分明（如果不这么做的话，恐怕项目进行没过半，就会尝到苦头，不为别人，也要为自己打算打算，一定要尽量在设计上多下功夫）四是多测试，先是为每一层测试(比如数据库交互层、业务逻辑层、控制层等)最后是整体流程走几遍。（缺乏测试的结果是后期砸下大量的时间来测试、排查、改错，并可能给客户留下极差的印象，并且查错改错的难度要远远大于上线前或交付前）
需求是会变的，设计优良百利无一害
如果时间不宽裕，老板又不是很注重过程，那么，不用写文档了吧，除非客户要什么操作文档。
如果可以的话，写全注释，如果还有点时间的话，重构一下吧。
记住经常做备份
--------------------------------------------------
此法应对特殊情况，但绝不是什么推荐的玩法儿，前人总结的传统流程虽可能有缺陷或不足，但不无道理！
老板有时要的仅仅是一定时间内的结果。

------解决方案--------------------
收藏学习!
------解决方案--------------------
学习了
------解决方案--------------------
学习

------解决方案--------------------
人月神话 看看
------解决方案--------------------
先要知道你要做什么，
然后就要知道你怎么做，

....