Skip to content

Grading System

Jump to bottom
Claude edited this page Sep 18, 2026 · 2 revisions

📊 Система оценивания

Итоговая оценка — по 100-балльной шкале. Семестр разбит на 3 модуля, у каждого модуля — своя контрольная точка или защита. Отдельного экзамена нет: финальная защита проекта в Модуле 3 и есть экзамен — она оценивается по экзаменационным критериям и в отдельный балл сверх неё не выделяется.

📐 Общая раскладка (100 баллов)

Компонент Когда Баллы
Модуль 1 — Техническое задание конец Модуля 1 15
Контрольная точка 1 — тестирование конец Модуля 1 10
Модуль 2 — Код конец Модуля 2 20
Контрольная точка 2 — тестирование конец Модуля 2 10
Модуль 3 — Интеграция и защита конец Модуля 3 35
Посещаемость весь семестр 10
Итого 100

Модуль 3 разбит на две части:

Часть Модуля 3 Баллы
Проделанная работа (интеграция backend + frontend, модуль реально работает целиком) 15
Защита модуля (презентация, ответы на вопросы — по сути и есть экзамен) 20

Backend-команда и frontend-команда одного модуля получают баллы раздельно на каждом этапе (у каждой стороны своя ТЗ, свой код, своя часть работы) — кроме интеграционной части Модуля 3, где обе команды оцениваются совместно, потому что результат (работающий модуль целиком) — их общий.

🧾 Модуль 1 — Техническое задание (15 баллов)

Что сдаётся: docs/modules/[module-name]/specification-backend.md (backend-команда) и docs/modules/[module-name]/specification-frontend.md (frontend-команда) — по шаблону из Getting Started.

Критерии (оцениваются раздельно у каждой команды, если не указано иное):

  • Все разделы шаблона заполнены содержательно, а не оставлены как [Описание...].
  • Раздел «4.1 API Endpoints» описан подробно: метод, путь, параметры, тело запроса/ответа, ошибки — см. 🔌 API-контракт.
  • Совпадение контрактов (общий критерий на обе команды): раздел 4.1 у backend- и frontend-команды одного модуля реально согласован — методы, пути, форматы ответов совпадают. Несовпадение здесь — не мелочь: это ровно то, что должно было быть проверено чек-листом сверки из 🔌 API-контракт, и его отсутствие снижает балл обеим командам, а не только той, что «неправа».
  • Функциональные требования и пользовательские сценарии реалистичны и покрывают заявленный функционал модуля.
  • (Backend) Структура БД (раздел 5) соответствует тому, что реально понадобится для описанных эндпоинтов.
  • (Frontend) Описание экранов и сценариев использования соответствует тому, какие данные эти экраны запрашивают у backend по контракту.

✅ Контрольная точка 1 — тестирование (10 баллов)

Проверка усвоения материала по итогам Модуля 1 (формат — по согласованию с преподавателем: тест, короткие практические задания). Балл индивидуальный, не командный.

💻 Модуль 2 — Код (20 баллов)

Что сдаётся: код модуля в modules/[module-name]/ (backend) и frontend/[module-name]/ (frontend), через Pull Request в main (см. Git-GitHub-Guide).

Критерии (раздельно у каждой команды):

  • Код реализует то, что было заявлено в своей части ТЗ (Модуль 1) — в первую очередь эндпоинты/экраны из раздела 4.1.
  • CI (pytest + flake8) зелёный на PR, см. .github/workflows/ci.yml.
  • (Backend) Есть тесты на реализованные эндпоинты (по образцу docs/examples/example_module/tests/).
  • (Frontend) Страницы реально обращаются к backend через fetch() по путям из согласованного контракта, а не к захардкоженным данным (заглушки допустимы только как временное решение, пока backend не готов — см. 🔌 API-контракт).
  • Соблюдены соглашения репозитория: структура кода как в docs/examples/example_module/, коммиты и ветки по правилам Git-GitHub-Guide.
  • Код читаемый, без мёртвого/закомментированного кода, без нарушений flake8.

✅ Контрольная точка 2 — тестирование (10 баллов)

Проверка усвоения материала по итогам Модуля 2. Балл индивидуальный.

🔗 Модуль 3 — Интеграция и защита (35 баллов)

Проделанная работа — интеграция (15 баллов, общий балл на backend- и frontend-команду модуля)

Проверяется, что модуль реально работает целиком, а не только «backend отдельно, frontend отдельно»:

  • python main.py run поднимает backend, http://127.0.0.1:8000/frontend/[module-name]/ открывает рабочую страницу модуля.
  • Основные пользовательские сценарии из ТЗ выполняются end-to-end: со страницы можно сделать действие → запрос уходит на backend → данные реально меняются в БД → изменения видно на странице.
  • Ошибки (не найдено, невалидные данные и т.п.) обрабатываются на frontend по контракту, а не «падают» на странице.
  • Нет расхождений с согласованным в Модуле 1 контрактом (если контракт менялся по ходу работы — это отражено в обновлённых specification-backend.md/specification-frontend.md, см. 🔌 API-контракт).

Поскольку этот балл общий, он мотивирует обе команды доводить интеграцию до реально рабочего состояния, а не сваливать вину друг на друга при защите.

Защита модуля (20 баллов, по сути — экзамен, оценивается индивидуально)

Формат — устная защита перед преподавателем (и, возможно, другими командами). Проверяется:

  • Понимание собственного кода: каждый участник может объяснить, что делает его часть модуля, а не только «руками показать, что работает».
  • Понимание архитектуры проекта в целом (core/, modules/, frontend/, как раздаётся API — см. docs/architecture.md) — не только своего модуля.
  • Понимание API-контракта своего модуля: что отдаёт каждый эндпоинт и почему он выглядит именно так.
  • Ответы на вопросы преподавателя по ходу и по коду.

🗓 Посещаемость (10 баллов)

Начисляется по итогам семестра пропорционально посещённым занятиям — точный порядок расчёта уточняется преподавателем в начале семестра.

📚 См. также

Clone this wiki locally