031402632 朱松

031402615 林昊斌

需求分析：

N(Need，需求)：

• 信息收集困难，每个学生要把信息报给年级负责人再报给系负责人，过程十分繁琐复杂。
• 信息不透明，学 生和导师之间的信息流通困难。
• 每个学生最后必须得分配给一个导师。
• 每个导师带的学生人数不超过8个。
• 导师的选择有条件，人数过多时按绩点排名。
• 每个师要求自己带的学生人数有变动，那么尽可能满导师的学生数尽可能平均，如果导足老师的需求。
• 尽量保证学生分配到的导师在他的志愿名单内。

A(Approach,做法)：

• 采用web端的形式，因为选导师系统四年只用到一次，与客户端相比较之下更方便，并且免去不同平台的覆盖，在各种机型上的适配以及推广难度等问题。
• 我们的网页分为学生和导师两种界面，分别具有不同的功能，并且记录了不同的导师和学生的具体信息。
• 在导师界面，导师可以自己设置学生人数，系统按照绩点排名进行筛选；在学生界面，学生可以从导师列表中自己设置5个志愿。
• 为了避免有的学生无法分配到导师，我们采用了多轮选取。

B(Benefit,好处)：

• 节省人力，不需要大量的负责人。
• 让导师和学生在选择时更直观，方便。
• 在分配时，不需要系负责人进行复杂的人工分配，让分配更加简单智能，使最后结果的满意度最高。

C(Competitors,竞争)

• 我们小组认为，在这个项目上存在竞争的方面有2点，一是使用便捷性，二是用户的选择。在便捷性上web端不仅能在电脑，还能在手机等具有上网功能的设备上进行使用，而客户端在这点上就具有局限性；并且因为这个系统大学基本只用一次，所以客户可能更倾向于web端。

D(Delivery,推广)

• 如果这个系统更好用的话，可以在教务系统添加这个系统的接口，这样每个学生选导师时就能直接进入。

原型模型设计：

结对过程:

原型模型介绍：

导师选择系统主界面中根据输入的用户名进入不同的系统界面，分为学生界面和导师界面，当遇到问题时，可发邮件咨询管理员。系统中的导师和学生详细信息都从教务处系统导入。

学生界面，学生可在左边的信息栏中查看具体的方向介绍，然后根据不同的方向选择合适的导师，并且可在选择框中直观的设定志愿和查看中选情况。并且点击导师姓名即可跳转到教师资料界面查看详细介绍。

教师信息界面，在这里学生可以了解到各位导师的个人信息和教学成果。

导师界面，在这个界面中，导师可以设置要带的学生的人数，并且对选了他的学生进行挑选，点击学生姓名即可查看学生详细信息学生列表可按绩点排序，并且每轮选择结束都可查看学生的中选情况。

学生信息界面，在这里可以了解学生的详细资料和学习情况。

PSP：

感想：

阅读完《构建之法》后，对于一个项目的需求分析有了更加深入的了解，知道了NABCD模型，也和队友在摸爬滚打中完成了这个模型。第一次接触原型模型设计工具，感觉开启了新世界的大门。。设计完这个模型内心还是有点激动的，希望能继续进步吧。

PDF附件：http://files.cnblogs.com/files/linhaobin/结对.pdf