GigaCode: как ИИ-ассистент упрощает жизнь системным аналитикам

от автора

Здравствуйте! Меня зовут Щедрин Николай, и я являюсь ведущим аналитиком продукта GigaCode от Сбер. Хочу поделиться с вами сценариями применения ИИ-ассистента в работе системного аналитика, которые использую сам. Надеюсь, статья позволит вам посмотреть на привычные вещи под другим углом и побудит поделиться своими мыслями, идеями и предложениями о применении ИИ-ассистентов в вашей профессиональной деятельности.

Если вы системный аналитик, эта статья — ваш must read. Остальным коллегам (разработчикам, архитекторам, владельцам продукта) будет полезно узнать, как ИИ-инструменты выходят за рамки генерации кода и помогают проектировать системы.

А ещё здесь есть мемы от Kandinsky — куда же без них?  

Бесконечная вселенная мемов

Бесконечная вселенная мемов
Как ИИ это придумывает?

Как ИИ это придумывает?

Немного о GigaCode (нескрытая реклама)

В конце 2023 года мы запустили первый разработанный в России ИИ-ассистент разработчика — GigaCode. За год он научился не только генерировать код, но и стал настоящим «швейцарским ножом» для команд: 30 миллионов принятых строк кода в режиме inline-подсказок, появился встроенный чат с ИИ-ассистентом (CodeChat — не путать с GigaChat) и поддержка новых сценариев (например, объяснение кода и создание документации).

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

Прежде всего, давайте определим основные роли, которые обычно присутствуют в стандартной команде по разработке ИТ-продукта. Совершенно очевидно, что в команде должен быть владелец продукта (ВП) или продукт-менеджер (ПM), нескольких разработчиков, архитектор, QA-инженер, системный аналитик (СА), специалист по DevOps и другие роли. Каждый член команды может выполнять одну роль или объединять в себе несколько функций. Хотя сценарии использования ассистента для разработчиков и специалистов по DevOps вполне очевидны, сценарии для системных аналитиков остаются не до конца ясными.

Системный аналитик и код: где пересекаются их пути? 

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

Примеры задач СА, где пригодится GigaCode:

  • работа с БД: от проектирования таблиц до миграций между СУБД; 

  • создание спецификаций для интеграций;

  • документирование через UML (Use Case, ER-диаграммы) с привязкой к коду через PlantUML.  

Схемы тоже будут

Схемы тоже будут

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

Задача: «Необходимо проработать процесс списания средств со счёта Клиента при подключении или автопродлении пакета услуг».

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

Перечень стейкхолдеров (GigaChat сгенерировал гораздо больший список, чем в примере ниже):

  1. Клиент (основной пользователь услуги, чьи средства списываются) — хочет безопасность и удобство.  

  2. Финансовый отдел (отвечает за управление финансами компании, контроль денежных потоков) — требует соблюдение нормативов.  

  3. ИТ-отдел (разрабатывает и поддерживает систему автоматизации процесса списания средств) — заботится о стабильности работы систем, надёжности интеграций.  

  4. Служба поддержки клиентов (обеспечивает техническую поддержку пользователей, решает возникающие проблемы) — заботится о высоком качестве клиентского сервиса.

  5. Банки (организации, через которые осуществляются денежные переводы) — минимум комиссий, максимум скорости.  

Попросим GigaChat сгенерировать пользовательскую историю клиента:

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

Контекст:  

— Клиент использует мобильное приложение или сайт для подключения к услугам.  

— Автоматическое списание средств должно происходить после успешного завершения процедуры подключения/автопродления

Основные этапы: Выбор услуги → проверка данных → оплата → уведомление.  

Цель: минимум действий, максимум прозрачности.  

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

Рассмотрим несколько сервисов, которые могут поддержать процесс, описанный выше:

  1. Веб-сайт/приложение — интерфейс для клиента.  

  2. Backend — обработка запросов и логика.  

  3. Сервис авторизации — управление учетными записями.  

  4. Платежный шлюз — проведение транзакций.  

  5. Сервис уведомлений — информирование пользователей.  

Рассмотрим гипотетически возможные сценарии взаимодействия сервисов на примере бэкенда:

Backend получает POST-запрос от сайта.

Backend проверяет данные → авторизует пользователя → создает заказ.

