1、结队成员
031502314—柯豪燊、031502306—陈晓凯
2、需求分析（NABCD模型）
N:需求
- 需求客户来自大学新生和部门：
- 简历互选阶段：学生和部门之间的双向选择方式太过于陈旧繁琐，学长学姐辛苦跑腿和解说，学生们也每天都要面对很多部门的上门安利哪怕是自己毫无兴趣的也要有礼貌的迎来送往，确实麻烦，而且信息也不全面，难以选到适合自己的部门，所以需要一个app可以节省大家的时间与精力。对于学生们而言可以在app上面细致的了解每个部门的面试时间（若面试时间和活动时间冲突部门简介需要额外说明）、纳新人数等细节，并且在每个部门的栏目页都可以看到附上了这个部门上几届的成果展览+带队学姐学长的照片+联系方式，然后在信息全面的情况下选择简历投向哪里；对于部门来说，他们只需要将自己的介绍做得真实、丰富而且花里胡哨可以吸引人就ok，剩下的就是慢慢筛选简历，向合适的同学发出面试邀请；
- 面试淘汰阶段：所选部门的时间不冲突+部门不超过五个+通过面试的同学可以直接进入部门享受快乐的大学生活，但是如果常规活动请假次数超过6次就会被淘汰。
- 目前没有人做这个app，所以这是一个全新的市场，需求量不小。
A:做法
- App界面采用简约漂亮的风格更适合年轻人的喜好。
- 学生和部门两种方式登陆：
- 学生：学号登陆。登录之后可以编辑简历、查看部门概况、投出简历、查看部门人气值（每个部门所收简历数）、接收部门的询问消息、面试邀请
- 部门：部长或副部可以登录，登录之后可以编辑“部门风采展”“纳新信息”，可以查看收到的简历，并且向同学发出消息以及面试邀请，面试过后统计每个部员的请假次数，达到预置次数自动删除
- Ps： 这些在模型中会有详细描述
B:好处
- 可以给双方在互选和管理阶段都带来很多方便节约时间和精力
- 学生更可能选到适合的部门，部门更可能选到需要的部员
- 一个收集部门发展期间精彩回忆的地方
- 并不占用多大内存
C：竞争
- 用户的需求基本可以满足
- 优势：该有的功能都有，不做没用的功能，节约开发时间，从而更早推出产品、占领市场
- 劣势：简约风格也许不能满足所有人的喜好
D：推广
- 向教务处网站申请广告资源
- 开学期间做公关活动：“扫码下载安装即送华丽开学大礼包”等等
- 在校园内张贴海报
- 发传单
3、原型系统介绍
工具：墨刀
登陆界面 注册界面：在登陆界面点击注册后进入
学生登陆后的界面——点击个人信息
点击我的部门——点击加入的部门，这里会显示部门最近的安排和任务
往后还可以提供活动签到、任务完成的按钮
在我的部门里点击查看所有部门
选择之后出现
选择其中一个部门：会有四个界面的部门介绍，在右下角可加入该部门
申请加入可能出现的情况：
而后可在我的部门，申请加入的部门里查看：
部门登陆（部门管理者登陆）
点击部门管理：有三个管理选项
点击出勤管理：有三个选项
在出勤详情里可以选择之前的开会日期来查看之前的出勤情况
在部门管理里点击部员任务可以发布任务和查看部员任务完成情况
同样可以查看部员审核情况
在部门登陆的初始界面可以选择部门展示进行编辑
一共有四个可编辑的界面
这四个界面与学生登陆界面里的查看部门界面类似，因此可以在一定程度上通用
4、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 |
5、结队过程
这次的结队过程也是刻骨铭心，一开始两个人都有各自的想法，在没有沟通好的情况下就开始动作做节目，导致做了许多无用功和要做大量的修改，后来经过了激烈的讨论并在deadline的逼压下终于达成一致，就像栋哥说的在编码阶段才修改的成本是很大的，以后要充分地沟通再进行下一步，稍微学习一下瀑布模型。
6、心得体会
这次的结对作业任务是比较有趣的，和小豪大哥不断地交流意见、改进设计的过程也很interesting！通过这次的合作，我要给出一个结论：1+1>2。通过阅读邹欣老师的《构建之法》，我了解了很多关于软件开发的知识和需要的态度，NABCD模型对于客户的需求以及开发软件如何去满足这种需求都进行了细致的分析。以往，关于软件的印象不过停留在自己关上门敲的那几行小代码上面，这次用墨刀工具做出来了和我手机界面类似的画面，这让我有了一种打开新世界大门的感受，离真正的软件工程，真正的做出项目，越来越近了，很期待接下来的团队作业！——031502306晓凯
这是第一次的结对作业，也是我第一次接触墨刀这个软件。这次的作业虽然磕磕绊绊，但是总的来说还是完成得蛮愉快的，首先在墨刀这个软件上可以随心所欲，一把组件拖到画布上就能马上运行看到成果，虽然一行代码没打，但是感觉就像是自己已经做出了一款APP，运行起来，点击按钮，页面之间的跳转还是很有趣的，虽说并没有多大的工作量，成果也有点简陋，但是还是很有成就感。和晓凯的合作过程也是越来越有默契，这将是一次宝贵的经验，让我更好地适应多人合作做一个东西，为以后的团队合作点明了方向。——031502314柯豪燊
-
