成员
031402330 吴宇轩
031402327 肖承志

项目名称：选择和分配本科毕设导师

项目来源：

大四的学生需要进行本科毕业设计，每个学生都会被分配到一个导师进行毕设指导，而每个导师的时间精力有限，只能指导有限个学生，需要做出一款成品软件，为导师和学生进行牵线搭桥，尽量让每个学生可以选到自己心仪毕设方向的导师，每个导师可以选到对自己研究方向有兴趣的学生。

项目现状：

系负责人下发导师候选名单(excel或word形式)给该方向的所有学生，每个学生报五个平行志愿提交给年级负责人，年级方向负责人手动收集汇总并发给系负责人。系负责人人工安排算法排序，统一给每个学生分配导师。而老师只有被动分配到学生，大多学生也只能被动分配到老师。每个老师对于期望的学生数不同，不能做到满足各自心愿。学生也不太了解老师的课题选择和研究方向。稀里糊涂分完的结果，为后续毕设的指导留下很多困扰和隐患。

需求分析

N(Need,需求):

这个项目的核心需求是将人力从繁琐的层层收集汇总解脱出来，用更科学合理的选择算法让老师和同学们进行双向选择，尽量做到每一个老师同学都能选到自己心仪的目标，握手成功！

• 年级负责人需求：可以不用一个个向同学们统计信息，以防汇总的时候出现错误。
  如果能有一个软件让同学们自己录入选择信息，就不会产生错误啦。
• 系负责人需求：人工安排算法排序，还要尽量满足更多同学的志愿，如果一个导师很多同学选还要按绩点进行排序，即使算法best也要花费大量的时间精力还容易造成疏漏。
  如果能用一个软件将所有同学的选择信息导入进行自动排序选择就轻松多了，还可以添加导师选择功能，实现双向选择。
• 报名学生需求：填了五个导师的名字，虽然是平行志愿，但总是希望能由排序更靠前的导师进行毕设指导。还能对可选择的导师有一个大概的了解，知道他们的研究方向，能由自己感兴趣方向的导师进行毕设指导。
• 导师需求：能指导对自己研究方向感兴趣的学生或者某方面来说相对其他学生更优秀的学生，让学生们在毕设中能有更好的成果。

