学生与部门管理app-产品功能与界面的简单设计
学生与部门管理app-产品功能与界面的简单设计
1. 结对成员学号
我：*********
大佬：*******10
2. 需求分析（NABCD模型）
2.1 N-需求
各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传；对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选，人工筛选留下的学生也面临被淘汰问题。筛选和淘汰的规则如下：
* 部门纳新人数和面试时间必须事先申报确定；
* 部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
* 如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；
* 学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
* 未参加部门面试的学生不能纳入部门。
现状困扰的是：流程繁琐复杂，各个部门手工发放申请表，手工收集汇总，各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力。学生在加入部门前对部门的情况了解有限；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。
现在，现在，现在，我们很想做这样一个系统，请你和你的“对友” 设计一个原型系统，让部门选择的过程能够信息化起来，让学生和部门之间可以双向选择。
我们虽然没有参加过部门活动，但是我们对于时间冲突，那是有着很深的体会啊。我们课业繁忙，同时又揽了一堆的事情，到后面某一天发现这些事情突然挤在一起，像炸弹一样的爆发了。
这种问题并不像因为拖延而导致的压力剧增，因为拖延这些因素是可以通过优良的时间管理来解除的。而前面所说的时间冲突，在时间定下来的那一刻开始，就无法避免。然而，学生与部门管理者正是在一开始没有一个好的协调渠道，所以才酿成了后面的苦果。
所以，我们认为，所谓的痛点，就是在一开始就没有协调好双方的时间事宜。如果一开始协调好了，那么后面也就没什么事情了。
2.2 A-做法
我们设计了一个app，专门用来管理学生与管理者一开始的协调工作。这个协调工作在学生入会的时候进行。部门在自己的介绍页醒目的贴出自己所需要的时段，而学生根据此来选择部门。当学生进入部门的时候，学生的时间就得到分配，我们app的使命也就完成了。
2.3 B-好处
我们的app只做有限但重要的功能，这样我们的app就会更加的小巧灵活，用最少的功能解决用户的痛点。
2.4 C-竞争
我们的产品，直接对象就是福大的学生会，所以我们的对手就是我们福大需要做这道题的同学，我们自认为我们的app还不能登大雅之堂。
优势：满足关键需求、解决痛点，小巧灵活，实现快。
劣势：算法实现能力不足，可能速度会有点慢，功能少。
2.5 D-推广
我们会通过朋友介绍、直接向我们学校的学生会推荐、博客发布等方式推广我们的app。如果效果好了，我们就可以做进一步的推广，甚至让福州各大高校的学生会用上我们的产品（梦想还是要有的）。
3. 原型设计
3.1 角色说明
3.1.1 系统管理员
首先我们需要“第一推动”，我们一开始先预设一个系统管理员账号，这个账号要交到会长、或是特定的管理人员手中。
系统管理员登录后，可以管理包括系统管理员在内的所有账号。具体的功能有：创造系统管理员账号、删除任意一个账号（不能删除所有系统管理员账号）、改变某一个普通账号的级别（申请者/部员或是管理层）等。当发生特殊情况时，一般需要动用系统管理员。
3.1.2 申请者/部员
一个尚未加入任何部门的学生注册后，就成为申请者。
申请者/部员的主界面有如下特征：
- 搜索框：主界面下拉显示，可以搜索特定的部门、人员或职位。
- 部门信息：
- 如果该学生没有加入任何部门，则会显示“你还没有加入任何部门”。
- 如果该学生加入了一个部门，则会显示该部门的详细部门信息，包括部门介绍、活动介绍、活动时间等。
- 如果该学生正在申请加入一个部门，则除了会显示部门信息之外，还会显示通过状态、面试时间等信息。
- 如果该学生加入了多个部门，则可以在多个部门之间切换浏览。
- 申请列表：不可用。
- 部门申请：填写申请表的地方，超过申请上限之后则无法申请。
- 违规查询：只可以查询自己的违规记录，分部门显示。
- 各部门条目：显示该部门的详细部门信息，包括部门介绍、报名信息、纳新人数、面试时间、职能简介、活动时间、我是否为本部成员/我的职位等。
3.1.3 管理者
通过系统管理员对部员的申请，即可使部员拥有管理者权限。一般来说都是在部员升职的时候会用到这个功能。管理者有两种：会长和部长。
管理者的主界面有如下特征：
- 搜索框：与申请者/部员相同。
- 部门信息：会显示自己负责的部门的相关信息，还可以对此进行编辑修改。如果是会长级别的，会显示本会信息。
- 申请列表：会显示当前本部的全体申请人员名单。如果是会长级别的，会显示当前本会的全体申请人员名单。可以直接在本界面进行批阅工作。点击一个条目可以查看这个学生的相应信息。
- 部门申请：不可用。
- 违规查询：会显示当前本部的全体人员的违规名单。如果是会长级别的，会显示当前本会的全体人员的违规名单。点击一个条目可以查看这个学生的相应信息，可以直接踢人。
- 各部门条目：与申请者/部员相同。
3.2 业务流程图
如图所示。
3.3 系统结构图
如图所示。其中绿色为管理者特有，紫色为系统管理员特有。
3.4 实际效果
我们使用的工具是墨刀。
由于时间紧迫，我们做的原型会略有简陋、短缺，此中不足还望多多包涵。
演示地址
4. PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 28 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 28 |
| Development | 开发 | 800 | 615 |
| · Analysis | · 需求分析 (包括学习新技术) | 300 | 178 |
| · Design Spec | · 生成设计文档 | 300 | 148 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 200 | 289 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 160 | 105 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 10 | 7 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 150 | 98 |
| 合计 | 990 | 748 |
5. 结对过程
第一次结对的时候，也没有考虑那么多。因为那个时候我主要是在找团队，以及做一些七七八八的事情，结对这事也就暂时先不考虑了。然后泓立就进来我们宿舍，问我要不要一起做，我就同意了，就是这么随便。
我们的合作也是十分愉快的，主要战斗场地是泓立的宿舍。设计app是两人每个人各班一条椅子坐一起，七嘴八舌地讨论页面还有样式，然后在纸上画一堆丑到爆的草稿图。夜间的宿舍留下了我们
勤奋的背影
6. 结对心得和项目总结
- 我：我觉得一开始在草稿纸上的构思工作，是最爽的。感觉好像回到了小学制作纸上游戏的快乐时光。那个时候几个人围在一起，在纸上涂涂画画，这里是我方的城堡，那里是敌人……感觉自己在构建一个世界，真的有那种控制的感觉。这种成就感真是不可比拟的。后面实际制作app界面的时候，我反而没有那么热血了。一方面我其实本质上不喜欢扁平化的风格，觉得现在的扁平化都烂大街了，再也没有当初Win8刚出来那时候的惊艳了。另一方面我也觉得我自身设计功力有限，包括配色在内都不太满意，有些字也不满意，还要微调位置，太麻烦了，真的没有草图时期的那种畅快淋漓。我强行抑制住实现一切的冲动，先完成主要页面，不然时间可能不够。但是总的来说，合作还算愉快顺利。因为不能设身处境，没做过部员，所以我们也知道我们做的也不够好。不过，有努力就好了吧，这次合作使我重新看到了我体内时隔多年的、重新燃烧的热情，这才是更重要的。毕竟，曾经在无尽的代码题海中自我放弃的我，最需要的就是热情。
- 大佬：这是第一次结对合作，初尝二人组合分工合作的滋味，收获颇多，学习了使用墨刀设计原型系统，不必再自己去写一个APP框架，让投资方能第一时间看到产品成果，我认为这次的合作是意义非凡的。
