🐞
Сообщить об ошибке или предложить улучшениеВыделите текст, чтобы активировать кнопку и отправить отчет.
1 курс, итоговая аттестация, 100 баллов
1. Общие положения
Финальная защита проектного практикума проводится в форме онлайн-демонстрации с живым выступлением команды. Защита является обязательной для всех команд 1 курса и входит в итоговую аттестацию по дисциплине.
Цель защиты — оценить, насколько команда:
- сформулировала идею проекта и целевую аудиторию;
- выполнила предварительную проектную и аналитическую проработку;
- реализовала работающий продукт;
- способна логично и убедительно представить результат работы.
Оценивание проводится по 100-балльной шкале на основе укрупнённых критериев.
Оценка ИИ-инструментов не выделяется отдельно и не влияет на итоговый балл.
2. Формат проведения защиты
2.1. Формат
- Защита проводится онлайн.
- Демонстрация результата выполняется вживую. Использование заранее записанного демо допускается только как резервный вариант при долгом выполнении продуктом основной задачи или техническом сбое. (Видеоматериалы являются вспомогательным элементом, а не заменой "живой" демонстрации результата)
2.2. Время
- На полную защиту команды отводиться до 15 минут.
- Данное время включает в себя:
- 5 минут - краткое вступление и показ презентации проекта;
- 5 минут - демонстрация результатов работы по проекту, краткие пояснения по реализации продукта;
- 5 минут - ответы на вопросы комиссии.
2.3. Участники
- Команда проекта;
- Эксперты 2+ (внешние эксперты, кураторы)
- Модераторы
2.4. Материалы, предоставляемы до защиты
Команда обязана заранее предоставить:
- отчет по проектному практикуму
- ссылку на репозиторий или облачное хранилище;
- презентацию в PDF-формате, ориентированную под формат 16:9;
- дизайн-макеты или прототипы в Figma и аналогичных инструментах;
- аналитический материал по проекту;
- ссылку на доску задач (например, YouGile или аналог).
Срок предоставления материалов до 10:00, 17.05 в teamproject
3. Порядок проведения защиты
Защита проходит в следующем порядке:
- Эксперт объявляет команду и проверяет готовность материалов.
- Команда кратко представляет проект и логику выступления.
- Команда показывает презентацию.
- Команда демонстрирует работающий продукт вживую.
- Эксперты задают вопросы.
- Эксперты выставляют оценки по критериям.
4. Структура выступления команды
Рекомендуемый порядок выступления:
- Название проекта и состав команды
- Проблема, идея и целевая аудитория
- Анализ аналогов и отличия проекта
- Сценарии использования или игровые механики
- Техническая и дизайнерская проработка
- Демонстрация работающего продукта
- Что уже реализовано и что планируется далее
- Краткий итог
Для игровых допускается адаптация структуры:
- вместо классических пользовательских сценариев могут использоваться игровые механики, игровые циклы, pipeline обработки данных, пользовательские пути или сценарии взаимодействия с системой.
5. Критерии оценивания
Максимальная сумма — 100 баллов.
Оценка выставляется по четырём укрупнённым блокам.
5.1. Идея, целевая аудитория и ценность продукта - 20 баллов
Оценивается, насколько ясно сформулированы:
- суть проекта;
- решаемая проблема;
- целевая аудитория;
- практическая или пользовательская ценность;
- отличие от существующих решений.
Уровни оценки
| Уровень | Описание | Баллы |
|---|---|---|
| Отлично | Идея, проблема, ЦА и ценность сформулированы чётко. Проведён анализ не менее 3 аналогов. Показано понятное отличие проекта от существующих решений. | 18–20 |
| Хорошо | Основные элементы раскрыты, но есть отдельные недочёты: недостаточно сильное УТП, поверхностный анализ аналогов, не до конца раскрыта польза. | 13–17 |
| Удовлетворительно | Идея и ЦА обозначены, но раскрыты поверхностно. Анализ аналогов слабый или формальный. | 7–12 |
| Слабо | Идея размыта, целевая аудитория определена плохо или не определена вовсе. | 1–6 |
| Не выполнено | Описание идеи проекта отсутствует. | 0 |
5.2. Техническая проработка - 20 баллов
Оценивается качество проектирования: сценарии, требования, стек, дизайн-решения, логика технического подхода.
Уровни оценки
| Уровень | Описание | Баллы |
|---|---|---|
| Отлично | Подготовлены пользовательские сценарии или эквивалентные проектные сценарии. Определены требования. Обоснованы стек и дизайн-решения. | 18–20 |
| Хорошо | Сценарии, требования и стек есть, но аргументация неполная. | 13–17 |
| Удовлетворительно | Сценарии или требования обозначены, но почти не обоснованы. | 7–12 |
| Слабо | Сценарии отсутствуют, стек выбран без объяснения. | 1–6 |
| Не выполнено | Техническая проработка отсутствует. | 0 |
5.3. Реализация и объем выполненной работы - 20 баллов
Оценивается, насколько проект реально доведён до рабочего состояния и насколько он соответствует заявленному объёму.
Уровни оценки
| Уровень | Описание | Баллы |
|---|---|---|
| Отлично | Реализовано не менее 80% запланированного функционала. Продукт стабилен, критические ошибки отсутствуют, демонстрируется сквозной сценарий. | 18–20 |
| Хорошо | Реализовано 60–79% функционала. Возможны небольшие баги или неполная стабильность отдельных сценариев. | 13–17 |
| Удовлетворительно | Продукт работает частично, есть заметные ошибки, сквозной сценарий не доведён до конца. | 7–12 |
| Слабо | Реализован только прототип или разрозненные части без цельной работы продукта. | 1–6 |
| Не выполнено | Работающий продукт отсутствует. | 0 |
5.4. Командная работа и презентация - 20 баллов
Оцениваются структура выступления, распределение ролей, соблюдение регламента и качество демонстрации.
Уровни оценки
| Уровень | Описание | Баллы |
|---|---|---|
| Отлично | Выступление логично: постановка проблемы → решение → реализация → результат. Команда укладывается в регламент, говорит уверенно, видно участие каждого. | 18–20 |
| Хорошо | Есть небольшие недочёты: отдельные запинки, незначительное отклонение по времени, роли раскрыты не полностью. | 13–17 |
| Удовлетворительно | Структура есть, но выступление сбивчивое, вклад участников не всегда понятен. | 7–12 |
| Слабо | Презентация бессвязна, чтение со слайдов, демо отсутствует или неубедительно. | 1–6 |
| Не выполнено | Презентация или выступление отсутствуют. | 0 |
5.5. Документация, артефакты и готовность проекта к сопровождению - 20 баллов
Оценивается:
- наличие и качество репозитория;
- наличие рабочей ссылки на продукт;
- наличие доски задач;
- наличие дизайн-макетов;
- наличие аналитики, README или иной поясняющей документации;
- аккуратность и полнота проектных материалов;
- готовность проекта к дальнейшей передаче, проверке или доработке.
Уровни оценки
| Уровень | Описание | Баллы |
|---|---|---|
| Отлично | Все материалы предоставлены, ссылки рабочие, структура понятна, документация аккуратна и помогает быстро разобраться в проекте. | 18–20 |
| Хорошо | Материалы есть, но часть из них оформлена неидеально или раскрыта неполно. | 13–17 |
| Удовлетворительно | Присутствует только часть артефактов, документация слабая, навигация по материалам неудобна. | 7–12 |
| Слабо | Материалы представлены формально, часть ссылок не работает, проект плохо подготовлен к проверке. | 1–6 |
| Не выполнено | Ключевые материалы отсутствуют. | 0 |
6. Штрафы
Штрафы применяются к сумме баллов по защите.
Каждое нарушение - минус 2 балла, но общий штраф не может превышать 10 баллов.
Основания для штрафов:
- презентация выполнена не в формате 16:9;
- в презентации использованы некорректные, неприемлемые или неуместные материалы;
- присутствуют мат, оскорбительные элементы, политические высказывания, мемы, не относящиеся к теме;
- во время демонстрации возникают технические ошибки, мешающие показу результата;
- превышение регламента более чем на 30 секунд (по докладу или по демонстрации);
- неработающие ссылки на ключевые материалы.
7. Дополнительные баллы - 10 баллов
Критерии:
- Присутствует обоснование использование ИИ. Команда чётко объясняет, зачем использовала ИИ (для генерации кода, текста, дизайна, тестов, документации, идей или как часть функционала продукта). Не «просто потому что модно», "так легче" и тд. ИИ должен или ускорять процесс разработки, или выполнять работу несоответствующую навыкам команды.
- В отчёте / презентации указано: какие именно ИИ-инструменты применялись, на каких этапах, какой объём контента/кода сгенерирован. Отмечены доработки человеком и проведен анализ по работе ИИ.
- Сгенерированный код/текст/изображения работают и соответствуют стилю проекта (нет галлюцинаций, явных ошибок, небезопасных конструкций). ИИ-фичи в продукте стабильны.
- Команда соблюдает лицензии используемых ИИ-инструментов, не нарушает авторские права, не выдаёт сгенерированное за своё оригинальное творчество без оговорок. Указано, какой контент создан ИИ, а какой – человеком.
Уровни оценки
| Уровень | Описание | Баллы |
|---|---|---|
| Отлично | Выполнены все 4 критерия | 9-10 |
| Хорошо | Выполнены 3 из 4 критериев | 7-8 |
| Удовлетворительно | Выполнены 2 из 4 критериев. | 5–6 |
| Слабо | Выполнен 1 из 4 критериев. | 2–4 |
| Не выполнено | Не выполнено ни одного критерия | 0-1 |
8. Итоговая шкала
| Сумма баллов | Оценка | Решение |
|---|---|---|
| 80 – 100 | Отлично (5) | Проект высокого уровня, защита пройдена уверенно |
| 60 – 79 | Хорошо (4) | Проект качественный, есть отдельные недочёты |
| 40 – 59 | Удовлетворительно (3) | Защита засчитана, но есть замечания |
| 0 – 39 | Неудовлетворительно (2) | Требуется доработка и повторная защита |
9. Основания для доработки или пересдачи
Команда может быть направлена на доработку, если:
- продукт существует, но не доведён до демонстрационного уровня;
- презентация есть, но проект слабо реализован;
- проектная логика понятна, но отсутствует рабочий результат;
- материалы предоставлены не полностью, но есть потенциал для завершения.
Повторная защита допускается по решению организаторов и экспертов.
10. Рекомендации для команд
Для успешной защиты команде рекомендуется:
- показать именно работающий продукт, а не только описание;
- заранее отрепетировать выступление;
- подготовить короткий и понятный сквозной сценарий демо;
- распределить, кто и что рассказывает; Если рассказывает один человек из команды, то рекомендуется прописать на слайдах с демонстрацией результатов аналитики, разработки, организации, ФИО человека работавшего над этой частью.
- проверить все ссылки, макеты, репозиторий и демонстрацию;
- держать фокус на сути проекта, а не на второстепенных деталях.