Курсовая по программной инженерии в СПбГУ: как пройти путь от требований до архитектуры, CI и измеримого качества

Курсовая по программной инженерии в СПбГУ в 2026 году имеет прямой образовательный контекст: в актуальном наборе бакалавриата есть отдельная программа «Программная инженерия».

Официальный список программ:
https://cabinet.spbu.ru/Lists/ForeignersLists/bak/index_comp_groups.html

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

Сначала определите продукт

Кто пользователь?

Какую задачу он выполняет?

Что считается успешным результатом?

Например:

«Сервис принимает лабораторные данные, проверяет схему, запускает обработку и сохраняет воспроизводимый отчёт».

Это уже инженерная постановка.

Scope

Сразу зафиксируйте, чего не будет.

Например:

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

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

User stories

Не нужны десятки.

Выберите главные.

Например:

«Как исследователь я хочу загрузить новый dataset, чтобы запустить расчёт».

Добавьте acceptance criteria.

Acceptance criteria

Сделайте критерии проверяемыми.

Например:

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

Так появляется тестовая стратегия.

Архитектурные требования

Архитектура должна отвечать на реальные ограничения.

Например:

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

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

Простая архитектура может быть лучше

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

У него меньше сетевых отказов, инфраструктуры и сложности запуска.

Если вы выбираете монолит, это тоже инженерное решение.

Когда нужны сервисы

Например:

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

Покажите причину разделения.

ADR

Для 3-5 важных решений создайте короткие записи.

Например:

Контекст: расчёт занимает до 40 секунд.
Решение: очередь и worker.
Альтернатива: синхронный HTTP.
Последствие: сложнее инфраструктура, но request не висит.

Так архитектура перестаёт быть рисунком без аргументации.

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

Покажите:

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

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

Domain model

Сущности должны следовать предметной области.

Например:

• project;
• dataset;
• run;
• result;
• user.

Не делайте таблицу `objects`, где хранятся все сущности.

API

Ключевые методы:

• create;
• read;
• start job;
• get status;
• download result.

Для каждого покажите ошибку.

Например, пользователь запрашивает чужой result.

Ожидаемо:

403.

Авторизация

Проверка прав должна быть на сервере.

Скрытая кнопка в интерфейсе не защищает данные.

Создайте отдельные negative tests.

Миграции

DB schema развивается.

Все изменения должны быть записаны.

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

Unit tests

Проверяйте бизнес-правила отдельно.

Например:

• validation;
• calculation;
• state transition.

Не подключайте настоящую сеть к каждому unit test.

Integration tests

Проверьте:

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

Именно границы компонентов часто ломаются.

E2E

Проведите основной пользовательский сценарий целиком.

Например:

login -> upload -> process -> report.

Пара хороших E2E полезнее десятков нестабильных.

Test data

Не используйте production-данные с персональной информацией.

Подготовьте synthetic fixtures.

Это делает тесты воспроизводимыми.

CI

Автоматический pipeline может запускать:

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

Скрин зелёного статуса сам по себе мало значит.

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

Code review

Даже если проект индивидуальный, можно использовать checklist:

• correctness;
• naming;
• error handling;
• tests;
• security.

Сделайте self-review перед финальной версией.

Static analysis

Инструмент может найти потенциальный bug, unsafe pattern или excessive complexity.

Разберите 2-3 реальные находки.

Не прикладывайте сотни предупреждений без анализа.

Coverage

Процент нужен как ориентир, а не как цель.

Тест, который выполняет строку без meaningful assert, повышает coverage, но не качество.

Mutation testing

Если тема позволяет, это интересный способ проверить силу tests.

Изменённый оператор должен быть обнаружен.

Если мутант выживает, test suite недостаточно чувствителен.

Производительность

Свяжите benchmark с требованием.

Например:

p95 GET /items при 100 concurrent users < 300 мс.

Измерьте:

• p50;
• p95;
• error rate.

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

Profiling

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

Это может быть SQL, network, serialization или CPU.

Не переписывайте всю архитектуру без профиля.

Надёжность

Искусственно создайте:

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

Покажите поведение.

Сильная система не только работает, но и предсказуемо ломается.

Retry

Определите, что можно повторить.

Network timeout - иногда да.

Validation error - нет.

Неправильный retry создаёт нагрузку и дубли.

Observability

Для серверной системы можно хранить logs, metrics и trace id.

Покажите, как найти причину одного сбоя.

Это гораздо полезнее общего раздела «мониторинг».

Security

Минимум:

• input validation;
• authentication;
• authorization;
• secret management;
• dependency check.

Не пишите «полная защита».

Пишите, что именно проверено.

Docker

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

Зафиксируйте base image, dependency versions и env variables.

Не используйте `latest` там, где нужна повторяемость.

README

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

Если без автора проект не запускается, инженерная часть слабее.

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

Честно перечислите известный bottleneck, отсутствующую функцию или упрощение.

Для каждого укажите риск.

Это сильнее обещания «всё готово».

Финальная демонстрация

На защите лучше показать цепочку:

требование -> архитектура -> код -> test -> метрика.

Тогда видно, что элементы связаны.

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

Удобная логика:

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

Контекст СПбГУ

В актуальном наборе 2026 года программная инженерия существует как отдельная бакалаврская программа, поэтому статья может говорить о ней прямо, без подмены смежными направлениями.

Защита

Будьте готовы объяснить одно архитектурное решение, показать test, показать CI, воспроизвести ошибочный сценарий, назвать p95 и технический долг.

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