031402632 朱松
031402615 林昊斌
需求分析:
N(Need,需求):
- 信息收集困难,每个学生要把信息报给年级负责人再报给系负责人,过程十分繁琐复杂。
- 信息不透明,学 生和导师之间的信息流通困难。
- 每个学生最后必须得分配给一个导师。
- 每个导师带的学生人数不超过8个。
- 导师的选择有条件,人数过多时按绩点排名。
- 每个师要求自己带的学生人数有变动,那么尽可能满导师的学生数尽可能平均,如果导足老师的需求。
- 尽量保证学生分配到的导师在他的志愿名单内。
A(Approach,做法):
- 采用web端的形式,因为选导师系统四年只用到一次,与客户端相比较之下更方便,并且免去不同平台的覆盖,在各种机型上的适配以及推广难度等问题。
- 我们的网页分为学生和导师两种界面,分别具有不同的功能,并且记录了不同的导师和学生的具体信息。
- 在导师界面,导师可以自己设置学生人数,系统按照绩点排名进行筛选;在学生界面,学生可以从导师列表中自己设置5个志愿。
- 为了避免有的学生无法分配到导师,我们采用了多轮选取。
B(Benefit,好处):
- 节省人力,不需要大量的负责人。
- 让导师和学生在选择时更直观,方便。
- 在分配时,不需要系负责人进行复杂的人工分配,让分配更加简单智能,使最后结果的满意度最高。
C(Competitors,竞争)
- 我们小组认为,在这个项目上存在竞争的方面有2点,一是使用便捷性,二是用户的选择。在便捷性上web端不仅能在电脑,还能在手机等具有上网功能的设备上进行使用,而客户端在这点上就具有局限性;并且因为这个系统大学基本只用一次,所以客户可能更倾向于web端。
D(Delivery,推广)
- 如果这个系统更好用的话,可以在教务系统添加这个系统的接口,这样每个学生选导师时就能直接进入。
原型模型设计:
结对过程:
原型模型介绍:
导师选择系统主界面中根据输入的用户名进入不同的系统界面,分为学生界面和导师界面,当遇到问题时,可发邮件咨询管理员。系统中的导师和学生详细信息都从教务处系统导入。
学生界面,学生可在左边的信息栏中查看具体的方向介绍,然后根据不同的方向选择合适的导师,并且可在选择框中直观的设定志愿和查看中选情况。并且点击导师姓名即可跳转到教师资料界面查看详细介绍。
教师信息界面,在这里学生可以了解到各位导师的个人信息和教学成果。
导师界面,在这个界面中,导师可以设置要带的学生的人数,并且对选了他的学生进行挑选,点击学生姓名即可查看学生详细信息学生列表可按绩点排序,并且每轮选择结束都可查看学生的中选情况。
学生信息界面,在这里可以了解学生的详细资料和学习情况。
PSP:
PSP | |
---|---|
计划 | 估计这个任务需要3周的时间。 |
开发 | 分析需求:实现双向选择系统,解放人力并提高分配效率。 |
生成设计文档:md文档。 | |
设计复审:因为结对编程,和队友都在讨论审核最适合的模型。 | |
具体设计:根据实际情况,一步一步完善起初的设想。 | |
测试:设计完,让一些用户进行测试查看是否存在不合适的地方。 | |
报告 | 由于结对编程,所以报告由双方共同讨论完成。 |
感想:
阅读完《构建之法》后,对于一个项目的需求分析有了更加深入的了解,知道了NABCD模型,也和队友在摸爬滚打中完成了这个模型。第一次接触原型模型设计工具,感觉开启了新世界的大门。。设计完这个模型内心还是有点激动的,希望能继续进步吧。