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

Ещё один небольшой pet-проект: про кафе и коворкинги на солнечном Кипре. "Рабочие места" для цифровых кочевников ヽ(。_°)ノ

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

В настоящее время организации в среднем управляют в 10 раз большим количеством данных, чем пять лет назад: с 1,45 петабайт в 2016 году до 14,6 петабайт в 2021 году. Таков главный вывод Глобального индекса защиты данных 2021 года компании Dell, где освещаются проблемы, с которыми сталкиваются предприятия в связи с угрозой вымогательства и сложностями, связанными с ростом объема информации.

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

Исследование Dell показало, что большинство руководителей компаний сомневаются относительно своих разработок по защите данных, причем 82% респондентов выразили обеспокоенность тем, что существующие в их организации решения не смогут обеспечить выполнение будущих бизнес-задач. Даже компании, предпринимающие определенные усилия для преодоления возникающих препятствий, говорят, что ожидают серьезных трудностей. По данным Dell, 58% компаний, инвестирующих — или планирующих вложить — средства в приложения «программное обеспечение как услуга», испытывают затруднения с поиском средств защиты данных для них.

RTOS или не RTOS вот в чем вопрос 2, или Windows тоже RTOS?

В определении данным «отцом основателем» всея пользовательского опыта, Доном Норманом, определяющим словом является — «All». В переводе на русский язык — «ВСЕ».  

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

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

Мы как дизайнеры часто отступаем немного назад и смотрим на свою работу со стороны —  на мой взгляд, это важная часть процесса проектирования. Обычно мы задаем себе подобные вопросы:
— Всё ли это понятно?
— Можно ли сделать ещё лучше?
— А не фигню ли я делаю?

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

Многие задачи, встающие перед аналитиками в компаниях, в конечном итоге сводятся к вопросам: а что если случится это? что будет, если мы введём эту фичу? что будет, если мы примем такую стратегию действий? что будет, если мы ничего не будем делать?

Вы уже наверняка знаете, что лучший способ получить точные ответы на такие вопросы — это эксперименты. Наверное, вы также слышали, что «корреляция — это не каузация»  и слепо доверять неэкспериментальным данным не стоит. Но почему это так? И так ли безнадёжны неэкспериментальные исследования? Можно ли приблизить их по точности к экспериментам, и если да, то как?

Всё это попадает в область причинно-следственного вывода (Causal Inference). Она основана на многолетних трудах как в области «классической» статистики, так и в сфере машинного обучения — и даже для краткого введения в проблематику зачастую требуются многостраничные книги. Здесь мы попробуем рассказать о небольшом формальном инструменте, крайне популярном среди неэкспериментальных исследователей. Называется этот инструмент очень коротко — DAG.

Привет, Хабр!

Анализ исходного кода - давно зарекомендовавшая себя практика для выявления отклонений до выхода приложения на рынок. Проверка на уязвимости, program understanding, поиск логических ошибок в использовании библиотек, code review и многие другие методы статического, динамического и ручного анализа кода широко применяются во многих компаниях занимающихся разработкой программ. 

Меня зовут Андрей Насонов, я работаю UI/UX-дизайнером и руковожу дизайн-отделом. В 2008 году я начал заниматься графическим дизайном, а в 2015 году перешел в веб-дизайн.
В этой статье я описываю работу модального окна для десктоп-версии сайтов.

"Что делать, когда ТОПовые BI-системы стали недоступны и перспективы работы с ними оказались сильно ограничены?". Эта дилемма встает сегодня перед многими компаниями. Меня часто спрашивают, можем ли мы взять и перенести уже наработанные практики на другие платформы, доступные в России на сегодняшний день? К счастью, ответ на этот вопрос положительный, и об одном из вариантов его решения я расскажу сегодня.

Привет! В этом посте мы обсудим Real-time optimization и его влияние на бизнес, само собой, по большей части поговорим про нефтехимию. Но RTO способно повысить эффективность бизнеса и в других сферах, главное — правильно применять этот подход.

Что это вообще такое — RTO?

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

Привет! Меня зовут Виктория Кабыткина, я работаю старшим системным аналитиком в компании Lamoda. По своему опыту как в банковской сфере, так и в сфере e-commerce, могу заметить, что во многих компаниях существует тенденция избавляться от монолита и переходить на микросервисную архитектуру. 

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

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

Решил составить для себя план развития (я в IT с 2007, как аналитик - с 2017). Что получилось: некий чек-лист с перечислением 13 блоков (от работы с требованиям до безопасности) с описанием, что обязательно и желательно знать/уметь.

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

Вопрос обязательности умения/знания/понимания программирования для ИТ-аналитика-проектировщика вызвал жаркие дебаты в профильных группах. Приводились два вида аргументов:

Многим на Хабре уже известны наши конференции вроде Joker, HolyJS или Heisenbug. Теперь к ним добавляется ещё одна, на смежную тему: мы увидели, что есть спрос и на «аналитическое» мероприятие. Поэтому 29-30 ноября проведём новую конференцию Flow, программа и билеты доступны на сайте.

А в этом тексте мы расскажем главное про конференцию. На кого мы ориентировались, когда выбирали доклады? А для кого, наоборот, подходящих докладов там не найдётся? Это оказалось не самым очевидным вопросом.

А для дочитавших до конца — ещё и небольшой бесплатный бонус к конференции.

SAP-практика в СИГМЕ — одна из крупнейших в стране. Однако уход SAP из России повлек за собой существенные изменения на рынке ERP-решений, которые затронули и нашу компанию. Так как преобразования сейчас в самом разгаре, давайте вместе разберемся, что будет происходить на этом рынке в ближайшие годы, какие специалисты будут востребованы, а также — чем может похвастаться российский рынок ERP сейчас и в будущем.

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

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

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