Герои комикса фулстек-аналитик Иван и ИИ-бот Марика помогают исследовать словарь терминов системного аналитика.
СЕГОДНЯШНЯЯ ТЕМА — ТРЕБОВАНИЯ. Выдержки из словаря:
👇 Делитесь в комментариях официальными и разговорными терминами, которые использует ваша команда. На основании ваших обсуждений мы дополним глоссарий, так наша подборка станет ещё полезнее.
СЕГОДНЯШНЯЯ ТЕМА — ТРЕБОВАНИЯ. Выдержки из словаря:
Спецификация требований (SRS – Software Requirements Specification)
Определение: Формализованный документ, описывающий функциональные и нефункциональные аспекты компьютерных программ, используемый для согласования между стейкхолдерами и командой разработки.
Официальные термины: «Software Requirements Specification (SRS)»
Разговорные: «спека», «требования в доке»
Функциональные требования (Functional Requirements)
Определение: Описывают, что именно должна делать система (функции, процессы, реакции на действия пользователя), формирующие основу предметной логики.
Официальные термины: «Functional Requirements», «FR»
Разговорные: «ФТ»
Нефункциональные требования (Non-functional Requirements – NFR)
Определение: Характеристики системы, не описывающие конкретный функционал (производительность, безопасность, масштабируемость), но влияющие на её качество и архитектуру.
Официальные термины: «Non-functional Requirements (NFR)», «Атрибуты качества»
Разговорные: «НФТ»
👇 Делитесь в комментариях официальными и разговорными терминами, которые использует ваша команда. На основании ваших обсуждений мы дополним глоссарий, так наша подборка станет ещё полезнее.
👍9😁7🔥3❤2
Кто должен писать OpenAPI: аналитик или разработчик?
Разбираемся, где заканчиваются требования и начинаются спецификации
Если вы работаете с API, этот вопрос возникал не раз!
Аналитик, который формулирует требования? Разработчик, который реализует эндпоинт? Или архитектор, который проектирует взаимодействие компонентов?
Разберём роли каждого
🦸♂️Роль аналитика: зачем, что, кому и почему
Что именно делает аналитик:
— Определяет сценарии использования API (например: «получить список заказов клиента по ID»)
— Описывает структуру и логику данных, включая ограничения и валидации
— Согласует API с внешними/внутренними потребителями
— Пишет черновой draft OpenAPI, если уровень зрелости команды это позволяет
🥷 Роль разработчика: реализация и точка правды
Разработчик отвечает за то, чтобы API было реализуемо и работало как надо. Даже идеальная спецификация бесполезна, если код делает что-то другое.
Разработчик:
— Уточняет детали реализации, которые могли быть упущены в требованиях
— Сопоставляет спецификацию с реальным кодом
— Поддерживает актуальность OpenAPI, особенно если используется code-first подход (например, с Springdoc, Swagger Annotations и пр.)
Если спецификацию пишет аналитик — разработчик её валидирует. Если наоборот — аналитик проверяет соответствие требованиям.
Хотите научиться работать с OpenAPI и AsyncAPI на практике?
На воркшопе «Проектирование сложных API: OpenAPI + AsyncAPI» всего за 7 часов вы:
— Научитесь читать и писать спецификации OpenAPI и AsyncAPI
— Разберётесь, как описывать синхронные и асинхронные интеграции
Подробнее
#воркшоп@systems_education
Разбираемся, где заканчиваются требования и начинаются спецификации
Если вы работаете с API, этот вопрос возникал не раз!
Кто должен писать OpenAPI?
Аналитик, который формулирует требования? Разработчик, который реализует эндпоинт? Или архитектор, который проектирует взаимодействие компонентов?
Разберём роли каждого
🦸♂️Роль аналитика: зачем, что, кому и почему
Что именно делает аналитик:
— Определяет сценарии использования API (например: «получить список заказов клиента по ID»)
— Описывает структуру и логику данных, включая ограничения и валидации
— Согласует API с внешними/внутренними потребителями
— Пишет черновой draft OpenAPI, если уровень зрелости команды это позволяет
🥷 Роль разработчика: реализация и точка правды
Разработчик отвечает за то, чтобы API было реализуемо и работало как надо. Даже идеальная спецификация бесполезна, если код делает что-то другое.
Разработчик:
— Уточняет детали реализации, которые могли быть упущены в требованиях
— Сопоставляет спецификацию с реальным кодом
— Поддерживает актуальность OpenAPI, особенно если используется code-first подход (например, с Springdoc, Swagger Annotations и пр.)
Если спецификацию пишет аналитик — разработчик её валидирует. Если наоборот — аналитик проверяет соответствие требованиям.
Хотите научиться работать с OpenAPI и AsyncAPI на практике?
На воркшопе «Проектирование сложных API: OpenAPI + AsyncAPI» всего за 7 часов вы:
— Научитесь читать и писать спецификации OpenAPI и AsyncAPI
— Разберётесь, как описывать синхронные и асинхронные интеграции
Подробнее
#воркшоп@systems_education
❤3👍3
Типы защитных мер в информационной безопасности: как выстроить комплексную защиту, которая действительно работает
Информационная безопасность — это не только технические средства, но и стратегия. Эффективная защита строится на комплексном подходе, где разные типы мер работают согласованно: предупреждают, обнаруживают, минимизируют ущерб и помогают быстро восстановиться после инцидентов.
Ниже рассказали про пять ключевых типов защитных мер
🔐 Превентивные меры (Preventive): минимизируем риск до инцидента
Цель — не допустить реализацию угрозы. Это фундамент безопасности.
Ключевые вопросы:
— Какие угрозы наиболее вероятны в вашей системе?
— Как их можно устранить до возникновения?
— Что можно сделать, чтобы ошибка пользователя или случайное действие не привели к катастрофе?
🔍 Детективные меры (Detective): своевременно замечаем угрозу
Цель — обнаружить инцидент, зафиксировать его и собрать данные для анализа и реагирования.
Ключевые вопросы:
— Какие события нужно логировать и хранить?
— Какие данные критичны для расследования инцидентов?
— Как защитить логи от компрометации?
— Как обеспечить автоматическое оповещение и корректную визуализацию инцидентов?
🚨 Восстановительные меры (Recovery): быстро возвращаемся в строй
Цель — минимизировать последствия и оперативно вернуть систему в рабочее состояние.
Ключевые вопросы:
— Какие процессы критичны и должны быть восстановлены в первую очередь?
— Сколько времени система может быть недоступна без серьёзных последствий?
— Какие данные нельзя потерять ни при каких обстоятельствах?
— Какие процедуры восстановления нужно регулярно тестировать?
🖋 Корректирующие меры (Corrective): устраняем причины и учимся на ошибках
Цель — не просто «потушить пожар», а устранить источник проблемы и предотвратить повторение.
Ключевые вопросы:
— Как выявить и нейтрализовать первопричину инцидента?
— Как изменить процессы, чтобы ситуация не повторилась?
— Как не нарушить бизнес-функции при реализации мер?
— Какие изменения стоит зафиксировать документально и процедурно?
🔋 Компенсирующие меры (Compensating): когда основная защита недоступна
Цель — обеспечить защиту там, где по каким-то причинам невозможно реализовать основной механизм.
Ключевые вопросы:
— Какие альтернативные меры возможны в текущих условиях?
— Какие компромиссы допустимы без потери безопасности?
— Какие условия должны быть соблюдены, чтобы компенсирующая мера была признана достаточной?
Примеры всех типов мер показали на карточках ⬆️
— Не породят ли эти меры новые векторы атаки?
Каждый тип мер — часть этой архитектуры, и только в совокупности они дают реальный эффект: от профилактики до восстановления. На воркшопе «Основы разработки требований к информационной безопасности ИТ-систем» вы получите универсальный фундамент понимания принципов информационной безопасности, сформируете умения, применимые для разных категорий систем в разных юрисдикциях и улучшите качество проектной документации и ТЗ, в том числе на проектах интеграции.
Регистрация
#воркшоп@systems_education #безопасность@systems_education
Информационная безопасность — это не только технические средства, но и стратегия. Эффективная защита строится на комплексном подходе, где разные типы мер работают согласованно: предупреждают, обнаруживают, минимизируют ущерб и помогают быстро восстановиться после инцидентов.
Ниже рассказали про пять ключевых типов защитных мер
🔐 Превентивные меры (Preventive): минимизируем риск до инцидента
Цель — не допустить реализацию угрозы. Это фундамент безопасности.
Ключевые вопросы:
— Какие угрозы наиболее вероятны в вашей системе?
— Как их можно устранить до возникновения?
— Что можно сделать, чтобы ошибка пользователя или случайное действие не привели к катастрофе?
🔍 Детективные меры (Detective): своевременно замечаем угрозу
Цель — обнаружить инцидент, зафиксировать его и собрать данные для анализа и реагирования.
Ключевые вопросы:
— Какие события нужно логировать и хранить?
— Какие данные критичны для расследования инцидентов?
— Как защитить логи от компрометации?
— Как обеспечить автоматическое оповещение и корректную визуализацию инцидентов?
🚨 Восстановительные меры (Recovery): быстро возвращаемся в строй
Цель — минимизировать последствия и оперативно вернуть систему в рабочее состояние.
Ключевые вопросы:
— Какие процессы критичны и должны быть восстановлены в первую очередь?
— Сколько времени система может быть недоступна без серьёзных последствий?
— Какие данные нельзя потерять ни при каких обстоятельствах?
— Какие процедуры восстановления нужно регулярно тестировать?
🖋 Корректирующие меры (Corrective): устраняем причины и учимся на ошибках
Цель — не просто «потушить пожар», а устранить источник проблемы и предотвратить повторение.
Ключевые вопросы:
— Как выявить и нейтрализовать первопричину инцидента?
— Как изменить процессы, чтобы ситуация не повторилась?
— Как не нарушить бизнес-функции при реализации мер?
— Какие изменения стоит зафиксировать документально и процедурно?
🔋 Компенсирующие меры (Compensating): когда основная защита недоступна
Цель — обеспечить защиту там, где по каким-то причинам невозможно реализовать основной механизм.
Ключевые вопросы:
— Какие альтернативные меры возможны в текущих условиях?
— Какие компромиссы допустимы без потери безопасности?
— Какие условия должны быть соблюдены, чтобы компенсирующая мера была признана достаточной?
Примеры всех типов мер показали на карточках ⬆️
— Не породят ли эти меры новые векторы атаки?
Каждый тип мер — часть этой архитектуры, и только в совокупности они дают реальный эффект: от профилактики до восстановления. На воркшопе «Основы разработки требований к информационной безопасности ИТ-систем» вы получите универсальный фундамент понимания принципов информационной безопасности, сформируете умения, применимые для разных категорий систем в разных юрисдикциях и улучшите качество проектной документации и ТЗ, в том числе на проектах интеграции.
Регистрация
#воркшоп@systems_education #безопасность@systems_education
❤5🔥2👍1
Forwarded from Денис Бесков: умные мысли и несколько своих
Нам в Systems.Education нужен part-time CTO/CIO
сейчас мы внедряем ИИ в наши курсы, хотим предлагать ученикам использовать не только внешние готовые SaaS, но и уметь ставить и настраивать локальные-облачно-доверенные LLM
для этих целей выбираем тариф-хостинг сервера, дальше делаем что-то вроде Лаборатории по применению ИИ для анализа и проектирования ИТ-систем
также во многих курсах постоянно нужны разные СУБД и middleware ПО, организация учебных сред для разработки-тестирования, хочется это всё нормально организовать и менеджерить
у нас есть парт-тайм технический администратор вышедший из бухгалтеров-аналитиков и есть тимлиды аналитиков с серьёзным опытом в бэкенде, но хочется чтобы такими вопросами занимался выделенный технический менеджер (не я)
итого, что делать:
— анализировать запросы экспертов и преподавателей на инфраструктурные сервисы и ПО для применения в обучении и прикладных исследованиях
— выбирать подходящий хостинг(И?)
— организовывать развёртывание необходимого ПО
— организовывать администрирование этого ПО
также возможно потребуются какие-то политики и скрипты виртуализации-развёртывания-зачистки-обновления, чтобы разные пользователи и учебные группы не мешали друг другу, но я в этом плохо понимаю
денег немного, тысяч 40-50, но и загрузки будет пропорционально, часов 4-5 в неделю
если у вас есть опыт техдиректора/CTO и вам интересно то, что мы делаем, пишите плс мне в личку @beskov
сейчас мы внедряем ИИ в наши курсы, хотим предлагать ученикам использовать не только внешние готовые SaaS, но и уметь ставить и настраивать локальные-облачно-доверенные LLM
для этих целей выбираем тариф-хостинг сервера, дальше делаем что-то вроде Лаборатории по применению ИИ для анализа и проектирования ИТ-систем
также во многих курсах постоянно нужны разные СУБД и middleware ПО, организация учебных сред для разработки-тестирования, хочется это всё нормально организовать и менеджерить
у нас есть парт-тайм технический администратор вышедший из бухгалтеров-аналитиков и есть тимлиды аналитиков с серьёзным опытом в бэкенде, но хочется чтобы такими вопросами занимался выделенный технический менеджер (не я)
итого, что делать:
— анализировать запросы экспертов и преподавателей на инфраструктурные сервисы и ПО для применения в обучении и прикладных исследованиях
— выбирать подходящий хостинг(И?)
— организовывать развёртывание необходимого ПО
— организовывать администрирование этого ПО
также возможно потребуются какие-то политики и скрипты виртуализации-развёртывания-зачистки-обновления, чтобы разные пользователи и учебные группы не мешали друг другу, но я в этом плохо понимаю
денег немного, тысяч 40-50, но и загрузки будет пропорционально, часов 4-5 в неделю
если у вас есть опыт техдиректора/CTO и вам интересно то, что мы делаем, пишите плс мне в личку @beskov
👍2🔥1
Недавно в этом посте рассказали про No-code и low-code интеграции и различные сценарии их использования. Но важно понимать, что no-code ≠ универсальный подход. За удобство приходится платить рядом ограничений.
🚨 О некоторых из них хотим рассказать сегодня:
— Границы возможностей: No-code платформы предоставляют богатый, но конечный набор готовых функций. Если требуемая логика выходит за эти рамки, без кода не обойтись. Проще говоря, кастомизация ограничена — сложные правила или специфические алгоритмы не реализуешь, если для них нет блока в интерфейсе.
— Масштаб и нагрузка: Когда речь о нескольких сотнях записей в день – no-code справится отлично. Но если нужно обработать миллион транзакций или обеспечивать задержки в миллисекундах, могут возникнуть проблемы с производительностью. Типичная архитектура no-code сервисов — облачная и мультиарендная, рассчитанная на усреднённые кейсы. Интенсивные нагрузки могут либо сильно стоить (тарифы часто зависят от количества операций), либо вообще выйти за пределы поддерживаемого. Кроме того, некоторые облачные интеграторы работают не в режиме реального времени, а с небольшими задержками. Например, у бесплатного тарифа Zapier задачи выполняются раз в 15 минут, что неприемлемо для ряда сценариев, требующих мгновенного отклик.
— Скрытая сложность: Фраза «без кода» не означает, что интеграцию может сделать кто угодно без подготовки. Порог входа ниже, чем у классического программирования, но разобраться всё же нужно. Новичку придётся понять логику работы переменных, условий, форматов данных, иначе даже с визуальным интерфейсом можно запутаться. Например, чтобы связать две системы, надо чётко представлять, какие данные на каком шаге передаются, в каком формате (JSON, XML, CSV и т.д.), как обработать ошибки. Без базовых знаний о тех же API и вебхуках возможно столкнуться с трудностями.
— Вендорозависимость и контроль: Используя стороннюю платформу интеграции, вы становитесь в определённой степени зависимы от неё. Все ваши связки хранятся в её облаке. Если сервис сбоит или меняет условия использования, это влияет на ваши процессы. Вы не можете залезть «под капот» и что-то поправить самостоятельно – придётся ждать, когда провайдер решит проблему. Гибкость ниже, чем при собственном код. Кроме того, возможны нюансы безопасности: важно доверять выбранной платформе, ведь через неё проходит корпоративная информация.
Интеграция без кода успешно работает в реальных проектах, избавляя команды от рутины и ускоряя внедрение новых решений. Но и считать, что no-code решит абсолютно всё, тоже нельзя.
На курсе «Интеграция систем. Разработка требований и основы проектирования» вы под руководством эксперта изучите на практике все этапы проектирования интеграций — от разработки требований к ним и до изучения современных технологий интеграций.
Регистрация
#интеграции@systems_education #REST@systems_education #брокеры@systems_education #Kafka@systems_education #SOAP@systems_education #XML@systems_education
🚨 О некоторых из них хотим рассказать сегодня:
— Границы возможностей: No-code платформы предоставляют богатый, но конечный набор готовых функций. Если требуемая логика выходит за эти рамки, без кода не обойтись. Проще говоря, кастомизация ограничена — сложные правила или специфические алгоритмы не реализуешь, если для них нет блока в интерфейсе.
— Масштаб и нагрузка: Когда речь о нескольких сотнях записей в день – no-code справится отлично. Но если нужно обработать миллион транзакций или обеспечивать задержки в миллисекундах, могут возникнуть проблемы с производительностью. Типичная архитектура no-code сервисов — облачная и мультиарендная, рассчитанная на усреднённые кейсы. Интенсивные нагрузки могут либо сильно стоить (тарифы часто зависят от количества операций), либо вообще выйти за пределы поддерживаемого. Кроме того, некоторые облачные интеграторы работают не в режиме реального времени, а с небольшими задержками. Например, у бесплатного тарифа Zapier задачи выполняются раз в 15 минут, что неприемлемо для ряда сценариев, требующих мгновенного отклик.
— Скрытая сложность: Фраза «без кода» не означает, что интеграцию может сделать кто угодно без подготовки. Порог входа ниже, чем у классического программирования, но разобраться всё же нужно. Новичку придётся понять логику работы переменных, условий, форматов данных, иначе даже с визуальным интерфейсом можно запутаться. Например, чтобы связать две системы, надо чётко представлять, какие данные на каком шаге передаются, в каком формате (JSON, XML, CSV и т.д.), как обработать ошибки. Без базовых знаний о тех же API и вебхуках возможно столкнуться с трудностями.
— Вендорозависимость и контроль: Используя стороннюю платформу интеграции, вы становитесь в определённой степени зависимы от неё. Все ваши связки хранятся в её облаке. Если сервис сбоит или меняет условия использования, это влияет на ваши процессы. Вы не можете залезть «под капот» и что-то поправить самостоятельно – придётся ждать, когда провайдер решит проблему. Гибкость ниже, чем при собственном код. Кроме того, возможны нюансы безопасности: важно доверять выбранной платформе, ведь через неё проходит корпоративная информация.
Интеграция без кода успешно работает в реальных проектах, избавляя команды от рутины и ускоряя внедрение новых решений. Но и считать, что no-code решит абсолютно всё, тоже нельзя.
На курсе «Интеграция систем. Разработка требований и основы проектирования» вы под руководством эксперта изучите на практике все этапы проектирования интеграций — от разработки требований к ним и до изучения современных технологий интеграций.
Регистрация
#интеграции@systems_education #REST@systems_education #брокеры@systems_education #Kafka@systems_education #SOAP@systems_education #XML@systems_education
❤2🔥2