🐙 Знакомство с gRPC 🐙

1️⃣ Общая информация

▫️gRPC — система удалённого вызова процедур.
Разработана в Google в 2015 году.

▫️Использует Protocol Buffers — protobuf — буферный протокол сериализации данных, проще говоря преобразования данных.

▫️RPC (Remote Procedure Call) — это способ, который позволяет одной программе на сервере А вызвать функцию в другой программе, которая находится на другом сервере B, как будто это локальный вызов. Другими словами, как будто вызов функции происходит на одном сервере A, а не на разных.

▫️Зачем нужна сериализация в gRPC?
(= Зачем нужно преобразование данных?)
1. Сериализация позволяет компактно представлять данные в бинарном виде, что уменьшает объем передаваемой информации и ускоряет передачу.
2. Сериализованные данные можно передавать между разными системами и языками программирования, сохраняя их структуру и типы данных.
3. Сериализованные данные проще проверять на целостность и корректность при передаче по сети.


➕ Назначение gRPC
Оптимизировать связь между приложениями и сервисами с помощью высокопроизводительных RPC.


➕ Общие принципы

1. gRPC использует протокол HTTP/2 для транспортировки данных, обеспечивая высокую производительность и двунаправленное потоковое взаимодействие.

2. Определение контрактов между клиентом и сервером осуществляется с помощью proto-файлов.

3. Proto-файлы компактны и позволяют автоматически генерировать исходный код для различных языков программирования.

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


➕ Особенности и отличия от других API

1. В отличие от REST, где каждый запрос требует нового HTTP-соединения, gRPC использует постоянное HTTP/2 соединение, что улучшает производительность.

2. Благодаря protobuf можно быстрее передавать данные по сети.


Итого:
gRPC выбираем, когда нужна высокая скорость обмена данными между системами или сервисами.

#АрхитектураGA

Продолжение 👇👇👇

🐙 Примеры и ссылки по gRPC 🐙

➕ Примеры использования

▫️Google Cloud
Google активно использует gRPC в своих облачных сервисах.
https://cloud.google.com/api-gateway/docs/grpc-overview

▫️Netflix
Netflix применяет gRPC для внутренней связи между микросервисами.
gRPC обеспечивает высокую производительность и надежность передачи данных между различными микросервисами, что важно для масштабируемых систем потокового видео​.
https://www.cncf.io/blog/2021/08/04/grpc-in-action-example-using-java-microservices/

▫️Lyft (аналог Яндекс.Такси и Uber)
Использует gRPC для передачи данных о местоположении автомобилей в режиме реального времени.
Постоянное соединение gRPC позволяет непрерывно отправлять сообщения о местоположении автомобиля на мобильное приложение, что значительно улучшает пользовательский опыт и снижает задержки по сравнению с традиционным опросом сервера​.
https://www.redhat.com/architect/grpc-use-cases


➕ Для каких видов архитектуры подходит

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

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


➕ Влияние на выполнение НФТ

Высокая производительность (скорость обмена данными) за счет использования HTTP/2 и protobuf.


➕ Полезные ресурсы для изучения

1. Официальная документация gRPC

2. Подкаст GetAnalyst с Марией Кубениной по gRPC

3. Книга "gRPC: запуск и эксплуатация облачных приложений. Go и Java для Docker и Kubernetes", Индрасири Касун, Курупу Данеш:
Отличное руководство для разработчиков, но немного перебор для аналитиков. Полезно пролистать понятные страницы.

4. Примеры работы с gRPC API от Яндекс.Cloud тут 🙂


Вот так я применяю Пошаговый план: с чего начать изучение нового API? - идеальная инструкция для знакомства с разными API. С ним последовательно можно найти самую важную информацию.

#АрхитектураGA

🛢 Оптимизация БД. Работа с индексами 🛢

Каждый месяц в GetAnalyst мы проводим практикумы, посвященные проектированию БД и SQL. В этом году я перешла на новый уровень, и предлагаю только самые продвинутые темы в онлайн формате.

