结对名单：031402224 彭巍 031402233 郑扬涛
一、一个老师的迫切需求――选择和分配毕设导师之烦恼
选择和分配本科毕设导师的现状：
系负责人下发导师候选名单(excel或word形式)给该方向的所有学生，每个学生报五个平行志愿提交给年级负责人，年级方向负责人在某个截止时间点之前负责汇总该方向所有学生的填报志愿，发给系负责人。系负责人通过一种复杂而说不清道不明的人工排序和安排算法，统一给每个学生分配导师。人工分配的规则现有这些：
1.每个学生最终必须被分配到有且仅有一个导师；
2.每个老师最多带不超过8个学生；
3.某些热门老师受大多数学生共同选择而溢出时，考虑学生绩点优先；
4.每个老师分配的学生数尽可能平均；除非老师主动向系负责人声明自己带的学生数希望是0――8中的某个数值或某个区间，那么尽可能满足老师的需求；
5.在最后情况下，某些同学可能被分配到非他五个志愿的老师。 这样的情况希望越少越好。
现状的困扰是：流程很传统复杂繁琐不透明。过程也很繁琐，年级负责人手动收集汇总，系负责人手动分发调整。老师只有被动分配到学生。大多学生也只能被动分配到老师。每个老师对于期望的学生数不同，不能做到满足各自心愿。学生也不太了解老师的课题选择和研究方向。稀里糊涂，不可言说，就分完了，为后续毕设的指导留下很多困扰和隐患。
二、需求分析（NABCD模型）
1、N（Need，需求）
1、信息收集与发放流程复杂。系负责人需要将导师名单手动下发至学生，然后学生提交的志愿要人工逐级向上汇总。为了简化流程，提高信息化程度，最好可以有一套系统能够代替人工操作。
2、导师的主动权不大。导师只能被动的分配到学生。如果今年导师由于某些原因不能带太多的学生，而系里又强制分配一定数量的学生，则造成不必要的困扰。因此，导师在该系统中需要有一定的主动权，比如可以声明自己所带的学生数，能够主动选择学生等。
3、学生与导师之间相互不了解。如果导师在之前是有给自己上过课的，那么还好说，但是也有相当多的导师是第一次接触，完全不了解。导师对学生也存在相同的情况。因此，在系统中学生与导师之间应该能相互查看个人信息，学生简历，教师研究方向，联系方式等等（来源于教务处和学院提供的信息）。
4、分配方式、流程、结果不透明。“系负责人通过一种复杂而说不清道不明的人工排序和安排算法，统一给每个学生分配导师”，会不会给人一种钦定的感觉...因此，需要将分配流程透明化，同时分配结束后结果需要进行公示。
2、A（Approach，做法）
我们选择开发APP客户端，用户是学生和老师，用户是直接生成不用注册，类似教务处，账号是学号/工号，密码是身份证后六位。主要思路类似教务处选课，学生先在某段时间填写志愿（没到截止日期可以修改），然后老师选择学生，最后若是还有学生没有分配到导师可以用以前的算法进行分配。
学生模块的功能：
1.学生可以查看有哪些导师（可以分类查看），及其个人信息，并选择。
2.可以查看自己选了哪些导师并退选（在截止日期前）。
3.若被某个导师选中则会收到提示消息。
4.编辑个人信息。
老师模块功能：
1.导师可以查看选择自己的学生及其个人信息，并选择。
2.可以查看自己选中了哪些学生。
3.编辑个人信息。
3、B（Benefit，好处）
1、信息分发与收集实现信息化。学生登录系统后，能够查看各个方向导师的信息，填报志愿只需要在APP中勾选即可。无需进行Excel的汇总，减少时间成本和出错几率。
2、提高导师选择的主动权。导师能够在个人信息中编辑期望的学生数。同时可以查看有哪些学生选了自己，再根据学生的其他信息可以决定是否选择该学生。
3、实现导师方向的分类索引。学生可以根据自己的兴趣，很方便地选择适合自己的方向，了解到该方向有哪些导师在做研究。
4、促进师生之间的了解。在列表中可以很方便地查看学生或者导师的信息。
4、C（Competitors，竞争）
各个学校每年都会有学生面临导师分配的问题，因此导师分配系统的需求空间还挺大的。
我们的优势：
1、移动端APP操作简单方便。
2、实现导师方向的分类索引。
3、学生与导师获取信息便利。
我们的劣势：
1、APP用户粘性不强，本科四年只用一次，用完就卸载了。
2、未提供评价导师功能，无法查看他人对该导师的看法。
3、用户交互、UI等有待改进。
5、D（Delivery，推广）
推广的话，可以先安利给数计学院下一届的学弟学妹试用，有了一定的用户基础后，再不断完善界面、功能，然后逐步推广到全校。
三、原型设计
原型模型设计工具：MockingBot（墨刀）
推荐扫描下方二维码进行在线体验原型 或 点击我 进行跳转：
登录模块
Figure 1. 登录界面
学生模块
1.学生可以查看有哪些导师（可以分类查看），及其个人信息，并选择。
2.可以查看自己选了哪些导师并退选（在截止日期前）。
3.若被某个导师选中则会收到提示消息。
Figure 10. 消息界面
4.编辑个人信息。
Figure 11. 个人信息
导师模块
1.导师可以查看选择自己的学生及其个人信息，并选择。
2.可以查看自己选中了哪些学生。
Figure 16. 中选学生
3.编辑个人信息。
Figure 17. 教师信息
结对交流过程
Figure 18. 讨论原型草稿
Figure 19. 设计登录界面
Figure 20. 设计学生首页
四、效能分析和PSP表格
效能分析
| 流程 | 花费时间 |
|---|---|
| 需求分析（画原型草稿） | 45min |
| 熟悉原型工具 | 40min |
| 开发原型 | 3.5h |
| 改进完善 | 35min |
| 文档（博客） | 3h |
PSP表格
| PSP | Personal Software Process Stages | 计划时间 |
|---|---|---|
| Planning | 计划 | 45天 |
| Estimate | 估计这个任务需要多少时间 | 45天 |
| Development | 开发 | 30天 |
| Analysis | 需求分析 | 3天 |
| Design Spec | 生成设计文档 | 1天 |
| Design Review | 设计复审 | 1天 |
| Coding Standard | 代码规范 | 1天 |
| Design | 具体设计 | 3天 |
| Coding | 具体编码 | 30天 |
| Code Review | 代码复审 | 3天 |
| Test | 测试 | 7天 |
| Reporting | 报告 | 1天 |
| Test Report | 测试报告 | 1天 |
| Size Measurement | 计算工作量 | 1天 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 1天 |
五、小结
阅读完构建之法的相关内容后才意识到一个程序员要关注的事情不仅仅只有编码、测试，用户的需求和体验同样重要。之前没画过原型图，画的过程中才发现把需求变成功能是要考虑很多细节，还要考虑实现的可行性。学习完NABCD模型之后，对需求分析有了初步的了解，并在此次的结对编程中进行了实践。在这次实践中学到了很多的知识，更重要的是我们知道了一个程序员该如何评估发展自己。
六、附件
本次博客的PDF版：点击查看