Backend передает данные в платежный сервис → отправляет уведомление.  

А почему бы и нет? Сценарий использования пиццей не испортишь.

А почему бы и нет? Сценарий использования пиццей не испортишь.

Попросим GigaCode через окно CodeChat сгенерировать скрипт в формате PlantUML-диаграммы последовательности для этого сценария. Ответ выглядит так:

@startuml actor "Веб-сайт" as website participant "Backend" as backend participant "Сервис авторизации" as auth participant "База данных" as db participant "Сервис обработки платежей" as payment  website -> backend: POST-запрос с данными пользователя и услугами backend -> backend: Проверка данных  alt Данные верны    backend -> auth: Запрос на аутентификацию пользователя    auth -> backend: Результат аутентификации     alt Пользователь аутентифицирован        backend -> db: Создание заказа        db -> backend: Подтверждение создания заказа        backend -> payment: Обработка платежа        payment -> backend: Результат обработки платежа        backend -> website: Результат операции     else Пользователь не аутентифицирован        backend -> website: Ошибка аутентификации    end  else Данные неверны    backend -> website: Ошибка проверки данных end @enduml

Этот скрипт можно перевести в изображение с помощью онлайн-сервисов или специального плагина для VSCode. В результате получим:

За эти схемы нам платят ;)

За эти схемы нам платят 😉

Следующий запрос к CodeChat направлен на генерацию скриптов для базы данных. Предложения:

