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

Специалисты института «Уралгипротранс» рассказали об опыте использования программы nanoCAD BIM Электро на примере разработки разделов силового электрооборудования и электроосвещения при проектировании учебного корпуса и общежития политехнического техникума в городе Березники Пермского края. В статье отмечены особенности применения программного продукта, а также основные результаты его внедрения.

Уральский проектно-изыскательский институт транспортного строительства, основанный в 1936 году, специализируется на проектировании объектов транспортной инфраструктуры. Среди ключевых направлений – проектирование транспортных объектов промышленных предприятий, разработка проектов железных и автомобильных дорог, мостов, путепроводов, метрополитенов, тоннелей, жилых и общественных зданий, а также проведение инженерных изысканий и реализация природоохранных мероприятий.

За годы работы «Уралгипротранс» реализовал множество проектов как в России, так и за рубежом...

Хайп вокруг AI‑агентов продолжается. Компании активно внедряют агентов в продукты, внутренние процессы и даже повседневную рабочую рутину сотрудников. Но чем дальше мы уходим от игрушечных агентских сценариев к реальным продуктовым задачам, тем чаще возникает вопрос — как понять, что агент действительно работает хорошо?

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

Представьте себе высоконагруженный сервис, который решает, с какого из множества складов нужно отправить товар покупателю. В пике через него проходит около 600 000 RPS, а строгий SLA требует ответа в пределах 50 мс. Для расчёта нужно за минимальное время выбрать оптимальный склад с учётом остатков, доступности и других данных, которые хранятся в разных микросервисах и их базах данных.

Первое, что приходит на ум, — обратиться к этим сервисам по API во время запроса и получить всё необходимое для расчёта. Но один запрос может затрагивать сотни и даже тысячи складов, не считая связанных сущностей. Такое число сетевых вызовов быстро превысит SLA и приведёт к клиентским таймаутам. Сетевые запросы к мастер-системам в нашем случае — непозволительная роскошь, поэтому мы вынуждены держать слепок данных прямо в памяти подов. А значит, появляется новая проблема: как быстро и надёжно доставлять постоянно меняющиеся данные из мастер-систем в оперативную память сотен подов.

Недавно CrewAI представила экспериментальную возможность Conversational Flows как способ найти баланс между детерминированной логикой и рассуждением на основе ИИ в агентных системах. Это действительно важная архитектурная задача. Хочу поделиться тем, чему мы научились, создавая и эксплуатируя именно такие системы в промышленной среде — для корпоративных заказчиков из банковского сектора, телекома и других строго регулируемых отраслей.

Каждое лето сотни тысяч абитуриентов пытаются понять одну простую вещь:

Поступлю я или нет?

Казалось бы, все данные открыты. Вузы публикуют конкурсные списки, количество мест известно, правила приёма описаны на сайтах.

Но на практике ответить на этот вопрос гораздо сложнее, чем кажется.

Именно из этой проблемы вырос проект AbitList.

Сайт: https://abitlist.ru

Получил очередное приглашение на мероприятие по цифровизации промышленности. В программе всё знакомо: ERP, MES, PLM, 1С, производственный контур, импортозамещение, интеграции, производственные решения, новые продукты и очередная панельная дискуссия о том, куда движется российская промышленность. Сама по себе такая программа нормальна: предприятиям действительно нужны системы, интеграции и прикладные решения. Но чем больше я смотрю на этот привычный набор слов, тем сильнее возникает один простой вопрос: а что мы сегодня вообще называем цифровой трансформацией?

Внедрение ERP? Интеграцию ERP с MES? Замену импортной PLM? Подготовку регламентов? BI-панель? Электронный документооборот? Производственную аналитику? Новые рабочие места в системе? Всё это может быть полезно, а иногда и совершенно необходимо. Проблема начинается в тот момент, когда обычная автоматизация, внедрение или интеграция начинают называться цифровой трансформацией предприятия.

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

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

Привет, Хабр! Меня зовут Александр, я работаю в IT с 2006 года, последние годы занимаюсь системным анализом и управлением командами аналитики.

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

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

По условиям кейса организация Meridian, вымышленный крупный B2B-маркетплейс услуг для среднего бизнеса с клиентской базой более 4 млн компаний и оборотом 180 млрд рублей в год, столкнулась с падением выручки и ростом оттока клиентов, а руководству не хватало скорости принятия решений.

Команда победителей хакатона разработала AI-платформу для бизнес-аналитики, объединяющую возможности BI-систем и мультиагентного ИИ.

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

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

Статья будет полезна системным аналитикам и backend-разработчикам, которые проектируют интеграции с внешними API, используют OAuth 2.0 и хотят разобраться в практических сценариях — включая фоновые операции.