Работа с индексами в БД - одна из них 💫

Приглашаю вас присоединиться!

🗓 3 ИЮНЯ, 19:00 Мск (пн)
🔗 Подробности и запись


План практики:
1. Нефункциональные требования к системе и их связь с БД.
2. Понятие индексов в БД и их назначение. Разбор примеров.
3. Практика: знакомство с БД проекта и определение таблиц с индексами.
4. Проблемы избыточной оптимизации БД.
5. Индексы в постановке задачи на разработку.

👨‍💻 Этот практикум идеально подходит для системных аналитиков, стремящихся углубить свои знания и навыки в области проектирования баз данных и оптимизации систем.

Присоединяйтесь к нам в следующий понедельник и получайте новый опыт 🙌

🤝 Договориться можно обо всём 🤝

Мы постоянно сталкиваемся с переговорами. Предлагаем и защищаем свои решения в работе почти ежедневно.

А когда есть карьерные цели, то при обсуждении вопросов ЗП пытаемся угадать с какой стороны подойти к вопросу, чтобы аккуратно и т.д.

Договориться можно обо всём - это не красиво придуманное название поста, а название важной для меня книги Гевина Кеннеди. Она изменила мой взгляд на взаимоотношения с людьми. Как в рабочем плане, так и в личном.

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

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


Важные уроки:

📗 1. Переговоры – это не только умение убеждать, но и искусство слушать и понимать другую сторону.

📗 2. Не стесняться высказывать свои мысли и защищать свои предложения. Зачастую, именно благодаря уверенности в себе и умению правильно преподнести аргументы, можно добиться успеха в любых переговорах.


Не бойтесь отстаивать свою точку зрения и быть настойчивыми – это поможет вам не только в профессиональной деятельности, но и в личной жизни.


О чем договорились, то и получаем 🙌

💻 Интеграция — что это? 💻

Ситуация: вам нужно купить билет на самолёт. И вместо того, чтобы гулять по сайтам авиакомпаний в поисках нужной цены, вы заходите в одно приложение и просто вбиваете пункты А-В и желаемые даты. Это приложение называется Агрегатор билетов.

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

Аналогично работают приложения Госуслуги, банки, сервисы по доставке еды и многие другие. Все возможности через единое окно!

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

Интеграция — это единый процесс, объединяющий технологии и системы в единую последовательную цепочку.

Интеграции преобразуют форматы данных между системами в единую структуру.

Как итог, пользователю не приходится обращаться к множеству ресурсов - всё в одном месте ✅


Еще немного теории, пример и ссылку на большую подборку видео, разборов проектов и статей по интеграциям от GetAnalyst оставила на последней странице мини-гайда, прикрепленного к посту 😉

🏦 Новый проект: приложение для банковских переводов 🏧

В этом месяце мы будем работать над новым интеграционным проектом для мобильного приложения банка #GABank.

Чтобы сделать банковский перевод между счетами юридических лиц (далее - юрлиц) для оплаты товаров или услуг, пользователям приходится вводить вручную множество реквизитов. Это утомительный процесс, так как нужно заполнить такие данные, как ИНН, КПП, БИК банка, корреспондентский счет (КС), расчетный счет (РС), наименование банка и получателя, и другие.

Ввод каждого из этих реквизитов вручную занимает время и может приводить к ошибкам 😞

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


Основные возможности, которые хотим внедрить:

✨ Автозаполнение реквизитов
Приложение должно автоматически подтягивать нужную информацию с помощью интеграции с сервисом DaData по HTTP API (аналог REST API). Вводим ИНН юрлица, а все остальные поля заполнятся сами! 🧙‍♂️

✨ Сохранение истории
Все введенные реквизиты будут сохраняться в истории, так что в следующий раз можно будет повторить перевод в два клика 🕶️

