结对成员：
031502340 易伟航
031502312 黄阳正
原型构建工具：sketch
文档编辑工具：markdown
需求分析：
1.N(Need，需求)
- 对于部门来说，部门手工发放收集汇总申请表，通过这种方法收到的申请表质量参差不齐，这样的工作效率不仅不高，而且工作人员也会比较辛苦。这样做的目的其实就是让学生们了解我们的各个部门的基本信息，向学生们推荐自己的部门，而后通过人工筛选以及面试成功纳新实现新人换旧人。
- 而对于学生而言，在面对琳琅满目的部门的时候其实他们大多数人心里并没有明确的目标说一定要加入某个部门。而且当学生报了多个部门的时候，其实他们也不怎么会注意到部门彼此之间的活动时间是不是会有冲突。若是好不容易通过了层层筛选面试终于加入了某个部门，而这个部门恰好和另一个部门的活动时间冲突了，这样损失的不仅仅是学生个人的时间精力。
- 所以我们需要满足双方的要求。部门需要简化自身的工作强度以及难度，在自己的版块上完善自己的信息，供学生们参考，且能在该系统上通知一些部门消息。而学生们在了解各个部门后能在线报名申请，至于加入部门的要求或者部门之间活动时间的冲突在该系统上也会呈现。
2.A（Approach，做法）
- 在一开始登陆这个系统是需要账号密码的。而且每个部门都有一个专门的账号，一般这个账号由该部门的主要负责人管理，在这个系统上，会有部门的宣言，就像我们的QQ个性签名一样，部门需要编辑自己的基本信息，如部门的以前曾经举办过的活动，部门部长副部等等成员的信息，部门招收人员限制，部门的活动时间等等。而当有学生提交加入部门的申请时，部门的账号会收到这些学生的申请消息。一旦收到学生提交的申请信息满足部门要求的条件，这些人员会被管理部门账号的工作人员手动加入到待面试人员中，随后部门统一通知面试的时间地点，并在面试中筛选出人员，这些人也会被手动从待面试人员转移到部员的行列，其余淘汰的人员一律删除。部员的信息中包括了缺席的次数。（当学生加入了两个部门活动时间冲突的部门时，学生以及部门都会收到系统的提示信息，随后协商处理）
- 每个学生都有他们的个人账号，账号是他们的学号，初始密码是他们的身份证后六位（或者说可以注册自己的账号，不过账号必须是自己的学号，以便得知注册者的学生信息），而当学生加入了某个部门之后，学生账号上的加入部门个数的信息就会开始录入，加入一个个数加一个，一旦加入的部门数达到5个，系统就会提出警告，不能加入其他的部门，或者必须自行决定取舍，部门个数一定不能超过5个。学生上了该系统就可以看到校级院级的各个部门的纳新人数，部门活动时间，主要的活动形式。在里面只要学生看中了哪一个部门都可以直接发送申请，在发送的信息中有各个部门要求的不同的格式，所填信息的不同类型（比如自己为什么要加入这个部门，有什么爱好或者是执念吗，部门不是进了就随随便便退的，分布的任务也是要按时完成的，不能是不负责任，违反了是有惩罚的，比如说唱首送别歌吧），然后等待部门回信，通知面试信息或者是初审就没过的婉拒。没有经过面试，因为什么原因的放了鸽子的，除非有特殊原因可以加试，否则直接淘汰掉。
3.B（Benefit，好处）
- 对于部门而言，首先部门免去了向学校申请场地以及在场地搭帐篷等等的准备事宜，这样不仅能节省时间而且也提高了工作效率；其次，部门不用再忙着发传单（部门纳新的时候系统上和现实生活中的找人纳新类似，本来大家拼的就有宣传海报啊，以及口头描述部门优点等等方面，现在在系统上大家拼的也是创意，只不过创意是展现在系统上的，一旦有学生登录上该系统，系统就会给学生推送所有的纳新广告，学生选择自己感兴趣的部门进行深入了解），节省人力财力；最后，各个部门会更容易地进行彼此间的交流，而且当有学生成功纳入两个活动时间有冲突的部门时能够及时解决该问题，也避免了有其中一个部门会因为这个原因纳新人数没有达到目标。
- 对于学生而言，这样会让学生更全面地了解到学校各部门的信息，不会因为巧合错过自己喜欢的部门的宣传而与它擦肩而过，而且这样选择部门的效率会更高，自己的生活在这个特殊阶段也不会受到太大的影响（因为一般部门宣传要么就是扫楼要么就是在哪个场地设置帐篷）；其次，在系统上学生也可以通过部门纳新的人数以及该部门的待面试人员人数的比例大概推测出自己通过面试的概率，心里有个底，有一些自己比较感兴趣的部门也可以提前做好准备，不至于手足无措；最后，在报了多个部门时，你可以收到你已经申请的哪几个部门他们的活动时间冲突的警告信息，让你先做好心理准备。当你靠自身实力以及一定的运气成分，冲突的部门恰好都通过面试了，这时候系统就会通知你是时候做出艰难的抉择了，因为一旦部门活动缺席一定次数是会直接淘汰出部门的。
4.C（Competitors，竞争）
在这么多的系统中我们优势就是我们很专一，，目的很纯粹，这个系统就是用来处理学生与部门之间的事，并没有其他的比如加好友啊，成员发自己加入了什么什么部门的个人动态分享啊。
5.D（Delivery，推广）
推广的话，我们没有钱，所以我们不打算做广告。我们准备先杀熟。因为现在已经大三了，一些同学都已经是某些部门的部长之类的“大官”了，我们觉得走后门，先将这个系统展示给他们瞧瞧，从向一个个部长推荐到欠人情拜托部长将这个系统推荐给其他的部长，我相信只要我们的系统本身的实力够硬，这个系统还是会成功实现的。
原型系统：
-
在登录界面用学号可登录到个人账号，用部门编号可登录到部门账号。
-
通知栏可以查看最近信息，部门栏里可以点击查看所有部门的纳新信息，包括纳新人数、纳新时间、值班时间、例会时间，点击右上角可进入部门主页。可以在线提交简历，看到自己账号上收到的部门回复信息，而部门可以看到学生提交的申请。这样就可以节省时间成本，印刷成本，实现在线宣传、在线报名、在线通知。
-
第三栏是管理页面，里面是个人或部门账号里的包含的信息，可进行编辑管理。
-
在第二栏，即所有部门一栏，若部门右方有勾号，就代表你已经向该部门提出了申请，可点击info进入该部门主页。
-
当个人要申请加入某个部门时，点击该部门就可以获知该部门的纳新信息及部门活动时间等等，如果有兴趣就可以按照要求填写自己的基本信息提出申请，而后你就可以收到部门对你的回复，以及面试的地点时间安排。
-
在个人账号的第三栏，你可以看到自己参与部门的详细信息。比如你点开自己的活动安排就能看到自己什么时候需要到那个部门参加活动，绿色代表一般的值班安排，蓝色代表部门例会，黄色代表部门的特殊活动，红色代表你至少有两个部门在这个时间段有活动需要你参与，你可以详细地知道冲突情况。而点击你已经加入的部门你就可以进入该部门的主页。
-
你还可以看到自己已参加过的部门活动的汇总，以及在所有的部门缺勤记录。
-
下方只有5个格子，代表个人只能参与最多5个部门。
-
在部门账号的第三栏，和个人账号上的活动安排类似。但是这些活动显然都是本部门的活动，所以活动安排里没有红色提示活动时间与其他部门是否有冲突。
-
而点击部门人员也统计了该人员的缺勤次数，次数越多，用的颜色警示效果越明显。超过6次会面临淘汰。
-
面试结束后可以在面试人中选择参加面试的进入待录取页面。部门筛选后可以在待录取人员中选择录取哪些人员进入正式部员行列。这样可避免未面试人员被录取。
PSP 2.1表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 15 |
| · Estimate | · 估计这个任务需要多少时间 | 10 | 15 |
| Development | 开发 | 390 | 440 |
| · Analysis | · 需求分析 (包括学习新技术) | 30 | 40 |
| · Design Spec | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 320 | 340 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 30 | 30 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 20 |
| 合计 | 390 | 425 |
结对过程及结对照片
结对过程很简单，我爱他，他爱我
结对心得以及本次项目的总结
伟航结对的心得和本次项目的总结：和小正高中两年同班，高中经常一起踢球，配合还是很默契的，分工很明确，我们一起分析、讨论后，大概讨论出一个模型，画出草图，然后我主要负责操刀sketch实现模型图，他负责写文档阐述细节，然后一起汇总，整个过程很流畅很舒服。
阳正结对的心得和本次项目的总结：这次合作其实也没什么心得，因为和伟航也是老相识了，沟通流畅，合作起来毫无障碍，很舒服。而且这次的作业其实并没有什么实质的内容，只是做一个模型的东西，所以也没什么好说的。