原型设计(结对第一次)
社团管理系统
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群等社交渠道进行宣传纳新并且宣传提倡使用该平台,而学生自然而然的也就变成了用户。
二、产品功能结构图
![](https://images2017.cnblogs.com/blog/1221686/201709/1221686-20170922001411900-3128067.jpg)
三、原型设计功能界面展示
原型作品展示点这
为节省篇幅,有些功能不展开详细介绍,可点击上方链接进行演示。
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)