2008-03-08

需求分析书 概要设计书 详细设计书 数据库设计书

关键字: se
在研发的过程中，我碰到最多的问题是：“我觉得这些文档，在我的模块完工后写更有效”

我自己曾经也提出过这种说法。

大家这些文档都是在什么时候写的。
评论
evangoe 2008-03-18
无论如何都是要写的啊~
blogbin 2008-03-18
根据具体情况裁减。
一般来说，在学校多写文档，毕业之后少写。
艾玛王国 2008-03-15
文档确实是重要且必须的，
制定和编写的过程，也是需求逐渐明确，责任清晰的这样一个过程。

至少在初期应该出个干货，
项目行进中，不断修改，

本人做国内项目，同一个需求经常被客户要求进行N次修改，

文档也需要进行N次调整，很痛苦，
但一些问题，也确实从文档里就可以发现的了。
抛出异常的爱 2008-03-14
没设计
没文档
没过程
没规范

你怎么才能知道你手下的员工不是在磨洋工？
wufan0023 2008-03-14
我现在做的项目就是因为文档不齐，问题非常的多，现在新的项目还没开始就写文档了。而且原来的PM（国外总部的）被所有coding人员（国内部）排斥了。新项目开始的要求就是把原来这个PM排除在外。o(∩_∩)o...
没有文档很多都是口头的，责任也都是推来退去，特别是管理人员，你都不知道自己还有多少东西没有搞定。
chnlslc 2008-03-14
感觉文档是必须的，但这个必须的程度就要根据每个团队的情况来自己定义了。像某些皮包公司，让他们写文档不如杀了他们。。。而对于规模较大的公司，利用文档来规范项目开发过程、降低项目风险绝对是行之有效的方法，公司规模越大，文档就要分得越细致，反之亦然。
insomniask 2008-03-12
有时文档 还不如不写！嘿嘿！！有的东西是天天变
alfred99 2008-03-11
我觉得这个要看情况而定，不过有一点是，文档一定要的，作为开发，验收，测试的依据。大家都想当然的做东西，你的系统变身人狼也就不远啦。
如果你们的团队很成熟，那有需求分析，和概要设计（一定要逻辑清晰，没有歧义，或者和需求分析合二为一），熟悉一点的人设计好数据库，下面就比较容易把握了，你心里知道下面的东西大家会做成什么样子。
如果你们的团队不太成熟，team leader就要辛苦点，把要规定的东西，注意的问题，都写出来，越详细越好，而且要时常跟踪，或者每天几分钟的站立会议（10人以下），组员汇报进度。
huanglppp 2008-03-11
哎..我在公司里,也写文档,都是开发完了在写需求,为了给客户看
bulargy 2008-03-11
文档这个东东，要写，不然做东东都是做的人当时凭空想想，想这样就这样，想那样就那样，最后整理整个系统的时候就发现无比的痛苦，我们公司以前好多项目都是项目快做完再补文档，现在在老大的推动下，一定要按照开发流程来做，虽然很多人还是有些不习惯，但是毕竟是在做了，我想慢慢就会好了。
真正的编码工作量其实占整个项目的40%就已经比较高了，开头的需求设计文档是必不可少的。
莫生气 2008-03-10
最好还是有份基本文档,这样对项目的功能点会确定的差不多
chenzengpeng 2008-03-10
学生做东西时，必须养成的习惯！！
alee007 2008-03-10
需求、設計文檔絕對不能少
習慣了寫起來就很快了。。。
hantsy 2008-03-10
国内开发过程都是扯蛋，我们公司需求分析，把设计要做的事都做完了
tomas_z 2008-03-10
需求分析一定要写的，越详细越好。不过还有一个总结文档也要写。对于积累很有用。
zgia 2008-03-10
我们是项目确定下来后，开始写需求分析，边写边讨论。
zhuxinyan0824 2008-03-10
我们也是项目做的差不多了，才开始写需求规格说明书，这方面语言能力还是不行，还的学习。
clasp 2008-03-10
有句话叫：大军末动，粮草先行。(10人的开发团队在国内应算是"大军"了，文档就是团队的"粮草").个人认为不管这个"军"有多大,要"行"多远都得事先形成文字的文档.这样项目才会有保障.降低项目风险是loader必做的事。做好文档就是最好的办法~O~.
lz726 2008-03-10
需求分析我觉得一定要先行，然后定下需求，才能进行后续的一系列设计。
b00062213 2008-03-10
需求书是不能在完成代码之后写的，要不你的业务逻辑和多人配合怎么办，而且和客户的交流没有需求书也很麻烦
发表评论

提醒: 该博客已发表在公共论坛，博客所有留言会成为论坛回贴，留言请注意遵守论坛发贴规则

您还没有登录，请登录后发表评论

homesailing
搜索本博客
博客分类
最近加入圈子
最新评论