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

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

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

Установив, что мы подразумеваем под объектом исследования: Организация производства ИС, продолжим разбирать формализованные варианты построения ЖЦ и экосистемы, поддерживающей его.

Начнем с определений.

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

Управление ИТ-производством – это организация и координация всех процессов, связанных с выпуском ИТ-продукта или оказанием услуг.  Это не управление проектами в классическом смысле. Это управление потоком создания ценности в высокодинамичной, сложной системе, где Сырьем являются идеи, а Продукцией — измеримая ценность для бизнеса.

Существует множество подходов организации производства в ИТ-отрасли, которые применяются в зависимости от приоритета целей, специфики бизнеса, типа продукции, уровня автоматизации и прочих факторов. Чтобы целенаправленно управлять этими процессами как системой, а не набором людей, проектов и методологий, чтобы осознанно комбинировать различные методики и приемы в зависимости от условий, прежде всего необходимо разобраться в фундаментальных способах классификации характеристик ИТ-производства.

Загадка: во сколько раз увеличится RPS на ручку поллинга, если уменьшить интервал поллинга с 5 минут до 2? 

Ответ: в 2,5 раза!

Привет! Меня зовут Стёпа, и я разработчик в Яндекс Go. Я хочу поделиться тем, как математика может встречаться в самых неожиданных местах — даже в такой рутинной задаче, как настройка интервала поллинга. В статье я рассмотрю модельный пример, который встречался каждому разработчику, и просчитаю его с математической точки зрения, использовав базовые факты из теории вероятностей и статистики.

Если с 2022 по 2024 год рынок проходил момент пика количества вакансий при нехватке специалистов, то сейчас ситуация обратная. Кандидатов много, но предложений меньше, а требования к системным аналитикам выше.

Меня зовут Филипп Сенцов, я Lead Solution Architect в финтех-компании и ментор курса «Системный аналитик» в Яндекс Практикуме. В этом тексте расскажу, какие сложности переживает рынок найма и как начинающим и опытным специалистам с ними справиться. Некоторые утверждения будут актуальны только для системных аналитиков, но многие — для всех IT-специалистов.

Ранее в статье "Почему нейросети не заменят прикладных специалистов: простая логика против вероятностных подходов" рассматривались общие вопросы поиска решений управляемого данными. Кратко: это механизм динамического связывания отдельных фрагментов решения в виде информационных блоков в последовательности для определения запрошенных параметров. Эта информационная технология, основанная на простой логике, позволяет оперативно вести диалог с пользователем, используя накопленные в процессе поиска решения данные. Для того чтобы общаться с системой на естественном языке необходим терминологический словарь предметной области.

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

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

ПРИМЕЧАНИЕ. В качестве примера выбрана реальная задача из медицинской практики связанная с назначением антирабической помощи. Антирабическая помощь необходима для исключения заболевания бешенством после контакта с домашним или диким животным. Бешенство смертельно опасное заболевание. От правильности врачебных назначений зависит жизнь обратившегося за медицинской помощью. Имеется инструкция, регламентирующая действия по оказанию антирабической помощи, которая и является первоисточником базы знаний. Несмотря, на кажущуюся простоту выбор лечения (профилактики) требует чёткого анализа ситуации и учёта многих факторов. Экспертная система в диалоге управляемом данными не позволит ничего пропустить и предложит безошибочное решение.

