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

Условия задачи

Сценарий:  

У нас есть e-commerce платформа, состоящая из:

• веб-приложения,

• брокера сообщений,

• бэкенда.

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

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

Проблема:  

Клиенты могут:

• добавлять несколько товаров в корзину одновременно,

• отправлять несколько заказов.

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

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

Необходимо:

• Выявить процессы, которые происходят,  

• На основе этих процессов отобразить схему (sequence diagram) взаимодействия,  

• Предложить 2 способа оптимизации, чтобы избавиться от текущих проблем. 

Переходим к решению ⬇️

Стоимость минуты простоя в iGaming может приносить миллионы упущенной прибыли и более тяжелые репутационные потери. Когда real‑time ставки замирают, а букмекерские терминалы уходят в ступор - это не просто баг. Это экзамен на зрелость команды и процессов. Что мы делаем после - определяет, повторится ли он снова.

Привет! В департаменте корпоративных систем ЛАНИТ, где я работаю аналитиком, одно из направлений — разработка ИТ-решений и бизнес-приложений на базе систем визуального программирования. Последние два года мы реализовывали проекты с использованием low-code платформы BPMSoft. Хочу поделиться нашим опытом в этой статье.

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

Всем привет! Я Алексей Толбин, главный системный аналитик в ПСБ, эту статью я написал вместе со своими коллегами — Никитой Резаевым, ведущим системным аналитиком, и Оксаной Резван, управляющим экспертом. 

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

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

Доброго времени суток, дорогие гости Хабра!

Меня зовут Роман Мосоло́в, последние 8 лет занимаюсь веб-разработкой. Окончил магистратуру Казанского (Приволжского) федерального университета, факультет программной инженерии. Проектно разрабатывал сервисы для Росатома, Пятерочки, Перекрестка, одной международной CRM и ряда других организаций. В этих проектах выступал как исполнитель, так и был опыт подбора кадров.

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

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

Все говорили о микросервисах. Гибкость. Масштабируемость. Независимые команды. Звучало как мечта. Многие компании бросились распиливать свои монолиты. Разработка действительно ускорилась. Отдельные компоненты стало проще обновлять и разворачивать.

А потом сервисам понадобилось общаться. И мечта превратилась в сложную, многомерную головоломку.

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

Мы рассмотрим подробнее эту методологию и особенности её применения. А также на нескольких примерах из практики М.Видео-Эльдорадо и Т1 покажем, чем процессная аналитика может быть полезна в компании.

Процессная аналитика (Process Mining) — это методология сбора и анализа информации о бизнес‑процессах. Она помогает составить реальную схему процессов, разобраться в их работе и найти узкие места, требующие вашего внимания. Также процессная аналитика помогает выявлять «нетипичные» пути прохождения и прогнозировать работу бизнес‑процессов.

Мы рассмотрим подробнее эту методологию и особенности её применения. А также на нескольких примерах из практики М.Видео‑Эльдорадо и Т1 покажем, чем процессная аналитика может быть полезна в компании.

Предлагается к рассмотрению метод динамического определения форматов хранения и типов индексации в таблицах аналитической базы данных Dimension DB. На основе метаданных из источников данных (SQL-запросов, таблиц или представлений) определяется формат хранения или представления данных, а по текущему распределению данных, автоматически определяется тип индексирования.

Привет, Хабр! 

Я — Мила Муромцева, системный аналитик в Альфа-Банке. Пишу эту статью, чтобы поделиться нашим опытом, а с кодом и тех. частью мне помогает наш разработчик Миша Буторин. Расскажем, как мы научили LLM проверять документацию для платформы Альфа-Онлайн: переписали стандарт, поборолись с токенами и немного с хаосом.

Всем привет. Меня зовут Александр Виноградов, я главный архитектор Ви.Tech – ИТ-дочки ВсеИнструменты.ру. Последние 9 лет занимаюсь ИТ-архитектурой и менеджментом в архитектуре, и сегодня бы хотел поделиться с вами своим топом заблуждений про эту самую архитектуру из серии: «если бы мне каждый раз давали рубль, когда я слышу...». 

Кому будет полезна эта статья:

— Тимлидам и РП, которые смогут чуть лучше понять, почему архитектор так долго возится со своими картинками.
— Продактам, которых пугают словами «ну здесь нам нужен корпоративный архитектор».
— Разработчикам, которые считают, что архитекторы занимаются исключительно рисованием квадратиков и стрелочек.
— Самим архитекторам, чтобы почерпнуть дополнительные аргументы для дискуссий с коллегами.

Вы узнаете, что:

— Не существует «правильных» технологий (и postgres не лучше mysql).
— Архитектор не должен писать код (и почему).
— Что покупка коробочных решений не избавляет от проблем.

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

Все это уже умеют LLM. Например, трансформенные модели GPT, Claude или Gemini могут принять на вход изображения, распознать и описать на них объекты — это позволяет использовать их для восприятия окружающей среды.

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

Меня зовут Артем Лыков, я ведущий RnD-разработчик в МТС Web Services. В Лаборатории интеллектуальной космической робототехники Сколтеха мы реализовали CognitiveOS — когнитивную операционную систему для роботов. В этом материале я познакомлю вас с ней и расскажу, какие проблемы она решает, как устроена и как позволяет справляться с реальными задачами.

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

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

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

Привет! Меня зовут Катя, я заместитель руководителя направления системного анализа в Контуре, а еще программный директор Конференции аналитиков.

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

В статье расскажем, как мы готовились (готовимся до сих пор!) и что вас ждёт!

В общем, решил сделать пет-проект. ЦРМ нормального фрилансера. Сам я ремесленник-одиночка и пользуюсь ограниченным набором инструментов для ведения дел: Google Таблицы, да Windows-заметки. Решил все эти данные свести воедино в рамках собственной црмки.

Я не разработчик, а проектировщик интерфейсов (UX/UI-дизайнер). Опыта в программировании совсем немного. Поэтому пет-проект был мне особенно интересен. Я уже двадцать лет готовлю проектную документацию для других — а в этот раз для себя.

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

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

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

Процедура передачи может регулироваться, например, управленческими правилами делегирования, а именно:

Краткий гайд по наведению порядка HTTP status code и тому, как действовать если реальность становится по-настоящему пугающей.

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

Он запускает несколько методов… и дальше начинает происходить что-то сверхъестественное:

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

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

Обо всем этом и поговорим.

Давайте разбираться!