Школа
системного анализа
и проектирования

Профессия «Системный аналитик информационных систем для бизнеса»

Автор: Денис Бесков
Это универсальное пособие для всех, кто связан с системным анализом: оно охватывает весь путь создания информационной системы — от идеи и требований до внедрения и развития. Новичкам книга подскажет, как войти в профессию; джуны поймут свою роль в проекте; мидлы смогут восполнить пробелы и увереннее вести переговоры; сеньоры сравнят свои подходы с альтернативными мнениями, а руководители отделов анализа получат обзор ключевых навыков, инструментов и актуальных трендов. По сути, это настольная книга, к которой стоит обращаться по мере возникновения новых задач и вопросов.
Автор: денис бесков

Профессия «Системный аналитик информационных систем для бизнеса»

Раздел III. Проектирование информационных систем для бизнеса

Раздел III посвящён проектированию информационных систем и охватывает самые «технические» аспекты. Но при этом не нужно штудировать всё залпом — достаточно выбрать, что у вас болит.


Допустим, глава 16 описывает «техническое проектирование»: как внутри системы распределить логику, какие базы данных выбрать, зачем нужна контейнеризация. Если вы туманно представляете, чем занимаются архитекторы и почему обсуждают микросервисы или ER-диаграммы, то здесь вас ждёт прозрение: «Ах, вот оно что, так строится внутреннее моделирование!»


В 17-й главе речь идёт о более широком подходе к архитектуре: микросервисы, распределённые системы, слоистая архитектура, балансировщики, оркестрация — всё то, что часто звучит на командных встречах.


Глава 18 открывает тему интеграции: очереди сообщений, API, брокеры — если вы застряли в вопросах «какими форматами мы обмениваемся с внешними системами?» или «как мы синхронизируем редактуру данных?», вам обязательно туда.


И, наконец, глава 19 покажет, как оформлять задачи на разработку так, чтобы не остаться в недоумении: «Почему у нас всё время разные люди по-разному поняли одни и те же требования?»


Возможные инсайты: «Подождите, значит REST-подход и очереди — это не взаимоисключающие методы?» и «Вместо того, чтобы в четвёртый раз переписывать техническое задание для разработчиков, я могу наконец-то составить критерии приёмки».

Глава 16. Техническое проектирование

Когда функциональные и системные требования более-менее прояснены, наступает этап технического проектирования. Здесь системный аналитик, совместно с архитекторами, ведущими разработчиками и другими заинтересованными сторонами, вырабатывает детальные схемы и спецификации, описывающие техническую реализацию системы: внутренние структуры данных, механизмы интеграции, архитектурные паттерны и принципы взаимодействия компонентов.

Рис. 16.1 — Проектирование базы данных в ER-диаграмме. Командная работа участников буткемпа «Системный аналитик / проектировщик корпоративных информационных систем»
16.1. Внутрисистемное моделирование
На уровне внутрисистемного моделирования (в отличие от концептуального или бизнес-ориентированного уровня) фокус смещается на детальные схемы того, как именно будут устроены модули, классы, базы данных, протоколы обмена и т. д.

Основные задачи:
1. Определение детальной структуры
  • Какие сущности и классы будут внутри каждого модуля, какие методы и поля они содержат.
  • Какое поведение «зашито» в объекты (паттерны, бизнес-правила).

2. Выявление и уточнение интерфейсов
  • Если в системе используются микросервисы или компоненты с чёткими границами, нужно описать публичные методы, форматы сообщений.
  • Для внутренней коммуникации (между подсистемами) может использоваться REST, gRPC, очереди (RabbitMQ, Kafka), или другие механизмы.

3. Проработка последовательностей взаимодействий
  • Детальный Sequence Diagram: кто вызывает кого, с какими параметрами, какие данные возвращаются.
  • Учёт ошибок, таймаутов, повторных запросов.

4. Определение используемых паттернов
  • Domain-Driven Design (DDD) — выделение агрегатов, репозиториев, сервисов;
  • ORM-паттерны (например, Active Record, Repository);
  • Паттерны интеграции (Saga, CQRS, Event Sourcing), если речь о сложной распределённой системе.

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

16.2. Введение в базы данных
Для большинства бизнес-приложений база данных (БД) — ключевой элемент. Именно там хранятся объёмы критически важных данных (заказы, счета, клиенты, логи и т. д.). Системный аналитик должен обладать базовым пониманием, какие типы БД бывают и как их выбирать.

Классические реляционные базы данных (SQL):

1. Реляционная модель
  • Данные организованы в таблицы, строки, столбцы;
  • Связи (relationship) между таблицами описываются ключами (foreign keys).

2. Нормализация
  • Процесс удаления дублирования данных и обеспечения согласованности.
  • Помогает избежать аномалий при обновлении или удалении.

3. Язык SQL
  • SELECT, INSERT, UPDATE, DELETE, JOIN и другие конструкции.
  • Большинство систем (MySQL, PostgreSQL, Oracle, Microsoft SQL Server) поддерживают стандартный SQL c некоторыми расширениями.

4. Транзакции
  • ACID-свойства (Atomicity, Consistency, Isolation, Durability): обеспечивают надёжность при обновлениях.
  • Важны для финансовых и критичных систем, где нельзя потерять данные или допускать «грязные» записи.

NoSQL и нереляционные базы

