一、问题背景
开学初加入学生会部门的迫切需求——选择部门和课余时间冲突之烦恼
新生入学初，总会被学校、学院内各类形形色色的部门所吸引。但是，新生仅能从部门制作的宣传媒介以及自发组织的扫楼中了解到极少的关于部门的信息，若想要报名也需要自行填写纸质报名表并投递至该部门，报名流程与筛选流程繁冗。同时，新生由于新鲜感会同时报名面试多个部门，对自己所报部门职能是否重叠不够了解，部门对报名者自身的实际情况、所报选的部门数量也无法得知，无法让新生正确地在部门中得到锻炼，同时也会极大地增加部门未来的工作负担。这种现象在各大高校持续存在，新生的思维误区与部门的纳新工作对新生群体以及部门的管理者存在极大困扰。
二、需求分析－－NABCD模型
N（Need,需求）
根据客户的诉求，我与队友经过讨论，觉得做主要的客户需求就是部门管理信息化,以实现学生与部门间的双向互选。
以下为一些需求细节：
-
部门纳新阶段 ：纳新人数、纳新时间、纳新地点等都要提前申报确定，并通过这个平台发布信息，同时需要将部门的常规活动发布出来，以便让新生了解部门基本纳新情况。新生可在平台上提交自己的简历，根据部门的公告信息，参与部门的人工筛选（面试）。
-
部门管理阶段 ：学生进入学生会部门后，通过这个平台安排自己日常的部门活动。部门在这个平台上，发布部门的常规活动及临时活动内容，管理部员参与活动的情况。部门管理员还可上传部门的活动内容和总结，方便日后交流和纪念。
-
部门淘汰规则 ：这个平台需要实现学生和部门的双向互选，所以学生加入的所有部门对部门管理人员来说是完全透明的，若学生加入的部门超过5个，需要考虑活动时间的冲突次数。若学生在部门常规活动中请假超过6次，将面临淘汰。
A（Approach,做法）
-
设计移动端：移动端管理操作等都比web端方便实用。
-
设计两个客户端：
学生端：学生通过学号注册，填写自己的个人基本信息。在平台中找到各个部门的纳新信息，根据自己的兴趣提交简历报名，在该平台获取部门发布的面试等信息。加入部门后，学生还可获取部门的活动信息，形成方便快捷的安排自己的部门活动。平台还提供聊天功能，方便小伙伴之间的交流。
部门管理人员端：部门管理人员可在平台中发布部门的基本信息和特色，并发布纳新信息，让新生能够全方面的了解部门，增强新生报名的热情。后期部门活动管理也通过这个平台，可根据这些活动参与的信息，对部员进行奖惩，透明而公平。还可以上传已经办过的活动的资料和照片。
B (Benefit,好处)
-
部门管理信息化：无论是学生还是部门管理人员都可以方便快捷管理部门活动，就像课表一样～（再也不用去好几个通知群看消息，忘了这个，丢了那个，再也不会被部长骂了(´･_･`)）
-
各部门信息集中：学校各个部门的信息全都在一个平台上，信息全面，分类展示，学生可以看到尽览一切信息，再也不怕错过那个心仪中的部门了（啊！我要是知道这个部门！我也去面试了！后悔orz...）
-
部门奖惩制度透明化：平台上记录着部门中各个部员的活动记录，奖惩制度也公开透明（哼！看你们这群小崽子还敢不敢随便翘班！再翘班，学长学姐就不翻你牌子了(￣^￣)ゞ）
-
信息收集方便：新生报名信息直接在线上提交、统计，避免了报名表丢失造成的不便（哇！我再也不怕错过这群可爱的小萌新们了～_～）
-
部门资料集中管理：可上传部门的活动资料、照片等。（OMG!连部门网盘都省了！怎么会有这么好用的app！）
-
部门消息统一通知：部门管理员可通过这个平台统一发布部门消息通知。（耶！不用群发短信了！麻麻再也不用担心我的话费了（≧∇≦））
-
具备聊天功能：给小伙伴们提供增近感情的机会（来自学长学姐意味深长的笑容 嘿嘿嘿）
C (Competitors,竞争)
优势
除了作业要求中的五点需求，我们还增添了其他的功能：
-
所有部门的信息整合，且分类显示。
-
学生可以在平台上直接提交报名表，部门管理员也可以直接发布纳新信息。
-
部门管理员可以在平台上管理部员的参与活动情况，进行奖惩，还可上传部门的资料、照片，部门管理方便实用。
-
提供了部门人员之间交互的功能。
劣势
-
功能复杂，实现难度略大。
-
有些功能与现有的部门qq群的功能重复，推广有些难度
-
大家脑洞这么大，肯定还有比我们更有趣的想法。
D (Delivery,推广)
可以联系学校较大的学生组织，如校会、社联、校青协等，将我们制作出来的app二维码印在纳新宣传册中，扫码下载app，直接线上报名；通过运行微信公众号、制作H5宣传页等新媒体途径扩大宣传范围，迎合大学生群体的宣传需求，受众面大，接受的人数数多，推广力度较大，宣传效果也会很好～
三、原型设计
开发工具：墨刀
参考app：Teambition
原型介绍：
登录界面：两种身份（学生、部门）登陆方式,红色问号❓表示忘记密码操作。学生登陆后填写自己的基本信息，部门填写部门基本介绍。
部门端首页：
部门管理：部门通过这个功能实现部员的管理，包括纳新面试是否通过、部员奖惩情况。
活动发布：部门在这里发布部门活动、纳新面试信息等。
扫码签到：部门端生成签到二维码，提供给参加活动的部员扫一扫签到，方便签到制度的管理
部门资料：部门活动资料和照片在这里快捷上传
学生端首页
部门介绍：学生可以在这里查看全面的分类整理的部门信息，直接对自己中意的部门提交报名表。
活动行程：直接呈现学生不同时间段的不同部门活动，简单明了。
我的部门：查看各部门的活动情况。
我的：这个界面包括查看任务、文件以及自己收藏的功能。
任务：学生可以在这个界面手动添加部门会议中安排的个人任务 部门可添加部门近期活动计划
文件：学生和部门都可以在这里看到参与的部门活动资料、照片等,看到自己喜欢的文件可以添加到收藏中。
收藏：保留部门活动美好的回忆~~
通知：
- 学生在这里可以看到部门新发布的活动提醒，以及部门一些通知事项，并可直接表示参加或请假。
- 部门在这里可以看到部员的活动请假等消息，且若部员触犯了淘汰规则这里也会出现系统提醒。
聊天：学生和部员之间都可以直接在这里聊天，交流感情。
看了这么多介绍也觉得眼花撩乱了吧，不如动手一试比较直观呀～_～
(可以通过点击两个不同的身份进入不同身份界面哦～)
墨刀
四、PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时 | 实际耗时 |
|---|---|---|---|
| Planning | 计划 | 20 | 10 |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 10 |
| Development | 开发 | 440 | 320 |
| · Analysis | · 需求分析 (包括学习新技术) | 120 | 90 |
| · Design Spec | · 生成设计文档 | 60 | 60 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 20 | 20 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | --- | --- |
| · Design | · 具体设计 | 180 | 120 |
| · Coding | · 具体编码 | --- | --- |
| · Code Review | · 代码复审 | --- | --- |
| · Test | · 测试（自我测试，修改代码，提交修改） | 60 | 30 |
| Reporting | 报告 | 115 | 130 |
| · Test Report | · 测试报告 | 90 | 120 |
| · Size Measurement | · 计算工作量 | 5 | 5 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 5 |
| 合计 | 575 | 460 |
五、结对过程
照片
（我们都比较害羞，所以没有人入镜）
心得
李佳铭：第一次结队合作完成作业，两个人合作得还是挺顺利的，一共开了3次会，然后交流也是挺多的，这次结队作业让我认识到结队中多交流会让合作的项目更好更顺利。需求分析部分是极其重要的部分，只有分析透彻了，才会满足客户要求，让客户满意。而对于原型系统，从刚开始完全不了解它是什么，到后来我们也利用墨刀做出了一个原型系统，虽然做得不专业，但刚开始学可以做成这样子还是挺满意的，希望下次结队作业也可以和这次一样顺利。
黄若岚：经过这一次的作业，我收获蛮多的。学习到了NABCD模型需求分析报告的书写，也学会了用墨刀设计原型，我觉得设计原型挺有意思的，至少不用敲代码hhh。在与队友的合作中，我们互相交流各自的想法，把用户需求和原型不断完善，合作完成的原型设计功能还算完备，挺有成就感的。真的觉得原型设计的工作蛮有意思的！！！我喜欢！！！