鲍亮 031402401 李陈辉 031402409
需求分析与原型设计
结对过程
我们是来自不同组的两个人结对，一起合作分析需求，解决问题，设计界面。
结对时讨论的照片：
分析原分配方案存在的弊端：
- 分配过程不透明，老师与学生无法了解分配的具体过程；
- 中间环节（系负责人）任务繁重，承担了所有的分配工作；
- 人工分配，易出现错误和主观性的不公平情况；
- 分配规则存在问题，可能不能达到理想的结果（令老师和同学们觉得公平且能够接受）；
- 师生对对方的信息掌握不足，缺乏信息获取途径
根据NABCD模型，我们分析设计出一个完整的方案
NABCD模型的介绍
- Need（需求）—客户需求是什么？
- Approach（方法）—要满足这种需求，我能够提出什么独特的方法吗？
- Benefits（收益）—该方法给顾客提供的便利是什么？
- Competition (竞争) —对于竞争对手和其他可选择的方案来说，优势在哪里？
- Delivery(推广) —如何把产品交到用户手中？
Need
客户需求包含以下方面：
- 让师生之间可以双向选择；
- 老师可以了解学生基本信息，学生可以了解导师的课题选择和研究方向等信息；
- 整个过程信息化，将中间环节压力转移到系统上；
- 优化分配规则；
- 提供分配信息及时获取的途径
Approach
- 原分配规则不能达到预期目的，也未实现师生的双向选择，优化的分配规则（保留部分原有规则）如下：
1）采取两轮分配规则：第一轮，由学生向老师（限制一位）发信息请求成为自己的导师，老师根据收到的学生请求，结合学生个人信息，选择想要的学生；第一轮中未被选取的学生进入第二轮，老师设定期望带的学生人数0-8之间且大于或等于自己第一轮已收的学生人数），学生提交五个平行志愿，分配遵循以下规则：每个学生最终必须被分配到有且仅有一个导师；每个老师最多带不超过8个学生；某些热门老师受大多数学生共同选择而溢出时，考虑学生绩点优先；尽可能满足老师设定人数的需求，否则每个老师分配的学生数尽可能平均；在最后情况下，某些同学可能被分配到非他五个志愿的老师，这样的情况希望越少越好。 - 提供个人信息、导师信息、学生信息的便捷获取
- 所有信息在系统上收集、处理、发布，减轻人工过程，实现信息化
Benefits
- 改变了原有的负责人处理模式，减轻了人工负担，也使信息处理更可靠、客观；
- 用户由客户端登录后，很方便地根据自己的身份（学生or老师）完成一些操作，如选导师，编辑个人信息，查看导师信息等；
- 及时获取信息，在导师结果公布时能很快速地获取
Competition
我方优势：
- 改变了原来的单轮选择模式，加入双向选择功能，更注重公平客观；
- 学生能够先了解导师信息后在作出选择，并可在限定时间内改变主意，老师也可以根据学生信息决定学生的收取；
- 学生选择时给导师留言功能，加强了双方的互动性；
- 界面简洁，功能简单，使用方便
我方劣势： - 教师评价系统的引入会更有利于导师的选择（设立讨论区）；
- 界面设计经验不足，也许不够有吸引力
Delivery
这个应用本身需要数据库支持，所以需要借助学校教务处，向各高校推荐使用该应用，达成合作，才有利于推广
原型模型的设计：
（1）登陆界面：
分为学生和教师两个角色登录，输入学号（工号）和密码即可登录到角色相对应的界面，当用户忘记密码时可以通过重置找回。
（2）学生端功能主界面。在界面的主体包括4个功能，分别是：第一轮选择，第一轮选择，个人信息和公示信息。底栏有4个按钮：主页、我的导师、个人信息、设置。主界面如下：
A． 第一轮选择界面。当在学生主页按下第一轮选择后就跳转到该界面。上方是搜索框，可以直接对教师的姓名进行搜索；主体部分是教师信息的介绍，包括教师的头像、姓名、简要的专业方向信息，可以通过上下滑动进行浏览。
B． 查看导师的详细信息。该界面提供了教师的详细信息的显示，具体包括教师的职称、研究方向、个人简介、联系方式（电子邮件）。下方提供了选择和返回的按钮。按下选择按钮后，就跳转到了选择并留言的界面。
C． 第二轮选择界面。在第一轮未被教师选中的学生可以进入第二轮进行选择导师。
（3）教师端功能主界面。在主体部分的功能分别是：选择学生（查看已经选中自己的学生信息名单）、我的学生（自己从选择学生中选取的学生名单）、个人信息（查看个人信息）、公示信息（教务处的通知等等信息）
A． 教师选择学生的界面。显示了学生的简要信息。点击某个学生将跳转到该学生的详细信息界面界面。下方提供选择的按钮。
（4）其他界面的介绍。学生教师界面提供了学生教师信息的详细介绍。
PSP与效能分析
| PSP | Time(Day) | |
|---|---|---|
| Planning | 计划 | 1 |
| Development | 开发 | 1 |
| Analysis | 分析需求 | 1 |
| Design Spec | 生成设计文档 | 1 |
| Coding Standard | 代码规范 | 1 |
| Design | 具体设计 | 1 |
| Coding | 具体编码 | 30 |
| Code Review | 代码复审 | 3 |
| Test | 测试 | 5 |
| Test Report | 测试报告 | 1 |
| Size Measurement | 计算工作量 | 1 |
| Postmortem | 事后总结 | 1 |
| Process Improvement Plan | 提出过程改进计划 | 1 |
效能分析
《构建之法》第二章介绍了效能分析的相关内容，由于我们还没有开发实际的APP，只能做到对设计部分的描述，做出时间的预估。选导师功能在截止时间之前可能由于大量用户访问造成服务器响应超时，这是未来可以着手优化的部分。
本文PDF附件下载链接: http://pan.baidu.com/s/1dEXmzPB 密码: fpz7