研究生数学建模经验分享

声明: 本人从未参加、指导过数学建模比赛. 仅仅通过与参赛同学的初步交流写下本贴, 属于纸上谈兵. 如有任何建议, 请留言批评指正.

1. 引言

研究生数学建模是一个系统工程, 需要小组成员、指导老师的通力配合才能顺利完成任务. 同时, 它也是将理论与实践结合起来的锻炼机会, 因此应该是理工科研究生非常有必要参加的一项赛事.

2. 过程控制与人员分工

应在比赛前就制订详细的时间表, 进行合理的人员分工. 本节列出一个可能的方案.
由于比赛时间有 4.5 天, 如何保证紧张有序是成功的关键.

2.1 Day0 材料准备与心理建设

每年题目的形式都是一致的, 因此可以提前准备材料和环境. 包括

1. 文档模板.
   1.1 各节的标题、小标题.
   1.2 常用的句式. 可以找学长或导师要三份成功的 (往届一等奖) 文档, 然后将他们好的句式抄下来, 以后只需要在其基础上改内容. 对于摘要等重要部分, 尤其需要作好这类充分的准备.
   1.3 表格. 常用表格就那么几个.
2. 工具.
   2.1 编程工具.
   2.2 绘图工具. 必须生成矢量图.
   2.3 公式编辑工具. 如果用 Latex 就不存在这个问题了.

2.2 Day1 题目选择与文献检索

1. 题目选择 (8:00-10:00, 2 小时)
   30 分钟独立浏览所有题目, 进行评估.
   20 分钟投票确定 2-3 个题目.
   30 分钟进一步查找筛选后的题目的大致资料.
   30 分钟讨论获得最终的题目.
   预留 10 分钟喝水、上厕所.
   讨论后文档撰写员需要花 30分钟写出讨论纪要, 下同.
2. 文献检索 (10:00-12:00, 14:30-17:30, 5 小时)
   分头进行文献检索
3. 文献分享与讨论 (19:00-20:00, 1 小时)
   每人找出 5 篇有价值的文献, 并与队员分享.
4. 文献整理 (20:00-21:00, 1 小时)
   进一步理解文献.
5. 文档撰写第一阶段 (21:00-22:00, 1 小时)
   文档撰写应贯穿比赛的整个过程, 第一天的文档编号为 001 至 050. 相信你也不可能迭代 50 个版本.

第一天重要的是进入状态, 给自己多一些思考的时间.

2.2 Day2 方案确定与理论分析

1. 总体方案讨论 (9:00-10:00, 1 小时)
   给出各自的基本方案, 然后进行选择. 如果出现争执, 建议由组长定夺, 下同.
2. 分头分析 (10:00-12:00, 2 小时)
   根据基本方案进行分析, 需要画出草图, 给出数学式子, 对自己的方案进行支撑.
3. 方案初步汇总讨论 (14:30-15:30, 1 小时)
   获得比较确定的方案.
4. 分头分析 (15:30-17:30, 2 小时)
   如果有相关数据, 可以使用 Matlab, Python 等工具进行数据统计、可视化,
   如果程序设计的戏分比较重, 在本阶段也可以使用程序来进行某些验证, 或进行数据特征的分析.
5. 方案讨论与汇总 (19:00-21:00, 2 小时)
6. 文档撰写第二阶段 (21:00-22:00 3 次, 每次 0.5-1 小时, 文档撰写员完成)

第二天要形成一个理论部分比较完备的文档.

2.3 Day3 编程实现

1. 程序设计分工 (9:00-10:00, 1 小时)
   涉及模板划分 (类划分)、接口制订, 所以还是会花一些时间. 需要相应的 UML 图. 即使些图不出现在最终文档中, 对于队员之间的交流也非常有用.
2. 基础功能实现 (10:00-12:00)
3. 问题讨论 (14:30-15:00)
   将实现过程中的问题拿出来讨论, 看别的队员是否能给出相应建议.
4. 程序实现 (15:00-17:00)
5. 问题讨论 (17:00-17:30)
6. 程序实现 (19:00-20:00)
7. 程序联调 (20:00-21:00)
   应获得一个可正常运行的版本.
