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

Введение

Представление моделей бизнес‑процессов на основе онтологий (онтологическое моделирование) эквивалентно Semantic BPM. Введение в семантический BPM (Business Process Management) см. «Semantic BPM. Семантика и синтаксис бизнес‑процессов» [semBPM24]. Если кратко, то можно провести аналогию: если классическая BPM система (BPMS: ARIS, бизнес‑студия, fox‑manager и т. п.) — это технологический аналог mediawiki (wikipedia), то Semantic BPM — это технологический аналог semantic mediaWiki (Wikidata), т. е.

IF MediaWiki → Semantic MediaWiki then BPM (ARIS, BPMS, EA) → Semantic BPM

Основной замысел (цель) семантического представления процессов (BPM, EA) не классическими BPM‑системами, а семантическими (Linked Data) — такой же, как и у семантических wiki

Одно из ключевых дополнений к wiki‑гиперссылки (html) это указание не просто что «ОбъектА связан с ОбъектомБ» (т. е. просто «связано») и соответствующий кликабельный переход (wiki‑ссылки, markdown syntax), а указание, что «ОбъектА связан с ОбъектомБ» такими‑то типом отношения (впрочем, как и задание других свойств объекта через отношения).

Изначально все BPMS (изначально называемые CASE‑средствами) — семантические, т.к. их суть — это отношения между объектами, только в них семантика глубоко спрятана «под капотом» BPMS и нестандартная (собственная, проприетарная). Semantic BPM «поднимает» семантическую составляющую на поверхность (возможность работы с семантическим слоем) и использует стандартные сематические технологии Linked Data.

В основе RDF (Resource Description Framework) — триплеты «субъект — отношение — объект» лежит ERD: Entity Relationship (ER) diagram. RDF \ ERD — это способ формализации знаний на основе атома знания — триплета. Вообще ER, subject, predicate, типы рассуждений и другие базовые элементы для работы со знаниями в СССР содержались в школьных учебниках [Логика54].  

Всем привет! Меня зовут Андрей Демьянов. Я тимлид и разработчик в МТС Travel. Совместно с другими командами мы создаем сервис по бронированию отелей в России и всему миру. Развиваемся с нуля, поэтому прямо на себе испытываем необходимость в новых библиотеках, подходах и изменениях, которые связаны с расширением и улучшением возможностей.

В этой статье я хотел бы рассказать о нашем опыте работы с библиотекой React Query (ныне TanStack Query, дальше RQ) и почему мы остановились именно на ней. А еще как она помогает нам упростить и ускорить доступ к страницам и данным, сэкономить ресурсы на однотипных запросах, упростить визуализацию работы с данными и распутать код. Глубоких технических подробностей не будет, но статья может быть интересна тем, кто хочет узнать об опыте применения RQ в условиях продуктовой разработки.

Привет, Хабр! По нашему опыту, при разработке интеграционного взаимодействия труднее всего даётся сопоставление различных форматов данных интегрируемых систем — «маппинг». Для этого нужно проанализировать много форматов, выявить корректные связи между элементами XSD- или JSON-схем и описать правила преобразования. Работа кропотливая, трудозатратная и не самая интересная. Раньше нам приходилось вручную сводить в таблицах поля, сидеть ночами. Думаю, все аналитики с этим сталкиваются и понимают, о чём я говорю.

Меня зовут Ярослав, я техлид в Т1 Иннотех. Наша команда занимается интеграцией всевозможных систем и разработкой ядра интеграционной платформы. За последние три года мы успешно заменили решение на стеке IBM MQ и IBM App Connect (бывший IBM Integration BUS) на open-source решение на основе ActiveMQ Artemis в качестве транспорта, с использованием Java и Kubernetes, и перенесли более 1500 различных способов взаимодействий на новую платформу. Хочу поделиться с вами нашим опытом по автоматизации этой работы и обсудить получившийся инструмент.

Один из наших длительных проектов — это крупное многопользовательское SaaS-решение (CRM-система) основанное на микросервисной архитектуре и развернутое в облаке Azure. Изначально это был MVP, где все части (сервисы, базы данных и т. д.) располагались на одной виртуальной машине. Со временем проект вырос в облачное распределенное решение с множеством веб- и мобильных клиентов. 

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

