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

В статье «Пример описания многослойной архитектуры, основанной на использовании наборов подслоёв и иерархии моделей данных» рассмотрен подход к построению многослойной архитектуры приложения с использованием трёх слоёв и девяти подслоёв.

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

Анализируя типовой функционал приложения можно выделить 9 основных архитектурных блоков.

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

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

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

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

Как мы добываем железо из руды? Бурим горную породу и руду в карьере, закладываем взрывчатку и взрываем, чтобы экскаватор мог зачерпнуть породу. Огромные куски до 1,2 метра вывозим на БелАЗах на перегрузочные пункты, затем перегружаем в железнодорожные думпкары, потом дробим до состояния пыли, отсеиваем вскрышу и извлекаем железо. 

Работа у нас масштабная: экскаваторы высотой с четырёхэтажный дом, 240-тонные БелАЗы и много взрывов. При этом мы имеем одно из самых низких в отрасли содержаний (в процентном соотношении) железа в руде. Поэтому просто бурить, взрывать и возить недостаточно. Эффективность начинается с качества руды, которое мы отслеживаем буквально в каждом ковше экскаватора.

Меня зовут Вячеслав Загирный, я руководитель проектов в ЕВРАЗе. Мы стали первыми в России, кто создал IT-систему, позволяющую прослеживать качественные показатели руды от блочной геологической модели до дробильно-обогатительной фабрики. Проект называется «Геометаллургия». В этой статье расскажу, как всё устроено.

Приветствую читателей.
Мы пытались построить LLM-чат для продакшена.
Через месяц у нас был 20k-токенный prompt, 50 тулзов и ответы по 2 минуты.
В итоге пришлось отказаться от ReAct и перейти на LLMCompiler.

А начали мы с того что компания захотела поекспериментировать с созданием чата

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

Простейший пример чата.

Когда я решила стать аналитиком, я не знала про SQL вообще ничего, совсем, базовое образование у меня экономическое и в университете SQL нам никто не преподавал.

В этой статье приведу пример 5 задач, которые меня научили SQL по-настоящему, все они построены на том, с чем работает аналитик ассортимента: товары, категории, продажи и поставки.

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

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

Data Mesh, Data Fabric, Lakehouse: разбираем модные термины

Data Mesh, Fabric, Lakehouse – все говорят, но никто толком не объясняет, чем они отличаются и можно ли их использовать вместе. Разобралась и делюсь структурированно и без воды.

➕ Сравнительная таблица и чек-лист: что выбрать под свою боль.

✔️Сохраняйте, чтобы больше никогда не путаться.

Сегодня мы в Beeline Cloud решили поделиться свежими публикациями на нашей DIY-площадке «вАЙТИ». Это — подробные технологические материалы и относительно легкие разборы смежных тем: от лайфхаков по теме eCommerce-разметки и React Server Components до опыта разработки видеоаналитики на базе открытых решений.

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

🔹 Бесплатные курсы, которые дают реальную базу (и где искать правдивые отзывы)
🔹 Как подружиться с ИИ и заставить его работать вашим личным наставником
🔹 Честный тест-драйв: как понять, что аналитика – это ваше, до покупки курса
🔹 Когда идти на платное обучение и как выбрать курс, чтобы не выбросить деньги на ветер

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

Этот вопрос стал основой моей ВКР на тему «Разработка методики определения квалификационного уровня программиста на основе мультимодального анализа».

Вместо того чтобы гадать, я решила довериться данным. Я собрала датасет из 721 вакансии стека C#/.NET и 16 различных репозиториев, прогнала их через LLM (Saiga Llama 3) и нейросеть GraphCodeBERT, чтобы найти объективные метрики «сеньорности».

По моей задумке (и уже работающему прототипу), методика позволит оценивать грейд не по лайв-кодингу, а по «цифровому следу» программиста — его репозиторию. Цель этой статьи — показать «внутреннюю кухню» исследования, поделиться первыми инсайтами о том, как нейросети видят наш код, и получить вашу обратную связь, чтобы подготовиться к главному вопросу на защите: «А зачем всё это надо?».