✨ Обновление данных
Если нужной компании нет в базе DaData, не беда! Мы будем сохранять ее данные в нашей внутренней базе, чтобы помочь другим пользователям в будущем 📚


Наши задачи как аналитиков на проекте:

1. Сформулируем функциональные требования к интеграции.
2. Сделаем модель БД, которая обеспечит хранение всех необходимых данных.
3. Опишем архитектуру решения.
4. Исследуем API-документацию внешней системы DaData.
5. Протестируем API в Postman.
6. Сформулируем интеграционный Use Case.
7. Сделаем маппинг данных между системами.

Стартуем проект на июнь? 😉🔥

#ИнтеграцииGA

🚀 Спасибо за то, что вы достигаете цели 🚀

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

Растить специалистов, которые будут создавать качественные и надёжные IT-продукты для бизнеса

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

Собрала несколько последних сообщений, которые получила только за последние пару недель.

Евгения

Кто провел пресейл, нарисовав заказчику С4 и расписав, как мы классно все интегрируем и настроим SSO с помощью Keycloack, и ваще, и довел дело до договора, тот я. Прям с колес, даже домашки по занятости так и не сделав. Большое человеческое спасибо

Владимир

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

Zalina D

Спасибо большое за курс. Всё было очень полезно и познавательно ❤️❤️❤️

Дарина А

Большое спасибо за курс, было очень много полезной информации, видно Ваш богатый опыт! У Вас отличная команда! 👍🏼

Настя

спасибо тебе большое за ту миссию, что ты делаешь. А делаешь ты из сложного простое, и все меньше становится страшно ❤️

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

Ставим карьерные цели и идем к ним вместе. Я и команда GetAnalyst здесь, чтобы поддержать вас на пути к ним 🚀

🧩 Как интеграцию видит обычный пользователь? 🧩

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

Пользователь банковского приложения #GABank для юрлиц выбирает функцию “Сделать перевод по реквизитам”, нажав на кнопку в одном из основных экранов. Отрисовывается новый экран - вы видите поля для ввода реквизитов. Пока никакого волшебства в виде запросов к серверу для загрузки данных нет.

Поля ввода для осуществления перевода:
+ ИНН получателя,
✅ КПП получателя,
✅ полное наименование получателя,
☑️ БИК банка,
✅ название банка,
✅ к/с банка (номер корреспондентского счета банка),
☑️ р/с (номер расчетного счета получателя),
+ сумма,
+ назначение платежа,
+ НДС.

Сейчас все заполняется вручную.
Но часть реквизитов может заполняться автоматически:
✅ - на основании данных DaData,
☑️ - из данных банка.



КАКОЙ СЦЕНАРИЙ ОЖИДАЕМ ПОЛУЧИТЬ:


1. Пользователь начинает вводить ИНН получателя.

После ввода 5 символов начинаем предлагать варианты выбора организации из списка.

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

Если пользователь выбрал организацию из списка или она найдена по ИНН, то автоматически заполнять все поля до БИК.


2. Пользователь начинает вводить БИК банка.

После ввода 4 символов начинать предлагать варианты банков для выбора.

🧩Интеграция с DaData.

Если удалось найти банк по БИК, то заполнять все поля. Р/с также будет заполнен автоматически, если данные о для этого юрица сохранены в БД банка.

3. Пользователь вводит оставшиеся параметры и делает перевод.

4. После успешного перевода, если р/с не был ранее сохранен, то сохраняем его в БД банка.

Итого:
+ Пользователь вводит только 5/10 полей.
+ Часть из них только наполовину.

Так начинается работа с интеграциеями. Понимание пользовательского сценария и бизнес-цели того, что мы делаем, важны.

#ИнтеграцииGA

✅ Функциональные требования к Интеграции: чек-лист ✅

Когда мы разрабатываем требования (ФТ) к интеграции систем, то на поверхности видны далеко не все требования, которые нужно описать для бизнес-заказчиков и разработчиков, чтобы все стороны ясно понимали объем работ.

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