8. 文档撰写第三阶段 (21:00-22:00)
   如前所述, 文档撰写员并不闲, 因为每次小讨论之后都会进行文档整理. 同时, 要在下次讨论开始时花 10 分钟对上次的文档进行回顾.

第三天要形成一个可提交版本, 也就是说该版本应可以保证获得三等奖.

2.3 Day4 方案优化

1. 讨论与分工 (9:00-10:00, 1 小时)
   找出影响性能的瓶颈, 讨论可能的解决方案.
2. 理论分析与编程验证 (10:00-12:00, 2 小时)
3. 讨论 (14:30-15:30, 1 小时)
   当前存在的问题, 相互想办法.
4. 理论分析与编程验证 (15:30-17:30, 2 小时)
   继续啃骨头.
5. 讨论 (19:00-20:00, 1 小时)
   放弃实在啃不动的骨头. 有舍才有得.
6. 程序联调 (20:00-21:00)
   应获得一个可效果比较好的版本.
7. 文档撰写第三阶段 (21:00-22:00)
8. 文档检查阶段 (22:00-22:30)
   所有组员检查文档, 要把当前版本当成是最终版.

如果有人愿意熬夜啃骨头, 也可能试一下. 但不要对其有效性寄予任何期望.

2.4 Day5 文档检查与提交

1. 文档检查 (8:30-10:00, 1.5 小时)
   本阶段仅进行小范围的修改 (句子、标点符号等等), 如果这个时候还进行大改, 只会越改越差.
2. 10:00 提交.

虽然系统要求的提交时间是 12:00, 但是有可能断网、系统出问题, 所以预留两小时是非常必要的. 提交了就可以开开心心出去玩了. 不要相信好莱坞大片, 总是能在最后一秒成功拆弹.

3. 文档撰写常见问题

由于已经有成功的模板, 本节不讨论文档撰写本身, 仅指出文档撰写常见的问题, 可以作为一个检查列表使用.

3.1 版本管理不当

1. 未使用 “XXX竞赛008-李四.pdf”, “XXX竞赛325-汇总.pdf” 之类的明确版本文件名, 甚至自始至终只有一个文件名 “XXX竞赛.pdf”, 导致一旦出错就无法回退.
2. 不同队员修改不同版本之后, 并未同步.

3.2 不合适的句子、用词

1. 句子太长影响阅读;
2. 句子间的逻辑关系不清楚;
3. 两个相邻句子出现了重复的词或词组.
4. 使用了口语词汇.

3.3 质量差的图表

1. 未使用矢量图;
2. 图表缺编号, 并使用 “如下图” 指代. 应写 “如图 3-1 所示”;
3. 图表缺图题、表题. 应写 “图 3-1 数据分布” 甚至更长的图题;
4. 图表排版导致文档出现大量空白. 用 Latex 不会出现本问题.

4. 20211019 讨论汇总

1. 不同题目难度相差较大，要快速浏览一遍所有题目，把两个最难的丢掉。
2. 文献检索主要是背景知识，会写到最终论文中去。
3. 文献检索可能不是集中完成，在做到每个小问题的时候会查阅。
4. 第一天就可能开始编程。
5. 以文献撰写员为主线，两位队员提供相应素材（图表等）。
6. 每个小问题可能相对独立，不需要一个总体的程序框架，不需要程序的集成。
7. 两个队员可能同时做一道题，独立获得结果，选择更好的一个。也可以做方案集成。
8. 有些小问题不需要做实验？有可能，比较少。
9. 有可能第三天完成其中三个小问题，获得比较完整的版本。原型开发的味道。
10. 队长应该自顶向下地把控，需要图表的地方队员一定要提供，质量好点差点都是其次的。
11. 思路比结果更重要，还是总体把握的事情。
12. 可以不提交代码，但不建议。
13. 讨论的想法不但来自于理论分析，而且由实验结果驱动（反过来强行解释）。
14. 讨论仅确定方案的可行性，是否效果好还是由实验结果来验证。如果只有两个方案，就并行做。
15. 论文包装非常重要，长文更受青睐。提前准备足够的材料、模板。

---

等待拍砖的分割线.