- 陈甘霖（031502604）——支队长
- 蔡鸿杰（031502601）——政委
- 曾玮诗（031502602）——二营长
说好的结对为什么这个队这么牛逼居然有三个人？因为支队长和政委都是大佬，需要二营长扛意大利炮！
2.原型开发工具
- 墨刀 MOCKINGBOT
为什么选择墨刀？首先，支队长政委二营长一致决定坚决服从老师助教指挥推荐，想提高用墨刀。其次，下载运用后你会发现墨刀对于APP的原型设计真的是体验非常好，其控件的拖拉、大小的调整，都会自然的去匹配相应的母版大小。无需去担心有多移动一点或多选择一点，减少了不少工作环节。
3.问题描述
-
选择部门的现状：
各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传；对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选，人工筛选留下的学生也面临被淘汰问题。 -
筛选和淘汰的规则如下：
- 部门纳新人数和面试时间必须事先申报确定；
- 部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
- 如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；
- 学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
- 未参加部门面试的学生不能纳入部门。
-
现状困扰的是：流程繁琐复杂，各个部门手工发放申请表，手工收集汇总，各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力。学生在加入部门前对部门的情况了解有限；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。
-
现在，现在，现在，我们很想做这样一个系统，请你和你的“对友” 设计一个原型系统，让部门选择的过程能够信息化起来，让学生和部门之间可以双向选择。
4.NABCD框架设计
N（Need，需求）
首先对于刚到校的大学新生，开学第一周新生活动已经让他们疲惫不堪。各社团以上门走访新生宿舍为核心，通过收发大量传单来引导整个纳新活动的形式会让部分新生失去对社团的兴趣和耐心。对于一些“不消费”群体我们听到部门新生的拒绝理由是有的是因为填写信息太麻烦，有的是因为太过疲惫不愿意接受学长学姐的疯狂“洗脑”，还有最重要的是新生对于社团的了解太少，而学长学姐们的介绍信息量过大，新生没有充足的思考时间，而胡乱做决定。他们更需要规范而优雅的方式提前了解社团的一切，并且有充足的时间去思考社团的舍得，对自己的选择有一个更合理的规划。避免因选择过多的社团而发生时间上和空间上的冲突。
其次，对于社团本身而言，大量的收发传单的形式本身工作量大而繁琐，加之还需要对部员进行一些必要的反馈，诸如面试时间，是否成功通过了社团验证。社团之间还缺乏足够的沟通，比如筛选社团成员时候需要综合对他们参与的部门数。
最后，在社团运营时，需要和社员或是其他社团有一些交互。他们需要发布一些及时的通讯信息，或者是与其他社团的必要沟通。
A（Approach，做法）
因此我们需要一个这样的简单易上手的APP来完美解决需求。我们考虑过网页的制作，但是相比于网页，APP的推送功能更加人性化，也具有更强的及时性。随时随地都可以享受到这样的一种近乎完美的服务。据我们的问卷调查分析，对于大一新生而言他们更加愿意使用一个方便的APP而不是去开一个繁琐的网页。当然APP制作带来的成本也更高，时间也更多。
B（Benefit，好处）
在这个移动互联网时代，手机已经成为了一个大学生，甚至说一个普通人的标配，因此运行APP的媒介几乎人人具备。对于新生，他们能够更加方便的去了解社团的一切，有充足的时间和同学舍友讨论社团的去留，对自己的整体方向也有充足的时间规划。对于社团而言，他们的纳新环节将大大简化，他们即时通信将变为一种可能，他们的后期管理也更加的方便。
C（Competition，竞争）
我们的优势总结起来就是简便与及时性，相比于网页更加的人性化，也更加容易让新生去接受这样的一个模式。当然我们的劣势是开发和维护APP的成本更高，需要花费更多的时间。
D（Delivery,推广）
对于推广，我们主要致力于在新生的入取通知书信封中展现，或者是新生报到时候宣传，还可以通过部门宣传。我们并不是完全排斥社团上门宣传的形式，只是通过一种方式让新生对社团有一个提前的认识，给新生晚上一些喘息的时间。
5.整体方案
学生用户界面：
-
登录界面
-
学生注册页面
-
学生登陆后首页有：“我的部门”，“所有部门”，“个人信息”，“活动”，右上角有部门个数限制提示，最多加入5个部门（如图中的3/5）。
-
点击中间下方“我的部门”-->“部门名称（比如组织部）”进入学生已加入的部门界面：里面有部长信息，通知，活动安排以及时间，可以在里面进行请假以及退部操作。
-
点击左下角“所有部门”-->“部门名称（比如社团部）”可以进入各个部门界面：里面有部门介绍，部长信息，活动安排，如果是未加入的部门可以在界面里申请加入部门。
-
点击“申请”会出现申请信息填写界面
-
点击右下角“个人信息”，可以进入并查看或者修改个人信息。
-
点击左上角“活动”可以看到自己所加入部门的活动安排，里面会显示活动是否冲突，是否请假等。
部门用户界面：
-
登录界面
-
点击“部门登录”后会出现所有的部门名称-->选择并点击你要登录的部门-->此时会弹出密码验证框，输入密码并确定进入页面。
-
进入界面后，有“部门介绍”，“部门管理”，“通知发布”，“活动发布”，“请假信息”等模块。
-
在“部门管理”模块中包含：“面试设置”、“申请信息”、“部员信息”：
-
点击“面试设置”，会弹出可设置的面试信息，可以设定部门纳新人数和面试时间以及介绍部门的常规活动时间等。
-
点击“申请信息”，会弹出申请加入部门的学生信息。点击学生信息，会弹出学生的申请表，未参加面试的不能纳入部门。
-
点击“部员信息”，会弹出部门里面包括部长、副部长、部员的信息。
-
点击“请假信息”，会弹出请假学生的信息，里面有记录请假次数，假如请假次数超过6次将被淘汰出部门。
6.总结
-
对于模型设计最关键的是，对于整个设计框架的构建，你的核心内容是什么（必须容纳老师的所有要求）。在设计APP上，我们尽可能考虑到每一个界面的跳转变换，以及状态的多种改变。但是，我们对于状态的多种改变和页面的转化，在实际设计框架的时候并没有真正
的深谋远虑，以至于我们在设计过程中还是不够连贯的进行，多次停下重新思考框架，也浪费了不少时间。 -
墨刀这个工具整体操作起来也是比较Easy的，所以在墨刀的学习上我们并没有花费太多时间，实际设计模型的过程中只是一些有很多
繁琐、重复的工作。 -
在设计模型上我们几乎费劲心思，参照了部分APP（例如福大教务通，支付宝等），尽可能以人性化的角度出发，去合理排版，虽然
只是一个简单模型，但是我们想尽可能呈现多功能和尽善尽美，但又不失简洁的初衷和本心。两者的权衡个人感觉至今都还未调和至极。 -
比较有意思的是，我们队的政委设计模型居然上瘾了，每次都老想添加更多的功能元素，墨刀设计7个小时根本停不下来，支队长不得不让二营长端上意大利面让政委尝尝。不过令人尴尬的是，三个大男人的色感实在有些僵硬，美工能力有待加强。
-
盛世美颜：
- PS：支队长和政委在商讨战略事宜，二营长除了扛意大利炮还得拍照纪实所以只能露个大拇指点个赞以示尊敬。
- PS：支队长和政委在商讨战略事宜，二营长除了扛意大利炮还得拍照纪实所以只能露个大拇指点个赞以示尊敬。
-
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 40 | 40 |
| · Estimate | · 估计这个任务需要多少时间 | 40 | 40 |
| Development | 开发 | 420 | 570 |
| · Analysis | · 需求分析 (包括学习新技术) | 40 | 50 |
| · Design Spec | · 生成设计文档 | 40 | 40 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 20 | 30 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 300 | 420 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 20 | 30 |
| Reporting | 报告 | 150 | 220 |
| · Test Report | · 测试报告 | 90 | 150 |
| · Size Measurement | · 计算工作量 | 30 | 30 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 40 |
| 合计 | 610 | 830 |