nis2/project.md

Командный проект

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

Обычная команда состоит из трёх человек. Пары формируются только для выравнивания числа студентов; для них преподаватель сокращает объем обязательной работы. Команды из четырёх человек не создаются.

В проектном задании перечислены три содержательных направления. Они служат ориентирами для планирования и не задают готовых ролей по числу участников. Команда распределяет работу самостоятельно; каждый студент отвечает за законченный проверяемый результат.

Календарь проекта

Начало проекта

• 14.09.2026, 23:59 — заполнить короткий профиль.
• 18.09.2026 — получить окончательный состав команды и ознакомиться с окончательным банком заданий.
• 21.09.2026, 23:59 — указать три предпочтительных задания от команды.
• 23.09.2026 — получить назначенное проектное задание.

Сроки контрольных точек

Для каждой точки команда заранее сдаёт материалы. На общем занятии ведущий даёт обратную связь и разбирает несколько показательных проектов, после чего команда получает письменный статус и обязательные исправления.

Контрольная точка	Материалы	Занятие	Статус	Опрос
Проверка и детализация проектного задания, план эксперимента	03.11.2026, 23:59	09.11.2026	до 13.11.2026	—
Первый работающий результат	02.12.2026, 23:59	07.12.2026	до 11.12.2026	до 18.12.2026, 23:59
Промежуточные результаты воспроизведения и уточнение плана	27.01.2027, 23:59	01.02.2027	до 05.02.2027	до 12.02.2027, 23:59

Завершение проекта

• 26.02.2027, 23:59 — сдать короткую сверку состояния проекта через ветку nis/status и PR/MR. Опросы и сверка отдельно не оцениваются.
• 01.03.2027 — при отсутствии оцениваемого участия получить предупреждение о риске ИР=0 и требуемом результате к итоговой сдаче.
• 05.03.2027 — получить адресную обратную связь, если у команды выявлены риски или блокировки.
• 19.03.2027, 23:59 — сдать технический отчёт, репозиторий и лист итоговой сдачи через PR/MR; указать полный хеш оцениваемого коммита.

После срока 19 марта разрешены только редакторские изменения презентации и согласованные технические исправления. Даты защит приведены в расписании.

Формирование команды и выбор проектного задания

До 14 сентября, 23:59 каждый студент заполняет короткий профиль. Названия групп приведены в тематическом указателе банка. Профили видит преподаватель; общая таблица имён и интересов не публикуется. Если профиль не заполнен, команда и проектное задание могут быть назначены без учёта предпочтений.

Имя:
Команда: готовая тройка / пара / команды нет
Участники готовой команды:
Интересующие проектные задания:
2–3 тематические группы из банка:
Своя статья, если есть: название и ссылка
Чем статья связана с курсом:
Какой результат интересно проверить:
Код и данные, если есть:

К 18 сентября публикуются окончательные составы команд и окончательный банк готовых проектных заданий. До 21 сентября, 23:59, команда совместно ранжирует три задания. 23 сентября проектные задания распределяются между командами. После этого команда создаёт репозиторий по общим правилам, передаёт его адрес преподавателю и фиксирует начальные содержательные ответственности. Отдельная проектная заявка не нужна.

Что требуется от проекта

Обязательный объём задаёт назначенное проектное задание. Поле «Что уже предоставляет артефакт» описывает готовые код, данные и сценарии и разрешённое повторное использование. Поле «Обязательное приращение команды» указывает собственные компоненты, эксперименты и проверки. Оно входит в обычную программу проекта; раздел «Возможное продолжение» остаётся необязательным.

Сборка, запуск и повторение готового сценария сами по себе не закрывают технический результат. Адаптация засчитывается, когда получен её содержательный результат, прямо указанный в задании. Трудности сборки и несовместимость зависимостей сами по себе не образуют исследовательского результата; диагностика блокировки рассматривается по правилам контрольных точек. От проекта требуются:

• проверяемый технический результат;
• корректный эксперимент с сопоставимыми вариантами, метриками и повторами;
• проверка корректности и доказательный анализ результатов;
• воспроизводимый репозиторий и полный протокол основных серий;
• технический отчёт и презентация.

Сравниваемые варианты запускаются на одинаковых входах или на одинаково сформированных выборках. Для недетерминированных измерений выполняется не менее трёх повторов, если проектное задание явно не требует большего числа.

Корректный отрицательный результат или расхождение со статьёй могут быть полноценным итогом, если эксперимент корректен, данные пригодны для анализа, а причины разобраны по свидетельствам. Техническая блокировка без корректного эксперимента итоговым результатом не считается.

