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

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

Я отношусь к написанному ниже как к гипотезе, которую надо проверять об практику и об другие умы. Собственно этим я и занимаюсь, и продолжу заниматься.

Для начала вспомним что такое средовой подход и чем он отличается от системного

Это заключительная статья цикла. В ней мы рассмотрим разработку и отладку сценариев симуляции спутниковой связи. Разберемся в форматах описания исходных данных эксперимента (сцены эксперимента). А также получим представление об интерпретации результатов моделирования.

Я взял одного и того же агента (Claude Code), менял у него ровно одну вещь — какой MCP-сервер отдаёт контекст по коду, — и гонял по 26 задачам на apache/superset. Четыре «руки»: filesystem (grep + read), graphlens (структурный граф), serena (LSP) и codegraph. Три модели (haiku / sonnet / opus), три сида — 936 прогонов.

Главный результат: вывод переворачивается в зависимости от типа задачи.

В 2025 году мы работали над концепцией прикладного решения «1С Управление предприятием» для учебного курса УЦ №1 фирмы «1С». В основу легла процессная модель дискретного предприятия, которую мы много лет проверяли на реальных проектах. Видеоматериала получилось около 50 часов, а рабочих наработок — ещё больше.

Но в какой-то момент стало понятно: всё в учебную концепцию не войдёт. Хотелось показать и бизнес-предметы, и граф знаний, и объектно-ориентированный управленческий учёт, и связь ERP с будущим интеллектуальным предприятием. Но для входного курса это был бы перегруз.

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

Всем привет! Я Светлана Забирова, лид аналитики в Центре разработки и машинного обучения компании «Инфосистемы Джет». В ИТ работаю уже больше десяти лет, из них половину – в заказной разработке.

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

По заданному контексту ИИ хорошо справляются с кодом, миграциями, OpenAPI, сценариями и документацией. Но агентная разработка быстро начинает буксовать, если входной артефакт остается большой постановкой в Confluence, Word или Jira без строгой структуры и трассировки. Модель теряет важные условия, смешивает уровни детализации, дублирует требования или додумывает недостающие связи.

ИИ не будет работать лучше, если аналитики просто «начнут промптить». Задача решается уровнем выше: требования должны стать инженерным артефактом. То есть относиться к требованиям нужно так же, как разработчики относятся к коду.

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

Мы решили проверить подход на одном из пилотных проектов, где было все: аналитика, архитектура, backend/frontend-разработка, тестирование и DevOps.

Как мы перевели аналитику из Confluence/Word в SDD-контур и что из этого получилось, рассказываю под катом.

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

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

Именно поэтому принцип GIGO — garbage in, garbage out, «мусор на входе — мусор на выходе» — в логистике звучит особенно буквально. Если в мастер-данные попал неверный габарит товара, WMS не начнёт спорить с пользователем. Она просто будет добросовестно рассчитывать всё дальше на основе неправильной цифровой модели.

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

Новая Entry/Exit System, или EES, задумывалась как один из ключевых элементов цифровой границы Шенгенской зоны: вместо ручных паспортных штампов система должна автоматически фиксировать въезд, выезд и отказ во въезде для граждан третьих стран, приезжающих на короткий срок. Она собирает данные документа, дату и место пересечения границы, фотографию лица и отпечатки пальцев, а с 10 апреля 2026 года, по заявлению Еврокомиссии, стала полностью операционной во всех странах Шенгена, использующих систему.

Парадокс EES в том, что формально это проект автоматизации, но на практике он временно увеличил ручную нагрузку на аэропорты. Старая процедура — штамп в паспорте — была примитивной, плохо пригодной для аналитики и контроля overstayers, но физически быстрой. Новая процедура создает качественно более богатую цифровую запись, но требует первичной регистрации, биометрии, проверки данных, работы киосков, e-gates, национальных пограничных систем, центральной инфраструктуры eu-LISA, приложений предварительной регистрации и обученного персонала на месте. Иными словами, ЕС цифровизировал не одну операцию, а целую цепочку, где пропускная способность определяется самым слабым звеном.

Давайте разберём кейс подробнее:

Финансовые данные в компании обычно уже есть: в 1С, в хранилище, витринах, аналитических кубах. Но в конце отчётного периода аналитики всё равно часто делают одно и то же: выгружают числа в Excel, собирают сводные таблицы, вручную считают отклонения и готовят презентации для руководства. В этой статье покажем, как перевести такой процесс в промышленный контур: создать OLAP-модель, вынести бизнес-логику в семантический слой и получать живые отчёты в Web, Excel и LibreOffice без ручного копипаста. Выгружать данные будем из 1С, но в виду большого количества способов это сделать мы коснёмся этой темы в следующей статье, а здесь сосредоточимся я на возможностях анализа данных.

Статья будет особенно полезна:

- BI-разработчикам;

- архитекторам данных;

- бизнес-аналитикам;

- финансистам;

- руководителям, которым важно быстро получать корректную управленческую отчётность.