1. Документо-ориентированные (MongoDB, CouchDB)
  • Данные хранятся в виде JSON-подобных документов.
  • Удобны для гибких схем, быстрых изменений структуры.

2. Ключ-значение (Redis, DynamoDB)
  • Очень высокая скорость чтения/записи за счёт простой структуры: ключ → blob.
  • Используются для кэшей, сеансов, высоконагруженных операций.

3. Графовые (Neo4j, JanusGraph)
  • Хранение данных в виде вершин и рёбер, эффективно для задач, связанных с графами (соцсети, маршруты, связи).
  • Умеют быстро искать кратчайшие пути, общих соседей и т. д.

4. Колонковые (Apache Cassandra, HBase)
  • Оптимизированы для аналитических запросов, больших объёмов данных.
  • Данные хранятся по «столбцам», что упрощает агрегаты по большим массивам.

Выбор базы данных зависит от:
  • Природы данных: табличные, документы, графы, ключ-значение;
  • Требований к транзакционной целостности;
  • Объёмов данных и нагрузки (read-heavy или write-heavy);
  • Необходимости горизонтального масштабирования (которое легче обеспечить в NoSQL-системах).

Системный аналитик часто участвует в обсуждении вместе с архитекторами, отстаивая интересы бизнеса: если нужны сложные SQL-отчёты, возможно, лучше SQL-БД, если важна гибкость структуры — NoSQL и т. п.


Взаимосвязь с требованиями

Решение о том, какую базу данных использовать, должно согласовываться с нефункциональными требованиями (производительность, масштабируемость, отказоустойчивость) и существующей инфраструктурой. Если в компании уже есть лицензии Oracle и сильная команда DBA, логично использовать их экосистему. Если нужна масштабируемая на десятки миллионов пользователей база без сложных транзакций, NoSQL может быть предпочтительней.
Рис.16.2.1 — Когда использовать noSQL базы данных. Слайд из программы курса «Архитектура ИТ-решения. Проектирование и реализация MVP»
Читайте наши статьи по теме:
Вывод по главе 16
Рис. 16.2 — Презентация решения в диаграмме UML Sequence. Командная работа участников курса «Системное моделирование. Проектирование информационных систем с помощью UML»
Техническое проектирование — это углубление в детали реализации, от внутренних структур модулей и компонентов до выбора подходящей базы данных и механизмов интеграции.

На этом этапе системный аналитик:
  1. Уточняет и консолидирует решения, которые предложили архитекторы и ведущие разработчики, следя за тем, чтобы они не расходились с системными требованиями и бизнес-логикой.
  2. Поддерживает процесc моделирования (UML, Sequence Diagrams, схемы данных), фиксируя согласованные решения в документации (спецификациях, wiki, Confluence).
  3. Участвует в выборе технологий (тип БД, паттерны взаимодействия, инструменты разработки), соотнося их с нефункциональными требованиями (производительность, надёжность, масштабируемость).
  4. Обеспечивает понимание командой конечной цели и механики: если есть расхождения или нестыковки, вовремя поднимает вопрос и помогает найти компромисс.

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

Глава 17. Введение в архитектуру решений, ПО и Systems Design

Когда речь идёт о проектировании и создании сложных IT-систем, одним из важнейших аспектов становится архитектура — совокупность ключевых принципов, структур и паттернов, определяющих, как система будет устроена и как она будет взаимодействовать с окружением. Архитектура является своеобразным «скелетом» решения, вокруг которого формируется конкретная реализация.

В данной главе мы рассмотрим, что такое архитектура в контексте программного обеспечения (ПО) и решений (Solution Architecture), какие принципы и стили встречаются, и почему Systems Design (проектирование систем на более высоком уровне) сегодня приобретает особую актуальность.

17.1. Что такое архитектура
Рис. 17.1.1. — Разработка архитектуры в модели С4, Уровень контекста (общая среда и стейкхолдеры). Командная работа участников воркшопа «Паттерны проектирования микросервисной архитектуры и нотация С4»
Архитектура системы — это высокоуровневое описание её структуры и поведения, включая:

  1. Основные компоненты (building blocks): модули, подсистемы, сервисы, которые выполняют ключевые функции.
  2. Взаимодействие между компонентами: протоколы, форматы данных, шины интеграции, события.
  3. Принципы и паттерны: дизайн-принципы (SOLID, DRY), архитектурные паттерны (MVC, Layered Architecture, Hexagonal, микросервисы, и т. п.).
  4. Нефункциональные характеристики (security, performance, reliability, availability), влияющие на выбор технологий и структуру решения.
  5. Ограничения и допущения: технические (stack, окружение), бизнес-ограничения (сроки, бюджет), организационные (команда, политика, правовые аспекты).

Архитектура должна быть понятной всем ключевым участникам: разработчикам, тестировщикам, DevOps-инженерам, бизнес-заказчикам (в общих чертах). Она служит опорой для принятия решений и помогает избегать хаотичного роста системы.
17.2. Закон Конвея
Закон Конвея (Conway’s Law) гласит, что «Любая организация, разрабатывающая систему (в широком смысле), в итоге создаёт дизайн, копирующий структуру коммуникаций внутри этой организации».

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

