Пользователь
Когда клиент приходит с задачей, можно скинуть ему табличку с брифом и попросить заполнить. Это самый простой путь для разработчиков, но мы так не делаем. Кажется, что это означало бы перекладывать на клиента часть наших задач. В статье расскажем, как общаемся с заказчиками, вникаем в их потребности, составляем для них ТЗ и считаем смету.
История об испытаниях, которые ждут аналитика в стартапе. Расскажу о том, как выстроить процесс, когда разработка и аналитика стартуют вместе, как поддерживать частые изменения и как мы выкручивались без тестовых площадок.
Привет, Хабр! По нашему опыту, при разработке интеграционного взаимодействия труднее всего даётся сопоставление различных форматов данных интегрируемых систем — «маппинг». Для этого нужно проанализировать много форматов, выявить корректные связи между элементами XSD- или JSON-схем и описать правила преобразования. Работа кропотливая, трудозатратная и не самая интересная. Раньше нам приходилось вручную сводить в таблицах поля, сидеть ночами. Думаю, все аналитики с этим сталкиваются и понимают, о чём я говорю.
Меня зовут Ярослав, я техлид в Т1 Иннотех. Наша команда занимается интеграцией всевозможных систем и разработкой ядра интеграционной платформы. За последние три года мы успешно заменили решение на стеке IBM MQ и IBM App Connect (бывший IBM Integration BUS) на open-source решение на основе ActiveMQ Artemis в качестве транспорта, с использованием Java и Kubernetes, и перенесли более 1500 различных способов взаимодействий на новую платформу. Хочу поделиться с вами нашим опытом по автоматизации этой работы и обсудить получившийся инструмент.
Недавно я с удивлением обнаружил, что, оказывается, толковых туториалов по Oracle Application Express (он же APEX, он же апекс, но не путать с языком apex, который используется в Salesforce) в природе не существует.
Это не самая распространенная технология, конечно, но, тем не менее, довольно востребованная. Есть десятки блогов об апексе (англоязычные, в основном), пара тысяч вопросов на Stackoveflow, специальный раздел по апексу на официальных форумах оракла, сам апекс существует уже 15 лет и все время развивается. Я был уверен, что и хороших туториалов полно. Но нет!
Мне тут же пришла в голову гениальная мысль восполнить этот пробел.
Почему существующие туториалы — плохие
Вводная информация
Обзор IDE
App builder
Страница приложения
Application properties
Shared Components
Page Designer
SQL Workshop
Object Browser
SQL Commands
Хабр, привет!
Меня расстраивает несправедливость в мире IT: для новичков-разработчиков есть куча пошаговых инструкций, о там, как разработать API или мобильное приложение. Хочу немного уровнять баланс вселенной, поэтому я написал небольшой гайд для аналитиков для составления документации.
В прошлой статье я представил шаблон, а теперь заполнил его для фичи «Экспресс-доставка товара в маркетплейсе». Моя цель – показать, как можно вести документацию и как правильно заполнять этот шаблон.
DNS (Domain Name System) – это система, которая переводит понятные человеку доменные имена в IP-адреса, которые используют компьютеры для связи друг с другом. Представьте, что DNS – это как телефонная книга интернета. В обычной телефонной книге, если вам нужно найти номер телефона человека, вы ищете его по имени, и книга предоставляет вам номер. Точно так же DNS помогает находить IP-адреса, когда вы вводите доменное имя.
Когда вы вводите адрес веб-сайта, например, www.example.com, в строку браузера, DNS помогает найти нужный IP-адрес, чтобы ваш браузер мог подключиться к нужному серверу. IP-адрес – это уникальный числовой идентификатор, который используется для идентификации устройства в сети. Всякий раз, когда вы отправляете запрос на веб-сайт, ваш браузер отправляет этот запрос через интернет на сервер, который затем отвечает данными, которые вы видите на экране.
В статье я постарался затронуть базовые темы в виде вопрос/ ответ на горячо любимые темы на собеседованиях и не только.
Привет, Хабр, меня зовут Светлана Уварова, я — ведущий системный архитектор в МТС.
В этой статье я расскажу о том, как может меняться архитектура системы в зависимости от нефункциональных требований к ней, и как важно знать все нефункциональные требования на начальном этапе проектирования системы.
Привет, Хабр! Меня зовут Андрей Царев — я системный аналитик, технический интервьюер и ментор.
Системный анализ — одно из популярных направлений в ИТ.
Но далеко не все представляют, как правильно готовиться к интервью и проходить их. В этой статье я делюсь собственным опытом и полезными советами, чтобы вам было проще получить работу мечты!
Многие из вас, я уверен, слышали о теории игр в какой-то момент своей жизни. Если вы хотите выглядеть умным и произвести впечатление на свою девушку — просто упомяните «игру с нулевой суммой» или «эволюционную стратегию», и ваши шансы отвести её домой сегодня вечером только что подскочили на 50%. Или вы можете использовать теорию игр, чтобы принимать решения в инвестировании своих денег (чтобы их полностью потерять и разориться) или, например решая, на какой девушке жениться (что также очень вероятно вас разорит). Как видите, это очень полезная теория.
Чтобы казаться умным - достаточно выучить эти пару выражений, но чтобы на самом деле что-то понимать - придется разобраться. Оказывается, это не так уж сложно и довольно интересно. Давайте посмотрим.
Хотя сейчас я работаю в ИТ-отрасли, много лет назад я верстал рекламную газету, и с тех пор дизайн – мой профессиональный навык и увлечение за пределами профессии.
Сделать диаграммы привлекательными гораздо проще, чем вы думаете. Получить рекомендации на все случаи жизни не выйдет, но освоить несколько приемов в Excel и узнать азы теории, вы сможете за 10 минут.
Из тридцатилетнего опыта и десятков прочитанных книг я выбрал семь полезных приемов. Их мы и разберем в этой статье в блоге ЛАНИТ.
У INCOSE (Международного совета по системной инженерии) в июне 2023 года вышла итоговая сводка по руководство по написанию требований (ссылка).
Данная итоговая сводка содержит определения, краткое описание свойств, которыми должны обладать качественно сформулированные потребности/требования, а также наборы потребностей/требований. В итоговой сводке содержится краткое изложение правил написания качественных потребностей/требований, а также их атрибутов.
Данная статья - перевод с английского языка итоговой сводки по написанию требований.
Управляющие конструкции языка программирования Аргентума основанны не на типе Boolean а на типе Optional. Это имеет далеко идущие последствия для надежности, выразительности и удобочитаемости.
Всем, привет. Для самых жаждущих и нетерпеливых эта в этой статье будет про:
• Типы анализа, используемые для/около информационных технологий;
• Систему координат типов анализа и для чего использовать каждый из них;
• Специальные артефакты для каждого типа анализа;
• То, как понять, что в компании/процессе/проекте нужно использовать конкретный тип анализа;
• Акценты и навыки, нужные при использовании каждого типа анализа;
Для тех, кому интересно и хочется сложить причинно-следственные связи, проследить нить рассуждений, то давайте это сделаем. Я Иван. Люблю сферу информационных технологий и стремлюсь развиваться в дисциплинах, задействованных для создания информационных продуктов – анализе, проектировании, разработке. Эти дисциплины влияют друг на друга и на конечный результат - создаваемую информационную систему.
Рассуждая, что такое анализ, какой он бывает, какой тип, в каких условиях использовать и какие навыки нужны для того, чтобы его выполнять, я предположил, что будет полезным систематизировать имеющийся опыт и результаты обсуждения с коллегами, слушателями профессиональных программ развития НИУ ВШЭ, МИСИС, интернет университетов. Так появился следующий обзор. Надеюсь, он принесет вам пользу. Рассчитываю на обсуждение. Присоединяйтесь :-)
Лучший способ понять теорию — получить больше опыта в разных проектах. Для системных и бизнес‑аналитиков я постоянно показываю подходы к работе через публикацию разборов задач: БД, API, Интеграции, требования, и все, что связано с проектированием систем.
После публикации поста общий подход к работе с задачами системного аналитика, меня попросили показать, как его применить на практике. Собрала примеры постановок задач и описаний системы по одному из проектов. Здесь постараюсь кратко изложить его. А в конце оставлю ссылку на подборку примеров, которые можно посмотреть и переиспользовать в своих проектах.
Решил составить для себя план развития (я в IT с 2007, как аналитик - с 2017). Что получилось: некий чек-лист с перечислением 13 блоков (от работы с требованиям до безопасности) с описанием, что обязательно и желательно знать/уметь.
С чего все началось. Я недавно менял работу, поэтому готовился к техническим собеседованиям. Для удобства составил шпаргалку частых вопросов по основным темам. Когда проходил собеседования и видел, чего я не знаю, то дописывал это в свою шпаргалку. А немного позже решил составить для себя что-то наподобие плана развития. При создании плана использовал личный опыт, опыт коллег, ряд статей, учебные планы нескольких школ, требования из вакансий.
Каждый системный и бизнес-аналитик проходит "боевое крещение" в своей карьере, когда получает первую задачу на проектирование интеграций. Звучит серьезно и сложно. И это так, если ни разу не работал с таким видом задач.
С чего начать и куда смотреть при работе с задачами на интеграции? Давайте воспользуемся пошаговой инструкцией, чтобы понять план действий.
Идемпотентность — звучит сложно, говорят о ней редко, но это касается всех приложений, использующих API в своей работе.
Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.
