03.福大本科生毕设导师双向选择系统_需求分析和原型设计
031402508 洪佳铭
031402516 黄瑞钰
一、需求分析
1、N（Need，需求）
-
分配过程繁琐：以往都是通过系负责人对各班收集来的信息进行汇总，再通过某种复杂的算法进行分配。
-
学生对导师的了解程度有限：学生只能从表格中得到导师的些许信息，甚至连联系方式都没有，这对学生是不利的。
-
导师对学生不了解：之前的模式中，完全没有导师的参与，导师完全不知道选择自己的学生是怎样的，只能是在分配后才知道自己带的学生是谁。
-
分配结果不尽如人意：有些学生分配到的导师不是他（她）所期望的，这对之后的学习是一个重大的隐患。
2、A（Approach，做法）
-
采用web端：由于使用频率非常的低，所有web端绝对更适合该项目。很难想象去把一个用户使用一两次就绝对不会再去用的功能，做成一个独立的APP。如果作为一个功能模块，嵌入到像福大教务通、福大助手这些使用频率高的产品里，那还说得过去。
-
线上直接选择：学生通过系统，直接填选自己中意的导师，无需通过中间人来收集填报信息。
-
双向选择，导师参与其中：导师也参与到分配过程，导师可以根据学生的志愿表来挑选自己中意的学生。
-
丰富学生、导师信息：导师和学生均可以编辑自己的信息，加深双方的了解，做出更好的决策。特别是导师和学生都可以留下联系方式，师生可以更好的沟通。
-
多轮志愿填报：采取2~3轮志愿填报，这样第一轮没有选中的学生，可以根据自己的情况再去选择其他人数未满的导师。这样就避免了被强制安排的情况。
3、B（Benefit，好处）
-
解放系负责人：学生和导师均可在线上直接互选，不用系负责人辛苦收集学生的填报志愿，再人工分配导师。
-
师生之间更加了解：有详细的信息参考，学生更加了解导师的研究方向，导师更加了解学生的特长和需求。
-
分配方式更加人性化：导师可以自己选择学生，如果未选择，系统将一定的排序自动分配。
4、C（Competitors，竞争）
-
竞品较多：同班20多个组，竞争很激烈啊。
-
优势：
- 基于web端，没有使用负担，方便操作
- 部分数据基于教务处，尽量减少需要用户自己填写的数据。
-
劣势：
- 队里的两人都不会开发web端
- 依赖教务处的数据，如果教务处那边不愿意提供帮助，就得增改功能了。
5、D（Delivery，推广）
-
老师方面：希望学校鼓励老师提前去完善自己的个人信息。（我看了咱们学院网站，里面老师信息不是很完善，有些老师信息甚至是空白的。希望日后能够完善，这样也方便未来在其他地方信息共用。）
-
学生方面：由于这是每届学生必做的事情，所有只要在选择导师前期，学校直接下放通知，层层往下，最终学生能收到通知就好。
二、原型设计
-
原型模型设计工具：Axure Rp Pro 7.0
-
演示地址：猛戳此处⬅️
-
产品功能结构图
-
学生界面
-
登录希望能够直接和教务处的账号密码关联，这样用户就无需再去注册账号。（若有政策方面的原因而无法和教务处关联，那后期再考虑其他方式注册登录。问：教师应该也有自己的教务处账号密码吧？）
-
导师选择界面的入口用户可以很方便的查看自己的预选结果。
-
导师选择界面灵感来自于与京东筛选电脑的界面。用户看到导师姓名、职称、预带人数、研究方向等基本信息。
-
点击选择该导师后，导师头像和名字将在底部志愿确定框中显示。
-
点击红框中的热区，学生可以查看导师信息详情。（导师部分信息学院网站里就有（待完善），若能共享数据那最好，不能的话后期导师的个人信息编辑功能需要增加一些输入）
-
我的导师界面，用户可以查看自己的中选结果，为了方便勾搭自己的导师，同时考虑到教师手机号这种隐私性较强的东西，只有学生中选后才会显示。中选前，学生只能看到QQ、电子邮箱这类联系方式。
-
个人信息界面，由于是和教务处账号关联，应该会有用户的基本信息，所有姓名，学号强制设为不可编辑，以防用户ID更改。其他信息，学生根据自己情况填写。
- 教师界面
-
学生选择界面，没有像导师选择界面那么丰富。考虑到性别、长相可能会产生差别对待的情况，所以只抓取了学生姓名，专业方向，志愿序列这些关键信息。学生排序，默认按照学生填报志愿顺序排序，相同志愿序的按照绩点高低来排列。
-
点击学生姓名，可以查看学生详细信息。
-
我的学生界面，主要还是为了方便导师查看自己的学生的联系方式。
-
个人信息界面，导师根据自己情况填写。特别是老师可以自定义预带学生人数。
三、效能分析和PSP
- 效能分析
- 前期的需求讨论充分利用了课余时间。
- 为了确保双方最终想法一致，各自画了一份低保真的原型，这样不仅可以补缺补漏，也可以很好的避免未来的争执，少绕弯路。
- 使用有道云笔记一起拽写文档，提高效率。
- 由于中秋假期回家，在家效率比较低。
- PSP
| psp | 明细 | 时长 |
|---|---|---|
| 需求阶段 | 需求讨论 | 1天 |
|| 需求确认 | 1小时
产品设计 | 产品功能框架 | 1天
|| 原型设计 | 2天
文档拽写 | |3天
四、小结
-
需求讨论：最开始根据本次作业的要求以及客户的需求，相互撕逼（讨论），一步一步的考虑解决方案。比如是要采用web端还是APP来实现这个项目，我们考虑到用户的使用频率等因素就果断抛弃了APP。恩，撕逼过程还是很愉快的。
-
功能取舍：最开始是有想做站内学生和导师相互交流的功能，但是考虑到学生和导师都不会常常登录，何况我们还是基于web端，更难实时交流，站内交流的功能就鸡肋了。交流方面导师提供邮箱/QQ就可以沟通了。
-
保证想法一致：讨论过后，为了确认双方是否都有很好理解对方的想法和整个项目，我们各自画了一份原型，双方互换后补缺补漏，再完善成一份中保真原型。
-
协同工具的使用：因为两个人要一起写文档，所有考虑到了协同工具的使用。最初是要用石墨的，但是中秋期间石墨停机了...后来我们转战有道云笔记，经过多个版本的更改， 逐渐完善了这份文档。
