Анализ и проектирование систем *

Привет, Хабр!

Я — независимый разработчик, и хочу рассказать о своём open-source проекте ATMO NeuroYoga (https://play.google.com/store/apps/details?id=com.atmo.full ) — мобильном приложении для заботы о нервной системе. Текущая версия 1.4.1 уже доступна и включает упражнения NeuroYoga breathing и интерактивные точки акупрессуры. Но главная цель проекта — ATMO Shield, полностью оффлайн инструмент для непрерывного мониторинга и защиты нервной системы на основе вариабельности сердечного ритма (HRV).

Цель статьи — провести классификацию и иерархическое деление требований на группы с конкретными примерами из лабораторной практики. Разделение требований на группы и подгруппы необходимо для правильного построения проектного решения, основанного на анализе требований, а не на "представлениях о хорошем". Особенно это актуально для систем, подчиняющихся строгим стандартам, таким как ГОСТ ISO/IEC 17025-2019, который устанавливает общие требования к компетентности, беспристрастности и стабильной работе лабораторий.

Я провожу обучения и консультации для лабораторий, которые хотят автоматизировать часть своей деятельности и внедрить ЛИМС или адаптировать имеющиеся системы под задачи лаборатории. Естественно, что в самом начале я делаю акцент на необходимости правильной постановки цели автоматизации и разработке технического задания. В это время всегда появляется необходимость разделения требований на группы с определенной иерархией. Проанализировав разные подходы и классификации, я пришел к тому, что проще начать с дихотомического деления на функциональные и нефункциональные требования.

Предельная унификация a.k.a. IDEAV — хранение вообще всего как список Entity — Attribute — Value с дополнительным полем ID. Звучит пугающе, но реализация скрыта под капотом, а снаружи нам доступен максимально родной и дружественный интерфейс.

Все любят безопасность, пока не приходится её настраивать. Первая версия нашего аудита напоминала пульт управления АЭС: бесконечно гибко, но без инструкции не взлетишь. Мы признали поражение, послушали стоны администраторов и сделали «версию 2.0» — с классами событий и логикой, понятной человеку, а не только компилятору. История работы над ошибками, которая превратила «полочный» софт в рабочий инструмент.

Я работаю системным и бизнес-аналитиком, но периодически вижу обсуждения, что аналитики не нужны, либо не нужны били изначально, потому что DDD и вот это всё, либо не нужны становятся сейчас из-за развития нейросетей и трансформации разработки. Однако на своем опыте я вывел несколько причин, почему аналитики всё таки нужны:

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

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

Тушитель пожаров - аналитики на проектах часто выступают в роли затыкателя дыр, выполняя все возможные временные функции от тестировщика до тех.писа.

Собиратели конструкторов - аналитики заменяют разработку в проектах с лоу-код и ноу-код конструкторами.

Вайб-кодеры - в настоящее время за счет нейросетей аналитик может самостоятельно тестировать идеи в коде и прототипах вообще без разработчиков.

Привет, Хабр! Меня зовут Артем Евтеев, я ведущий аналитик в МТС Web Services. Кажется, каждый бизнес-аналитик (и не только) хотя бы раз в жизни слышал о книге «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти.

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

В жизни теория нередко сочетается с практикой. Но так ли это в профессии бизнес-аналитика в ИТ-компании — предлагаю разобраться. 

Согласно Hype Cycle от Gartner за 2025 год, AI-агенты достигли пика завышенных ожиданий. Но что скрывается за хайпом с технической точки зрения? Самое время разобраться, чтобы не ждать от технологии чудес, а использовать её по назначению.

В статье объединим теорию и практику построения AI-агентов. Сначала разберем ключевые концепции: цикл Perception-Reasoning-Action, модель PEAS (Performance, Environment, Actuators, Sensors), уровни автономии. А затем, опираясь на эти принципы, построим работающего AI-агента 3-го уровня автономии. Наш технологический стек: 

- Оркестратор n8n;

- LLM через агрегатор OpenRouter;

- Telegram в качестве пользовательского интерфейса.

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

Статья инспирирована переводом Распределенный монолит: тихий убийца мечты о микросервисах и некоторыми комментариями, отражающими, что тема описана не слишком подробно. Покажу видение данной темы немного с другой стороны.

Привет, Хабр! Меня зовут Андрей Боков, я главный архитектор отдела разработки хранилищ данных в «Газпром ЦПС». Если вы хоть раз сталкивались с тем, что информация о сотрудниках не соответствует в различных корпоративных системах, например, 1С, электронный документооборот, корпоративный портал, система управления проектами, – вы понимаете, о чем сейчас пойдет речь. Мы пробовали решить эту проблему точечными интеграциями, но с ростом числа систем увеличивался и хаос в данных. Нам был нужен единый контур, который позволит проследить путь данных от источников до отчета.

Так началась работа над корпоративным хранилищем данных (КХД). Мы выбрали многослойную архитектуру и методологию Data Vault 2.0 – подход, который сохраняет историю изменений и дает возможность подключать новые источники без перепроектирования структур хранилища. В статье я расскажу про наш опыт, который будет полезен специалистам по работе с данными: руководителям, архитекторам, аналитикам и инженерам. Подробно опишу, как мы строили ядро КХД и какие уроки и инсайты вынесли по результатам реализации.

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

Я Артем Лыков, ведущий RnD-разработчик в МТС Web Services. А параллельно — аспирант в Лаборатории интеллектуальной космической робототехники Сколтеха (руководитель Дмитрий Тетерюков), где лидирую направление когнитивной робототехники. Вместе с коллегами по лаборатории мы описали способ обойтись без многомесячных записей движений и сложных симуляций, опираясь на уже существующие VLA-модели и модульный агентный подход, позволяющий генерировать будущие действия робота прямо из картинки и текста, проверять их, править, повторять и в итоге добиваться результата, сравнимого со специализированными решениями. В этом материале я разберу архитектуру PhysicalAgent, покажу, как мы реализовали цикл Perceive → Plan → Reason → Act для роботов, и расскажу, чем нам помогли открытые видеомодели и как этот подход помогает переносить навыки между разными платформами.

Привет, Хабр! Меня зовут Роман Стрекаловский, я корпоративный архитектор в «Столото». Мой первый рабочий день начался с экскурсии в лотерейный центр — место, где воплощаются мечты миллионов. Блестящие шары, гул вращающихся барабанов, атмосфера напряжённого ожидания — всё это производило сильное впечатление. Я сразу почувствовал: здесь живёт энергия, которая двигает бизнес.

Но когда я заглянул «под капот» — в ИТ‑ландшафт компании, — меня ждало ещё более интересное открытие. Передо мной оказалась сложная, многолетняя экосистема: более 500 систем, выросших вместе с бизнесом, монолиты, сплетённые самописными интеграциями, и процессы, в которых ключевую роль играл опыт инженеров. Запуск нового решения мог занимать до года, а создание новой игры — требовать ручного внесения данных в десяток разных систем.

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

И я хочу поделиться этой историей с вами.

1 Операционная надежность (надежность операций, процессов, функций)

Регулятор (ЦентоБанк) уже несколько лет ведет «крестовый поход» под знаменем «Операционная надёжность»: выпускает «одноименные» Положения (850-П / 787-П, 779-П), Стандарты Банка России (СТО БР БФБО-1.5-2023), ГОСТы (ГОСТ 57580.3 / 57580.4, с его участием), а также методические рекомендации (18-МР) и формы обязательной отчетности по «Операционной надёжности» (operational resilience).

Под знаменем «Операционная надёжность» - делается попытка «скрестить» (где-то «ежа с ужом», но сама идея достойная) бизнес-архитектуру (архитектуру процессов, как технологических, так и бизнес – хотя разделение их не понятное), EA (enterprise architecture) / ИТ-архитектуру, ITSM (CMDB, управление инцидентами, в том числе, инцидентами операционной надежности), информационную безопасность (вкл. ГОСТ 57580.1 / 57580.2), надежность / отказоустойчивость / ОНиВД, риск-менеджмент (опер-риски, 716-П), импортозамещение (ФТК). Подобный «единый узел» - это проекции «одного и того же» на разные плоскости (EA, BPM, GRC, ИБ, ITIL и др.) с разными словарями / концепциями, поэтому формализовать его видимо равносильно притчи / сценарию «Вавилонская башня». Однако «язык графа» сближает такое восприятие и снижает барьер сложности.

Далее будем говорить только о Форме 0409072 (далее ф072) — «Сведения о показателях операционной надёжности кредитной организации и применяемых ею информационных технологиях при осуществлении банковской деятельности и деятельности в сфере финансовых рынков», точнее о ее части – шифре \ шифровке архитектуры предприятия. «Операционная надёжность» - это всего лишь контекст. 

Почему векторной базы/RAG недостаточно для качественной памяти ИИ-агентов. Приближаем поведение агента к человеческому с помощью архитектурных решений поверх LLM

В своей работе в качестве консультанта лабораторий по внедрению ЛИМС и системного аналитика часто сталкиваюсь с двумя понятиями: цифровизация и автоматизация. А недавно услышал интересное мнение, что цифровизация это не помощник, а надсмотрщик. Конечно захотелось разобраться в чем разница и почему так происходит
Путем недолгого запроса в нейросеть Qwen получил следующие определения:
Цифровизация — это перевод процессов, данных или взаимодействий в цифровой формат. Это не замена человека машинами, а переход от аналоговых или бумажных систем к цифровым инструментам.

Автоматизация — это использование технологий для выполнения задач без человеческого вмешательства. Здесь речь идет о замене ручного труда машинами, программами или алгоритмами.

Представление чисел в IT сфере - одна из самых простых вещей, которую интуитивно знает каждый разработчик, аналитик, тестировщик, админ (нужное подчеркнуть).

Еще из школы мы помним: Округление — замена числа на его приближённое значение (с определённой точностью), записанное с меньшим количеством значащих цифр. 

Точные определения и механизмы легко гуглятся.

Элементарные математические операции производятся в уме, мы даже не замечаем, как в разговорной речи мы округляем любые числа.

Это первая статья о том, как идея проходит путь от прототипа до полноценного продукта — с участием архитектуры на каждом шагу. Формат — ADR (Architecture Decision Records): каждое решение зафиксировано по дням, чтобы показать реальную эволюцию проекта. Продукт вымышленный, проблемы — настоящие. Те самые, с которыми сталкиваются архитекторы и команды. Документация и код — в открытом доступе на GitHub.

ИИ-агенты ворвались в чарты и обсуждения по всему миру, к ним прикован интерес, в них вливают миллиарды и интегрируют в продукты и платформы. Но долго ли это продлится?

На связи команда Research & Insights Центра стратегии цифровых продуктов МТС. Мы подготовили исследование мирового и российского рынка ИИ-агентов. Это третий материал на его основе: в первом рассказали об инсайдах исследования, во втором — о видах агентов. А в этом покажем, какие три сценария развития ИИ выделяют инвесторы, в какой верят больше всего и как в эту картину вписывается тренд на ИИ-агенты. 

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

На примере разработки AI-консультанта для своего агентства расскажу о системном подходе к проектированию архитектуры production-ready AI-агентов, который мы применяем при создании агентских систем для бизнеса. Чтобы они не были дорогой игрушкой, а приносили эффект и оправдывали своё назначение.

Поехали...

Чем хорош малый бизнес, особенно на своем старте? Ему не нужны сложные инструменты: он в состоянии увидеть состояние дел расчетами «на коленке», а план действий уместить карандашом на трамвайном билетике.

А когда бизнес подрастает? Скажем, его месячная выручка становится 100М+, количество сотрудников исчисляется сотнями, а бизнес-процессы усложняются настолько, что перестают быть прозрачными, покрываются «туманом войны».

Эта история про то, как инструмент, понравившийся команде на старте бизнеса, довел её до убытков в десятки миллионов при росте оборотов, когда компания стала крупнее. И как прозрачность вернула контроль и разблокировала рост выручки на 50%.

Нестабильность – это часть нашей жизни, и, конечно, невозможно избежать нестабильности в вопросах разработки. В современном, постоянно меняющемся мире непрерывно что-то происходит: новые требования закона, новые бизнес-процессы, новые библиотеки и интерфейсы. В этой статье я разбираю принципы проектирования ПО на основе нестабильности. Всех, кто устал переделывать компоненты, а также тех, кто уже научился не переделывать лишнее, приглашаю поговорить про принцип обратных зависимостей, оси нестабильности и принципы архитектурной устойчивости проекта.

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