结对项目之需求分析与原型设计
031402304 陈燊
031401433 张斯巍
一、需求分析（NABCD模型）
1、N（Need，需求）
- 师生互选，改变导师被动分配学生的局面
- 每个学生分配到预想的导师，避免分配了志愿以外的导师的情况出现
- 学生可以了解到所有导师的课题和研究方向
- 导师可以设定自己想要的学生数
- 导师所分配到的学生数尽可能平均
- 志愿填写和导师的学生数设置均可在系统里完成
- 系统可根据志愿情况以及导师需求，通过一定算法得出最后的分配结果
2、A（Approach，做法）
导师选择每个学生大学四年只需做一次，固开发成单独的一个APP不是很理智的选择，我们小组采用的做法是开发一个基于Android端的导师选择系统，然后整合进现有的APP比如福大易班、福大教务通、福大助手等。这样在开发过程中便可以专注于主要功能模块的设计，而不用浪费精力在边边角角的界面上。
导师选择系统大致的运行流程如下：
-
学生和导师在第一次登录系统时便要完善个人信息，进行实名认证。特别要完善其对应的专业技能兴趣或则课题研究方向，系统将自动这些信息进行匹配，为学生计算出每个导师的推荐度，便于学生更有目的性得进行选择；
-
学生登录系统，在规定期限内填写并提交五个志愿的导师；
-
导师登录系统，在学生列表界面查看相应的学生信息，并选择自己想要的学生；
-
所有导师操作完毕之后，分配算法如下：
-
学生只有被一名导师所接受，将直接分配
-
多名导师选择同一学生，该学生将被分配给志愿优先级高的导师
-
剩余学生按照绩点进行排序，并依次检索其志愿，若对应志愿的导师已分配的学生数未满其设定值，将直接进行分配；
-
将导师按照已分配学生数升序排序，剩余学生依次分配给对应导师，以求尽可能让所有导师的学生数平均分布；
-
算法运行结束，导师分配完毕。
-
-
学生和导师登录导师选择系统，查看最终的分配结果，并联系其对应的导师或学生
3、B（Benefit，好处）
- 改变被动分配的局面，让每个导师参与学生的选择
- 推荐度的设置让学生选择导师时更理性化，更具指导性
- 导师分配结果大致符合学生和导师的预期
- 学生信息以及导师信息透明化，方便彼此的了解以及沟通
- 大大简化了年级负责人以及系负责人繁琐复杂的人工分配
- 每名导师所分配到的学生数量尽可能平均
- 互联网正在移动化，基于Android端的系统便于用户下载，实时查看导师信息和分配结果
- 学习成绩好的学生有更大机会分配到理想的导师，以此鼓励学生努力学习
4、C（Competitors，竞争）
- 目前学校的导师分配大都采用人工排序分配的做法，尚无成熟的系统可供使用，市场竞争小
- 潜在竞争对手可视为目前参加软工实践的学生，其中不乏有拥有丰富项目经验的优秀码农，他们全都在对“导师分配”这块大蛋糕垂涎欲滴
5、D（Delivery，推广）
- 当原型系统被采纳之后，立马投入精力进行开发
- 通过博客以及软工课程进行初期的推广，预期让所有修读软工的学生了解到该系统，并从学生角度出发期望得到建设性的意见
- 通过邮箱或则当面交谈，尽可能向学院所有导师推广这一个系统，并从中汲取到更为专业、更全面的建议并加以改进
二、结对过程
我和我的对友在之前便有过合作的经历，我有过一定的Android开发经验，而对友对前端的掌握也很好，故作业发布后不久我们便结对了。在整个导师选择系统的设计过程中，我主要是负责画原型，队友则是进行初期的草稿以及文档的完善。结对让我们效率更为高效，短短几天时间便完成了作业。
三、原型设计
原型设计工具：Axure rp 7.0
学生端
-
主页界面——拥有志愿填写、导师信息、个人信息、结果查询四个功能模块；
-
个人信息——每名学生均要进行实名认证，并完善自己的个人信息，尤其专业兴趣。这些信息在导师选择学生的时候将会起到重要的作用。
-
志愿填写——学生可以在这个界面填写自己的志愿信息，这些信息将在导师选择学生时起到关键性的作用；另外，在规定期限截止之前，学生可以任意修改志愿信息；
-
结果查询——在规定期限之后，导师选择系统根据算法分配导师成功。每名学生均可在结果查询界面查询到自己的导师以及相同导师的同学，并通过上面的联系方式互相取得联系，更有利于之后毕设工作的指导进行。
-
导师信息——导师信息界面可以根据推荐度、研究方向、学生数等进行搜索排序，而每一个导师都会根据学生以及导师的兴趣方向自动计算出一个推荐值，可供学生更加理性得进行导师的选择；
-
导师简介界面有着每一位导师完整的资料以及联系方式，学生可以通过联系方式与心仪的导师事先取得沟通，更有利于之后的互选成功率。
导师端
- 主页界面——拥有学生列表、个人信息、结果查询等三个界面。
- 学生列表——拥有待选学生和已选学生两个界面。学生填报志愿完成后，在待选学生界面，每位导师均可查看选中自己的学生信息，并决定是否接受。当学生被导师给选中之后，相应信息会传递到已选学生界面，并在后台进行相应数据得更新，让分配算法的运行更具准确性。而在已选学生界面，导师亦可通过侧滑删除的方法，筛掉先前已接 受的学生。
-
个人信息——导师可以在这个界面完善自己的个人信息，设定想要的学生数量以及研究方向，这些信息都将为学生选择时提供关键的指导作用。
-
结果查询——在规定期限之后，导师选择系统根据算法分配导师成功。每位均可在结果查询界面查询到自己的学生，并通过上面的联系方式互相取得联系，更有利于之后毕设工作的指导进行。
四、效能分析
| 内容 | 时长 |
|---|---|
| 需求分析 | 1H |
| 导师分配流程设计 | 2H |
| 手绘原型草图 | 3H |
| 用Axure RP进行原型设计 | 6H |
| 用MD进行文档编写 | 4H |
| 系统后期完善 | 1H |
因为客户的需求都比较明确，且自身也经历过导师选择，所以前期的需求分析还是比较明朗的，而导师分配流程则是和对友在互相激烈的辩论出得出来的。整个导师分配系统流程确定后，较为头痛得便是原型的设计，我们在稿纸上画了好多版的原型之后，才最终确定了如上图所示的系统。之后便开始原型设计和文档的编写。
整个过程大致用了17个小时，基本都是集中在两三天之内，工作连续紧凑，目的性强，期间也参考了许多其他同学的想法。整体的效率还是蛮高的。
五、PSP
| PSP | |
|---|---|
| 计划 | 预估时长为一个月左右 |
| 开发 | 需求分析：师生互选，系统后台自动完成导师分配，减少人工工作量 |
| 生成设计文档：.md文档 | |
| 设计复审：多次审核，共同讨论，确保原型的正确性和完整性 | |
| 代码规范：大小驼峰命名法；杜绝中文命名；适当采用单词缩写；见名知意 | |
| 具体设计：数据库设计、接口设计、界面编写、逻辑跳转等 | |
| 具体编码：Android、JavaWeb、PHP | |
| 代码复审：在开发过程中不断对系统进行完善修改 | |
| 测试：单元测试、黑白盒测试、BUG修正 | |
| 测试报告 | 利用测试结果进行测试报告的编写 |
| 工作量计算 | 预估服务器端的任务比较艰巨，需要实时更新信息，并运行分配算法给出最终的分配结果；Android端因为有过开发经验，界面之间的逻辑也较为简单，工作量较小 |
| 事后总结 | 暂无 |
| 过程改进 | 暂无 |
六、总结
导师选择是每个学生大学必将面临的问题，在几个月之前我们也完成了自己导师的选择，但是整个选择过程就如客户需求所述一样，高度不透明，繁琐复杂，分配结果也很难做到让每个人都满意。因此，开发一个透明化、智能化的导师选择系统是时势所趋，这次软工作业正好也给了我们一个时机去认真思考这个问题并努力解决。
在整个系统的设计过程中，结对的高效率得到了充分的提现，思想的碰撞让我们迅速得到的系统的大致分配流程，而各自的开发经验让我们对原型的设计以及文档的编写也是得心应手。互取其长，互补其短，我们在短短两天的时间内便完成了原型系统的设计。期间对Axure RP软件的使用以及项目的开发流程有了更深层次的理解。
虽然文档以至尾声，但我们并未将其认定为此次作业的结束，我们期待的是专属于我们的第三次作业的出现。斯是陋室，惟吾德馨。希望我们的原型系统能够得到您的认可！
