关于软件工程体系的困惑
各位论坛里的大大们：
小弟软件工程专业，今年大二刚完，暑假留校参与老师的一个项目。项目是由我们学校数学系的一个老师负责，主要的业务是生物仿真和科学计算，目前暂用MFC的框架实现。
目前我遇到一个很大的困惑，就是关于软件工程开发文档的问题，老师让我们先做出一个详细的设计文档，可以参照目前国外现有的资料，但是我发现实际上很难在现有的基础上去设计这样一份文档，所以前期耗了很久去了解这个项目的逻辑业务，包括公式推导和算法设计，但是我还是没有一个自信的把握说能去整出这么一套文档。后来参与这个项目的我们专业（软件工程）的另一个老师好歹才说服了他让我们这边的学生开始动手去先做代码，解决核心的业务问题。
我今年大二刚刚结束，还没有接受过系统的软件开发的流程，相关课程也是在下学期才开设，但是我现在站在一个懵懂的状态去质疑这套软件开发的体系：
1.实际软件开发的过程是否建立在充分详细设计文档的基础之上？
2.严格按照这个体系下的效率究竟如何？
3.后期版本需要做出一系列的修改时是否也应该先有文档后有代码？
小弟并非胡乱质疑，我作为一个初学者给出自己对上述质疑的解释：
1.设计文档的建立是在一个纯臆想的基础之上（至少目前我是这样一个感受），很难去捕捉其中的一些细节，而这些细节可能涉及到非常重要的内容，不到编码层面可能无法发现（在做的时候我深刻体会到这一点，包括老师给出的公式都有潜在的逻辑错误）。
2.详细设计的过程中必然会花费大量的时间和精力，而花费这些代价去做一个后期连自己都不确定的东西是否值得？这层意思可能表达的有些模糊，我再解释一下，现在前期初步的成果已经出来，我横竖看着都觉得有很多问题，存在大量数据冗余，效率低下的问题和无数的BUG......如果看着当初的设计，也就是我现在的产品，我肯定是不会按照上面写的做的。
3.现阶段才刚刚起步不久，但是在工作上我已经感觉到了一定的压力，我每天工作8个小时，在老师需要做中期产品检验的时候还加班去赶出一个粗糙的成果，这已经很累了，如果还要按照软件工程的那套理论去做，不知道还得折腾多久......
当然需要补充的是，前期项目的工作还没有涉及到数据库以及网络这一块的应用，如果说数据库的设计是必然先行的这点毋庸质疑，但是如果没有呢？灵活的成分是否存在？
因为老师不是本专业的，是搞数学的，不知道哪天搞了本软件工程的书看了，天天给我们灌输这套理论，我承认如果完全按照这套理论执行确实会非常完美。但是我觉得这和现实完全是两码事......老师当然有他的考虑，完整的文档是为了后续开发者的便利，以及后期的维护，但是这些是一定得按照那套顺序来？开发文档在后期产品成型后再做补充是否可行？
说了很多，希望大大们耐心看完，能够解答我目前的困惑。今天老师去开会，几个学生都翘班了，呵呵......
[解决办法]
1.实际软件开发的过程是否建立在充分详细设计文档的基础之上？
2.严格按照这个体系下的效率究竟如何？
3.后期版本需要做出一系列的修改时是否也应该先有文档后有代码？
确实是这样，先有代码后有文档那是毕业设计
[解决办法]
要有文档啊
不会写文档的话
在开发这条路上不会走太远的
顶多只是个会解决简单问题的码农
写文档要有很深厚的业务知识和逻辑分析能力的
文档时独立于开发平台之外的
也就是说，你有了编写良好的文档
就可以一路高歌猛进了
[解决办法]
《设计原本》的作者在书中讲过一句名言，大意如下：
我的价值，乃是帮助客户发现他真正地需求所在。
用户不清楚自己的需求，这在开发之中太常见了，甚至可以说大部分项目都是这种情况。因此我们作为工程师的价值便是帮助客户发现他们真正地需求。
软件工程之中，需求是需要专门做功课的，需求的提炼决定项目的成败，同时也可看出工程师的水平。这绝对不是一朝一夕能修炼出来的功夫，需要反复地和客户折腾，折腾若干年，积累一定的经验之后，水平才可能上去。大部分工作多年的工程师的发展瓶颈都出现在这块，更不用说一个大二的学生了。
慢慢来吧，这东西，着急没用的，需求是最见功夫的一块，只能一点一滴积累，没有捷径。
针对你说的项目，你可以尝试先给你的客户提出若干可行的解决方案，然后逐个和客户沟通，把抽象的描述通过问答的形式逐步细化为可操作的流程，以一个一个具体可见的场景来驱动你的设计。
针对设计和建模，推荐一本书《Thinking In UML》，可以作为参考，里头都是实战经验的总结。引用:
1. 写一份好的设计文档不是那么容易的事情，很多文档专家都是 业务专家 & 技术专家，没个若干年的经验很难写出来。
2. 把文档作为描述设计的手段，而不要当作目的，这样你写起来会比较有眉目。本末倒置的文档的必然结果就是：项目完结后便丢到永远没人看的文档库中。
3. 设计和实现在实际开发中往往都是迭代的，先有粗略的设计，然后实现大致框架，在实现过程中又会……
