Телефон: 8-800-350-22-65
Напишите нам:
WhatsApp:
Telegram:
MAX:
Прием заявок круглосуточно
График работы офиса: с 9:00 до 21:00 Нск (с 5:00 до 19:00 Мск)

Статья опубликована в рамках: Научного журнала «Студенческий» № 22(360)

Рубрика журнала: Информационные технологии

Скачать книгу(-и): скачать журнал

Библиографическое описание:
Заремба О.Ю. СЦЕНАРИИ ВЗАИМОДЕЙСТВИЯ И ПОТОК ОБРАБОТКИ ЗАПРОСА ПРИ ПРОЕКТИРОВАНИИ СИСТЕМЫ АВТОМАТИЗАЦИИ ОТВЕТОВ // Студенческий: электрон. научн. журн. 2026. № 22(360). URL: https://sibac.info/journal/student/360/423570 (дата обращения: 06.07.2026).

СЦЕНАРИИ ВЗАИМОДЕЙСТВИЯ И ПОТОК ОБРАБОТКИ ЗАПРОСА ПРИ ПРОЕКТИРОВАНИИ СИСТЕМЫ АВТОМАТИЗАЦИИ ОТВЕТОВ

Заремба Ольга Юрьевна

студент, кафедра информационных технологий и математики, Сочинский государственный университет,

РФ, г. Сочи

Копырин Андрей Сергеевич

научный руководитель,

канд. экон. наук, доц., Сочинский государственный университет,

РФ, г. Сочи

АННОТАЦИЯ

Разработка сценариев работы прототипа MVP.

 

Ключевые слова: пользовательский сценарий.

 

В MVP выделяются две роли: «Сотрудник» и «Администратор базы знаний». Роль «Сотрудник» соответствует конечному пользователю, получающему справочную информацию. Роль «Администратор базы знаний» объединяет функции владельца контента и администратора системы, что соответствует целевой минимизации организационных ролей и упрощает контур сопровождения базы знаний в прототипе. Ниже рассмотрены основные сценарии работы прототипа.

Сценарий «Поиск ответа» является основным пользовательским сценарием. Его результатом выступает либо выдача релевантной статьи базы знаний, либо фиксация случая «ответ не найден» для последующего пополнения базы. В реализованном прототипе интерфейс поиска представлен веб формой ввода вопроса в свободной форме; запрос отправляется на серверную часть, где выполняется нормализация текста, полнотекстовый поиск по опубликованным статьям и ранжирование результатов. Статьи базы знаний трактуются как документы, индексируемые по текстовым полям и метаданным.

Сценарий «Просмотр статьи» является обязательной частью поиска и реализуется как отображение выбранного результата в форме «вопрос—ответ» с метаданными. Для обеспечения проверяемости и актуальности ответа статья содержит категорию, дату изменения и ссылку на источник (название и, при наличии, URL).

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

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

Сценарии администратора объединяют управление содержанием и наблюдение за проблемными запросами. Сценарий «Создание/редактирование статьи» включает ввод текста вопроса (канонической формулировки), текста ответа, назначение категории, заполнение ссылки на источник и изменение статуса публикации.

Сценарий «Просмотр запросов без ответа» обеспечивает управляемость развития базы знаний. Администратор просматривает журнал обращений с признаками найденного/ненайденного ответа, оценкой пользователя и техническими атрибутами результата (например, оценкой релевантности). Этот сценарий замыкает цикл пополнения базы знаний: нерешённые запросы становятся кандидатами на добавление новых статей или расширение формулировок существующих статей. Формирование и хранение таких записей соответствует практикам сервисного управления, где наблюдаемость потока обращений рассматривается как обязательная предпосылка улучшения процесса.

Поток обработки запроса фиксируется как последовательность операций, реализованных в серверной части приложения: приём запроса и валидация, нормализация текста, выполнение поиска по базе знаний, ранжирование и принятие решения «найдено/не найдено», запись результата в журнал обращений, возврат ответа пользователю.

 

Список литературы:

  1. ГОСТ Р ИСО/МЭК 25010—2015. Системная и программная инженерия. Требования и оценка качества систем и программных продуктов (SQuaRE). Модели качества систем и программных продуктов. — Москва: Стандартинформ, 2015. — Текст: непосредственный.
  2. Вдовин, В. М., Суркова, Л. Е., Валентинов, В. А. Информационные технологии в финансово-банковской сфере: учебное пособие. — Москва: Дашков и К, 2016. — 304 с.
  3. Django Software Foundation. Django documentation (Django 5.0) Электронный ресурс. — URL: https://docs.djangoproject.com/en/5.0/ (дата обращения: 28.05.2026).
  4. PostgreSQL Global Development Group. PostgreSQL 16 Documentation: Full Text Search Электронный ресурс. — URL: https://www.postgresql.org/docs/16/textsearch.html (дата обращения: 28.05.2026).