031402203 陈齐民
031402505 陈少铭

需求分析与原型设计

需求分析

N（Need, 需求）

在分析客户的现实困扰后，我们总结提炼了以下几点用户的痛处所在：

• 收集信息的过程十分繁琐， 需要班级先收集，后汇总给年级负责人，再汇总给系负责人
• 对于导师不够了解，没有导师的相关详细信息，无法选择自己感兴趣的方向的导师
• 导师对学生也不够了解，导师不知道学生需要什么帮助，有何兴趣爱好，希望往何方向发展
• 传统的导师选择操作不便，系负责人只能excel表用某种复杂而说不清道不明的人工排序和算法分配
• 导师分配不平均，某些同学可能被分配到非他五个志愿的导师

A（Approach, 做法）

我们决定开发一个安卓客户端 (其实web端的更好用，但是我们两个人前端都不是很好..)，对总结的用户痛楚进行逐一解决，让选导师和导师选更加方便：

• 学生用学号注册，登录后选个五个志愿的导师（如果教务处提供API最好了！）
• 查看导师信息，学生可以选择自己方向的导师，并查看他们的详细信息
• 填写自己的专长/兴趣/方向，导师筛选时可以查看学生的专长/兴趣/方向，是否契合自己的研究方向
• 采用安卓客户端方式，学生和导师有不同的操作界面，操作简便 (下拉看原型设计)
• 系负责人不可言说的权利，系负责人可以看到各个导师的学生分配情况，若存在无选中导师的学生，可根据导师的学生数进行适当调整

B (Benefit, 好处)

肯定是好处多多啦：

• 信息收集方便，年级负责人再也不用担心要收集表格信息了
• 导师学生相互了解，学生：“blablabla，这老师好酷！”，导师：“I want you！”
• 解放系负责人，系负责人：“哈哈哈我终于可以不用手动分配导师了”
• 操作简单方便，这个APP好酷炫好喜欢

C (Competitors, 竞争对比)

还有那么多结对的弟兄们在做选导师系统，竞争当然大了：

D (Delivery, 推广)

推广感觉现在只能先向身边的同学推荐使用

原型设计

通过前面的NABCD模型分析之后，我们总结了客户的需求并且提供可行的优化步骤，以下是我们做出的原型模型：

1. 所采用的原型模型设计工具：MockingBot
2. Markdown工具：Mou for mac
3. APP原型模型：

登录界面

登录用户登录之后，根据账号进入不同的入口，学生进入学生页面，导师进入导师页面；注册时学生需要使用自己的学号和身份证进行实名制注册（教务处提供API就无须注册了，但是教务处貌似封杀了一切）；以下是注册界面和登录界面：

学生端界面

主页学生主界面为导师选择界面，学生需要选择五位导师和自己的教务处总绩点，还可在技能特长填写自己的兴趣爱好专长方向等等优势，无需年级负责人收集表格，只需要学生进行下图为主页界面；

导师信息导师信息页面可以查看学生自己方向的所有导师列表，点进去后可以查看对应导师的基本信息、履历和研究方向，便于学生根据自己的兴趣选择导师，也可以看到该导师接收的学生数，妈妈再也不用担心我稀里糊涂一脸蒙逼的选择导师了，下图为导师信息界面；

个人信息学生可以个人信息页面填写或修改自己的个人基本信息，也可以编辑自己的个人履历，方便导师的查看，满满的履历导师快选我快选我，下图为个人信息界面；

设置设置页面可以设置是否推送中选信息，版本更新提醒，可以检测最新版本，下图为设置界面；

导师端界面

主页导师主页面为已选该导师的学生列表，列表的顺序按照学生的绩点降序排列，导师可点击cell查看对应学生的信息和履历，可选择该同学是否为自己的学生，点击提交则通过学生的导师选择申请，“I want you！”下图为主页界面；

你的学生导师在你的学生页面可查看自己的学生列表，点击某学生可查看他的个人详细信息，通过搜索bar可查找学生，下图为你的学生界面；

个人信息导师可以在个人信息界面修改自己的信息、履历和研究方向，方便学生查看，导师也可以设置自己的学生数，学生可在导师信息查看该导师接收的学生数，下图为个人信息界面；

设置设置页面可以设置是否推送中选信息，版本更新提醒，可以检测最新版本，界面与学生端的设置界面相同；

4. (4) PSP

   PSP
   计划	估计这个任务需要3周时间
   开发	需求分析：简化导师学生双选的过程，提高导师选择的效率，减少人工工作量
   	生成设计文档：.md文档
   	设计复审：随笔是由两人共同讨论写成的
   	代码规范：代码格式整齐，变量尽量名词化，且采用驼峰法
   	具体设计：界面设计、数据库设计、代码逻辑设计等等
   	具体编码：Java + PHP
   	代码复审：因为是结对编程，所以可以不间断复审
   	测试：黑白盒测试
   记录用时	利用课余时间，大概2-3周左右的时间
   测试报告	根据黑白盒的测试结果写测试报告
   计算工作量	感觉工作量应该不大，利用课余时间还是足够的
   事后总结	可以边做边总结，在碰到问题的时候就记下来，最后总结也不会忘记
   过程改进计划

5. (5) 预期规划
   我们的方案采用安卓客户端的方式实现（如果有时间也会实现网页版），搭建ThinkPHP框架和MySQL数据库，使用Java+PHP实现；在APP的基本功能实现之后，对UI进行美化，优化用户体验，因为学生导师双向选择系统只有在特定的时间才会被使用，每年估计就一次吧，所以如果有时间，会在APP功能实现之后，进行网页版的开发，并尽力做到网页版的简洁易用。

6. (6) 小结
   以上需求分析和原型设计是在阅读《构建之法》后结合作业而写的，两人讨论了许多次，包括客户端和后台应该如何配合能够更加轻松地实现功能等，也考虑了许多在开发过程中可能会出现的问题，比如界面美观、算法优化等问题，求栋哥和助教带飞，指出方案的不足之处。
   //Markdown用了之后才发现真心好用啊，排版也美观简洁，看起来特别舒服，就是有一个很难搞的问题，在Mou上排版排的好好的，到博客就出现奇奇怪怪的问题，最要注意的就是空格和回车，多一个或者少一个排版就不对了。。比如上面的456，怎么改都不对

附:

1. 博客园的Markdown排版太简洁了不够美观，所以我们组用Mou for mac进行随笔的md排版，附上随笔的.md文件 需求分析与原型设计随笔.MD
2. 随笔的.pdf文件 需求分析与原型设计随笔.PDF