Работа проектного института охватывает полный цикл строительного проекта: от изысканий и BIM-моделирования до авторского надзора. Его специалисты уже несколько лет работают в программах комплекта nanoCAD Инженерный BIM (с апреля 2026 года – nanoCAD комплект Инженерия). Но для комплексного BIM-процесса недоставало ключевых звеньев: мощных инструментов архитектурно-строительного моделирования и единой среды для данных.

Было принято решение внедрить nanoCAD BIM Строительство (конфигурация «Архитектура») и CADLib Модель и Архив, чтобы научиться создавать 3D-модели архитектурной части, отработать процедуры информационного моделирования и выпустить собственные автоматизированные шаблоны. Полигоном для экспериментов стал реальный проект малоэтажного гражданского здания.

Привет, Хабр! Меня зовут Анатолий, я руковожу группой автоматизации и управления тестового оборудования в YADRO.

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

Хаотичная работа с тестовыми стендами — это проблема, и я пришел в компанию, чтобы ее решить. Так в YADRO появилась автоматизированная система бронирования тестовых стендов, она же Automated Testing Facility (ATF). В статье расскажу, что она умеет, на каких технологиях основана и почему под наши задачи не подошел Jenkins

Всем привет! В предыдущих двух статьях нашего цикла – шесть основ бизнес-анализа мы с вами разобрали первые два базовых понятия Бизнес-анализа – Заинтересованные стороны (Stakeholders) и Потребность (Need).  Мы выяснили, что аналитик начинает любой проект с определения «кто в игре» для создания рабочей группы проекта и первым делом «ставит диагноз», т.е. определяет истинную потребность заказчика. Но когда потребность сформулирована и решение найдено начинается самая недооценённая часть работы бизнес-аналитика. Потому что даже идеально спроектированное решение может провалиться, если не управлять тем, что происходит между «сейчас» и «потом» — то есть самим изменением.

По данным McKinsey & Company, около 70% инициатив по организационным изменениям не достигают поставленных целей. Причина почти всегда одна и та же: техническая часть выполнена, а человеческая — проигнорирована. Новая система работает, процесс описан, инструкции написаны. Но люди продолжают работать по-старому.

Чтобы не наступить на эти грабли, разберём третье базовое понятие BABOK — Изменение (Change).

Да не вопрос! На самом деле буквально три месяца назад у меня вообще не было никакого AGENTS.md. Он появился автоматом, когда я устанавливал code-review-graph.

История такая: я каждый день провожу стримы на Ютубе, где показываю процесс разработки своего проекта. И однажды в чатике мне посоветовали воспользоваться code-review-graph, чтобы сэкономить токенов в Codex. Я воспользовался советом, запустил установку через терминал — и в проекте автоматом появилась куча инструкций для разных агентов. Среди этих инструкций оказался и AGENTS.md.

Если вы, как и я поначалу, мало что понимаете в этих терминах и для чего они нужны, — сейчас объясню. А если вы полностью в теме — просто покажу кусочек своей «кухни».

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

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

Начнём с того, что по-настоящему «вайблю» я где-то с ноября 25 года. До этого моё общение с LLM строилось на копипасте в ChatGPT, DeepSeek, Gemini и обратно. Рука наловчилась, и я в целом не замечала, сколько времени это всё-таки сжирает. Казалось бы, лишнее действие.

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

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

А потом случилась революция. И моя компания решила не тормозить.

В проекте пользователям регулярно нужно скачивать наборы документов в виде архива. Изначально архивы формировались только из файлов внутри системы, но задача усложнилась, когда потребовалось добавлять внешние источники. В статье я разбираю решение на базе nginx mod_zip и потоковой генерации архива, позволяющее собирать ZIP «на лету» с минимальной нагрузкой на сервер. Также я подготовил простое демо, где можно всё попробовать самостоятельно.

Циклические испытания материалов – это задача, где важны не только механика установки, но и качество программного контура: нужно управлять нагружением, синхронно снимать данные с датчиков, сохранять результаты и видеть процесс в реальном времени.

В совместном проекте внедрения с Институтом физики твердого тела (ИФТТ) РАН мы проверяли, можно ли использовать Engee как основу для автоматизации установки циклических испытаний композитных материалов. Перед нами стояла прикладная задача: реализовать сбор данных с тензодатчика и датчика перемещения и управление сервоприводом.

Через несколько лет после сдачи проекта новая команда открывает модель. Формально всё на месте: проектная документация сохранена, каталоги и базы данных переданы, архив доступен. Но как только нужно продолжить работу — внести изменение, проверить выпуск или подключить нового подрядчика, — появляется главный вопрос: можно ли понять, почему данные устроены именно так?

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

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

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

Так же известно, что от версии к версии в модели добавляются скрытые детерминированные механизмы (модель думает), улучшающие адекватность ответов. Соответственно,  чем «умнее» становятся модели, тем больше в них добавляется человеческого фактора. Хорошо это или плохо? Для коммерческого продвижения точно хорошо. В любом случае человеческая предвзятость может накладывать свой отпечаток на ответы ИИ.

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