«Зачем мне эта ваша математика?» честный разбор для тех, кто хочет расти в аналитике

Если вы работаете в аналитике и ни разу не задавались вопросом «а зачем мне эти интегралы и производные» – вы либо гений, либо врете.
В интернете много статей про матан для аналитиков, но они либо уходят в дебри интегрирования по частям, либо ограничиваются уровнем «логарифм делает большие числа маленькими». Где золотая середина?

Что внутри:
Логарифмы: не просто log1p, а эластичность и среднее геометрическое
Производные: как поймать момент перед падением (вторая производная)
Пределы: почему retention не упадет ниже 15% (и при чем тут асимптоты)
Интегралы: LTV с дисконтированием и площадь под uplift-кривой

Для кого: аналитики, которые уже вышли из Excel и хотят понимать, что на самом деле делают их .diff() и .cumsum().

Команда «Нанософт» создала информационную модель исторического здания торговых рядов на Красногорской площади в Сергиевом Посаде Московской области. Здание, построенное в 1902–1903 годах по проекту А. А. Латкова в русском стиле, в 1920 году пережило пожар, а в 2014-м было полностью отреставрировано к 700-летию Сергия Радонежского.

На примере этой модели мы показываем, как создавать и настраивать пользовательские проемы в nanoCAD BIM Строительство – от базовых до более сложных методов.

Кому это будет полезно?

Архитекторам, конструкторам, руководителям проектов, студентам и всем, кто работает с nanoCAD BIM Строительство или изучает его, – для быстрого освоения программного продукта и решения реальных практических задач.

— Нам нужен дизайн-док. — Какой именно? — Ну...ГДД.

Пожалуй, это одна из самых частых ситуаций, с которыми я столкнулся, начав искать работу в студиях.

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

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

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

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

Итак, попробуем разобраться.

Привет, Хабр! Меня зовут Руслан Каллагов, я системный аналитик в Лаборатории Globus — партнёре Нетологии по стажировкам на курсах ИТ-профессий. Уже 4,5 года я работаю в проектировании программного обеспечения и верю в силу синергии человеческой экспертизы и ИИ. В этой статье расскажу, как именно меняется рабочий процесс, инструментарий и зона ответственности системного аналитика под влиянием технологий вроде ChatGPT. 

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

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

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

Практики FinOps в Telegram| Бот

Почему начинать с оптимизации — плохая идея

Первая мысль, которая появляется, когда счет за облако в очередной раз оказывается процентов на 40 выше запланированного, — взять и что-нибудь урезать. Неважно что. Лишь бы сократить расходы. Ну, оно вроде и логично. Режем лишнее – оставляем нужное – сокращаем траты.

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

Мы подошли к финальной стадии производства Информационной системы (ИС).

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

Как и для предыдущих стадий, определим вызовы и цели, с которыми мы подошли к этапу:

Среди всего многообразия электрических машин переменного тока синхронный реактивный электродвигатель (СРД, от английского Synchronous Reluctance Motor, SynRM) занимает особое место. С одной стороны, принцип его работы был известен ещё в XIX веке и казался инженерам того времени малоперспективным. С другой — именно этот тип машин за последние два десятилетия переживает настоящий ренессанс и активно вытесняет асинхронные двигатели в задачах промышленного привода.

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

Ключом к реализации потенциала SynRM стали два взаимосвязанных достижения: развитие силовой электроники, позволившей строить высококачественные частотные преобразователи, и разработка алгоритмов управления с оптимизацией по критерию максимального момента на ампер (MTPA — Maximum Torque Per Ampere). Без этих инструментов SynRM остаётся малоэффективным. Вместе с ними — становится конкурентоспособным решением для широкого круга промышленных задач.

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

В мире разработки программного обеспечения существует понятие, которое окружено множеством мифов, страхов и недопонимания. 

Это технический долг. 

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