Marking Rubric
本页目录· 12 条
- 评分等级说明
- 1. Authentication and Authorisation(认证与授权,10%)
- 2. Core Functionalities(核心功能,50%)
- 2.1 File Handling(文件处理,20 分)
- 2.2 Queries(查询功能,20 分)
- 2.3 Data Management & Notifications(数据管理与通知,10 分)
- 3. User Interface(用户界面,20%)*
- 4. Demo and Final Reports(演示与最终报告,20%)
- 4.1 Demo Performance(演示表现,15 分)
- 4.2 Final Reports(最终报告,5 分)
- 总分
- Additional Notes(补充说明)
评分等级说明
- 100%(完全实现):功能完全可用,并且无错误地满足所有规格要求。
- 50%(部分实现):功能已存在,但存在 bug、缺少边界情况处理,或只部分满足要求。
- 0%(未实现):功能缺失、完全无法工作,或在测试中完全失败。
1. Authentication and Authorisation(认证与授权,10%)
| 类别与评分标准 | 最高分 | 100%(完全实现) | 50%(部分实现) | 0%(未实现) |
|---|---|---|---|---|
| 1.1 Sign-up, Sign-in, Sign-out注册、登录、登出 | 4 | AWS Cognito 能够安全、完整地处理用户注册(包括 email、first name、last name、password)、邮箱验证、登录和登出。 | 使用了 Cognito,但某些功能缺失或存在 bug,例如邮箱验证或特定用户信息未正确处理。 | 未实现,或无法对用户进行认证。 |
| 1.2 Access Control & Redirection访问控制与重定向 | 3 | 除注册页面外,所有 endpoint 都能完全阻止未认证访问;用户能够被正确重定向。 | 部分 endpoint 受到保护,但其他 endpoint 仍暴露;或重定向处理较差。 | 没有保护措施;endpoint 可被公开访问。 |
| 1.3 Fine-Grained Permissions(IAM)细粒度权限控制 | 3 | 上传、数据库访问和 Lambda 调用都通过精确的 IAM roles/policies 在跨云环境中被正确限制。 | 存在基础 IAM roles,但权限过宽,或缺少正确的跨云 token 处理。 | 缺少 IAM roles;权限配置损坏或不存在。 |
2. Core Functionalities(核心功能,50%)
2.1 File Handling(文件处理,20 分)
| 类别与评分标准 | 最高分 | 100%(完全实现) | 50%(部分实现) | 0%(未实现) |
|---|---|---|---|---|
| 2.1.1 File Upload & Deduplication文件上传与去重 | 6 | 文件能够通过 API/SDK 成功上传;系统能使用文件 checksum 可靠地防止重复上传。 | 上传功能可用,但去重失败;或仅依赖基础文件名而不是 checksum 进行去重。 | 上传失败,或未实现去重。 |
| 2.1.2 Thumbnails & Video Processing缩略图与视频处理 | 6 | 能为图片触发缩略图生成(保持纵横比并压缩),并能为视频按 1 frame/sec 提取帧。 | 缩略图或视频处理可用,但忽略了纵横比、压缩要求,或提取帧率错误。 | 处理失败,或未实现视频/图片提取。 |
| 2.1.3 ML Tagging & DB Insertion机器学习标签识别与数据库写入 | 8 | Serverless function 能够使用 ML model 成功检测物种,并将文件类型、标签、URL(image/thumbnail)保存到数据库。 | ML 检测或数据库写入可用,但缺少部分数据,例如 URL 或文件类型缺失;或需要手动触发。 | ML tagging 或数据库写入完全失败。 |
2.2 Queries(查询功能,20 分)
| 类别与评分标准 | 最高分 | 100%(完全实现) | 50%(部分实现) | 0%(未实现) |
|---|---|---|---|---|
| 2.2.1 Find by Tags(Counts/Species)按标签查询(数量/物种) | 6 | JSON API 能够正确处理多个 tags 的逻辑 AND 操作和 minimum counts,并能处理简单物种查询,返回正确 URLs。 | 查询功能可用,但逻辑 AND 失败(例如做成 OR)、忽略 minimum counts,或返回损坏的 URLs。 | 未实现 Tag/Species 查询,或查询功能完全损坏。 |
| 2.2.2 Find by Thumbnail URL按缩略图 URL 查询 | 6 | API 能准确地将提供的 thumbnail URL 映射到对应的 full-size image URL。 | 部分可用,但返回错误映射,或在特定图片类型上失败。 | 未实现,或无法返回 full-size URLs。 |
| 2.2.3 Find by Uploaded File按上传文件查询 | 8 | API 能成功接收一个文件、检测 tags,并返回数据库中匹配的 URLs,且不会永久保存该查询文件。 | 功能可用,但会永久保存查询文件;或查询文件的 tag detection 不准确。 | 未实现,或无法处理上传文件查询。 |
2.3 Data Management & Notifications(数据管理与通知,10 分)
| 类别与评分标准 | 最高分 | 100%(完全实现) | 50%(部分实现) | 0%(未实现) |
|---|---|---|---|---|
| 2.3.1 Manual Tag Edit(Bulk)手动批量编辑标签 | 3 | POST API 能成功支持批量添加/删除 tags,使用 operations(1 = add,0 = remove),并在删除时忽略未分配的 tags。 | API 只对单个文件可用,但批量操作失败;或未正确处理 add/remove 的二进制逻辑。 | 未实现 tag editing,或功能失败。 |
| 2.3.2 Delete Files删除文件 | 3 | API 能正确从云存储中删除 full images、thumbnails 和 videos,并删除对应的数据库记录。 | 只从数据库删除但云存储仍保留文件(或相反);或批量删除失败。 | 未实现删除功能。 |
| 2.3.3 Tag-Based Notifications基于标签的通知 | 4 | AWS SNS(或同等服务)能够在系统中新增特定 watched tags 时成功触发并发送 email notifications。 | 通知能够触发,但不稳定、缺少特定 tag filtering,或 email formatting 有问题。 | 未实现通知功能。 |
3. User Interface(用户界面,20%)*
| 类别与评分标准 | 最高分 | 100%(完全实现) | 50%(部分实现) | 0%(未实现) |
|---|---|---|---|---|
| 3.1 Auth & Upload UI认证与上传界面 | 6 | 提供清晰、可用的 sign-in、sign-up 和 media uploading UI,并包含关于去重/成功状态的明确反馈。 | UI 已存在但较笨拙、缺少错误处理,或只支持部分功能。 | 未为这些功能提供 UI。 |
| 3.2 Queries UI查询界面 | 6 | UI 支持复杂查询,能可视化预览 thumbnails,并允许用户点击 thumbnails 查看 full-size images。 | 查询 UI 可用,但缺少 thumbnail previews;或点击后无法获取 full-size image。 | 未为查询功能提供 UI。 |
| 3.3 Tag Edit & General Usability标签编辑与整体可用性 | 8 | UI 能成功支持批量 tag editing 和 file deletion;设计专业、用户友好。 | UI 支持部分 tag management,但缺少批量支持,或非常不直观。 | 未为 tag/data management 提供 UI。 |
4. Demo and Final Reports(演示与最终报告,20%)
4.1 Demo Performance(演示表现,15 分)
| 类别与评分标准 | 最高分 | 100%(完全实现) | 50%(部分实现) | 0%(未实现) |
|---|---|---|---|---|
| 4.1.1 Architecture Presentation架构展示 | 5 | 能在 3–5 分钟内清晰、简洁地解释 multi-cloud architecture 和 design choices;所有成员均出席。 | 展示仓促或不清晰;缺少架构细节;或并非所有成员都积极参与。 | 没有 presentation,或对自身架构存在完全误解。 |
| 4.1.2 Application Demo & Q&A应用演示与问答 | 10 | 能流畅、无错误地演示所有核心功能;团队能自信地回答考官 Q&A。 | Demo 存在明显 bug/crash;或团队在回答 Q&A 时明显困难。 | Demo 未能展示核心功能。 |
4.2 Final Reports(最终报告,5 分)
| 类别与评分标准 | 最高分 | 100%(完全实现) | 50%(部分实现) | 0%(未实现) |
|---|---|---|---|---|
| 4.2.1 Team Report小组报告 | 3 | 包含官方 multi-cloud architecture diagram、contribution table、user guide,以及 shared Git repository link,并且所有成员都有 commits。 | 缺少一到两个元素,例如使用了非官方 icons、没有 user guide,或 Git commits 不均衡。 | 未提交报告,或缺少大部分要求。 |
| 4.2.2 Individual Report个人报告 | 2 | 清楚描述个人角色,并包含一段有思考深度的 150-word reflection,反思团队合作与挑战。 | 缺少角色描述或 reflection 其中之一,或细节不足。 | 未提交。 |
总分
| 项目 | 分数 |
|---|---|
| Total Marks(总分) | 100 |
Additional Notes(补充说明)
- 根据 assignment specifications,如果团队选择不创建 UI,则 UI 部分最高只能获得 D(14/20),前提是替代演示方式(例如 CLI、scripts 或通过 Postman demo)表现完美。如果没有 UI,也没有提供替代 scripts,则第 3 部分得分为 0。
- 在 session 结束时,团队将对其他成员在项目中的贡献和参与度进行 peer assessment。对于没有积极参与小组项目的成员,可能会在其 group mark 基础上被扣除最高 50%。