结对成员
031502109 陈文举
031502433 伍杰麟
客户需求
各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传；对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选，人工筛选留下的学生也面临被淘汰问题。筛选和淘汰的规则如下：
- 部门纳新人数和面试时间必须事先申报确定；
- 部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
- 如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；
- 学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
- 未参加部门面试的学生不能纳入部门。
现状困扰的是：流程繁琐复杂，各个部门手工发放申请表，手工收集汇总，各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力。学生在加入部门前对部门的情况了解有限；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。
现在，现在，现在，我们很想做这样一个系统，请你和你的“对友” 设计一个原型系统，让部门选择的过程能够信息化起来，让学生和部门之间可以双向选择。
需求分析
N(Need，需求)
-
新生痛点
- 等待被扫楼 新生获取部门信息的途径基本就是部门的扫楼宣传。然而总有没被扫到的楼层，因此而错失机会。也有新生根本不了解部门是做什么的，只看到许多部门在几天之内不停的狂轰乱炸，难免有些喜欢安静的新生会产生严恶之感。
- 信息不全面 通过扫楼，新生能知道的信息非常有限，也没办法横向对比，最后跟风报名，通过各轮面试后才发现这并不是自己喜欢的部门，体验极差！
- 冲突 有的新生会加多个部门，加入了才发现两个部门的例会时间冲突。 -
部门痛点
- 宣传费时费力 不止是新生会讨厌扫楼，部门本身也烦这件事，动用那么多人力物力，有时候还会吃闭门羹。
- 整理报名表 如此多的报名表整理起来相当费时，而且在通知新生面试时很容易发错号码，或是新生填写号码时笔迹没干导致看不清楚。
- 未知生物 部门对新生的了解也很不足
A(Approach,做法)
- 首先想到的是要做一个app，现在人人手机不离手，手机app是最好的选择。
- 分为两个客户端，学生登录学生客户端，可查看部门的纳新信息，线上填写报名表，接收部门的消息。部门登录部门管理客户端，管理纳新情况，发布社团最新消息，记录活动出勤情况。
B(Beneift,好处)
- 对于部门来说，可以省下很多时间，还有宣传的费用。
- 对新生来说，可以更全面的了解部门，不用再盲目选择。
- 对学校来说，传单减少了，减轻清洁人员的负担。
C(Competions,竞争)
- 优势：操作方便，功能较齐全
- 劣势：最主要的功能还是纳新，纳新完可能就没什么人用了。我想消息的通知还是QQ和打电话更快更便捷。
D(Delivery,推广)
先让部门试用，如果部门认可，就可以通过学校官方宣传，像是给新生发的新生手袋里加张传单，以及易班、教务通等官方app的推广。
功能介绍
使用工具：Mockplus
首先是登录和注册界面，部门登录和学生登录类似，就不贴了
这是学生端的主页，简单的列出已加入部门和申请中部门的情况
这是四个主要页面之一的可申请部门列表。点击某个部门后可以看到部门的详细情况以及部门以往的活动风采，点击申请表即可填写线上报名表。
动态与通知页面，社团端有相应的发送消息功能
社团端的主页，可编辑，相应内容会出现在学生端浏览可申请部门列表里面的社团情况中出现，是社团的门面。
纳新系统，用于管理纳新情况。可在此页面管理新手的面试情况，是否将其淘汰，点击调整时间可调整面试时间。
部员管理页面，部长可在此页面发送消息给部员或者干部。在人员变动页面里可更改部员的职位，根据缺勤情况淘汰部员。
考虑到纳新完这个app的价值大大降低，我们加入动态的功能，各个社团可以在此页面发布自己社团的近况以及活动的宣传。
心得体会
陈文举：这是第一次和别人一起完成设计类的作业，有点不适应。小伙伴这一周部门纳新特别忙，所以我必须担任领航员的任务，这也在一定程度上改变了我爱拖延的习惯。最大的体会就是领悟到需求分析的重要性，虽然花了很多时间，但是大部分时间都在卡壳，纠结功能到底怎么改比较好，进度相当慢，磨刀不误砍柴功这句话真是不假，分析不够透彻做起来很是难受。这次的作业也让我知道了合作的魅力，让我一个人做肯定很多细节想不到。同时也初步掌握了一个新工具（做一半才发现这是试用版，一些高级功能根本用不了。。。），虽然看了大家的博客才知道有更好用的。。。总之，这次合作还算顺利，收获也蛮大的。
伍杰麟：在这次结对作业期间刚好遇到部门纳新了，所以这次作业多亏了搭档的引领，也还好这次作业的作业量并不是特别大。我们的合作模式是互相对需求（学生端和社团端）作出自己的理解并且最后整合在一起，充分的整合了两个人的想法。在想具体的功能的时候要设身处地的投入进去，才能想出实用且合理的功能，在此次合作的过程中，更多的体会是“咿~你的角度我没有想到！”所以也深刻体会到了结对合作的重要性，同时也可以延伸到团队合作还有与人沟通的能力。这次作业同时也学会用一个新软件：Mockplus 一开始以为要像VS的C#窗口任务一样做一个真正的窗口化项目。所以这也体验了软工的最表面的一部分，原型设计、需求分析。此次作业收益良多，更期待以后的作业任务中，能让自己有更多的提高！
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 20 |
| · Estimate | · 估计这个任务需要多少时间 | ||
| Development | 开发 | 300 | 450 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 120 |
| · Design Spec | · 生成设计文档 | ||
| · Design Review | · 设计复审 (和同事审核设计文档) | ||
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | ||
| · Design | · 具体设计 | 180 | 240 |
| · Coding | · 具体编码 | ||
| · Code Review | · 代码复审 | ||
| · Test | · 测试（自我测试，修改代码，提交修改） | 60 | 90 |
| Reporting | 报告 | 130 | 200 |
| · Test Report | · 测试报告 | ||
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 120 | 190 |
| 合计 | 440 | 680 |