此次测试的机型有两款,以下的bug在两款机器上基本都有出现。
使用的软件平台为 微信6.7.3 ( Android ) 和 微信6.7.4 ( IOS )。
以下截图基本为iPad的微信上的截图。
许多问题已经超出了技术上的bug的范畴。
模块 | 优点 | 缺点 |
---|---|---|
数据量 | 部分功能直接链接网页,内容丰富 | 部分功能无法提供任何信息 |
界面 | 软件的整体界面整洁 | 部分操作逻辑较不合理,部分界面设计较不友好、美观 |
功能 | 能够查看主页、新闻等 | 1.部分功能不可用;2.部分功能存在bug,用户体验不够友好;3.直接链接网页影响响应速度 |
准确度 | 部分功能都能正确响应 | 部分操作存在问题 |
用户体验:用户体验很不友好,在界面布局、功能、反应速度等方面都或多或少存在着问题。
改进意见:将现有功能完善至可用,如可能,可考虑整合入学生管理功能。
结论:非常不推荐
大约一个月。
理由:功能较少,实现难度不高,但对于刚毕业的大学生,还是需要一定时间的。
具备主页、新闻、公告查看等基本功能,界面简洁。
部分功能不可用,部分功能存在较多bug,用户体验差。
对比同类软件:
主要是两类:一类是同为福大系的软件,另一类是同为微校系的软件。
相比于同为福大系的福大助手、福大教务通和福大一卡通等,本软件由于响应速度较不友好,所以身为微信平台企业号的轻便优势基本没有,更不用提许多功能不可用、bug众多等。
相比于同为微校系的软件们,我对比了暨南大学的微校号。暨南微校的界面友好,操作简便流畅,具有完整的校内通讯录,直通各位学生微信号,且整合有如请假审批、抽签、签到、学生工作、问卷调研等功能,用户体验良好。
模块 | 重要度 | 完成度 | 出发点 | 效果 |
---|---|---|---|---|
通知文件 | 非常重要 | 80 | 主要用于查看通知文件,公示以及校内公告 | 能够查看所需内容 |
福大主页 | 非常重要 | 75 | 主要用于查看关于福大的重要信息 | 链接向福大主页的网页,能满足要求 |
校园新闻 | 非常重要 | 80 | 主要用于查看福大的校园新闻 | 分为三类进行新闻订阅,可查看相关新闻,可搜索,可调节字体和设置夜间模式,较友好 |
福大邮箱 | 重要 | 75 | 主要用于登录用户的福大邮箱 | 链接向福大邮箱的网页版 |
福大黄页 | 非常重要 | 80 | 主要用于查看福大各部门电话号码 | 能够查看所需内容,操作简便 |
我的课表 | 重要 | 主要用于查看用户的课表 | 无法显示课表信息 | |
成绩查询 | 重要 | 主要用于查看用户的成绩 | 由于年份选择有限,无法查看绝大多数用户的成绩 | |
个人日程 | 一般 | 70 | 主要用于查看用户的日程 | 能进行部分基本操作,但bug较多,且界面不友好 |
移动OA | 一般 | 无法使用 | ||
失物招领 | 非常重要 | 80 | 主要用于查看、发布失物招领和寻物启事信息 | 能够查看、发布失物招领和寻物启事信息,操作简便 |
校园巴士 | 一般 | 70 | 主要用于查看校园巴士的运行信息 | 能查看到基本信息,但所提供的信息量较小,无法为用户提供有效帮助 |
讲座报告 | 重要 | 80 | 主要用于查看讲座报告的相关信息 | 能查看到所需信息,但界面设计和内容排版较不友好 |
学生证附卡 | 重要 | 主要用于查看、更新学生证附卡信息 | 能查看到部分信息,其他功能不可用 |
模块 | 打分 | 理由 |
---|---|---|
用户体验 | 60分 | 反应速度慢,且存在较多bug,用户体验不好 |
UI界面 | 70分 | 界面简洁,部分操作逻辑较不合理 |
核心功能 | 60分 | 功能略显单薄,一些简单的需求能够满足,许多功能无法使用 |
我认为需要提高的地方大致有量点:
首先是软件的质量问题,目前的用户体验还不够好。在试用和测试的过程中可以很明确地感受到这个软件在设计制作上的严重不足。若将其与功能齐全,制作也较为完善的福大助手或其他微校相比较,那根本就是云泥之别。从界面设计不合理到功能设置不完善,这款软件的app需要改进的地方有非常多,更不要说与对手竞争、吸引用户了。它连满足用户的基本要求都非常困难。没有谁会愿意浪费时间在一款并不便捷,使用体验也不尽如人意的软件上的。
其次是宣传。我们学校关于自己公众号和企业号的宣传基本没有。如果不是这次作业,我甚至不知道我们学校有这样的软件存在。这对于一款需要学生支持的软件来说是致命的,所以应加强宣传,提高在本校生,甚至在外校生中的知名度,这也有利于提高学校在学生中的声誉。
主要是两类:一类是同为福大系的软件,另一类是同为微校系的软件。
相比于同为福大系的福大助手、福大教务通和福大一卡通等,本软件由于响应速度较不友好,所以身为微信平台企业号的轻便优势基本没有,更不用提许多功能不可用、bug众多等。
相比于同为微校系的软件们,我对比了暨南大学的微校号。暨南微校的界面友好,操作简便流畅,具有完整的校内通讯录,直通各位学生微信号,且整合有如请假审批、抽签、签到、学生工作、问卷调研等功能,用户体验良好。
一个学生管理的功能。该功能可以协助学生工作,帮助学生和辅导员进行请假、节假日的审批。
目前我们学校的软件中还缺乏类似的功能。所有相关的审批和表格填写都需要人工在纸质假条、表格上进行填写,每次请假都需要填写纸质假条再交给辅导员签字,非常不便。
Need
现在我们学校的软件中还缺乏类似的功能。所有相关的审批和表格填写都需要使用纸质文件,耗时耗力,电子化是大势所趋。
Approad
添加一个审批模块,提供假条填写和记录、节假日去向填写等功能,并且不断完善。甚至可以添加电子化签名、存档等功能
Benefit
能够便利学生和辅导员的学习和工作,也让文件管理更加简便。
Competitors
目前校内还没有相关产品。
Delivery
对于这类校园应用,特别是这种嵌入学生、辅导员工作中的应用,首先必须得到学校的支持,之后的推广就比较简单。先通过老师或辅导员了解学校在这方面的意向,然后争取与相关工作的老师进行沟通。在获得支持后也要注重用户反馈,及时修复、增添功能,让软件能真正便利大家的生活。
经过这次的测试可以看出,该软件还比较简陋:功能少、部分设计不合理,还有存在很多bug。如果由我来领导团队,会更注重界面的美观和基本功能的可用性。
美工一人(包括UI和原型设计)
开发三人(前端两人,后端一人)
测试一人(开发阶段辅助后端)
周数 | 任务 | 里程碑 |
---|---|---|
1 | 确定项目内容与项目核心,进行需求分析,初步完成需求说明书 | |
2 | 完善需求规格说明书,明确分工,计划好接下来的时间安排 | 完成需求分析 |
3-4 | 搭建开发环境,制定编码规范,构建架构,进行原型设计 | 完成原型设计 |
5-7 | 开始主体功能的编码,美工完成UI设计,前端与后端并行,根据具体情况调整进度 | |
8 | 功能完善,测试,并改进 | 发布Alpha版本 |
9-11 | 开始其它功能的编码,完成接口设计,实现对接,完成剩余模块的任务 | |
12 | 继续完善各功能模块,初步完成正式版本 | 发布Beta版本 |
13-14 | 大规模测试,修复bug,根据反馈不断调整完善最终版产品 | |
15 | 编写用户手册 | 用户手册完成 |
16 | 项目部署,发布最终版本的产品 | 项目部署,发布最终版本的产品。 |
负载均衡:2台(主备)
应用服务器:16核32G 2台
后端服务器:32核64G 3台
关系型数据库:MySql 3个(读写分离2个,备份1个)
缓存数据库:Redis 2个(主备)
带宽:采用千兆以太网连接
原文:https://www.cnblogs.com/S031602240/p/10086483.html