Курсовая по программной инженерии в Бауманке: требования, архитектура, тесты и CI без проекта ради проекта

Курсовая по программной инженерии в МГТУ им. Баумана должна показывать не только работающий код, но и управляемый процесс его создания. Если студент демонстрирует приложение, но не может объяснить требования, архитектуру и тесты, работа остаётся обычным программированием.

В МГТУ им. Н.Э. Баумана направление 09.03.04 «Программная инженерия» представлено как отдельная образовательная программа. Кафедра ИУ7 специализируется на проектировании и разработке программного обеспечения и прямо подчёркивает практическую проектную работу.

Официальные страницы:
https://iu7.bmstu.ru/
https://open.bmstu.ru/courses/
https://mf.bmstu.ru/sveden/education/programs/tehnologii-razrabotki-informacionnyh-sistem-suos-09.03.04.html

Начните с требований

До кода сформулируйте:

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

Не начинайте архитектуру с выбора FastAPI или Spring.

Функциональное требование

Например:

«Пользователь загружает CSV и получает отчёт по качеству данных».

Оно описывает поведение.

Нефункциональное требование

Например:

«95% файлов до 20 МБ обрабатываются быстрее 5 секунд».

Оно задаёт качество.

Не смешивайте оба типа.

Acceptance criteria

Для каждой ключевой user story задайте проверяемый результат.

Например:

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

Так тесты появляются из требований.

Scope

Зафиксируйте, что не входит в проект.

Например:

• мобильное приложение;
• сложная авторизация;
• внешняя интеграция.

Хороший scope защищает курсовую от бесконечного расширения.

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

Архитектура должна следовать из требований.

Например:

• высокая нагрузка;
• offline;
• безопасность;
• масштабирование;
• простота развёртывания.

Не выбирайте микросервисы просто потому, что это современно.

Монолит

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

Он проще:

• запускать;
• тестировать;
• отлаживать.

Если микросервисы не решают реальную проблему, они только увеличивают сложность.

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

Если они действительно нужны, покажите:

• границы;
• контракт;
• обмен;
• отказ.

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

ADR

Для важных решений можно создать Architecture Decision Record:

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

Например:

«Выбрана очередь задач, потому что обработка файла длится дольше допустимого HTTP-timeout».

Модульность

Каждый модуль должен иметь одну понятную ответственность.

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

Dependency inversion

Высокоуровневая логика не должна жёстко зависеть от конкретной БД или внешнего API.

Для курсовой достаточно показать один пример интерфейса и реализации.

Контракт

API или внутренний интерфейс должен описывать:

• вход;
• выход;
• ошибки.

Непредсказуемые исключения между модулями усложняют систему.

Версионирование

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

Содержательные коммиты:

• add validation;
• fix retry;
• implement report.

Не один коммит final.

Ветки

Если процесс предполагает feature branches, покажите:

• задача;
• ветка;
• merge.

Но не создавайте сложный GitFlow для индивидуального проекта без необходимости.

Issue tracker

Задача должна иметь:

• описание;
• критерий готовности;
• статус.

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

Code review

Даже индивидуально можно использовать чек-лист:

• корректность;
• тесты;
• стиль;
• безопасность;
• читаемость.

Не оценивайте код только по тому, что он запускается.

Unit tests

Проверяйте бизнес-логику без БД и сети там, где это возможно.

Тест должен иметь ясные:

• input;
• action;
• expected.

Не пишите тест без assert.

Integration tests

Проверяйте:

• БД;
• очередь;
• внешнее API;
• файловую систему.

Именно границы компонентов дают много ошибок.

End-to-end

Проверьте главный пользовательский flow.

Например:

регистрация -> загрузка -> обработка -> отчёт.

E2E не должно быть сотни. Они медленные.

Test pyramid

Разумный ориентир:

• много unit;
• меньше integration;
• немного E2E.

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

Coverage

Высокий coverage не гарантирует сильных тестов.

Покажите, какие риски реально покрыты.

Одна строка может выполняться без проверки поведения.

Mutation testing

Если курс позволяет, mutation testing помогает проверить качество тестов.

Мутант должен «убиваться» тестом.

Но не добавляйте инструмент без анализа результата.

CI

Pipeline может содержать:

1. lint;
2. type check;
3. tests;
4. build.

Покажите YAML-фрагмент и результат.

Не вставляйте 15 страниц логов.

CD

Автоматический deploy нужен только если он часть задачи.

Не добавляйте Kubernetes для локальной учебной программы.

Docker

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

Опишите:

• image;
• port;
• env;
• volume.

Не храните секрет в Dockerfile.

Конфигурация

Разделяйте код, config и secret.

Используйте переменные окружения или другой безопасный механизм.

Не коммитьте токен в Git.

Логирование

Лог должен помогать расследовать ошибку.

Сохраняйте:

• timestamp;
• level;
• request id;
• event.

Не пишите персональные данные и пароль.

Обработка исключений

Ошибка должна:

• логироваться;
• переводиться в понятный ответ;
• не раскрывать внутренний stack trace пользователю.

Покажите один такой сценарий.

Наблюдаемость

Если система серверная, можно измерять:

• latency;
• errors;
• throughput.

Эти метрики полезнее общего слова «стабильность».

Performance test

Сформулируйте нагрузочный сценарий:

• 10, 50, 100 пользователей;
• одинаковый endpoint;
• длительность.

Покажите p50 и p95.

Среднее может скрывать хвост.

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

Если p95 плохой, найдите bottleneck.

Не переписывайте архитектуру до измерения.

Security

Минимум:

• валидация;
• auth;
• authorization;
• secrets;
• dependency scan.

Не заявляйте «система защищена», если проверили только пароль.

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

README должен позволять другому человеку:

• клонировать;
• установить;
• настроить;
• запустить;
• протестировать.

Если это невозможно, проект недостаточно воспроизводим.

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

Честно зафиксируйте:

• известное ограничение;
• риск;
• план улучшения.

Это лучше, чем скрывать недоделку.

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

Рабочая структура:

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

Бауманский контекст

ИУ7 и другие подразделения МГТУ делают сильный акцент на практике разработки. Поэтому курсовая выигрывает, когда инженерные решения подтверждаются репозиторием, тестами и метриками, а не только текстом.

Защита

Будьте готовы показать требование, ADR, commit, unit test, CI pipeline, benchmark и известное ограничение.

Сильная курсовая по программной инженерии в Бауманке показывает полный инженерный путь от требования до проверяемого программного продукта.