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

Закон Мура, который обещал нам удвоение мощности каждые два года, оказался не вечным. Прямо сейчас мы наблюдаем за тем, как покорение производителями процессоров каждого следующего нанометра стоит все дороже, а прироста дает все меньше. Из-за этого почти половина операционных расходов дата-центров уходит на оплату электроэнергии. И это притом, что земля тоже не дешевеет, а площади под строительство новых ЦОД выкупаются везде и в любом состоянии. А масштабироваться в таких условиях, сами понимаете, весьма и весьма проблематично. Но бизнесу-то это не объяснишь. Значит, надо экономить. И, по возможности, там, где это делать проще всего.

Если вы пропустили INFOSTART TECH EVENT 2025 или «Анализ & Управление в ИТ-проектах 2025» - хорошая новость: мы собрали 20 самых рейтинговых выступлений и открыли к ним бесплатный доступ.

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

Меня зовут Александр Мачулин, я основатель Gramax – open source системы для ведения документации в подходе Docs as Code с визуальным редактором.

Сегодня я расскажу вам идею, как вести всю документацию по проекту и весь цикл разработки в одном Git-репозитории и настроить backward-трассировку требований в Git.

Несколько лет назад, когда мы только начинали внедрять Engee — среду для математического моделирования, техрасчётов и генерации встраиваемого кода — одним из первых крупных промышленных запросов стал интерес со стороны АО «ПО «УОМЗ». Коллеги представили техническое задание и предложили проверить, насколько Engee действительно готова для разработки алгоритмов обработки данных от датчиков и последующей интеграции в микроконтроллеры.

В этом материале я подробнее разберу, как проходил проект, какие задачи стояли, какие подходы к интеграции кода мы использовали и к каким результатам пришли. Фактически речь идёт не просто о демонстрации генерации кода, а о полноценной проверке возможности использовать Engee как замену MATLAB/Simulink в существующих инженерных процессах УОМЗ.

Привет, Хабр! В этой статье разберём модель AIaaS. Она помогает компаниям использовать ИИ без развёртывания собственной инфраструктуры и большой R&D‑команды. Такой подход снижает барьер входа и ускоряет запуск прототипов.

AIaaS (AI as a Service — ИИ как услуга) — это модель, при которой компания подключается к облачным API и получает готовые функции машинного обучения, LLM и компьютерного зрения. Инфраструктура моделей остаётся на стороне провайдера, а оплата идёт за вызовы и интеграцию, а не за развёртывание и обучение базовой модели.

Современные цифровые продукты выглядят устойчивыми.

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

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

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

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

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

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

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

Загадка: во сколько раз увеличится 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) методологий, считающих их анахроничными. При этом сложившееся их самих понимание о той единственно верной парадигме организации процесса, а скорее возможность гибко и технично обходить эту парадигму, не дает даже шанса договориться о целостном восприятии темы. И чего уж греха таить, как правило упорство при отстаивании своей точки зрения, это просто лазейка для прикрытия недостаточно глубокого осмысления, почему именно так или иначе протекает тот или иной техпроцесс.

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

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

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