Перейти к основному содержимому

Задание 2: Proof of Concept (RAT-PoC)

📋 Вторая контрольная точка проекта - Демонстрация практической осуществимости проекта

📅 Основная информация​

  • Название: Proof of Concept (RAT-PoC)
  • Формат: Очная защита с презентацией
  • Длительность: 5 минут рассказ + 5 минут на вопросы
  • Дедлайн загрузки: 18 октября 11:00
  • Защита: 18 октября с 13:00
  • Запись на защиту: В ведомости

📁 Материалы для загрузки в SmartLMS​

  • Презентация: Формат PPTX
  • Содержание: Ключевые пользовательские сценарии, риски, решения, макеты, диаграммы архитектуры

🎯 Описание задания​

Вторая контрольная точка проекта, на которой команда должна продемонстрировать практическую осуществимость проекта.

Основные требования к презентации​

Презентация должна отражать:

  • Ключевые пользовательские сценарии (user stories с приоритизацией по MoSCoW)
  • User Story Map - полная карта пользовательских историй с зависимостями
  • Описан критический путь системы
  • Сформулированные риски с их решением (включая технические, архитектурные и бизнес-риски)
  • Выбранные четко аргументированные методы и технологии под каждый риск
  • Макеты приложения
  • Диаграммы архитектуры системы (С4)
  • Трассируемость требований - связь между user stories, техническими требованиями и архитектурой

📊 Критерии оценивания​

КритерийВесОписание
Продукт20%Видение конечного продукта, понимание характеристик и пользовательских сценариев
Риски20%Понимание основных рисков в проекте, в т.ч. на дальнейших этапах работы
Решение30%Riskiest Assumption Test (RAT): подтверждение реализуемости рисковых элементов
Сборка30%Наличие "сборки" (proof of concept): минимальный вариант, демонстрирующий работу

📋 Детальные критерии оценивания​

Продукт (20%)​

📚 Рекомендуемые материалы:

0 баллов: Про конечный продукт много неясного, пользовательский опыт не продуман

1 балл: Vision и mission есть, но могут быть некорректными. Есть user stories, но они недостаточно детально проработаны ИЛИ user stories не соответствуют продукту ИЛИ user stories не соответствуют правилам составления (As a [user type], I want [functionality] so that [benefit]).

2 балла: Vision и mission четко сформулированы и соответствуют продукту. User stories соответствуют продукту и составлены по правилам (As a [user type], I want [functionality] so that [benefit]). Есть User Story Map, но она не полностью корректна или не содержит всех необходимых элементов.

3 балла: Vision и mission четко сформулированы, соответствуют продукту и отражают стратегические цели проекта. User stories составлены корректно, полностью соответствуют правилам составления и продукту, а также принципам INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable). User Story Map создана качественно и включает: приоритизацию user stories по MoSCoW, четко расписанные временные промежутки и контрольные точки, детально описанные типы пользователей, зависимости между user stories.

Риски (20%)​

📚 Рекомендуемые материалы:

0 баллов: Риски не продуманы. ИЛИ Риском названо то, что им не является

1 балл: Выбранные риски соответствуют будущим (возможно, лишь ближайшим) этапам работы, НО описание рисков неполное

2 балла: Риски всех этапов перечислены понятным списком и сгруппированы (производительность, надежность, безопасность, масштабируемость, архитектура). Коротко объяснён выбор архитектуры (монолит или микросервисы). Указан CAP‑выбор и простые последствия для пользователя (либо данные всегда одинаковые, либо иногда небольшая задержка обновления). Есть базовый план деградации под нагрузкой: что временно отключаем/упрощаем. Определен критический путь в системе.

3 балла: Риски приоритизированы и связаны с планом работ. Показан простой план развития архитектуры на следующие этапы (когда и что выносить из монолита). CAP‑компромисс привязан к основным операциям (например: записи — CP; чтения — допускаем AP) и описано влияние на UX. План деградации более конкретный (триггеры, что выключаем, кто отвечает, как возвращаем функциональность). Определен критический путь в системе.

Решение (30%)​

📚 Рекомендуемые материалы:

0 баллов: Команда обозначила риски, но не знает, как будет справляться с ними или у команды есть предположения о том, как обойти риски, но предположение команды не основывается ни на каких технологиях или методах (полностью выдумано)

1 балл: Команда нашла решение только для части своих рисковых элементов, но эти решения четко аргументированы методами и технологиями

2 балла: Команда нашла решение для всех рисковых элементов И Для каждого такого решения есть четко аргументированный метод или технология. Дополнительно применены изученные паттерны проектирования для решения архитектурных рисков

3 балла: Используется оригинальное решение или обход риска через широкое осмысление задания: предложен альтернативный путь или технология. Дополнительно создана матрица трассируемости требований, показывающая связь между user stories, техническими требованиями и архитектурными решениями

Сборка (30%)​

📚 Рекомендуемые материалы:

0 баллов: Представленный результат не демонстрирует решение основных поставленных задач или названные основными демонстрируемые результаты таковыми не являются

1 балл: Представлены слабые макеты или дизайн, которые соответствуют заданию тематически, но имеют значительные недостатки в реализации. Созданные С4 диаграммы системы не соответствуют нотации или неправильно отображают архитектуру системы.

2 балла: Показанные макеты и диаграммы архитектуры наглядно демонстрируют работу продукта по основному его назначению. Созданы полные С4 диаграммы системы 1го, 2го уровня.

3 балла: Требования на 2 балла + продемонстрирован рабочий прототип, который превосходит ожидаемый плановый уровень и является функциональным образцом (программа, сервис). Вероятно, требует участия разработчиков в запуске, но способен выполнять основные поставленные задачи.

⏰ Дедлайны и пересдача​

Основной дедлайн​

  • Загрузка: 18 октября 11:00
  • Защита: 18 октября с 13:00

Сдача после дедлайна​

Коэффициент 0.6​

  • Дедлайн: 25 октября 11:00
  • Защита: 25 октября с 13:00

Коэффициент 0.4​

  • Дедлайн: 1 ноября 11:00
  • Защита: 1 ноября с 13:00

Важные правила​

  • Доступ к защите: Только команды, загрузившие презентацию до дедлайна
  • Участие команды: Выступает вся команда, отсутствующие получают "0"
  • Пересдача: Только 2 недели для досдачи, позже нельзя
  • Отсутствующие: Могут защитить на следующей защите с понижающим коэффициентом