团队作业3--需求改进&系统设计
小学生四则运算练习软件APP
一、需求&原型改进
1.给目标用户展现原型,与目标用户进一步沟通理解需求
我们的主要目标用户是小学生,次要目标用户是小学教师
场景一:小明一个三年级的学生,放学回家做作业,妈妈问他上次的数学小测考了多少分
小明:62分
妈妈:你为什么只考了62呢?你做完了吗?你检查了吗?
小明:我只做完了近80%的题
从妈妈的问题我们也能看出家长也知道关键是速度和准确率 ,而小明的回答也是印证了,在规定的时间内只完成了80%,速度跟不上,然而80%的得分只有62,准确率不高,因此这两个方面是小学生用户的痛。
场景二:
对某小学的三年级教师的提问
我:我们想做一个小学生做四则运算的训练,您有什么好的建议吗?
老师:如果你们能让我少批改他们的那些计算题就好了,哈哈哈
我们的次要用户教师们的痛是大量的重复工作,每天要批改大量重复的作业,如果我们可以把老师出的作业放在app上,让班级里同学来做,自动出成绩和用时,对老师来说也是一个减轻工作量的事。
2.修改完善上周提交的需求规格说明书
我们根据用户的选择设计两个版面,学生用户可以自己选择段位(即等级难度)进行测试训练和回顾习题,教师用户可以有出题的功能。
我们针对测试功能根据家长的要求和小学生的需求进行了细分,首先分为两大类,速度测试(在固定的时间内出一道题让用户回答,在时间限定内答对+1,若超过答题时间则进入下一题)和准确度测试(输入想要测试的题目数,然后进行测试),然后两大类里在分别是整数运算,真分数运算和混合 运算的选择。
教师用户可以自己出题并发布,当有人回答自己出的题时,会在下面显示答题人的信息及用时情况和准确率。
3.参考《构建之法》8.5节功能的定位和优先级,给出功能分析的四个象限
第一象限(杀手功能,必要需求):教师用户可以自主出题功能,学生用户的测试功能
第二象限(外围功能,必要需求):良好亲切的界面设计
第三象限(外围功能,辅助需求):习题回顾功能
第四象限(杀手功能,辅助需求):用户登录注册功能及用户信息修改功能
4.任务分解WBS
二、系统设计
从架构设计上我们分为前端设计和后端设计两部分
前端设计:直接与用户打交道,与用户进行交互
后端设计:负责处理用户的请求,为用户提供其想要的数据
三、Alpan 任务分配计划
本组队员有六人,故将任务分为三个子模块,一个总模块,一个测试模块
模块一:教师模块(负责队员 连永刚 014)
A.自主出题 (自动查错功能:防止教师因手误输入没有正确答案的题目,给学生测试带来不便)
B.信息统计 (测试学生姓名 年级 班级 正确率)
模块二:测试模块
1. 测试部分(负责队员 申悦 010)
A. 题目输出
a. 教师自主出题
b. 系统随机出题
B. 正确率的计算
C. 计时功能
2. 回顾部分(负责队员 徐璨 009)
A. 错题记录
B. 成绩记录
C. 错题回顾(错题做对两次才能从错题库中剔除)
模块三:注册模块(负责队员 李志强 028)
1. 注册者姓名
2. 注册证是否为教师
模块四:整合部分(负责队员 李志强 028)
1. 联系整合前三个模块
2. 发现联系问题及时与负责队员沟通并解决
模块五:测试部分(负责队员 魏辉 029 林方言 014)
1.测试计划的编写及任务分配
2.总负责整个测试过程
四、测试计划
1. 项目背景: 本系统是一个针对小学生四则运算的测试系统
2.任务概述
2.1 测试目标: 希望通过测试,发现项目存在的漏洞,大家一起解决问题,完善整个系统。
2.2 测试范围:教师子系统
测试子系统
注册子系统
3.测试策略
3.1 测试方法:手动测试
3.2 测试人员需求、分工
人员 | 职责 |
魏辉 |
组织测试 制定测试计划 需求审核 控制测试进度 与有关队员沟通 测试分析 |
林方言 |
组织测试培训 协助沟通 协助确定测试需求 协助准备测试数据 缺陷报告 |
申悦 徐璨 | 测试 测试子系统 |
连永刚 | 测试注册模块 |
李志强 | 测试教师子系统 |
3.3 测试阶段计划
测试阶段 | 开始时间 | 结束时间 | 测试人员 | 完成标志 |
测试计划设计 | 2017.4.20 | 2017.4.21 | 魏辉 | 计划完成 |
测试培训 |
2017.4.21 |
2017.4.21 |
全体队员 |
掌握此次测试重点 |
测试测试部分 |
2017.4.21 |
2017.4.26 |
申悦 徐璨 |
测试功能实现 错题回顾功能实现 |
测试注册模块 | 2017.4.21 | 2017.4.26 | 连永刚 | 教师与学生都能实现注册 |
教师模块测试 | 2017.4.21 | 2017.4.26 | 李志强 |
实现自主出题并查错 实现查看学生信息 |
缺陷报告 | 2017.4.21 | 2017.4.27 | 林方言 |
完整记录系统缺陷及解决方法 报告缺陷 |
测试分析 | 2017.4.26 | 2017.4.27 | 魏辉 |
完整分析测试中存在的问题 及整个系统存在的问题 |
4.资源需求
4.1 人员需求:要求六名队员掌握
本次测试的重点
每个子系统的功能
实际使用过程中哪部分问题较多
4.2 硬件需求:
笔记本电脑4台
4.3 软件需求:
Java开发环境
5. 风险评估
本次测试可能是有关队员第一次参与完整测试过程,由于知识经验方面的不足,可能无法将使测试足够完善。
6. 其他
计划时间:2017.4.20
修改时间:2017.4.21