不好意思,先泼点冷水
DELPHI半个月!如果以前没有开发过,那我祝你好运。
以下是我的意见:
分析,一定细致,这里的工作量要比写代码的工作量大。
那就正常,反之,你们要注意了,可能会被代码压死。
主要是要知道,要做什么,在业务的角度,知道业务
处理的规则
分析做完了,就是设计了,要考虑业务规则,怎么
处理,以及分布,多了,结果是,设计完成时
你门的程序已经,确定了,应该细到 每一个 窗体
上有什么控件
至于技术吗,我想不出,有什么说的,如果不用COM
但应该考虑,安全性,和健壮性,效率我认为不是
很重要。
测试很重要没什么了(我就知道这些)
DELPHI半个月!如果以前没有开发过,那我祝你好运。
以下是我的意见:
分析,一定细致,这里的工作量要比写代码的工作量大。
那就正常,反之,你们要注意了,可能会被代码压死。
主要是要知道,要做什么,在业务的角度,知道业务
处理的规则
分析做完了,就是设计了,要考虑业务规则,怎么
处理,以及分布,多了,结果是,设计完成时
你门的程序已经,确定了,应该细到 每一个 窗体
上有什么控件
至于技术吗,我想不出,有什么说的,如果不用COM
但应该考虑,安全性,和健壮性,效率我认为不是
很重要。
测试很重要没什么了(我就知道这些)
用户需求说明书是属于合同范畴的吗,还是不属于合同的但具有法律效应?
首先用户在提出需求的时候并不能知道软件可以实现什么功能,所以很多业务上
的东西他都是提了最基本的要求,深入一点的不提或者没有再去细想。其次,就是
用户会在开发的过程中因为看到软件能够实现的功能而不断提出新的要求。很多公司
都会对这些要求默认接受,导致最终付款时出现双方扯皮的事情。不过,最终要
的是最初的需求做仔细一点,多考虑一些可能存在的情况,那以后修改起来也方便。
我以前做过一个仓管系统,跟物流有较为密切的关系,如果可以,大家交流一下吧
我的email:[email protected]
很多的时候你省下的时间还不够DEBUG用。
设计的时候尽量减少各个部分之间的依赖,这样可以防止需求变更的时候要改动太多的东西。
至于协议,好象没有具体的规范。就算你能把功能写详细,各个人的理解不同,很难有得到一致,还不如不写的好。