Немного насчет - «AI-агенты сделают разработку самоподдерживаемой».

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

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

Как это работает на практике:

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

Привет, Хабр! На связи Владимир Сыропятов, Senior Analyst в Garage Eight. Все же в детстве слушали сказки? Так вот, я бы хотел вспомнить одну из них — про мальчика и волков. В ней ребенок так часто зря кричал «Волки!», что жители деревни перестали реагировать на предупреждения. А когда волки пришли по-настоящему, ему никто не поверил.

Я это всё к тому, что в антифроде эта история повторяется регулярно, только вместо мальчика — система мониторинга, вместо деревни — операционная команда, а вместо волков — реальный фрод, который незаметно «подкрадывается», пока все заняты ложными тревогами. Именно такую картину я обнаружил на одной из платформ для управления инвестициями, когда пришел туда как антифрод-аналитик.

Если в компании уже используются AI‑инструменты, она может быстрее и дешевле производить свой продукт и, следовательно, давать более конкурентные цены. Конечно же, потребитель выберет производителя с AI.

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

Каждый, кто пробовал играть в настольные ролевые игры типа ДнД с ИИ‑ассистентом типа ChatGPT или Gemini, быстро упирался в ограничения: модель забывает контекст, подыгрывает пользователю, путается в очерёдности ходов и теряет сюжетные рельсы. Но что, если забрать у нейросети математику и управление, оставив ей то, в чём она сильна — работу с нарративом?

В этой статье я расскажу о своём пути R&D: от простого PoC «одна модель делает всё» через трёх агентов к параллельному событийно‑ориентированному пайплайну, где каждый новый шаг — это ответ на ограничение текущего решения.

Модераторы A&PM EVENT 2026 участвуют не только в формировании программы конференции. Они готовят собственные практические форматы: доклады, деловые игры, воркшопы и мастер-классы. В этом году в центре внимания — инструменты аналитика, архитектура решений на 1С, управление проектами и командами, а также современные подходы к решению сложных профессиональных задач.

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

Когда у вас появляется продукт с активными процессами и большим количеством пользователей, объём данных начинает расти быстрее, чем ожидалось. На старте всё выглядит достаточно просто: есть PostgreSQL, где хранятся основные сущности, есть Kafka с событиями, и кажется, что этого достаточно для решения большинства задач.

Но со временем появляются новые вопросы. Команде становится недостаточно просто посчитать количество записей или получить текущее состояние объекта. Хочется понять, что происходило в системе: какие события привели к изменению состояния, какие действия выполнялись, где возникла проблема и на каком этапе произошёл сбой.

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

В этой статье расскажу, как мы с командой построили отдельный аналитический контур: организовали миграцию данных из разных источников, объединили события Kafka и данные PostgreSQL, а затем вывели результат в удобные дашборды для технических специалистов и бизнеса.

Ошибки в спецификациях, бесконечные правки чертежей, ручной ввод данных из CAD в учетную систему – знакомые боли? АО «Профсталь» прошло этот путь и нашло решение. Компания не просто автоматизировала рутину – она создала дружелюбную цифровую экосистему, где проектирование в nanoCAD и управление затратами в 1С стали единым безошибочным процессом. Результат, который говорит сам за себя: время расчетов сократилось в 2-3 раза, объем обрабатываемых заявок вырос вдвое, а продажи по проектам конструкторов увеличились более чем в два раза.

Из этой статьи вы узнаете, как «Профсталь» шаг за шагом выстроила интеграцию компонента «СПДС» Платформы nanoCAD и 1C: ERP через Microsoft SQL Server. От проектирования цифровых двойников сэндвич-панелей до автоматической выгрузки спецификаций – мы покажем технологическую цепочку, которая исключает ошибки и экономит сотни часов рабочего времени.

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

Стратегия цифровизации: как инженерная экспертиза определяет задачи автоматизации...

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

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

О них сегодня мы и поговорим.

Проектирование систем противопожарной защиты за последние три года изменилось до неузнаваемости.Обновленные своды правил – СП 484.1311500.2020, СП 6.13130.2025, СП 3.13130 кардинально усложнили требования к зонированию объектов, расчетам резервированного электропитания и формированию огнестойких кабельных линий. Параллельно нарастает давление со стороны ТИМ: технология информационного моделирования становится обязательной для государственных объектов и все более востребованной в коммерческом секторе.

Все методологии управления проектами думают о процессе. Я попробовал поставить в центр человека — и получил первую версию продукта за 7 недель вместо пяти месяцев. Рассказываю, как.

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

С такими трудностями столкнулись специалисты ООО «Мечел-Инжиниринг» — организации, которая занимается проектированием объектов горной промышленности, выполняет проектно-изыскательские и конструкторско-технологические разработки, включая проекты технологических процессов и производств. Ведущий специалист группы информационных систем «Мечел-Инжиниринг» Рудольф Балашов рассказал об опыте компании по внедрению программных продуктов nanoCAD российского разработчика инженерного ПО «Нанософт».