结对成员
071503427 张岳
031502341 张富华
用户需求
各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传；对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选，人工筛选留下的学生也面临被淘汰问题。筛选和淘汰的规则如下：
部门纳新人数和面试时间必须事先申报确定；
部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
如果一个学生常规部门活动时间请假超过6次，将面临被淘汰； 学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
未参加部门面试的学生不能纳入部门。
现状困扰的是：流程繁琐复杂，各个部门手工发放申请表，手工收集汇总，各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力。学生在加入部门前对部门的情况了解有限；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。
需求分析
N（need 需求）
学生客户的需求：
1.避免手写简历的繁琐，以及每次报名都要填一份简历的无奈。
2.能了解部门的基本信息、纳新人数以及面试时间。
3.能避免加入多个部门时，部门活动时间上冲突的尴尬。
4.能及时知道自己部门活动缺勤的次数，以避免被淘汰。
部门客户需求：
1.需要实时了解报名的学生信息以及简历状态（未审查/已审查）。
2.能准确了解部门成员、活动的基本信息发布与查看以及活动的出勤情况。
A ( Approach 做法)
我们这次的原型是基于web端设计的，先和结对小伙伴讨论出具体的角色和主要功能，然后开始制作原型，感觉墨刀比Axure更易上手，制作中也不断发现很多细节没有注意到，基本都是在边讨论边修改中完成的。
B ( Beneift 好处)
总体上极大的减少了人力、物力、财力的浪费，也减小了失误的可能性。
对于学生：
- 增加了对部门的了解，能够随时查看所有部门的介绍，不必担心自己因为不了解而导致后来的活动时间冲突
- 减少劳动量，不必填写多份简历
- 及时查看面试结果和部门活动情况
- 查看自己的出勤情况
对于部门：
- 减少部门成员工作量，不必手工收集，可随时查看报名情况
- 可在线发布活动
- 方便统计部门成员出勤情况
C ( Competions 竞争)
优势：界面简洁，操作方便，覆盖了纳新后部门和学生的后续活动发布和出勤考核功能
劣势：部门与部门之间的交流很少，部门在筛选学生时的功能有些繁复
D( Delivery 推广)
先通过几个部门试用，收集使用反馈，改进后可面向全校推广
原型介绍
总体需求
登录页面（可通过角色的下拉框选择学生/部门）
注册 和忘记密码页面
学生需求
填写简历
了解部门信息（学生应简要了解部门的基本信息、部门本次纳新人数以及部门面试的准确时间以及部门常规的活动时间。），点击部门还可进一步了解详细信息
部门报名（不同时间段页面显示内容不同，可进行报名，修改报名，查看面试结果等）
点击提交简历时时若活动时间冲突系统会给出提示
成为部门成员后可查看自己部门的活动
及时了解自己的出勤情况
部门需求
查看收到的简历以及当前状态
部门活动页面，还可在线发布新的活动
部门成员考勤页面
psp表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| · Estimate | · 估计这个任务需要多少时间 | 20 | 15 |
| Development | 开发 | ||
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 75 |
| · Design Spec | · 生成设计文档 | ||
| · Design Review | · 设计复审 (和同事审核设计文档) | ||
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | ||
| · Design | · 具体设计 | 240 | 300 |
| · Coding | · 具体编码 | ||
| · Code Review | · 代码复审 | ||
| · Test | · 测试（自我测试，修改代码，提交修改） | 60 | 120 |
| Reporting | 报告 | ||
| · Test Report | · 测试报告 | ||
| · Size Measurement | · 计算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 25 |
| 合计 | 410 | 510 |
心得体会
结对照片
张富华
对于第一次组队完成作业的我来说，怎么样和队友交流思想其实挺困难，因为有些东西不知道怎么去说，去表达。就像这次的系统，刚开始他写的时候我就看了，只不过总感觉缺了点什么就是说不出来，直到写这篇博客的时候，刚开始没有思路，不知道怎么去写，当第二动笔之后，慢慢地我把自己当成了客户，在写“学生客户需求”和
“部门客户需求”的时候，一直在问自己： 如果我是客户，我会想要什么功能？ 当我回到开发人员的位置时，我又会想：
我该怎么实现客户想要的功能，同时让客户感觉到方便，舒适，能让他们由衷的选择我们。
后来，在两种角色的不断转换中我不知不觉地完成了博客，还不等客户反馈，在写博客的过程中我就逐渐发现这个系统的不足之处。
同时，我也感觉到了写“做后感”的重要性，只不过，我觉得“做后感”应该提前写，也就是“做前感”，因为有时候客户也不知道自己想要什么或者粗略地知道自己想要什么，有或者像这次一样没有客户，这个时候我们就需要写出一个思路，并且在这写的过程中增加一些想到的可以使客户更加方便、舒适的想法。如果是在编程的时候想，我们就会在脑子里同时关注思想和工具而分散注意力，这可能也是为什么结对工作的原因吧。
感谢队友张岳的付出，我们下次一定会更好。 谢谢老师！
张岳
第一次完成结对作业，效果还是不错的。虽然之前有用过Axure这款原型制作工具，但是用了墨刀之后感觉更好上手，墨刀还可以多人协同修改感觉很方便。感觉需求分析真的是很重要的一环，我们在最开始的讨论中花费了比较长的时间讨论需求，好处就是后期做原型真的很省力。在制作过程中也在不断修改，突然发现即使是原型设计要考虑的细节也很多很多，难度也不亚于实现工作。NABCD模型也给了我很多启发。