Всем привет! Продолжаем делиться тем как мы разрабатываем наш инструмент моделирования. К предыдущей статье было много вопросов о том можно ли модели хранить и редактировать в текстовом виде, как насчёт architecture as code, code first и т. д. Мне хотелось бы написать, что мы добавили эту фичу в текущем релизе, но нет, пока есть только такая демка с исходниками. И в этой статье я расскажу как она сделана, как запилить свой предметно‑ориентированный язык (DSL) и текстовый редактор для него.
Сегодня я хочу поделиться глубоким исследованием того, как применять золотое сечение в современном дизайне 2025 года. Эта статья основана не только на теории, но и на реальном опыте работы с крупными проектами, A/B тестах и исследованиях пользователей.
Привет Хабр! Меня зовут Татьяна Ошуркова, я системный аналитик и разработчик. Несмотря на то, что UML-диаграммы являются популярным и востребованным инструментом, не все системные аналитики используют его в своей работе. Одной из причин может быть непонимание пользы для требований и проработки задачи.
Скажу честно, что такое было и со мной, когда опыта у меня было немного. Сложностей в работе хватало и без дополнительных инструментов, которые требовали время на погружение. В этой статье я на практическом примере покажу, как проработать процесс с помощью моделирования на UML. Подробно посмотрим, как сделать это быстро, понятно, а также выделим основные преимущества решения.
Привет Хабр! Меня зовут Татьяна Ошуркова, я системный аналитик и разработчик. Наверное многие хотя бы раз сталкивались с диаграммой, которая сделала процесс более понятным. И с диаграммой, после которой пришлось перечитывать описание процесса еще не раз. Грамотная модель делает требования более качественными, а некорректно построенная модель может привести к непониманию хорошо проработанной документации.
В этой статье я разберу пять распространённых ошибок в построении диаграмм системным аналитиком на практических примерах.
Системный аналитик как термин в США почти не используется. Если вы просто наберёте "System Analyst", то в 9 из 10 случаев увидите совсем не то. Либо вакансии из финансового сектора, либо вообще нечто около-административное.
Так кто же тогда делает ту работу, которую в России выполняет системный аналитик?
Когда проект разрастается до десятков экранов, а папка helpers начинает весить больше, чем хотелось бы, приходит время пересмотреть подход к архитектуре. В этой статье — как я пришёл к принятию Feature-Sliced Design на React. Только личный опыт, ошибки и выводы.
Это первая статья в блоге нашего стартапа, надеюсь, что не последняя. Мы разрабатываем инструмент моделирования и будем делиться нашим видением идеального продукта, рассказывать про наши успехи и неудачи, надеюсь, что будем получать критику и в итоге у нас получится что‑то полезное.
Здравствуйте! Меня зовут Щедрин Николай, и я являюсь ведущим аналитиком продукта GigaCode от Сбер. Хочу поделиться с вами сценариями применения ИИ-ассистента в работе системного аналитика, которые использую сам. Надеюсь, статья позволит вам посмотреть на привычные вещи под другим углом и побудит поделиться своими мыслями, идеями и предложениями о применении ИИ-ассистентов в вашей профессиональной деятельности.
Если вы системный аналитик, эта статья — ваш must read. Остальным коллегам (разработчикам, архитекторам, владельцам продукта) будет полезно узнать, как ИИ-инструменты выходят за рамки генерации кода и помогают проектировать системы.
А ещё здесь есть мемы от Kandinsky — куда же без них?
Я работаю архитектором ПО, причём достаточно ленивым архитектором. Одна из моих задач — это проектирование модели данных для приложений. Ладно бы всё этим и ограничивалось, но нужна ещё и документация по модели для аналитиков и заказчиков, нужны SQL скрипты и Java‑код, реализующие эту модель данных, нужно постоянно актуализировать модель, если разработка ушла дальше, актуализировать документы, которые вечно устаревают.
Мы не ищем лёгких путей, поэтому запилили небольшой «инструмент моделирования», который упрощает всю эту работу. В этой статье я опишу как мы это сделали. Сразу предупреждаю, что инструмент наколеночный и я даже поленился упаковать его в нормальный продукт, который можно скачать и запустить. Плюс у нас активно используется Eclipse, но статья не про него, а про сам подход, можно использовать и другие инструменты.
Привет!
Меня зовут Алексей Фоменко. Я разработчик из Нижнего Новгорода.
Сегодня хочу рассказать вам о своем сервисе «Клюква».
«Развесистая клюква» или просто «Клюква» в общем виде означает ложные или искаженные представления о чем‑либо.
Как раз здесь мы приходим к написанию документации. К сожалению, составить и поддерживать документацию в актуальном состоянии — это проблема. Скорее всего проблема в том числе и в вашей компании.
Это компиляция основных знаний по проектированию архитектуры ПО, которые мне удалось собрать. Конспект доступен по ссылке на Miro-доску.
Можно сказать, что это взгляд на System Design с точки зрения фронтенд-разработчика, который пытается разобраться в теме.
Каждый, кто пользовался PlantUML, знает, что этот инструмент хорош тем, что позволяет создавать разнообразные диаграммы без необходимости ручного позиционирования их элементов: написал код — получил рендеринг. Но, как известно, у медали две стороны. В данном случае вторая сторона медали это не всегда понятные правила, которыми руководствуется логика, лежащая в основе движка PlantUML.
Как следствие, иногда получаются не самые эстетически привлекательные диаграммы, а поиск ответа на вопрос, как повлиять на автоматическую расстановку элементов, заводит в тупик. Это происходит из-за того, что доступной информации об управлении вёрсткой в PlantUML практически нет.
В данной статье я попытаюсь закрыть этот пробел и заодно поделюсь некоторыми полезными приёмами, чтобы снизить порог вхождения в работу с PlantUML.
Привет! С вами снова Даниил Нейман из отдела развития инициатив ИБ-сообществ. Это продолжение цикла статей о проблеме, с которой сталкивается специалист при анализе кибератак, — о сложности анализа без использования стандартизированных методов моделирования, используемых для разбиения и визуального представления этапов кибератаки.
Ранее были рассмотрены методы моделирования атак на основе сценариев использования и темпоральные методы моделирования. А завершим цикл статей мы рассмотрением методов, основанных на графах. Отличительная черта этих методов — использование графов, где сущностями являются вершины графа, а связями между ними — ребра.
Даже долго работая в одной команде, люди смотрят на вещи по-разному – у них отличается бэкграунд, взгляды на технологии и подходы к работе., т.е. всегда есть проблема синхронизации. И для ее решения необходим общий способ коммуникаций, который исключает недопонимания. Без него даже аналитики не всегда могут договориться между собой, что уж тут говорить про передачу информации в другие сферы проекта. Можно писать огромные талмуды текстом, но на практике гораздо удобнее обмениваться диаграммами.
В сентябре 2024 года с российского рынка ушли такие сервисы, как Miro и Notion, а перед этим российский рынок покинула Atlassian с продуктами Confluence и Jira. Меня зовут Павел Мокеев, я работаю системным аналитиком в компании МойСклад и я предлагаю поговорить о том, как базы знаний подверглись риску потери и что сделать, чтобы это не повторилось.
Всем привет! На связи снова Даниил Нейман из отдела развития инициатив сообществ по ИБ в Positive Technologies. В прошлой статье я рассказывал про одну из основных проблем, с которой сталкивается специалист при анализе кибератак, а именно про сложность анализа без использования стандартизированных методов моделирования атак для разбиения и визуального представления различных этапов кибератаки.
Нами были рассмотрены методы моделирования атак на основе юзкейсов, теперь поговорим про темпоральные методы моделирования (акцент на хронологическом порядке и последовательности событий в кибератаке).
Отличительной чертой этих методов является представление кибератаки с временной точки зрения. Они позволяют моделировать и анализировать развитие атаки во времени, учитывая динамику изменений состояния системы или сети, а также временные зависимости между действиями атакующего.
Привет, друзья!
Сегодня я хочу поделиться с вами важной новостью: проект HyperCube Dream подходит к концу своей активной разработки, и я рад представить последнее обновление этого увлекательного инструмента для создания и анимации 3D фигур в браузере. Однако есть и хорошая новость — проект будет доступен в открытом исходном коде! Это значит, что каждый сможет использовать, модифицировать и развивать его, как пожелает.
В этой статье я расскажу, что нового в финальном обновлении, как можно использовать HyperCube Dream и как вы можете внести свой вклад в его дальнейшее развитие.
Привет! Меня зовут Даниил Нейман, я работаю в Positive Technologies в направлении развития инициатив ИБ-сообществ, где я активно занимаюсь поддержкой и развитием open-source-проектов и сообществ. Одна из наших целей — продвижение обмена знаниями между специалистами в области информационной безопасности.
В наше время, когда постоянно появляются новые и все более сложные кибератаки, специалистам трудно провести быстрый анализ и выявить сложные закономерности действий киберпреступников, которые приводят к успешной кибератаке. Хорошо продуманные системы, описывающие все возможные действия злоумышленника, называются методами моделирования атак и могут решить эту проблему.
Методы моделирования атак (attack modelling techniques), или AMT, используются для моделирования и визуализации последовательности событий, приводящих к успешной кибератаке на системы. Их можно разделить на три категории: 1. методы, основанные на диаграммах сценариев использования, 2. темпоральные методы (акцент на хронологическом порядке и последовательности событий в кибератаке) и 3. методы, основанные на графах.
В этой статье расскажу про первую категорию методов — на основе сценариев использования (use case methods).
Я написал этот гайд для использования аналитиками в компании (мы интегратор решений 1С в медицине), как настольная шпаргалка и некий базовый «стандарт унификации» формируемых диаграмм данного типа.
Полезно будет как тем, кто только делает первые шаги к стандартизации своего подхода при описании логики бизнес-процессов так и тем, кто уже имеет опыт применения данной нотации.
Многие пользователи диаграмм, создаваемых аналитиком зачастую не готовы читать схемы, содержащие большое кол-во элементов, виды которых нужно знать и понимать. Для описания бизнес-процессов из опыта в большинстве случаев достаточно элементов нотации, описанных здесь.
От переводчика:
Я веду телеграмм‑канал, посвященный системному анализу, и провожу тренинги, и в какой‑то момент задался вопросом — а актуален ли сейчас UML? Если посмотреть обсуждения на SO, Reddit'e и в блогах — видно очень много постов в вопросом «Is UML Dead?». Я начал искать публикации на эту тему, и через некоторое время обнаружил этот пост, в котором были ссылки на статьи, которые я уже нашел, и ещё на некоторые, которых я до этого не видел. Мне показалось, это очень хороший сборник мнений, если вас тоже интересует судьба UML.
Вторая часть статьи — про принципы создания диаграмм последовательности — это буквально то, что я проговариваю участникам на каждом тренинге. Надеюсь, вам будет интересно и полезно.