Чек-лист функциональных требований:

1. Конфигурационные параметры
2. Авторизация
3. Ре-авторизация
4. Хранение данных в БД - изменение модели
5. Интеграционные API методы (ключевые функции)
6. Логирование, метрики и алерты

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

Пользуйтесь и сохраняйте на будущее 💾❤️

#ИнтеграцииGA

👩‍💻 Пример ФТ к Интеграции с DaData для приложения #GABank 👩‍💻

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

1-И. Обеспечить хранение конфигурационных параметров для интеграции с DaData: авторизационные параметры, URL-ы тестовой и боевой площадки, лимит на количество запросов.

2-И. Реализовать общий механизм авторизации банковской системы с внешней системой DaData.

3. Обеспечить хранение данных о расчетных счетах (р/c) юрлиц в различных банках.

4-И. Реализовать возможность поиска организации по ИНН с использованием интеграции с внешней системой DaData. Поиск организации должен осуществляться при вводе 5 или более символов.
НФТ: Запросы на поиск в систему DaData должны отправляться не чаще 1 раза в 2 сек.

5-И. Реализовать возможность поиска банка по БИК с использованием интеграции с внешней системой DaData. Поиск банка должен осуществляться при вводе 4 или более символов.
НФТ: как в п.4.

6-И. Вести учет количества запросов в сутки к внешней системе DaData, визуализировать на графике Grafana и информировать ответственных бизнес-сотрудников, если значения в сутки составляет более 85% от предоставленного лимита по оплаченному тарифу (ссылка на требования к оплате при использовании сервиса DaData, но нам для аналитики хватит и бесплатной версии).

И - связано с интеграцией
НФТ - нефункциональное требование


P.S. Я рада комментариям про альтернативные сценарии и обработку ошибок в интеграциях!)) Это тоже обсудим в рамках проекта, но на уровне ФТ считаю, что это будет обязательно заложено в логику работы.

Есть ли еще ФТ, которые хочется включить? Если все учли, то ставим 👍под постом и двигаемся далее.

#ИнтеграцииGA

Подводя итоги половины 2024, поняла, что этот год перенасыщен событиями 🙌

Работа порой чуть ли не 24/7. Иногда кажется, что я ничего не успеваю. Но если взглянуть на количество галочек в ежедневнике за каждый день, то обычный человек может испугаться. А я думаю как вместить ещё.

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

На прошлой неделе я смогла устроить небольшой отпуск, и теперь мне кажется, что на этой неделе я должна свернуть горы 🏔🌇

Она только начинается, а я уже в предвкушении, поскольку впереди:
☑️ Прилететь в Нью-Йорк и успеть хоть немного погулять по нему.
☑️ Бизнес-встречи.
☑️ Конференция по использованию ИИ в разработке (ИИ - Искусственный Интеллект).
☑️ Первая онлайн-встреча по проекту Архитектуры с новым потоком.
☑️ Стандартный объем задач по ведению проектов и работе с программами GetAnalyst.

Каждую неделю думаю, что сложная и насыщенная событиями неделя закончилась и дальше легче. А нет, вот и новая прилетела! Расписание загружено на 200%. Придётся успевать всё, что возможно, и что невозможно))

“Зона комфорта” не для меня, хочется постоянно чувствовать рост и проходить через челленджи. И 2024 даёт их сполна и помогает двигаться к поставленным целям!

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

Делитесь с нами в комментариях и как справляетесь морально, когда тяжело 🙂

📁 БД системы и ее значение в задачах на Интеграции 📁

Один из ключевых этапов работы системного аналитика при постановке задач на интеграции - маппинг (сопоставление) данных между различными системами.

В описание маппинга включают данные:
- API внешней системы.
- API системы, в которой делают интеграцию.
- БД системы, в которой делают интеграцию.
- UI системы, в которой делают интеграцию, при постановке задач на пользовательские приложения с экранами (фронтенд).