Технический путь проекта

Проверяется утверждение или метод статьи, поэтому опубликованный программный артефакт не обязан быть основой реализации. Проектное задание может предусматривать один или несколько равноправных путей:

• восстановить, адаптировать или модифицировать авторский артефакт;
• самостоятельно реализовать центральный механизм в объёме, достаточном для проверки;
• построить собственный симулятор или модель существенного механизма;
• сочетать реальный прототип с имитацией для более широких экспериментальных серий.

Допустимые пути указаны в конкретном проектном задании. Если их несколько, команда выбирает путь самостоятельно и фиксирует выбор к первой контрольной точке. Переход к пути, которого нет в задании, оформляется как его уточнение: команда показывает технические основания, после чего преподаватель выпускает новую версию задания.

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

Что предстоит делать, если код уже опубликован?

Рассмотрим проект P01 Remix по статье EuroSys 2025. Авторы предоставляют смешанную спецификацию, демонстрационные трассы и инструменты генерации новых трасс и их проигрывания на ZooKeeper. Команда использует эту базу, чтобы исследовать, как степень детализации модели влияет на стоимость проверки и обнаружение расхождений между моделью и реализацией.

Работа в этом проекте проходит четыре этапа:

1. Воспроизвести исходный сценарий. Запустить готовые демонстрационные трассы, сопоставить результат с ожидаемым в авторской инструкции, затем проверить генерацию и проигрывание трасс из модели.
2. Разобраться в проверке. Установить, какие события и ограничения задаёт модель, что означает совпадение при проигрывании и какие свойства остаются вне проверки.
3. Подготовить собственное сравнение. Использовать доступные спецификации как основу грубого, детального и смешанного вариантов с сопоставимыми сценариями и ограничениями поиска. Добавить содержательно новый сценарий ZooKeeper; генерация очередной случайной трассы готовой модели этот шаг не заменяет.
4. Провести эксперимент. Сравнить число состояний, время проверки и расхождения на нескольких сценариях. Хотя бы один результат независимо разобрать по журналам и состоянию ZooKeeper, объяснив соответствие событий модели и реализации.

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

Работа развивается через несколько итераций: реализация сценария, проверка его корректности, первые измерения, разбор результатов и уточнение эксперимента. Обратная связь на контрольных точках помогает определить, что нужно доработать. Готовый артефакт помогает пройти этот путь и даёт основу для проверки собственных решений.

Ресурсы, данные и лицензии

Каждое выданное задание имеет содержательный обязательный путь на CPU, обычном личном компьютере или бесплатно доступной инфраструктуре. Личные расходы не требуются. По согласованию команда с подтверждённым доступом к GPU может включить GPU-реализацию и эксперименты в обязательный план. Доступ должен сохраняться до окончания проверки, а преподавателю должна быть обеспечена возможность выборочно повторить запуски на сопоставимом ресурсе. Оценка зависит от полученного результата; сам доступ к оборудованию преимуществ не даёт. При утрате доступа команда возвращается к исходному CPU-пути. По согласованию могут быть выделены ресурсы Яндекс Облака, но их наличие, объём и срок не гарантируются.

Если у артефакта нет явной лицензии, команда не копирует его код: нужно получить разрешение правообладателя или реализовать механизм независимо по описанию статьи. Закрытые данные, код и сервисы можно использовать только при законном доступе и возможности проверки преподавателем.

Воспроизводимость

Состав и оформление репозитория определены в отдельной памятке. Итоговый репозиторий должен содержать:

• зафиксированные версии кода, данных, зависимостей и параметров;
• автоматизированную настройку или точную инструкцию;
• сокращённый сквозной запуск на обычной машине;
• полный протокол основных серий, сырые и обработанные данные;
• сценарий, который перестраивает итоговые таблицы и графики.

Если в обязательный план входят GPU-эксперименты, преподавателю достаточно обеспечить выборочный повторный запуск; полное повторение всех дорогих серий не требуется.

Контейнеризация не обязательна. Секреты, токены и закрытые данные в репозиторий не помещаются.

Контрольные точки

Каждая точка сдаётся через отдельную ветку и PR/MR. Полный хеш в описании PR/MR фиксирует версию, сданную к сроку. Материалы содержат краткий результат, ссылки на проверяемые свидетельства и карточки ответственности участников. На занятии разбираются общие ошибки и несколько показательных проектов. Статусы, порядок обратной связи, исправлений и документирования блокировок приведены в общих правилах контрольных точек.

