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

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

На современных проектах объектно-ориентированные подходы могут стать универсальным средством построения API, а файлы  YAML — понятной всем нотацией при интеграции. В новой статье рассмотрены оригинальные объектно-ориентированные подходы для проектирования архитектуры цифрового офиса сотрудника РСХБ.

Например, DDD может быть реализовано аналитиком через онтологическую разметку предметной области. При разработке приложения специалисты РСХБ-Интеха опирались на методику экспрессной визуализации объектов предметного поля через анализ чата в мессенджере с помощью методов математической лингвистики, также применяли адаптированную матрицу Эйзенхауэра для определения важности элементов интерфейса, методику определения границ микросервиса и концептуальную схему построения микросервисного конвейера.

О важности разметки предметного поля при анализе

Как сделать мобильное приложение для сотрудников банка? Не для клиентов, а для сотрудников. Клиенты у всех банков более-менее однородны, их интересует стандартный набор функция: оплата, кредиты, ипотека. А как быть с нуждами сотрудников? И что нужно в приложении сотрудникам именно нашего банка? Да и для чего вообще им нужно приложение?

Громкая новость прошлой недели: OpenAI запустили GPTs. Теперь каждый может опубликовать своего ассистента и поделиться с друзьями. Новый GPT Builder позволит сделать это за 3 минуты, но насколько ваш новый ИИ агент защищен от атак?

В этой статье мы сначала создадим себе ассистента, потом его сломаем. Подумаем, как и когда стоит защищать свой GPT. Далее, рабоче-крестьянским методом сделаем защиту от промпт-инъекций. Поехали!

Хабровчане, приветствую! Меня зовут Андрей Иванов, я системный аналитик в сфере медицины и здравоохранения. До 2005 года работал практикующим врачом, потом руководил медицинским информационно-аналитическим центром. Спустя время возникла настоятельная потребность получить базовое IT-образование и научиться тому, чем прежде приходилось руководить, — так я начал обучение на курсе «Системный аналитик». 

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

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

В данной статье содержится вольный перевод документации по Structurizr.

Из-за большого объема информация разделена на три статьи:

• общее описание языка;

• синтаксис;

• книга рецептов (эта статья).

В данной статье содержится вольный перевод документации по Structurizr.

Из-за большого объема информация разделена на три статьи:

• общее описание языка;

• синтаксис (эта статья);

• книга рецептов.

В данной статье содержится вольный перевод документации по Structurizr.

Из-за большого объема информация разделена на три статьи:

• общее описание языка (эта статья);

• синтаксис;

• книга рецептов.

Продолжаем публикацию лекций Олега Степановича Козлова с кафедры Ядерные Энергетические Установки МГТУ им. Баумана. Вторая часть лекции про качество САР и модель реактора как бонус.

В предыдущих сериях:

1. Введение в теорию автоматического управления.2. Математическое описание систем автоматического управления 2.1 — 2.3, 2.3 — 2.8, 2.9 — 2.13. 

3. Частотные характеристики звеньев и систем автоматического управления регулирования. 3.1. Амплитудно-фазовая частотная характеристика: годограф, АФЧХ, ЛАХ, ФЧХ. 3.2. Типовые звенья систем автоматического управления регулирования. Классификация типовых звеньев. Простейшие типовые звенья. 3.3. Апериодическое звено 1–го порядка инерционное звено. На примере входной камеры ядерного реактора. 3.4. Апериодическое звено 2-го порядка. 3.5. Колебательное звено. 3.6. Инерционно-дифференцирующее звено. 3.7. Форсирующее звено.  3.8. Инерционно-интегрирующее звено (интегрирующее звено с замедлением). 3.9. Изодромное звено (изодром). 3.10 Минимально-фазовые и не минимально-фазовые звенья. 3.11 Математическая модель кинетики нейтронов в «точечном» реакторе «нулевой» мощности. 

4. Структурные преобразования систем автоматического регулирования.

5. Передаточные функции и уравнения динамики замкнутых систем автоматического регулирования (САР).

