考前自救题库NABCD分析
考前自救题库NABCD分析
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021春季软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 团队项目-初次邂逅，需求分析 |
项目名称：考前自救题库(暂定)
项目简介：本产品计划完成一个多功能题库，包括航概、军理、数据结构等科目的学习平台。
N (Need 需求)
现阶段北航的大一大二同学在期末复习时经常会面对这样很多问题：航概、军理、数据结构怎么背题啊？航概APP怎么没有其他科目呀？怎么只有选择题呀？以上种种问题给烤漆中的同学们带来了很多困扰。
归纳一下目前的同学们在期末背题时会遇到如下的问题：
-
相关产品较少
- 当前市场上题库软件主要包括英语打卡和阅读软件，少有关于航概以及军理这些北航特色的答题软件
- 仅有的航概题库在同学中的知名度也较低
-
已有题库的设计功能较为欠缺
- 科目只有航概，题型只有选择题，只能对题目进行评论，不能回复
- 题型缺少标签，难以形成体系，用户不能针对性选择题目
- 没有用户社区，答题缺少趣味性，缺少交流功能
- 功能类型单一，用户背题时缺乏动力
同时因为使用纸质的相关习题集还需要自己购买，复习时还需要手动翻页查找。目前学弟学妹复习时基本都使用电子题库。
针对以上需求，我们推出了该题库小程序，提供多科目的各题型练习。其中使用标签对题型进行分类，提供社区功能让大家对题目进行评论和回复，增加排行榜和在线PK功能，实现友好交互，帮助用户更好地规划烤漆时间。
A (Approach 做法)
产品总架构实现前后端分离实现，具体分析如下：
- 前端：使用 uni-app进行小程序开发，在Alpha阶段预计需要重建五至十个界面。
- 后端： 使用 springboot 构建，如果需要做高并发优化，将需要更大的学习成本。
关于高并发优化方面我们可以尝试采用优化的后端架构，做缓存代理，使用squid，varnish，将经常访问的图片等静态内容缓存下来，提高访问速度；关于题库系统的手动和批量导入系统，我们使用形式化的数据集格式例如json之类，实现批量导入和导出，对于单个用户我们可以专门做一个页面，用户可以提交相关信息，手动输入，后台自动转化。
B (Benefit 好处)
为用户提供学习的外部激励：许多用户是在接近考期时火急火燎地去复习，本产品不仅能让用户在紧迫的时间中享受高质量的题库服务，还能通过趣味性、规划性的方式激励用户有计划地学习，让用户高效地完成复习。
C (Competitors 竞争)
目前类似的产品有微信小程序上的北航航概练习题库，但如同NEED阶段中中提到的，航概练习题库存在着诸多缺陷。
相比于航概练习题库，我们的小程序主要的竞争优势有：
-
提供排行榜功能，激励用户学习
-
像其他APP一样允许用户设置每日目标，自己给自己施加动力
-
题目的评价体系与评分系统，同时完善题目的讨论区功能，实现用户的进一步交互
-
给题目添加标签，针对错题对应的标签进行推荐。
-
增加类似于你问我答的PK功能，提高用户之间的互动性
修改
关于你问我答PK部分，我们希望大部分题目是新的自定义题目。那么问题就在与这个新题目的审核系统，我们的解决方案大致有两个部分.
一个是系统层面，我们可能会接入一个敏感词过滤系统(考虑使用现有api)，对新题目的内容进行初步的过滤，这样至少保证题目内容中没有一些垃圾词汇.
第二个是业务层面，我们考虑这个你问我答系统有一个预报名的环节，用户希望参与出题的提前将题目与答案发给后台，后台人工进行一些初步的筛选和审核，我们的这个你问我答的开放频率在日常可能略少，一周一次，考期可能会增加频率，约为一天一次，并且每次的题量不会太大（初步20题左右），然后我们的人工只保证题目符合主题，并且我们后台算法将等级高的用户的题目优先提供给我们的人员，这样的话人工的工作量就很少，对于答案的正确性保证，我们在的设计主要是，题目的生命周期结束（答题环节结束）后公布答案，用户觉得题目有问题可以进行举报，我们也会视情况基于被举报的出题人一定的惩罚，包括不限于降低用户等级，限制功能使用等等。
D (Delivery 交付， Data 数据）
交付：以推送的方式在学弟学妹的各大水群里宣传。
数据：在产品中进行问卷调查或采访产品的试用者。
修改
用户量评估： 我们的产品预计以安卓APP的形式发布，并且有PC端或者web端的后台管理系统。由于小程序备案较为麻烦，所以我们放弃微信小程序端，修改后技术栈不需改变，uni-app可以方便的发布在安卓端。
预计一周后的用户量有多少：
- Alpha版本：预计发布一周内产品的使用次数达到100左右
- Beta版本：预计发布以后一周内产品的使用次数达到300左右
以上均为累计用户数量，但是真正评价软件是否吸引用户，还是日活用户这个数值比较准确。我们希望大约在alpha测试阶段，就有用户在我们的应用上制定计划，并且尽量执行，正是考虑到这一点，所以对我们的程序来说日活用户可能更能反映出受欢迎程度。我们希望日活用户在50以上。
