В этой теме мы подробно разберём интеграции систем — как разные приложения, сервисы и базы данных обмениваются данными, чтобы работать как единое целое.
Вы узнаете основные стили интеграции (файловый обмен, общая БД, удалённый вызов процедур, асинхронный обмен сообщениями), разницу между синхронным и асинхронным взаимодействием, их плюсы, минусы и когда какой подход лучше использовать.
Мы глубоко изучим API: что это такое, основные виды (REST, GraphQL, gRPC, WebSocket, SOAP), структуру запросов и ответов, анализ JSON и XML, авторизацию и аутентификацию (идентификация → аутентификация → авторизация), а также популярные механизмы безопасности (API Key, JWT, OAuth 2.0, TLS-сертификаты).
Кроме того, рассмотрим брокеры сообщений (Kafka, RabbitMQ), шину данных (ESB), документацию API в OpenAPI/Swagger, тестирование в Postman и диаграммы последовательности (Sequence Diagram) для наглядного описания интеграций. По тренируемся на тренажере по API

В рамках изучения мы подробно разберём ГОСТ 34.602-2020 — актуальный стандарт, который устанавливает правила разработки Технического задания (ТЗ) на создание автоматизированной системы.
Мы узнаем, почему ТЗ является главным документом проекта, отвечающим на вопрос «Что именно нужно сделать?», и как правильно формировать требования к системе, не вторгаясь в зону «как именно реализовывать» (это остаётся за разработчиком).
Особое внимание будет уделено обязательной структуре ТЗ (10 ключевых разделов), правилам оформления: что делать при отсутствии требований в разделе, когда можно добавлять приложения или новые разделы, как избегать дублирования и правильно конкретизировать требования.
Также разберём главный принцип стандарта — описывать «ЧТО», а не «КАК», изучим исключения и рассмотрим практические примеры правильного и неправильного оформления разделов ТЗ.

В процессе создания автоматизированной системы по ГОСТ 34 одним из важнейших этапов являются испытания, которые подтверждают соответствие системы требованиям Технического задания (ТЗ).
Мы изучим, что такое ПМИ (Программа и методика испытаний) — это основной документ, который подробно описывает, что именно будем проверять, как будем это делать, в какой последовательности, какие результаты считаются успешными и в каких условиях проводятся испытания. ПМИ разрабатывает аналитик, а заказчик его согласовывает и утверждает; без утверждённой ПМИ испытания не проводятся.
Также разберём ПСИ (Приёмо-сдаточные испытания) — это сам процесс приёмки системы заказчиком, финальная проверка, в ходе которой система сдаётся в промышленную эксплуатацию.
Простыми словами: ПМИ — это «инструкция и план проверки», а ПСИ — это «сама проверка при сдаче», которая проводится строго по утверждённой ПМИ.

В рамках этого раздела мы изучим два ключевых документа эксплуатационной документации автоматизированной системы (АС) по требованиям ГОСТ 34 и РД 50-34.698-90 — Руководство пользователя и Руководство администратора.
Мы разберём, для кого предназначен каждый документ, в чём заключается их основная цель и чем они принципиально отличаются по глубине технических деталей, объёму и характеру информации.
Уделим внимание сравнительному анализу: какие вопросы решает Руководство пользователя (повседневная работа обычных сотрудников), а какие — Руководство администратора (настройка, управление правами, безопасность и поддержка системы).
В итоге вы будете чётко понимать, когда и какой документ нужен, а также какие требования предъявляются к их содержанию и оформлению.