第二次结对编程作业——毕设导师智能匹配

Deadline： 2016-09-30 22:00pm

      结对的感觉真不错，以前单人作业里没有过的化学反应。上一次是结对讨论和设计，已经让我们有了些不同的感觉。那么既然名称叫做“结对编程”，什么时候开始编程呢？在大家的期盼中，这一次作业开始要求编码啦！还是结对编程，还是第二次作业的结对的组合，不要拆分。

      首先我们回顾上一次作业里的结对项目——选择和分配本科毕设导师的原型设计：

      比我想象的好，第二次的作业，首先几乎每个同学都完成了作业，甚至还有一个没有选实践课的同学也单兵作战完成了作业。这次作业里要求大家，1、自学 《构建之法》及NABCD模型；2、自学 原型工具软件；3、分析客户语言描述的需求；4、细化讨论实现；5、随笔描述和Markdown排版；6、体会结对合作的过程和感受。 每一项都挺费时费力的，很多组都做得很不错，作品中看出了用心。同学和我的交流中，分享了构建之法阅读的感受、博客中分享了结对合作的体会。作品中也有不少亮点，比如：增加了客户忽视的毕设选导中的互动交流功能，忽视的绩点和方向选择的自动匹配功能，这一些都是你们作为开发者同时也是用户，从自己的亲身经历和感受出发得到的需求。很漂亮。 但是，也存在着一些明显的不足：1、在原型设计中主要考虑了毕设双向选择几个主要功能的页面排布，没有考虑系统整体运行使用过程中，比如30个导师和100个学生从选导开始到全部分配结束，会遇到什么问题，如何透过设计去解决这些问题。2、没有考虑异常情况，原型设计和系统实现，不是简单的将窗口边框按钮文字排布得当代码实现就OK了的，需要考虑用户实际操作中的问题，比如：如果学生和导师都迟迟不选择和不确认怎么办？ 如果多个导师同一时刻同时点击确认了同一学生怎么办？如果剩余师生都一直互不满意，怎么办？。 我们的系统应该如何去透过设计和流程考虑，来解决现实使用中会遇到的这些问题？这些都是原型设计阶段必须考虑和必须抛给用户，甚至提前为用户考虑得当并征求用户意见的内容。 系统是必须可运行的！可实际全程使用的！抱着这样的同理心去考虑系统。3、竞争是激烈和残酷的。完成作业只是满足基本要求。但最终只有一组胜出拿下这个标的。软件行业也是如此，投标方很多，投标书辛辛苦苦准备了很久，但只有一家会胜出。你们的作业中从哪里体现出必胜必杀的决心，和完全超越其他组的亮点和用心之所在。完成作业的同时，还要再进一步超越自我。

      接着我们来说明这次作业的内容和要求吧：

      编码实现一个毕设导师的智能匹配的程序。提供输入包括：30个老师（包含带学生数的要求的上限，单个数值，在[0,8]内），100个学生（包含绩点信息），每个学生有5个导师志愿（志愿的导师可以重复但不能空缺）。实现一个智能自动分配算法，根据输入信息，输出导师和学生间的匹配信息（一个学生只能有一个确认导师，一个导师可以带少于等于其要求的学生数的学生） 及 未被分配到学生的导师 和 未被导师选中的学生。   

     要求：

     1、输入的数据，另外写生成程序随机实现。

     2、为输入输出设计标准化、通用化、可扩展的接口，为该智能匹配程序模块后期可能的整合入系统提供便利。

     3、输入输出的格式，如采用文本文件或数据库的方式输入，可自由讨论确定，但需要明确，为后期可能的整合入系统提供便利。

     4、需要为智能匹配算法确立几条分配或排序原则，比如 绩点优先、或其他、或其他等等，请你们结对讨论确定。

     5、算法评价的目标是：对于同一组输入，输出的未被导师选中的学生数越少越好。

     6、代码具有规范性。

     7、实现的程序语言不做限制性要求。

     8、代码提交在https://coding.net 上。提交和使用方法，本周六助教会通过git和github使用讲解。网站上也有对应视频，可先自行学习使用。

     9、两个人共同撰写一个博客，包含上述内容的描述，同时包含结对感受，以及两个人对彼此结对中的闪光点或建议的分享。

     说明：仅就上述内容，实现一个单独的程序模块。不需要和之前的原型整合在一起。