1. Проверка и детализация проектного задания, план эксперимента — команда уточняет обязательный результат, проверяет технические предпосылки выбранного пути и готовит план эксперимента. Полный сквозной эксперимент пока не требуется.
2. Первый работающий результат — команда показывает один содержательный сквозной сценарий, исходные измерения, обработанный результат и свидетельства проверки корректности. Baseline и полная серия пока не требуются.
3. Промежуточные результаты и уточнение плана — команда сравнивает основной метод с baseline, представляет промежуточные данные и уточняет обязательный план завершения проекта. Возможное самостоятельное продолжение описывается отдельно.

Конфиденциальные опросы и риск-сигналы

Каждый студент заполняет опрос о себе и каждом участнике команды до 18 декабря, 23:59, и до 12 февраля, 23:59. По шкале «да», «частично», «нет», «недостаточно данных» оцениваются выполнение согласованных задач, проверяемость результата, своевременность сообщения о блокировках, участие в проверке и интеграции и необходимость вмешательства преподавателя. При ответе «частично» или «нет» нужен конкретный пример.

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

Между точками можно подать риск-сигнал, если блокировка угрожает обязательному результату, нужно пересогласовать объём или возникла документированная командная проблема:

Команда и тема:
Ссылка на проверяемые материалы:
Конкретная блокировка:
Что уже сделано:
Влияние на обязательный результат:
Какое решение требуется от преподавателя:

Риск-сигналы, поданные до среды 23:59, разбираются до пятницы 23:59. Обычная отладка, предварительное рецензирование черновиков и управление внутренними задачами команды в этот порядок не входят.

Итоговые материалы и защита

Итоговый комплект включает репозиторий с сокращённым сквозным запуском, данные и конфигурации полного протокола, технический отчёт, презентацию и лист итоговой сдачи nis/final.md. До 19 марта 2027 года, 23:59 команда открывает итоговый PR/MR и указывает в его описании полный хеш оцениваемого коммита. Материалы оцениваются в конце курса как компонент ПР проектного экзамена; второй компонент ЗП определяется на защите. Порядок подготовки и оформления комплекта приведён на странице «Финальная версия проекта».

Защиты ориентировочно проходят 25, 29 и 31 марта; точные даты будут уточнены ближе к концу курса. На команду отводится 20 минут: до 7 минут на доклад, 12 минут на индивидуальные вопросы и 1 минута на смену команды. Каждый участник отвечает на вопросы о своей работе, общей методике, проверке результатов и ограничениях.

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

Проект может быть связан с ВКР, но должен иметь самостоятельный законченный результат к марту. Подробная шкала проекта приведена в памятке по оцениванию.

Дополнительное достижение по проекту

Дополнительное достижение описывается в техническом отчёте и nis/final.md, подтверждается материалами проекта и ответами на защите. Отдельная форма или предварительное согласование не требуются. Четыре признака достижения и примеры приведены в порядке итоговой сдачи, условия высокой оценки — в правилах оценивания.

Риски и порядок действий

Риски фиксируются в материалах контрольной точки или через риск-сигнал. Своевременное сообщение позволяет скорректировать дальнейшую работу; обещание будущего результата и затраченное время сами по себе не учитываются.

Риск	Порядок действий	Как учитывается
Ошибочная предпосылка проектного задания	Команда прикладывает воспроизводимую диагностику. Преподаватель уточняет задание или назначает другое свободное задание и корректирует сроки и объём.	Документированная ошибка задания не снижает статус контрольной точки.
Утрата внешнего ресурса	Команда возвращается к обязательному CPU-пути и при необходимости подаёт риск-сигнал.	Доступ к GPU, облаку или закрытому сервису преимуществ в оценке не даёт.
Техническая блокировка или отрицательный результат	Команда сохраняет материалы, анализирует причины и обновляет план.	Документированная блокировка может быть зачтена как контрольная точка, но сама по себе не заменяет итоговый результат. Корректный отрицательный результат оценивается на общих основаниях.
Проблема внутри команды	Участники фиксируют ответственность и результаты в материалах точек, конфиденциальных опросах и при необходимости в риск-сигнале.	ИР оценивается индивидуально. Если своевременно документированная проблема не зависит от студента и делает продолжение исходного проекта объективно невозможным, ему может быть назначено одно из заранее подготовленных резервных заданий.
К сверке нет оцениваемого участия студента	До 1 марта студент получает в PR/MR адресное предупреждение о риске ИР=0, требуемом результате и сроке. Конфиденциальные ответы и личные обстоятельства публично не раскрываются.	Студент продолжает работу в исходном проекте. Отдельный индивидуальный проект из-за отсутствия вклада не назначается; при итоговом ИР=0 применяются общие правила оценивания и пересдачи.