万恶的软件工程开发文档

现在在上软件工程课，布置的课设是叫13份开发文档。

01、可行性研究报告
02、项目开发计划
03、需求规格说明书
04、概要设计说明书
05、详细设计说明书
06、用户操作手册
07、测试计划
08、测试分析报告
09、开发进度月报
10、项目开发总结报告
11、程序维护手册
12、软件问题报告
13、软件修改报告

万恶的文档，越写越生气。上课老师教的课程围绕如何少用goto语句，并且还给我们举了好多例子来解释这个问题

面向对象都好多年，还总能看到类似于这样的让人无从下手的标题：

3、 模块设计说明
3.1 模块n结构（n是模块序号）
将概要设计产生的功能模块进行细化，形成若干个可编程的程序单元（用图表形
式给出程序单元的结构）。
3.2 算法
给出选用的算法和数学公式。
3.3 数据结构
用图表描述数据结构。
3.4 程序逻辑
用框图或过程性描述语言的形式表示各程序单元的控制流程（常用程序流程图表
示）。

我和老师反映过这个问题，人家给出的解释是“这个还是要按照课本上面的来”

我还没有上班，想问一下坛子上面的人 现在的开发文档也是这个样子么？ 没有改进么？

要是不涉及保密问题，不知道方便不方便传上来一份 让我也了解了解到底应该是什么样子呢？

项目中的文档有三个作用：
1，忽悠客户，领导，面子工程
2，项目规范和沟通（文档的实际作用）
3，人员流失严重的补救措施（美化一下说就是：后续开发的理论和技术基础）

ps：文档写好对项目还是有很大帮助的，关键看项目实施过程中是不是遵照文档实施。文档写好靠书是没有用的，还是得真刀真枪的干。

我个人还是比较看重文档的编写的，就像您所有说得

是一种沟通方式，不过我还是觉得内部面对面沟通来的比较实在。并且在写文档的时候可以发觉许多之前忽略掉地方。比如写需求分析的时候。一边写用例一边就发现了之前的漏洞

并且确实如果存在项目开发中人员流动的话，我觉得新来的人读读文档就可以很好的了解现在的项目进度，以及对项目有了整体的认识。

不过教科书上面这13文档实在是。。。。太古老了吧。好多条条框框早已经不适用了。

正好在坛子上面看见一个人的blog把13文档都转过来了。和我这本书上的一模一样
http://niceo.iteye.com/category/38363

可以仔细看看 好多文档的格式 我认为早已经太古老了。

我在学校大部分的软件工程开发的书籍都读过了。我读到的国内所有的软件工程方面的书 都是我抄你，你抄我。连例图都懒的改一下。
国外确实有基本好的书，不过我在网上Google了半天 发现没有模板是按人家那种格式写作的。

不知道现实公司中 模板的大体格式都是什么样子的呢？也是那13份万恶的文档的格式么？

HEHE

实际中只多不少

这么万恶-。-

3.2 算法
给出选用的算法和数学公式。
3.3 数据结构
用图表描述数据结构。
3.4 程序逻辑
用框图或过程性描述语言的形式表示各程序单元的控制流程（常用程序流程图表
示）。

那这些玩意呢？ 也要填写？

没有就可以不写，描述程序逻辑你可以用别的图，比如UML状态图和序列图。做得好，有创新，难道老师会给你0分吗？
与格式相比，内容更重要

如果一个程序要写这么多文档，那当然不合理。
做为一个学生，学习多一点似乎没有什么不对吧。
估计楼主是在培训学校，而不是正在上大学。

我在北京一所正规的不能再正规的大学-。- 还是软件工程专业的。



肯定不会，因为老师从来不看。他只是按指标完成课程布置必须有的东西，我都很怀疑他懂不懂uml（因为他确实不懂面向对象是什么），所以我更不指望他去看。


我的意思是想了解一下正经公司里面开发文档到底什么样子的，起到多大的作用。

据我了解到的小道消息都是说 文档几乎没有任何作用，做给客户看看而已。甚至都是在开发项目以后“后补”出来的。

不知道情况是否属实。

这个话就跟没说一样
就好像说，小道消息说吃东西没有好处，会撑死会毒死，到底要不要吃东西啊

哎。。。。

我的意思是想知道，正经公司的开发文档是什么样子的。好让我这个在校生长长见识了解了解情况。

如果我的话说得很晦涩 很难理解。 让您们理解不清楚我想表达的意思 请您们海涵

谢谢。

谢谢谢谢。

谢谢。