UML Design *

Привет, чемпионы!

Часто ли вы обращаетесь к Midjourney или Stable Diffusion, чтобы нарисовать фантастический арт? Я да - нравится позалипать пару минут на фантастический арт. Давайте сегодня учиться генерировать подобные пикчи за пару кликов:

Что такое диаграмма последовательности? Из чего она состоит? Где и как пользоваться?

А еще тут есть интересные возможности, о которых ты мог не знать.

Привет, меня зовут Сергей, я ведущий разработчик в DDoS-Guard и человек из мемов xkcd, который любит всё экстраполировать, истовый фанат визуализации данных. Диаграммы и графики решают кучу моих проблем с онбордингом джунов и объяснением задачи исполнителям. 

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

Сценарии использования ИИ для учебы на поверхности. Тот же ChatGPT как стандарт по умолчанию студенты (да и преподаватели тоже) используют для написания текстов (рефераты, курсовые, дипломы и тому подобное), для анализа данных, изучения языков и, конечно же, для решения задач. Поговорим же здесь про то, как можно использовать ChatGPT для обучения программированию. Типично, студенты и школьники «скармливают» чату условие своей задачки, а на выходе получают код программы на требуемом языке. Часто чат дает еще и объяснения основных моментов в коде, рассказывает про алгоритм. Так можно учиться программированию, имея под боком «умного» консультанта. Не всегда, правда, код чата адекватен, а решения полные. Но, это очевидные вещи. Попробуем тут составить список примеров, которые могут быть полезны и тем, кто изучает программирование и тем кто учит. Начнем с простого.

Хабр, привет! В прошлых статьях про UML (Часть 1, Часть 2) мы узнали что такое язык моделирования UML и зачем он нужен, а также рассмотрели диаграмму классов и диаграмму компонентов. Сегодня я хочу продолжить тему проектирования процессов и остановиться на диаграмме объектов.

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

В предыдущих частях статьи (часть 1 и часть 2) мы прикоснулись к теоретическим основам этих процессов и впоследствии рассмотрели множество полезных подходов к использованию цвета при анализе и проектировании информационных систем.

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

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

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

В данной части мы углубимся в последний вопрос и разберём множество полезных приёмов на примере следующей группы популярных видов диаграмм.

Такие схемы на проектах готовят наши архитекторы. Достаточно ли их чтобы оценить состав и сложность каждого модуля, объем и трудоемкость работ в целом. Поможет ли такая схема при планировании работ?

В статье рассуждение о том что могло бы помочь.

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

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

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

Настоящая публикация ставит перед собой целью сделать шаг вперёд в этом направлении.

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

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

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

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

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

В данной статье я попытался заполнить этот пробел и предложить своё видение решения.

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

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

Обзорная статья о QPR Enterprise Architect. Основные возможности и преимущества данного инструмента.

Хочу поделиться с вами Key skils Systems Analyst которые нашла и сформировала для себя, чтобы в дальнейшем можно было легко оценить свой знания по всем пунктам.

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

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

Лично мне завесу тайны приоткрыл Альфа-Банк, здесь документация ведется рядом с кодом, и схемы логичнее описывать тоже кодом. Но это не так страшно и не так сложно (почти) как кажется. Давайте я приоткрою ящик Пандоры и сниму кармическое проклятье с  этого инструмента. 

Хабр, привет! Меня зовут Витя, я работаю системным аналитиком, сегодня хочу рассказать про такой обязательный навык аналитиков, как проектирование процессов. Думаю, что каждый, кто будет работать на позиции системного/бизнес аналитика, рано или поздно столкнется с такой задачей.

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

Я не буду расписывать аналоги, их преимущества, недостатки и т. д. Но просто расскажу, чем руководствовалась, когда собирала все эти принципы в один текст. Конечно, материалами исследований составили работы таких дизайнеров, как: Якоба Нильсен, Й. Мюллер-Брокманна, М. Ильяхова, И. Б. Бирмана, А. Лебедева, А. Горбунова, И. Иттена, А. Литриса, А. Мариока, Ш. Адамса, Пол Фитса, П Боаг, Д. Линдси и других очень уважаемых авторов. Далее, основываясь на существующих законах и принципах UI UX дизайна были проанализированы сайты популярных музеев мира таких как: MoMA, Metropolitan, Эрмитаж, Государственный исторический музей, и крупных площадок с большим количеством цифровых изображений: Google Arts & Culture, Pinterest, Shutterstock, Госкаталог, «Артхив»

В сети вы можете найти множество статей на тему «UML мертв», «Почему системным аналитикам не нужен UML» и множество подобного. Работая на протяжении последних 15 лет в совершенно разных компаниях, с совершенно разным жизненным циклом приложений и систем, с различной структурой и методологиями разработки я вижу одно и тоже — попытки ускорения time‑to‑market за счет отказа от процесса управления требованиями, подаваемые под разными прекрасными аргументами, приводят 100% компаний к необходимости переписывать приложения не потому, что оно не отвечает требованиям, а потому что «никто не знает как или почему оно так работает».

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

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

Здравствуйте! Меня зовут Дмитрий Моряков, и я ведущий системный аналитик в компании МаксимаТелеком. Теме миграции с монолита на микросервисную архитектуру (здесь и далее — МСА) за последние годы на страницах Хабра было посвящено немало материалов, поэтому я хотел бы сосредоточиться на узких аспектах этого процесса: выделении критической части при реализации пилотного проекта миграции на МСА и реализацию изоляции полученных микросервисов по данным.