Курсовая по программной инженерии: как построить проект с требованиями, архитектурой, тестами и контролируемой разработкой

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

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

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

Разделите их на функциональные, нефункциональные и ограничения.

Функциональное требование описывает поведение.

Нефункциональное - качество.

Ограничение может задавать платформу или совместимость.

Не формулируйте всё как «система должна позволять».

Критерий приёмки

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

Например:

«Пользователь может восстановить пароль по подтверждённому адресу».

Критерий:

«После запроса создаётся одноразовая ссылка, старый пароль перестаёт действовать после смены».

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

Backlog

Если проект ведётся итерационно, разбейте работу на законченные пользовательские функции.

Не создавайте задачи вида:

• написать backend;
• сделать frontend.

Лучше:

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

Так легче оценивать прогресс.

Репозиторий

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

Не загружайте весь код одним коммитом final.

Хорошие коммиты небольшие, тематические и с понятным сообщением.

Не храните секреты и пароли в репозитории.

Ветки

Для учебного проекта сложный GitFlow не обязателен.

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

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

Не имитируйте корпоративный процесс ради диаграммы.

Архитектурные решения

Для ключевого решения зафиксируйте:

• проблему;
• варианты;
• выбранный вариант;
• последствия.

Например:

«Хранить файлы в БД или объектном хранилище».

Это намного сильнее фразы «была выбрана современная архитектура».

Модульность

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

Не создавайте класс ManagerServiceHelper, который занимается всем.

Разделение должно помогать тестировать, заменять и понимать код.

Слишком мелкие классы тоже могут ухудшить читаемость.

Зависимости

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

Бизнес-логика не должна без необходимости зависеть от деталей интерфейса.

Если архитектура слоистая, придерживайтесь выбранного направления.

Не рисуйте диаграмму, которая не соответствует импортам в коде.

API

Опишите контракт.

Для важных эндпоинтов укажите:

• вход;
• выход;
• ошибку;
• права.

Не ограничивайтесь фразой «реализован REST API».

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

Обработка ошибок

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

Разделяйте:

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

Логирование и сообщение пользователю должны быть разными.

Unit-тест

Он проверяет небольшой компонент изолированно.

Хороший unit-тест:

• быстрый;
• детерминированный;
• не требует реальной сети;
• проверяет одно поведение.

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

Integration-тест

Он проверяет взаимодействие компонентов.

Например:

• приложение и БД;
• сервис и очередь;
• два модуля.

Такие тесты медленнее и требуют среды.

Не пытайтесь заменить ими все unit-тесты.

End-to-end

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

Он полезен для критических потоков, но хрупок и медленнее.

Не автоматизируйте сотни E2E, если те же правила дешевле проверить ниже.

Тестовая пирамида

Смысл не в красивом рисунке, а в балансе.

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

Небольшое число сквозных тестов подтверждает, что система собрана правильно.

Покрытие

100% coverage не гарантирует качество.

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

Используйте покрытие как индикатор пропущенных участков, а не как конечную цель.

Mock

Подмена полезна для внешней зависимости.

Но чрезмерное мокирование приводит к тестам, которые проверяют собственные заглушки.

Мокайте границу, а не каждую внутреннюю функцию.

Статический анализ

Линтер и type checker ловят часть ошибок автоматически.

Не просто включите инструмент.

Покажите, какие категории проблем он предотвращает.

Если предупреждение игнорируется, объясните причину.

Форматирование

Автоматический formatter снижает шум в code review.

Это не показатель качества алгоритма, но упрощает совместную работу.

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

CI

Минимальный pipeline может делать:

1. установку зависимостей;
2. линт;
3. тесты;
4. сборку.

Если один шаг падает, изменения не должны считаться проверенными.

Не добавляйте CI только в виде картинки. Конфигурация должна реально запускаться.

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

Разделяйте код, конфигурацию и секреты.

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

Не зашивайте адрес БД и пароль в исходный код.

Миграции

Если схема БД меняется, изменения должны быть воспроизводимыми.

Миграция лучше ручной инструкции «добавьте колонку».

Покажите, как новая версия приложения получает нужную схему.

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

Даже учебный проект выигрывает от понятных логов.

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

Но не стройте полноценную observability-платформу, если проект маленький.

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

Сначала измерьте.

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

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

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

Если вы сознательно сделали упрощение, зафиксируйте его.

Например:

• временно нет кэша;
• один сервис вместо двух;
• нет полного аудита.

Честно описанный долг лучше случайной сложной архитектуры.

Рефакторинг

Рефакторинг не меняет внешнее поведение.

Перед серьёзным изменением полезны тесты, которые фиксируют текущий контракт.

Не называйте добавление новой функции рефакторингом.

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

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

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

Не храните документацию, которая описывает прошлую версию.

Защита

Покажите инженерную цепочку:

1. требование;
2. архитектурное решение;
3. реализация;
4. тест;
5. CI;
6. результат.

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