作者：031402209 黄伟炜 、031402230 张建明
需求分析
N:Need
- 选导师流程复杂不透明.需要班级先收集，后汇总给年级负责人，再汇总给系负责人
- 需要手动收集数据.调整分配.浪费时间和精力
- 老师和学生存在被动分配.老师无法选择学生.学生也可能选不到自己想要的老师
- 老师希望控制学生人数
- 学生希望了解老师课题和研究方向
- 老师和学生互相选择
A:Approach
- 移动端,程序设计在安卓
- 时间制,在规定时间内完成选择.类似教务处选课系统
- 多轮选择,类似教务处系统
- 互查信息,学生老师双向查看个人资料
B:Benefit
- 移动端简单便捷.现在比较适合使用的
- 不必争分夺秒.有充足的时间考虑
- 没选中下次还可以选择.实在不行也只能随机了(这也是没办法的事情咯)
- 知己知彼.加深老师和学生的相互了解
C:Competitors
- 千篇一律,都差不多
- 网页,安卓,ios都差不多
- 这个类似教务处选课.我觉得挺好的
- 安排多次选择.给学生更多的机会.这是不错的
- 现在已有的校园应用大用户量大，它们已经实现了一些学生需要的功能，如选课、查成绩等。它们的竞争力最强。
D:Delivery
这个估计没啥好推广的了，每年用一次。最好作为现在校园应用的补充功能模块
原型设计
栋哥说不能队内结对，于是就找到了班上的建明。然后，我们就开始了热烈的讨论。在几番他讨论之后，我们确定了需求。于是，开工
- 打草图
- 使用
Axure Rp设计
- 在原型设计方面，我们尝试了几款原型开发软件。其中，Fluid UI、和 墨刀 是网页应用，比较便捷，但是使用起来比较卡顿。最后决定采用
AxureRp - 注册和登陆界面: 因为，本次原型设计和主要功能师实现，学生和导师之间的双向选择。这个功能考虑应用时效性，这个应用不适合作为独立应用开发。最好是，整合到现有的校园应用（
福大助手、福大易班以及福大教务通）中去，作为它们功能的补充。因此，注册和登录界面可以忽略。而将精力放在要实现的功能模块 - 学生端:本着去繁从简的原则,登录之后的学生界面,有选择导师的界面.以及对每个老师的资料描述,学生只需要在规定的时间内选好自己喜欢的导师即可.
- 老师端:本着去繁从简的原则,登录之后的老师有修改界面.选择学生界面.以及对每个学生的资料描述老师先填好想要收的学生数量,已经学生选择导师之后,选择自己喜欢的学生即可
学生端
导师端
效能分析和PSP:
效能分析:
- 对象:移动端程序
- 目标:去繁从简
- 预测:可能出现的问题就是如何获取学生老师的数据。以及使用何种算法，来分配导师。同时，让导师也选中满意的学生。
PSP
计划
使用 java 语言进行服务器应用开发不熟悉，预计要四周完成开发
开发
- 分析需求。找到学生和老师之间互相选择的痛点。
- 生成设计文档
- 设计复审。初次，先讨论定好要实现的功能，做出原型。再对原型进行审核，对原型进行修改完善
- 代码规范。主要代码是在 android 端完成。而且 google android 的代码规范很优秀。因此，采用 google java 的编程规范（风格）
- 具体设计。按照原型设计进行实际编码开发
- 代码复审。对开发的代码进行复审，对代码进行重构。有利于代码维护和迭代
- 测试。进行单元测试
记录用时
记录流程中每一步的具体用时
测试报告
做真实的测试，获取测试结果并分析
总结&改进
完成任务后，对整个过程的遇到的困难和出现困难的原因进行分析和总结。然后，针对每个困难提出改进的计划。
小结
- 首次设计原型，对原型软件使用不熟悉。为了尽快实现原型，使用“暴力”`堆各种矩形和图标的方法，缺少交互效果。还需要深入学习使用
- 最后安利一下，windows 平台下的 markdown 神器 typora
- 作业附件：需求分析及原型设计.pdf