[大家帮我说说]一个系统=一个项目+一个项目开发文档（数据流程图，数据库设计，系统功能介绍）

[Gutta]

我是一个小私营企业的软件开发小头头。

现在我最困扰的就是对于一个系统拿到手里以后不知道怎么下手？？

画数据流程图
然后 画ER图
然后 设计数据库
然后 设计界面
然后 写代码
然后 测试
然后 完成文档

总的说来，我的思路还是比较乱。。。希望各位大哥帮帮我，一个比较正规的开发方法应该是怎么样的？？当然，我不要求很正规，毕竟不是什么软件的专业开发公司嘛


就是说说上面我的方法有什么需要改进的地方？？？
还有系统流程图和数据流程图是不是一个概念，差不多吧？？？

谢谢各位！！

[Gutta]

顶！

[椅子]

你的意思是要走魔道？速成？

要根据项目组成员来决定开发过程。

你需要一个中轴线：需求暨设计，开发负责人，售后服务

第一个：视野开阔，写一手漂亮方案，能迅速学习
第二个：能带领程序员编码，不能是code fans，能和设计者沟通通畅，并参与设计
第三个：很多人都忽视这个，一个能与客户相处融洽，能快速修改程序，并能说服客户不改程序的售后服务人员是多么的不好培养!!!

[SunnyTomorrow]

一个系统=一个项目+一个项目开发文档

这个想法是错误的，是诸多软件管理过程做不好的罪魁祸首。

错误在于：我们在学习软件过程建设的时候没有系统地从目的和如何做好这件事情的方法这两个根本点来思考问题。而是盲目地照搬一些典型软件管理方法中的“文档”格式（很多讲软件开发过程的书应该被烧掉，误人子弟），企图在自己的项目中毫不偏差地应用这些格式（每个公司都有自身的能力水平和业务特点，应该针对性地建立自己的管理过程，参考一些“标准”建立文档记录格式），进而达到记录下开发过程的目的（这个目的是错误的，提高软件项目的可控性和软件的质量才是最终目标）。

[SunnyTomorrow]

系统的建设过程=开发过程的管理和控制标准规程+每个环节的实践方法+每个环节的工作成果
这三个方面都应该由开发企业根据自身的特点而定制，而不是照搬。只是工作成果方面，在表述需求、设计、测试的结果方面可以利用目前比较公用的模型——比如uml，但是也必须只能是参考，其他的文档还要自己根据过程的成熟度选择或者定义。

提醒：楼主说的下面这些图，只是设计部分的，还没有需求部分的图。设计部分各个公司考虑的侧重点不同，我就不说什么了。

关键是不能为了文档而文档——这害苦很多人我们就不要再踩地雷了。

画数据流程图
然后 画ER图
然后 设计数据库
然后 设计界面
然后 写代码
然后 测试
然后 完成文档

[bino]

按软件工程开发过程来管理撒.........