Продолжение 👇
Вариант 2. Делаем оформление заказа и прием платежей на нашей стороне.
Этот вариант сложнее с точки зрения технической реализации. Но у него есть преимущество - полный контроль процесса и данных у GetDelivery.
Плюсы:
+ Мы сможем отслеживать заказы, которые оформлены с использованием нашей системы: будем создавать заказы и контролировать прием платежей, вызывая внешние системы по API.
То есть мы будем являться инициатором всех действий по отправлению груза и оплате от клиента, по сути действуя как помощники нашего клиента (пример: страховой брокер - человек, который помогает оформить страховку на автомобиль по самой выгодной цене).
В этой интеграции GetDelivery - мастер-система / управляющее приложение.
+ После создания заказа мы сможем по API отслеживать его статус, получать и отправлять клиенту уведомления об изменении статуса заказа, если внешняя система представляет соответствующие API-методы. Эту возможность нужно будет уточнить на этапе изучения документации внешних систем.
+ Если на нашей стороне организован прием платежей, то получается, что мы будем получать деньги от клиента первее чем СДЭК или другую компанию.
Это звучит привлекательно для бизнеса. Но требует уточнения: как затем деньги будут поступать в СДЭК - должны ли мы сделать оплату за клиента с нашего счета сразу, или потом сформировать отчет обо всех заказах за месяц и выполнить единый банковский перевод, вне системы. Нужно уточнять условия сотрудничества и взаиморасчетов с каждой из компаний.
+ Единое окно для пользователя для работы с отправлениями грузов, без усложнений с переходами на дополнительные ссылки и страницы.
👇👇👇
Вариант 2. Делаем оформление заказа и прием платежей на нашей стороне.
Этот вариант сложнее с точки зрения технической реализации. Но у него есть преимущество - полный контроль процесса и данных у GetDelivery.
Плюсы:
+ Мы сможем отслеживать заказы, которые оформлены с использованием нашей системы: будем создавать заказы и контролировать прием платежей, вызывая внешние системы по API.
То есть мы будем являться инициатором всех действий по отправлению груза и оплате от клиента, по сути действуя как помощники нашего клиента (пример: страховой брокер - человек, который помогает оформить страховку на автомобиль по самой выгодной цене).
В этой интеграции GetDelivery - мастер-система / управляющее приложение.
+ После создания заказа мы сможем по API отслеживать его статус, получать и отправлять клиенту уведомления об изменении статуса заказа, если внешняя система представляет соответствующие API-методы. Эту возможность нужно будет уточнить на этапе изучения документации внешних систем.
+ Если на нашей стороне организован прием платежей, то получается, что мы будем получать деньги от клиента первее чем СДЭК или другую компанию.
Это звучит привлекательно для бизнеса. Но требует уточнения: как затем деньги будут поступать в СДЭК - должны ли мы сделать оплату за клиента с нашего счета сразу, или потом сформировать отчет обо всех заказах за месяц и выполнить единый банковский перевод, вне системы. Нужно уточнять условия сотрудничества и взаиморасчетов с каждой из компаний.
+ Единое окно для пользователя для работы с отправлениями грузов, без усложнений с переходами на дополнительные ссылки и страницы.
👇👇👇
👍5👏2
👇👇👇
Минусы:
- Придется дополнительную интеграцию с платежной системой, чтобы принимать платежи за заказы у нас. Либо смотреть, как предлагают работать с платежами внешние системы СДЭК, Деловые Линии и Возовоз, с которыми мы интегрируемся.
Исходя из этого принимать решение о дополнительной интеграции с платежной системой типа ЮКасса, Райф Пэй или другая.
- На нашу систему, с точки зрения администрирования, ляжет большая ответственность по расчетам сумм прибыли и комиссии для GetDelivery, учет сумм выплат для конечных организаций, которые занимаются доставкой грузов.
- Платежная история может быть разная для разных систем. Это может усложнить интеграцию. А в системах агрегаторах важно свести все к единому сценарию при возможности, любыми способами.
🟢 Вариант 2 мне больше нравится для реализации интеграции, т.к. он удобен для пользователя, и наша система имеет больше контроля.
Но прежде чем принимать окончательное решение о выборе этого варианта, я должна внимательно изучить API-документацию - прием платежей, и условия сотрудничества - как будут рассчитываться между собой GetDelivery и СДЭК, Деловые Линии, Возовоз. Это поможет мне принять окончательное решение по реализации формирования заказов и платежной части.
Кроме того, что я буду изучать документацию и условия возможного партнерства доя СДЭК, Деловые Линии и Возовоз, я также посмотрю аналогичные системы, т.к. потенциально понимаю, что в будущем могут потребоваться подобные типовые интеграции для агрегатора и мне было бы интересно разобрать больше примеров и заранее знать, к каким сложностям нудно быть готовой в будущем при подключении дополнительных интеграций.
📌 Запрос документации внешних систем:
Всё получено.
📌 Запрос доступов к внешним системам:
Можно писать письма СДЭК, Деловые Линии и Возовоз, на запрос тестовых доступов. Для этого нам может потребоваться подпись договора или NDA. Так часто бывает с интеграциями. Поэтому запрос доступов это самый первый шаг, чтобы далее не было блокирующих моментов для проектирования и разработки интеграций
Этап 1️⃣
Подготовка ✅
Минусы:
- Придется дополнительную интеграцию с платежной системой, чтобы принимать платежи за заказы у нас. Либо смотреть, как предлагают работать с платежами внешние системы СДЭК, Деловые Линии и Возовоз, с которыми мы интегрируемся.
Исходя из этого принимать решение о дополнительной интеграции с платежной системой типа ЮКасса, Райф Пэй или другая.
- На нашу систему, с точки зрения администрирования, ляжет большая ответственность по расчетам сумм прибыли и комиссии для GetDelivery, учет сумм выплат для конечных организаций, которые занимаются доставкой грузов.
- Платежная история может быть разная для разных систем. Это может усложнить интеграцию. А в системах агрегаторах важно свести все к единому сценарию при возможности, любыми способами.
🟢 Вариант 2 мне больше нравится для реализации интеграции, т.к. он удобен для пользователя, и наша система имеет больше контроля.
Но прежде чем принимать окончательное решение о выборе этого варианта, я должна внимательно изучить API-документацию - прием платежей, и условия сотрудничества - как будут рассчитываться между собой GetDelivery и СДЭК, Деловые Линии, Возовоз. Это поможет мне принять окончательное решение по реализации формирования заказов и платежной части.
Кроме того, что я буду изучать документацию и условия возможного партнерства доя СДЭК, Деловые Линии и Возовоз, я также посмотрю аналогичные системы, т.к. потенциально понимаю, что в будущем могут потребоваться подобные типовые интеграции для агрегатора и мне было бы интересно разобрать больше примеров и заранее знать, к каким сложностям нудно быть готовой в будущем при подключении дополнительных интеграций.
📌 Запрос документации внешних систем:
Всё получено.
📌 Запрос доступов к внешним системам:
Можно писать письма СДЭК, Деловые Линии и Возовоз, на запрос тестовых доступов. Для этого нам может потребоваться подпись договора или NDA. Так часто бывает с интеграциями. Поэтому запрос доступов это самый первый шаг, чтобы далее не было блокирующих моментов для проектирования и разработки интеграций
Этап 1️⃣
Подготовка ✅
👍9
▫️Этап 2 проектирования Интеграций. Сбор и анализ требований ▫️
Этот этап включает формирование полных требований по IT-проекту. От заказчика должны быть получены все вводные, проведено исследование действующих бизнес-процессов AS IS, и сформированы требования к TO BE.
С какими проблемами можно столкнуться на этапе сбора и анализа требований проекта? 🤯
Заказчик хочет, но это сделать невозможно. Требования не реализуемы.
Для бизнес-аналитиков и системных аналитиков, кто не сильно погружается в детали технического проектирования, это может стать сюрпризом. Неприятным сюрпризом, если “это не реализуемо” от разработчиков всплывает на этапе реализации программы, после подписания договора на разработку по ТЗ с заказчиком.
Почему “это не реализуемо” случается на этапе сбора и анализа требований?
⛔ Аналитик знал о необходимости интеграций с внешними системами в проекте, но не проверил в API-документации наличие соответствующих методов.
⛔Аналитик проверил наличие соответствующих методов для интеграции систем, но не ознакомился детально с их описанием. Вследствие чего могут быть получены проблемы: получение необходимых данных для работы системы, разные ожидаемые статусные модели для сущностей и подобные.
⛔Аналитик не проводил базовое тестирование API (если такая возможность была, например с SOAP, REST, GraphQL это возможно, Postman наш друг).
⛔Не учтены нефункциональные требования, которые помешают реализации бизнес-процесса. Например, ограничение на количество запросов в минуту.
Продолжение 👇
Этот этап включает формирование полных требований по IT-проекту. От заказчика должны быть получены все вводные, проведено исследование действующих бизнес-процессов AS IS, и сформированы требования к TO BE.
С какими проблемами можно столкнуться на этапе сбора и анализа требований проекта? 🤯
Заказчик хочет, но это сделать невозможно. Требования не реализуемы.
Для бизнес-аналитиков и системных аналитиков, кто не сильно погружается в детали технического проектирования, это может стать сюрпризом. Неприятным сюрпризом, если “это не реализуемо” от разработчиков всплывает на этапе реализации программы, после подписания договора на разработку по ТЗ с заказчиком.
Почему “это не реализуемо” случается на этапе сбора и анализа требований?
⛔ Аналитик знал о необходимости интеграций с внешними системами в проекте, но не проверил в API-документации наличие соответствующих методов.
⛔Аналитик проверил наличие соответствующих методов для интеграции систем, но не ознакомился детально с их описанием. Вследствие чего могут быть получены проблемы: получение необходимых данных для работы системы, разные ожидаемые статусные модели для сущностей и подобные.
⛔Аналитик не проводил базовое тестирование API (если такая возможность была, например с SOAP, REST, GraphQL это возможно, Postman наш друг).
⛔Не учтены нефункциональные требования, которые помешают реализации бизнес-процесса. Например, ограничение на количество запросов в минуту.
Продолжение 👇
👍13❤5🔥2🤩1
⚠️ Ограничения на платные-бесплатные возможности API, которые не были учтены на этапе сбора и анализа требований, могут привести к дополнительным расходам для заказчика, что не говорит о нереализуемости, но говорит о финансовых вопросах, которые придется решать.
Хотя в последовательности шагов по проектирования интеграции на первом месте у меня стоит этап сбора и анализа требований, результат работы с ним будет уточнен и дополнен на этапе ▫️3 “Анализ API-документации” и ▫️4 “Тестирование API”.
Поэтому системные аналитики важны в проекте: они своевременно, на ранних этапах, могут провести анализ интеграционной API-документации, проверить реализуемость всех требований, и принять решения об обходных путях или отказе от взаимодействия с определенными системами.
Это обходное решение будет принято до момента подписания договора на разработку ПО, что сэкономит много нервов, сил и денег для всех сторон в бизнесе 🙏
Продолжаем работу над интеграцией для GetDelivery. На этапе 2 нужно спроектировать и описать:
☑️ Бизнес-цель разработки интеграции.
☑️ Бизнес-задачи интеграции.
☑️ Бизнес-требования.
☑️ Функциональные требования.
☑️ Нефункциональные требования.
☑️ Разработка верхнеуровневой схемы архитектуры.
Хотя в последовательности шагов по проектирования интеграции на первом месте у меня стоит этап сбора и анализа требований, результат работы с ним будет уточнен и дополнен на этапе ▫️3 “Анализ API-документации” и ▫️4 “Тестирование API”.
Поэтому системные аналитики важны в проекте: они своевременно, на ранних этапах, могут провести анализ интеграционной API-документации, проверить реализуемость всех требований, и принять решения об обходных путях или отказе от взаимодействия с определенными системами.
Это обходное решение будет принято до момента подписания договора на разработку ПО, что сэкономит много нервов, сил и денег для всех сторон в бизнесе 🙏
Продолжаем работу над интеграцией для GetDelivery. На этапе 2 нужно спроектировать и описать:
☑️ Бизнес-цель разработки интеграции.
☑️ Бизнес-задачи интеграции.
☑️ Бизнес-требования.
☑️ Функциональные требования.
☑️ Нефункциональные требования.
☑️ Разработка верхнеуровневой схемы архитектуры.
👍9
🤍 Где всё получается, там есть “Всё получится” 🤍
Моя жизнь – постоянный процесс принятия новых вызовов. Каждый этап карьерного роста требует от меня постоянного обучения и погружения в самые разные технические детали. Но мой рост был бы невозможен без поддержки.
Раньше в карьере я полагалась на наставничество и мотивацию от руководителей, которые всегда говорили: "Всё получится! Если что, не бойся и спрашивай! Обсудим вместе!". Они создавали для меня доверительную атмосферу, где я могла ошибаться и не бояться, где я уверенно спрашивала совета не боялась, что начальник посчитает меня тупой и уволит.
Теперь, когда я сама руководитель, эту роль поддержки взяла на себя моя команда. Мы вместе обсуждаем проблемы и находим решения, создаем среду взаимоподдержки и вдохновения.
Поддержка близких в карьерном росте тоже играет важную роль. Недавно, после перегруженных дней с минимумом количества сна, я чувствовала себя абсолютно истощенной. Много задач, ошибки, много всего происходит, на что я не могу влиять. В голове: “Я сдаюсь… У меня ничего не получается". И в тот момент я получила очень важные и нужные слова поддержки от близкого человека: "Ты уже столько сделала! Смотри, ты переехала сюда совсем одна, строишь бизнес, у тебя международный проект.... Ты чего? Все хорошо будет. Иди отдохни и завтра в новый день. Всё получится. Ведь уже столько получилось! Ты очень умная, ты со всем справишься!".
Эти просто слова, но они важные и нужные. Они что-то переключают в голове Это слова наполнили меня новой энергией и верой в себя. Они напомнили мне, что, несмотря на все трудности, я не одна и что мои достижения – это результат усилий не только моих, но и тех, кто меня поддерживает.
В процессе роста и развития поддержка окружающих – это ключевой фактор успеха. Она дает силы двигаться вперед и напоминает, что даже самые большие препятствия можно преодолеть, когда рядом есть люди, которые верят в тебя.
Всё получится, ты же уже молодец, смотри сколько всего сделал! Дальше тоже всё будет ещё лучше! Я в тебя верю 🤍
Моя жизнь – постоянный процесс принятия новых вызовов. Каждый этап карьерного роста требует от меня постоянного обучения и погружения в самые разные технические детали. Но мой рост был бы невозможен без поддержки.
Раньше в карьере я полагалась на наставничество и мотивацию от руководителей, которые всегда говорили: "Всё получится! Если что, не бойся и спрашивай! Обсудим вместе!". Они создавали для меня доверительную атмосферу, где я могла ошибаться и не бояться, где я уверенно спрашивала совета не боялась, что начальник посчитает меня тупой и уволит.
Теперь, когда я сама руководитель, эту роль поддержки взяла на себя моя команда. Мы вместе обсуждаем проблемы и находим решения, создаем среду взаимоподдержки и вдохновения.
Поддержка близких в карьерном росте тоже играет важную роль. Недавно, после перегруженных дней с минимумом количества сна, я чувствовала себя абсолютно истощенной. Много задач, ошибки, много всего происходит, на что я не могу влиять. В голове: “Я сдаюсь… У меня ничего не получается". И в тот момент я получила очень важные и нужные слова поддержки от близкого человека: "Ты уже столько сделала! Смотри, ты переехала сюда совсем одна, строишь бизнес, у тебя международный проект.... Ты чего? Все хорошо будет. Иди отдохни и завтра в новый день. Всё получится. Ведь уже столько получилось! Ты очень умная, ты со всем справишься!".
Эти просто слова, но они важные и нужные. Они что-то переключают в голове Это слова наполнили меня новой энергией и верой в себя. Они напомнили мне, что, несмотря на все трудности, я не одна и что мои достижения – это результат усилий не только моих, но и тех, кто меня поддерживает.
В процессе роста и развития поддержка окружающих – это ключевой фактор успеха. Она дает силы двигаться вперед и напоминает, что даже самые большие препятствия можно преодолеть, когда рядом есть люди, которые верят в тебя.
Всё получится, ты же уже молодец, смотри сколько всего сделал! Дальше тоже всё будет ещё лучше! Я в тебя верю 🤍
❤27🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Всем крутого воскресенья!
🌟 Отдыхаем и набираемся сил,
🌟 Досматриваем вебинар про карьеру системного аналитика и собеседования,
🌟 Готовимся к воркшопу по ChatGPT,
и собираем хорошее настроение! 😉😄
🌟 Отдыхаем и набираемся сил,
🌟 Досматриваем вебинар про карьеру системного аналитика и собеседования,
🌟 Готовимся к воркшопу по ChatGPT,
и собираем хорошее настроение! 😉😄
😁11❤4💯3🔥1
Привет, коллеги! Продолжаем разбирать интеграционный проект GetDelivery.
▫️Этап 2 проектирования Интеграций. Сбор и анализ требований▫️
✅ Цель интеграции:
Разработать и запустить логистический сервис-агрегатор GetDelivery, предоставляющий пользователям удобный доступ к актуальной информации о стоимости и условиях отправления посылки через различные компании доставки (Деловые Линии, СДЭК, Возовоз).
Сервис должен упростить процесс выбора наиболее выгодного предложения по перевозке посылки, а также предоставлять возможность оформления заказа внутри GetDelivery, чтобы владелец сервиса получал комиссию за каждый оформленный через него заказ.
✅ Задачи интеграции:
✔️ Обеспечить возможность задания параметров груза для расчета стоимости его доставки.
✔️ Реализовать интеграцию с сервисами доставки для получения актуальных условий перевозки и выбора сервиса с наиболее выгодными.
- Деловые Линии,
- СДЭК,
- Возовоз.
✔️ Реализовать интеграцию с сервисами доставки для оформления сервисов заказов через них.
✔️ Уведомлять клиентов об обновлении статусов заказов, оформленных через GetDelivery.
✔️ Формировать для владельца GetDelivery отчетность по полученным выплатам за оплаченные заказы.
✔️ Формировать для владельца GetDelivery аналитику - % пользователей, которые выполнили поиск и оплатили заказ с использованием GetDelivery (= кол-во пользователей оформивших заказы и оплативших их / кол-во выполнявших поиски).
И вот на этом моменте я пошла изучать API-документацию.
Всё ли возможно реализовать технически? И если да, то как?
▫️Этап 2 проектирования Интеграций. Сбор и анализ требований▫️
✅ Цель интеграции:
Разработать и запустить логистический сервис-агрегатор GetDelivery, предоставляющий пользователям удобный доступ к актуальной информации о стоимости и условиях отправления посылки через различные компании доставки (Деловые Линии, СДЭК, Возовоз).
Сервис должен упростить процесс выбора наиболее выгодного предложения по перевозке посылки, а также предоставлять возможность оформления заказа внутри GetDelivery, чтобы владелец сервиса получал комиссию за каждый оформленный через него заказ.
✅ Задачи интеграции:
✔️ Обеспечить возможность задания параметров груза для расчета стоимости его доставки.
✔️ Реализовать интеграцию с сервисами доставки для получения актуальных условий перевозки и выбора сервиса с наиболее выгодными.
- Деловые Линии,
- СДЭК,
- Возовоз.
✔️ Реализовать интеграцию с сервисами доставки для оформления сервисов заказов через них.
✔️ Уведомлять клиентов об обновлении статусов заказов, оформленных через GetDelivery.
✔️ Формировать для владельца GetDelivery отчетность по полученным выплатам за оплаченные заказы.
✔️ Формировать для владельца GetDelivery аналитику - % пользователей, которые выполнили поиск и оплатили заказ с использованием GetDelivery (= кол-во пользователей оформивших заказы и оплативших их / кол-во выполнявших поиски).
И вот на этом моменте я пошла изучать API-документацию.
Всё ли возможно реализовать технически? И если да, то как?
👍10❤3❤🔥2🥰1
🤖 Что ждать от ChatGPT 4.0 системным аналитикам? 🤖
ChatGPT предоставляет системным аналитикам много возможностей, которые помогают лучше работать с данными и проектировать системы, значительно повышая эффективность и сокращая время работы.
Я часто повторяю, что ChatGPT это ваш личный ассистент - младший системный аналитик, который помогает! Хоть иногда и с ошибками. На всех программах обучения с этого года я демонстрирую команды, которые можно использовать в работе.
С учетом новых возможностей ChatGPT 4.0, которые позволяют анализировать актуальные данные из Интернета, а не как в предыдущих версиях только до 2021 года, вот как можно применить его в своей работе:
🤖 Анализ API - документации и описание маппингов данных для интеграций
ChatGPT 4.0 принимает к анализу ссылки на веб-страницы. Теперь всю интерактивную API-документацию можно отправить к нему на анализ. Для нашего проекта GetDelivery можно смело проводить анализ API Деловых Линий, СДЭКа и Возовоза, т.к. мы получили на вход ссылки на их API.
🤖 Генерация требований к системе
Одним из основных аспектов работы системного аналитика является определение и документирование требований к создаваемой системе. ChatGPT 4.0 может помочь в этом процессе, предоставляя подробные и точные ответы на запросы.
Например, если вы хотите узнать, как пользователь будет взаимодействовать с системой, он может запросить у ChatGPT описание этого взаимодействия.
🤖 Помощь в моделировании процессов
Аналитик может использовать ChatGPT для генерации идей по описанию новых и улучшению существующих бизнес-процессов.
Например, ChatGPT может помочь описать процесс оформления перевозки грузов, и при необходимости дополнить его API-методами, если оформление перевозки надо делать во внешней системе.
🤖 Поддержка в написании технической документации
ChatGPT может помочь в создании шаблонов документации, в их наполнении, в разработке руководств пользователя, ТЗ и других видов документов, ускоряя процесс документирования.
Что ещё? 👇
ChatGPT предоставляет системным аналитикам много возможностей, которые помогают лучше работать с данными и проектировать системы, значительно повышая эффективность и сокращая время работы.
Я часто повторяю, что ChatGPT это ваш личный ассистент - младший системный аналитик, который помогает! Хоть иногда и с ошибками. На всех программах обучения с этого года я демонстрирую команды, которые можно использовать в работе.
С учетом новых возможностей ChatGPT 4.0, которые позволяют анализировать актуальные данные из Интернета, а не как в предыдущих версиях только до 2021 года, вот как можно применить его в своей работе:
🤖 Анализ API - документации и описание маппингов данных для интеграций
ChatGPT 4.0 принимает к анализу ссылки на веб-страницы. Теперь всю интерактивную API-документацию можно отправить к нему на анализ. Для нашего проекта GetDelivery можно смело проводить анализ API Деловых Линий, СДЭКа и Возовоза, т.к. мы получили на вход ссылки на их API.
🤖 Генерация требований к системе
Одним из основных аспектов работы системного аналитика является определение и документирование требований к создаваемой системе. ChatGPT 4.0 может помочь в этом процессе, предоставляя подробные и точные ответы на запросы.
Например, если вы хотите узнать, как пользователь будет взаимодействовать с системой, он может запросить у ChatGPT описание этого взаимодействия.
🤖 Помощь в моделировании процессов
Аналитик может использовать ChatGPT для генерации идей по описанию новых и улучшению существующих бизнес-процессов.
Например, ChatGPT может помочь описать процесс оформления перевозки грузов, и при необходимости дополнить его API-методами, если оформление перевозки надо делать во внешней системе.
🤖 Поддержка в написании технической документации
ChatGPT может помочь в создании шаблонов документации, в их наполнении, в разработке руководств пользователя, ТЗ и других видов документов, ускоряя процесс документирования.
Что ещё? 👇
🍾5🔥4❤2👎2
👇 Что еще может ChatGPT 4.0?
🤖Интеграция с другими инструментами
ChatGPT 4.0 может быть интегрирован или использован с различными программными инструментами, включая Postman, Swagger, Confluence и другие.
Он может помогать в написании и проверке спецификаций OpenAPI для API, используя актуальные сведения о лучших практиках и стандартах. А также может писать автотесты на ваш API в Postman.
🤖 Улучшение коммуникаций
Теперь можно зачищать свой текст от сложной терминологии прибегая к помощи Искусственного Интеллекта (ИИ). Раньше приходилось вычитывать и править свои тексты вручную, теперь с этим помогает ChatGPT. Генерация понятных объяснений сложных технических концепций может помочь в коммуникации с не-техническими стейкхолдерами.
🤖 Поддержка в принятии решений
🤖 Обратная связь по работе системы и итеративное улучшение
🤖 Самостоятельное обучение и развитие навыков
🤖 Развитие технического английского
🤖 Голосовой набор текста с зачисткой от “шума” и правками по орфографии
Передовые IT-компании уже внедряют свои внутренние аналоги ChatGPT, чтобы сохранить конфиденциальность и безопасность данных внутри компании.
Яндекс запустил YandexGPT.
⚡ ИИ - новый инструмент IT-команд, который скоро станет обязательным навыком.
Еще не использовали ChatGPT или не знаете как применять? Пока не понимаете как внедрить его в работу, чтобы использовать эффективно?
На воркшопе передам справочник команд. Покажу ChatGPT и YandexGPT!
🤖 Лайфхаки ChatGPT для аналитиков на практике
⚡ 28 Ноября, ВТ | 19:00 (МСК)
🟢 ЗАПИСАТЬСЯ
Разработка требований. Проектирование БД. Создание UML, ER и BPMN диаграмм. Описание интеграционных сценариев. Шаблоны команд и шаблоны проектной документации.
Это тот самый знак, чтобы не откладывать на потом знакомство с ИИ и его самыми актуальными обновлениями 😎
🤖Интеграция с другими инструментами
ChatGPT 4.0 может быть интегрирован или использован с различными программными инструментами, включая Postman, Swagger, Confluence и другие.
Он может помогать в написании и проверке спецификаций OpenAPI для API, используя актуальные сведения о лучших практиках и стандартах. А также может писать автотесты на ваш API в Postman.
🤖 Улучшение коммуникаций
Теперь можно зачищать свой текст от сложной терминологии прибегая к помощи Искусственного Интеллекта (ИИ). Раньше приходилось вычитывать и править свои тексты вручную, теперь с этим помогает ChatGPT. Генерация понятных объяснений сложных технических концепций может помочь в коммуникации с не-техническими стейкхолдерами.
🤖 Поддержка в принятии решений
🤖 Обратная связь по работе системы и итеративное улучшение
🤖 Самостоятельное обучение и развитие навыков
🤖 Развитие технического английского
🤖 Голосовой набор текста с зачисткой от “шума” и правками по орфографии
Передовые IT-компании уже внедряют свои внутренние аналоги ChatGPT, чтобы сохранить конфиденциальность и безопасность данных внутри компании.
Яндекс запустил YandexGPT.
⚡ ИИ - новый инструмент IT-команд, который скоро станет обязательным навыком.
Еще не использовали ChatGPT или не знаете как применять? Пока не понимаете как внедрить его в работу, чтобы использовать эффективно?
На воркшопе передам справочник команд. Покажу ChatGPT и YandexGPT!
🤖 Лайфхаки ChatGPT для аналитиков на практике
⚡ 28 Ноября, ВТ | 19:00 (МСК)
🟢 ЗАПИСАТЬСЯ
Разработка требований. Проектирование БД. Создание UML, ER и BPMN диаграмм. Описание интеграционных сценариев. Шаблоны команд и шаблоны проектной документации.
Это тот самый знак, чтобы не откладывать на потом знакомство с ИИ и его самыми актуальными обновлениями 😎
👍7🎉1
😱 Требования не реализуемы. Тревога. Или? 😱
Я определила бизнес-цели и задачи GetDelivery. Но теперь надо разобраться с их реализуемостью. Это один из главных подвохов в работе с задачами на интеграцию.
Если кто-то сталкивался при разработке требований с термином “Бизнес-правила и ограничения”, то вот они в натуральном виде, только не про бизнес, а технические.
Я ознакомилась с API-документацией и сделала важные заметки для проекта.
✔️ Мы можем оформить заказ, но оплату доставки каждый сервис реализует по-разному.
✔️ Технически мы не имеем возможности менять статус оплаты заказа на доставку груза самостоятельно.
А значит подключить свою платежную систему типа ЮКасса, РайфПэй или подобное мы не можем. Давайте разбираться с тем, что есть.
В деталях:
🔹 Деловые Линии
Есть возможность проведения оплаты за заказ - метод Получение ссылки на оплату. Здесь все хорошо. Нужно будет только заглянуть глубже с точки зрения обновления статуса платежа за заказ и переключения экрана на клиенте. И обязательно уточнить, как будет учитываться вознаграждение за каждый сформированный на нашей стороне заказ.
Как я увидела из первичного знакомства - в методах API явно нигде не отображается комиссия. А значит получение комиссии за каждый заказ будет регулироваться договором сотрудничества с Деловыми Линиями. Что это для нас значит? Нужно будет сделать админку, через которую владелец GetDelivery сможет смотреть отчетность и в которой нужно будет запрограммировать правила выплат для нас от Деловых Линий.
Продолжение завтра👇
Я определила бизнес-цели и задачи GetDelivery. Но теперь надо разобраться с их реализуемостью. Это один из главных подвохов в работе с задачами на интеграцию.
Если кто-то сталкивался при разработке требований с термином “Бизнес-правила и ограничения”, то вот они в натуральном виде, только не про бизнес, а технические.
Я ознакомилась с API-документацией и сделала важные заметки для проекта.
✔️ Мы можем оформить заказ, но оплату доставки каждый сервис реализует по-разному.
✔️ Технически мы не имеем возможности менять статус оплаты заказа на доставку груза самостоятельно.
А значит подключить свою платежную систему типа ЮКасса, РайфПэй или подобное мы не можем. Давайте разбираться с тем, что есть.
В деталях:
🔹 Деловые Линии
Есть возможность проведения оплаты за заказ - метод Получение ссылки на оплату. Здесь все хорошо. Нужно будет только заглянуть глубже с точки зрения обновления статуса платежа за заказ и переключения экрана на клиенте. И обязательно уточнить, как будет учитываться вознаграждение за каждый сформированный на нашей стороне заказ.
Как я увидела из первичного знакомства - в методах API явно нигде не отображается комиссия. А значит получение комиссии за каждый заказ будет регулироваться договором сотрудничества с Деловыми Линиями. Что это для нас значит? Нужно будет сделать админку, через которую владелец GetDelivery сможет смотреть отчетность и в которой нужно будет запрограммировать правила выплат для нас от Деловых Линий.
Продолжение завтра👇
👍7❤5
🔹 СДЭК 👇
Тут сложнее. Создания платежа и проведения оплаты нет. Работают с квитанциями, наложенными платежами. Можно получить информацию по чеку, но получения ссылки на платежную форму не вижу по документаци.
Поэтому тут, прежде чем реализовывать интеграцию, я предлагаю пообщаться с отделом по партнерам СДЭК и уточнить у них условия вознаграждений за то, что мы привлекаем к ним клиентам. И как вообще платежи будут проводиться и учитываться?
Пока вижу расхождение с Деловыми линиями по платежам. Т.е. до момента создания заказа у нас сценарии одинаковые, а далее нужно думать как сделать единый сценарий. Это повлияет на бизнес-процесс реализации интеграции систем и вообще на бизнес системы-агрегатора GetDelivery. 🔺
Плюс я заметила методы про вызов курьера. Прям явно в требованиях ТЗ напишу, что для СДЭК это мы поддерживать не будем. А то мало ли?...
🔹 Возовоз
Привет JSON-ы и JavaScript примеры запросов для анализа. Возможность создания заказа есть. Возможность оплаты не вижу. Хотя на тестовом демо-сервере для разработчиков она есть.
Партнерские комиссии опять же могут регулироваться только бизнес-договором. И нужно сообщить заказчику о том, что информация по всем взаиморасчетам и учетам прибыли может быть только на нашей стороне. История повторяется.
Тут сложнее. Создания платежа и проведения оплаты нет. Работают с квитанциями, наложенными платежами. Можно получить информацию по чеку, но получения ссылки на платежную форму не вижу по документаци.
Поэтому тут, прежде чем реализовывать интеграцию, я предлагаю пообщаться с отделом по партнерам СДЭК и уточнить у них условия вознаграждений за то, что мы привлекаем к ним клиентам. И как вообще платежи будут проводиться и учитываться?
Пока вижу расхождение с Деловыми линиями по платежам. Т.е. до момента создания заказа у нас сценарии одинаковые, а далее нужно думать как сделать единый сценарий. Это повлияет на бизнес-процесс реализации интеграции систем и вообще на бизнес системы-агрегатора GetDelivery. 🔺
Плюс я заметила методы про вызов курьера. Прям явно в требованиях ТЗ напишу, что для СДЭК это мы поддерживать не будем. А то мало ли?...
🔹 Возовоз
Привет JSON-ы и JavaScript примеры запросов для анализа. Возможность создания заказа есть. Возможность оплаты не вижу. Хотя на тестовом демо-сервере для разработчиков она есть.
Партнерские комиссии опять же могут регулироваться только бизнес-договором. И нужно сообщить заказчику о том, что информация по всем взаиморасчетам и учетам прибыли может быть только на нашей стороне. История повторяется.
👍5❤2🥰1
Итог этапа анализа и сбора требований 🧐
Пока есть вопросы в части оплаты заказов и получения комиссий. Придется приложить больше усилий на этапе детального проектирования и по возможности заранее пообщаться с разработчиками внешних систем. Калькулятор стоимости доставки предоставляется во всех API.
Я, как системный аналитик, подготовлю отчет для заказчика с НЕтехническими вопросами, а лучше проведу очную встречу и расскажу об особенностях, с которыми я встретилась при техническом анализе.
Основные вопросы у меня бизнесовые - по соглашениям о комиссиях и ответственности за реальные деньги пользователей. Но эти вопросы возникли только после технического анализа.
P.S. Почему в этом проекте нужно строить единый сценарий на интеграцию всех систем? 🔺
У нас система-агрегатор. Это означает, что мы создаем единое окно для пользователей. И для систем агрегаторов порой важно выйти за пределы первичных требований и проанализировать больше подобных систем, чтобы быть готовыми к следующим дополнительным интеграциям, которые в будущем попросит заказчик.
P.P.S. А еще документацию на предмет уведомлений надо проанализировать: где вебхуки, где обновления статуса заказа и как это все внедрить в наш проект.
Пока есть вопросы в части оплаты заказов и получения комиссий. Придется приложить больше усилий на этапе детального проектирования и по возможности заранее пообщаться с разработчиками внешних систем. Калькулятор стоимости доставки предоставляется во всех API.
Я, как системный аналитик, подготовлю отчет для заказчика с НЕтехническими вопросами, а лучше проведу очную встречу и расскажу об особенностях, с которыми я встретилась при техническом анализе.
Основные вопросы у меня бизнесовые - по соглашениям о комиссиях и ответственности за реальные деньги пользователей. Но эти вопросы возникли только после технического анализа.
P.S. Почему в этом проекте нужно строить единый сценарий на интеграцию всех систем? 🔺
У нас система-агрегатор. Это означает, что мы создаем единое окно для пользователей. И для систем агрегаторов порой важно выйти за пределы первичных требований и проанализировать больше подобных систем, чтобы быть готовыми к следующим дополнительным интеграциям, которые в будущем попросит заказчик.
P.P.S. А еще документацию на предмет уведомлений надо проанализировать: где вебхуки, где обновления статуса заказа и как это все внедрить в наш проект.
👍6🔥2
Чтобы перейти к разработке схемы архитектуры GetDelivery, я должна сформулировать бизнес-требования, функциональные и нефункциональные требования?
Для работы мне достаточно описать основной бизнес-сценарий. Сделаю это я в формате Use Case.
Для примера беру сценарий расчета стоимости доставки. Описывать его буду на бизнес-уровне, без технических деталей, но с упоминанием всех внешних систем, с которыми предстоит интеграция. Часть с созданием заказов и уведомлениями не рассматриваю до открытого вебинара (это намек).
Помощник ChatGPT поможет мне с этим. Ускоряю работу 🙌 Я за ним сделала проверку сделала по логике, правки минимальные:
Название Use Case:
Проверка Стоимости Доставки в Сервисе GetDelivery
Предусловие:
Пользователь открыл веб-приложение GetDelivery и ему требуется информация о наиболее выгодных условиях и стоимости доставки его груза (посылки).
Роли:
- Пользователь: Клиент GetDelivery, который ищет информацию о наиболее выгодной стоимости и условиях доставки. Может быть как с авторизацией в GetDelivery, так и без неё.
Приложения и сервисы GetDelivery:
- Веб-приложение - PWA приложение, адаптированное под мобильные устройства;
- Интеграционный сервис Backend сравнения стоимости: собирает данные из разных внешних систем доставки, предоставляет сравнительную информацию и выделяет наиболее выгодную.
Внешние системы:
- Деловые Линии,
- СДЭК,
- Возовоз.
Входные Данные:
- Параметры доставки (адрес отправки, адрес доставки, вес, объем и т.п.).
- Предпочтения пользователя (скорость доставки, стоимость, дополнительные услуги).
* В реализации UI и логики рекомендуется предусмотреть как можно больше подсказок по автозаполнению на этапе ввода, чтобы повысить удобство работы пользователя с GrtDelivery и добавить ценность.
Ожидаемый Результат:
Пользователь получает сравнительную информацию о стоимости доставки от различных сервисов доставки, полученную по API и обработанную соответствующим интеграционным сервисом Backend GetDelivery.
Основной сценарий скоро появится 👀
🔽🔽🔽
Для работы мне достаточно описать основной бизнес-сценарий. Сделаю это я в формате Use Case.
Для примера беру сценарий расчета стоимости доставки. Описывать его буду на бизнес-уровне, без технических деталей, но с упоминанием всех внешних систем, с которыми предстоит интеграция. Часть с созданием заказов и уведомлениями не рассматриваю до открытого вебинара (это намек).
Помощник ChatGPT поможет мне с этим. Ускоряю работу 🙌 Я за ним сделала проверку сделала по логике, правки минимальные:
Название Use Case:
Проверка Стоимости Доставки в Сервисе GetDelivery
Предусловие:
Пользователь открыл веб-приложение GetDelivery и ему требуется информация о наиболее выгодных условиях и стоимости доставки его груза (посылки).
Роли:
- Пользователь: Клиент GetDelivery, который ищет информацию о наиболее выгодной стоимости и условиях доставки. Может быть как с авторизацией в GetDelivery, так и без неё.
Приложения и сервисы GetDelivery:
- Веб-приложение - PWA приложение, адаптированное под мобильные устройства;
- Интеграционный сервис Backend сравнения стоимости: собирает данные из разных внешних систем доставки, предоставляет сравнительную информацию и выделяет наиболее выгодную.
Внешние системы:
- Деловые Линии,
- СДЭК,
- Возовоз.
Входные Данные:
- Параметры доставки (адрес отправки, адрес доставки, вес, объем и т.п.).
- Предпочтения пользователя (скорость доставки, стоимость, дополнительные услуги).
* В реализации UI и логики рекомендуется предусмотреть как можно больше подсказок по автозаполнению на этапе ввода, чтобы повысить удобство работы пользователя с GrtDelivery и добавить ценность.
Ожидаемый Результат:
Пользователь получает сравнительную информацию о стоимости доставки от различных сервисов доставки, полученную по API и обработанную соответствующим интеграционным сервисом Backend GetDelivery.
Основной сценарий скоро появится 👀
🔽🔽🔽
👍8❤4👀3👎1
Основной Сценарий:
1. Пользователь вводит данные для расчета стоимости доставки в веб-приложении GetDelivery и инициирует расчет стоимости доставки.
2. Система GetDelivery отправляет запросы к API Деловых Линий, СДЭК, Возовоз для расчета актуальной стоимости доставки.
3. Полученные данные собираются и обрабатываются в GetDelivery.
Выполняется сравнение условий для выбора наиболее выгодного предложения, которое отобразится для пользователя.
4. Пользователю в веб-приложении отображается список результатов расчета стоимости перевозки груза на разных условиях и на разных тарифах - список предложений.
5. Пользователь может выбрать предпочтительный вариант в списке предложений, посмотреть его подробности и перейти к оформлению заказа в соответствующем сервисе доставки (Деловые Линии, СДЭК или Возовоз).
—--------
Альтернативные сценарии и обработка ошибок:
** Это раздел на котором стоит сфокусироваться в процессе работы с интеграционными задачами.
1А. Некорректные входные данные:
Если пользователь вводит некорректные или неполные данные, система запрашивает уточнение или коррекцию данных.
2А. Отсутствие ответа от API внешней системы:
Если один из сервисов не отвечает, система сообщает об этом пользователю и предоставляет данные от доступных сервисов.
2B. Ошибка авторизации в API внешней системы:
Необходимо повторить попытку, если она неуспешна, то…. . Это уже технические детали пошли. И они важны! Но позже 🙂
Основной сценарий работы системы описан. Про оформление доставки тоже примерно понимаем как это должно работать, и, если что, будем уточнять в процессе проектирования.
Можно переходить к разработке верхнеуровневой схемы архитектуры! 🛠❤️
1. Пользователь вводит данные для расчета стоимости доставки в веб-приложении GetDelivery и инициирует расчет стоимости доставки.
2. Система GetDelivery отправляет запросы к API Деловых Линий, СДЭК, Возовоз для расчета актуальной стоимости доставки.
3. Полученные данные собираются и обрабатываются в GetDelivery.
Выполняется сравнение условий для выбора наиболее выгодного предложения, которое отобразится для пользователя.
4. Пользователю в веб-приложении отображается список результатов расчета стоимости перевозки груза на разных условиях и на разных тарифах - список предложений.
5. Пользователь может выбрать предпочтительный вариант в списке предложений, посмотреть его подробности и перейти к оформлению заказа в соответствующем сервисе доставки (Деловые Линии, СДЭК или Возовоз).
—--------
Альтернативные сценарии и обработка ошибок:
** Это раздел на котором стоит сфокусироваться в процессе работы с интеграционными задачами.
1А. Некорректные входные данные:
Если пользователь вводит некорректные или неполные данные, система запрашивает уточнение или коррекцию данных.
2А. Отсутствие ответа от API внешней системы:
Если один из сервисов не отвечает, система сообщает об этом пользователю и предоставляет данные от доступных сервисов.
2B. Ошибка авторизации в API внешней системы:
Необходимо повторить попытку, если она неуспешна, то…. . Это уже технические детали пошли. И они важны! Но позже 🙂
Основной сценарий работы системы описан. Про оформление доставки тоже примерно понимаем как это должно работать, и, если что, будем уточнять в процессе проектирования.
Можно переходить к разработке верхнеуровневой схемы архитектуры! 🛠❤️
👍7❤1👎1
📋 О важности планирования
Новый год скоро. Планируете что-то?
С тех пор как я начала работать в IT, я всегда планировала, как проведу Новый год. Работа системным аналитиком много принесла в мою жизнь, в частности: системность и путешествия.
С началом работы в IT я начала много путешествовать и исполнять свое детское желание - смотреть на мир. Вспоминаю один из первых годов, когда дала себе обещание: всегда встречать Новый год за границей, и желательно в теплых краях.
И далее каждый год, даже во времена пандемии, мне удавалось это сделать. Ранняя покупка билетов на самолет, бронирование отелей, план посещения красивых мест и встречи 00:00 – все это было частью моих последних Новых годов.
И вот что поняла в прошлом году:
Если плана на Новогоднюю ночь нет, то ничего не происходит 😂
Удивительно? Нет.
В прошлом году плана не было. Я до последнего не знала, как буду праздновать. И в итоге Новый год прошел дома, организованный в последний момент. Ну хоть в теплых краях, с прогулкой у океана. Так случилось из-за большого количества переживаний и перемен, я посвятила ту Новогоднюю ночь осознанию что произошло за один год.
И вот, в этом году Новый год уже спланирован! Ура! Интересно, как все пройдет! Это будет интересное путешествие, несколько городов, и начнётся оно уже совсем скоро. Кажется, что каждый день расписан, каждый день есть планы, даже запасные. Я чувствую спокойствие и уверенность. Всё будет вау!
Наши цели – это наши желания. Хотите получать желаемое? Формулируйте цели четко и стройте планы. Системный анализ помогает 🙂Мечтайте и действуйте! Зима и Новый год – отличный повод начать ❤️
Новый год скоро. Планируете что-то?
С тех пор как я начала работать в IT, я всегда планировала, как проведу Новый год. Работа системным аналитиком много принесла в мою жизнь, в частности: системность и путешествия.
С началом работы в IT я начала много путешествовать и исполнять свое детское желание - смотреть на мир. Вспоминаю один из первых годов, когда дала себе обещание: всегда встречать Новый год за границей, и желательно в теплых краях.
И далее каждый год, даже во времена пандемии, мне удавалось это сделать. Ранняя покупка билетов на самолет, бронирование отелей, план посещения красивых мест и встречи 00:00 – все это было частью моих последних Новых годов.
И вот что поняла в прошлом году:
Если плана на Новогоднюю ночь нет, то ничего не происходит 😂
Удивительно? Нет.
В прошлом году плана не было. Я до последнего не знала, как буду праздновать. И в итоге Новый год прошел дома, организованный в последний момент. Ну хоть в теплых краях, с прогулкой у океана. Так случилось из-за большого количества переживаний и перемен, я посвятила ту Новогоднюю ночь осознанию что произошло за один год.
И вот, в этом году Новый год уже спланирован! Ура! Интересно, как все пройдет! Это будет интересное путешествие, несколько городов, и начнётся оно уже совсем скоро. Кажется, что каждый день расписан, каждый день есть планы, даже запасные. Я чувствую спокойствие и уверенность. Всё будет вау!
Наши цели – это наши желания. Хотите получать желаемое? Формулируйте цели четко и стройте планы. Системный анализ помогает 🙂Мечтайте и действуйте! Зима и Новый год – отличный повод начать ❤️
🔥15❤8👍6👎2
🛠 Use Case для Интеграций: в чем отличия от обычных задач? 🛠 Пока не ушли дальше, хочется напомнить.
Когда мы говорим об интеграциях, то основное отличие для аналитиков от обычных задач начинается при разработке функциональных требований, когда мы описываем сценарии работы пользователей и функциональные возможности системы.
Функциональные требования определяют, ЧТО система должна делать.
Это описания возможностей или характеристик системы, которые влияют на ее поведение.
Пример: "Система должна предоставлять возможность пользователям задавать адреса отправления и получения груза с использованием справочника адресов".
Use Case (или сценарий использования) описывает, КАК эти функциональные требования реализуются, какой последовательностью шагов в рамках взаимодействия пользователя с системой.
Это не просто функция или действие, а некий "рассказ" о том, как система и пользователь совместно решают задачу.
Пример: Сценарий поиска наиболее выгодного варианта перевозки груза “Проверка Стоимости Доставки в Сервисе GetDelivery” с обращением во внешние системы Деловые Линии, СДЭК и Возовоз.
Что такое интеграционный Use Case?
В контексте интеграционных Use Cases рассматриваются ситуации, когда наша система взаимодействует не только с пользователями, но и с другими системами.
Например, в сценарии, где пользователь оформляет заказ в онлайн-сервисе доставки, этот заказ может передаваться в систему управления заказами для обработки или в финансовую систему для ведения учета.
В заключении:
Use Case описывает поведение системы:
🔸 в ответ на действия конкретного пользователя - обычные Use Cases,
🔸 при взаимодействии с внешней системой - интеграционные Use Cases.
Когда мы говорим об интеграциях, то основное отличие для аналитиков от обычных задач начинается при разработке функциональных требований, когда мы описываем сценарии работы пользователей и функциональные возможности системы.
Функциональные требования определяют, ЧТО система должна делать.
Это описания возможностей или характеристик системы, которые влияют на ее поведение.
Пример: "Система должна предоставлять возможность пользователям задавать адреса отправления и получения груза с использованием справочника адресов".
Use Case (или сценарий использования) описывает, КАК эти функциональные требования реализуются, какой последовательностью шагов в рамках взаимодействия пользователя с системой.
Это не просто функция или действие, а некий "рассказ" о том, как система и пользователь совместно решают задачу.
Пример: Сценарий поиска наиболее выгодного варианта перевозки груза “Проверка Стоимости Доставки в Сервисе GetDelivery” с обращением во внешние системы Деловые Линии, СДЭК и Возовоз.
Что такое интеграционный Use Case?
В контексте интеграционных Use Cases рассматриваются ситуации, когда наша система взаимодействует не только с пользователями, но и с другими системами.
Например, в сценарии, где пользователь оформляет заказ в онлайн-сервисе доставки, этот заказ может передаваться в систему управления заказами для обработки или в финансовую систему для ведения учета.
В заключении:
Use Case описывает поведение системы:
🔸 в ответ на действия конкретного пользователя - обычные Use Cases,
🔸 при взаимодействии с внешней системой - интеграционные Use Cases.
👍5🔥3👎1
В сценарии интеграций всегда есть минимум два участника. А вообще больше:
🔹Наша система (Backend) - которая отвечает за работу сценария Use Case, реализует его логику. Основная часть интеграций в проектах обычно реализуется на бэкенде.
В нашем проекте Backend GetDelivery будет:
- реализовывать логику приема и проверки данных, которые ввел пользователь, чтобы получить выгодную стоимость доставки,
- отвечать за логику вызова внешних систем - СДЭК, Деловые Линии и Возовоз,
- и обработку результатов, получаемых от них.
Также важно понимать, что и к нам могут интегрироваться, к нашему Backend. В GetDelivery это будут делать как минимум наши веб- и мобильные приложения. Для этого мы разрабатываем на сервере программные интерфейсы - API (например REST API, SOAP API, GraphQL или другие).
🔹Внешняя система - с которой мы интегрируемся, к которой делаем запросы. Важно понимать, что внешние системы в процессе интеграции могут быть как внутри одного проекта, так и за пределами - разработаны другими разработчиками, в других компаниях.
В проекте GetDelivery это системы доставки СДЭК, Деловые Линии и Возовоз.
А можно сделать распределенную архитектуру проекта и сказать, что наш сервис управления данными о пользователях будет взаимодействовать с нашим же интеграционным сервисом для расчета стоимости доставки.
Это взаимодействие = внутренняя Интеграция.
Т.к. например, сервис пользователей - основной в интеграционном Use Case для получения истории запросов пользователя, а сервис расчета стоимости может быть внешней системой по отношению к нему. Зависит от контекста.
🔹Наша система (Frontend) - мобильные приложения, веб-приложения и другие клиенты, которые могут обращаться по интеграционному API к нашему серверу за данными или для их обработки.
🔹Пользователи, которые запускают интеграционные процессы в системе.
🔹Наша система (Backend) - которая отвечает за работу сценария Use Case, реализует его логику. Основная часть интеграций в проектах обычно реализуется на бэкенде.
В нашем проекте Backend GetDelivery будет:
- реализовывать логику приема и проверки данных, которые ввел пользователь, чтобы получить выгодную стоимость доставки,
- отвечать за логику вызова внешних систем - СДЭК, Деловые Линии и Возовоз,
- и обработку результатов, получаемых от них.
Также важно понимать, что и к нам могут интегрироваться, к нашему Backend. В GetDelivery это будут делать как минимум наши веб- и мобильные приложения. Для этого мы разрабатываем на сервере программные интерфейсы - API (например REST API, SOAP API, GraphQL или другие).
🔹Внешняя система - с которой мы интегрируемся, к которой делаем запросы. Важно понимать, что внешние системы в процессе интеграции могут быть как внутри одного проекта, так и за пределами - разработаны другими разработчиками, в других компаниях.
В проекте GetDelivery это системы доставки СДЭК, Деловые Линии и Возовоз.
А можно сделать распределенную архитектуру проекта и сказать, что наш сервис управления данными о пользователях будет взаимодействовать с нашим же интеграционным сервисом для расчета стоимости доставки.
Это взаимодействие = внутренняя Интеграция.
Т.к. например, сервис пользователей - основной в интеграционном Use Case для получения истории запросов пользователя, а сервис расчета стоимости может быть внешней системой по отношению к нему. Зависит от контекста.
🔹Наша система (Frontend) - мобильные приложения, веб-приложения и другие клиенты, которые могут обращаться по интеграционному API к нашему серверу за данными или для их обработки.
🔹Пользователи, которые запускают интеграционные процессы в системе.
❤6👍3
🔺Use Case: ОБЫЧНЫЕ vs ИНТЕГРАЦИИ 🔺
Расскажу про отличия по пунктам шаблона Use Case.
-----------------------
ℹ️ Предусловие:
Отличий нет. Просто описываем что инициирует запуск сценария.
ℹ️ Роли пользователей:
Здесь могут отсутствовать пользователи, т.к. сценарий может запускаться автоматически, например, по расписанию. Но и в обычных сценариях это тоже допустимо.
ℹ️ Приложения и сервисы:
Здесь перечисляются наши приложения, системы и подсистемы, а также внешние системы, с которыми выполняется интеграция. Для внешних систем рекомендуется дать ссылку на их API-документацию.
ℹ️ Входные данные:
Здесь может быть ситуация, когда входные данные надо получать из внешней системы и сценарий начинается с обращения к ней. В это случае лучше текстом прописать какие данные и откуда получить.
ℹ️ Результат:
Отличий нет, кроме того, что итоговые данные могут быть получены из внешней системы.
ℹ️ Основной сценарий:
1. В шагах сценария указываются конкретные системы и API методы, которые отвечают за его выполнение.
При работе с интеграциями важно четко понимать, какие данные и функции доступны через API. От этого зависит, какие функции мы можем реализовать внутри Use Case.
2. Важно различать синхронное и асинхронное выполнение задач.
3. Аналитик должен понимать, как последовательно происходит исполнение задачи подсистемами (сервисами / микросервисами) проекта и внешними системами.
Описание “выполняется получение самой выгодной цены внешними сервисами” не подойдёт - слишком открытая формулировка, за которой нет конкретного решения.
4. Внешние системы могут иметь свои ограничения. Например, если их API предоставляет меньше данных, чем нам нужно, это может стать проблемой. Наоборот, если внешняя система предоставляет слишком много информации, нам придется отбирать только необходимую.
Для этого системные аналитики описывают маппинги данных к Use Case.
ℹ️ Обработка ошибок и альтернативные сценарии:
1A. Нужно учитывать что в любой момент любая внешняя система может оказаться недоступна.
1B. Обрабатывать потерю технической авторизации с внешней системой, которая не видна пользователю и восстанавливается автоматически стандартным методом ре-авторизации.
2A. Обрабатывать задержки в ответах на запросы и ошибки по тайм-ауту.
...
-----------------------
Умение видеть и выделять интеграционные Use Cases помогает заранее поставить себе в планы на аналитику четкий объем задач, избежать проблем с оценкой времени и проблем реализации разработчиками (куча вопросов после передачи требований).
Интеграции — это не просто "еще одна задача". Это серьезная работа по анализу взаимосвязей БД + Функций + UI/UX + API нашей и внешних систем, который требует нашего опыта, внимания и профессионализма 🙌 Поэтому важно уметь определять и разрабатывать требования к интеграционным Use Case.
Расскажу про отличия по пунктам шаблона Use Case.
-----------------------
ℹ️ Предусловие:
Отличий нет. Просто описываем что инициирует запуск сценария.
ℹ️ Роли пользователей:
Здесь могут отсутствовать пользователи, т.к. сценарий может запускаться автоматически, например, по расписанию. Но и в обычных сценариях это тоже допустимо.
ℹ️ Приложения и сервисы:
Здесь перечисляются наши приложения, системы и подсистемы, а также внешние системы, с которыми выполняется интеграция. Для внешних систем рекомендуется дать ссылку на их API-документацию.
ℹ️ Входные данные:
Здесь может быть ситуация, когда входные данные надо получать из внешней системы и сценарий начинается с обращения к ней. В это случае лучше текстом прописать какие данные и откуда получить.
ℹ️ Результат:
Отличий нет, кроме того, что итоговые данные могут быть получены из внешней системы.
ℹ️ Основной сценарий:
1. В шагах сценария указываются конкретные системы и API методы, которые отвечают за его выполнение.
При работе с интеграциями важно четко понимать, какие данные и функции доступны через API. От этого зависит, какие функции мы можем реализовать внутри Use Case.
2. Важно различать синхронное и асинхронное выполнение задач.
3. Аналитик должен понимать, как последовательно происходит исполнение задачи подсистемами (сервисами / микросервисами) проекта и внешними системами.
Описание “выполняется получение самой выгодной цены внешними сервисами” не подойдёт - слишком открытая формулировка, за которой нет конкретного решения.
4. Внешние системы могут иметь свои ограничения. Например, если их API предоставляет меньше данных, чем нам нужно, это может стать проблемой. Наоборот, если внешняя система предоставляет слишком много информации, нам придется отбирать только необходимую.
Для этого системные аналитики описывают маппинги данных к Use Case.
ℹ️ Обработка ошибок и альтернативные сценарии:
1A. Нужно учитывать что в любой момент любая внешняя система может оказаться недоступна.
1B. Обрабатывать потерю технической авторизации с внешней системой, которая не видна пользователю и восстанавливается автоматически стандартным методом ре-авторизации.
2A. Обрабатывать задержки в ответах на запросы и ошибки по тайм-ауту.
...
-----------------------
Умение видеть и выделять интеграционные Use Cases помогает заранее поставить себе в планы на аналитику четкий объем задач, избежать проблем с оценкой времени и проблем реализации разработчиками (куча вопросов после передачи требований).
Интеграции — это не просто "еще одна задача". Это серьезная работа по анализу взаимосвязей БД + Функций + UI/UX + API нашей и внешних систем, который требует нашего опыта, внимания и профессионализма 🙌 Поэтому важно уметь определять и разрабатывать требования к интеграционным Use Case.
👍15👏2👎1
🗼 Поговорим про архитектуру 🗽
Архитектура информационных систем — это как чертежи для строительства дома. Она описывает, как разные части программы связаны между собой и как они работают вместе.
Архитектор зданий планирует размеры комнат и их расположение, количество этажей в доме, и соответствующий размер фундамента под него. Архитектор в IT определяет, где хранятся данные, где и как они обрабатываются, как различные части системы будут взаимодействовать друг с другом.
Различают основные подходы к проектированию архитектуры:
🔹 Монолитная архитектура: всё в одном месте - один большой модуль, нагрузка в одном месте, где вся системы.
🔹 Сервисно-ориентированная архитектура (SOA): система разделена на сервисы, каждый из которых выполняет определенную функцию и общается с другими через API.
🔹 Микросервисная архитектура: Подобна SOA, но сервисы меньше и более специализированы, часто работают независимо. Как правило у каждого микросервиса есть своя независимая БД.
🔹 Событийно-ориентированная архитектура (EDA): Фокусируется на обработке событий и асинхронной связи между компонентами.
🔹 Layered (Слоистая) архитектура: Разделяет систему на слои с определенными функциями, например, слой представления UI, слой бизнес-логики, слой данных. Хотя и монолитная архитектура может быть организована в слои, вся система обычно развертывается (релизится) как единое целое, в отличие от слоистой архитектуры, где отдельные слои могут быть более независимыми.
Я хочу познакомить вас с монолитами, SOA и MSA.
Архитектура информационных систем — это как чертежи для строительства дома. Она описывает, как разные части программы связаны между собой и как они работают вместе.
Архитектор зданий планирует размеры комнат и их расположение, количество этажей в доме, и соответствующий размер фундамента под него. Архитектор в IT определяет, где хранятся данные, где и как они обрабатываются, как различные части системы будут взаимодействовать друг с другом.
Различают основные подходы к проектированию архитектуры:
🔹 Монолитная архитектура: всё в одном месте - один большой модуль, нагрузка в одном месте, где вся системы.
🔹 Сервисно-ориентированная архитектура (SOA): система разделена на сервисы, каждый из которых выполняет определенную функцию и общается с другими через API.
🔹 Микросервисная архитектура: Подобна SOA, но сервисы меньше и более специализированы, часто работают независимо. Как правило у каждого микросервиса есть своя независимая БД.
🔹 Событийно-ориентированная архитектура (EDA): Фокусируется на обработке событий и асинхронной связи между компонентами.
🔹 Layered (Слоистая) архитектура: Разделяет систему на слои с определенными функциями, например, слой представления UI, слой бизнес-логики, слой данных. Хотя и монолитная архитектура может быть организована в слои, вся система обычно развертывается (релизится) как единое целое, в отличие от слоистой архитектуры, где отдельные слои могут быть более независимыми.
Я хочу познакомить вас с монолитами, SOA и MSA.
🔥21❤3👍2
Начнем с 🗽Монолитной архитектуры!
Монолитную архитектуру систем можно сравнить с одним большим зданием, где все комнаты (функции) находятся под одной крышей. Всё в одном пространстве без разделения на отдельные комнаты.
В такой архитектуре вся программа — это один большой блок, где все части тесно связаны и работают вместе. И если течет крыша и надо сделать ремонт, то будут задеты все помещения.
Монолитный подход к архитектуре был очень популярен на ранних этапах развития программирования, потому что он прост в создании и управлении. Он упрощает проект на старте разработки. Монолитные системы дешевые в разработке и запуске. До сих пор очень часто стартапы начинаются именно с монолитной архитектуры.
👆Важно помнить, если нужно что-то изменить в монолите, приходится работать со всей системой целиком. После доработки маленькой функции придётся обновлять всё приложение. Это приводит к “регламентным окнам” во время обновления, т.к. всё приложение перезапускается и становится временно недоступно пользователям.
➕ Плюсы:
+ Удобно для небольших приложений.
+ Дешево в реализации, не нужно привлекать высококвалифицированную и опытную команду. Остается идеальным решением для стартапов.
+ Просто для поддержки - всё в одном месте.
➖ Минусы:
- Если обновляем, то сразу всё - наличие регламентных окон при обновлении системы.
- При увеличении числа пользователей, масштабирование возможно только путём копирования монолита. Монолит требует много вычислительных ресурсов. Два монолита - ещё больше. Вместо того, чтобы наращивать ресурсы на отдельные части (отдельные популярные функциии), мы делаем копии монолита на серверах, чтобы иметь возможность обработать больше одновременных запросов пользователей.
- Все части сильно связаны друг с другом. При обновлении одной функции легко можно сломать несколько связанных. Систему тяжело развивать.
- Уязвимость - злоумышленник при взломе получит доступ сразу ко всей системе.
Успешные ИТ-проекты уходят от монолитной архитектуры, хотя могли именно с неё начать свой путь.
Монолитную архитектуру систем можно сравнить с одним большим зданием, где все комнаты (функции) находятся под одной крышей. Всё в одном пространстве без разделения на отдельные комнаты.
В такой архитектуре вся программа — это один большой блок, где все части тесно связаны и работают вместе. И если течет крыша и надо сделать ремонт, то будут задеты все помещения.
Монолитный подход к архитектуре был очень популярен на ранних этапах развития программирования, потому что он прост в создании и управлении. Он упрощает проект на старте разработки. Монолитные системы дешевые в разработке и запуске. До сих пор очень часто стартапы начинаются именно с монолитной архитектуры.
👆Важно помнить, если нужно что-то изменить в монолите, приходится работать со всей системой целиком. После доработки маленькой функции придётся обновлять всё приложение. Это приводит к “регламентным окнам” во время обновления, т.к. всё приложение перезапускается и становится временно недоступно пользователям.
➕ Плюсы:
+ Удобно для небольших приложений.
+ Дешево в реализации, не нужно привлекать высококвалифицированную и опытную команду. Остается идеальным решением для стартапов.
+ Просто для поддержки - всё в одном месте.
➖ Минусы:
- Если обновляем, то сразу всё - наличие регламентных окон при обновлении системы.
- При увеличении числа пользователей, масштабирование возможно только путём копирования монолита. Монолит требует много вычислительных ресурсов. Два монолита - ещё больше. Вместо того, чтобы наращивать ресурсы на отдельные части (отдельные популярные функциии), мы делаем копии монолита на серверах, чтобы иметь возможность обработать больше одновременных запросов пользователей.
- Все части сильно связаны друг с другом. При обновлении одной функции легко можно сломать несколько связанных. Систему тяжело развивать.
- Уязвимость - злоумышленник при взломе получит доступ сразу ко всей системе.
Успешные ИТ-проекты уходят от монолитной архитектуры, хотя могли именно с неё начать свой путь.
👍15
🗽 Монолитная архитектура
Если мы делаем GetDelivery в архитектуре монолита, то у нас будет такая картина:
🔺 Одна общая БД (хотя можно и несколько).
🔺 Вся логика, касающаяся регистрации и авторизации пользователей, расчета стоимости, платежей за заказы доставки или другие услуги будет в одном месте - на одном сервере. Если дорабатываем функцию создания заказа на доставку, то придется обновлять всё приложение.
🔺 Веб-приложение может быть сделано отдельно от бэкенда, а может быть неразрывно связано с ним.
🔺 У монолита может быть свой API для мобильных приложений.
Представим GetDelivery как монолит - бюджетный вариант реализации 😄
Если мы делаем GetDelivery в архитектуре монолита, то у нас будет такая картина:
🔺 Одна общая БД (хотя можно и несколько).
🔺 Вся логика, касающаяся регистрации и авторизации пользователей, расчета стоимости, платежей за заказы доставки или другие услуги будет в одном месте - на одном сервере. Если дорабатываем функцию создания заказа на доставку, то придется обновлять всё приложение.
🔺 Веб-приложение может быть сделано отдельно от бэкенда, а может быть неразрывно связано с ним.
🔺 У монолита может быть свой API для мобильных приложений.
Представим GetDelivery как монолит - бюджетный вариант реализации 😄
👍5❤4🔥3