Описание программного модуля

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

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

1. Аутентификация пользователей

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

2. Работа с заявками

2.1. Экранная форма

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

- Общие сведения

Атрибут	Описание
Номер заявки	Автоматически, только чтение
Статус заявки	Автоматически, только чтение
Дата создания	Автоматически, только чтение
Дата изменения	Автоматически, при каждом сохранении заявки, только чтение
Ответственный	Автоматически, по умолчанию ФИО автора заявки, только чтение для роли «Регистратор»
Согласующий (Профильный специалист)	ФИО, выбор из справочника сотрудников с ролью «Профильный специалист», сортировка в алфавитном порядке
Согласующий (Контроллер)	ФИО, выбор из справочника сотрудников с ролью «Контроллер», сортировка в алфавитном порядке

- Участники

Атрибут	Описание
Клиент	Наименование в текстовом поле.
ИНН	Поле для ввода атрибута Клиента.
Регистрационный номер	Отображение атрибута выбранного Контрагента, только чтение.
Вид оружия	Выбор из справочника, только чтение
Количество ед.	Выбор из справочника диапазона, только чтение

- Основная информация

Атрибут	Описание
Услуга	Наименование, выбор из справочника «Услуга», порядок сортировки в алфавитном порядке
Краткое описание	Текст, 100 знаков
Полное описание	Многострочный текст, 4000 знаков

- Сведения о согласовании

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

Возможность ввода атрибутов вновь создаваемой заявки доступна пользователям с ролью «Регистратор». Возможность изменения атрибутов существующей заявки доступна только пользователю, Ответственному за заявку.

По результатам заполнения атрибутов электронной формы создания заявки на услугу и ее первичного сохранения формируется заявка, ей присваивается номер и статус «Новая», атрибуты «Дата создания» и «Дата изменения» устанавливаются в соответствии с текущей датой и временем, в атрибуте «Ответственный» сохраняется ФИО текущего пользователя.

Должна быть реализована функция прикрепления файлов, размера не более 10 Мб и загрузки на локальный компьютер пользователя любого из ранее прикрепленных файлов.

2.2. Проверка на полноту и корректность

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

- Должны быть заполнены все атрибуты следующих групп:

o Общие сведения

o Участники

o Основная информация

o Внешние источники

- Числовые значения должны быть неотрицательными.

Если проверка на полноту и корректность не пройдена, необходимо отметить атрибуты, по причине которых не пройдена проверка, специальной индикацией.

2.3. Статусная модель

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

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

После инициирования процесса согласования заявке должен быть присвоен статус «Идет согласование».

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

Рисунок 23

 

2.4. Работа со списками (табличное представление)

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

- номер заявки;

- дата и время создания заявки;

- краткое описание;

- наименование услуги;

- наименование клиента;

- статус заявки;

- ответственный (в том числе с возможностью быстрого переключения между представлениями «Все / Только мои»).

В списочной форме для пользователей с ролью «Регистратор» должна быть предусмотрена возможность создания новой заявки на услуги.

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

- Инициировать согласование;

- Отозвать ранее инициированное согласование;

- Подтвердить возможность оказания услуги;

- Поменять ответственного за заявку на услугу на пользователя с ролью «Профильный специалист».

 

В случае невозможности выполнить запрашиваемое действие, необходимо обеспечить информирование пользователя о причинах.

 

3. Работа с задачами на согласование

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

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

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

- Согласована;

- На доработку (с обязательным указанием комментария);

- Отказ в согласовании (с обязательным указанием комментария).

В случае принятия решения «Согласована» по первой задаче происходит автоматическое инициирование второй задачи согласования.

В случае принятия решения «Согласована» по обеим задачам согласования, заявке должен быть присвоен статус «Согласована».

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

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

Рисунок 24

4. Работа с профилями пользователей и справочниками

4.1. Модуль управления пользователями

В модуле управления пользователями Программного модуля должна быть предусмотрена возможность создания пользователей Программного модуля, с обязательным указанием ФИО, логина и пароля, а также возможность назначить пользователю роль из следующего перечня:

- Администратор;

- Регистратор;

- Профильный специалист;

- Контроллер;

При работе с профилями пользователей должны быть предусмотрены следующие возможности:

- Просмотр списка всех пользователей;

- Просмотр профиля выбранного пользователя;

- Изменение атрибутов и роли пользователя;

- Блокировка и разблокировка пользователя (за исключением себя).

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

4.2. Модуль управления справочниками

В Программном модуле необходимо обеспечить возможность управления справочниками: добавление и изменение значений. Состав справочников Программного модуля и их атрибуты приведены в Приложении №1 к настоящему Квалификационному заданию.

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

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

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

 

Рисунок 25

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

- система оркестровки контейнеров;

- система мониторинга и логирования процессов и сервисов;

- система управления бизнес-процессами.

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

В системе мониторинга для всех компонент программного модуля должен быть предусмотрен сбор следующих метрик:

- количество запросов в секунду;

- время ответа;

- количество сессий;

- количество используемой ОЗУ;

- количество потоков;

- количество используемого процессорного времени.