CREATE TABLE Users (     id INT PRIMARY KEY,     email VARCHAR(255) UNIQUE NOT NULL,     password_hash VARCHAR(255) NOT NULL,     phone_number VARCHAR(20),     -- Другие поля, связанные с пользователем );  CREATE TABLE Services (     id INT PRIMARY KEY,     name VARCHAR(255) NOT NULL,     description TEXT,     price DECIMAL(10, 2) NOT NULL,     -- Другие поля, связанные с услугой );  CREATE TABLE Orders (     id INT PRIMARY KEY,     user_id INT,     service_id INT,     order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,     status VARCHAR(50),     FOREIGN KEY (user_id) REFERENCES Users(id),     FOREIGN KEY (service_id) REFERENCES Services(id),     -- Другие поля, связанные с заказом );  CREATE TABLE Payments (     id INT PRIMARY KEY,     order_id INT,     payment_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,     amount DECIMAL(10, 2) NOT NULL,     status VARCHAR(50),     FOREIGN KEY (order_id) REFERENCES Orders(id),     -- Другие поля, связанные с платежом

Для визуализации связей таблиц просим сгенерировать скрипт ER-диаграммы.

N.B. Некоторые парсеры PlantUML не поддерживают ключевое слово table. Поэтому рекомендуется в запросе вместо table использовать ключевое слово entity.

Результат запроса:

@startuml !define entity(x) class x << (E,#FF7700) >> !define column(x) note right: x  entity Users {    id : INT    email : VARCHAR(255)    password_hash : VARCHAR(255)    phone_number : VARCHAR(20)    -- Другие поля, связанные с пользователем }  entity Services {    id : INT    name : VARCHAR(255)    description : TEXT    price : DECIMAL(10, 2)    -- Другие поля, связанные с услугой }  entity Orders {    id : INT    user_id : INT    service_id : INT    order_date : TIMESTAMP    status : VARCHAR(50)    -- Другие поля, связанные с заказом }  entity Payments {    id : INT    order_id : INT    payment_date : TIMESTAMP    amount : DECIMAL(10, 2)    status : VARCHAR(50)    -- Другие поля, связанные с платежом }  Users ||--o{ Orders : "has" Services ||--o{ Orders : "has" Orders ||--o{ Payments : "has" @enduml
ER-диаграмма

ER-диаграмма

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

Добавим же и отрисуем?

Добавим же и отрисуем?

В конце попросим чат-бота сгенерировать спецификацию API в формате OpenAPI. При генерировании учитываются сущности сгенерированных ранее таблиц.

Код
openapi: 3.0.0  info:  title: Backend API  version: 1.0.0  paths:  /users:    post:      summary: Создание пользователя      requestBody:        required: true        content:          application/json:            schema:              $ref: '#/components/schemas/UserRequest'       responses:        '200':          description: Пользователь успешно создан          content:            application/json:              schema:                $ref: '#/components/schemas/UserResponse'         '400':          description: Ошибка проверки данных     get:      summary: Получение списка пользователей      responses:        '200':          description: Список пользователей          content:            application/json:              schema:                type: array                items:                  $ref: '#/components/schemas/UserResponse'   /services:    get:      summary: Получение списка услуг      responses:        '200':          description: Список услуг          content:            application/json:              schema:                type: array                items:                  $ref: '#/components/schemas/ServiceResponse'   /orders:    post:      summary: Создание заказа      requestBody:        required: true        content:          application/json:            schema:              $ref: '#/components/schemas/OrderRequest'       responses:        '200':          description: Заказ успешно создан          content:            application/json:              schema:                $ref: '#/components/schemas/OrderResponse'         '400':          description: Ошибка проверки данных         '401':          description: Ошибка аутентификации     get:      summary: Получение списка заказов      responses:        '200':          description: Список заказов          content:            application/json:              schema:                type: array                items:                  $ref: '#/components/schemas/OrderResponse'   /payments:    post:      summary: Обработка платежа      requestBody:        required: true        content:          application/json:            schema:              $ref: '#/components/schemas/PaymentRequest'       responses:        '200':          description: Платеж успешно обработан          content:            application/json:              schema:                $ref: '#/components/schemas/PaymentResponse'         '400':          description: Ошибка проверки данных         '401':          description: Ошибка аутентификации  components:  schemas:    UserRequest:      type: object      properties:        email:          type: string        password_hash:          type: string        phone_number:          type: string      required:        - email        - password_hash      example:        email: user@example.com        password_hash: 'hashed_password'        phone_number: '+1234567890'     UserResponse:      type: object      properties:        id:          type: integer        email:          type: string        phone_number:          type: string      example:        id: 1        email: user@example.com        phone_number: '+1234567890'     ServiceResponse:      type: object      properties:        id:          type: integer        name:          type: string        description:          type: string        price:          type: number          format: double      example:        id: 1        name: 'Service 1'        description: 'Service 1 description'        price: 100.0     OrderRequest:      type: object      properties:        user_id:          type: integer        service_id:          type: integer      required:        - user_id        - service_id      example:        user_id: 1        service_id: 2     OrderResponse:      type: object      properties:        id:          type: integer        user_id:          type: integer        service_id:          type: integer        order_date:          type: string          format: date-time        status:          type: string      example:        id: 1        user_id: 1        service_id: 2        order_date: '2022-01-01T00:00:00Z'        status: 'success'     PaymentRequest:      type: object      properties:        order_id:          type: integer        amount:          type: number          format: double      required:        - order_id        - amount      example:        order_id: 1        amount: 100.0     PaymentResponse:      type: object      properties:        id:          type: integer        order_id:          type: integer        payment_date:          type: string          format: date-time        amount:          type: number          format: double        status:          type: string      example:        id: 1        order_id: 1        payment_date: '2022-01-01T00:00:00Z'        amount: 100.0        status: 'success'

Скрипт можно загрузить в Swagger — и вуаля, документация готова!

Swagger-документация

Swagger-документация
Пример тела запроса и ответа

Пример тела запроса и ответа

Итоги: GigaCode — отличный инструмент для аналитиков

В этой статье мы рассмотрели на примере GigaCode возможности ИИ-ассистентов в помощи системным аналитикам. На наши запросы ассистент сгенерировал:

  1. диаграммы в формате PlantUML-скриптов (диаграмму последовательности, ER-диаграмму);

  2. таблицы для базы данных;

  3. спецификацию в формате openAPI.

Мы видим, как GigaCode выходит за рамки традиционного ассистента разработчика и становится универсальным помощником для всех ролей, работающих с кодом. GigaCode может упростить работу системным аналитикам. Вам доступен не только текстовый ввод в CodeChat, но и возможность прикреплять файлы. Например, вы можете отправить HTML-файл страницы Confluence с таблицами, алгоритмами и другим содержимым, чтобы GigaCode сгенерировал таблицы. Или передать yml-файл с описанием API, чтобы получить тесты для него. 

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

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

Попробуйте бесплатно — gigacode.ru. Если что-то пойдёт не так, пишите в комментариях, разберёмся вместе.


ссылка на оригинал статьи https://habr.com/ru/articles/899728/