团队作业 3 - 教学课件和班级管理系统 需求改进 & 系统设计

这个作业属于哪个课程	https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience
这个作业要求在哪里	https://edu.cnblogs.com/campus/gdgy/Class34Grade23ComputerScience/homework/13482
这个作业的目标	完成项目需求迭代优化、系统架构/数据库设计、Alpha阶段任务分配及同步测试计划

一、需求 & 原型改进

1. 课堂讨论问题及修改

（依据课堂讨论中教师&其他组的反馈，完成需求调整）

原问题	对应修改
课件格式支持单一（仅PPT/PDF）	新增MP4（视频课件）、MP3（音频讲解）格式的上传+在线预览功能
成绩统计维度单一（仅平均分）	扩展为“最高分/最低分/分数段占比”多维度统计，支持教师自定义统计项
学生评分流程繁琐（多步操作）	优化为“首页快捷评分入口+选星（1-5星）+30字短评”两步流程
课件版本追溯操作复杂	新增“版本对比”功能，高亮展示不同版本课件的内容修改点（如新增页面、文字调整）
教师权限细分不足	新增“课件审核权限”，管理员可过滤违规/低质量课件后再开放给学生

2. 用户调研与原型展示

调研手段：采用半结构化访谈（10位教师+20位学生）+ 场景模拟问卷，调研过程已通过访谈录音+前后场景对比照片记录，附件已上传至随笔。

• 教师用户（张老师，计算机系专业课教师）
  痛点：多班级课件混杂，更新后学生常拿错旧版，每周整理需1小时
  场景对比：

  • 使用前：维护10+个网盘文件夹（如“数据结构-23级班1/班2-修订版”），更新后需逐一通知学生
  • 使用后：通过“课程-班级-版本号”分类上传，系统自动标注“最新版”，学生扫码获取对应课件，整理时间缩至10分钟/周，版本错误率降为0

• 学生用户（陈同学，计算机系大三学生）
  痛点：课件分散在微信群/网盘/教务系统，找资料需1小时；课程评分要填15项量表，凑字数耗时久
  场景对比：

  • 使用前：备考时切换3个平台找资料，评分需补满量表字数
  • 使用后：一键筛选“本学期课程-课件类型”，3分钟集齐资料；“选星+30字短评”30秒完成评分，反馈效率提升80%

3. 需求规格说明书完善

（1）上周初稿不足与改进

初稿不足	具体改进内容
未明确课件版本管理的操作流程	新增“版本对比”模块：教师选2个版本课件，系统高亮展示内容差异（如PPT新增页面、文字修改）
成绩统计导出仅支持Excel格式，无范围选择	支持Excel/CSV双格式导出，可选择“本班数据/跨班级对比数据”等导出范围
未描述权限控制的具体逻辑（仅提“分角色”）	细化角色权限：教师（上传课件/看本班成绩）、学生（看课件/评分）、管理员（审核课件/全局统计）

（2）用户故事（场景化）

作为计算机系张老师，我上传《数据结构》新课件后，点击“版本对比”按钮，就能看到与上一版本的差异（比如新增“红黑树”章节），不用手动打开两个文件逐页对照，节省20分钟核对时间。

4. 功能四象限分析（参考《构建之法》）

按“用户价值+实现成本”划分，明确功能优先级：

象限	定义	功能示例	优先级
杀手功能	核心竞争力，吸引用户	课件共享+热度排序	高
必要需求	产品必备功能，缺之不可	权限管理、成绩统计	高
辅助功能	提升体验，非必备	课件版本对比、评分短评	中
外围功能	锦上添花，优先级最低	界面主题切换、操作引导动画	低

5. WBS与进度计划调整

（Alpha阶段：11.25-12.01，基于原WBS新增任务）

任务名称	负责人	调整后耗时（小时）	时间节点
课件版本对比开发	林嘉俊	6	11.26-11.27
成绩多格式导出开发	廖鸿基	4	11.28
评分流程优化	王梓涵	5	11.25-11.26

二、系统设计

1. 系统架构设计

采用前后端分离分层架构，职责清晰、便于分工：

• 前端层：Vue3 + Element Plus，适配PC/平板端，负责用户交互（如课件列表展示、评分弹窗）
• 接口层：Spring Boot，提供RESTful API，处理请求路由、参数校验
• 服务层：封装业务逻辑（如课件版本对比算法、成绩统计算法），实现模块解耦
• 持久层：MyBatis Plus（操作MySQL）+ MinIO（存储课件），支持课件断点续传、多版本管理

架构优势：前后端分离降低耦合，MinIO保障课件存储的高可用性

2. 数据库ER图设计

ER图关系说明：

• 一个教师可上传多个课件（User → Courseware：一对多）；
• 一个学生可对多门课程评分（User → Score：一对多）；
• 一门课程对应多个成绩记录（Course → Grade：一对多）；
• 一个班级包含多个学生（Class → User：一对多）。

三、Alpha任务分配计划

1. Product Backlog选取

选取优先级Top3的核心功能（对应“杀手功能+必要需求”）：

1. 课件上传/浏览/版本管理
2. 学生课程评分（选星+短评）
3. 成绩多维度统计与导出
4. 基础角色权限控制

2. Sprint Backlog分解

负责人	任务名称	开始日期	预估耗时
王梓涵	前端：用户登录页面开发	2025-11-17	2天
王梓涵	前端：课件列表页面开发	2025-11-19	2天
王梓涵	前端：课件上传页面开发	2025-11-21	2天
王梓涵	前端：评分弹窗开发	2025-11-23	2天
王梓涵	前端：评分列表展示页面开发	2025-11-25	2天
林嘉俊	后端：用户认证接口开发	2025-11-18	2天
林嘉俊	后端：课件上传 / 版本接口开发	2025-11-20	3天
林嘉俊	后端：成绩统计接口开发	2025-11-23	3天
廖鸿基	测试：课件上传功能测试	2025-11-27	2天
廖鸿基	测试：评分功能测试	2025-11-29	2天

3. 甘特图计划（Leangoo实现）

四、测试计划

（测试与开发同步进行，覆盖核心场景）

1. 测试类型与范围

• 单元测试：后端接口逻辑（如课件格式校验、成绩计算）、前端组件功能，由开发自测
• 集成测试：前后端接口联调（如“课件上传接口+前端页面”数据流转）
• 系统测试：全流程验证（教师上传课件→学生评分→教师看统计）

2. 时间安排与负责人

测试阶段	时间节点	测试内容	负责人
单元测试	11.25-11.27	接口逻辑、前端组件功能	林嘉俊、王梓涵
集成测试	11.28	接口联调、数据流转验证	廖鸿基
系统测试	11.30-12.01	全流程场景、边界测试	廖鸿基

3. 测试资源与工具

• 测试环境：本地开发环境（Vue CLI+Spring Boot+MySQL）
• 测试工具：Postman（接口测试）、Junit（单元测试）、Excel（用例管理）
• 测试数据：模拟100条学生数据、50个不同格式的课件文件