本次作业地址：结对项目——第一次作业
结对成员
031502537 叶己峰
031502518 练斐弘
需求分析
这次的结对作业，我们严格遵守了栋哥上课讲过的规则，即先定需求，规划，建模，越迟开始产品实现越优，因此，我们的准备工作做的较充分。采用了NABCD模型，首先分析了顾客需求，从部门和新生两个角度来考虑；其次是实现方法，采用web端实现，用mockplus制作界面。
0.题目大体要求
各个部门在开学初占据学校青春广场有利位置，通过张贴海报、发传单等形式向学生宣传；对某个部门感兴趣的同学，填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选，人工筛选留下的学生也面临被淘汰问题。筛选和淘汰的规则如下：
- 部门纳新人数和面试时间必须事先申报确定；
- 部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
- 如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；
- 学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
- 未参加部门面试的学生不能纳入部门。
现状困扰的是：流程繁琐复杂，各个部门手工发放申请表，手工收集汇总，各个部门之间信息沟通不畅，导致不少学生加入几个部门后，由于活动时间冲突而被淘汰，浪费时间和精力。学生在加入部门前对部门的情况了解有限；部门在学生申请之前对学生也不了解，稀里糊涂，不可言说，就接收了，导致后续配合存在隐患和困扰。
现在，现在，现在，我们很想做这样一个系统，请你和你的“对友” 设计一个原型系统，让部门选择的过程能够信息化起来，让学生和部门之间可以双向选择。
1.N——need需求
- 新生方面
- 新生想要申请加入某个部门，只能通过线下的纳新活动，如部门扫楼、摆点纳新，而无法线上报名；
- 新生对想要加入的部门，其部门职能和活动时间无从得知，了解部门信息的渠道狭隘或不便，如咨询学长、宣传单；
- 新生加入部门后，活动安排大都通过短信得知，但是其活动具体内容则不大清楚；
- 部门方面
- 部门纳新多在青春广场摆点，若要上门宣传则需要耗费大量人力；
- 部分部门由于人力匮乏，导致宣传力度不佳，报名人数较少；
- 通知学生来面试一般用QQ或短信，需要手动输入号码，效率低还可能出错；
- 部门纳新新成员时，通常无法 得知学生已参加的部门个数和他的空闲时间，一般要等到面试时询问；
综上，需设计一款软件，实现部门和新生在纳新上双向选择，同时满足以上需求，
2.A——approach做法
- 设计一个数据库系统，开发一个基于C/S网页系统，学生和部门可以通过账号密码登入平台，可以完成线上的交流沟通。
- 每个学生凭借学号和姓名注册唯一账号，然后部门注册需要联系网站负责人提交证明方可，保证真实性；
- 在这个平台上有双方公开信息，学生可以了解部门的职务，活动安排；部门可以了解学生的兴趣爱好和技能，可以查看这个学生与部门活动时间会不会冲突。
- 部门可以在平台上发布自己的动态，吸引更多新生参与加入部门，降低部门在宣传上的资源投入。
- 会记录所以部员的参与活动、请假的记录，方便同一管理
- 学生主页上会实时刷新已加入的部门的通知，点开可以查看详情，低下有参加/请假按钮；
3.B——benefit好处
- 学生打开手机就可以了解所有的部门和相关信息，通过手机就可以完成第一轮的部门申请；
- 部门通过这个平台，可以相互交流动态，也能够了解申请的新生在其他部门的纳新情况；
- 可以在这个平台上对成员信息进行管理
4.C——competitors竞争
- 整个软件界面虽比较单调，但是功能还是很齐全的；
- 操作十分简单易懂，很容易上手；
- 都是根据自己的经历，也有同学们的建议来开发本产品的，贴近实际需求；
- 而且比较满意的是增加了部门动态宣传和批量通知这两个功能，我们大一是作为新生去参加部门，大二是作为部员招收新成员，以我们经历来说在宣传部门和通知管理上都是比较花费时间的，
5.D——delivery 交付
首先邀请少数部门和同学使用这个产品，依据他们意见提出改进，如果一段时间后他们可以接受这个产品，那么我们会联系部门和校方力量进行推广，然后再慢慢往外扩散，扩大使用者的范围。
后期，会考虑使用第三方软件推广，放到一些免费的下载平台上供大家下载使用。
原型系统
1.使用工具
MockPlus（官网中有相应教程）
2.描述
设计如下功能结构，并通过c/s模式达到信息交互，实现纳新管理、部门活动宣传、活动安排通知等
3.图片
-
登录界面
-
学生注册界面
-
部门主页，学生可以通过这个主页来了解部门。
-
部员管理，部门可以通过这个统计部员信息，还可以批量通知部员活动安排，一旦有部员请假次数超过6次会有提示，可以发送淘汰通知。
-
纳新管理，部门可以通过这个纳新学生信息，通知面试安排。
-
部门动态管理，部门可以管理动态发布或者安排活动，系统会按格式把动态呈现在部门主页，起宣传作用。
-
部门安排活动，下拉框挑选参与人员，会筛选出时间不冲突的人。
-
学生主界面，通过这个界面可以了解部门活动，查看自己感兴趣的部门活动，加入部门后可以接到活动安排通知
-
学生请假界面，通过这个界面可以向部门请假，只要填写理由，而且每次会提示部员请假次数
-
参加新部门管理，可以查看到所有部门，并且查看到开会时间是否冲突。
-
对已加入部门管理，可以查看到自己已经加入的、退出的和申请被拒绝的部门，可以填写申请退部。
-
公开信息，我们每次参加新部门都有反复填写这些公开信息，很麻烦，直接作为自己介绍。
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 10 |
| · Estimate | · 估计这个任务需要多少时间 | 10 | 10 |
| Development | 开发 | 380 | 490 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 100 |
| · Design Spec | · 生成设计文档 | 30 | 30 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 30 | 50 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 20 | 30 |
| · Design | · 具体设计 | 180 | 210 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 60 | 60 |
| Reporting | 报告 | 70 | 70 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 20 | 30 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 50 | 40 |
| 合计 | 450 | 560 |
描述结对的过程
选择队友环节很简单，我们之前一起做过外包大赛，对彼此有所了解，虽然性格相差甚远，但是有过合作经验还是比较理想的。我们的完成周期大概是5天，第1、2天，在阅读完《构建之法》的相关章节后，我们一同进行了需求分析，我本身是学生会部长的，对需求有一定的了解，简单从部门和新生两个层面分析了需求，接着大致想了几种实现方法，结合mockplus提供的界面，选择了移动端的平板电脑界面作载体。第3，叶己峰先构建了博客的模板，让我们更清晰地认识到要完成的具体模块还有哪些，练斐弘做了个简单的数据库关系图，理清了几个数据之间的联系，初步定下来了APP的风格和结构框架。所谓磨刀不误砍柴工，第四天我们才真正开始实现界面的构造，这一部分主要由叶己峰完成，练斐弘后期修改，由于有了前三天的铺垫，在界面实现部分，我们做起来得心应手了许多。第5天，统计PSP表格并完成博客的所有内容。
心得体会
-
031502537 叶己峰
首先看到这个作业不需要编写代码，本以为应该会很轻松的，但是一上手就会发现很多问题，一些功能会反复斟酌是否要加上。特别是在需求分析和原型设计上，我们脑洞大开时会有一些争执和不同想法，可能会反复修改，这就非常的花费时间。当然了和队友一起设计一个可以使作品更全面，而且一些压力可以共同承担，这次的结队作业是一个非常新鲜的体验，我也从中收获良多。
-
031502518 练斐弘
这次的结对作业，我们严格遵守了栋哥上课讲过的规则，即先定需求，规划，建模，越迟开始产品实现越优，因此，我们的准备工作做的较充分。采用了NABCD模型，首先分析了顾客需求，从部门和新生两个角度来考虑；其次是实现方法，采用web端实现，用mockplus制作界面。我的工作主要是分析需求，建立模型，编写博客，并且在每一步完成后都给队友进行一轮审核，以改善。通过结对合作，我发现一个人的思路还是比较容易出现过于片面的问题，解决的方案较单调。通过和队友的讨论合作，产品的合理程度会大大提高。这次结对任务，我特地选择了性格跟我相差甚远的同学合作，想看看能碰撞出什么样的思维火花，一开始还担心合作中会出现矛盾，但从结果来说，还是比较满意的一次合作！