Практическая ценность: При проектировании архитектуры нужно учитывать организационную структуру и коммуникации. Иногда проще подстроить архитектуру под реальные команды (чтобы каждая команда владела определённым сервисом), а иногда имеет смысл изменить организацию, чтобы лучше соответствовать желаемой архитектуре.
17.3. Архитектура ПО и решений
Рис. 17.3.1. — Разработка архитектуры в модели С4, уровень контейнеров (сервисы, БД, фронтенд)
Командная работа участников воркшопа «Паттерны проектирования микросервисной архитектуры и нотация С4»
Архитектура ПО (Software Architecture) концентрируется на устройстве программной части информационной системы или конкретного программного продукта: как разделены модули, какие технологии выбраны, как обеспечивается безопасность, логирование, масштабирование.

Архитектура решений (Solution Architecture) смотрит шире: не только на программные компоненты, но и на взаимодействие с другими системами в IT-ландшафте, на инфраструктуру (серверы, облако, сети), а также на процессы внедрения, управления и эксплуатации.

Часто на стороне заказчика или в консалтинговых компаниях есть Solution Architect, который отвечает за согласование ключевых элементов архитектуры с бизнес-целями, бюджетом, организационными особенностями.
17.4. Архитектурные стили и паттерны
Рис.17.2.1 — Монолитная архитектура и ее эволюция. Слайд из программы курса «Архитектура ИТ-решения. Проектирование и реализация MVP»
Рис. 17.4.1 — Различия между основными архитектурными стилями. Слайд из программы курса «Архитектура ИТ-решения. Проектирование и реализация MVP»
Существует множество архитектурных стилей, и выбор зависит от характера проекта, его масштабов и приоритетов.

1. Монолит
  • Вся логика системы собирается в одном процессе (или наборе тесно связанных модулей), развертывается как единое приложение.
  • Проста в начале, но может стать громоздкой и маломанёвренной по мере роста проекта.

2. Слоистая (Layered) архитектура
  • Выделение слоёв (Presentation, Business Logic, Data Access).
  • Классический подход для многих enterprise-приложений.

3. Сервис-ориентированная архитектура (SOA)
  • Предполагает набор loosely coupled сервисов, которые взаимодействуют через шину (ESB) или API.
  • Часто применялась в крупных корпоративных системах.

4. Микросервисы
  • Разбиение функционала на небольшие, автономные сервисы, разворачиваемые и масштабируемые независимо друг от друга.
  • Позволяет быстро развивать отдельные части системы, но накладывает overhead на интеграцию, мониторинг и DevOps-процессы.

5. Событийно-ориентированная архитектура
  • Компоненты реагируют на события, публикуемые в шине, вместо прямых вызовов друг друга.
  • Удобно для асинхронной обработки, гибкого масштабирования и loosely coupled взаимодействия.

6. Serverless
  • Логика приложения разворачивается в виде функций (lambdas, cloud functions), которые запускаются «по событию» в облаке.
  • Быстрое прототипирование, автоматическое масштабирование, но есть ограничения по длительности выполнения, мониторингу и привязке к облачному провайдеру.

Архитектурные паттерны (MVC, Hexagonal, Clean Architecture, CQRS, Event Sourcing) могут сочетаться со стилями, уточняя, как именно упаковывать бизнес-логику и взаимодействие между модулями.

17.5. Распределённые системы
Рис. 17.5.1. — Разработка архитектуры в модели С4, уровень компонентов (внутренние компоненты каждого контейнера)
Командная работа участников воркшопа «Паттерны проектирования микросервисной архитектуры и нотация С4»
Сегодня многие системы являются распределёнными — работают на нескольких серверах или в облачной среде, часто географически разведённой. Это даёт гибкость и масштабируемость, но добавляет сложностей:

1. Сетевая задержка и ненадёжность сетей
  • Нужно учитывать, что запрос может пропасть, задержаться, прийти в неправильном порядке.
  • Не все решения, которые хорошо работали в монолите, будут надёжны в распределённом окружении.

2. Последовательность данных
  • В распределённых системах возникает проблема согласованности (CAP-теорема): нельзя одновременно достичь идеальной консистентности, доступности и устойчивости к разделению сети.
  • Приходится выбирать, где допустимы eventual consistency схемы, а где нужна строгая транзакционность.

3. Мониторинг и отладка
  • Логи и метрики могут быть разбросаны по разным узлам, нужна централизованная система мониторинга (Prometheus, Grafana, ELK-стек).

4. Оркестрация
  • Автоматизация деплоя (Docker, Kubernetes), балансировка нагрузки, резервирование.
Читайте наши переводы книг по теме:
17.6. Фитнес-функция архитектуры
В контексте эволюционной архитектуры существует понятие фитнес-функций (fitness function) — это автоматизированные проверки, которые оценивают, насколько текущая реализация соответствует заданным критериям качества (performance, security, maintainability и т. п.).
  • Пример: «Время отклика в 95% случаев не более 300 мс» — можно реализовать нагрузочный тест, который регулярно проверяет этот показатель. Если он не проходит, фитнес-функция «сигнализирует», что архитектура не соответствует требуемому уровню.
  • Такие функции интегрируются в CI/CD pipeline, позволяя выявлять деградацию или нарушения SLA уже на этапах тестовых окружений.
17.7. Моделирование архитектуры
Рис. 17.7.1. — Разработка архитектуры в модели С4, уровень компонентов (внутренние компоненты каждого контейнера)
Командная работа участников воркшопа «Паттерны проектирования микросервисной архитектуры и нотация С4»
Для описания архитектуры используются разные способы:

1. UML (Component, Deployment, Sequence)
  • Component diagram, чтобы показать основные модули и связи;
  • Deployment diagram, чтобы отразить физическое размещение (серверы, контейнеры).

2. C4-модель
  • Уровень Context (общая среда и стейкхолдеры)
  • Container (сервисы, БД, фронтенд)
  • Component (внутренние компоненты каждого контейнера)
  • Code / Class (детализация при необходимости).

3. ADR (Architecture Decision Record)
  • Для фиксации ключевых архитектурных решений (почему выбрали именно такую БД, такую шину сообщений, такой паттерн).
  • Помогает будущим поколениям разработчиков понимать логику принятых решений.

Главное — поддерживать документацию в актуальном состоянии и не перегружать детальными схемами, если они не используются командой.
17.8. Микросервисы
Рис. 17.8.1 — Микросервисная архитектура. Слайд из программы курса «Архитектура ИТ-решения. Проектирование и реализация MVP»
Микросервисная архитектура — одна из самых популярных тем в последние годы. Она предполагает, что система разбивается на набор мелких сервисов, каждый из которых выполняет определённую бизнес-функцию и автономен:
  • Автономность деплоя: каждый сервис можно разворачивать, обновлять независимо.
  • Автономность развития: разные команды могут вести разные сервисы.
  • Гибкость масштабирования: только нужные сервисы можно масштабировать, вместо масштабирования всего приложения.

Однако у микросервисов есть сложность интеграции, повышенные требования к DevOps-практикам, мониторингу и управлению конфигурациями. Нужно чётко понимать, что микросервисы не панацея, а инструмент, требующий зрелой инженерной культуры.
17.9. Архитектура, ориентированная на события
Event-Driven Architecture (EDA) предполагает, что ключевой способ взаимодействия — публикация и обработка событий, а не запрос-ответ. Компоненты могут подписываться на события (например, «Создан заказ», «Платёж подтверждён») и асинхронно на них реагировать.

  • Это снижает связанность (coupling), позволяет обрабатывать некоторые операции в фоне (например, отправку уведомлений клиентам).
  • Но требует проектировать шину или message broker (Kafka, RabbitMQ), учитывать порядок, дедупликацию, потенциально сложные отладку и трассировку (деньги списаны, но событие потерялось в шине?).
Читайте наши статьи по теме:
17.10. Что такое Systems Design
Systems Design — термин, используемый в более широком контексте, чем просто архитектура ПО. Он включает:

  1. Инфраструктурные аспекты (серверы, сети, балансировщики, CDN, кластеры).
  2. Data engineering: хранилища больших данных, стриминг, распределённые вычисления (Spark, Hadoop).
  3. Сложные требования: горизонтальное масштабирование, обеспечение низкой задержки, геораспределённые инсталляции.
  4. Бизнес-контекст: понимание объёмов данных, потенциального роста, сезонных пиков, рисков downtime.

В интервью для позиций «Senior Software Engineer» или «System Architect» нередко спрашивают задачи на Systems Design: «Как спроектировать Twitter», «Как обеспечить работу YouTube», «Как обработать миллион запросов в минуту».
17.11. Практики проектирования архитектуры
Читайте наши статьи по теме:
Рис. 17.11.1. — Проектирование архитектуры с помощью Event Storming
Командная работа участников воркшопа «Event Storming как техника моделирования предметной области и выявления микросервисов»
  1. Domain-Driven Design (DDD): фокус на моделировании бизнес-домена, выделении bounded context, Ubiquitous Language.
  2. Event Storming: коллективная сессия, где участники «раскидывают» события на стикерах, чтобы понять основные процессы в бизнесе и выявить ключевые агрегаты.
  3. Documenting Architecture: использование ADR, C4-модели, UML-диаграмм, Confluence-страниц для описания решений.
  4. Threat Modeling (моделирование угроз): анализ уязвимостей, рисков безопасности на ранних этапах проектирования.
  5. Performance Testing / Load Testing: прототипирование критических точек, проведение нагрузочных тестов, прежде чем реализовывать всё решение.
  6. Proof of Concept (PoC): если есть сомнения насчёт выбранной технологии, лучше сделать небольшой эксперимент, чем «вкладываться» в масштабную реализацию и потом обнаружить несоответствия.
Вывод по главе 17
Архитектура — это «фундамент» IT-решения, определяющий его структурные и технические характеристики. Системному аналитику важно понимать:

  1. Основные архитектурные стили (монолит, микросервисы, события, SOA) и паттерны, чтобы взаимодействовать с архитекторами и объяснять бизнесу, почему выбран тот или иной подход.
  2. Закон Конвея и влияние организации на архитектуру, а также необходимость согласовать архитектурные решения с реальным составом команд и практик.
  3. Системный уровень (Systems Design), где учитываются распределённость, масштаб, требования по производительности и доступности, роль облачных технологий и больших данных.
  4. Инструменты и практики, которые помогают поддерживать архитектуру в актуальном состоянии: C4-модель, ADR, Event Storming, PoC.

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

Глава 18. Введение в интеграцию систем

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