Когда Anthropic анонсировали Claude Cowork, первой моей мыслью было: «Наконец-то! Теперь я смогу пересадить на это команду, жену и всех тех, кто падает в обморок от слова `bash».
Моя лента наполнилась восторженными отзывами: «Mindblowing!», «Game changer!», «Убийца рутины!».

Спойлер: не получилось.

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

Привет, меня зовут Евгений Смоленцев, я работаю программистом в АНО по развитию городской среды «МосводостокСтройТрест», которая занимается благоустройством улиц и сезонной инфраструктуры, капитальным ремонтом многоквартирных домов и объектов образования, строительством производственных баз, а также выполнением специализированных задач учредителя. В этом посте расскажу, как мы с помощью MWS Tables собрали учет оборудования в систему полного цикла — от закупки и присвоения инвентарного номера до выдачи сотруднику и возврата. Спойлер: мы сделали видимые взаимосвязи, удобные формы для внесения записей и генерацию актов по шаблону прямо из таблицы.

Или как я за 200+ внедрений научился отличать реальную боль от маркетинговой иллюзии

Знаете, что меня бесит больше всего в этой индустрии? Когда бизнес тратит 200–300 тысяч на «решение всех проблем», а через полгода система, на которую потрачены силы и время, не открывается и не используется. Деньги в трубу. И самое обидное — это не вина технологии или IT продукта. Это вина того, что никто не задал правильные вопросы ДО покупки.

За 200+ внедрений я насмотрелся на эту картину столько раз, что могу предсказать провал ещё на первой встрече. И сейчас расскажу, почему так происходит и как этого избежать.

Хочу познакомить вас с одной аналогией, которая в своё время помогла мне усвоить, как же работает микросервисная архитектура.

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

Вы написали безупречное техническое задание. Провели двадцать интервью. Заполнили сто страниц в Confluence. Проект запущен, а через месяц ключевой стейкхолдер говорит: «Нет, это не то, что мы хотели». Знакомо?

Классический бизнес-анализ даёт нам инструменты для работы с озвученными потребностями. Но настоящая магия (и главные риски проекта) скрыта в зоне неозвученных мотивов, страхов и психологических игр. Сегодня поговорим о том, как применять методы, условно называемые «психоанализом стейкхолдеров», не будучи психологом.

Стандарты автоматизации корпоративных информационных систем развиваются эволюционно: от автоматизации небольшой предметной области, обеспечиваемую незначительным программным функционалом, до покрытия хозяйственных операций предприятий и даже холдингов, требующего масштабных программно-технических разработок. Это наглядно демонстрирует стандарт ERP, включавший в себя изначально класс систем MRP2, далее трансформировавшийся в ERP2 и ERP3, объединив множество прочих классов систем (SRM, CRM, PLM, SCM, FI и др.). Таким образом полнота охватов бизнес-процессов демонстрирует степень развития как предприятия, так и программного решения. Не стал исключением и класс автоматизации CRM: технологическое развитие и инновации в области управления взаимоотношениями с клиентами, их опытом и знаниями, позволил расширить данных стандарт и предложить новый – Customer Experience или CX.

В данной работе мы выполним обзор стандарта автоматизации CX, не так давно появившегося на рынке корпоративных программных систем. Рассказ будет построен следующим образом:

Всем привет! Меня зовут Сидоров Антон, я руководитель отдела технической архитектуры в департаменте сопровождения информационных технологий ПСБ. Моя команда занимается архитектурой инфраструктурных систем, и сегодня я хочу рассказать вам про наш первый опыт использования подхода «Архитектура как код»

Большие языковые модели (LLM) становятся мощными инструментами для автоматизации моделирования бизнес-процессов, обещая упростить перевод текстовых описаний процессов в диаграммы Business Process Model and Notation (BPMN). Однако степень, в которой эти системы ИИ способны создавать высококачественные BPMN-модели, пока не подверглась тщательной оценке.

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

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

Наши выводы показывают, что хотя существующие инструменты на базе LLM способны создавать BPMN-диаграммы, отражающие основные элементы описания процесса, они часто демонстрируют ошибки — пропущенные шаги, непоследовательную логику или нарушения правил моделирования, что подчёркивает ограничения в достижении полностью корректных и полных моделей. Чёткость и читаемость генерируемых диаграмм также различаются, указывая на то, что эти модели ИИ всё ещё находятся на стадии созревания в генерации легко интерпретируемых потоков процессов.

При обсуждении вопросов, связанных с процессами разработки Информационных систем (далее ИС) в среде ИТ специалистов сплошь и рядом возникают споры, как это делать максимально правильно и канонично. К примеру “свидетели” Каскадной (Waterfall) модели, зачастую вызывают лишь раздражение и насмешки у адептов Гибких (Agile) методологий, считающих их анахроничными. При этом сложившееся их самих понимание о той единственно верной парадигме организации процесса, а скорее возможность гибко и технично обходить эту парадигму, не дает даже шанса договориться о целостном восприятии темы. И чего уж греха таить, как правило упорство при отстаивании своей точки зрения, это просто лазейка для прикрытия недостаточно глубокого осмысления, почему именно так или иначе протекает тот или иной техпроцесс.

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

В корне этой дезориентации могут лежать следующие факторы...

Данный материал создан учеными Национального исследовательского университета «МЭИ» (НИУ «МЭИ») кафедры Автоматизированных систем управления тепловыми процессами (АСУТП). Представленные сведения основаны на результатах научных исследований и отражают профессиональное мнение авторов.

Если в вашей компании RCA формально существует, но инциденты повторяются,

а выводы так и не доходят до backlog, то эта статья для вас.

Статья не о том, как правильно делать RCA (Root Cause Analysis), и не о том, какие шаблоны или методики лучше использовать. Она о том, почему RCA в реальной жизни часто не приводит к изменениям и почему отсутствие RCA это не нейтральное состояние, а решение менеджмента, даже если его так не называют.

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

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

В своей работе я применяю ITIL 4, в связи с этим, я буду использовать терминологию применяемую этого фреймворка.

Привет, Хабр! Мой путь в мире IT официально начался относительно недавно: в октябре 2025 года. До этого программирование вообще не выходило за рамки увлечений. Но однажды я решил испытать удачу и выйти на тропу приключений, после которой я уже не вернулся прежним...

Привет, Хабр! Когда-то совсем недавно я, (пока что) зеленый джун, узнал о таком интересном языке, как Brainfuck. Даже не языке, а так, "язычке", с 8 командами. 8-битные лимиты чисел (т.е. не может обрабатывать числа больше 255), а синтаксис и процесс кодинга такой, что и тимлид там ногу сломит. Увидев сие чудо 1993 года (динозавер), меня постигла безумнейшая идея провести один веселый вечер за компов, породив полноценный калькулятор, использовав BF-код для вычислительных мощей в своей забавной разработке. Но сначала давайте по порядку...

Типовая ситуация: в проект приходят умные люди, менеджеры внедряют эффективные процессы, а проект все равно превращается в болото. Фичи разрабатываются месяцами, релизы откладываются, а на ретроспективах все жалуются на зависимости. При этом на схемах все выглядит красиво: микросервисы, CI/CD, облака. Что с этим миром не так?

Понятно, что «не так» может быть что угодно и как обычно it depends, но здесь и сейчас разберем одну из возможных причин, а именно ситуацию, при которой архитекторы и техлиды работают только с одним видом сложности – технологической. Рисуют квадратики, проводят стрелочки, выбирают базы данных. Реальность разработки при этом гораздо сложнее: в любом проекте одновременно живут три вида сложности, и они постоянно влияют друг на друга.

Привет, Хабр! Меня зовут Игнатий Цукергохер, я фриланс-журналист и блогер. На Хабре в основном пишу про технику и выкладываю интервью, но решил вернуть рубрику обзоров мероприятий. И начну с такой камерной и при этом хардкорно-айтишной встречи, как True Tech Arch #8.

От корпоративной ИТ-архитектуры сегодня ждут скорости, устойчивости и понятной ценности для бизнеса, но она все еще часто существует в виде схем, презентаций и документов, которые быстро устаревают и мало помогают в ежедневной работе команд. На конференции True Tech Arch #8, последней встрече Гильдии архитекторов MWS в 2025 году, рассказывали, как выбраться из этого замкнутого круга.

В этом материале расскажу про основные темы, которые на ней поднимались: переход от Big Data к Small Data и Data Lakehouse, способы превратить архитектуру в исполняемую и измеряемую систему, а также изменение роли архитектора и коммуникаций между командами при внедрении AI-ассистентов.