结对学生：031402418 汪培侨

　　　　　031402618 林宇晨

使用工具：Axure Rp 7.0

一、需求分析(采用NABCD模型)

N (Need)

年级负责人：

• 需要向同学收集各种自己选择志愿的信息，收集麻烦
• 需要通过手动汇总信息，并提交给相应的分配负责人，汇总麻烦

分配负责人：

• 根据年级负责人收集的信息，进行相应规则的算法排序，分配好相应的老师，有时候需要一定人工分配，只是单纯的分配，没有导师选择学生这一个环节
• 有时候处理的不好，可能会导致一些学生的分配不合理（当然这方面比较靠近算法）

老师：

• 只能是被动听从分配负责人的安排，失去自己选择学生的权利
• 不能够控制自己所带学生的个数，从以往来说，一般都是3个
• 对自己的学生不够了解，有时候连自己的学生的大体情况都不了解

学生：

• 对可选导师的了解不够详细，选导师的时候也是迷迷糊糊，比如说是导师的研究方向，导师的选题内容
• 学生联系导师的方式，也不能够直接去获得，比如导师电话，原有情况下，只能够通过询问其他老师，或者不同的方式去获得，缺少了透明性。

A(Approach)

本次课题我们采用了APP进行对该系统的分配

1.  登入界面，我们设想是调用教务处登入的接口，进行账号密码的匹配
2. 首先有一个系统推送消息，先通知学生老师开始选择的时间，然后第一步，由导师先提前登入提交自己本次所选学生人数区间，学生登入填写自己的相应资料，比如推荐利用，以及毕业方向。
3. 然后学生端的导师选择界面通过导师确定的人数，自动生成可选导师的列表，并且可以通过点击导师的姓名得到导师相应的信息，进行相应志愿的选择次序，然后选择提交，到对应截至时间，就无法更改，期间可完成任意次的提交，最新一次的提交覆盖上面的提交。学生最多可以选择五个志愿，最少选择一个志愿。
4. 接着就是导师端，对学生进行选择，导师可以查看选自己的学生列表，并通过点击学生的姓名进入到学生信息的页面，查看学生的推荐，以及他的基本信息。导师可以通过这些信息，对相应同学进行筛选，如果不要则点击X，如果要则点击钩，然后也是有一个截至时间，期间也可以通过多次提交，最后一次即最终确认，然后这个选择是对应于自己当初的选择区间，不能大于最大区间，可小于最大区间。当然期间会出现一种特殊情况，就是多个老师选择了同一个学生，则通过消息在第二轮选导师之前，讲消息发送给学生，由学生自己选择这些选择他的导师。

• 这样第一轮选导师差不多完了。
• 第二轮第三轮第四轮选导师的方式与第一轮选导师的方式一样。
• 第五轮的时候，还是通过采用提交志愿的形势，不过这次选择的方式就跟传统的分配方法一样，如果没有到自己想要的导师那里去，只能通过随机分配。
• 上述轮次中，如果在某轮已经分配完毕后，则通过系统消息反馈，导师分配已结束，不在进行下一轮的筛选。

 B(Benefit)

• 可以化年级负责人收集的方式为提交，可以直接省去年级负责人这个职位
• 可以更加便捷的去了解导师，以及他们联系方式，不用在想法设法去找了
• 实现了双向选择的机制
• 减少了随机分配分到不是自己选择导师的概率

C(competitors)

 

• 相比于其他设计者而言，我们原型界面的设计是参考了 MOOC课程APP Coursera的界面风格，扁平化简单易操作。
• 我们的功能基本上可满足用户的需求，但是用户的满意度上，是有可以改进的地方，比如对导师进行分配时候，导师分类上。
• 加入了消息功能模块，不必向以往QQ群之类的推送消息，学生和导师即可通过消息模块进行消息信息的获取。
• 相比较与Web端的，我觉得应该是55开，Web端通过网页查看，电脑屏幕大，可以对条目看的更加的清楚，日后可整合到教务处的功能内部，而我们APP端的则是适应了当前时代的潮流，可以更加便捷的在何处何地，查看内部的信息，日后可以整合到福大教务通，或者西二在线之类的应用里去。

D(Delivery)

• 首先可以在我们周边的同学进行试用，如果好用的话，整合到福大教务通离去，然后可以推荐给周围学校的人，然后可以收获一定的利润。

一、原型设计

第一步

      首先我们进行需求的讨论，并粗略的画了几张手画图

双方美术都很差，有很大进步空间

第二步

　　　用原型工具Axure Rp 7.0进行我们界面的展示

　　　我们界面大小采用了720*1280的屏幕

一、首先二话不说一来肯定是登入界面

可以根据你是老师还是学生，选择对应的账号密码进行登入。

结对项目之需求分析与原型设计