A(Approach,做法）:

• APP可以通过手机等易携的终端设备进行操作，我们打算前期先做APP，后期视情况决定需不需要做web端。
• 每个学生以学号为账户，导师以职工号为账户，进行导师选择操作。导师会提前对自己所带学生数量进行设置。
• 每个学生和导师都会有自己的介绍，关于项目实践、研究兴趣方向、专业技能等的履历，以期在双向选择系统中能被自己心仪的对象所看中。（其中研究兴趣方向是前期由导师提供，系统生成各个小栏目后由学生选取）。
• 每个导师都会在个人信息中留下自己的邮箱，可以供学生们进行前期的咨询联系。
• 在系统选择中会给导师一段时间进行对有意向由该导师指导毕设的学生中选取自己心仪的学生，其余的名额由系统按选取算法进行自动匹配选取。

B(Benefit,好处):

• 参考研究生的双向选择机制，对本科毕设导师选择系统进行双向选择机制安排，让有意愿考研的学生可以提前了解熟悉研究生的导师选择机制。
• 在对导师研究方向有了解、与导师有前期沟通的前提下，让更多的同学不再是迷茫状态：不知道自己的导师是谁、研究方向是什么、自己的毕设课题是否真是有用有价值有情怀。
• 解放了年级负责人和系负责人大量的时间精力，降低了因人工产生错误带来重大不良影响发生的可能性。
• 导师可以选到自己心仪的学生，在志同道合的毕设研究中收获更多更好的课题成果。

C(Competitors,竞争):

• 提供了一个相互了解的平台，可以让导师和学生们能有所了解而不是在互不相知的情况下阴差阳错的开始毕设。
• APP样式简洁。作为一个服务学生的校园教务软件，简洁实用就是它的最好诠释。这款软件为的是解决毕设导师选择问题，尽量让更多的学生选到自己心仪的导师，更多的导师选到自己心仪的学生。所以它的界面要简洁，功能要专一，让人一看就会明白如何操作使用！
• 研究兴趣方向的归类，可以让学生们在五个志愿都无法选上的情况下也能找到志同道合的导师。

D(Delivery,推广):

• 与学校教务处商议进行捆绑安装或由其开辟功能跳转链接（可能需要进行web端的建设）。
• 以“实用、简洁、空间小”为宣言进行软件宣传，一款几乎不占用存储空间又必须使用的小巧软件。
• 在同学间进行前期推广测试，让同学们进行软件评测建议，如果用户体验效果良好则能占据先期市场。

原型设计

通过对用户需求的分析和详细的讨论，我们大致总结了app要实现的功能，并设计了原型模型。

所使用的原型模型设计工具：Axure Rp

• 结对讨论ING。

  

• 原型模型的界面结构列表。

  

• 简洁的应用主页和登录界面。

  应用主页的三个选项分别跳转至学生登录界面/教师登录界面/导师选择结果查询界面。
  登录界面中输入用户名(学号或教师号)和密码即可登录系统。

• 

学生界面

学生登录至系统后跳转至学生界面，学生界面下方有三个选项分别为个人信息/导师信息/志愿选择，登录后默认先显示导师信息界面，左上角为退出系统选项。

• 学生-个人信息界面。可以查看个人信息，进行修改邮箱/密码/个人介绍的操作。

  

• 学生-导师信息界面。列表为各个导师的简要介绍，点击可跳转至导师的详细信息界面。

  

• 导师详细信息界面。可查看导师的详细信息(研究方向/个人介绍等)。

  

• 学生-志愿选择界面。可按志愿顺序填写五个导师，也可填写希望方向，综合考虑后优化导师选择的满意度。

  

教师界面

教师登录至系统后跳转至教师界面，教师界面下方有三个选项分别为个人信息/待选学生/已选学生，登录后默认先显示待选学生界面，左上角为退出系统选项。

• 教师-个人信息界面。可以查看个人信息，进行修改邮箱/密码/研究方向/个人介绍的操作。

  

• 教师-待选学生界面。列表为选择自己的待选学生的简要介绍，按绩点从高到低排序，点击可跳转至待选学生的详细信息界面。

  

• 待选学生详细信息界面。可查看学生的详细信息(邮箱/个人介绍等)。如果觉得满意可以点击下方的选择来选择该学生，同时还给出了当前选择该学生的导师数作为参考。

  

• 教师-已选学生界面。可查看已选择的学生的简要介绍，同时给出可继续选择的人数。点击跳转至学生的详细信息界面，如果希望取消选择该学生，可在详细信息界面点击下方的取消选择进行操作。

  

选择结果

选择结果出来后，可在选择结果界面查询，查询角色分为学生/教师/负责人，学生可以查看自己选中的导师的信息，教师可以查看自己选中的学生的信息，负责人可以查看所有选择结果的信息。

效能分析

由于我们的产品原型并没有实际的代码和成品，无法进行真正的效能分析。而初步预计程序代码的效能主要在于导师选择算法以及从数据库读取数据的速度上。

• 一个更好的导师选择算法无疑可以减少很多的程序导师分配时间。
• 如果将软件存储空间尽可能减少，许多数据就会存储在服务器上或直接从教务处读取，这里端口的读取速度也影响着程序的运行速度。

PSP

预期规划

我们的方案采用安卓客户端的方式实现，后期视APP发展情况考虑要不要进行web端的建立。通过Java和Mysql进行APP的基本功能实现，优化用户体验，UI的唯一要求就是简洁明了，能让用户一眼就明白该如何操作。因为这是一个有针对性的特殊软件，使用频率正常是一年一次，而使用目的也是尽可能满足导师学生的双向选择，因而重点还是在算法的设计，如何用一个尽量简单快速的算法进行选择匹配。

小结

原型的设计采用RP进行，因为界面尽量简洁明了的初始要求在设计原型上省了很多时间精力。但关于学生导师页面上应有信息的讨论花费了比较多的时间，而即使是RP上初始框架构建也让用过墨刀的队友大呼美工不易。Markdown刚开始使用时还有些生涩，后面习惯了就还好，也让我们意识到了决定一个软件的被接受与否除了本身的好坏以外还有一个至关重要的就是前期市场的占领。正如腾讯在尚未构建满意的情况下投入市场只为比MSN更快一点，让用户熟悉使用习惯，更好的占领市场份额。让用户在同类型产品之间转换的成品远大于让用户熟悉一个全新类型的产品。因而对于现在的这个产品我们讨论后的要求就是算法尽量好，推出的速度尽量快人一步，界面尽量简单明了，以期在同类型的产品中能拔得头筹。

PDF版