Выборы архитектора происходят всегда по‑разному. Это только политиков одинаково выбирают — по принципу лишь бы не этот… А вот с архитекторами везде свой сценарий. Где‑то в половине мест сидят эстеты и предлагают что‑то изобразить да обсудить. Четверть мест явно химики с мензурками в сейфе — спрашивают про правильный код или просят пузырьковую сортировку. Ещё реже циркачи просят пожонглировать стеклянными шариками на башне или погонять трамваи. Остальные просто хотят обсуждения с залом. Как бы намекая, что нельзя вот так просто прийти в училище имени Гнесиных с фамилией Иванов. Кто‑то из гильдии таки должен сказать, что в мальчике что‑то есть.

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

Влияет ли наше состояние на то как мы думаем и что говорим? Как через состояние и мышление повысить качество документации?

Миграция данных является одним из ключевых и самых сложных аспектов внедрения SAP: непродуманная стратегия может поставить под угрозу весь проект. Несмотря на то, что миграция данных является частью плана по внедрению (Cutover Plan), её важность очень часто недооценивают и весь процесс рассматривается как простая административная задача по переносу данных из одного места хранения в другое. Команда сосредотачивается на дизайне и демонстрации системы (Workshop), а также конфигурации, оставляя планирование миграции на потом. В результате на активности по миграции закладывается недостаточно времени и ресурсов, что может привести к срывам сроков при запуске. Грамотно спланированные миграционные активности помогут избежать «кранча» в период подготовки, а также снизят риски после запуска проекта. 

Если целью внедрения SAP ERP является замена старой (Legacy) системы, то миграция позволит перенести релевантные бизнес-данные из Legacy в соответствующие SAP-модули. Процесс миграции включает в себя следующие этапы [1]:

Привет! Меня зовут Дарина Кухтина, я руководитель аналитики в компании, которая разрабатывает мобильные игры, и наставник на курсе «Аналитик данных». В статье я расскажу, зачем бизнес нанимает аналитиков данных.

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

Меня зовут Ерохова Елена и я аналитик.

В моей практике перепроектирование встречалось почти так же часто, как проектирование с нуля.

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

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

Здесь я имею в виду, что «проект» - записанные в документ образ результата прикладного программирования и последовательность этапов по достижению этого результата.

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

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

Может быть, можно с самого начала так спроектировать приложение, чтобы потом не перепроектировать его?

В данной статье речь пойдет про видеограмметрию-создание 3d моделей объектов на основе видео. Видеограмметрия появилась давно, но до сих пор используется редко из-за необходимости в более мощном "железе", чем при построении 3d моделей местности/объектов с помощью лидаров. В 2024 году производительность ПК настолько выросла, что теперь можно в течении разумного времени строить модели на домашних компьютерах и даже ноутбуках. Сначала покажу, какие модели получились у меня, затем поделюсь лайфхаками, которые помогут сразу строить модели обходя технические сложности, а в конце расскажу чем видеограмметрия может быть полезна.

Денис Терехов, тимлид в Яндекс Еде, рассказал на митапе для разработчиков в Новосибирске о том, как его команда помогла курьерам быстрее доставлять заказы.

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

Всем привет. Меня зовут Татьяна Цикунова, я работаю системным аналитиком в компании МойСклад, в команде eCommerce. Моя команда специализируется на разработке интеграций сайтов с сервисом МойСклад. Мы помогаем бизнесу автоматизировать процессы: учета, продаж, коммуникаций с клиентами, выход на новые торговые площадки. Также мы разрабатываем интеграции с самыми популярными маркетплейсами на рынке России и зарубежных стран У МоегоСклада уже есть решения для селлеров на Ozon, Wildberries, Яндекс Маркете и Мегамаркете, а также для зарубежных маркетплейсов.

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

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

Представьте ситуацию. Приходит Product Owner и говорит: «Давайте сделаем новый дизайн страницы сайта». Аналитик берётся за задачу — проводит A/B-тест. Такая же задача случается в соседней команде, в сопоставимом по сложности продукте, — но если в первом случае тест занимал пару часов, то во втором ждать приходится несколько дней. Чем больше команд и аналитиков, тем выше риск разрозненности. 

Унификация процессов помогает минимизировать этот риск, только как к ней лучше подступиться? Подготовить чеклисты, шаблоны, документацию, скрипты..? В нашем случае понадобилось всё это, плюс самодельный инструмент, который автоматизирует статистический анализ результатов A/B-тестов

Под катом пошагово описываем, как мы унифицировали процессы в нашем A/B-тестировании, и что получили на выходе.

