Курсовая по программной инженерии в МФТИ: требования, архитектура, тесты и эксплуатационные метрики

Курсовая по программной инженерии в МФТИ имеет прямой образовательный контекст. В правилах приёма 2026 года указано направление 09.03.04 «Программная инженерия» в Высшей школе программной инженерии, программа «Разработка программно-информационных систем». Кроме того, программная инженерия встречается как программа внутри направления ИВТ в ПИШ ФАЛТ.

Официальные страницы:
https://pk.mipt.ru/bachelor/2026_rules/
https://hsse.mipt.ru/bachelor/software-systems

Не начинайте с фреймворка

Плохо:

«Разработка сайта на Django».

Сильнее:

«Разработка сервиса обработки экспериментальных данных с гарантией воспроизводимости вычислений».

Теперь технология выбирается под требования.

Опишите пользователя

Кто пользуется системой?

• исследователь;
• инженер;
• оператор;
• администратор;
• клиент.

Для каждого определите цель, действие, права и типичную ошибку.

Требования

Разделите функциональные и нефункциональные.

«Сервис принимает файл» - функциональное.

«p95 обработки файла до 50 МБ меньше 4 секунд» - нефункциональное.

Приоритеты

Используйте:

• must;
• should;
• could.

Не пытайтесь реализовать весь возможный функционал.

Курсовая выигрывает от законченного ядра.

Acceptance criteria

Для ключевого требования задайте проверку.

Given: файл имеет неверную схему.
When: пользователь загружает его.
Then: система возвращает понятную ошибку.

Так требования становятся тестами.

Архитектурный драйвер

Каждое важное решение должно отвечать на риск:

• высокая нагрузка;
• долгий расчёт;
• безопасность;
• offline;
• отказоустойчивость.

Не используйте микросервисы ради слова «микросервисы».

Модульный монолит

Для индивидуальной курсовой это часто хороший выбор.

Преимущества:

• проще запуск;
• меньше distributed complexity;
• легче тестирование.

Если нет реальной причины делить сервисы, один процесс может быть сильнее.

Микросервисы

Если нужны, покажите границы по бизнес-функции и протокол взаимодействия.

Не делите систему на сервисы только по техническим слоям.

ADR

Architecture Decision Record позволяет объяснить:

• контекст;
• варианты;
• принятое решение;
• последствия.

Например:

«Очередь выбрана для расчётов, которые превышают допустимое время HTTP-запроса».

Схема компонентов

Покажите:

client -> API -> domain -> DB
             -> queue -> worker.

Стрелка должна означать реальное взаимодействие.

База данных

Проектируйте от домена.

Сущности должны соответствовать реальной задаче.

Не начинайте с таблиц users, items, data без смысла.

Миграции

Изменение schema должно быть воспроизводимым.

Сохраняйте migrations в репозитории.

Не исправляйте базу вручную в финальной версии.

API contract

Для 3-5 ключевых endpoint покажите method, path, request, response и error.

Этого достаточно, чтобы понять интерфейс.

Асинхронная задача

Для долгого расчёта:

request -> job id -> worker -> status -> result.

Это лучше долгого зависшего запроса.

Но очередь нужна только при реальной длительной работе.

Idempotency

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

Это хороший критерий зрелого API.

Авторизация

Проверяйте права на сервере.

Скрытая кнопка во frontend не защищает endpoint.

Создайте негативный тест: user A пытается открыть объект user B.

Unit tests

Проверяют локальную логику:

• parser;
• validator;
• calculation.

Минимизируйте сеть и БД в unit test.

Integration tests

Проверяют границы:

• API + DB;
• worker + queue;
• external API.

Большинство реальных проблем появляется между компонентами.

End-to-end

Проверьте один главный сценарий:

login -> create -> process -> result.

Не делайте E2E единственным типом тестирования.

Coverage

Процент строк не равен качеству.

Сильнее показать критичные ветки, ошибки и ограничения.

100% coverage может не проверять правильный результат.

Mutation testing

Для развитой курсовой можно искусственно менять код и смотреть, ловят ли тесты ошибку.

Это полезнее декоративного большого coverage.

CI

Минимальный pipeline:

1. lint;
2. type check;
3. unit tests;
4. integration tests;
5. build.

Не вставляйте весь лог CI.

Покажите схему и итоговый статус.

Docker

Контейнер помогает воспроизвести среду.

Зафиксируйте base image, dependencies, ports и env.

Не храните секреты внутри образа.

Secrets

API key и пароль не должны попадать в Git.

Используйте переменные окружения или secret storage.

Даже учебный проект должен показывать нормальную практику.

Логирование

Записывайте:

• time;
• level;
• request id;
• event.

Не логируйте пароль и токен.

Метрики

Для backend-системы полезны request rate, error rate, p50, p95 и queue length.

Выберите несколько метрик, которые отражают требования.

Нагрузочный тест

Сценарий:

• 1 пользователь;
• 10;
• 50;
• 100.

Покажите, когда растёт p95 и появляются errors.

Не пишите «система масштабируется» без измерения.

Профилирование

Если performance не устраивает, сначала измерьте.

Профиль покажет SQL, serialization, CPU или внешний вызов.

Не оптимизируйте по интуиции.

Надёжность

Проверьте:

• DB unavailable;
• timeout;
• worker crash;
• invalid input.

Система должна иметь предсказуемое поведение.

Retry

Повторять можно не любую ошибку.

Timeout внешнего сервиса - возможно.

Validation error - бессмысленно.

Задайте policy.

Security

Минимальный набор:

• validation;
• auth;
• role;
• secret management;
• dependency check.

Не обещайте полную защищённость.

Документация

README должен позволять другому студенту установить проект, поднять окружение, выполнить migration и запустить tests.

Это простой тест инженерного качества.

Технический долг

Оставшееся ограничение лучше назвать.

Например:

«Нет горизонтального масштабирования worker».

Это сильнее фразы «система полностью готова».

Практическая глава

Хорошая схема:

1. требования;
2. архитектурные драйверы;
3. архитектура;
4. data model;
5. реализация;
6. тестовая стратегия;
7. CI;
8. benchmark;
9. failure tests;
10. ограничения.

Контекст МФТИ

В 2026 году программная инженерия является официальным направлением ВШПИ МФТИ, поэтому здесь не требуется искусственно объяснять поисковый запрос через другую специальность.

При этом требования конкретной курсовой всё равно определяются дисциплиной.

Защита

Будьте готовы показать requirement, ADR, архитектуру, test, pipeline, p95 и failure case.

Сильная курсовая по программной инженерии в МФТИ показывает систему как инженерный объект, который можно проверить, воспроизвести и сопровождать.