结对作业
031502306&03150231
需求分析（NABCD模型）
N(need 需求)：
- 需求客户来自大学新生和部门：
- 简历互选阶段：学生和部门之间的双向选择方式太过于陈旧繁琐，学长学姐辛苦跑腿和解说，学生们也每天都要面对很多部门的上门安利哪怕是自己毫无兴趣的也要有礼貌的迎来送往，确实麻烦，而且信息也不全面，难以选到适合自己的部门，所以需要一个app可以节省大家的时间与精力。对于学生们而言可以在app上面细致的了解每个部门的面试时间（若面试时间和活动时间冲突部门简介需要额外说明）、纳新人数等细节，并且在每个部门的栏目页都可以看到附上了这个部门上几届的成果展览+带队学姐学长的照片+联系方式，然后在信息全面的情况下选择简历投向哪里；对于部门来说，他们只需要将自己的介绍做得真实、丰富而且花里胡哨可以吸引人就ok，剩下的就是慢慢筛选简历，向合适的同学发出面试邀请；
- 面试淘汰阶段：所选部门的时间不冲突+部门不超过五个+通过面试的同学可以直接进入部门享受快乐的大学生活，但是如果常规活动请假次数超过6次就会被淘汰。
- 目前没有人做这个app，所以这是一个全新的市场，需求量不小。
A:做法
- App界面采用简约漂亮的风格更适合年轻人的喜好。
- 学生和部门两种方式登陆：
- 学生：学号登陆。登录之后可以编辑简历、查看部门概况、投出简历、查看部门人气值（每个部门所收简历数）、接收部门的询问消息、面试邀请
- 部门：部长或副部可以登录，登录之后可以编辑“部门风采展”“纳新信息”，可以查看收到的简历，并且向同学发出消息以及面试邀请，面试过后统计每个部员的请假次数，达到预置次数自动删除
- Ps： 这些在模型中会有详细描述
B:好处
- 可以给双方在互选和管理阶段都带来很多方便节约时间和精力
- 学生更可能选到适合的部门，部门更可能选到需要的部员
- 一个收集部门发展期间精彩回忆的地方
- 并不占用多大内存
C：竞争
- 用户的需求基本可以满足
- 优势：该有的功能都有，不做没用的功能，节约开发时间，从而更早推出产品、占领市场
- 劣势：简约风格也许不能满足所有人的喜好
D：推广
- 向教务处网站申请广告资源
- 开学期间做公关活动：“扫码下载安装即送华丽开学大礼包”等等
- 在校园内张贴海报
- 发传单
- ~
原型系统
工具：墨刀
登陆界面
个人登录：
两个界面：查看和管理个人信息+查看和管理部门
已经加入的部门：
查看所有部门：
查看申请加入状态：
已加入的部门：部门签到+完成部门任务
psp表格：
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 100 | 120 |
| · Estimate | · 估计这个任务需要多少时间 | 120 | 120 |
| Development | 开发 | 300 | 400 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 100 |
| · Design Spec | · 生成设计文档 | 20 | 30 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 10 | 5 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 5 | 15 |
| · Design | · 具体设计 | 20 | 10 |
| · Coding | · 具体编码 | 10 | 20 |
| · Code Review | · 代码复审 | 10 | 10 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 20 | 10 |
| Reporting | 报告 | 10 | 10 |
| · Test Report | · 测试报告 | 5 | 5 |
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 10 | 5 |
| 合计 | 700 | 860 |