你们的软件开发项目,项目文档都比较齐全吗?(300分)

  • 主题发起人 主题发起人 荷塘新月
  • 开始时间 开始时间
我遇到的问题更郁闷了,我以前在一个大的软件公司坐过,现在到了一个小的公司,我给公司写了几个项目开发规范,包括:1软件开发规范,2项目备份规范,3项目修改规范,4文档编写规范,5数据库设计规范五大部分并配有标准的样板文件,结果老板看了只说不错,还让我讲了一次课,结果,也没实行。一个公司要想大的发展要靠一点点地积累,不要瞧不起这些文档工作。
 
我觉得文档这东西要全面起来看,不能光看一些所谓的规范就做出需要一系列的文档的结论。比方说在大家都很清楚需求的情况下不一定需要什么需求文档。典型的例子模仿某个软件,而这个软件都有现成的帮助说明文件了,就没有必要再写什么特定格式的需求文档,只要附出不同的部分就行了(大家可以参看《最后期限》的有关部分)。一年前我还追求齐全的文档,仔细想想,文档是用来交流传递思想的,如果有其他的方法,不一定要追求格式以及齐全.
 
钱,没钱谁写文档
 
系统文档数量的多寡与工程利益成正比,有钱啥都好弄,没钱啥都没劲
 
进了一家 日资
虽然情绪上不是很爽,但人家的开发模式的确够规范,而且已经成为习惯了。
所谓 师宜长技以制宜,呵呵
 
一般非纯软件公司是不全的
我在广告公司。
 
to paul_geng,你说得不对,软件文档是给别人看的,不管是模仿软件还是自己新的作软件,让别人一看到你写的设计文档就知道程序是怎么实现的。这样别人接替你的工作也好作。你说的“大家都很清楚需求的情况下”只是暂时清楚,难保几月或几年后你自己也忘了。再简单的系统也要文档。
 
我还没工作,不过自己写点小东西也会先写所谓的"文档".
我的那些东西虽然不规范,但是至少让我写程序的轻松了不少.
我的文档主要就是以下几个方面:
1.软件将要实现的功能,包括整体构思和各部分具体功能的说明.
2.各窗体设计说明,包括窗体将要完成的功能和控件具体作用.
3.各单元代码说明,这个是边做边写的,主要记一些自定义函数的输入输出说明.
4.数据库表设计.
5.命名规范,包括窗体、控件、自定义函数、全局变量等的命名和说明,这个一般写一次就可以了.
班门弄斧,很希望能有哪位大虾指点一下~
 
我一般都是随写文档随写代码,嘿嘿
 
什么计划文档都没有还要我写,没门!!那个老板太恶心了!!我准备走人[:(!]
 
小弟正在求职中,各位推荐一下:
华中理工2001年毕业,学电气自动化的。自学了一年的DELPHI+SQL,英语6级(有学习基础),希望转行写程序,哪位 大哥收留一下,待遇够吃饭就行了,主要想转行学习
 
一点都不全!!!
 
偶现在用的都是、正版 了哈哈
文档。。 唉一个人做工程。 还得管 铺光钎 哪有时间 写啊。。
综合布线 +自动化。 一个人搞 。
 
我们公司更小,软件版本都没有控制,更不用说其他的了
 
我们公司的系统分析能力很强,但是规模不大,也没有必要做文档。各位兄台是否认为没有文档的软件(大型)就一定会崩掉?我认为不一定,主要要看开发方式和开发方法。如果按照目前的教科书式的开发当然是一定需要,其实如果采用其他的开发方法,文档并不是必要的。只需要:1-代码格式、命名、书写的规范 2-加入适当的注释 3-经常在一起讨论
 
===========================================
来自:hlsl, 时间:2003-12-7 23:06:00, ID:2339957
我们公司的系统分析能力很强,但是规模不大,也没有必要做文档。各位兄台是否认为没有文档的软件(大型)就一定会崩掉?我认为不一定,主要要看开发方式和开发方法。如果按照目前的教科书式的开发当然是一定需要,其实如果采用其他的开发方法,文档并不是必要的。只需要:1-代码格式、命名、书写的规范 2-加入适当的注释 3-经常在一起讨论
========================================================
嘿嘿,当你和你现在的同事跳槽了的时候,你的老板可就抓瞎了。就算你们不跳槽,等两年后你们需要升级这个程序的时候,你可就需要费好大劲了。。。。。。
 
强烈法对hlsl的观点,cmm的评定标准中软件文档排在很重要的位置,难道印度、美国都错了吗?
reedblue说的对极了。
 
手头的工程,开始的时候所有文档齐备,编码完后,测试的文档就没有见过了!
 
都是开发前写一小步分,开完后补写大部分
 
后退
顶部