Представьте, что вы разрабатываете API для ветеринарной клиники. Вы проектируете метод GET /animals, который возвращает список всех питомцев. Однако ваша клиника расширяется и вы начинаете обслуживать не только кошек, но и собак и рептилий. Ваш врач-ветеринар говорит, что помимо общей информации (кличка, возраст, данные хозяина) нужно хранить специфические для каждого вида животных данные.
⬆️ Интересная ситуация? Давайте подумаем, что делать в таком случае?
Более подробно изучить вопросы проектирования API и интеграций вы можете в рамках курса «Интеграция систем. Интеграция систем. Разработка требований и основы проектирования + ИИ»
Автор поста — Юрий Насу
Под редакцией SE
Более подробно изучить вопросы проектирования API и интеграций вы можете в рамках курса «Интеграция систем. Интеграция систем. Разработка требований и основы проектирования + ИИ»
Автор поста — Юрий Насу
Под редакцией SE
⬇️ Код из карточек — Спецификация OpenAPI
openapi: 3.0.3
info:
title: Vet Clinic API
version: 1.0.0
paths:
/animals:
get:
summary: List animals
responses:
"200":
description: Animals list (polymorphic items)
content:
application/json:
schema:
type: array
items:
$ref: "#/components/schemas/Animal"
components:
schemas:
Animal:
oneOf: # указывает, что объект Animal должен соответствовать одной (и только одной) из указанных ниже схем
- $ref: "#/components/schemas/Cat"
- $ref: "#/components/schemas/Dog"
- $ref: "#/components/schemas/Reptile"
discriminator: # дискриминатор
propertyName: species # используется поле species для определения типа
mapping: # маппинг схемы ответа для каждого вида животного в зависимости от значения species
cat: "#/components/schemas/Cat"
dog: "#/components/schemas/Dog"
reptile: "#/components/schemas/Reptile"
AnimalBase:
type: object
required: [id, name, species, ageYears, owner]
properties:
id:
type: string
name:
type: string
species:
type: string
description: Discriminator (animal kind). Will be extended
ageYears:
type: integer
owner:
$ref: "#/components/schemas/Owner"
Owner:
type: object
required: [id, fullName]
properties:
id:
type: string
fullName:
type: string
Cat:
allOf: # Используется для склейки AnimalBase и специфичных для Cat полей
- $ref: "#/components/schemas/AnimalBase"
- type: object
required: [species, felvStatus]
properties:
species:
type: string
enum: [cat]
felvStatus:
type: string
enum: [positive, negative, unknown]
description: FeLV test status
Dog:
allOf:
- $ref: "#/components/schemas/AnimalBase"
- type: object
required: [species, heightAtWithersCm]
properties:
species:
type: string
enum: [dog]
heightAtWithersCm:
type: integer
description: Height at withers in centimeters
Reptile:
allOf:
- $ref: "#/components/schemas/AnimalBase"
- type: object
required: [species, enclosureTempC]
properties:
species:
type: string
enum: [reptile]
enclosureTempC:
type: number
description: Enclosure temperature in Celsius
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍3❤1
Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
Нам помогают и мы сохраняем, что можем А теперь хорошие новости. Вчера произошло шоковое по позитивности событие. Ко мне в личку пришёл подписчик наших каналов и групп, который знает меня более 10 лет и предложил финансовую помощь в размере 300 тр. Как…
Сохранили для вас бесплатные тесты на сайте ещё на год: https://systems.education/b-test-q27
systems.education
ACSE. Бесплатный тест для оценки компетенций системного аналитика / 27 вопросов
В-тест Q27
❤18
Заполненный_шаблон_Acceptance_Criteria_SE.docx
400.3 KB
#рубрика_артефакт@systems_education
🏫 Шаблон Acceptance Criteria в формате Gherkin
На проектах часто бывает, что при описании требований от бизнеса до разработки они доходят в искаженном виде и проблема проекта упирается в «Мы так поняли». Как описывать требования так, чтобы они не искажались восприятием разработки и тестирования?
Один из ключевых артефактов, который помогает это сделать — Acceptance Criteria в формате Gherkin. Это таблица, в которой каждая строка — один критерий приемки к User Story:
— Код Acceptance Criteria — Уникальный код вида AC-<код Story>-<порядковый номер>
— Acceptance Criteria — Краткая формулировка критерия на бизнес‑языке
— Описание сценария (Gherkin) — Сценарий в формате Given / When / Then / And / But
⬆️ Можете скачивать файл и сразу использовать для работы. Инструкция по заполнению шаблона внутри файла.
На воркшопе «Бизнес-анализ. Разработка пользовательских требований и постановка задач на разработку» вы также сможете научиться описывать постановку задачи на разработку ИТ-системы, сервиса, продукта в понятной, однозначной, наглядной форме, не залезая в детали реализации.
Автор поста — Владимир Бурмистров
Под редакцией SE
#воркшоп@systems_education
На проектах часто бывает, что при описании требований от бизнеса до разработки они доходят в искаженном виде и проблема проекта упирается в «Мы так поняли». Как описывать требования так, чтобы они не искажались восприятием разработки и тестирования?
Один из ключевых артефактов, который помогает это сделать — Acceptance Criteria в формате Gherkin. Это таблица, в которой каждая строка — один критерий приемки к User Story:
— Код Acceptance Criteria — Уникальный код вида AC-<код Story>-<порядковый номер>
— Acceptance Criteria — Краткая формулировка критерия на бизнес‑языке
— Описание сценария (Gherkin) — Сценарий в формате Given / When / Then / And / But
На воркшопе «Бизнес-анализ. Разработка пользовательских требований и постановка задач на разработку» вы также сможете научиться описывать постановку задачи на разработку ИТ-системы, сервиса, продукта в понятной, однозначной, наглядной форме, не залезая в детали реализации.
Автор поста — Владимир Бурмистров
Под редакцией SE
#воркшоп@systems_education
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6🔥5🥰1
Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
Нам помогают и мы сохраняем, что можем А теперь хорошие новости. Вчера произошло шоковое по позитивности событие. Ко мне в личку пришёл подписчик наших каналов и групп, который знает меня более 10 лет и предложил финансовую помощь в размере 300 тр. Как…
Команда продукта Storm BPMN оказала существенную финансовую поддержку нашей школе, спасибо коллегам огромное!
👉 StormBPMN — платформа, которая превращает бизнес-процессы в прозрачную и управляемую систему.
Что внутри:
— Моделирование процессов в BPMN (понятно всем, не только аналитикам)
— Единая база всех процессов, ролей и документов
— Согласование процессов прямо в браузере (без лишнего софта)
— Контроль связей и узких мест в процессах
— Автоматическая проверка ошибок в моделях
Почему это важно:
✔️ меньше хаоса и «ручного управления»
✔️ быстрее согласования и внедрение изменений
✔️ прозрачная ответственность (кто за что отвечает)
✔️ решения на основе данных, а не интуиции
Результаты пользователей:
📉 до −46% времени выполнения процессов
📈 рост эффективности и ускорение внедрения BPM
💡 Это не просто редактор схем — это полноценная система управления процессами: от моделирования до контроля KPI в одной среде.
Если вы строите процессный офис, внедряете BPM или просто хотите «разгрести бардак» — стоит посмотреть.
В ближайшее време анонсируем ещё пару коллабораций с Storm BPMN.
👉 StormBPMN — платформа, которая превращает бизнес-процессы в прозрачную и управляемую систему.
Что внутри:
— Моделирование процессов в BPMN (понятно всем, не только аналитикам)
— Единая база всех процессов, ролей и документов
— Согласование процессов прямо в браузере (без лишнего софта)
— Контроль связей и узких мест в процессах
— Автоматическая проверка ошибок в моделях
Почему это важно:
✔️ меньше хаоса и «ручного управления»
✔️ быстрее согласования и внедрение изменений
✔️ прозрачная ответственность (кто за что отвечает)
✔️ решения на основе данных, а не интуиции
Результаты пользователей:
📉 до −46% времени выполнения процессов
📈 рост эффективности и ускорение внедрения BPM
💡 Это не просто редактор схем — это полноценная система управления процессами: от моделирования до контроля KPI в одной среде.
Если вы строите процессный офис, внедряете BPM или просто хотите «разгрести бардак» — стоит посмотреть.
В ближайшее време анонсируем ещё пару коллабораций с Storm BPMN.
1🔥28
Media is too big
VIEW IN TELEGRAM
Дело «Умный Лондон». Серия 5 — Словарь данных и UML: Каталог улик
Что произойдет, если на этапе проектирования данных позволить заказчику вписывать свободный текст в атрибуты состояний, да еще и без сохранения истории? Нет, система не рухнет. Но она потеряет главное — способность хранить полный архив с каталогом улик с четкой привязкой к дате и времени, как того требуют правила раскрытия любого преступления.
В пятой серии расследования Шерлок проводит ревью модели данных для домена Управления инцидентами. ИИ Лестрейд сгенерировал PlantUML-код, где атрибут Status у класса Incident оказался обычной перезаписываемой строкой (String). Мэр Лондона обрадовался: теперь его цифровые аватары смогут писать туда длинные PR-сообщения для жителей. Но если передать такую спецификацию в разработку, алгоритмы маршрутизации не смогут обрабатывать тексты, город потеряет весь аудит происшествий, а скорые застрянут в пробках.
В новом видео Шерлок с помощью PlantUML выносит статусы в класс-справочник (Reference Data), добавляет класс истории (Status History) и наполняет словарь данных точными системными кодами (NEW, DISPATCHED, ON_SCENE и др.), которые управляют умными светофорами.
⬆️ Как Холмс и ИИ Лейстрейд разбираются с этими задачами по методике SARD — смотрите в видео-обзоре.
🎥 Посмотреть видео на YouTube
Автор поста — Елена Беляева
Под редакцией SE
#курс@systems_education #системный_анализ@systems_education
За всей серией постов следите по хештегу #Шерлок@systems_education
Что произойдет, если на этапе проектирования данных позволить заказчику вписывать свободный текст в атрибуты состояний, да еще и без сохранения истории? Нет, система не рухнет. Но она потеряет главное — способность хранить полный архив с каталогом улик с четкой привязкой к дате и времени, как того требуют правила раскрытия любого преступления.
В пятой серии расследования Шерлок проводит ревью модели данных для домена Управления инцидентами. ИИ Лестрейд сгенерировал PlantUML-код, где атрибут Status у класса Incident оказался обычной перезаписываемой строкой (String). Мэр Лондона обрадовался: теперь его цифровые аватары смогут писать туда длинные PR-сообщения для жителей. Но если передать такую спецификацию в разработку, алгоритмы маршрутизации не смогут обрабатывать тексты, город потеряет весь аудит происшествий, а скорые застрянут в пробках.
В новом видео Шерлок с помощью PlantUML выносит статусы в класс-справочник (Reference Data), добавляет класс истории (Status History) и наполняет словарь данных точными системными кодами (NEW, DISPATCHED, ON_SCENE и др.), которые управляют умными светофорами.
Автор поста — Елена Беляева
Под редакцией SE
#курс@systems_education #системный_анализ@systems_education
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8🔥1
Узнать больше про проектирование интеграций с REST API можно на воркшопе
Автор поста — Дарья Курнаева
Под редакцией SE
#воркшоп@systems_education #интеграция@systems_education #RESTAPI@systems_education
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6
Опубликовали запись интервью с Дмитрием Боболевым на тему «От разработчика к фаундеру — как на самом деле строится продукт»
Как выглядит реальный discovery в стартапе, когда у тебя нет аналитиков, методологий и красивых фреймворков — но есть идея, рынок и давление времени?
Поговорили с Дмитрием Боболевым — основателем стартапа Froxi AI — про путь от разработчика к фаундеру, запуск продукта и работу с пользователями в условиях неопределённости.
Тайм-код интервью:
00:00 Приветствие
00:59 О спикере. Путь от разработчика к фаундеру
02:57 Роль фаундера: как проходит день и на что уходит время
05:16 Общение с пользователями: кастдев и работа с потребностями
08:10 Как рождалась идея и формировался продукт
10:58 Проверка гипотез и валидация идеи на практике
17:58 Как искать точки роста продукта помимо общения с пользователями
20:06 Нужен ли аналитик в стартапе и вопросы делегирования
22:04 Переход к своему продукту: страхи, сомнения и личный опыт
27:05 Ошибки и фейлы при запуске и развитии продукта
33:23 Что сложнее: найти причину проблемы или её исправить
36:11 Зачем развивать офлайн-сообщество в цифровую эпоху
41:49 Жизненный цикл сообщества: как поддерживать его активность
46:04 Самый важный навык для IT-специалистов в ближайшие годы
49:02 Заключение
Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК
#вебинары@systems_education
Как выглядит реальный discovery в стартапе, когда у тебя нет аналитиков, методологий и красивых фреймворков — но есть идея, рынок и давление времени?
Поговорили с Дмитрием Боболевым — основателем стартапа Froxi AI — про путь от разработчика к фаундеру, запуск продукта и работу с пользователями в условиях неопределённости.
Тайм-код интервью:
00:00 Приветствие
00:59 О спикере. Путь от разработчика к фаундеру
02:57 Роль фаундера: как проходит день и на что уходит время
05:16 Общение с пользователями: кастдев и работа с потребностями
08:10 Как рождалась идея и формировался продукт
10:58 Проверка гипотез и валидация идеи на практике
17:58 Как искать точки роста продукта помимо общения с пользователями
20:06 Нужен ли аналитик в стартапе и вопросы делегирования
22:04 Переход к своему продукту: страхи, сомнения и личный опыт
27:05 Ошибки и фейлы при запуске и развитии продукта
33:23 Что сложнее: найти причину проблемы или её исправить
36:11 Зачем развивать офлайн-сообщество в цифровую эпоху
41:49 Жизненный цикл сообщества: как поддерживать его активность
46:04 Самый важный навык для IT-специалистов в ближайшие годы
49:02 Заключение
Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК
#вебинары@systems_education
YouTube
Интервью: от разработчика к фаундеру — как на самом деле строится продукт
Как выглядит реальный discovery в стартапе, когда у тебя нет аналитиков, методологий и красивых фреймворков — но есть идея, рынок и давление времени?
Поговорили с Дмитрием Боболевым — основателем стартапа Froxi AI — про путь от разработчика к фаундеру, запуск…
Поговорили с Дмитрием Боболевым — основателем стартапа Froxi AI — про путь от разработчика к фаундеру, запуск…
❤2
Forwarded from Денис Бесков написал
Zoom
Welcome! You are invited to join a meeting: Вебинар про автоматический анализ законов с ИИ. After registering, you will receive…
Чужой против Хищника: как ИИ разбирает российские законы
Строгость российских законов смягчается необязательностью их исполнения — попробуйте объяснить эту крылатую фразу системе, в которой должны быть зашиты правила, проверки и статусы.
7 апреля в 19:00 на бесплатном вебинаре Алина Богачёва и Денис Бесков покажут, как переводить юридический на язык системных и бизнес-аналитиков.
Как из фразы, после которой хочется закрыть ноутбук и уйти в лес, получить понятное бизнес-правило и нормальное требование к системе. И нет, промт «ИИ, нормально сделай мне анализ закона» не работает.
Будем использовать ИИ как ассистента, который помогает разложить текст по цепочке: норма → логика → бизнес-правило → требование. Отработаем на реальных примерах.
Допустим, возьмём 152-ФЗ, статья 18, часть 5 (не пытайтесь это прочитать самостоятельно без помощи профессионала):
Для бизнеса: переходим с Google Forms на Яндекс формы.
Для системы: если в контуре есть внешний IdP, CRM, SaaS-форма или сервис авторизации, они не должны быть первичной точкой записи персональных данных граждан РФ.
Или, скажем, 63-ФЗ, статья 11 (уберите детей от экрана):
Для бизнеса: короче, используйте Госключ и живите спокойно.
Для системы: проверка КЭП должна быть не булевым полем is_signed = true, а полноценной цепочкой проверки сертификата, ключа, времени подписания и целостности документа.
ЗАПИСИ НЕ БУДЕТ
(некоторые реакции на юридический язык хороши только в прямом эфире, на монтаже цензуры не оберёшься)
Как вы понимаете, вебинар будет содержать сцены аналитического насилия над канцеляритом.
Потому что в системе необязательность исполнения не работает.
Регистрация на вебинар
Строгость российских законов смягчается необязательностью их исполнения — попробуйте объяснить эту крылатую фразу системе, в которой должны быть зашиты правила, проверки и статусы.
7 апреля в 19:00 на бесплатном вебинаре Алина Богачёва и Денис Бесков покажут, как переводить юридический на язык системных и бизнес-аналитиков.
Как из фразы, после которой хочется закрыть ноутбук и уйти в лес, получить понятное бизнес-правило и нормальное требование к системе. И нет, промт «ИИ, нормально сделай мне анализ закона» не работает.
Будем использовать ИИ как ассистента, который помогает разложить текст по цепочке: норма → логика → бизнес-правило → требование. Отработаем на реальных примерах.
Допустим, возьмём 152-ФЗ, статья 18, часть 5 (не пытайтесь это прочитать самостоятельно без помощи профессионала):
При сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети "Интернет", запись, систематизация, накопление, хранение, уточнение (обновление, изменение), извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся за пределами территории Российской Федерации, не допускаются, за исключением случаев...
Для бизнеса: переходим с Google Forms на Яндекс формы.
Для системы: если в контуре есть внешний IdP, CRM, SaaS-форма или сервис авторизации, они не должны быть первичной точкой записи персональных данных граждан РФ.
Или, скажем, 63-ФЗ, статья 11 (уберите детей от экрана):
Квалифицированная электронная подпись признается действительной, если квалифицированный сертификат действителен на момент подписания электронного документа (при наличии достоверной информации о моменте подписания электронного документа) или на день проверки действительности указанного сертификата, если момент подписания электронного документа не определен...
Для бизнеса: короче, используйте Госключ и живите спокойно.
Для системы: проверка КЭП должна быть не булевым полем is_signed = true, а полноценной цепочкой проверки сертификата, ключа, времени подписания и целостности документа.
ЗАПИСИ НЕ БУДЕТ
(некоторые реакции на юридический язык хороши только в прямом эфире, на монтаже цензуры не оберёшься)
Как вы понимаете, вебинар будет содержать сцены аналитического насилия над канцеляритом.
Потому что в системе необязательность исполнения не работает.
Регистрация на вебинар
🔥7
devhands.ru
Системный дизайн высоконагруженных проектов
Среди нишевых школ, которые занимаются архитектурой и системным дизайном, есть DevHands.
С Алексеем Рыбаком, основателем проекта, мы знакомы давно — ещё со времён Badoo и далее конференции HighLoad-2008, где я был программным директором. Так что для меня это не просто рекомендация «где-то слышал», а проект, за которым я давно наблюдаю и который неплохо понимаю.
Если в Systems.Education мы чаще смотрим на системный дизайн через требования, продуктовую логику и системную архитектуру, то в DevHands фокус другой: backend, программная архитектура, инфраструктура, масштабирование, базы, очереди, наблюдаемость. То есть взгляд на систему — со стороны инженера, которому важно не столько придумать концептуальное решение, но детально понимать, как конкретно оно будет работать, разворачиваться, поддерживаться.
Что мне в подходе Devhands кажется интересным:
— там не разбирают архитектуру в отрыве от инженерного контекста
— курсы делают и ведут люди, которые сами работали с большими сложными системами, а не просто пересказывают теорию
— делается упор на высокие нагрузки, оценку пропускной способности и разбор нагрузочного профиля
— там, где это уместно, дают реальные стенды и серверы, чтобы можно было руками пройти через практику
— обучение живое: встречи, демо, обсуждения, совместное проектирование
Для системных аналитиков и архитекторов, мне кажется, особенно интересен курс «Системный дизайн высоконагруженных проектов», который ведёт сам Алексей. Там нет сильного уклона в инфраструктурную практику — и для нашей аудитории это скорее плюс: можно сосредоточиться на самой практике проектирования.
Ещё у ребят есть открытый трёхчасовой вебинар (ссылка в комментах) по основам системного дизайна — хорошая возможность присмотреться, понять, как Алексей объясняет, насколько вам близок его подход и хочется ли идти глубже.
Так что если тема системного дизайна вам сейчас актуальна и вам близок глубокий инженерный подход, рекомендую посмотреть вебинар или программу курса, а дальше уже спокойно решить, подходит вам такой формат или нет.
Денис Бесков
С Алексеем Рыбаком, основателем проекта, мы знакомы давно — ещё со времён Badoo и далее конференции HighLoad-2008, где я был программным директором. Так что для меня это не просто рекомендация «где-то слышал», а проект, за которым я давно наблюдаю и который неплохо понимаю.
Если в Systems.Education мы чаще смотрим на системный дизайн через требования, продуктовую логику и системную архитектуру, то в DevHands фокус другой: backend, программная архитектура, инфраструктура, масштабирование, базы, очереди, наблюдаемость. То есть взгляд на систему — со стороны инженера, которому важно не столько придумать концептуальное решение, но детально понимать, как конкретно оно будет работать, разворачиваться, поддерживаться.
Что мне в подходе Devhands кажется интересным:
— там не разбирают архитектуру в отрыве от инженерного контекста
— курсы делают и ведут люди, которые сами работали с большими сложными системами, а не просто пересказывают теорию
— делается упор на высокие нагрузки, оценку пропускной способности и разбор нагрузочного профиля
— там, где это уместно, дают реальные стенды и серверы, чтобы можно было руками пройти через практику
— обучение живое: встречи, демо, обсуждения, совместное проектирование
Для системных аналитиков и архитекторов, мне кажется, особенно интересен курс «Системный дизайн высоконагруженных проектов», который ведёт сам Алексей. Там нет сильного уклона в инфраструктурную практику — и для нашей аудитории это скорее плюс: можно сосредоточиться на самой практике проектирования.
Ещё у ребят есть открытый трёхчасовой вебинар (ссылка в комментах) по основам системного дизайна — хорошая возможность присмотреться, понять, как Алексей объясняет, насколько вам близок его подход и хочется ли идти глубже.
Так что если тема системного дизайна вам сейчас актуальна и вам близок глубокий инженерный подход, рекомендую посмотреть вебинар или программу курса, а дальше уже спокойно решить, подходит вам такой формат или нет.
Денис Бесков
👍6❤4🔥1🦄1