I
import
Unregistered / Unconfirmed
GUEST, unregistred user!
开发步骤
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第四阶段,最好找开始做调研的人中的一两个负责测试的主要工作(当然,测试不可能
只用一两个人,但这一两个人是总体把握什么是对的即符合用户要求的)既然测试,总会
有些问题的,所以,此时,也应该留几个开发人员跟着,(这几个开发人员的水平可以平一
一些,锻炼队伍嘛),有问题及时修改,没有问题,一起做测试
其实在开发过程中,总会有一些不太协调的地方,所以,一个项目的成败,还必须有两点
特别提出的,一是这个项目的负责人必须能够调动项目组中的每一项可利用资源(包括
员和其它各方面的东西)二是项目客户必须有一个说话可以算数的人当对项目挂名负责
真的,这两点真的很重要.
说了这么多废话,不知有没有什么用处,真的,有些算是教训吧,有些可以算是不太成熟
的经验,有没有用我实在也无从知道,因为才做过一两个比较大的项目而已
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第四阶段,最好找开始做调研的人中的一两个负责测试的主要工作(当然,测试不可能
只用一两个人,但这一两个人是总体把握什么是对的即符合用户要求的)既然测试,总会
有些问题的,所以,此时,也应该留几个开发人员跟着,(这几个开发人员的水平可以平一
一些,锻炼队伍嘛),有问题及时修改,没有问题,一起做测试
其实在开发过程中,总会有一些不太协调的地方,所以,一个项目的成败,还必须有两点
特别提出的,一是这个项目的负责人必须能够调动项目组中的每一项可利用资源(包括
员和其它各方面的东西)二是项目客户必须有一个说话可以算数的人当对项目挂名负责
真的,这两点真的很重要.
说了这么多废话,不知有没有什么用处,真的,有些算是教训吧,有些可以算是不太成熟
的经验,有没有用我实在也无从知道,因为才做过一两个比较大的项目而已