031402402 曹鑫杰
031402428 鄢继仁
结对项目之需求分析与原型设计
一、需求分析------(NABCD模型)
N（Need，需求）
- 信息收集繁琐：系负责人下发导师候选名单，每个学生填报完提交给年级负责人，再汇总发给系负责 人，过程繁琐。
- 学生获取信息有限：学生了解导师具体信息的渠道有限，给填报志愿造成了困扰。
- 导师无法选择学生：导师往往只能被动分配到学生，对学生的期望人数也各不相同。
- 分配结果可能不理想：系负责人通过一种复杂而说不清道不明的人工排序和安排算法，统一给每个学生分配导师，结果可能不理想。
A（Approach，做法）
我们觉得采用APP的方式来实现。
- 同学使用学号注册登录，查看导师信息，填写5个梯度志愿的导师。
- 老师使用相应的账号登陆，填写自己期望的学生人数区间，查看填报了自己的学生的信息以及完成选择。
- 最后再由后台完成分配。
B（Benefit，好处)
- 省去了人工收集信息的过程。
- 学生更方便了解导师课题选择和研究方向。
- 导师可以了解学生，设定期望的学生人数。
- 学生和老师能双向选择，兼顾了双方的意愿。
C（Competitors，竞争）
- 优势：app端方便灵活，后期可以增加更多功能，本身还可作为一个版块附在其他app上。
- 劣势：需要下载，且使用一次后就没用了。
D（Delivery，推广）
- 课附在其他APP上(福大教务通、福大易班)，作为一小个功能。
原型设计
通过NABCD方法分析后，我们做出如下原型：
1、原型设计工具：Mockplus
2、Mackdown工具：stack editor
登录界面分为学生和老师。
学生端主页，填报5个梯度志愿
学生可查看导师信息
设置界面，消息通知可推送中选，留言等消息
教师端主页，可查看填报自己的学生
教师可查看学生具体信息，可以主动选择学生(但不是最终结果)
教师可设置自己希望的学生人数区间(默认0-8)
最后结果由后台分配，具体过程如下
1.第一次分配，为互相选中的情况。针对多个老师选择同一个学生，按学生梯度志愿优先分配。老师只能选择填报志愿为自己的学生，所以不会产生冲突；同时也因为老师选择学生时有人数限制(自己设定的学生人数)，所以也不会存在老师所收学生超过上限。
2.第二次分配，剩下学生都为没有老师选择他的情况。先视所有学生的志愿为平行志愿，对于每个人数未满的老师，将选择他的学生按绩点降序排序，绩点高的优先分配。如果产生一个学生可以分配给多个老师的情况，再按照学生自己的梯度志愿优先分配。
3.第三次分配，不考虑老师设定的人数上限，尽可能平均的分配剩下的学生给各个老师。
效能分析
断断续续花费了将近10个小时，效率略低。
PSP
| PSP | |
|---|---|
| 计划 | 估计这个任务需要4周的时间 |
| 开发 | |
| 需求分析：简化信息收集和整理；实现老师学生双向选择 | |
| 生成设计文档：博客 pdf | |
| 设计复审：先确定必要功能，再逐步细化讨论各个细节 | |
| 代码规范：花括号换行、缩进4个空格、变量尽量名词化、条例清楚、写好注释 | |
| 具体设计：界面设计，算法设计，数据库设计等 | |
| 具体编码：Java | |
| 代码复审：结对编程时，一人编程，另一人复审 | |
| 测试：黑白盒 | |
| 记录用时 | 课余时间，四周左右 |
| 测试报告 | 边做边测试，根据黑白盒测试写测试报告 |
| 计算工作量 | 两人*4周 |
| 事后总结 | 边做边总结，将开发过程中所遇问题和解决方法记录下来 |
| 过程改进计划 |
小结：
通过阅读《构建之法》，明白项目开发过程中，每个人的重点工作不相同，不可随意替换，书中用足球赛形象比喻了这一过程。正是因为这样，软件工程实现困难且常常延期。在开发过程中，需要多沟通，在结对编程中，仅仅两个人就有许多分歧，一定要先解决分歧再往下，不然常常导致中途返回重新讨论。比如对于后台互选算法，我们当时产生了分歧，导致后来原型设计的时候各个功能不断出现冲突。完成这次作业感触挺多的，发现软件工程不编码的部分要比编码的复杂得多了，今后还要多多努力。