Понимание структуры базы данных (БД) проекта является важным аспектом. Это необходимо для корректного маппинга данных, особенно в случаях, когда в результате работы интеграционного сценария нужно что-либо сохранить в БД или сопоставить с данными, хранимыми в системе.

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

👇

Таблица company

Эта таблица хранит информацию о компаниях (юридических лицах), которые являются участниками банковских операций.

Если компания открывает счет в GABank, то данные о ней создаются в системе. Если нет, то компания может быть добавлена в список как внешняя при создании перевода в неё.

+ id: Уникальный идентификатор компании (первичный ключ).
+ inn: ИНН компании.
+ kpp: КПП компании. Может быть сохранен на основании интеграции с DaData, при получении информации о компании по ИНН.
+ name: Краткое название компании. Может быть сохранено из DaData.
+ full_name: Полное название компании. Может быть сохранено из DaData.

#ИнтеграцииGA

Продолжение 👇

📁 БД системы и ее значение в задачах на Интеграции 📁

Таблица related_companies

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

+ company_id: Идентификатор компании, которая имеет счет в GABank, и может делать переводы в другие компании, в том числе на их счета в других банках или на свой счет в другом банке (внешний ключ).
+ related_company_id: Идентификатор связанной компании (внешний ключ).
+ created_by_transfer_id: Идентификатор перевода, через который впервые установлена связь (внешний ключ).
is_visible: Поле, указывающее, видна ли связь пользователям - показывается ли сразу эта запись при переводе в списке подсказок..

Таблица bank

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

+ id: Уникальный идентификатор банка (первичный ключ).
+ name: Название банка. Может быть сохранено из DaData.
+ bik: БИК банка.
+ correspondent_number: Корреспондентский счет банка. Может быть сохранено из DaData.
created_at: Дата создания записи.

Таблица account

Эта таблица хранит информацию о счетах компаний внутри GABank.

+ id: Уникальный идентификатор счета (первичный ключ).
+ bank_id: Идентификатор банка, в котором счет (внешний ключ).
+ company_id: Идентификатор компании, которой принадлежит счет (внешний ключ).
+ number: Номер расчетного счета.
+ created_at: Дата создания счета.

Таблица external_account

Эта таблица хранит информацию о банковских счетах компаний в других банках.

+ id: Уникальный идентификатор внешнего счета (первичный ключ).
+ bank_id: Идентификатор банка (внешний ключ).
+ company_id: Идентификатор компании (внешний ключ).
+ number: Номер счета.
+ created_at: Дата создания записи.

Таблица transfer

Эта таблица хранит информацию о банковских переводах.

+ id: Уникальный идентификатор перевода (первичный ключ).
+ recipient_account_id: Идентификатор счета получателя (внешний ключ).
+ is_external: Флаг, указывающий, является ли перевод внешним, т.е. данные о счете будут в таблице external_account.
+ sender_account_id: Идентификатор счета отправителя (внешний ключ).
+ amount: Сумма перевода.
+ currency: Валюта перевода.
+ vat: НДС.
+ notes: Примечания к переводу.
+ status: Статус перевода.
+ created_at: Дата создания.
+ transferred_at: Дата осуществления перевода.


Эта структура БД обеспечивает хранение всех необходимых данных для выполнения и отслеживания банковских переводов между юридическими лицами в приложении #GABank.

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

#ИнтеграцииGA

🔥 Проектирование БД для проекта с нуля - 2 важных видео🔥

Коллеги, выше показала небольшую модель БД, но не для всех может быть понятно как она получилась для приложения GABank.

Если у вас нет опыта проектирования БД с нуля, нужно структурировать знания по построению ER-диаграмм или необходимо прокачать знания по БД, то настоятельно рекомендую посмотреть эти видео:

1. Проектирование БД: концептуальный уровень
2. Проектирование БД: логический уровень + ChatGPT

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

