---

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

---

4. Программирование модуля в соответствии с требованиями и спецификациями

Разработка велась итеративно с учетом утвержденной спецификации требований (SRS). Код писался на Python с использованием паттернов проектирования Repository и Service Layer. Это позволило отделить бизнес-логику от логики доступа к данным. Все эндпоинты API реализованы в соответствии с принципами RESTful. Спецификация OpenAPI служила контрактом между бэкендом и фронтендом. Программирование велось в среде PyCharm с использованием плагинов для линтинга.

---

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

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

1. Модуль аутентификации (JWT-токены).
2. Модуль заявок (CRUD-операции).
3. Модуль уведомлений (интеграция с Telegram/SMTP).
4. Модуль отчетов (генерация PDF/Excel).

Связи между модулями реализованы через синхронные REST-запросы для критичных операций и асинхронные очереди (Celery + Redis) для фоновых задач (например, отправка писем). Интерфейсы (API-контракты) зафиксированы в виде Pydantic-схем.

---

6. Работа с репозиторием (Git): создание веток, коммиты, разрешение конфликтов при слиянии

Ведение кода осуществлялось в Git-репозитории. Использовалась стратегия ветвления GitFlow:

· master — релизный код;
· develop — основная ветка разработки;
· feature/... — ветки для новых задач.

Каждая задача начиналась с создания фича-ветки от develop. Коммиты выполнялись атомарно с осмысленными сообщениями (типа fix:, feat:). При слиянии feature-веток в develop возникали конфликты (в основном в файлах миграций БД и в requirements.txt). Разрешение конфликтов производилось вручную через встроенный инструмент VSCode (или git mergetool) с обязательным последующим тестированием спорных участков кода.

---

7. Подключение к базам данных (SQL/NoSQL), внешним API, веб-сервисам

· SQL (PostgreSQL): Подключение выполнено через асинхронный драйвер asyncpg и SQLAlchemy Core. Для работы с миграциями использован Alembic.
· NoSQL (Redis): Использован для хранения сессий пользователей и кэширования частых запросов к справочникам (для ускорения работы модуля).
· Внешние API: Реализованы HTTP-клиенты (httpx) для интеграции с сервисом рассылки уведомлений (SMS-провайдер) и складской системой (1С). Для работы с API настроены повторные попытки (Retry-политика) и таймауты, чтобы обеспечить отказоустойчивость.

---

8. Выявление и исправление синтаксических, логических и семантических ошибок с использованием отладчика (debugger)

Отладка проводилась на всех этапах. Синтаксические ошибки выявлялись автоматически интерпретатором и IDE. Для поиска логических и семантических ошибок активно использовался встроенный отладчик PyCharm. В частности, была найдена ошибка в алгоритме расчета скидки (логическая ошибка в условии if/elif), из-за которой программа некорректно обрабатывала пороговые значения суммы заказа. С помощью пошагового выполнения (Step Over / Step Into) была восстановлена корректная последовательность вычислений.

---

9. Применение профилировщиков, логгеров, точек останова (breakpoints) для локализации ошибок

Для локализации проблем производительности использовался профилировщик cProfile совместно с визуализацией в SnakeViz. Выявлен медленный запрос к БД, который не использовал индекс.
Система логирования настроена с уровнями DEBUG, INFO, ERROR. Логи структурированы в формате JSON для передачи в ELK-стек. Точки останова (breakpoints) устанавливались условные (conditional breakpoints) для отлова ситуаций с конкретным ID заявки, что позволило быстро поймать ошибку обработки в редком Edge Case.

---

10. Написание unit-тестов для проверки корректности работы отдельных компонентов