原型设计（结对第一次）

社团管理系统

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