- 作业的摇篮
- pdf与结对作业演示
- 结对成员：031502530 王雨勤、031502501 蔡安琪
- 原型设计工具：Mockplus
- 使用该工具的原因：之前做项目需要做原型，就去知乎上查了一下，看到挺多人推荐mockplus就去下载试用，觉得使用感受还不错，简洁易使用，并且一些基本的功能也都能实现，还能导出脑图，演示程序和html文件，觉得挺好用的，就去开了年费会员，所以这次就接着用了(钱花了就不能浪费) —— @苏木木木
【Need——需求】
- 新生初来乍到，缺少充足的信息来源。各部门虽拥有经营良久的微博、微信、qq等公众号，但这些都是新生未能打通的消息渠道，部门纳新消息主要通过扫楼、通知群推送、纳新现场游说等方式传播，流通速度较慢，三言两语也不见得打动人心，且损耗大量人力物力资源。
- 从现状描述中可以看出，部门纳新主要的困扰在于学生与部门之间、部门与部门之间的信息不对称，申请阶段流程繁琐，资源投入产出不成正比。
- 需求细化：
- 部门资料公开，申请入部的学生资料对部门公开。
- 线上提交入部申请。
- 面试时间、部活时间冲突检测。
- 部门上限检测。
- 请假上限检测。
- 部门、学生双向选择机制。
【Approach——做法】
- 系统应用于Wed端，有学生版与部门版分别提供给学生与部门使用。针对上述需求，我们形成如下系统方案：
-
针对需求1——资料公开
- 学生和部门在创建账户时即完善资料，部门资料将展示在应用首页供学生查询浏览，学生资料在提交申请后允许部门查看。
- 学生可线上提交入部申请，部门可线上查看筛选。
- 系统在学生提交申请与每一次收到面试消息时，提醒学生是否有时间冲突。以及，为保证最终接纳的部员无时间冲突，强制同学在接到入部通知后做出抉择。
- 冲突包括：多个部门的面试时间冲突、多个部门的部活时间冲突、面试时间为非课余时间。
- 允许学生申请多个部门，只对收到入部通知的部门进行计数和上限控制。
- 学生每次不参加部活将记录在部门档案中，部门可查看和修改，达到上限时将被部门劝退。
- 系统设置最大面试轮数为三轮。
- 学生自主选择部门，可在每一次面试中自愿退出。
- 部门自主筛选学生，可在接到申请和每一轮面试中筛选淘汰学生。
【Benefit——好处】
- 使用本平台进行信息共享，能够：
- 完成学生与部门的互动
- 增进学生对部门的了解，促进部门间信息透明
- 协助部门线上纳新，减少线下物资人工损耗，大幅提高部门工作效率
- 减轻学生信息整合难度，避免信息错漏
- 待系统稳定后将进行完善，推出更多部学互动功能，实现部门工作与学生活动全流程信息化。
【Competitors——竞争】
- 我们在进行原型设计时，最大程度地参考了本校纳新流程，并为此做出适应，尽可能为用户提供最人性化的使用体验。
- 如：学生出于备胎心态可能选报多个部门，这个没中选还能去另一个，不必在报名时以最终上限封顶；部门面试时间分段分批，学生可选择性错开，或沟通取舍，无须因一时冲突而一刀切断等。
- 我们的开发成员也曾在部门纳新中摸爬滚打、斗智斗勇，熟悉校园纳新流程与痛点，拥有一定部门资源，便利推广。
- 看原型就知道，我们玩认真的:)
【Delivery——推广】
- 营销推广初期，采用一对一方式打开部门方市场，在迎新期集中向学生方进行推广，随各部门纳新消息的传开，我们的产品也将为更多人所熟知。
- 待打开市场后，可争取校方相关管理部门支持，从而实现自顶向下的推广，更快让更多同学认识和使用我们的产品。
- 在实现大规模应用后，不断跟进产品质量，提高服务体验，利用口碑营销，即可保证新鲜用户群体的不断更新涌入。
【我们的结对故事】
- 对舍的两只女队长不期而遇，从此相亲相爱成为幸福的结对伙伴。看图就知道我们有多恩爱:P
【遇到的困难及解决方法】
- 两个人对于题意各有见解，认为题目给出的淘汰规则不够合理，纠结于复刻现实细节与满足课程要求之中。
- 最终在尽可能保留现实中人为因素的前提下，满足课设要求。
【设计说明】
- 想知道更多细节欢迎查看百度云
-
登录
-
学生界面——查看部门
-
学生界面——我的部门
-
学生界面——个人中心
-
学生界面——个人消息
-
部门界面——部门管理
-
部门界面——部门消息
【PSP】
| PSP2.1 |
Personal Software Process Stages |
预估耗时（分钟） |
实际耗时（分钟） |
| Planning |
计划 |
240 |
120 |
| · Estimate |
· 估计这个任务需要多少时间 |
240 |
120 |
| Development |
开发 |
2010 |
1680 |
| · Analysis |
· 需求分析 (包括学习新技术) |
30 |
60 |
| · Design Spec |
· 生成设计文档 |
180 |
480 |
| · Design Review |
· 设计复审 (和同事审核设计文档) |
60 |
120 |
| · Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
0 |
0 |
| · Design |
· 具体设计 |
240 |
120 |
| · Coding |
· 具体编码 |
1440 |
720 |
| · Code Review |
· 代码复审 |
60 |
60 |
| · Test |
· 测试（自我测试，修改代码，提交修改） |
0 |
0 |
| Reporting |
报告 |
190 |
100 |
| · Test Report |
· 测试报告 |
0 |
0 |
| · Size Measurement |
· 计算工作量 |
10 |
10 |
| · Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
180 |
90 |
| 合计 |
|
2440 |
1900 |
【学习进度条】
| 第N周 |
本周学习消耗时（小时） |
累计学习消耗时（小时） |
重要成长 |
| 2 |
4 |
4 |
阅读《构建之法》，了解结对编程，学习NABCD竞争性需求分析的框架 |
【功能完善可能】
- 以下功能由于工程原因，未纳入此次开发目标，但作为可供改进的项目纪录在此。
- 部门纳新推送
- 部门活动推送
- 部门一键获取申请学生最有空的时间
- 消息接收确认时间范围控制
- 学生征信制度