6. Устойчивость систем автоматического регулирования. 6.1 Понятие об устойчивости САР. Теорема Ляпунова. 6.2 Необходимые условия устойчивости линейных и линеаризованных САР. 6.3 Алгебраический критерий устойчивости Гурвица. 6.4 Частотный критерий устойчивости Михайлова. 6.5 Критерий Найквиста.

7. Точность систем автоматического управления. Часть 1 и Часть 2

8. Качество переходного процесса ч.1

Формализация бизнес-процессов алгебраическими выражениями полвека будоражит умы математиков и методологов BPM (Business Process Management, ранее называемое CASE). Однако появление разнообразных алгебр процессов не добавили в практику BPM алгебраического формализма.

Алгебра алгоритмов (алгоритмическая алгебра Глушкова [GLU78], включая формализацию параллелизма), Алгебра \ исчисление процессов (CCS \ pi-calculus, CSP, ACP и др.), «Исчисление функций» (УФО, [UFO14]) не позволяют говорить о формальной (математической) теории BPM, а также инструменте, применимым бизнес-аналитиком на практике, т.е. об Алгебрах \ исчислениях бизнес-процессов - как математических абстракциях, формализующих workflow \ docflow и другие составляющие бизнес-процессов (Алгебре \ исчислении workflow).

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

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

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

Да при чем здесь вообще деривативы? А просто у деривативов, дженги и машинного обучения — много общего, давайте разбираться.

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

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

Привет, Хабр! На полях конференции Yandex.Talks взял интервью у Александра Поломодова, который за 7 лет вырос в Тинькофф до технического директора. Александр рассказал про технологический бум компании благодаря вовремя принятым решениям, возможностям роста, упомянул о важных качествах инженера.

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

Привет, Хабр! Меня зовут Ирина Ремизова, я куратор департамента системного анализа Sportmaster Lab, где, собственно, и курирую системных аналитиков, развивая их и рассказывая про инструменты принятия решений.

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

Начнём мы с ББМ. Это аббревиатура из трех слов, которая представляет собой три реакции человека при принятии решения. Боль (приобретение или потеря), боязнь сделать неправильное решение (верно или неверно) и муки (а что было бы, если…).

Почему бывает так трудно? 

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

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

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

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

Осложняет дело ещё и тот факт, что кроме вас это никому не нужно.

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

Погнали 🙂

Привет, Хабр! Меня зовут Дима. Я работаю в отделе разработки систем межведомственного взаимодействия РЕД СОФТ. Представляю вам вторую статью про импортозамещение в АИС ФССП России, в которой я расскажу о проектировании сложных территориально распределённых информационных систем.

В прошлом материале "Распределённые системы на службе ФССП России. Часть 1. МВВ" мы писали об общей архитектуре АИС ФССП России и подсистемах, которые она включает. В этой статье подробнее остановимся на важном проекте, которым мы занимались при работе над АИС — суперсервис «Цифровое исполнительное производство».

Для тех, кто впервые слышит про суперсервисы, поясним подробнее что это такое.

На рисунке приведена структурная схема современного, одного из самых навороченных (я подозреваю) 32-битного ARM процессора или микроконтроллера-microcontroller, в документации используются оба термина: high-performance Flash microcontroller (MCU) based on the 32-bit ARM Cortex-M7 RISC (х.хх CoreMark/MHz) processor.

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

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

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

Этот главный навык пригодится всем в индустрии — программистам, лидам, продуктологам, тестерам, менеджменту и всем остальным.

Имя ему этому навыку — здравый смысл.

Да, вот так просто, но на самом деле все совсем не просто, и я сейчас это объясню.

В процессе улучшения подходов к менеджменту зависимостей компонентов нашей Операционной Системы появилась необходимость перейти от монолитной статической сборочной системы на основе CI/CD инструментов к динамическому распределённому подходу с порождением сотен и тысяч автономных задач. Как выяснилось в процессе, это не самый радужный сценарий использования систем автоматизации, но вполне достижимый.

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

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

Ожидается много текста и примеров кода.