Alpha 阶段项目展示报告
项目亮点总结
成员与分工简介
OSome 课程开发团队根据个人技术栈进行团队分工，并且在团队成员出现特殊状况的情况下及时调整分工，保证任务顺利完成。
典型用户场景
-
场景 1：
-
姓名：沃老师
-
身份：OS 课程老师
-
时间：课程开始阶段
-
需求：根据选课表创建学生用户、将学生导入课程
-
本平台满足需求的场景：
老师收到了学生选课名单，希望能将学生信息导入课程平台上。因此他打开了课程管理端，选择用户创建界面，通过已经准备好的 csv 文件先给每个学生创建了用户。之后再切换到学生创建界面，将准备好的csv文件导入课程平台，给本学期的课程导入选课学生名单。
-
-
场景 2：
-
姓名：小红
-
身份：OS 课程学生
-
时间：课上考试阶段
-
需求：查看考试任务、选择 commit 进行评测、查看评测结果
-
本平台满足需求的场景：
小红使用本系统在课上考试查看对应的任务，点击任务后可以看到本次课上任务的题面。小红能力很强，很快在跳板机上完成了代码的编写，并将完成的代码提交到 git 仓库上。完成后小红切换到提交评测界面，选择刚刚的 commit 进行提交评测，很快他在界面上得到了本次提交的结果，并没有通过。她仔细思考，意思到自己代码的问题，重新进行编码，并将修改重新提交到 git 仓库上。她又回到代码提交界面，提交了最新的 commit，等待一段时间后得到了通过的结果。
-
-
场景 3：
-
姓名：小蓝
-
身份：OS 课程助教
-
时间：课下答疑阶段
-
需求：查看学生评测详细记录、查看学生提交的代码
-
本平台满足需求的场景：
小蓝收到了小红的提问，希望他帮忙看一下自己的课下代码为什么没有通过。小蓝收到消息后登录管理端界面，在评测记录界面查找小红的北航学工号，找到了对应的提交结果和反馈。小蓝仔细查看反馈，并跳转到小红的学生仓库进行查看，很快查明了问题，并将原因反馈给了小红。
-
-
场景 4：
-
姓名：小红
-
身份：OS 课程学生
-
时间：课程临近结束
-
需求：查看学习进度
-
本平台满足需求的场景：
小红很好的完成了本次操作系统课程，她认为自己收获颇丰，希望发朋友圈庆祝一下。她切换到了进度查看界面，密密麻麻的绿色方框证明了小红很好的完成了每次的课下任务和课上任务，她将整个页面截图，发到了朋友圈，收获了大量点赞。
-
杀手级功能
我们的系统提供了方便的评测功能。既能让每一名同学在学生前端页面选择 commit id 进行提交并查看结果，又能让助教和教师可以在管理前端页面查看每名同学的提交情况和反馈信息。
项目发布情况
以 yzr 为核心的 OSome 课程平台开发团队，始终保持与操作系统课程老师紧密沟通。
5 月 7 日，我们邀请操作系统课程的沃天宇老师，进行长达三小时的视频会议。我们向沃老师展示了 OSome 平台的学生平台、教师平台，并听取了沃老师的建议。我们立即对老师反馈的问题进行了修改。最终，于 5 月 9 日晚，向全体操作系统老师和正在上操作系统课程的全体学生发布。
软件工程质量
- 优秀的代码质量
- 完善的开发、部署指导
- 覆盖全开发过程的 CI/CD 配置
- 完整的单元测试机制、日志机制
- 自动化的前端代码风格检查
项目管理情况
成员简介、个人博客地址
| 姓名/昵称 | 头像 | 自我介绍 | 博客地址 |
|---|---|---|---|
| gyp |  |
我和 yzr 平均一下等于二分之一个 yzr 呢 | 毕业隐私保护 |
| cjy |  |
Good Game Well Play! | 毕业隐私保护 |
| yzr |  |
好好生活，注意休息 | 毕业隐私保护 |
| fxj |  |
劳逸结合，过好 UTC+08:00 的生活 | 毕业隐私保护 |
| ch |  |
神犇奆佬带带我 orzzzzz | 毕业隐私保护 |
| ptw |  |
再也不想熬夜干活了 | 毕业隐私保护 |
| wwq |  |
楼上带带 qwq | 毕业隐私保护 |
项目管理概述
- 范围管理：由大家共同协商决定需求是否纳入实现范围。
- 时间管理：
- 以模块化的整体规划为顶层，根据功能模块的技术难度与依赖关系设计。
- 将任务划分为子任务作为中层，见 Alpha 阶段任务划分文档。
- 在各子项目中创建 Issue 作为底层，实现项目进度的动态化管理。
- 使用自动化工具绘制燃尽图，聚合底层数据，作为项目进度管理抓手。
- 成本管理：
- 在部署阶段对若干服务进行资源限额与专属资源配置，避免整体资源使用超出现有额度。
- 质量管理：
- 实现以 Merge Request 功能为核心的 Code Review 机制，通过 Review 后方贡献方可生效。
分工协作情况
- 根据技术栈等因素综合考量，将开发人员分组分工，实现效益最大化，技术积累成本最小化：
- gyp 负责后端 API 实现与甲方对接。
- cjy 负责前端页面设计与前端页面实现。
- yzr 负责评测机制实现与后端测试。
- fxj 负责文档记录、需求整合分析、项目管理。
- ch 负责前端基础机制实现与显示调优。
- ptw 负责服务部署、系统架构设计与维护、技术支持。
- wwq 负责前端页面设计、排版优化与交互逻辑实现。
- 根据健康情况等因素灵活动态调整协作模式与分组分工安排，增强团队组织的鲁棒性：
- 在一位成员病倒后，我们及时地调整了分工模式，迅速地填补上了生产力空缺。
沟通对接模式
- 基于功能对接的沟通：
- 前后端同学直接对接
- 应用开发同学与应用部署同学直接对接
- 基于需求对接的沟通：
- 安排 gyp、yzr 负责与需求方对接
- fxj 负责汇总与分析需求
- 基于设计迭代的沟通：
- 微信群直接沟通
- Scrum Meeting 直接沟通
时间/质量/资源的平衡
在时间极为有限的情况下，我们以需求为导向进行取舍，将更多的精力用于保证 Alpha 阶段目标：支持同学们在 OSome 平台完成题目的提交，助教在 OSome 平台查看同学们的评测记录与通过情况，并优先测试了鉴权与登录、用户管理、课程管理、评测管理等功能，以保证其质量。
此外，OSome 团队成员彼此熟悉、配合默契且对项目抱有认同感，认为这是一件有意义和价值的事，甘愿将团队任务置于更高的优先级，为此不惜牺牲其它课程的课下或课上时间，在此也需要感谢 OSome 团队成员在其它课程中的队友的支持理解与感同身受。
实际进展（燃尽图）
燃尽图通过动态获取剩余开启 Issue 的数量并绘制图像，直观地展示了项目进度，成为我们管理项目进度的一个有力抓手。
角色、具体贡献、贡献分
贡献分配表：
| 成员 | 纸面得分 | 纸面比例 | 折合贡献分 | 下取整结果 | 未分配贡献 | 未分配补偿分 | 最终贡献分 |
|---|---|---|---|---|---|---|---|
| gyp | 165 | 0.142057684 | 49.72018941 | 49 | 2.39 | 1 | 50 |
| cjy | 166.5 | 0.143349118 | 50.17219113 | 50 | 0.571428571 | 0 | 50 |
| yzr | 175 | 0.150667241 | 52.73353422 | 52 | 2.434285714 | 1 | 53 |
| fxj | 140 | 0.120533793 | 42.18682738 | 42 | 0.62 | 0 | 42 |
| ch | 172 | 0.148084374 | 51.82953078 | 51 | 2.752857143 | 1 | 52 |
| ptw | 170 | 0.146362462 | 51.22686182 | 51 | 0.752857143 | 0 | 51 |
| wwq | 173 | 0.148945329 | 52.13086526 | 52 | 0.434285714 | 0 | 52 |
| 总计 | 1161.5 | 347 | 350 |
不幸地，fxj 同学于 4 月 30 日突发肠阻塞，并在北京大学第三医院接受治疗至 5 月 7 日。经过团队内部协商，我们对 fxj 同学给予其他同学 4 月 30 日至 5 月 9 日之间的贡献分的平均值（\((42.5+28+46+44+57+77.5)/6\approx 49\)）的补偿。
用户场景
项目预期
-
项目开发前的目标：
实现全新的 OS 课程平台。为教师用户提供便捷的班级、用户、权限管理机制；为助教用户提供可视化的公告管理、详细的学生评测记录、可快捷扩充评测机集群；为学生用户提供可视化的任务查看、评测信息管理和进度管理。
-
预期的典型用户场景：
-
场景 1：教师为课程导入学生
沃老师准备将选课学生导入课程。他从教务上下载了课程的选课清单并调整了文件内容，然后打开了课程管理端，上传该文件以创建学生账号。之后再切换到学生创建界面，将文件导入课程平台，给本学期的课程导入选课学生名单。
-
场景 2：上机考试相关场景
学生小红使用本系统在课上考试查看对应的任务，点击任务后可以看到本次课上任务的题面。小红完成代码编写后，将代码提交到git仓库上。然后切换到提交评测界面，选择刚刚的commit进行提交评测，很快他在界面上得到了本次提交的结果，但没有通过。她找到了自己代码中存在的问题并进行了丢该，将修改重新提交到git仓库上。她又回到代码提交界面，提交了最新的commit，等待一段时间后得到了通过的结果。
-
场景 3：通知发布
上机考试时，小蓝发现题目中有一处表述不太清楚。他打开对应题目的通知管理界面，采用 Markdown 编辑了一段通知对题目进行说明，并预览确认无误后进行发布。正在考试的小红在界面上看见了通知的气泡提示，通读内容后，对题目的要求有了更清楚的了解，很快就有了作答思路。
-
场景 4：助教查看提交的代码与评测记录
小蓝收到了小红的提问，希望他帮忙看一下自己的课下代码为什么没有通过。小蓝收到消息后登录管理端界面，在评测记录界面查找小红的北航学工号，找到了对应的提交结果和反馈。小蓝仔细查看反馈，并跳转到小红的学生仓库进行查看，很快查明了问题，并将原因反馈给了小红。
-
场景 5：查看学习进度
小红很好的完成了本次操作系统课程，收获颇丰，希望发朋友圈庆祝一下。她切换到了进度查看界面，密密麻麻的绿色方框证明了小红很好的完成了每次的课下任务和课上任务，她将整个页面截图，发到了朋友圈，收获了大量点赞。
-
-
预期的功能描述：
| 用户端 | 功能 | 验收标准 |
| 学生端 | 首页通知 |
- 支持 Markdown 格式的通知发布 - 纯文本形式通知 |
| 评测 |
- 在界面中显示所有的 Lab 分支，可以选择其中一个分支 - 选择分之后，按照时间顺序显示 commit 记录，最新的提交在最上面 - 显示的 commit 记录必须包含的信息包括 hash、commit message - 对于未提交评测的 commit，提供“提交评测”选项，用户点击后，可提交至该次试验对应的评测 - 对于已经评测的 commit，在 commit 信息旁边显示得分 - 不可重复评测同一个 commit - 在所有该分支所有评测信息的最上方显示当前课下实验（或课上测试）的最高得分 |
|
| 进度查看 |
- 用方块显示所有的任务，同一个 Lab 下所有的任务占一行 - 每一个方块中显示任务名称、开始时间、截止时间、座位、任务最终得分 - 任务的最终得分取该任务下所有提交的最高分 - 学生点击方块时，将显示该任务对应的题目 |
|
| 用户登录 |
- 用户在首页可点击“登录” - 输入用户名和密码后尝试登录 - 登录成功，则进入首页通知界面 - 登录失败则返回错误提示 |
|
| 个人信息 |
- 显示用户的个人信息，包括姓名、学号、教师等 - 提供注销功能，用户点击即可退出登录 |
|
| 建议与反馈 |
- 学生可在文本框中输入对课程平台的使用反馈 - 可通过附件上传图片辅助说明 |
|
| 教师端 | 用户管理 |
- 可以添加用户、如助教、学生等，可通过文件批量导入 - 可通过权限组为助教用户批量授权 |
| 教学信息 |
- 对课程信息进行编辑、修改 - 可查看所有的选课学生信息 |
|
| 公告管理 |
- 可发布、编辑公告，支持纯文本的 Markdown - 可查看所有助教发送的公告，并进行编辑、删除等操作 |
|
| 用户登录 |
- 用户在首页可点击“登录” - 输入用户名和密码后尝试登录 - 登录成功，则进入首页通知界面 - 登录失败则返回错误提示 |
|
| 评测记录 |
- 可查看每一名学生每一次提交评测的记录、包括 commit 信息、得分、评测机详细日志等 - 支持助教手动进行重测 |
|
| 评测端 | 代码评测 |
- 节点可扩充，用 U 盘启动装机后可快速扩充评测机集群 - 每一个题目用一个仓库存储，需要在课上评测/课下实验信息中填写对应的仓库信息 - 若干个评测节点轮训数据库，抓取评测请求 - 对于抓取的评测请求，分析请求内容，从 gitlab 中获取题目与评测数据进行评测，评测完成后写入数据库 |
项目功能
项目发布的功能：
- 学生端：
学生可以在课程公告一栏选择性的查看课程公告，对于希望查看的公告，可以展开查看，如下面的动图所示。
学生可以提交评测一栏查看当前的任务，并跳转的任务对应的题目中查看题目内容。当学生完成代码编写后，可以将代码提交到自己的git仓库，并在学生端界面上点击进行提交。提交结束后可以在学生界面直接获得评测结果和评测信息，如下面的动图所示。
学生可以在进度查看一栏查看当前的进度，进度的成绩将展示到进度查看界面上，不同的成绩将显示为不同的颜色，如下面的动图所示。
学生可以在反馈建议一栏对使用网站的情况进行反馈，可以选择星级和写反馈建议，如下面的动图所示。
学生可以在个人中心，查看自己的个人信息，并修改自己的密码，如下面的动图所示：
- 管理端：
在用户管理一栏，助教和教师可以单独创建用户和使用CSV表格导入用户。同时管理平台提供用户信息的查看和权限的修改，拥有权限的助教和教师可以编辑学生信息、重置学生密码和配置学生权限。
在教学管理一栏，助教和教师可以对课程和学生信息进行管理。在课程管理中可以编辑课程信息、修改课程状态和创建课程。在学生管理中，可以手动输入或者导入csv创建学生信息，同时可以对已经导入数据库的学生信息进行编辑和修改。
在公告管理一栏，助教和教师可以发布课程公告，并对已经发布的公告进行更新和删除。
在实验管理一栏，助教和教师可以进行Lab配置、任务管理和题目管理。在Lab配置中可以对Lab信息进行配置，调整Lab的顺序、更新和删除Lab。在任务管理中，可以配置参与本任务的学生和使用的题目，支持使用csv和json导入学生名单。在题目管理界面，可以创建题目并编辑题目信息。
在评测管理一栏，助教和教师可以对评测记录进行查看。
平台发布：
-
正式版
-
内测版
-
支持的浏览器版本
- Chrome 98+
- Edge 99+
- Firefox 98+
- Opera 82+
- Safari 15.2+
所有账号由课程管理员（老师或助教）创建，不允许自行注册。
联系课程组可获取正式账号或开发账号，用于登录正式版本或内测版本；联系开发团队只能获取开发账号，用于登录内测版本。
申请账号后即可登录并按照上面展示的方法使用系统。
未满足的场景
通知发布的场景未能满足。原因：通知发布需要用到 WebSocket，技术实现较为复杂，而 Alpha 阶段时间太紧（两周），难以在有限的时间内加上一个较为复杂的功能。
用户评价
团队对学生用户群体发放了反馈问卷。共收集问卷答卷 21 份，全部为有效答卷。再用户满意度方面，21 人均对本平台评价为“很满意”。
部分用户给出了具体的反馈，包括：
- 界面清爽
- 平台比较精美
也有部分用户提出了新的功能需求，如：
- 希望上线头像功能
- 支持夜间主题
还有极少部分用户表达了对 Beta 版本的强烈期望。
教师用户群体则对平台提出了更加具体、深入的意见，将在后文中详细介绍。
用户日活
推广努力
早在 1 月份与罗老师交流选题后，yzr 就亲自部署、亲自安排，与操作系统老师沟通，计划在 Alpha 版本发布时，在平台上发布一次需要学生完成的理论课作业。
由于以 yzr 为核心的 OSome 开发团队多半为操作系统课程助教，与操作系统课程组有着紧密联系。在与 wty 老师沟通过后，我们确定了布置给学生的题目。组员们立即完成了题目的构建、题面的撰写、评测的检验等，并最终给学生制定了完善的指导书。
此外，由于和操作系统课程组的深入联系，我们从老师那里拿到了当前课程所有学生的名单。我们将全体学生信息导入课程。这批学生就是我们的初始用户。
日活分析
截止至 5 月 12 日 17 时，已有 241 人完成登录，共 141 名学生完成提交，提交题目 302 次，总共 API 访问次数 13024 次。
仅 5 月 11 日，共 130 人完成登录，共 64 名学生完成提交，总提交次数 143 次，访问 API 共计 4762 次。由于系统中只布置了一次比较简单的作业，且截止日期较远，因此本系统目前的活跃情况还远达不到完整投入使用时的情况。
用户功能反馈
| 来源 | 功能建议 | 是否采纳 |
|---|---|---|
| 反馈问卷 | 是否能加入头像功能 | 将在 beta 阶段实现 |
| 反馈问卷 | 是否能开发出多种主题（如黑暗模式） | 将考虑在 beta 阶段实现 |
| 教师反馈 | 希望可以导出学生实验代码与评测记录 | 将在 beta 阶段实现 |
| 教师反馈 | 希望可以添加新的评测机状态——“评测错误” | 将在 beta 阶段实现 |
| 教师反馈 | 希望可以显示评测时长 | 将在 beta 阶段实现 |
| 教师反馈 | 希望可以修改课程管理与学生管理的层次关系 | 将在 beta 阶段实现 |
| 教师反馈 | 希望可以在考试时监控学生切屏 | 时间有限，目前不考虑实现 |
用户 bug 反馈
- 目前暂未收到用户 bug 反馈
特色功能
杀手功能
提供方便的评测功能。既能让每一名同学在学生前端页面选择 commit id 进行提交并查看结果，又能让助教和教师可以在管理前端页面查看每名同学的提交情况和反馈信息。这样就可以在不需要手动查询数据库的情况下了解每一位同学的错误原因，并对同学们的做题情况进行筛选和统计。
竞品分析
在原有的操作系统平台上，同学们的提交是通过 Git Push 触发评测的，这样就无法直接选择 commit 进行提交。
同时提交反馈结果只能通过对应 log 分支里面的文件查看，该文件中包括了大量编译信息，不方面同学们直接查看结果，也不方便助教和老师们进行统计。
我们对代码提交架构进行了设计，后端会根据 Gitlab 的 API 得到学生的全部 commit 信息，并返回给前端进行渲染。同时 yzr 同学重新设计了评测逻辑，将评测结果和原始输出全部反馈给后端，再由后端根据身份信息选择向前端反馈的信息，以达到学生只能看到自己的评测结果，而管理端能查看评测结果和原始输出。
自我评价
我们的课程项目是应用新技术、融合软件工程思想的典范，将 OS 课程的传统需求与开源社区的优质框架接轨，找准了新需求的出发点，明确了新场景的切入点，抓好了新形势下的落脚点。立足当前，着眼长远，抓住机遇，应对挑战。过程中有重点、分步骤，融入全过程，贯穿各方面，切实抓稳，扎实推进，明确职责，强化规范。必将激发激发同学们的巨大学习热情，凝聚课程组的无穷工作力量，催生 OS 教学的丰硕成果，展现北航计算机学院的全新魅力。
用户评价
- 我们采访了一些学生和助教，收集到了一些具体功能上的反馈意见：
- 教员导入学生不是很方便，希望可以按照类别导入（如按照教师等）
- 删除学生最好加入确认按钮，避免误删
- 希望管理端可以查看、编辑指导书（目前的做法是利用 git）
软件工程质量
文档与代码规范
- 每个仓库具有 readme，作为完整的开发指南，包含以下几方面的信息：
- 本地开发、构建说明
- 部署说明
- 配置说明
- 依赖说明
- 使用以下自动化工具检查代码质量，不通过时 CI/CD 失败：
- ESLint
- Prettier
- API 文档由 swagger 自动生成，省去人工维护的成本。
可传承性
- 代码质量
- 项目代码结构性好
- 层次清晰
- 标识符表意清楚，无需注释
- 重要概念有 OSome 平台概念介绍，避免混淆
- 指导质量
- 项目均有 readme.md，指导本地开发、测试流程。
- 服务均有 docker-compose.yml 留档，可以使用同样的命令启动所有服务：
docker compose up -d。 - 重要机制已形成固化记录（子站反代、Docker Registry 等），帮助使用。
单元测试
完成 24 个重要 API 的单元测试，涉及 68 个测试用例，覆盖率达到 62.6%，共 1874 行代码。
DevOps
CI/CD 是敏捷开发的关键。我们为学生前端、教师前端、后端、评测端、评测环境都配置了 Gitlab CI/CD，从而自动进行回归测试、构建、部署到服务器，极大提高了团队开发效率——除了运维同学外，自动构建、部署的过程对于开发者来说是近乎透明的，开发者只需要知道有一个机制使得开发者每一次 push/merge 都能在服务器上看到效果，而不关心这个机制的具体实现。
Docker 容器技术也是敏捷开发与系统运维的关键。容器技术在我们的开发过程中起到了关键作用：
- 我们可以在一个机器上同时运行多个服务且互不冲突
- 我们利用 Docker 镜像来包装、发布分布式评测机，只需在 V-TEST 上运行 docker-compose 即可自动拉取评测机镜像，扩充评测结点
经验教训
- 设计时要即时和老师沟通，了解用户需求，以免重构
- 开发期间出现了服务器宕机情况，形成处置文档
- 要保护好身体，不要再有人倒下了
- 要即时跟进项目，参与会议，接触技术栈，避免和项目脱节
