Очный курс «Системный анализ. Разработка требований в ИТ-проектах»
🔹Когда старт?
20 марта
🔹Где будет проходить?
Очно в Москве
🔹Этот курс для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
🔹Что получите от курса:
— Научитесь выявлять и формулировать требования к программной системе
— Создадите законченный документ Требований к ПО (SRS)
Программа курса охватывает полный цикл разработки требований к ПО, начиная от анализа бизнес-требований до сборки итогового документа. Курс подробно рассматривает моделирование функциональных требований, контроль качества, а также формулировку ожиданий к производительности и надёжности программного продукта.
Регистрация
#курс #системный_анализ
🔹Когда старт?
20 марта
🔹Где будет проходить?
Очно в Москве
🔹Этот курс для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
🔹Что получите от курса:
— Научитесь выявлять и формулировать требования к программной системе
— Создадите законченный документ Требований к ПО (SRS)
Программа курса охватывает полный цикл разработки требований к ПО, начиная от анализа бизнес-требований до сборки итогового документа. Курс подробно рассматривает моделирование функциональных требований, контроль качества, а также формулировку ожиданий к производительности и надёжности программного продукта.
Регистрация
#курс #системный_анализ
👍4❤2
Как Event Storming позволяет говорить на одном языке с бизнесом и разработчиками?
Один из ключевых вызовов в любой IT-команде — наладить эффективную коммуникацию между бизнесом и разработчиками. Когда аналитики, продакт-менеджеры и инженеры видят мир по-разному, это неизбежно приводит к ошибкам и задержкам. Event Storming — это техника, которая помогает устранить барьеры и выстроить общий язык для всех участников процесса.
Листайте карточки, где мы рассказали, почему Event Storming так эффективен? ☝️
Приглашаем вас на воркшоп «Event Storming как техника моделирования предметной области и выявления микросервисов». Вы узнаете, как применять методику для работы с бизнесом и командой разработки, научитесь выстраивать общую картину процесса и получать ценные инсайты уже на ранних этапах проекта.
Регистрация
Один из ключевых вызовов в любой IT-команде — наладить эффективную коммуникацию между бизнесом и разработчиками. Когда аналитики, продакт-менеджеры и инженеры видят мир по-разному, это неизбежно приводит к ошибкам и задержкам. Event Storming — это техника, которая помогает устранить барьеры и выстроить общий язык для всех участников процесса.
Листайте карточки, где мы рассказали, почему Event Storming так эффективен? ☝️
Приглашаем вас на воркшоп «Event Storming как техника моделирования предметной области и выявления микросервисов». Вы узнаете, как применять методику для работы с бизнесом и командой разработки, научитесь выстраивать общую картину процесса и получать ценные инсайты уже на ранних этапах проекта.
Регистрация
👍3🔥2❤1
22 января (ср) в 19:00 МСК пройдет вебинар в формате круглого стола на тему «Как стать системным аналитиком в 2025 году?», на котором мы с приглашенными гостями и экспертами школы ответим на самые популярные вопросы и обсудим актуальные проблемы в процессе построения карьеры СА.
▫️Формат вебинара
Вместе с экспертами школы и приглашенными гостями мы подискуссируем на темы актуальных вопросов, которые возникают у людей в начале карьеры СА:
— Какие «шишки вы набили» в процессе становления СА?
— На что сейчас смотрят в первую очередь работодатели при рассмотрении кандидатов?
— Какие факты в резюме сейчас могут стать решающими для работодателей?
— Какие самые неожиданные, каверзные вопросы вам могут попасться на собеседовании?
— Сколько прошло времени с конца обучения на буткемпе по системному анализу до получения первого офера?
— Какой вы бы дали совет людям, которые хотят стать СА, но боятся сильной конкуренции на рынке?
▫️Кому будет полезен вебинар:
— Не системным аналитикам
которые хотят освоить практики проектирования информационных систем и/или стать системным аналитиком
— Действующим системным аналитикам
которые хотят систематизировать знания в области проектирования ИС
— Старшим системным аналитикам
кто хочет освоить современные практики проектирования ИС
▫️Эксперты вебинара:
👤 Татьяна Назаренко
Ведущий тренер и менеджер буткемпа «Системный аналитик: Проектировщик корпоративных информационных систем»
— Опыт работы: 10 лет
— Ведущий научный сотрудник КБ ГИЦ МГТУ Станкин
— Специальность: информационно-управляющие системы и технологии
👤 Мира Карлаш
Соавтор буткемпа «Системный аналитик: Проектировщик корпоративных информационных систем»
— Опыт работы в роли от разработчика до менеджера проектов и системного аналитика;
— Клиенты — международные компании с миллионами ежемесячных пользователей;
— Дополнительное образование в сфере Data Analysis и нейропсихологии от университетов топ-25 по версии The World University Rankings (2022);
— Выступления на всероссийских конференциях, участие в международных форумах.
▫️Приглашенные гости:
Все гости являются выпускниками буткемпа «Системный аналитик: Проектировщик корпоративных информационных систем»
👥 Ланкевич Павел
— До СА работал интегратором — внедренцем интеграционных решений, также руководил командой разработки, совмещая роли РП, DM, SA и в какой-то степени бизнес-архитектора.
— Работает Lead SA в компании РОЛЬФ, имеет за плечами двухлетний опыт в профессии
— За период работы провел онбординг 5 SA в нашей команде
👥 Миронов Илья
— До буткемпа работал в телекоме системным аналитиком, после буткемпа пошёл в другую компанию. Сейчас работаю на проекте инвентаризации материальных ценностей и управлению ими в крупной компании.
— Действующий системный аналитик
👥 Ахмадеев Георгий
— Аналитик со стажем 4 года
— Ранее работал бизнес-аналитиком, после буткемпа стал системным аналитиком, через 6 месяцев стал старшим аналитиком
👥 Неугодникова Александра
— Работает системным аналитиком в банковской сфере, имеет опыт работы в финансовом подразделении банка, риск-менеджменте и в кредитовании юридических лиц. Стаж в кредитных организациях до IT свыше 10 лет.
— До буткемпа устроилась на позицию системного аналитика в банк топ-3. Буткемп помог пройти испытательный срок.
Регистрация
Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.
▫️Формат вебинара
Вместе с экспертами школы и приглашенными гостями мы подискуссируем на темы актуальных вопросов, которые возникают у людей в начале карьеры СА:
— Какие «шишки вы набили» в процессе становления СА?
— На что сейчас смотрят в первую очередь работодатели при рассмотрении кандидатов?
— Какие факты в резюме сейчас могут стать решающими для работодателей?
— Какие самые неожиданные, каверзные вопросы вам могут попасться на собеседовании?
— Сколько прошло времени с конца обучения на буткемпе по системному анализу до получения первого офера?
— Какой вы бы дали совет людям, которые хотят стать СА, но боятся сильной конкуренции на рынке?
▫️Кому будет полезен вебинар:
— Не системным аналитикам
которые хотят освоить практики проектирования информационных систем и/или стать системным аналитиком
— Действующим системным аналитикам
которые хотят систематизировать знания в области проектирования ИС
— Старшим системным аналитикам
кто хочет освоить современные практики проектирования ИС
▫️Эксперты вебинара:
👤 Татьяна Назаренко
Ведущий тренер и менеджер буткемпа «Системный аналитик: Проектировщик корпоративных информационных систем»
— Опыт работы: 10 лет
— Ведущий научный сотрудник КБ ГИЦ МГТУ Станкин
— Специальность: информационно-управляющие системы и технологии
👤 Мира Карлаш
Соавтор буткемпа «Системный аналитик: Проектировщик корпоративных информационных систем»
— Опыт работы в роли от разработчика до менеджера проектов и системного аналитика;
— Клиенты — международные компании с миллионами ежемесячных пользователей;
— Дополнительное образование в сфере Data Analysis и нейропсихологии от университетов топ-25 по версии The World University Rankings (2022);
— Выступления на всероссийских конференциях, участие в международных форумах.
▫️Приглашенные гости:
Все гости являются выпускниками буткемпа «Системный аналитик: Проектировщик корпоративных информационных систем»
👥 Ланкевич Павел
— До СА работал интегратором — внедренцем интеграционных решений, также руководил командой разработки, совмещая роли РП, DM, SA и в какой-то степени бизнес-архитектора.
— Работает Lead SA в компании РОЛЬФ, имеет за плечами двухлетний опыт в профессии
— За период работы провел онбординг 5 SA в нашей команде
👥 Миронов Илья
— До буткемпа работал в телекоме системным аналитиком, после буткемпа пошёл в другую компанию. Сейчас работаю на проекте инвентаризации материальных ценностей и управлению ими в крупной компании.
— Действующий системный аналитик
👥 Ахмадеев Георгий
— Аналитик со стажем 4 года
— Ранее работал бизнес-аналитиком, после буткемпа стал системным аналитиком, через 6 месяцев стал старшим аналитиком
👥 Неугодникова Александра
— Работает системным аналитиком в банковской сфере, имеет опыт работы в финансовом подразделении банка, риск-менеджменте и в кредитовании юридических лиц. Стаж в кредитных организациях до IT свыше 10 лет.
— До буткемпа устроилась на позицию системного аналитика в банк топ-3. Буткемп помог пройти испытательный срок.
Регистрация
Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.
👍8❤2🔥1
Что должен знать аналитик о REST API, чтобы говорить на одном языке с разработчиками?
Сегодня REST API — стандарт де-факто для интеграции систем. Но, несмотря на его повсеместное использование, многие аналитики ощущают недостаток знаний в этой области. Что же нужно знать, чтобы уверенно общаться с разработчиками и точно формулировать требования?
👇 Ключевые аспекты REST API для аналитика
1. Основные принципы REST
REST основывается на ресурсной модели: все данные представляются в виде ресурсов, доступ к которым осуществляется через HTTP-запросы. Знание таких методов, как GET, POST, PUT и DELETE, позволяет аналитикам лучше понимать, как данные создаются, читаются, обновляются и удаляются.
2. Структура запросов и ответов
Важный момент — формат данных. Чаще всего используется JSON. Аналитик должен знать, как выглядит типичный HTTP-запрос и ответ: например, запрос на получение данных о пользователе и ответ с его профилем.
3. Коды статусов HTTP
Разработчики активно используют коды, такие как 200 (OK), 404 (Not Found) или 500 (Internal Server Error), для диагностики процессов. Аналитику нужно понимать их значение, чтобы лучше интерпретировать ответы системы и корректно описывать ошибки.
4. Документация API
Работа с API-документацией — важный навык. Понимание спецификаций, таких как OpenAPI/Swagger, помогает аналитикам четко описывать взаимодействия между системами.
5. Авторизация и безопасность
REST API часто используют токены для авторизации. Аналитику нужно разбираться в базовых понятиях, таких как OAuth или JWT, чтобы формулировать требования к безопасности.
6. Понимание ограничений и возможностей
REST API имеет свои ограничения, например, относительно объема данных, скорости или количества запросов. Аналитику важно учитывать их при описании функциональных требований.
❓Зачем аналитикам знать REST API?
Знание REST API позволяет аналитикам:
— Формулировать требования, которые разработчики легко реализуют
— Понимать и описывать интеграционные сценарии
— Снижать риски недопонимания и ускорять реализацию проектов
Приглашаем вас на воркшоп «Проектирование интеграции с REST API». Вы изучите основы работы с API, научитесь анализировать запросы и ответы, работать с документацией и формулировать требования к интеграциям.
Регистрация
Сегодня REST API — стандарт де-факто для интеграции систем. Но, несмотря на его повсеместное использование, многие аналитики ощущают недостаток знаний в этой области. Что же нужно знать, чтобы уверенно общаться с разработчиками и точно формулировать требования?
👇 Ключевые аспекты REST API для аналитика
1. Основные принципы REST
REST основывается на ресурсной модели: все данные представляются в виде ресурсов, доступ к которым осуществляется через HTTP-запросы. Знание таких методов, как GET, POST, PUT и DELETE, позволяет аналитикам лучше понимать, как данные создаются, читаются, обновляются и удаляются.
2. Структура запросов и ответов
Важный момент — формат данных. Чаще всего используется JSON. Аналитик должен знать, как выглядит типичный HTTP-запрос и ответ: например, запрос на получение данных о пользователе и ответ с его профилем.
3. Коды статусов HTTP
Разработчики активно используют коды, такие как 200 (OK), 404 (Not Found) или 500 (Internal Server Error), для диагностики процессов. Аналитику нужно понимать их значение, чтобы лучше интерпретировать ответы системы и корректно описывать ошибки.
4. Документация API
Работа с API-документацией — важный навык. Понимание спецификаций, таких как OpenAPI/Swagger, помогает аналитикам четко описывать взаимодействия между системами.
5. Авторизация и безопасность
REST API часто используют токены для авторизации. Аналитику нужно разбираться в базовых понятиях, таких как OAuth или JWT, чтобы формулировать требования к безопасности.
6. Понимание ограничений и возможностей
REST API имеет свои ограничения, например, относительно объема данных, скорости или количества запросов. Аналитику важно учитывать их при описании функциональных требований.
❓Зачем аналитикам знать REST API?
Знание REST API позволяет аналитикам:
— Формулировать требования, которые разработчики легко реализуют
— Понимать и описывать интеграционные сценарии
— Снижать риски недопонимания и ускорять реализацию проектов
Приглашаем вас на воркшоп «Проектирование интеграции с REST API». Вы изучите основы работы с API, научитесь анализировать запросы и ответы, работать с документацией и формулировать требования к интеграциям.
Регистрация
systems.education
■ Онлайн-воркшоп. Проектирование интеграции с REST API
Вы проанализируете процесс взаимодействия систем, потоки данных и опишете REST-like API. Поймете, как аналитик решает интеграционные задачи. Подготовите шаблон с полным описанием процесса интеграции
👍2❤1
Сбор требований: почему «Просто сделайте, чтобы работало» — это не работает
Одна из самых распространённых ошибок, с которой мы сталкиваемся в IT-проектах, — это установка в духе: «Просто сделайте, чтобы всё работало». Заказчик иногда не понимает, как подробно ему нужно формулировать задачу, а разработчики недооценивают важность «копнуть» вглубь. В результате команда двигается «по наитию»: придумывают фичи на лету, продукт получается «как-нибудь», а потом начинаются бесконечные переделки и доработки.
Почему так происходит?
1️⃣ Неясность конечных целей
Если бизнесу важно «увеличить продажи», то в IT-проекте это может означать десятки различных вариантов: запустить новую CRM, улучшить интерфейс сайта, внедрить систему рекомендаций. Без детальной проработки заказчик и команда говорят на разных языках.
2️⃣ Пропуски в коммуникациях
«Просто сделайте» часто маскирует отсутствие нормального канала взаимодействия между отделами или между командой и стейкхолдерами. На уточняющие вопросы нет ответов, согласования задерживаются, а конечный результат получается «не тот».
3️⃣ Неучтённые ограничения
Для одного клиента критичен бюджет, для другого — сроки, а для третьего — скорость отклика приложения при высокой нагрузке. Если не понять, какие приоритеты у проекта, то команда решает всё по-своему. Потом приходится в авральном режиме фиксить «баги» или менять архитектуру продукта.
Что даёт продуманный сбор требований?
— Экономию времени и ресурсов
Подробный список функциональных и нефункциональных требований позволяет сразу определить «область ответственности» каждого члена команды, согласовать сроки и бюджет.
— Ясное распределение ролей
Если каждый понимает, за какую часть продукта отвечает, исчезают «серые зоны». Это снижает риск конфликтов и упрощает контроль качества.
— Устойчивость к изменениям
Когда у вас есть чёткая структура требований, вносить корректировки легче: вы видите, на какие модули или процессы повлияет та или иная правка.
На курсе «Системный анализ. Разработка требований в ИТ-проектах» вы научитесь выстраивать процессы сбора требований не только с заказчиком, но и внутри команды. Вы поймёте, как системный анализ помогает заранее увидеть «узкие места» и избежать дорогих ошибок при проектировании. Если вы хотите, чтобы ваш IT-проект «заработал» не просто как-нибудь, а действительно соответствовал бизнес-целям и пользовательским ожиданиям, мы ждем вас на ближайшем потоке курса.
Регистрация
#курс #системный_анализ
Одна из самых распространённых ошибок, с которой мы сталкиваемся в IT-проектах, — это установка в духе: «Просто сделайте, чтобы всё работало». Заказчик иногда не понимает, как подробно ему нужно формулировать задачу, а разработчики недооценивают важность «копнуть» вглубь. В результате команда двигается «по наитию»: придумывают фичи на лету, продукт получается «как-нибудь», а потом начинаются бесконечные переделки и доработки.
Почему так происходит?
1️⃣ Неясность конечных целей
Если бизнесу важно «увеличить продажи», то в IT-проекте это может означать десятки различных вариантов: запустить новую CRM, улучшить интерфейс сайта, внедрить систему рекомендаций. Без детальной проработки заказчик и команда говорят на разных языках.
2️⃣ Пропуски в коммуникациях
«Просто сделайте» часто маскирует отсутствие нормального канала взаимодействия между отделами или между командой и стейкхолдерами. На уточняющие вопросы нет ответов, согласования задерживаются, а конечный результат получается «не тот».
3️⃣ Неучтённые ограничения
Для одного клиента критичен бюджет, для другого — сроки, а для третьего — скорость отклика приложения при высокой нагрузке. Если не понять, какие приоритеты у проекта, то команда решает всё по-своему. Потом приходится в авральном режиме фиксить «баги» или менять архитектуру продукта.
Что даёт продуманный сбор требований?
— Экономию времени и ресурсов
Подробный список функциональных и нефункциональных требований позволяет сразу определить «область ответственности» каждого члена команды, согласовать сроки и бюджет.
— Ясное распределение ролей
Если каждый понимает, за какую часть продукта отвечает, исчезают «серые зоны». Это снижает риск конфликтов и упрощает контроль качества.
— Устойчивость к изменениям
Когда у вас есть чёткая структура требований, вносить корректировки легче: вы видите, на какие модули или процессы повлияет та или иная правка.
На курсе «Системный анализ. Разработка требований в ИТ-проектах» вы научитесь выстраивать процессы сбора требований не только с заказчиком, но и внутри команды. Вы поймёте, как системный анализ помогает заранее увидеть «узкие места» и избежать дорогих ошибок при проектировании. Если вы хотите, чтобы ваш IT-проект «заработал» не просто как-нибудь, а действительно соответствовал бизнес-целям и пользовательским ожиданиям, мы ждем вас на ближайшем потоке курса.
Регистрация
#курс #системный_анализ
systems.education
■ Онлайн-курс. Системный анализ + ИИ. Разработка требований и функциональное проектирование систем
Для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения
👍4🔥3
Семь уровней диаграммы C4
Многие знакомы с классической нотацией C4 как набором из четырёх основных диаграмм: Context, Containers, Components и Code. Но мало кто знает, что существуют ещё три дополнительных уровня, которые дополняют «большую четвёрку» и позволяют взглянуть на архитектуру ещё глубже.
Всем знакомые первые 4 уровня выглядят так:
🔹 Context (Контекст системы)
Самая «высокая» диаграмма, показывающая систему в окружении внешних акторов (пользователей и других систем).
🔹 Containers (Контейнеры)
Отражает основные «контейнеры»: микросервисы, базы данных, веб-приложения и прочие крупные блоки, в которых исполняется код.
🔹 Components (Компоненты)
Более детальная структура каждого контейнера. Показывает, как код логически разбит на службы, библиотеки и т.д.
🔹 Code (Уровень кода)
Самая детальная диаграмма, где раскрываются классы, модули, файлы и их связи.
На этом обычно останавливаются, потому что дальше начинается «грязная» реальность с привязкой к инфраструктуре, окружениям, сетям и другими нюансами, которые уже не столь универсальны. Однако именно там кроется тот самый «залив архитектурных сокровищ».
На карточках рассказали про 3 скрытых уровня диаграммы С4 ⬆️
Почему чаще всего эти уровни остаются в тени:
— Считаются «частными случаями»
Первая четвёрка C4 покрывает общие потребности архитектуры: от общего вида системы до кода. Следующие уровни будто касаются «частных» инфраструктурных или процессных вопросов.
— Отсутствие стандартизации
В классическом описании C4 нет чёткого руководства по документированию Deployment, Operational и Runtime. У разных команд свои подходы, поэтому нет единой практики.
— Высокая сложность и динамика
В эпоху облачных технологий и гибких методологий реальная картина легко меняется от релиза к релизу. Поддержание актуальности схем пятого, шестого и седьмого уровней может требовать отдельных ресурсов.
— Зачастую спрятаны в других инструментах
Детали развёртывания или мониторинга часто живут в DevOps-пайплайнах и инструментах CI/CD, а динамические сценарии можно увидеть в логах и трейсах. Архитекторам или менеджерам может казаться, что отдельная диаграмма «избыточна».
Вот такие тайны скрываются аз вроде уже давно известными инструментами. Если вы еще не освоили диаграмму C4, приглашаем вас на воркшоп «Паттерны проектирования микросервисной архитектуры и нотация С4», где вы под руководством эксперта на практике познакомитесь с первыми 3 уровнями.
Регистрация
Многие знакомы с классической нотацией C4 как набором из четырёх основных диаграмм: Context, Containers, Components и Code. Но мало кто знает, что существуют ещё три дополнительных уровня, которые дополняют «большую четвёрку» и позволяют взглянуть на архитектуру ещё глубже.
Всем знакомые первые 4 уровня выглядят так:
🔹 Context (Контекст системы)
Самая «высокая» диаграмма, показывающая систему в окружении внешних акторов (пользователей и других систем).
🔹 Containers (Контейнеры)
Отражает основные «контейнеры»: микросервисы, базы данных, веб-приложения и прочие крупные блоки, в которых исполняется код.
🔹 Components (Компоненты)
Более детальная структура каждого контейнера. Показывает, как код логически разбит на службы, библиотеки и т.д.
🔹 Code (Уровень кода)
Самая детальная диаграмма, где раскрываются классы, модули, файлы и их связи.
На этом обычно останавливаются, потому что дальше начинается «грязная» реальность с привязкой к инфраструктуре, окружениям, сетям и другими нюансами, которые уже не столь универсальны. Однако именно там кроется тот самый «залив архитектурных сокровищ».
На карточках рассказали про 3 скрытых уровня диаграммы С4 ⬆️
Почему чаще всего эти уровни остаются в тени:
— Считаются «частными случаями»
Первая четвёрка C4 покрывает общие потребности архитектуры: от общего вида системы до кода. Следующие уровни будто касаются «частных» инфраструктурных или процессных вопросов.
— Отсутствие стандартизации
В классическом описании C4 нет чёткого руководства по документированию Deployment, Operational и Runtime. У разных команд свои подходы, поэтому нет единой практики.
— Высокая сложность и динамика
В эпоху облачных технологий и гибких методологий реальная картина легко меняется от релиза к релизу. Поддержание актуальности схем пятого, шестого и седьмого уровней может требовать отдельных ресурсов.
— Зачастую спрятаны в других инструментах
Детали развёртывания или мониторинга часто живут в DevOps-пайплайнах и инструментах CI/CD, а динамические сценарии можно увидеть в логах и трейсах. Архитекторам или менеджерам может казаться, что отдельная диаграмма «избыточна».
Вот такие тайны скрываются аз вроде уже давно известными инструментами. Если вы еще не освоили диаграмму C4, приглашаем вас на воркшоп «Паттерны проектирования микросервисной архитектуры и нотация С4», где вы под руководством эксперта на практике познакомитесь с первыми 3 уровнями.
Регистрация
❤3
Очный курс «Системный анализ. Разработка требований в ИТ-проектах»
🔹Когда старт?
27 февраля
🔹Этот курс для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
🔹Что получите от курса:
— Научитесь выявлять и формулировать требования к программной системе
— Создадите законченный документ Требований к ПО (SRS)
Программа курса охватывает полный цикл разработки требований к ПО, начиная от анализа бизнес-требований до сборки итогового документа. Курс подробно рассматривает моделирование функциональных требований, контроль качества, а также формулировку ожиданий к производительности и надёжности программного продукта.
Регистрация
#курс #системный_анализ
🔹Когда старт?
27 февраля
🔹Этот курс для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
🔹Что получите от курса:
— Научитесь выявлять и формулировать требования к программной системе
— Создадите законченный документ Требований к ПО (SRS)
Программа курса охватывает полный цикл разработки требований к ПО, начиная от анализа бизнес-требований до сборки итогового документа. Курс подробно рассматривает моделирование функциональных требований, контроль качества, а также формулировку ожиданий к производительности и надёжности программного продукта.
Регистрация
#курс #системный_анализ
👍1
28 января (вт) в 18:00 МСК пройдет вебинар на тему «Что такое архитектура ИС и как ее проектировать?», на котором Анна Вичугова, Эксперт по бизнес-анализу и проектированию ИС и Кандидат наук по Системному анализу и управлению, на практических примерах расскажет про проектирование архитектуры информационных систем, связанные с этим мифы, техники и инструменты.
▫️План вебинара:
— Практический смысл архитектуры ИС
— Уровни архитектурного проектирования
— Основные факторы, влияющие на принятие архитектурных решений
— Почему фраза «все зависит от контекста» — не просто смешной мем
— Участники процессов проектирования
— Инструменты и артефакты проектирования
— Какова цена ошибки «неправильной» архитектуры
— Почему «идеального» решения не существует (в поисках компромисса)
▫️Вебинар будет полезен:
— Системным аналитикам
— Бизнес-аналитикам
— Менеджерам ИТ-проектов
— Разработчикам
— Проектировщикам информационных систем
Регистрация
Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.
▫️План вебинара:
— Практический смысл архитектуры ИС
— Уровни архитектурного проектирования
— Основные факторы, влияющие на принятие архитектурных решений
— Почему фраза «все зависит от контекста» — не просто смешной мем
— Участники процессов проектирования
— Инструменты и артефакты проектирования
— Какова цена ошибки «неправильной» архитектуры
— Почему «идеального» решения не существует (в поисках компромисса)
▫️Вебинар будет полезен:
— Системным аналитикам
— Бизнес-аналитикам
— Менеджерам ИТ-проектов
— Разработчикам
— Проектировщикам информационных систем
Регистрация
Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.
🔥3👍2
Выложили запись доклада Николая Рыжикова с конференции Systems Design 24
Доклад Николая, CTO компании Health Samurai, на тему «Стандарты и сообщества», в котором он поделился своей историей участия в разных сообществах и как они помогли ему в личной работе.
Тайм-код доклада:
00:00 О докладе
02:29 Как делали МИС (EHR)
03:54 Стандарт HL7v2 (1980)
8:27 Ruby eco-system
10:47 Как вести активности в сообществах
13:19 Сертификация
16:43 Стандарт FHIR
19:55 Компоненты хорошего стандарта
23:08 Aidbox FHIR Platform
Посмотреть можно как на нашем You-Tube канале, так и в группе в ВК
#выступления
Доклад Николая, CTO компании Health Samurai, на тему «Стандарты и сообщества», в котором он поделился своей историей участия в разных сообществах и как они помогли ему в личной работе.
Тайм-код доклада:
00:00 О докладе
02:29 Как делали МИС (EHR)
03:54 Стандарт HL7v2 (1980)
8:27 Ruby eco-system
10:47 Как вести активности в сообществах
13:19 Сертификация
16:43 Стандарт FHIR
19:55 Компоненты хорошего стандарта
23:08 Aidbox FHIR Platform
Посмотреть можно как на нашем You-Tube канале, так и в группе в ВК
#выступления
YouTube
Стандарты и сообщества • Николай Рыжиков
Стандарты и сообщества • Николай Рыжиков
CTO компании Health Samurai, Николай Рыжиков, спикер конференции Systems Design 2024, поделился своей историей участия в разных сообществах и как они помогли ему в личной работе.
00:00 О докладе
02:29 Как делали МИС…
CTO компании Health Samurai, Николай Рыжиков, спикер конференции Systems Design 2024, поделился своей историей участия в разных сообществах и как они помогли ему в личной работе.
00:00 О докладе
02:29 Как делали МИС…
❤3
Воркшоп «Проектирование интеграции с REST API»
🔹Когда старт?
1 февраля (сб)
🔹Воркшоп будет полезен тем, кто хочет:
— познакомиться с REST API
— научиться проектировать интеграцию «с нуля»
— описывать REST-интерфейсы в виде, пригодном для разработки
🔹Что получишь от воркшопа?
Пошаговую методику и шаблон описания интеграции
— Участники проанализируют процесс взаимодействия систем, потоки данных и опишут REST-like API
— Поймут, как аналитик решает интеграционные задачи
— Подготовят постановку задачи на интеграцию на основе шаблона
Регистрация еще открыта!
#воркшоп #интеграция #RESTAPI
🔹Когда старт?
1 февраля (сб)
🔹Воркшоп будет полезен тем, кто хочет:
— познакомиться с REST API
— научиться проектировать интеграцию «с нуля»
— описывать REST-интерфейсы в виде, пригодном для разработки
🔹Что получишь от воркшопа?
Пошаговую методику и шаблон описания интеграции
— Участники проанализируют процесс взаимодействия систем, потоки данных и опишут REST-like API
— Поймут, как аналитик решает интеграционные задачи
— Подготовят постановку задачи на интеграцию на основе шаблона
Регистрация еще открыта!
#воркшоп #интеграция #RESTAPI
👍1
UML-диаграммы используют и аналитики, и архитекторы — такой вывод сделал аналитик Юрий Куприянов по результатам опроса 275 респондентов. Респонденты — 80% из них используют UML — работают и в продуктовых компаниях, и во внутренней, и в заказной разработке.
Похоже, что UML (англ. Unified Modeling Language) — унифицированный язык моделирования — действительно универсален. Давайте разберемся, за счёт чего UML моделирование помогает в создании различных типов систем:
▫️ Корпоративные информационные системы
— Диаграммы (далее "Д.") прецедентов (Use case diagram) и деятельности (Activity diagram) помогают визуализировать и оптимизировать процессы компании.
— Д. классов (Class diagram) используется для моделирования данных и их взаимосвязей, что важно для баз данных.
— Д. компонентов (Component diagram) и развертывания (Deployment diagram) показывают, как модули взаимодействуют и интегрируются в систему.
— Д. последовательности (Sequence diagram) и коммуникации (Communication diagram) моделируют обмен данными между системами.
▫️ Встроенные системы
— Д. компонентов (Component diagram) и развертывания (Deployment diagram) помогают визуализировать, как программные модули взаимодействуют с аппаратной частью, что критично для встроенных систем, где программное обеспечение тесно интегрировано с оборудованием.
— Д. состояний (State Machine diagram) позволяет моделировать реакции системы на различные события, что важно для встроенных систем, требующих надёжного управления состояниями.
— Д. последовательности (Sequence diagram) обеспечивает чёткое понимание потоков данных и сигналов между компонентами, что помогает в проектировании систем с ограниченными ресурсами.
— Д. деятельности (Activity diagram) позволяет моделировать и оптимизировать процессы обработки данных, обеспечивая эффективное использование ресурсов.
▫️ Системы управления данными
— Д. классов (Class diagram) используется для проектирования структуры данных и их взаимосвязей, что важно для построения эффективных баз данных.
— Д. деятельности (Activity diagram) и последовательностей (Sequence diagram) помогают моделировать потоки информации, обеспечивая её надёжное хранение и обработку.
— Д. коммуникации (Communication diagram) позволяет описывать, как система управления данными будет взаимодействовать с другими системами, обеспечивая совместимость и интеграцию.
— Д. компонентов (Component diagram) помогает проектировать модульную архитектуру, обеспечивающую масштабируемость и гибкость системы.
▫️ Веб-приложения и мобильные приложения
— Д. прецедентов (Use case diagram) помогает моделировать пользовательские сценарии, что важно для понимания требований к интерфейсу и функциональности.
— Д. компонентов (Component diagram) и развертывания (Deployment diagram) визуализируют архитектуру приложения, включая клиентскую и серверную части, что помогает в проектировании распределённых систем.
— Д. последовательности (Sequence diagram) моделирует взаимодействие между пользователем и системой, а также потоки данных между различными частями приложения.
— Д. состояний (State Machine diagram) помогает управлять переходами между различными состояниями интерфейса и обеспечивать плавное взаимодействие с пользователем.
▫️ Системы реального времени
— Д. состояний (State Machine diagram) помогает управлять реакциями системы на события в реальном времени.
— Д. последовательности (Sequence diagram) и деятельности (Activity diagram) обеспечивают визуализацию потоков данных и сигналов.
— Д. коммуникации (Communication diagram) моделирует, как компоненты синхронизируются и взаимодействуют между собой.
Эти инструменты UML предоставляют разработчикам и архитекторам возможность создавать чёткие и эффективные модели для различных типов систем, обеспечивая успешное проектирование и реализацию.
Приглашаем на курс «Системное моделирование. Основы обьектно-ориентированного проектирования и разработка UML-моделей», чтобы на практике использовать многообразие функций UML.
Регистрация
Похоже, что UML (англ. Unified Modeling Language) — унифицированный язык моделирования — действительно универсален. Давайте разберемся, за счёт чего UML моделирование помогает в создании различных типов систем:
▫️ Корпоративные информационные системы
— Диаграммы (далее "Д.") прецедентов (Use case diagram) и деятельности (Activity diagram) помогают визуализировать и оптимизировать процессы компании.
— Д. классов (Class diagram) используется для моделирования данных и их взаимосвязей, что важно для баз данных.
— Д. компонентов (Component diagram) и развертывания (Deployment diagram) показывают, как модули взаимодействуют и интегрируются в систему.
— Д. последовательности (Sequence diagram) и коммуникации (Communication diagram) моделируют обмен данными между системами.
▫️ Встроенные системы
— Д. компонентов (Component diagram) и развертывания (Deployment diagram) помогают визуализировать, как программные модули взаимодействуют с аппаратной частью, что критично для встроенных систем, где программное обеспечение тесно интегрировано с оборудованием.
— Д. состояний (State Machine diagram) позволяет моделировать реакции системы на различные события, что важно для встроенных систем, требующих надёжного управления состояниями.
— Д. последовательности (Sequence diagram) обеспечивает чёткое понимание потоков данных и сигналов между компонентами, что помогает в проектировании систем с ограниченными ресурсами.
— Д. деятельности (Activity diagram) позволяет моделировать и оптимизировать процессы обработки данных, обеспечивая эффективное использование ресурсов.
▫️ Системы управления данными
— Д. классов (Class diagram) используется для проектирования структуры данных и их взаимосвязей, что важно для построения эффективных баз данных.
— Д. деятельности (Activity diagram) и последовательностей (Sequence diagram) помогают моделировать потоки информации, обеспечивая её надёжное хранение и обработку.
— Д. коммуникации (Communication diagram) позволяет описывать, как система управления данными будет взаимодействовать с другими системами, обеспечивая совместимость и интеграцию.
— Д. компонентов (Component diagram) помогает проектировать модульную архитектуру, обеспечивающую масштабируемость и гибкость системы.
▫️ Веб-приложения и мобильные приложения
— Д. прецедентов (Use case diagram) помогает моделировать пользовательские сценарии, что важно для понимания требований к интерфейсу и функциональности.
— Д. компонентов (Component diagram) и развертывания (Deployment diagram) визуализируют архитектуру приложения, включая клиентскую и серверную части, что помогает в проектировании распределённых систем.
— Д. последовательности (Sequence diagram) моделирует взаимодействие между пользователем и системой, а также потоки данных между различными частями приложения.
— Д. состояний (State Machine diagram) помогает управлять переходами между различными состояниями интерфейса и обеспечивать плавное взаимодействие с пользователем.
▫️ Системы реального времени
— Д. состояний (State Machine diagram) помогает управлять реакциями системы на события в реальном времени.
— Д. последовательности (Sequence diagram) и деятельности (Activity diagram) обеспечивают визуализацию потоков данных и сигналов.
— Д. коммуникации (Communication diagram) моделирует, как компоненты синхронизируются и взаимодействуют между собой.
Эти инструменты UML предоставляют разработчикам и архитекторам возможность создавать чёткие и эффективные модели для различных типов систем, обеспечивая успешное проектирование и реализацию.
Приглашаем на курс «Системное моделирование. Основы обьектно-ориентированного проектирования и разработка UML-моделей», чтобы на практике использовать многообразие функций UML.
Регистрация
Telegram
Системный сдвиг
Публикую презентацию с Flow про UML. Нужно тему сворачивать, а то уже, говорят, приклеилась слава, что "Куприянов всем говорит, что UML умер". Так вот — UML жив, и неплохо себя чувствует. Прямо по Жванецкому: "И что смешно — министр мясной и молочной промышленности…
👍1🔥1
REST vs GraphQL: когда какой выбрать и почему?
Сегодня выбор архитектуры API становится одним из ключевых решений при проектировании современной системы. REST и GraphQL — два наиболее популярных подхода, и у каждого есть свои сильные стороны и подводные камни. Как определиться, что нужно именно вам?
📕Когда стоит выбирать REST?
1. Простота и предсказуемость
REST базируется на чётких принципах (ресурсы, HTTP-методы, код ответа), поэтому его легко понять и использовать без дополнительной инфраструктуры.
2. Чётко сформулированные эндпоинты
Каждый endpoint чётко отражает ресурс (например, /users, /orders). Архитектура получается «говорящей»: становится проще поддерживать документацию и тестировать сервисы.
3. Широкая экосистема
REST используют уже десятилетиями — для него есть готовые библиотеки, инструменты для валидации и автогенерации документации, а также практики версионирования.
📘Когда стоит выбирать GraphQL?
1. Гибкость запросов
В GraphQL клиент сам описывает, какие поля ему нужны. Вместо нескольких запросов к REST-эндпоинтам можно сделать один запрос к GraphQL и получить ровно ту структуру данных, которая требуется.
2. Оптимизация трафика
Вместо «overfetching» или «underfetching» (когда вы либо получаете лишние данные, либо не получаете нужные) GraphQL даёт возможность точечно запрашивать нужную информацию, что может снизить нагрузку на сеть.
3. Единая точка входа
GraphQL-сервер предоставляет единый endpoint, объединяя разнообразные структуры данных и источники: это удобно при сложных интеграциях и микросервисной архитектуре.
📚 Скрытые риски и подводные камни
REST
— Версионирование может стать проблемой при больших изменениях в структуре данных
— Может возникнуть проблема «чрезмерной детализации»: приходится плодить множество эндпоинтов для разных случаев
GraphQL
— Дополнительная сложность в настройке схемы и серверной части
— Возможен «скрытый overfetching», если команда недостаточно контролирует бизнес-логику и не ограничивает глубину запросов
— Отладка запросов может усложниться без грамотного трекинга
Как же сделать правильный выбор? Если ваша задача — интегрировать несколько систем с нечасто меняющейся структурой данных, REST станет хорошим вариантом. Но если вы хотите максимально гибко обслуживать разные клиенты (мобильное приложение, десктоп, веб) и ваше API требует постоянных доработок, GraphQL может дать необходимые возможности.
Если вы хотите прокачаться в продвинутом проектировании API, приглашаем вас на воркшоп «Проектирование сложных API: OpenAPI + AsyncAPI». Вы узнаете, как грамотно документировать и проектировать REST, а также освоите подходы к асинхронным коммуникациям с помощью AsyncAPI. Это ваш шанс создать надёжную архитектуру, которая безболезненно выдержит масштабирование и будет удобна всем, от разработчиков до пользователей.
Регистрация
Сегодня выбор архитектуры API становится одним из ключевых решений при проектировании современной системы. REST и GraphQL — два наиболее популярных подхода, и у каждого есть свои сильные стороны и подводные камни. Как определиться, что нужно именно вам?
📕Когда стоит выбирать REST?
1. Простота и предсказуемость
REST базируется на чётких принципах (ресурсы, HTTP-методы, код ответа), поэтому его легко понять и использовать без дополнительной инфраструктуры.
2. Чётко сформулированные эндпоинты
Каждый endpoint чётко отражает ресурс (например, /users, /orders). Архитектура получается «говорящей»: становится проще поддерживать документацию и тестировать сервисы.
3. Широкая экосистема
REST используют уже десятилетиями — для него есть готовые библиотеки, инструменты для валидации и автогенерации документации, а также практики версионирования.
Используйте REST, если у вас относительно стабильная структура данных и потребность в хорошо документированном API, где принцип «один ресурс — один endpoint» упрощает коммуникацию между сервисами.
📘Когда стоит выбирать GraphQL?
1. Гибкость запросов
В GraphQL клиент сам описывает, какие поля ему нужны. Вместо нескольких запросов к REST-эндпоинтам можно сделать один запрос к GraphQL и получить ровно ту структуру данных, которая требуется.
2. Оптимизация трафика
Вместо «overfetching» или «underfetching» (когда вы либо получаете лишние данные, либо не получаете нужные) GraphQL даёт возможность точечно запрашивать нужную информацию, что может снизить нагрузку на сеть.
3. Единая точка входа
GraphQL-сервер предоставляет единый endpoint, объединяя разнообразные структуры данных и источники: это удобно при сложных интеграциях и микросервисной архитектуре.
Используйте GraphQL, если ваш проект требует высокой гибкости в работе с данными, особенно когда фронтенд постоянно меняется, а источники данных могут быть весьма разнообразны.
📚 Скрытые риски и подводные камни
REST
— Версионирование может стать проблемой при больших изменениях в структуре данных
— Может возникнуть проблема «чрезмерной детализации»: приходится плодить множество эндпоинтов для разных случаев
GraphQL
— Дополнительная сложность в настройке схемы и серверной части
— Возможен «скрытый overfetching», если команда недостаточно контролирует бизнес-логику и не ограничивает глубину запросов
— Отладка запросов может усложниться без грамотного трекинга
Как же сделать правильный выбор? Если ваша задача — интегрировать несколько систем с нечасто меняющейся структурой данных, REST станет хорошим вариантом. Но если вы хотите максимально гибко обслуживать разные клиенты (мобильное приложение, десктоп, веб) и ваше API требует постоянных доработок, GraphQL может дать необходимые возможности.
Если вы хотите прокачаться в продвинутом проектировании API, приглашаем вас на воркшоп «Проектирование сложных API: OpenAPI + AsyncAPI». Вы узнаете, как грамотно документировать и проектировать REST, а также освоите подходы к асинхронным коммуникациям с помощью AsyncAPI. Это ваш шанс создать надёжную архитектуру, которая безболезненно выдержит масштабирование и будет удобна всем, от разработчиков до пользователей.
Регистрация
systems.education
■ Онлайн-воркшоп. Проектирование сложных API: OpenAPI + AsyncAPI
Онлайн-воркшоп по проектированию и документированию API для системных аналитиков, которые хотят познакомиться со спецификациями OpenAPI и AsyncAPI, а также научиться проектировать и документировать синхронные и асинхронные API
❤2