В этой главе мы рассмотрим основные стили интеграции, специфику анализа при проектировании распределённого взаимодействия, что такое API, как проектировать очереди сообщений и брокеры, а также общие подходы к интеграции.
Посмотрите спецификации на интеграцию — работы участников курса
Интеграция систем. Разработка требований и основы проектирования:
Цель: минимизировать простои производства и судов...
Цель: спроектировать систему для подачи заявок на регистрацию патентов и их проверку...
Цель: ускорение процессов закупки...
Цель: сбор, обработка данных и построение аналитических форм ...
18.1. Что такое интеграция
Рис. 18.1.1 — Пользовательские требования к интеграции. Командная работа участников курса
«Интеграция систем. Разработка требований и основы проектирования»
Интеграция — это процесс «сшивания» нескольких систем таким образом, чтобы они могли корректно обмениваться данными и согласованно работать над бизнес-процессами. Она может происходить между:

  1. Внутренними системами в одной организации (ERP, CRM, складской учёт, бухгалтерия);
  2. Системами разных компаний, которые являются партнёрами или клиентами (EDI, банковские шлюзы, платёжные сервисы);
  3. Приложением и интернет-сервисом (OAuth-авторизация, использование внешних API для геолокации, платёжных транзакций и т. д.).

Цель интеграции — обеспечить целостность данных (чтобы не было расхождений и дублирований) и сквозную автоматизацию (чтобы бизнес-процессы не «рвались» на переходе между системами).
18.2. Интеграционные стили
Рис. 18.2.1 — Фрагмент карты паттернов и технологий интеграций от Юрия Куприянова. Ссылка на карту в PDF. Ссылка на вебинар по использованию карты
Существует несколько стилей интеграции, и выбор зависит от масштабов проекта, числа систем, требований к надёжности и скорости:

1. Point-to-Point
  • Каждая пара систем связывается напрямую, без центрального посредника.
  • Просто для небольшого числа подключений, но при росте приводит к «паутине» из множества связей, сложных в поддержке.

2. Hub-and-Spoke
  • Есть «центральный хаб», к которому подключаются все системы. Хаб отвечает за маршрутизацию, трансформацию форматов данных и т. д.
  • Упрощает управление интеграцией, но может быть узким местом по производительности и надёжности.

3. ESB (Enterprise Service Bus)
  • Эволюция Hub-and-Spoke, где шина (bus) обеспечивает масштабируемое и гибкое подключение сервисов. Может содержать механизмы оркестровки, преобразования сообщений, мониторинга.
  • Использовалось в крупных корпоративных проектах (SOA), однако может стать «монолитным» решением, если не аккуратно проектировать.

4. API-ориентированная интеграция
  • Каждая система предоставляет публичные/приватные API, через которые клиенты (в том числе другие системы) получают доступ к данным и функциям.
  • Сегодня API-first подход очень распространён: он предполагает, что любая логика доступна через REST, GraphQL или gRPC.

5. Событийно-ориентированная (Event-Driven)
  • Системы публикуют события в шину (Kafka, RabbitMQ), а другие системы подписываются и реагируют на них. Асинхронное взаимодействие снижает связанность и даёт гибкость.
  • Подходит для высоконагруженных и распределённых решений, но усложняет отладку, согласованность данных.
18.3. Межсистемный анализ
Рис. 18.3.1 — Диаграмма потоков данных с технологиями интеграций. Командная работа участников курса
«Интеграция систем. Разработка требований и основы проектирования»
Межсистемный анализ — это процесс исследования, какие именно потоки данных и какие процессы нужно связать между системами, какие форматы и протоколы использовать, и как обеспечить корректный обмен. Системному аналитику здесь важно:

1. Определить, какие объекты и атрибуты передаются
  • Например, «Заказ», «Счёт», «Клиент», «Оплата».
  • Выявить, как эти объекты «живут» в каждой из систем, в каких полях могут быть расхождения (дубли, разные форматы).

2. Уточнить, кто является «мастером» данных
  • Если запись о клиенте хранится в CRM, это «золотой источник» (single source of truth), а остальные системы должны обновляться из CRM.
  • Избегать ситуации, когда несколько систем «параллельно» редактируют одну и ту же сущность, не синхронизируясь.

3. Проанализировать частоту и объёмы обмена
  • Какие сценарии требуют «почти реального времени», а какие можно синхронизировать раз в час или сутки?
  • Сколько записей или сообщений будет «проходить» через интеграцию (трафик)?

4. Рассмотреть ошибки и исключительные ситуации
  • Что, если одна из систем временно недоступна? Как обеспечить надёжность (очереди сообщений, ретрансляцию)?
  • Как обрабатывать невалидные или конфликтующие данные?
18.4. Моделирование и проектирование распределённого взаимодействия
Рис. 18.4.1 — Диаграмма UML Sequence. Работа участника воркшопа
«UML-диаграммы последовательности для аналитика: ликбез и примеры использования»
Для распределённых систем (когда компоненты работают на разных узлах, в разных дата-центрах) нужно дополнительно учесть:

1. Сетевая задержка и сбои
  • Важно понимать, что запрос может не дойти, а ответ может задержаться. Нужно продумывать таймауты и повторные попытки.
  • Иногда требуется протокол с подтверждением (ACK), чтобы гарантировать доставку.

2. Согласованность
  • Если данные распределены, может потребоваться eventual consistency (например, после обновления клиента в одной системе, другая узнаёт об этом событии через 5 секунд).
  • В критичных сценариях (финансовые транзакции) нужно более жёсткое согласование (XA-транзакции или паттерны вроде Saga).

