同学A : 031502630 - 吴松青
同学B : 031502644 - 邹星
第一次结对作业
本次作业的要求是设计一个方便部门纳新与学生选择部门的app，当然只是原型......刚开始怕要求实现的我们畏首畏尾，总得考虑到后期的实现的困难。最后老师提醒我们不需要实现后，我们也算是大展拳脚，做了个我们两都还满意的原型。接下来，就让我们进入这次作业。
目录:
一.需求分析 ( N )
1.作业背景
* 1.1.部门方面问题
* 1.2.学生方面问题二. 具体做法 ( A )
1. 需求分析图
2. 功能
* 2.1. 学生
* 2.2. 部门三. 产品带来的好处 ( B )
1. 学生
2. 部门四. 市场竞争分析 ( C )
1.竞争优劣势五. 推广 ( D )
1.面向群体
2.推广方式六. PSP
七. 总结
1.吴松青-031502630
2.邹星-031502644
一. 需求分析 ( N )
1.作业背景
各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传；对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选，人工筛选留下的学生也面临被淘汰问题。然而现在存在着许多问题（如下），我们很想做这样一个系统，让部门选择的过程能够信息化起来，让学生和部门之间可以双向选择。
- 1.1. 部门方面问题:
- 部门纳新人数和面试时间必须事先申报确定；
- 部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
- 如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；
- 未参加部门面试的学生不能纳入部门；
- 流程繁琐复杂，各个部门手工发放申请表，手工收集汇总；
- 各个部门之间信息沟通不畅；
- 部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。
- 1.2. 学生方面问题:
- 大部分新生不能确定自己的兴趣点，或者不知道部门是否适合自己；
- 对部门情况了解有限；
- 学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
- 不能及时了解各部门的常规时间冲突情况，而常规部门活动时间请假超过6次，将面临被淘汰 ；
- 1.1. 部门方面问题:
二. 具体做法 ( A )
1. 需求分析图
2. 功能
- 2.1. 学生
- 双登录界面
- 关键字搜索部门 。
- 可查看部门介绍、纳新信息以及日常活动，还可以看到前辈的留言哦，可以填写入部申请。
- 有个特色是有个专门的时间表页面，可以清楚的知道每天是否有活动，绿色代表有活动，红色代表活动冲突。
- 内附请假系统，若请假5次后再次请假将会提醒你已经请假5次。
- 消息通知页面有平时的活动通知以及请假信息是否被批准。
- 个人信息页面有我的部门（已加入的、待批复的、未面试的），还有请假管理。
- 2.1. 学生
- 2.2. 部门
- 能编写部门的具体信息，还能发布部门活动时的照片；
- 可以设定纳新人数、面试地点以及面试须知；
- 可以添加、修改、删除常规活动信息与临时活动信息。
- 有个消息通知页面，可以接收新同学的入部申请与部员的请假请求等。
- 在部门成员页面可以查看部员信息（包括请假次数），可以将部员踢出，也可以设置部员职位。
- 在学生申请界面可以查看申请的同学的信息与操作是否纳入部门。
哈哈！具体还要体验过才知道啊，以下给出我们的部门帮app原型链接：部门帮
三. 产品带来的好处 ( B )
1. 学生
学生
- 消息畅通，了解各部门，可选择自己喜欢的部门；
- 更加方便的向各部门申请入部；
- 对于部门面试时间和活动时间不会遗漏，可以提早安排自己的行程，避免时间冲突；
- 请假方便；
2. 部门
部门
- 流程简单，各个部门无需手工发放申请表，手工收集汇总；。
- 发布纳新面试时间时，将提示当前学校在此时间段也同时进行面试的部门，有利于面试时间的更改，尽量减少与其他部门的冲突。
- 自动按照专业归类申请学生，利于部门首次筛选。
- 考量期的应用，便于部门更好地淘汰部分不积极或者不适合该部门的学生。
- 记录学生出勤数及参与活动次数，采用积分制度，更好去了解统计部员对部门的贡献。
- 可更新部门动态，便于部员了解当前部门的活动及近况。
四. 市场竞争分析 ( C )
4.2 竞争优劣势
优势
- 功能较多，针对性强，比较实用。
劣势
- 色彩方面比较单一
五. 推广 ( D )
1.面向群体
- 大一新生与部门人员
2.推广方式
- 向入学的新生推广
- 向团委方面推广以便从上而下的推广到各部门，再由各部门推广给学生。
六. PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 20 |
| · Estimate | · 估计这个任务需要多少时间 | 360 | 400 |
| Development | 开发 | ||
| · Analysis | · 需求分析 (包括学习新技术) | 50 | 60 |
| · Design Spec | · 生成设计文档 | ||
| · Design Review | · 设计复审 (和同事审核设计文档) | ||
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | ||
| · Design | · 具体设计 | 120 | 160 |
| · Coding | · 具体编码 | ||
| · Code Review | · 代码复审 | ||
| · Test | · 测试（自我测试，修改代码，提交修改） | ||
| Reporting | 报告 | ||
| · Test Report | · 测试报告 | ||
| · Size Measurement | · 计算工作量 | 5 | 5 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 45 |
| 合计 | 585 | 690 |
七. 总结
吴松青-031502630
这次的结对作业的任务我个人感觉还是比较轻松的，因为之前有过设计原型的经验，所以没有太大的压力，但是这次是跟别人一起合作设计原型，肯定需要大家一起商量决定这个设计，之前是自己一个人做，所以想怎么设计就怎么设计。经过这一次的合作，让我体会了团队合作的重要性，也让我获得团队合作所带来的收益。先来说一下这次合作的过程吧，刚开始确定用什么工具与做需求分析是比较顺利的，但是总是要考虑自己后期做不做的问题，一直束缚着自己（虽然心里想着应该不会让两个人就来完成这东西吧）。最后得到老师肯定的说明之后，可以开始大展拳脚了。但是由于队友跟自己不在一间宿舍，所以后期的完成品的主题存在着一些差距，所以就不免要花一些时间修改了。说到这里，我还是比较佩服队友对于这个原型的想法的，我觉得他比我的想法多，所以最终两者的结合体就由他来完成了（恩，我是很放心的），然后博客就由我来写。一直合作的是比较愉快的，最终做出来的原型也比我一个人做的好太多了。总得来说，对于这次一起合作完成的作业还是比较满意的。
邹星-031502644
可以说这是我第一次和别人一起负责一个题目，并一起设计完成一个项目。确实是没有和别人一起的经验，一开始的设计讨论时，倒也是还好。经过讨论便已经分配好了各自的任务，我是负责学生端的那部分。到了这个步骤后，大家便各自回去搞自己负责的部分了。然而却是导致我们再过了几天后准备将各部分一起合并时才发现了。两个人的风格有差别！而且各部分细节的处理差异导致了我们两个做的很难合并为同一个app，于是没办法我只有将两个人的都进行了修改进行风格上的靠拢和一致。在这部分上也浪费了很多时间。总而言之，第一次结队可以说是有意外也有收获。而对项目的总结嘛，也是有很多话想说，本人是第一次接触设计，所以先是去学习了如何使用工具。然后也莫名的感觉挺好玩的。我们是经历过那个部门纳新的时期的，并且还可以说记忆没遗忘。所以对其的需求分析也算了解。在确定了不需要考虑实现的时候。我就开始设计学生端了。首先是对部门的了解，学生要加入部门肯定是要对有很多了解的。而这些信息的来源，我觉得就是部门自己的介绍和学长学姐的建议。所以我给部门的详细那加了一个风采展示环节和前辈留言。还有将消息留言特意做出了一个模块来。因为我感觉对于双方而言，相互的消息的即时了解是非常重要的。而在活动时间上，我认为较为是要区分有活动的日期和有活动但是活动有冲突。同时将请假申请放入在查看活动的界面中，个人也认为比较合理吧。其实个人也还有很多想法想去实现来着，但是也想到了一个问题，这个app的功能基本已经达到了，用户的需求已得到满足的情况下，如果我才继续加入一些比较鸡肋的功能的话，少且尚可，但是多了的话，只会让人感觉复杂和难懂。所以也就适当的放弃了。
