031402632 朱松
031402615 林昊斌
需求分析：
N(Need，需求)：
- 信息收集困难，每个学生要把信息报给年级负责人再报给系负责人，过程十分繁琐复杂。
- 信息不透明，学 生和导师之间的信息流通困难。
- 每个学生最后必须得分配给一个导师。
- 每个导师带的学生人数不超过8个。
- 导师的选择有条件，人数过多时按绩点排名。
- 每个师要求自己带的学生人数有变动，那么尽可能满导师的学生数尽可能平均，如果导足老师的需求。
- 尽量保证学生分配到的导师在他的志愿名单内。
A(Approach,做法)：
- 采用web端的形式，因为选导师系统四年只用到一次，与客户端相比较之下更方便，并且免去不同平台的覆盖，在各种机型上的适配以及推广难度等问题。
- 我们的网页分为学生和导师两种界面，分别具有不同的功能，并且记录了不同的导师和学生的具体信息。
- 在导师界面，导师可以自己设置学生人数，系统按照绩点排名进行筛选；在学生界面，学生可以从导师列表中自己设置5个志愿。
- 为了避免有的学生无法分配到导师，我们采用了多轮选取。
B(Benefit,好处)：
- 节省人力，不需要大量的负责人。
- 让导师和学生在选择时更直观，方便。
- 在分配时，不需要系负责人进行复杂的人工分配，让分配更加简单智能，使最后结果的满意度最高。
C(Competitors,竞争)
- 我们小组认为，在这个项目上存在竞争的方面有2点，一是使用便捷性，二是用户的选择。在便捷性上web端不仅能在电脑，还能在手机等具有上网功能的设备上进行使用，而客户端在这点上就具有局限性；并且因为这个系统大学基本只用一次，所以客户可能更倾向于web端。
D(Delivery,推广)
- 如果这个系统更好用的话，可以在教务系统添加这个系统的接口，这样每个学生选导师时就能直接进入。
原型模型设计：
结对过程:
原型模型介绍：
导师选择系统主界面中根据输入的用户名进入不同的系统界面，分为学生界面和导师界面，当遇到问题时，可发邮件咨询管理员。系统中的导师和学生详细信息都从教务处系统导入。
学生界面，学生可在左边的信息栏中查看具体的方向介绍，然后根据不同的方向选择合适的导师，并且可在选择框中直观的设定志愿和查看中选情况。并且点击导师姓名即可跳转到教师资料界面查看详细介绍。
教师信息界面，在这里学生可以了解到各位导师的个人信息和教学成果。
导师界面，在这个界面中，导师可以设置要带的学生的人数，并且对选了他的学生进行挑选，点击学生姓名即可查看学生详细信息学生列表可按绩点排序，并且每轮选择结束都可查看学生的中选情况。
学生信息界面，在这里可以了解学生的详细资料和学习情况。
PSP：
| PSP | |
|---|---|
| 计划 | 估计这个任务需要3周的时间。 |
| 开发 | 分析需求：实现双向选择系统，解放人力并提高分配效率。 |
| 生成设计文档：md文档。 | |
| 设计复审：因为结对编程，和队友都在讨论审核最适合的模型。 | |
| 具体设计：根据实际情况，一步一步完善起初的设想。 | |
| 测试：设计完，让一些用户进行测试查看是否存在不合适的地方。 | |
| 报告 | 由于结对编程，所以报告由双方共同讨论完成。 |
感想：
- 在阅读完《构建之法》后，通过对第三章的阅读，在和队友在摸爬滚打中，了解到工工程师的含义，明白每个人的能力有与着重点不同，不行进行比较，而且有关技术方面，化不能说的太满，容易被打脸，正如有个同学说过，你真正了解过这个语言吗，怎么就敢说精通。
- 大学的生活，经历泰国安逸，让我们想当然的以为我们的能力很强，可是真正的水平，全用在网络搜索上。真正的工程师的能力距离我们还有一定的距离。
- 通过第八章的阅读，对于一个项目的开发过程有了更加深入的了解，很多时候，我们总是局限在自己的想法上，思想上的巨人，行动上的残疾，特别是在自己真正的去实现自己的想法时，又发现做出来的总与起初的设想有偏差。还有原本认为设计一个产品能只需要规划好做成什么样就够了，可是再知道NABCD模型后，发现自己的想法是那么的天真，需要照顾到的方面还有很多。需求分析是在软件开发中的重要程度不容轻视，它引导我们最开始前进的方向，方向对了，开门红，能够造就优势，方向错了，偏离最佳路径，结果就不得而知。
附件
需求分析与原型设计PDF：https://files.cnblogs.com/files/song6/需求分析与原型设计.pdf