031402504 陈逸超
031402426 许秋鑫
结对项目——导师分配系统
一、需求分析——(NABCD模型）
N（need）
在阅读完用户的现实困扰之后，我们总结了几个用户的痛点（即用户的需求）如下：
- 信息的内容较少：在分配导师的时候，一般是系负责人下发导师名单（excel或word），介绍导师的信息相对较少，学生从名单中对导师的了解不够充分。
- 信息的收集不够智能：年级负责人手动汇总学生的志愿信息，信息的收集十分繁琐，而且需要年级负责人十分的细心，否则容易出现一些意外。
- 分配过程不够透明化：系负责人通过一种复杂而说不清道不明的人工排序和安排算法，统一给每个学生分配导师。
- 分配结果不理想：老师只有被动分配到学生，大多学生也只能被动分配到老师。
A(approach)
我们决定开发一个app来解决用户的需求基本功能如下：
- 登录：学生用学号，教师用职工号登录导师分配系统。
- 信息查看：教师可查看选择自己的学生的资料，学生也可查看各位老师的简介、研究方向等。
- 学生—教师选择：学生填写五个平行志愿选择自己喜欢的导师，导师在选择自己的学生中挑选自己中意的学生。
- 查看分配结果：导师和学生在分配结果出来后均可在app内查看自己的学生/导师。
- 个人中心：学生和老师自主导入相关信息，例如学生填写自己的兴趣爱好、所获奖励、担任职务等等。
B(benefit)
根据以上功能，此导师分配系统较原本的手动分配有以下好处
- 学生与导师均能方便的了解到双方的信息作为自己的选择依据。
- 收集信息更加的方便准确，不需要年级负责人的手动收集，解放劳动力，并且减少信息收集出现错误的情况。
- 导师的选择更加方便快捷，只要在智能手机上安装app，随地随地都可以对导师/学生的信息进行查看，对自己的志愿或意向进行更改，对分配结果进行查看。
C(competitors)
主要竞争对手就是同样做这个系统的同班同学。我们的app有如下的优势:
- 如今移动端比PC端更为普及，几乎人手一部智能手机。使用app我们随时随地都可以对自己的志愿、信息等进行更改。可以使我们更加合理的利用零碎时间。
- 有优质的界面与用户交互，即用户体验。
我们的app有如下的劣势：
- 相比较于web，app使用需要下载
D(delivery)
我们的推广方案是向各个系的导师分配负责人介绍推荐，然后通过他们向学生们推荐使用这款软件，从而获得我们的大量用户。
二.原型模型展示
- 所采用的原型模型设计工具：MockingBot
- app原型模型:
这是我们原型设计的工作流
登录界面
根据登录的账号类型，进入不同的界面。学生进入学生端的界面，教师进入教师端的界面
学生端界面
首页
学生登录之后可以在首页看到导师的列表，点击选中之后可以查看导师的详细信息。
分配
学生点击分配之后，进入相应的界面。在分配中点击我的志愿，可以进入导师分配系统的学生选择导师的界面，选择自己喜欢的导师。在相应的导师分配结束之后，在分配结果中可以查看自己中选的导师。
个人中心
在个人中心点击列表第一项可以进入个人信息的界面。在个人信息界面中，学生可以编辑自己的联系方式、兴趣爱好、工作经历、所获奖励。
教师端
首页
教师登录之后可以在首页看到整个年级的学生列表，点击选中之后可以查看学生的详细信息。
分配
点击分配之后，进入相应界面。在分配中点击我中意的，可以查看当前选择我作为导师的所有学生，并且可以对所有选择的学生做出相应的回应。勾选同意表示该学生也被该导师选中。在分配中也有分配结果，在分配结束之后可以查看导师所带学生。
个人中心
在个人中心点击列表第一项可以进入个人信息的界面。在个人信息界面中，导师可以编辑自己的联系方式、简介、科研项目、教学成果、所获奖励。
三.效能分析与psp
1.效能分析
效能分析主要是让程序跑得越快越好，也就是为了降低时间和空间的复杂度。由于我们现在只是完成了原型设计，没有真正的编码。所以只能暂时预估我们的app在编码阶段可能在如下几个方面遇到问题：
- 实现学生和老师之间的匹配采取的算法。
- 学生或者老师从后台调取查看老师或学生的信息要耗费一定的时间，要如何优化。
- 个人中心保存信息、学生选择导师、老师选择学生，写入后台数据库要如何更高效的完成。
2.psp
四.结对过程
五.小结
以上的内容是我和队友两个人分析了客户的困扰之后，边学习《构建之法》，边应用《构建之法》里面的思想去对客户的现实困扰进行分析，并且做出需求分析和原型设计。完成这次作业收获挺多的，首先当然是学习到了知识，了解了整个软件开发的流程，知道除了编码以外，需求的分析以及原型的设计也是非常的重要。其次，通过我和队友的配合，我们体会到了分工协作的快乐。但是这只是我们初步的完成了栋哥的作业而已，我们还有界面的美化、后台数据库的设计、算法的设计等这些工作需要完成。
附：
pdf文件