苦 苦虫 Unregistered / Unconfirmed GUEST, unregistred user! 2003-06-14 #1 有个朋友托我写个管理软件,以前写软件只是自各写着玩,没有做过真正的项目 ,现在真有点不知所措。请问各位高人,在动手编写代码之前还有哪些事是必须 要做的啊
P pandababy Unregistered / Unconfirmed GUEST, unregistred user! 2003-06-14 #2 一个完整的项目是需要很多的步骤的,几句话不可能说的清楚的 给你个建议:先看看有关分析设计的书吧 如果你只有一个人做的话,需求调研,设计比较重要
F FeelingLoad Unregistered / Unconfirmed GUEST, unregistred user! 2003-06-14 #7 这些事情由你的朋友决定吧 既然是你的朋友,也不会把你卖了,对吧? 至于过程,我同意yczjs的,当然这也是一般的软件流程 需求分析 系统分析 单元模块 模块编码 模块测试 系统集成 总体测试 交付使用 服务
这些事情由你的朋友决定吧 既然是你的朋友,也不会把你卖了,对吧? 至于过程,我同意yczjs的,当然这也是一般的软件流程 需求分析 系统分析 单元模块 模块编码 模块测试 系统集成 总体测试 交付使用 服务
T toplucky01 Unregistered / Unconfirmed GUEST, unregistred user! 2003-06-14 #8 30天搭建框架, 3天写代码。 不要轻易动手写
特 特尔斐 Unregistered / Unconfirmed GUEST, unregistred user! 2003-06-14 #9 签个能保证你的利益的协议非常重要!不管是不是朋友,最好先小人后君子。 这个年头,连胡萝卜都靠不住[], 不要轻易相信别人。
Z zzcc_1205 Unregistered / Unconfirmed GUEST, unregistred user! 2003-06-14 #10 基本上就是yczjs和FeelingLoad所说的了,至于合同,最好还是签,以前我的一个朋友给我介绍了一家公司做个小的数据库,埋头赶了三天,搞好后突然说不要了,弄的很...。 合同上最好标明要实现的功能,要达到什么要求等...,还要有报价及付款方式等等。 最好作好需求分析,即调研,详细调查你要做的各个模块的具体实现,以前就碰到过仅一个输入模块就修改了N次的情况:今天说这样输入不符和习惯、颜色不好看...,明天又说配色不合理、看起来刺眼...,总之改来改去,改的头都大了。 切记:需求分析非常重要!!!
基本上就是yczjs和FeelingLoad所说的了,至于合同,最好还是签,以前我的一个朋友给我介绍了一家公司做个小的数据库,埋头赶了三天,搞好后突然说不要了,弄的很...。 合同上最好标明要实现的功能,要达到什么要求等...,还要有报价及付款方式等等。 最好作好需求分析,即调研,详细调查你要做的各个模块的具体实现,以前就碰到过仅一个输入模块就修改了N次的情况:今天说这样输入不符和习惯、颜色不好看...,明天又说配色不合理、看起来刺眼...,总之改来改去,改的头都大了。 切记:需求分析非常重要!!!
C czl007 Unregistered / Unconfirmed GUEST, unregistred user! 2003-06-14 #12 如果是商业往来,合同协议当然不能少,并且越细越好,牵扯到经济利益,如果是编程游戏当然没必要了。 至于具体程序设计么,我认为应是这样的过程: 需求分析:根据用户意向要求进行,最重要的过程,一般需要反复几次,大多数用户开始 时对自己的需求不是很清楚的。 系统分析:。。。。。。。。。。。。 单元模块:。。。。。。。。。。 模块编码:。。。。。。。。。。。。。 模块测试:。。。。。。。。。。。。。 系统集成:。。。。。。。。。。。。。 总体测试:。。。。。。。。。。。 交付使用:。。。。。。。。。。。。。 售后服务 :继续完善程序的过程。 其实,FeelingLoad说的很清楚了,我在补充一点。
如果是商业往来,合同协议当然不能少,并且越细越好,牵扯到经济利益,如果是编程游戏当然没必要了。 至于具体程序设计么,我认为应是这样的过程: 需求分析:根据用户意向要求进行,最重要的过程,一般需要反复几次,大多数用户开始 时对自己的需求不是很清楚的。 系统分析:。。。。。。。。。。。。 单元模块:。。。。。。。。。。 模块编码:。。。。。。。。。。。。。 模块测试:。。。。。。。。。。。。。 系统集成:。。。。。。。。。。。。。 总体测试:。。。。。。。。。。。 交付使用:。。。。。。。。。。。。。 售后服务 :继续完善程序的过程。 其实,FeelingLoad说的很清楚了,我在补充一点。
Z zanpen2001 Unregistered / Unconfirmed GUEST, unregistred user! 2003-06-14 #13 再说一点,设计的时候注意维护的工作量,意思是,你的设计要为维护打基础,设计的越简洁,维护起来越方便,当然还包括编码
苦 苦虫 Unregistered / Unconfirmed GUEST, unregistred user! 2003-06-14 #14 to czl007, :合同中对功能的部分是只写大概还是详细
L lightstar Unregistered / Unconfirmed GUEST, unregistred user! 2003-06-15 #15 合同写细些对双方都有好处,可以减少扯皮事件发生,包括项目周期、提交日期、费用及报酬、突发事件等最好都写清楚来
A Alex_Y Unregistered / Unconfirmed GUEST, unregistred user! 2003-06-15 #16 说到底就是流汗,当然也要讲方法 1.先把大的结构画一下 2.把模块分一下(大的功能) 3.参照同类软件取长补短 4.重点开发 哪差补哪,毕竟这是一个人完成的,前期再画流程也有预想不到的问题发生,所以多动手,多编代码没错. 5.排错并优化代码.界面和图标可以放到最后. 6.收钱
说到底就是流汗,当然也要讲方法 1.先把大的结构画一下 2.把模块分一下(大的功能) 3.参照同类软件取长补短 4.重点开发 哪差补哪,毕竟这是一个人完成的,前期再画流程也有预想不到的问题发生,所以多动手,多编代码没错. 5.排错并优化代码.界面和图标可以放到最后. 6.收钱
Z zjc Unregistered / Unconfirmed GUEST, unregistred user! 2003-11-11 #18 没错,楼上都是经验之谈。我的经验是需求分析不是要做,而是太重要了。问的越详细越好,还不能光听一个人的。否则,都要打包了又要改表结构,太累了。
H hongxing_dl Unregistered / Unconfirmed GUEST, unregistred user! 2003-11-11 #19 先跟用户交流,然后根据用户的要求总结。 最好做成通用的……管理软件,这下楼主就小发一笔了哦