结队项目——第一次作业
组队成员：031502533 熊立强 031502538俞鋆
一、客户需求简述
本次客户提出的需求，最重要的部分有两点：一是部门不知道学生的课余时间状况（包括申报其他部门），二是手工收集信息所带来的不必要的麻烦。
针对以上两点，都可以采用软件的形式进行解决，填写申请表时采用电子信息的方式，减少部门打印，发送，回收申请表的时间、人员的成本浪费。同时采用电子信息的方式，客户与学生用户还能够很直观的通过本软件，获取自己的课余时间信息，让客户能够在面试的时间了解到学生的课余时间状况，让学生在填写多份申请表时能够及时的获得反馈，在学生这一层次，就能够进行一定的思考，一定程度上减少了客户的烦恼。
具体客户需求如下：
【客户需求分析】
二、采用NABCD模型对客户需求的分析
Need 需求
第一象限：能够实现学生线上报名，查看报名情况，部长线上筛选报名的学生，可以根据学生的空闲时间和部门的活动时间计算出冲突，对学生选择的部门有限制。
第二象限：清晰的交互逻辑，友好的交互界面，在不同的手机上能流畅运行。
第三象限：能够自定义头像。
第四象限：部长发出通知时可以手机同步向部员发出短信通知，学生部门活动请假超过6次会提醒部长。
客户的需求分为三方面：一是面对管理人员的层面，二是学生层面，三是综合方面。
1.管理人员层面
需要一个无纸化，信息化的报名申请流程。在报名面试进行筛选的时候，对申请入部的学生的信息进行了解。有利于管理常规活动以及临时活动的一套方法。对部员能够进行有效通知。
2.学生层面
在填写入部申请表的时候，通过电子填表的方式，完成申请表。再填写第二份以上的申请表的时候，如果有活动冲突时间，会直接对学生进行提醒。
部员可以采用本软件进行接收通知，请假等操作。
3.综合方面
由于学生在加入部门前对部门的情况了解有限，同时部门对学生的信息情况也不是很了解。为了让客户能够不受这一方面的影响，对此我们采用了部门活动记录方式，向申请入部的同学展示部门的风采，以及常规活动。
Approach 做法
本产品主要通过对部门管理人员，与部员，和想要参与面试的学生进行一体化的处理，采用安装手机APP的方式，完成客户的需求。
Benefit 好处
- 采用手机app的形式，由于手机普及率较高，客户用户的使用会比较方便。
- 管理人员能够很明确的查看申请人的课余时间状况。
- 管理人员能够方便的查看申请人的擅长技术，已经兴趣爱好。
- 管理人员能够很方便的通过本产品，对于常规活动，以及临时活动，及时向部员进行通知。
- 对于学生请假的情况，学生能够很方便的通过本软件进行请假。
- 在学生入部之前能够对部门活动时间状况进行了解，以免自己的课余时间会同时被多个部门占用。
Competitors 竞争
优势
本产品的优势在于对管理人员的信息获取，在很大程度上解决了手工收发申请表的繁杂问题。对于电子化的信息，通过本软件也能够初步的筛选出，课余时间不足的同学。
部门之间信息流通。由于设定了常规的活动时间，以及面试时间，部门之间可以通过本软件查看其他部门的活动时间，对于有必要的部门，可以与其他部门进行协商，考虑是否更改面试或者活动时间。
管理人员的活动通知方式变得简化。只要使用本产品，在对常规活动进行通知的时候可以采用app的方式，对于重要的或者临时活动，可以采用本软件一键发送短信通知以及APP通知。
活动记录更加方便利于展示。考虑到学生和部门之间的双向信息不连通，针对部门这一层面，部门的管理人员可以在本产品中，对活动的记录，增加对活动的描述，让学生能够在加入部门前就对部门的状况进行一定的了解。同时对于学生这一层面，本产品要求学生在填写申请表的时候，再次描述对部门状况进行了解之后，为什么还要加入这一部门的描述。通过这一方式，学生与部门之间的双向信息交流变得更加得有效化。
平手
对于请假功能，部员在app中请假，达到六次后便被部门淘汰的功能，本产品与其他产品都能够轻易的实现。
劣势
本产品对于学生用户的体验性较差。
学生用户几乎只在填写申请表的时候有必要使用，但是对于入部之后，本软件对部员所起的作用就只有接收通知，以及请假的操作。这一功能与一般的社交软件没有区别，
Delivery
校内推广，通过在一些院级部门进行试用，让客户得到实际的效果之后，向校级部门进行推广。
三、原型系统
使用工具：Mockplus
- 首页，可以选择普通用户登录或部长登录
- 登录界面（用教务处的账号密码登录）
- 普通用户的开始界面，有热门部门、全部部门和通知，可以在开始界面搜索感兴趣的部门
- 点击具体部门会弹出部门的详细介绍，可以点击报名，信息以个人信息填写为准
- 普通用户通知界面分为面试通知、活动通知和冲突通知，冲突通知比较前两个通知得出
- 普通用户侧边弹窗，一开始为未加部门，子界面有个人信息，报名信息和设置界面
- 以部长登录开始界面，包括报名信息和通知
- 部长点击详情查看个人信息以及确实是否通过面试
- 部长可以在通知界面新增和修改通知
- 部长的侧边弹窗，显示所在部门和职务，子界面有个人信息、部门信息、报名筛选、管理部员和设置
- 部门信息，可以修改，需要写清部门活动和时间
- 报名筛选，部长可以按年级、面试部门数、学院、性别来筛选部员
- 部员管理，部长管理部员的界面，在部员的详细信息中请假次数在主界面就能看到，其他信息要点击详情，部长可以直接看到谁的请假次数达到6，达到6次，部长可以直接进入详情界面将部员淘汰
四、PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 26 | 33 |
| · Estimate | · 估计这个任务需要多少时间 | 250 | 400 |
| Development | 开发 | 200 | 300 |
| · Analysis | · 需求分析 (包括学习新技术) | 30 | 25 |
| · Design Spec | · 生成设计文档 | 20 | 20 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 10 | 10 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 15 | 20 |
| · Design | · 具体设计 | 30 | 60 |
| · Coding | · 具体编码 | 30 | 50 |
| · Code Review | · 代码复审 | 30 | 45 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 30 | 40 |
| Reporting | 报告 | 15 | 15 |
| · Test Report | · 测试报告 | 20 | 20 |
| · Size Measurement | · 计算工作量 | 240 | 300 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 25 |
| 合计 | 946 | 1363 |
五、 结对过程
讨论截图
六、 心得体会
031502533 熊立强 结对心得
这次的作业，我和结对伙伴的分工比较明确，先是共同部分，两人相互讨论了客户的需求，使得我们对客户的需求有了更清楚的理解。在考虑好客户的需求之后，我们之后分工合作，队友使用mockplus进行快速原形开发，在过程中，我也使用了mockplus进行文件的查看。我的工作则主要是对客户的需求进一步的分析，采用了《构建之法》中提供的NABCD模型，向客户介绍自己的产品。
对于结对编程，则是通过阅读，知道了其好处。 阅读后的收获如下：
《构建之法》 第四章：结对编程
在第四章的阅读过程中，从零开始逐渐加深对结对编程的理解，一开始我还认为结对编程并没有多大作用，看完这一章节之后彻底改变了我对结对编程的看法
《构建之法》第八章
在第八章的阅读中，作者一步一步地将读者带入软件需求分析。把软件需求过程中出现的问题都提点了一遍，对于比较重要的过程，作者更是用图文并茂的解说，讲解了几个常用的方法，非常易于理解。
031502538 俞鋆 结对心得
本次作业，我和熊立强同学一起完成，我们是同班的，又住在同一楼层，所以一起讨论很方便，但还是遇到了不少的麻烦，比如双方有空的时间刚好错开，讨论的时候有一些东西没讲清楚做出来之后才修改，同时做同一件任务浪费时间…… 庆幸的是我们有足够的时间一起解决这些问题。通过这次合作，让我了解到了软件开发中的原型设计，学会了使用原型模型设计工具，以后开发软件的过程中也会容易一些；同时，我也学会了如何与同学合作完成任务，受益匪浅。
