开发步骤

1) 先做应用分析,直到你和用户都明白他想要你作什么,这是最重要的.

2)用文档的方式记录下来

3)做总体系统逻辑分析.

4)做总体系统应用分析.

5)划分模块,并分配人手,

6)每队再做分析,并建立原型,修改原型.如果和他人的接口部分要改动,必须由

三方同意商定.

7)接口联合调试

8)系统调试

9)文档,用户说明.

--以上每一步的文档都要清楚,并由各模块负责人负责.

原则上编码的工作量视,如果应用模型细,就少些,反之就多些,还要看实现技术是否

容易.

团队精神很重要,要让所有人都觉得自己很有价值.

我觉得如果想将项目做得好,要做到一下几点,除非您特别牛:)

1 : 首先要熟悉用户的业务流程,明确需求,做好充分的可行性分析. 这一点我觉得

非常重要,直接决定以后工作的进度和质量.我做得第一个项目就是没有重视这一点,

需求没完全明确,到用户要求改的时候,sigh...我们几个人没日没夜的改,还是一大堆

bug在里头,痛苦,往事不堪回首:).

    了解用户的业务流程最为辛苦,或则编码对于我们程序员来说不是什么大问题,

但了解业务流程绝对是难解决的,要有耐心,不完全搞清楚不要匆匆忙忙的进行系统

设计,了解也是个渐进的过程,多点和用户交流,了解他们在现行系统上面的工作情况

和工作概要时非常重要的.这一部分的工作我觉得起码要1-2周.如果项目很大,还要

更久.

     可行性的分析包括了经济上的,技术上的,社会上的等等方面的因素,要了解到

用户提出的要求是不是真的能够完成,经济上有问题吗?技术上是不是不可行?都要知道

得清清楚楚.

 2 : 上面的内容了解完了,可以进行系统的设计了,按照上面所得的资料,确定一个

系统的概要.最好能用建模工具如Rose将模块划分好,再按工作量具体分工.如果系统

涉及到数据库的(大多数都是这样的拉),数据库各个表的定义及优化要讨论清楚,争取

一步到位,不要等做着做着发现表的定义有问题,要改,sigh...可能工作量就大了

 3 : 要具体编码了,严格控制进度是应该的,结合测试来完成,写代码的时候尽量能

加上注释.我个人认为测试时非常重要的,偏偏中国不重视这个,很多公司都没有专门的

测试人员,没办法,只要交叉测试了.

 4 : 文档要齐全!特别是对大型的系统来说,这个尤为重要.文档包括一开始的需求

报告,可行性报告,系统设计的总结,模块划分的纪录,在各个阶段测试结果的纪录,用户

手册,软件说明书等等,甚至程序员在编码的时候写的注释,可以在整个软件开发的过

程中起到知道的作用.

 我的看法就那么多,不知道对不对,如有不对,请大家指出//thx:)

************

说点我认为实用的罢

做一个项目,始终是人在做,书上的东西是死的,而人是活的,有了好的方法,

不一定会有好的效果.

我认为做一个项目,有以下几点注意的,当然,做一个项目不会只有这些:

1.前其人员不用太多,找几个(具体几个,看业务大小和这几个人的人员素质而定,

其实有时,也与客户的要求有关)对业务熟悉的人员(当然,也必须是熟悉开发工具的)

进行前其的调研,设计文档,此时,尚未进入编码阶段呢

2第二阶段,此时不应该是大量人员投入的阶段,而应该是找几个(也许是一两个)比较

有实力的人,做出系统的框架(如果有Delphi的话,就应该将系统总控模块做好,同时

做好各模块的接口部分)

与此同时,再找一两个人做一些基础数据的维护界面(例如人员信息维护等)

3第三阶段,此时,投入大量人员,(此时,应该是整个项目中时间最短的部分)分模块

开发,记住,开发必须是在前面定义好的接口之下,同时必须在主框架中调试

4第四阶段,最好找开始做调研的人中的一两个负责测试的主要工作(当然,测试不可能

只用一两个人,但这一两个人是总体把握什么是对的即符合用户要求的)既然测试,总会

有些问题的,所以,此时,也应该留几个开发人员跟着,(这几个开发人员的水平可以平一

一些,锻炼队伍嘛),有问题及时修改,没有问题,一起做测试

其实在开发过程中,总会有一些不太协调的地方,所以,一个项目的成败,还必须有两点

特别提出的,一是这个项目的负责人必须能够调动项目组中的每一项可利用资源(包括

员和其它各方面的东西)二是项目客户必须有一个说话可以算数的人当对项目挂名负责

真的,这两点真的很重要.

说了这么多废话,不知有没有什么用处,真的,有些算是教训吧,有些可以算是不太成熟

的经验,有没有用我实在也无从知道,因为才做过一两个比较大的项目而已