3. Нагрузочное тестирование
  • Проверить, способен ли брокер сообщений или API-шлюз выдержать пик («чёрную пятницу», сезонную нагрузку).
  • Эмулировать сценарии, где много параллельных вызовов.

4. Ограничения безопасности
  • Передача данных может требовать шифрования (TLS), аутентификации (OAuth 2.0, JWT), строгого контроля доступа.
  • Внешние API нужно защищать от DDoS, SQL/JSON-инъекций.
Читайте наши статьи по теме:
18.5. Что такое API
Рис. 18.5.1 — Описание спецификации REST API. Работа участника воркшопа «Проектирование интеграции с REST API»
API (Application Programming Interface) — это набор правил и механизмов, по которым одна программа может взаимодействовать с другой. Оно описывает эндпоинты, форматы запросов и ответов, методы (GET, POST, PUT и т. д.), коды ошибок и протоколы аутентификации.

Зачем нужен API:
  1. Интеграция: другие системы могут подключаться к вашему решению без прямого доступа к внутренней структуре БД.
  2. Безопасность: API может давать доступ только к определённым методам и данным, сохраняя логику авторизации.
  3. Расширение: если у системы есть стабильное API, партнёры и разработчики могут создавать надстройки, приложения, интеграции.
  4. Разделение ответственности: фронтенд (UI) отделён от бэкенда, который общается по API. Это упрощает развитие и тестирование.
18.6. Проектирование API
Рис. 18.6.1 — Описание спецификации в Swagger. Работа участника воркшопа «Проектирование сложных API:
OpenAPI + AsyncAPI»
Системный аналитик (совместно с разработчиками) прорабатывает дизайн API: какие методы будут доступны, какова структура JSON/XML, какие параметры нужны.

Важно учитывать:
1. REST, SOAP, GraphQL, gRPC — какой протокол выбрать?
  • REST на HTTP с JSON — самый популярный и простой вариант.
  • SOAP — для строго типизированных и более формальных контрактов (часто используется в legacy-системах).
  • GraphQL — гибкая схема, клиент сам выбирает, какие поля получать.
  • gRPC — двоичный высокопроизводительный протокол с поддержкой stream.

2. Удобство и консистентность
  • Единобразие в именах эндпоинтов (например, /api/v1/orders, /api/v1/customers).
  • Чёткое разграничение (GET/POST/PUT/DELETE).
  • Описание в OpenAPI (Swagger), чтобы другие могли легко понять спецификацию.

3. Версионирование
  • Возможность обновлять API, не ломая старый функционал.
  • Пример: /api/v1/... и /api/v2/... или параметр в заголовках.

4. Безопасность
  • Авторизация по токенам (JWT, OAuth 2.0), HTTPS, ограничение запросов (rate limiting).
  • Логирование и аудит (кто, когда, что вызывал).
Читайте наши статьи по теме:
18.7. Брокеры сообщений
Рис. 18.7.1 — Диаграмма потоков данных с использованием брокера Rabbit MQ. Командная работа участников воркшопа «Проектирование и реализация очередей в брокерах RabbitMQ и Apache Kafka»
Брокер сообщений (RabbitMQ, Apache Kafka, ActiveMQ, NATS) — это программный компонент, который принимает сообщения от одних приложений и передаёт их другим. Он позволяет:

  1. Асинхронное взаимодействие: отправитель не ждёт немедленного ответа, просто публикует сообщение в очередь или топик.
  2. Декуплинг: если получатель недоступен, сообщение может лежать в очереди и будет обработано, когда потребитель появится.
  3. Масштабируемость: можно распределять нагрузку среди многих потребителей.
  4. Гибкую маршрутизацию: можно настроить фильтрацию, трансформацию сообщений, привязку к конкретным очередям.
Читайте наши материалы по теме:
18.8. Проектирование очередей обмена сообщениями
Рис. 18.8.1 — Диаграмма потоков данных с использованием брокера Apache Kafka. Командная работа участников воркшопа «Проектирование и реализация очередей в брокерах RabbitMQ и Apache Kafka»
Когда используются очереди или потоки (Kafka topics), важно:

1. Определить формат сообщения
  • JSON, Avro, Protobuf, бинарные пакеты.
  • Чётко зафиксировать схемы: какие поля, типы данных.

2. Настроить маршрутизацию
  • В RabbitMQ есть exchange (fanout, direct, topic) и очереди; в Kafka есть темы (topic), партиции.
  • Определить ключи маршрутизации, чтобы правильный потребитель получал нужные сообщения.

3. Обрабатывать ошибки и ретраи
  • Если сообщение некорректно, куда оно уходит (dead-letter queue)?
  • Сколько раз делаем повторную попытку?

4. Обеспечить идемпотентность
  • В асинхронной среде сообщение может поступить несколько раз, нужно уметь распознавать «дубликаты», чтобы не создавать лишних операций (например, дважды списывать средства).

5. Безопасность
  • Конфигурация прав доступа, шифрование трафика (SSL), мониторинг очередей.
