社团管理系统
031502615 李家鹏
031502639 郑秦
原型设计使用 Axure Rp 。
一、需求分析（NABCD模型）
1.N（Need，需求）
- 流程繁琐复杂，各个部门手工发放申请表，手工收集汇总，通过一种说不清道不明的算法对申请的学生进行人工筛选。
- 各个部门之间信息沟通不畅，部门之间容易发生时间冲突，导致部员对部门活动的参与人数降低。
- 部门对学生、学生对部门的了解有限，部门完全不知道学生是什么样的，学生也不知道部门具体是做什么、有什么平时活动。
- 学生即使被部门选中了，也会被淘汰，学生最多加入5个部门，如果一个学生常规部门活动时间请假超过6次，将面临被淘汰。
2.A（Approach，做法）
- 使用web APP，由于该系统主要用户是部门，对于学生而言，纳新每学期就一次，可想而知使用频率非常低。此外，采用web APP可以实现跨平台。
- 部门通过此发布纳新信息后，学生可以直接查看，并且填写“入部申请表”，省去了平时手工发放的繁琐。同时，部门可在该平台上对申请的学生进行筛选后发布面试邀请。
- 丰富的部门信息，学生可以查看，增加对部门的了解。而部门也可以查看提交申请的学生的信息，增加对学生的了解。
- 学生信息大部分来自于教务处，保证了信息真实可靠。
- 学生在进行选择部门时，系统可以协助并给出是否有多部门时间冲突的提醒，防止出现被选中后还是被淘汰。而部门在发布时，可以查看彼此部门的发布信息，系统同样可以协助防止出现太多冲突。
3.B（Benefit，好处）
- 解放部门纳新时挨个进行扫楼的繁琐，学生也不会在纳新时期被部门频繁打扰。使用我们的系统，只需要在一些社交平台上发布，让学生进入该平台即可进行操作。
- 在这个系统中，有丰富的信息，可以让学生充分了解该部门。部门也能充分了解学生。
- 选择变得更加人性化，部门发布纳新时不会在像往常一样出现太多冲突，导致部员较少；学生选择部门时，也不再会出现存在活动时间冲突的部门。
4.C（Competitiors，竞争）
- 同类产品多，竞争非常激烈啊。
- 优势：
- 使用web APP，平台兼容性高，方便操作，无使用代价。
- 个人信息的数据来源于教务处，用户无需自己添加。
- 存在系统的辅助处理，用户无需太多复杂操作。
- 附加部门提供管理功能，额外减轻部门的管理代价。
- 劣势：
- 大量基础信息数据依赖于教务处，如果教务处不愿提供帮助，那就只能修改部分功能了。
- 界面设计上，无太多美化，长时间面对略显枯燥。
5.D（delivery，推广）
- 部门方面：在纳新开始前，与部门进行沟通交流，让他们知道我们的产品，并且帮助他们熟悉产品操作。
- 学生方面：鼓励部门纳新时转换纳新宣传方式，可通过QQ群等社交渠道进行宣传纳新并且宣传提倡使用该平台，而学生自然而然的也就变成了用户。
二、产品功能结构图
三、原型设计功能界面展示
原型作品展示点这
为节省篇幅，有些功能不展开详细介绍，可点击上方链接进行演示。
1.登录界面
- 学生采用教务处的账号密码登录，这里需要连接教务处端口。另外建立若干管理员账号，部门账号需由管理员进行注册。
2.学生模块
- 学生个人信息部分：qq号、邮箱、手机号、个人简介可进行更改，其余从教务处获取。
- 学生的我的部门部分：在这里，学生不仅可以查看该部门的关于自我的信息、部门公告，还可以提交各类部门申请。
- 学生的部门纳新部分：学生可以自我选择要查看哪些部门的大概信息。（红框内标记）
- 此外，在该部门，学生选择一个后，下方会有显示已选择的部门，左侧也会提示是否冲突
- 同时，学生可以点击某个部门，然后再弹窗中查看具体部门信息
- 学生可以查看近期通知，这里很多功能实际上做法一样，因此不展开详细介绍，只进行贴图
3.部门模块
- 首先是部门信息展示，可进行的操作如图按钮所示
- 部门的发布纳新功能。需要说明的是这里的申请由部门从本地上传，在日后可改进成如“问卷星"系统中”报名问卷“类型。
- 发布纳新以后，那么学生会对此进行响应，此时该系统具备了处理这些申请的功能，这里不仅可以查看申请学生的大概信息，还可以选择对哪些学生发出面试邀请
- 不仅可以进行批量邀请，也可以一个一个点击查看某个学生的具体信息，针对某个学生邀请，此外还可以选择采取邀请方式
- 部员管理这里不展开介绍，这边属于附加给客户的功能。若想了解，可进行演示
- 展示一个活动设置页面
- 近期活动中，部门负责人不仅可以查看近期发布的活动的大概信息，也可以点击某个活动查看具体信息，还可以对活动进行删除操作
4.管理员模块不进行太多介绍
四、PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 40 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 40 |
| Development | 开发 | 780 | 710 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 120 |
| · Design Spec | · 生成设计文档 | 60 | 60 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 60 | 30 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 600 | 500 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 90 | 80 |
| · Test Report | · 测试报告 | 30 | 30 |
| · Size Measurement | · 计算工作量 | 30 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 900 | 830 |
五、小结
ZQ：
- 一开始的时候，想的比较远，花了几天纠结于设计的功能下次结对编程要怎么实现，有些束手束脚。直到各个老师以及助教再三让我们安心，我们才大胆发挥想象去拓展功能。
- 首先，我对需求进行分析，提出对应的功能，而他思想比较缜密，考虑的比较全面，对其进行了(大量)补充。在画出草图及流程图后，我们使用原型设计软件分工负责相应模块。
- 但是，发生了一个“事故”。由于没有沟通好，我把他事先调好的页面大小给改动了，以至于两人花了一晚上重新修改- -，也算是一个收获吧，知道了实时交流的重要性，也使得我们对Axure的使用更为熟练。
- 通过这次结对作业，我了解到原型设计的流程，接触到新的软件Axure，学会了和他人交流协作，期待下一次自己的变化！
JP：
- 作业刚出来的时候，很不幸的遇上了第一次补考（周日= =），然后那几天我几乎没咋参与，让她去想了，也没有怎么沟通。结果就导致了在开始的时候两人想的方向有点不同。。
- 这是第一次非单人完成作业，体会到沟通的重要性。在进行需求分析的时候，考虑到主要针对的是纳新，为了方便性，因此就自己想着制作web APP，还好她也没意见= =（以后还是得保持沟通才行。。。先听听她说的） 。由于一直以来我也只做过桌面应用，然后担心后期需要具体真的实现功能，怕此时的原型设计功能过多的话，会做不出来，直到后面才开始大胆发挥想象。
- 因为一直找不到一个可以讨论的又不影响到别人自习室的地方（后来还是找到了个活动室），所以大部分时间都是通过远程一类的合作完成，这也导致了沟通上存在一定的障碍，远程、语音之类的效率还是不如直接到活动室。。
- 最后吐槽下我的审美- -，我的部分做完后，简直是不忍直视= = 都想砸电脑了。。。
（讨论中。。。。。。。）
[第一次结对作业博客内容附件.pdf](https://files.cnblogs.com/files/Reisende/%E7%BB%93%E5%AF%B9%E7%AC%AC%E4%B8%80%E6%AC%A1.pdf)