А если вам хочется глубже погружаться в работу с БД и SQL, то всегда можно подключиться на дополнительные практикумы.

Не откладывайте и обязательно смотрите эти два видео!)) Они очень помогут улучшить ваши знания и дадут опыт работы с БД! 🙌

🔬 Разбираем архитектуру интеграционного проекта #GABank 🔬

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

Главное, что мы должны показать на схеме - это её основные компоненты:
1. Пользовательские приложения / Frontend / UI
2. Backend с базовым пониманием архитектуры: сервисы / микросервисы / монолит
3. Базы данных
4. Файловые хранилища
5. Внешние системы
6. Оборудование


Стоит обратить внимание, что когда я готовила схему для нашего приложения банка, прикрепленную к посту, я сделала допущение, что Backend монолитный. В реальных банковских проектах это не так - там SOA и MSA (сервисная и микросервисная архитектуры).


Компоненты #GABank, задействованные в процессе ввода реквизитов для перевода между юрлицами и отраженные на схеме:
- Мобильные приложения iOS/Android
- Веб-приложение
- Монолитный Backend с REST API для клиентов
- Внешняя система DaData, с интеграцией по HTTP
- Единая база данных
- Файловое хранилище для PDF по итогам переводов
На основании их создана схема.


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

В идеале, дополнить это UML-диаграммой последовательностей, которая помогает рассказывать интеграционные сценарии. Но не обязательно :)

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

#ИнтеграцииGA

🤖 Подкаст про ИИ + лайфхаки ChatGPT для Системных Аналитиков 🤖

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

1:30 - Определение Искусственного Интеллекта (ИИ) / AI (Artificial Intelligence).
6:32 - Что такое ChatGPT*, как он работает и какие задачи выполняет.
15:56 - Идеальное транскрибирование голоса в текст за счет анализа контекста Искусственным Интеллектом через мобильное приложение ChatGPT.
18:12 - Обзор карты навыков системного аналитика и применение ChatGPT как дополнительного инструмента в работе. Про сбор требований.
27:11 - Работа с бизнес-требованиями. Диаграммы BPMN (инструмент Camunda). Для презентаций рекомендуется приложение Canva*.
37:49 - Работа с функциональными и нефункциональными требованиями (упоминаемый подкаст про НФТ). Диаграммы UML (инструмент PlantUML) через ChatGPT.
41:55 - Документирование, проектирование базы данных, архитектура систем.
48:15 - Маппинг данных с помощью ChatGPT при постановке задач на интеграции и API.
49:19 - Проектирование REST API через ChatGPT.
53:23 - Тестирование, инструменты и другие навыки системного аналитика.
Пример Swagger-документации Wildberries, пример рабочего проекта с кодом.
1:01:51 - Где использовать ChatGPT. Полезен или вреден ChatGPT? На что обращать внимание. Отсылка на статью про C4 - диаграмму для архитектуры.

*P.S. Часть ссылок точно доступна только под VPN в некоторых странах.

Эпизод доступен в:

⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ YouTube
⏯ Telegram
⏯ Castbox
⏯ Spotify

Слушайте на удобных площадках, подписывайтесь и делитесь с коллегами! 💖

Друзья, предлагаем подборку фильмов и сериалов про IT, чтобы вы точно проверили классно время в выходные 👌

Делитесь, что уже смотрели или планируете посмотреть😏👇

🔸 Как одно требование на интеграцию может превратиться в 10+ задач на разработчиков 🔸

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

Можно подойти к аналитике и декомпозиции поверхностно, создать и описать следующие задачи:

1. Дизайн экрана - изменения в связи добавлением функциональности.
2. Одна задача на Backend, на разработку метода API, который будут использовать приложения.
3-5. По одной задаче на каждый фронтенд (веб- / мобильные приложения).

Но это всего лишь группы работ, но не конкретные задачи на разработчиков.

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

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

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

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

Хочу поделиться им с вами в следующем посте 🙂

#ИнтеграцииGA