Какой вариант выберете?
Anonymous Poll
63%
Брокер сообщений / очередь
26%
REST API
5%
Webhook
5%
Накопление и отправка пакетами
Продолжаем серию постов с задачами по поиску оптимального способа интеграции
Все прошедшие задания и разборы эксперта можете найти по хештегу — #задача_от@systems_education
Ваша задача все такая же — выбрать наиболее подходящий способ интеграции к описанной ситуации. Через несколько дней выложим пост с разбором от Елены Бенкен, эксперта школы SE и автора курса «Интеграция систем. Разработка требований и основы проектирования».
Варианты решений:
— Брокер сообщений / очередь (например, MQTT, RabbitMQ, Kafka)
— REST API: вызов на каждый отправленный датчиком event
— Webhook: устройство «вызывает» URL при каждом событии
— Накопление и отправка пакетами (например, раз в час одним файлом)
Как организовать передачу событий от IoT-датчиков? ☝🏻
Совсем скоро сравним ваши ответы с разбором от эксперта!
Если этот вопрос пока вызывает у вас трудности, рекомендуем пройти курс «Интеграция систем. Разработка требований и основы проектирования», на котором вы под руководством эксперта сможете разобраться в теме интеграций и научиться проектировать взаимодействие ИТ-систем.
Подробнее о курсе
🔔 Следите за обновлениями в канале, если не хотите пропустить разбор от эксперта и следующие задачки по поиску оптимального способа интеграции!
#интеграции@systems_education #курс@systems_education
Все прошедшие задания и разборы эксперта можете найти по хештегу — #задача_от@systems_education
Ваша задача все такая же — выбрать наиболее подходящий способ интеграции к описанной ситуации. Через несколько дней выложим пост с разбором от Елены Бенкен, эксперта школы SE и автора курса «Интеграция систем. Разработка требований и основы проектирования».
Ситуация — Реальное время для событий от IoT-устройств
Задача: множество IoT-датчиков (смарт-устройств) в режиме реального времени отправляют небольшие сообщения (события) на сервер для мониторинга и анализа. Нужно обеспечить минимальную задержку и обработку потока данных от сотен устройств одновременно.
Варианты решений:
— Брокер сообщений / очередь (например, MQTT, RabbitMQ, Kafka)
— REST API: вызов на каждый отправленный датчиком event
— Webhook: устройство «вызывает» URL при каждом событии
— Накопление и отправка пакетами (например, раз в час одним файлом)
Как организовать передачу событий от IoT-датчиков? ☝🏻
Совсем скоро сравним ваши ответы с разбором от эксперта!
Если этот вопрос пока вызывает у вас трудности, рекомендуем пройти курс «Интеграция систем. Разработка требований и основы проектирования», на котором вы под руководством эксперта сможете разобраться в теме интеграций и научиться проектировать взаимодействие ИТ-систем.
Подробнее о курсе
🔔 Следите за обновлениями в канале, если не хотите пропустить разбор от эксперта и следующие задачки по поиску оптимального способа интеграции!
#интеграции@systems_education #курс@systems_education
✍2🤓1
Опубликовали статью Анны Вичуговой на тему «Пакетный и потоковый ETL для PostgreSQL с AirFlow и с коннекторами Kafka»
В этой статье на практических примерах рассматривается, как и с помощью каких инструментов можно реализовать потоковый и пакетный ETL-процессы. В статье даются рекомендации по проектированию ETL-конвейеров.
Подробно рассматривается:
— что такое ETL и для чего он нужен?
— на что обратить внимание при проектировании ETL?
— пример проектирования пакетного ETL с Apache Airflow
— пример проектирования потокового ETL с Kafka
Статья может быть интересна системным и бизнес-аналитикам, которые хотят получить общее представление о проектировании ETL.
Почитать можно тут
#статьи@systems_education
В этой статье на практических примерах рассматривается, как и с помощью каких инструментов можно реализовать потоковый и пакетный ETL-процессы. В статье даются рекомендации по проектированию ETL-конвейеров.
Подробно рассматривается:
— что такое ETL и для чего он нужен?
— на что обратить внимание при проектировании ETL?
— пример проектирования пакетного ETL с Apache Airflow
— пример проектирования потокового ETL с Kafka
Статья может быть интересна системным и бизнес-аналитикам, которые хотят получить общее представление о проектировании ETL.
Почитать можно тут
#статьи@systems_education
systems.education
■ Статья. Потоковый и пакетный ETL для PostgreSQL с коннекторами Kafka и AirFlow
🔥5❤1
Воркшоп «Проектирование интеграции с REST API»
🔹Когда?
30-31 Августа
🔹Воркшоп будет полезен тем, кто хочет:
— познакомиться с REST API
— научиться проектировать интеграцию «с нуля»
— описывать REST-интерфейсы в виде, пригодном для разработки
🔹Что получишь от воркшопа?
Пошаговую методику и шаблон описания интеграции
— Участники проанализируют процесс взаимодействия систем, потоки данных и опишут REST-like API
— Поймут, как аналитик решает интеграционные задачи
— Подготовят постановку задачи на интеграцию на основе шаблона
Регистрация
#воркшоп@systems_education #интеграция@systems_education #RESTAPI@systems_education
🔹Когда?
30-31 Августа
🔹Воркшоп будет полезен тем, кто хочет:
— познакомиться с REST API
— научиться проектировать интеграцию «с нуля»
— описывать REST-интерфейсы в виде, пригодном для разработки
🔹Что получишь от воркшопа?
Пошаговую методику и шаблон описания интеграции
— Участники проанализируют процесс взаимодействия систем, потоки данных и опишут REST-like API
— Поймут, как аналитик решает интеграционные задачи
— Подготовят постановку задачи на интеграцию на основе шаблона
Регистрация
#воркшоп@systems_education #интеграция@systems_education #RESTAPI@systems_education
❤1🔥1
⭐️ Наша программа переподготовки «Systems Analyst Bootcamp» попала на платформу TProger в подборку 7 курсов, с которых реально стартуют в IT в 2025. Найти ее можно тут.
Профессия системного аналитика — одна из точек входа в IT, которая также предлагает в дальнейшем много путей роста в этой сфере (архитектура, управление продуктом или программирование). На программе вы за 3 месяца полностью погрузитесь в реальные задачи системного аналитика, поработав с заказчиком над реальным проектом под присмотром экспертов. Это гарантирует быстрый и уверенный старт вашей карьеры СА.
Будем рады видеть вас на нашем буткемпе! Ознакомиться с учебной программой можно тут.
#буткемп@systems_education
Профессия системного аналитика — одна из точек входа в IT, которая также предлагает в дальнейшем много путей роста в этой сфере (архитектура, управление продуктом или программирование). На программе вы за 3 месяца полностью погрузитесь в реальные задачи системного аналитика, поработав с заказчиком над реальным проектом под присмотром экспертов. Это гарантирует быстрый и уверенный старт вашей карьеры СА.
Будем рады видеть вас на нашем буткемпе! Ознакомиться с учебной программой можно тут.
#буткемп@systems_education
❤5🔥5👏3
Публикуем разбор задачи по интеграции от эксперта школы Systems.Education Елены Бенкен! Описание ситуации и варианты ответов можно найти в этом посте.
✔️ Правильное решение: асинхронная передача через брокер сообщений / платформу стриминга событий. Для IoT-датчиков оптимально использовать специализированный брокер (например, MQTT) или систему потоковой обработки сообщений (Kafka, RabbitMQ и др.). Устройства публикуют события в очередь/топик, а серверы-потребители их обрабатывают в реальном времени. Такой подход масштабируется на тысячи событий в секунду и не приводит к перегрузке.
❗️ Почему не остальные:
— REST API на каждый event — в случае сотен устройств и постоянных сообщений это вызовет лавину HTTP-запросов. Нагрузка на сеть и сервер возрастёт, а время отклика будет выше, чем при работе через легковесные протоколы вроде MQTT.
— Webhook от устройств — неприменим, ведь webhook подразумевает вызов от сервера к приёмнику. Здесь же датчики сами инициируют отправку данных. Держать открытые адреса для webhooks на каждом устройстве невозможно.
— Накопление и разовая отправка — противоречит требованию реального времени. Если копить данные и отправлять их порциями раз в час или даже раз в несколько минут, мы теряем ценность мгновенного реагирования на события IoT (например, аварийные сигналы должны приходить сразу, а не через час).
(ESB тоже не идеален для такой задачи — высокая частота сообщений перегрузит шину, но этот вариант и не предлагался напрямую.)
🔔 Через несколько недель будет еще один шанс проверить свои знания на новой задачке!
Все прошедшие задания и разборы эксперта можете найти по хештегу — #задача_от@systems_education
На курсе вы «Интеграция систем. Разработка требований и основы проектирования» вы сможете разобраться в теме интеграций и научиться проектировать взаимодействие ИТ-систем
Подробнее
#задача_от@systems_education
Ситуация — Реальное время для событий от IoT-устройств
— REST API на каждый event — в случае сотен устройств и постоянных сообщений это вызовет лавину HTTP-запросов. Нагрузка на сеть и сервер возрастёт, а время отклика будет выше, чем при работе через легковесные протоколы вроде MQTT.
— Webhook от устройств — неприменим, ведь webhook подразумевает вызов от сервера к приёмнику. Здесь же датчики сами инициируют отправку данных. Держать открытые адреса для webhooks на каждом устройстве невозможно.
— Накопление и разовая отправка — противоречит требованию реального времени. Если копить данные и отправлять их порциями раз в час или даже раз в несколько минут, мы теряем ценность мгновенного реагирования на события IoT (например, аварийные сигналы должны приходить сразу, а не через час).
(ESB тоже не идеален для такой задачи — высокая частота сообщений перегрузит шину, но этот вариант и не предлагался напрямую.)
🔔 Через несколько недель будет еще один шанс проверить свои знания на новой задачке!
Все прошедшие задания и разборы эксперта можете найти по хештегу — #задача_от@systems_education
На курсе вы «Интеграция систем. Разработка требований и основы проектирования» вы сможете разобраться в теме интеграций и научиться проектировать взаимодействие ИТ-систем
Подробнее
#задача_от@systems_education
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥1😁1
VK Видео
Компромиссы в дизайне распределенных NoSQL баз данных, CAP-теорема в реальном мире • Андрей Манаков
Андрей Манаков выступил на третьей конференции Systems Design Online с докладом на тему «Компромиссы в дизайне распределенных NoSQL баз данных, CAP-теорема в реальном мире» Тайм-код доклада: 00:00 О докладе и докладчике 00:35 Доисторические базы данных 1950…
Опубликовали запись доклада Андрея Манакова на тему «Компромиссы в дизайне распределенных NoSQL баз данных, CAP-теорема в реальном мире» с третьей онлайн-конференции Systems Design Online
Тайм-код доклада:
00:00 О докладе и докладчике
00:35 Доисторические базы данных 1950-1960
01:14 Прорыв Эдгара Ф. Кодда в области баз данных 1970
01:50 Эра реляционных БД 1970-1980
03:05 Вызовы 1990-ых годов
03:52 Вертикальное масштабирование
04:32 Логически разбиваем базу
05:29 Жертвуем моделью Кодда
06:45 Кеширование
07:45 CAP-теорема
09:06 PACELC
10:09 Когда выбирать реляционные базы?
11:19 Репликация
12:51 Шардирование
13:46 NoSQL (2000-е)
14:51 Распределенные транзакции
17:29 Distributed SQL — 2010-ые
19:49 CAP-теорема на примере Redis
21:34 Подробнее про согласованность
21:59 Согласованность: практика
23:12 ScyllaDB
24:20 CAP-теорема на примере ScyllaDB
26:35 ScyllaDB: разрешение конфликтов
27:47 Database engine: LST- и B-дерево
30:11 Современные тренды
32:03 Выводы
Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК
✍️ Если вам интересна тема доклада, рекомендуем рассмотреть курс «Архитектура ИТ-решения: Проектирование и реализация MVP» (подробнее)
#конференция@systems_education
Тайм-код доклада:
00:00 О докладе и докладчике
00:35 Доисторические базы данных 1950-1960
01:14 Прорыв Эдгара Ф. Кодда в области баз данных 1970
01:50 Эра реляционных БД 1970-1980
03:05 Вызовы 1990-ых годов
03:52 Вертикальное масштабирование
04:32 Логически разбиваем базу
05:29 Жертвуем моделью Кодда
06:45 Кеширование
07:45 CAP-теорема
09:06 PACELC
10:09 Когда выбирать реляционные базы?
11:19 Репликация
12:51 Шардирование
13:46 NoSQL (2000-е)
14:51 Распределенные транзакции
17:29 Distributed SQL — 2010-ые
19:49 CAP-теорема на примере Redis
21:34 Подробнее про согласованность
21:59 Согласованность: практика
23:12 ScyllaDB
24:20 CAP-теорема на примере ScyllaDB
26:35 ScyllaDB: разрешение конфликтов
27:47 Database engine: LST- и B-дерево
30:11 Современные тренды
32:03 Выводы
Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК
✍️ Если вам интересна тема доклада, рекомендуем рассмотреть курс «Архитектура ИТ-решения: Проектирование и реализация MVP» (подробнее)
#конференция@systems_education
✍3❤2🔥1
Definition of Done оберегает нас от вечного «ну почти готово»
Каждый член команды хоть раз сталкивался с ситуацией: работа почти закончена, но до полного завершения постоянно что-то «чуть-чуть» не дотягивает. В Agile-проектах от этой проблемы защищает Definition of Done (DoD) — единый набор критериев готовности, при соблюдении которых результат действительно считается завершённым и готовым для пользователя. Проще говоря, DoD — это формальный чек-лист качества: если все пункты выполнены, то задача done, а не «почти».
Одновременно с DoD каждая пользовательская история имеет свои Acceptance Criteria (AC) — критерии приёмки конкретной функции. AC описывают функциональные условия, при которых история удовлетворяет потребностям пользователя. Они уникальны для каждой истории и служат ориентиром, что именно должно работать. В то время как AC фокусируются на результатах для пользователя, DoD отвечает за общие стандарты качества и завершённости работы.
Как DoD и AC спасают от ловушки «почти готово»? Без чётких критериев команда может поспешно объявить историю готовой, хотя часть работ — тестирование, документация или согласования — ещё не завершены. Именно так и возникает печально известное «ну, мы почти всё сделали». Итог — выпуск функциональности откладывается, пока в спешке доделываются упущенные мелочи, а релиз тормозится. Definition of Done не допускает таких ситуаций: история не перейдёт в статус «Done», пока не выполнены все требования качества. DoD выступает щитом, который отсекает незавершённые задачи и не даёт выпустить сырой продукт. Приёмочные же критерии (AC) гарантируют, что по функционалу учтены все оговоренные сценарии.
👥 Важно, что формулировать DoD (как и AC) должна вся команда — совместно и заранее. В обсуждении участвуют аналитики, проектировщики, разработчики, тестировщики и владелец продукта, чтобы у всех было единое понимание, что считать готовым результатом. Такой общий подход повышает прозрачность: «готово» означает одно и то же для всех участников.
На воркшопе «Бизнес-анализ. Разработка пользовательских требований и постановка задач на разработку» у вас будет возможность на практике познакомиться с DoD и многими другими техниками, которые помогают в описании постановки задачи на разработку ИТ-системы. Подробнее тут.
#Agile@systems_education #воркшоп@systems_education
Каждый член команды хоть раз сталкивался с ситуацией: работа почти закончена, но до полного завершения постоянно что-то «чуть-чуть» не дотягивает. В Agile-проектах от этой проблемы защищает Definition of Done (DoD) — единый набор критериев готовности, при соблюдении которых результат действительно считается завершённым и готовым для пользователя. Проще говоря, DoD — это формальный чек-лист качества: если все пункты выполнены, то задача done, а не «почти».
Одновременно с DoD каждая пользовательская история имеет свои Acceptance Criteria (AC) — критерии приёмки конкретной функции. AC описывают функциональные условия, при которых история удовлетворяет потребностям пользователя. Они уникальны для каждой истории и служат ориентиром, что именно должно работать. В то время как AC фокусируются на результатах для пользователя, DoD отвечает за общие стандарты качества и завершённости работы.
Как DoD и AC спасают от ловушки «почти готово»? Без чётких критериев команда может поспешно объявить историю готовой, хотя часть работ — тестирование, документация или согласования — ещё не завершены. Именно так и возникает печально известное «ну, мы почти всё сделали». Итог — выпуск функциональности откладывается, пока в спешке доделываются упущенные мелочи, а релиз тормозится. Definition of Done не допускает таких ситуаций: история не перейдёт в статус «Done», пока не выполнены все требования качества. DoD выступает щитом, который отсекает незавершённые задачи и не даёт выпустить сырой продукт. Приёмочные же критерии (AC) гарантируют, что по функционалу учтены все оговоренные сценарии.
👥 Важно, что формулировать DoD (как и AC) должна вся команда — совместно и заранее. В обсуждении участвуют аналитики, проектировщики, разработчики, тестировщики и владелец продукта, чтобы у всех было единое понимание, что считать готовым результатом. Такой общий подход повышает прозрачность: «готово» означает одно и то же для всех участников.
На воркшопе «Бизнес-анализ. Разработка пользовательских требований и постановка задач на разработку» у вас будет возможность на практике познакомиться с DoD и многими другими техниками, которые помогают в описании постановки задачи на разработку ИТ-системы. Подробнее тут.
#Agile@systems_education #воркшоп@systems_education
❤5👍1
Дайджест курсов и воркшопов школы на июль 🐝
Сохраняйте пост, чтобы потом не потерять!
🔹Курсы:
1️⃣ Бизнес-анализ + ИИ. Разработка требований к ИТ-решению с использованием нейросетей (с 5 июля)
Курс для опытных бизнес-аналитиков, системных аналитиков и проектировщиков информационных систем, которые хотят развить свои практики постановки задачи на выбор, разработку и внедрение ИТ-решений при автоматизации бизнеса
Регистрация
2️⃣ Системный анализ + ИИ. Разработка требований и функциональное проектирование систем (с 7 июля)
Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения
Регистрация
3️⃣ Интеграция систем. Разработка требований и основы проектирования (с 12 июля (онлайн), с 24 июля (очно))
На курсе вы:
— Изучите технологии интеграции
— Спроектируете рабочую интеграцию, которую можно будет использовать в качестве образца в работе или положить в Портфолио
— Научитесь документировать межсистемное взаимодействие
Регистрация
4️⃣ Архитектура ИТ-решения: проектирование и реализация MVP (с 28 июля)
Вы будете уметь проектировать и реализовывать двухзвенную, трехзвенную и EDA-архитектуры на открытом стеке (PostgreSQL, Kafka, Python)
Регистрация
🔹Воркшопы:
1️⃣ Use Case: основы (с 5 июля)
Воркшоп будет полезен начинающим системным аналитикам, которые хотят:
— научиться писать Use Cases
— строить диаграмму сценариев использования
— формировать пакеты и реестр Use Cases
— не допускать типичных ошибок
Регистрация
2️⃣ Проектирование архитектуры цифровых платформ (с 23 июля)
Цель обучения — Научиться проектировать системы цифровых маркетплейсов, где площадка соединяет поставщиков товаров и услуг (такси, доставка еды, обмен контента) с потребителями (gig economy).
Регистрация
3️⃣ UML-диаграммы последовательности для аналитика: ликбез и примеры использования (30 июля)
На воркшопе за 3 часа вы построите sequence диаграммы и убедитесь что:
— Cтроить sequence диаграммы несложно
— UML диаграммы удобно читать и легко понимать
— UML — отличный инструмент проектирования поведения систем
Регистрация
#дайджест@systems_education
Сохраняйте пост, чтобы потом не потерять!
🔹Курсы:
1️⃣ Бизнес-анализ + ИИ. Разработка требований к ИТ-решению с использованием нейросетей (с 5 июля)
Курс для опытных бизнес-аналитиков, системных аналитиков и проектировщиков информационных систем, которые хотят развить свои практики постановки задачи на выбор, разработку и внедрение ИТ-решений при автоматизации бизнеса
Регистрация
2️⃣ Системный анализ + ИИ. Разработка требований и функциональное проектирование систем (с 7 июля)
Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения
Регистрация
3️⃣ Интеграция систем. Разработка требований и основы проектирования (с 12 июля (онлайн), с 24 июля (очно))
На курсе вы:
— Изучите технологии интеграции
— Спроектируете рабочую интеграцию, которую можно будет использовать в качестве образца в работе или положить в Портфолио
— Научитесь документировать межсистемное взаимодействие
Регистрация
4️⃣ Архитектура ИТ-решения: проектирование и реализация MVP (с 28 июля)
Вы будете уметь проектировать и реализовывать двухзвенную, трехзвенную и EDA-архитектуры на открытом стеке (PostgreSQL, Kafka, Python)
Регистрация
🔹Воркшопы:
1️⃣ Use Case: основы (с 5 июля)
Воркшоп будет полезен начинающим системным аналитикам, которые хотят:
— научиться писать Use Cases
— строить диаграмму сценариев использования
— формировать пакеты и реестр Use Cases
— не допускать типичных ошибок
Регистрация
2️⃣ Проектирование архитектуры цифровых платформ (с 23 июля)
Цель обучения — Научиться проектировать системы цифровых маркетплейсов, где площадка соединяет поставщиков товаров и услуг (такси, доставка еды, обмен контента) с потребителями (gig economy).
Регистрация
3️⃣ UML-диаграммы последовательности для аналитика: ликбез и примеры использования (30 июля)
На воркшопе за 3 часа вы построите sequence диаграммы и убедитесь что:
— Cтроить sequence диаграммы несложно
— UML диаграммы удобно читать и легко понимать
— UML — отличный инструмент проектирования поведения систем
Регистрация
#дайджест@systems_education
❤1
👥 Ключевая ценность нашей школы — это особый подход к обучению. Мы стремимся, чтобы каждый поток курса или воркшопа был наполнен полезными инстайтами, практикой и обратной связью от эксперта. Именно бутиковый формат обучения в малых группах позволяет добиться той близости между обучающимися и преподавателям, которая гарантирует целостное освоение темы и продуктивную ее отработку.
Обратная связь студентов последнего потока воркшопа «Паттерны проектирования микросервисной архитектуры и нотация С4» говорит сама за себя — такой подход в обучении однозначно работает!
💬 Отзывы можно почитать на карточках
Если вы давно хотели бы изучить нотацию С4, приглашаем вас на ближайший поток под руководством Полины Комковой.
Подробнее о воркшопе
#воркшоп@systems_education #C4Notation@systems_education #C4@systems_education #отзывы_выпускников
Обратная связь студентов последнего потока воркшопа «Паттерны проектирования микросервисной архитектуры и нотация С4» говорит сама за себя — такой подход в обучении однозначно работает!
💬 Отзывы можно почитать на карточках
Если вы давно хотели бы изучить нотацию С4, приглашаем вас на ближайший поток под руководством Полины Комковой.
Подробнее о воркшопе
#воркшоп@systems_education #C4Notation@systems_education #C4@systems_education #отзывы_выпускников
❤4🔥2
В школу SE на днях обратился Сэм Альтман (глава OpenAI, отец ChatGPT и футурист) и попросил:
Для решения задачи мы подготовили план обследования:
1. Изучить бизнес-задачу и видение заказчика
2. Смоделировать контекст проекта
3. Построить контекстную диаграмму
4. Сформулировать перечень ФТ
5. Сформулировать перечень НФТ
В рамках первого этапа обследования мы провели интервью с Сэмом. Вопросы и ответы смотрите на картинках. ☝️
Продолжение результатов анализа ищите в следующих постах по хештегу #Сэм@systems_education
Если вы хотите научиться так же качественно разрабатывать пользовательские и системные требования, будем рады видеть вас на ближайших потоках курса «Системный анализ + ИИ. Разработка требований и функциональное проектирование систем». Подробнее тут.
Автор поста — Елена Беляева
Под редакцией SE
#курс@systems_education #системный_анализ@systems_education
«Помогите мне сделать GPT настолько незаметным, что люди перестанут бояться сингулярности».
Для решения задачи мы подготовили план обследования:
1. Изучить бизнес-задачу и видение заказчика
2. Смоделировать контекст проекта
3. Построить контекстную диаграмму
4. Сформулировать перечень ФТ
5. Сформулировать перечень НФТ
В рамках первого этапа обследования мы провели интервью с Сэмом. Вопросы и ответы смотрите на картинках. ☝️
Продолжение результатов анализа ищите в следующих постах по хештегу #Сэм@systems_education
Если вы хотите научиться так же качественно разрабатывать пользовательские и системные требования, будем рады видеть вас на ближайших потоках курса «Системный анализ + ИИ. Разработка требований и функциональное проектирование систем». Подробнее тут.
Автор поста — Елена Беляева
Под редакцией SE
#курс@systems_education #системный_анализ@systems_education
🔥11😁7❤2🥰1