团队作业2——需求规格说明书
软件工程 | 点我 |
---|---|
作业要求 | 点我 |
作业目标 | 对于团队项目的整体把握,并细化为规格说明书 |
团队选题及选题 | 团队展示及选题 |
目录
一、 需求规格说明书
1.1 项目简介
1.1.1 简单在线评测系统Easy Online Judge
在线评测系统是在线实践计算机语言学习的检测工具,通过线上输入代码,线上评定的方式,将线下编程作业批改以互联网在线形式实现,极大的简化了初学者的学习过程,提高了练习频率,促进学生积极学习计算机语言,提高自身代码能力。
1.1.2 预期的用户量
- 总用户量:不超过3000
- 日活用户量:不超过200
1.1.3 真实性
- 随着互联网的发展,教育教学逐渐由线下转为线上,同学们不仅仅学习课内老师教授的内容,而且还能通过网络进行科学的学习。
- 此外,还存在着不是计算机系的学生需要学习计算机语言,他们没有老师的指导,需要更简单,更方便他们学习计算机语言的工具。
1.1.4 可用性
- 本产品能兼容多种计算机语言,更有助于同学们的学习。
- 以网页在线的形式让用户快速上手和使用。
- 由于本系统是线上网页,对于电脑是否装有IDE并没有严格的要求,用户可以随时随地进行学习,充分利用碎片化时间。
1.1.5 价值
- 在线测评操作简单明了,对于零基础的初学者也可以流利使用。
- 理论学习与实践同步,操作简单,使用者也可以利用碎片化的时间学习。
1.1.6 情怀
本系统致力于帮助学生提高代码能力,在学习计算机语言时实际操作,练习是必不可少的,本系统在帮助同学们学习计算机语言的同时,也传递出‘学习不能停留在课本知识上,需要实践出真知’这一思想。
1.2 面向用户分析
本系统的目的在于提供一个简单的计算机语言学习平台,促进对计算机感兴趣的大学生可以利用本系统学习和锻炼到自己的代码能力。目前主要面向的是希望学习计算机语言的本校大学生。关于本系统主要有以下三种典型用户:
典型用户 | 用户需求 |
---|---|
学生(做题者) | 他们需要熟练的掌握编程语言,在没有老师实时指导的情况下,他们希望可以通过互联网和工具进行学习,以尽快提高自己的能力; |
1.需要大量的编程练习; | |
2.希望有人帮忙检查编写的代码是否出错; | |
3.由于活动或课程的原因,他们也想利用碎片化的时间学习,身边的电脑可能不都具备相应的IDE | |
管理员(老师/出题者) | 他们在校授课,由于不能兼顾每个学生的学习情况,他们需要专门的工具得到学生学习的情况的反馈信息,达到锻炼学生的同时也极大的减轻工作量; |
1.需要一个能够公布相应练习题目的平台; | |
2.还可以创建比赛提高学生积极性; | |
3.希望有人能公正客观的统计学生的学习情况 |
1.3 功能性需求
1.3.1 用户
功能 | 详细描述 |
---|---|
登录注册 | 1. 用户可以通过用户名和密码登录 2. 新用户可以通过邮箱注册账号 3. 用户可以通过邮箱找回密码 |
用户信息 | 1. 用户可以修改自己的昵称 2. 用户可以修改自己的密码 3. 用户可以修改自己的邮箱 |
题目显示 | 用户可以看到题目的相关信息: 1)题目列表 2)题目标题 3)题目描述 4)样例输入 5)样例输出 6)时间限制 7)空间限制 |
提交代码 | 用户上传题目的答案代码 |
提交语言 | 用户可选择提交的语言 |
提交状态 | 用户可以看到题目的提交状态: 1)提交编号 2)用户名 3)题目编号 4)判题结果 5)消耗内存 6)运行时间 7)提交语言 8)提交代码 9)提交时间 |
查找功能 | 1. 用户可以查找题目 2. 用户可以查找提交状态 |
多用户判题 | 1. 允许多个用户同时提交代码判题 2. 多个用户判题时有等待队列 |
实时榜单 | 比赛过程中,用户可以看到榜单 |
1.3.2 管理员
功能 | 详细描述 |
---|---|
登录注册 | 系统初始化时注册管理员账号 |
用户界面 | 管理员可以使用用户所有功能 |
管理员界面 | 除了用户界面外,还有单独的管理员界面 |
管理题目 | 管理员可以管理题目: 添加/修改/删除题目 设置时间限制 设置空间限制 添加/删除题目测试数据 设置题目是否可见 |
管理比赛 | 管理员可以管理比赛: 添加/修改/删除比赛 设置比赛时间 添加比赛的题目 设置语言限制 设置比赛是否公开 |
设置管理员 | 管理员可以设置现有用户为管理员 |
重判题目 | 管理员如果中途添加了题目测试数据,可以使用此功能重新判定之前的提交 |
1.4技术需求
1.4.1 前端
技术项 | 具体技术 |
---|---|
编程语言 | JavaScript, HTML, CSS |
技术框架 | Vue.js |
与后端交互 | Python eel |
测试环境 | Chrome浏览器 |
1.4.2 后台
技术项 | 具体技术 |
---|---|
编程语言 | Python |
使用版本 | 3.x |
消息队列 | Redis |
数据库 | MySQL |
二、 团队计划
2.1 Git仓库
-
issue截图
2.3 原计划安排
2.3.1 总体时间安排
任务 | 时间 |
---|---|
编写代码规范 | 10.26-10.27 |
架构设计 | 10.28-10.30 |
环境搭建 | 10.31-11.01 |
实现功能 | 11.02-11.15 |
2.3.2 功能时间安排:
功能 | 时间 |
---|---|
用户/管理员:登录注册 | 11.02-11.03 |
用户/管理员:用户信息 | 11.04 |
管理员:管理题目 | 11.05 |
用户:题目显示 | 11.06 |
用户:提交代码 | 11.07 |
用户:提交状态 | 11.08 |
用户:多用户判题 | 11.09-11.10 |
用户:查找功能 | 11.11 |
用户:多语言提交 | 11.11 |
管理员:管理比赛 | 11.12 |
用户:实时榜单 | 11.13 |
管理员:设置管理员 | 11.14 |
管理员:重判题目 | 11.15 |
2.4 改进后安排
版本迭代:
版本 | 内容 | 时间 |
---|---|---|
Alpha 1.0 | 完成核心功能 | 11.02-11.06 |
Alpha 2.0 | 完成基础功能 | 11.07-11.10 |
Alpha 3.0 | 完成额外功能 | 11.11-11.15 |
具体内容:
版本 | 功能 |
---|---|
Alpha 1.0 | 用户/管理员:登录注册 |
用户/管理员:用户信息 | |
管理员:管理题目 | |
用户:题目显示 | |
用户:提交代码 | |
用户:提交状态 | |
Alpha 2.0 | 用户:多语言提交 |
用户:多用户判题 | |
用户:查找功能 | |
Alpha 3.0 | 管理员:管理比赛 |
用户:实时榜单 | |
管理员:设置管理员 | |
管理员:重判题目 |
2.5 改进方法
- 版本迭代:版本迭代最大的优点在于灵活。把项目分版本迭代后,就可以逐层完成项目。
- 分层方法:按照功能的重要层度。
- 核心功能:用户可以做题,管理员可以出题。
- 基础功能:可以多语言交题,多用户判题等。
- 额外功能:可以创建比赛,有实时榜单等。
2.6 团队分工
分工 | 参与成员 |
---|---|
UI设计、前端开发 | 蔡晓芬、王欢 |
后端开发 | 张家维、严为炜、孔止 |
测试 | 张家维、严为炜、孔止、 蔡晓芬、王欢 |
文档和博客 | 王欢、孔止 |
三、 本周进展和总结
3.1 本周分工情况及进展
成员名称 | 工作进展 |
---|---|
王欢(组长,前端) | 查看原型 了解项目需求 了解项目所需技术 编写博客 |
孔止(PM,后端) | 完成原型 了解项目所需技术 具体需求/时间安排 |
蔡晓芬(前端) | 查看原型 了解项目需求 了解项目所需技术 |
张家维(后端) | 查看原型 了解项目需求 了解项目所需技术 |
严为炜(后端) | 查看原型 了解项目需求 了解项目所需技术 |
3.2 总结和感想
成员名称 | 总结与感想 |
---|---|
王欢 | 之前没有系统的学习过前端相关的知识,正积极学习着相关内容,这是个挑战也是一个提升技术的机会。 |
孔止 | 虽然很快的完成了简单的原型,但是根据实际的需求,发现的问题很多,需要积极学习新技术。 |
蔡晓芬 | 根据实际需求,分析页面功能还有很多可以完善的地方,要积极学习。 |
张家维 | 对前后端交互有了更深的理解,但是涉及的相关知识面很广,需要更深入的去学习,针对数据存储方式队内也有不同意见,需要尽早沟通确定。 |
严为炜 | 需求明确是开发过程中很重要的一环,明确了再进行开发和API的设计效率会更高。 |