需求分析与原型设计

NABCD模型

N（Need，需求）:

收集信息的过程太过繁琐，有班级总负责人需汇总每一个同学的志愿并填入excel表中，上交年级负责人，年级负责人再将信息通过excel表导入
时效太慢，要想完成一次选导师的任务工作，需要收集每一个人的意愿，再将信息通过复杂的算法，尽量照顾到每一个同学的情况下，把导师分配完
学生分配不均衡。有的老师可能有5-6，而有的老师就只有3个
师生之间互不了解
学生对老师的不了解：只能够通过学院官方网站以及学长学姐口中得知，只能得知老师的方向以及老师好不好（毕设好不好过），其他几乎都一概不知
老师对学生的不了解：老师不了解学生的学习状况以及其能力，只能在分配完之后才得知，原来我分配了几个学生，都是怎样的
志愿提交后就几乎不能更改。都说了，收集信息的过程太过繁琐，所以在选择导师志愿的时候就格外慎重，因为一旦提交了，就几乎不能更改

A（Approach,方法）:

通过老师学生互选的方式，可以大大缩短完整选导师的时间
采用安卓客户端，但起初的话web端的更好用，但由于考虑到选导师只是每年一次，使用次数较少，若在移动端得到用户的支持，可将其附加到例如福大教务处这样啊app上
师生之间充分了解，老师的信息中添加了一栏，是近三年来毕设课题以及优秀毕设的连接，让同学更加深刻充分地了解老师的方向，老师也可以充分了解学生的计划与经历
轮选时间制度，就想学习的选课制度一样，在一定的时间内学生选择导师，时间截止后由老师反选，待老师反选完后，再进行第二轮选导师，由未分配到的同学选择
心仪老师选择，能够在更小更精确地范围内选择导师，而不是大范围地去筛选老师，除此之外还可以利用筛选来缩小心仪老师的选择范围

B（Benefit,好处）:

信息获取更为方便和充实（不用再通过各种小道途径来了解老师了，咦，生物信息学是什么方向，毕设要做什么？看完老师信息后，奥~我懂了。）
时效性更大（就像选课一样，可以有几轮选导师的情况，但所花费时间不会太长）
规定的时间内可以更换自己的志愿（可能在选导师的那几天，不知何种原因不喜欢这个老师了，但是却把ta放在了第一志愿怎么办，怕什么，我可以改啊）
老师可以适当的挑选学生（都跟负责人说了不要那么多学生，怎么还分配了这么多，有这个app，我就有选几个学生，什么样学生的权利啦）
快捷方便操作简单（画面简洁，易操作，交互性好）

C（Competitors，竞争）：

与web之间的竞争：
劣势：移动端需要下载使用，而web无需下载
优势：操作简单快捷方便，在选导师的最后一天，对于有拖延症晚期的同学，恰巧身边有没有电脑，移动端就很好的解决了这个问题
（对于移动+web的队，我只能说，可以在杀手功能上ko）
与师生沟通模式的竞争：
劣势：没有良好的师生交互
优势：师生交互只是为了更好地了解老师以ta所研究的方向，只要学生从老师信息中get到他们想要的信息，也就不会有多余的交互
（学生人数>老师人数，在选导师的时学生可以私信老师，那么老师面对众多学生的询问，是不是都应该回答呢）

D（Delivery，推广）

该APP针对的用户是广大学生和老师，要做到推广，拥有用户，可以先与自己系的负责人安利该app，通过使用后，若获得一致好评后，可以融入到福大教务通里，毕竟一年只是用一次。

原型设计

原型模型设计工具

AxureRp 8.0

结对照片

登录界面

由于信息是从教务处导入，所以不需要注册

学生端----首页界面

从主页面点击查看老师信息，以及筛选老师

学生端----心仪老师界面

学生端----已选择界面

学生端----个人信息界面

教师端----个人信息界面

教师端----首页界面

教师端----已选学生界面

效能分析

内容	需求分析	手绘原型草图+确定方案	原型工具的使用	markdown的使用+文档
时间（h）	1.5	1+0.5	6	3

PSP

项目耗时记录表

	估计时长	需求分析	生成设计文档	设计复审	代码规范	具体设计	具体编码	代码复审	测试	测试报告	计算工作量	事后总结
时间（%）	6	5	4	3	4	9	45	6	10	3	2	3

计划

估计时长：28天，将近一个月

开发

需求分析：找到目前的痛点，在针对用户需求的基础上加以创新
生成设计文档：有利于更清晰的了解模块和界面的衔接，便于编码
设计复审：由两人共同完成，复审则检查一些遗漏的细节便可
代码规范:查看代码规范文档，并列出我们需要注意的点
具体设计:界面设计、数据库设计等
具体编码：严格意义上老说两个人都是小白，所以编码上花费时间较多
代码复审：由于采用的结对编程，所以代码复审在模块或界面完成后
测试：采用黑盒白盒测试和真实的测试，获取测试结果并分析

报告