Системный аналитик как термин в США почти не используется. Если вы просто наберёте "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С в медицине), как настольная шпаргалка и некий базовый «стандарт унификации» формируемых диаграмм данного типа.
Полезно будет как тем, кто только делает первые шаги к стандартизации своего подхода при описании логики бизнес-процессов так и тем, кто уже имеет опыт применения данной нотации.
Многие пользователи диаграмм, создаваемых аналитиком зачастую не готовы читать схемы, содержащие большое кол-во элементов, виды которых нужно знать и понимать. Для описания бизнес-процессов из опыта в большинстве случаев достаточно элементов нотации, описанных здесь.
Эта статья посвящается всем тем, кто помышляет о профессии дизайнера в IT, а также уже действующим единицам в нашем деле. Остальным скорее на оценку с точки зрения своего опыта.
1. Не стройте иллюзий относительно IT курсов и рекламы
Без должного энтузиазма и желания развиваться в сфере UX/UI-дизайна, а также продуктового дизайна (далее по тексту – дизайн) курсы чаще не помогут вам достичь высоких результатов в форме высокооплачиваемых должностей на рынке дизайна. Рынок зарабатывает на том, что модно и всё ещё старается продать вам мечту о беззаботной работе с высокими зарплатами независимо от географии за относительно небольшую плату за курс. На мой взгляд это в большинстве случаев просто фарс и надувательство, эксплуатация модного явления и спекуляция разношёрстных подонков на этой основе. Вы сами должны достаточно сильно желать стать дизайнером, желать служить этому делу или какому-либо другому делу, чтобы начать путь без дополнительных стимулов и самообманов, мол вот сейчас куплю курс и это уже обяжет меня начать какой-то путь, ведь я потратил деньги, а значит должен начать проходить курс и стать дизайнером, ну или ещё какие-то подобные убеждающие себя предлоги.Если твоя цель служить профессии – шаблонные программы курсов часто не твой путь.
Если хочешь просто «влиться в тему» и работать на «галере» выполняя задачи механизмом системы, курсы – твой путь. Однако, есть случаи, когда и после курсов люди добивались высоких результатов в карьере. Всё неоднозначно и исключения есть всегда, однако общая практика и данность, на мой взгляд, такова.
От переводчика:
Я веду телеграмм‑канал, посвященный системному анализу, и провожу тренинги, и в какой‑то момент задался вопросом — а актуален ли сейчас UML? Если посмотреть обсуждения на SO, Reddit'e и в блогах — видно очень много постов в вопросом «Is UML Dead?». Я начал искать публикации на эту тему, и через некоторое время обнаружил этот пост, в котором были ссылки на статьи, которые я уже нашел, и ещё на некоторые, которых я до этого не видел. Мне показалось, это очень хороший сборник мнений, если вас тоже интересует судьба UML.
Вторая часть статьи — про принципы создания диаграмм последовательности — это буквально то, что я проговариваю участникам на каждом тренинге. Надеюсь, вам будет интересно и полезно.
В основе сборки любых компонентов лежит общий шаблон того, как они выполняют прокидывание зависимостей, это концепция, которую разработчики называют очень общим именем Inversion of Control (IoC: инверсия контроля). В этой статье я углублюсь в то, как работает этот паттерн под более конкретным названием «Dependency Injection» (Инъекция зависимостей), и сравню его с альтернативой - Service Locator
Привет! Меня зовут Настя, я старший системный аналитик в X5 Tech. Я рисую sequence-диаграммы каждый день на протяжении четырёх лет. За это время я прошла все круги ада по Данте, то есть попробовала разные инструменты для рисования этих самых диаграмм. Пока не встретила его – PlantUML.
Что удивительно, инструмент довольно не новый, но тем не менее лучше него я пока не встречала. А ещё удивительно, что он не особо популярный. Когда мы запустили в управлении системного анализа первый воркшоп по PlantUML, за 3 минуты после анонса пришли 12 заявок от аналитиков разных грейдов – от Junior до Lead.
В процессе подготовки материалов к воркшопу мы искали статьи и литературу, которые помогли бы дополнительно изучить sequence-диаграммы в PlantUML. Ничего интересного мы не нашли.
На самих воркшопах участники часто говорили о том, что они пытались самостоятельно изучить PlantUML, но их пугало то, что нужно писать какой-то код и учить какой-то синтаксис. Документация достаточно обширная, но информации о том, как последовательно строить sequence почти нет.
Поэтому и появилась эта статья.