Вывод по главе 18
Рис. 18.8.1 — Задачи системного аналитика в проектировании интеграций. Слайд из программы курса
«Интеграция систем. Разработка требований и основы проектирования»
Интеграция систем — это фундаментальная составляющая любого современного IT-проекта, где множество приложений и сервисов должны согласованно работать. Системный аналитик играет важную роль, помогая:

  1. Выявить бизнес-процессы и объекты данных, которые пересекаются между системами.
  2. Определить необходимую частоту, формат и режим обмена (синхронный REST/GraphQL, асинхронный событийный).
  3. Разработать спецификации API, продумать протоколы, шифрование, аутентификацию и прочие аспекты.
  4. Протестировать и оценить надёжность, производительность, согласованность распределённых данных.

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

Глава 19. Постановка задач на разработку

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

В этой главе мы рассмотрим основные принципы и подходы к постановке задач в рамках проектов, какие форматы используются в разных методологиях (Agile, Waterfall), как описывать задачи и критерии приёмки, а также как организовать эффективную коммуникацию вокруг задач.

Посмотрите документ пользовательских и системных требований — работа участников курса «Системный анализ. Разработка требований и функциональное проектирование систем»
19.1. Зачем нужна грамотная постановка задач
  1. Сокращение двусмысленности. Чёткое описание задачи уменьшает риск, что разработчик поймёт её «по-своему» и будет делать не то, что ожидает бизнес.
  2. Повышение прозрачности. Видно, какие задачи действительно в работе, какие уже сделаны, какие заблокированы.
  3. Удобство планирования. Когда задача хорошо описана, её проще оценить по трудоёмкости, спланировать в спринте или в классическом графике проекта.
  4. Основа для тестирования. Если критерии приёмки прописаны, тестировщики могут сразу подготовить чек-листы и тест-кейсы.

Грамотно составленная задача переводит требования (часто объёмные) в конкретный шаг разработки, понятный исполнителю и проверяемый приёмкой.

19.2. Различия форматов в Waterfall и Agile
Рис.19.2.1 — Фрагмент User Story Map. Командная работа участников буткемпа «Системный аналитик / проектировщик корпоративных информационных систем»
Waterfall (каскадная модель)
  • Часто оформляются спецификации и технические задания (ТЗ), где каждая функция описана формально.
  • Задачи для разработчиков могут выделяться из этого ТЗ с указанием разделов и пунктов («Реализовать пункт 3.2.1: модуль авторизации»).
  • Изменения проходят формальный Change Request; каждой правке может соответствовать новая «задача на доработку».
Agile (Scrum, Kanban)
  • Используются user stories, разбитые на небольшие задачи (sub-tasks или technical tasks).
  • Есть бэклог (backlog), где задачи лежат по приоритетам.
  • В Scrum задачи берутся в спринт, обсуждаются на планировании, привязываются к конкретным исполнителям.
  • Изменения более гибкие: может добавить или переформулировать задачу в бэклоге, если меняются требования.
В обоих подходах важно сохранять прозрачность: чтоб команда и стейкхолдеры видели, какие задачи идут, какие завершены, какие заблокированы.
19.3. Структура задачи и критерии приёмки
Рис.19.3.1 — Фрагмент постановки задачи на ПО: сценарий варианта использования. Работа участника курса «Системный анализ. Разработка требований и функциональное проектирование систем»
1. Заголовок (Title)
  • Короткое название, описывающее суть задачи: «Реализовать фильтр заказов по статусу», «Добавить отправку e-mail при регистрации».
2. Описание (Description)
  • Детальное пояснение, что нужно сделать.
  • Может включать скриншоты, диаграммы, ссылки на прототипы, если речь идёт об интерфейсе.
  • В Agile-формате часто указывают User Story: «Как [роль], я хочу [действие], чтобы [результат]».
3. Критерии приёмки (Acceptance Criteria)
  • Чёткий список пунктов, по которым понимаем, что задача выполнена правильно.
  • Пример:
— «Пользователь на экране заказа видит кнопку «Фильтр»;
— При нажатии выпадает список статусов: «Новый», «Оплачен», «Отменён»;
— Выбираем статус — список заказов обновляется в течение 1 секунды, отображая только заказы с этим статусом;
— Если заказов нет, показывается сообщение «Нет заказов в данном статусе».
  • Acceptance Criteria служат базой для QA-тестов.
4. Дополнительная информация
  • Технические детали (какой API-эндпоинт трогаем, какие таблицы в БД).
  • Ссылки на связанные задачи или эпики.
  • Зависимости (к примеру, «Нельзя начинать, пока не реализована авторизация», «Работаем вместе с задачей DEV-123»).
5. Оценка и приоритет
  • В Scrum/Agile часто используют Story Points для оценки.
  • Приоритет: Must, Should, Could или High, Medium, Low.
19.4. Инструменты для управления задачами
Рис.19.4.1 — Инструменты для управления задачами
Для управления задачами при проектировании и разработке программного обеспечения наиболее востребованы профессиональные инструменты вроде Jira, YouTrack и Azure DevOps. Jira популярна в Agile-среде за гибкую настройку рабочих процессов и широкие возможности мониторинга (доски Kanban/Scrum, отчёты по спринтам, интеграции с системами контроля версий). YouTrack выделяется быстрым вводом команд, удобными фильтрами и встроенным тайм-трекингом, а также возможностью локальной установки. Azure DevOps совмещает управление задачами с репозиториями кода, тестированием и CI/CD, что облегчает полный цикл разработки.

