本组小伙伴做的课题大致分为两类:(1)系统;(2)算法
1、答辩存在的问题
(1)第二遍 “凡事预则立不预则废” ,事不过三。
自己准备的不够充分,对自己要做到课题只完成了初步的浅显理解:什么是AQM,什么是LPCC,两者一起时出现的问题。关于实验部分也只看到了有提供基础的仿真代码和可行性就没有深入, 所以在开题报告和答辩PPT上面关于怎么去做讲得比较粗糙。
被答辩组长老师问到接下来具体的实验部署时,我也只能模棱两可的给出回答:将从仿真NS2下完成AQM、LPCC下验证各自,再两者结合.. ...(下午和指导老师深入讨论之后,才知道自己的回答有多蠢orz)。然后是被陈老师怼,我的实验不符合毕业设计中的复杂性工程一项.....我...万分委屈。用球对我的形容就是“一看你就是被怼傻了,你就说难不就好了。”=.=||
[总结]:主要原因就是自己准备不足,自己没有很清晰自己的课题要做什么,不是大致的而是具体的要做什么,这些要在开题答辩之前自己明确了。因为开题答辩的目的:向老师展示自己做什么,并且具体展示可行性,看能否让老师赞同你的可行性。心态摆正。
补充一点是我在答辩完之后跟带我的毕设学长交流时候的:最好是先去找中文文献,看明白是啥做啥咋做,再去看英文文献。(因为大多都是英文文献,直接看简直完全吃不消)
(2) 开题报告的书写存在格式问题。
本组普遍存在的问题主要有:参考文献的格式、参考文献的引用要有顺序、报告中出现的图片要清晰(复制粘贴简单照片不如自己画)。
(3)最值得争议问题
因为这次我们组的答辩老师都是平时带比赛之类的工程项目类老师,所以我们组所有做算法的小伙伴都被怼,尤其是最后四个来自同一位指导老师的做算法的四位小伙伴,我答辩结束留下来全程围观,可以用体无完肤来形容,甚至被老师说“好了你的算法不用说了我们也差不多知道了,就说你要做什么有什么创新...”替他们万分委屈。
答辩组的老师组长也说了,他自己对算法也不是很了解(唉),但是觉得算法的毕设可以做的有三类:算法学习(工程量太少)、算法改进(本科生基本办不到)、算法工程应用(老师们认为这个很满意)。最后从老师反复强调出来就是:不做工程就对不起你本科学的C++、web、java、软件工程、安卓开发......(老师我们本科还学了计网、操作系统、软件测试、嵌入式orz)
毕设选题需谨慎,如果是选择算法,哎,除非给你开题答辩老师比较懂。(比如杜老板那一组)
2、老师怼人的问题小结
做系统主要问:
(1)你的工程量有哪些(一定要讲清楚,毕设有一项要求是复杂性工程)
你打算用什么语言实现,代码量多少(在这里被怼了“开提前那么长时间你没去了解一下?那你做了什么?”委屈)
前端做嘛?用什么做?后端做嘛?用什么做?你一个人做嘛? (比较细)
(2)会针对你的毕设题目问一些应用场景:比如你做xx公司的管理系统,这个系统会不会太小?可以用到其他公司?反面就是问你的系统是不是做的太大了,你做的完嘛?还有你的系统你的特色是什么?因为现在做这个的人很多,你怎么保证别人用你的?
我们组一小伙伴打算做关于帮助你找代码的系统,结果老师说我觉得现在百度关键词找源代码也挺方便的啊?你这个会不会应用范围太小?你要去和指导老师商量一下,看看要不要换一个做...orz 选题需谨慎
做算法主要问:
三位老师都是项目工程方面老师,所以算法问的都很浅,而且问着问着就怼,认为没有工程性,千万句委婉表达你们换个做要么把题目内容换换把。(指导老师后来去反映了,考虑在毕设结束答辩的时候安排一个算法专业方面的老师来。毕竟工程不仅仅是指系统啊)
(1)你在算法上打算做改进嘛?你的改进有没有人已经提出来了并且做出来了?
我没有表达清楚我的课题的解决方案还没有人提出来过!!!
(2)代码量大概多少?怎么体现工程性?
最后就是我们组老师强调毕设的:复杂性工程、工程。然后就是你要保证自己能做完啊。
3、下午找指导老师对开题答辩和报告等进行深入讨论,深刻反思自己。
寒假目标完成:第一个仿真验证试验。(深呕一口气 两两组合要凉凉 这工程量)
测量参数:TCP% 、平均队列长度E[Q]、链路利用率η
吞吐量也完全ok
提供环境:缓冲区大小Qmax、链路容量C、异构RTT延迟和流量占空比
控制变量法慢慢设计吧
预期结果:(给出其中一组如下)
排列组合一下 深呕一口气。
寒假回来 实测。
对于老师说的没有人提出解决方案 肯定会让我做出来的 我很方...
4、结尾
万分感谢带我的毕设学长 因为拖延症我觉得自己药丸 万不得已找学长坦白“学长我可能要完” 学长二话不说先帮助我一起解决问题然后给了很多建议。我以为学长一上来要批评我好久,但是完全没有 ,而是先全力帮助我解决了问题后来跟我说“下次不要再有拖延症了你看你现在多难过”。深刻反省自己。
擦一把眼泪开始去改报告 配环境 做实验了。给自己打call
附:复杂工程问题的特征
(1)必须运用深入的工程原理经过分析才能得到解决;(必须满足)
(2)需求涉及多方面的技术、工程和其他因素,并可能相互有冲突;
(3)需要建立合适的抽象模型才能解决,在建模过程中需要体现出创造性;
(4)不是仅靠常用方法即可解决;
(5)问题中涉及的因素可能没有完全包含在专业标准和规范中;
(6)问题相关的各方利益不完全一致;
(7)具有较高的综合性,包含多个相互关联的子问题。