Привет! Меня зовут Ольга Матушевич, я наставница на курсе «Аналитик данных» в Яндекс Практикуме. С Jupyter Notebook я впервые столкнулась шесть лет назад, когда начала изучать Python и анализ данных. И именно установка Jupyter Notebook стала самым сложным этапом моей учёбы — ни чистка данных, ни градиентный бустинг, ни бутстрэп не доставляли мне столько трудностей.

Если установка программного обеспечения даётся вам так же трудно, то эта статья для вас. В ней я рассказываю о не требующем установки сервисе Google Colab, сравниваю его с Jupyter Notebook и даю советы для лёгкого старта.

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

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

В последнее время на производственных площадках нефтепереработки и нефтехимии все чаще стало звучать словосочетание «Виртуальный анализатор». Что же это такое? Давайте разберемся.

Виртуальный анализатор – это косвенное измерение параметров качества (концентрации/ содержания) компонентов в выпускаемой продукции, в основе которой математическая модель, рассчитанная на статистических исторических данных. Он позволяет в режиме реального времени видеть качество продукта на технологическом объекте. В качестве входных параметров модели используются датчики с приборов КИП технологических объектов: температуры, давления, расходы и т.д.

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

ВА = k1*X1 + k2*X2 + kn*Xn + bias,

Где ВА – значение виртуального анализатора, X1…Xn технологические параметры (температура, давление, расход и т.д.), k1…kn коэффициенты этих параметров, полученные при построении модели в специализированном ПО, bias – свободный коэффициент для корректировки показаний виртуального датчика. В конце статьи это формула станет гораздо понятней :)

А вы сталкиваетесь с постоянными изменениями требований со стороны заказчиков?

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

Авторская методика ЛЮСТРА помогает аналитику разработать бизнес-требования таким образом, чтобы минимизировать последующие изменения требований со стороны заказчиков в проекте по автоматизации бизнес-процессов. Ее цель — направить разговор со стейкхолдерами в сторону бизнеса, чтобы выявить легитимные и обоснованные потребности. Преимущество методики заключается в использовании мнемотехник, что делает ее легко запоминаемой и применимой в любом интервью с заказчиком.

Иногда я читаю статьи на Хабре. Ключевое слово здесь - иногда. Не регулярно. Бывает, с очень большими перерывами. Когда есть подходящее настроение. Или наоборот нет никакого настроения. По крайней мере, это для меня более интересное и менее пугающее занятие, чем вечерний просмотр телевизора. Но последнее время я стал ловить себя на мысли, что инструменты Хабра, с помощью которых я пытаюсь составить свой список внеклассного полезного чтения, требуют небольшой, но важной доработки. Есть идея, как находить действительно интересные, но давно забытые статьи. Мне хочется бы, чтобы у этих статей был шанс на вторую жизнь. После забвения.

История дизайн-мышления (design thinking) началась более полувека назад, когда Герберт Саймон озвучил идею дизайн-мышления в 1969 году в книге «Науки об искусственном» (The Sciences of the Artificial). В своей работе он привёл тезис об общности творческого подхода к различным видам деятельности, будь то написание музыкального произведения или, например, разработка техники [1].

В 70-80-х годах прошлого века этот подход проникает в менеджмент. В 1978 году Дэвид Келли создаёт вместе со своим университетским другом Дином Хови компанию Hovey-Kelley Design, которая в последствие станет ядром компании IDEO, сделавшей своей официальной доктриной дизайн-мышление [2]. Сотрудники IDEO учат своих клиентов думать, как дизайнеры, чтобы улучшить качество работы. В портфолио компании разработка Palm V, первой мыши для Apple, первый ноутбук [3, 4].

Позднее идею развили учёные Стэнфордского университета и основали в 2005 году Стэнфордский институт дизайна, или d.school, который продвигает идею дизайн-мышления [5]. Своей целью институт ставит построение методов, которые позволят развить навыки креативности, применимые к самым разнообразным областям. Для этого применяемся инструмент «радикального сотрудничества», когда студентов с разных факультетов, а также преподавателей и практиков из совершенно разных областей объединяют вместе [6]. Цель такого эксперимента обеспечить многообразие точек зрения на одну и ту же проблему и привить умение смотреть на один и тот же вопрос с разных сторон.

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

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

Когда спрашиваю у людей на собесах, или когда в команде решаем, как клепать очередной проект, такое порой слышу, что становится страшновато. Мне кажется, лет через 5 все компании будут обитать в мультивселенной безумия из “микросервисов”, которую они себе радостно построили, уходя от этих ваших страшных “монолитов”.

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