Для небольших IT-команд или стартапов подойдут более простые инструменты — Trello, Asana или Google Таблицы (на первых порах). Но по мере роста такие решения могут оказаться недостаточно гибкими: понадобится учёт зависимости задач, планирование релизов и аналитика по трудозатратам. При этом обращайте внимание на тарифы, особенно если планируете масштабироваться: у Jira и YouTrack есть бесплатные планы для маленьких коллективов.

В российских реалиях нередко выбирают отечественные системы для он-премис развертывания (например, серверные версии Jira или локальный YouTrack). Также набирают популярность Planfix и Битрикс24 — их используют команды разработки, которым важна интеграция с 1С или хранение данных на территории РФ. При выборе инструмента учитывайте специфику процесса (Scrum, Kanban или свой собственный workflow), интеграции с VCS и CI/CD, а также уровень подготовки участников.

Системный аналитик в этих программах обычно отвечает за формирование и ведение требований к продукту, описание пользовательских историй и критериев приёмки, а также за координацию между бизнес-заказчиками и командой разработки. Он заводит задачи или «эпики», прикладывает к ним детальные спецификации, схемы, ссылки на внешнюю документацию (wiki, Confluence), добавляет комментарии по ходу обсуждения. Системный аналитик контролирует соответствие задач бизнес-требованиям, помогает разработчикам и тестировщикам уточнять детали, вносит изменения в описания при смене приоритетов, а также формирует связи между задачами, чтобы фиксировать зависимости и прослеживать влияние каждой доработки на общее решение.
19.5. Практические советы по постановке задач
Рис.19.3.1 — Фрагмент постановки задачи на ПО: расчёт нагрузки на систему. Командная работа участников буткемпа «Системный аналитик / проектировщик корпоративных информационных систем»
1. «Одна задача — одна чёткая цель»
  • Избегать «мешка» разных доработок. Лучше разделить задачи, если они касаются разных частей системы или решают разные проблемы.
  • Так легче тестировать и оценивать результат.

2. Использовать «Definition of Ready»
  • В Agile-командах бывает соглашение: задача не берётся в спринт, пока не прописаны критерии приёмки, нет необходимых макетов, не ясны зависимости.
  • Это снижает риск, что задача «зависнет» в процессе разработки из-за неясных деталей.

3. Заботиться о понятности
  • Писать на языке, понятном разработчику и тестировщику, избегать лишней «воды».
  • Если есть сложная логика, лучше приложить диаграмму (Sequence, Activity), чем пытаться описать её длинным текстом.

4. Стараться сохранять актуальность
  • Если по ходу выясняется, что задача меняется, надо обновить описание, а не держать важные детали в чатах.
  • Так остальные члены команды (тестировщик, технический писатель) не будут работать с устаревшей информацией.

5. Обсуждать лично при сложных кейсах
  • Часто проще «пройтись» по задаче на коротком митинге/колле, чем писать длинную переписку.
  • Аналитик может показать прототип, прояснить нюансы, ответить на вопросы команды.
19.6. Согласование задачи и приёмка
Рис.19.6.1 — Фрагмент постановки задачи на ПО: требование к информационной безопасности при аутентификации. Работа участника воркшопа «Основы разработки требований к информационной безопасности ИТ-систем»
После того как задача реализована, наступает момент приёмки. Здесь полезно вернуться к критериям приёмки:
  1. Ревью кода (Code Review) — разработчики смотрят друг за другом, нет ли нарушений стандартов, ошибок.
  2. Тестирование — QA-инженер или сам аналитик проверяет, соответствует ли результат требованиям, не сломалось ли что-то ещё.
  3. Демонстрация — если в конце спринта или итерации, на Review показывают, как работает реализованная задача.
  4. Фидбэк — если есть пожелания или обнаруженные неточности, они могут оформляться в виде новой задачи, если не являются критической ошибкой.
Если всё соответствует критериям приёмки, задача закрывается и переходит в статус «Done» (в Agile) или формально «Принята» (в классическом проекте).
Вывод по главе 19
Постановка задач на разработку — жизненно важный элемент в работе системного аналитика. Здесь все наработанные требования (функциональные, нефункциональные), сценарии использования, прототипы и уточнения превращаются в конкретные задачи, понятные исполнителям. От качества и ясности этих задач зависит:
  1. Эффективность разработки — меньше переделок и недопонимания;
  2. Скорость и прозрачность — команда чётко видит, что делать, как это проверить, и когда задача считается выполненной;
  3. Качество конечного продукта — если критерии приёмки прописаны грамотно, система в итоге удовлетворяет потребностям пользователей и бизнес-заказчиков.
Системный аналитик может выполнять роль «моста» между бизнесом (который формулирует что нужно) и разработчиками (которые воплощают это в коде), обеспечивая точное и эффективное формирование задач.
Читайте наши материалы по теме:

Об авторе

■ Другие статьи по теме Архитектура

Показать еще

■ Другие статьи по теме Интеграция

■ Другие статьи на тему Базы данных

Показать еще

■ Другие статьи на тему User Stories и Use Cases

■ Другие статьи на тему Требований

Показать еще

■ Другие статьи на тему Бизнес-анализ

■ Другие статьи на тему Профессия и трудоустройство

Показать еще

■ Другие статьи на тему Проектное управление

■ Другие статьи на тему Менеджмент и архитектура предприятия

Показать еще

■ Другие статьи на тему Дизайн интерфейсов и исследования