Подготовка технического задания на систему для СМЭВ: основные шаги и развилки

В статье перечисляются и разбираются основные особенности подготовки технических заданий на системы для организации межведомственного взаимодействия, а также приводится рекомендуемая структура ТЗ. Материал может быть полезен при планировании работ по подключению к СМЭВ или модернизации существующих программных решений. Для статьи авторами был обобщен опыт создания 7 ГИС, внедренных и используемых в органах исполнительной власти РФ.

Развилки на пути создания информационной системы

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

  • планируется развитие (модернизация) системы или разработка ИС «с нуля»?
  • планируется ли использовать базовое ПО при разработке системы?
  • должна ли система удовлетворять тенденциям импортозамещения?
  • требуется ли системе пользовательский интерфейс?
  • какие пользователи будут работать в системе, требуется ли разграничение прав доступа?
  • система создается для межведомственного взаимодействия, оказания государственных услуг, или для решения обеих задач?
  • какие данные будут храниться в системе?
  • должна ли система обмениваться данными с другими ведомственными информационными системами?
  • требуется ли в системе функционал формирования отчетов?
  • какие процессы необхоодимо автоматизировать в системе, что она должна уметь делать без вмешательства пользователя?

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

Разберем перечисленные особенности более подробно.

Модернизация или разработка новой системы

Достаточно часто у ведомств уже есть СМЭВ-система. И даже если она не работает, морально устарела, а разработчик ни в какую не хочет ее развивать – все равно очень желательно указывать в названии работ формулировку «модернизация». В противном случае у Минкомсвязи возникнет закономерный вопрос: «Зачем ведомству столько однотипных информационных систем?».

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

  • вывести старую ИС из эксплуатации – процесс сложный, требующий выполнения ряда формальных условий (например, с момента создания ИС должно пройти 5 лет);
  • указать в названии работ специфику задач, которые будет выполнять новая система (например, «создание ИС в целях обеспечения межведомственного взаимодействия департамента делопроизводства» или «создание ИС с целью оказания государственной услуги «Выдача охотничьего билета» в электронном виде».

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

Единственный очевидный минус «модернизации» существующей ИС вместо создания новой – необходимость подробного описания в ТЗ «объекта автоматизации». В данном разделе, как правило, указывается история создания системы, структура её компонентов, функциональные возможности, ранее переведенные в электронный вид госуслуги, подключенные сервисы СМЭВ. Всю эту информацию можно найти в ТЗ на создание/развитие старой системы. Если же система создается «с нуля», в разделе «Объект автоматизации» достаточно указать «Объектом автоматизации выступает деятельность ведомства по оказанию государственных услуг и осуществлению межведомственного взаимодействия в электронном виде».

Наличие базового ПО

Базовое ПО – программное обеспечение, на основании которого создается система. Например, в роли базового ПО может выступать система документооборота или ERP-решение.

Как правило, базовое ПО всегда используется разработчиками при создании СМЭВ-системы. Вместо того чтобы каждый раз разрабатывать решение с нуля они берут за основу готовое ядро или даже полноценную систему и кастомизируют его под требования ведомства-заказчика.

Если при создании системы планируется использовать базовое ПО – в ТЗ обязательно должно содержаться указание на способ его приобретения. Либо ведомство-заказчик закупает ПО самостоятельно или в рамка контракта на создание ИС, либо его закупает исполнитель и передает заказчику все необходимые права и лицензии.

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

Импортозамещение

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

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

Что касается базового ПО —  желательно включить в ТЗ требование о том, что разработчик должен подтвердить лицензионную используемого чистоту Базового ПО и факт его наличия в «Едином реестре российских программ для электронных вычислительных машин и баз данных» (он же – «реестр отечественного ПО»).

Пользовательский интерфейс

Существует множество СМЭВ-решений, не имеющих пользовательского интерфейса и выполняющих функцию передачи (транспорта) запросов между СМЭВ и ведомственной информационной системой. С точки зрения ТЗ это очень существенная развилка.

Если интерфейс в системе не нужен, в ТЗ обязательно должно содержаться подробное описание способа интеграции существующей ведомственной ИС с создаваемой СМЭВ-системой, в том числе:

  • на чьей стороне реализуется API;
  • тип сервиса;
  • типы и содержание сообщений (передаваемых данных);
  • требования к логированию действий СМЭВ-системы и т.д.

Если интерфейс нужен, в ТЗ включаются разделы:

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

Пользователи

Интерфейс и функционал СМЭВ-системы должен учитывать число и характеристики пользователей. Некоторые ИС создаются для одного пользователя или департамента из нескольких пользователей. В этом случае в системе достаточно иметь одну роль и одну учетную запись на всех. Можно даже обойтись без системы авторизации. Это существенно упростит работы и снизит их стоимость.

Обратная ситуация – решение, в котором работает множество пользователей, различающихся:

  • функциональными обязанностями и задачами;
  • структурными подразделениями;
  • местом осуществления трудовой деятельности (территориальные органы, представительства);
  • типами используемых устройств (ПК, ноутбуки, планшеты) и операционных систем (Windows, Linux, iOS).

Для такой системы в ТЗ обаятельно обязательно необходимо описать следующие особенности:

  • использование адаптивного web-интерфейса (отсутствие необходимости установки ПО на локальное устройство, доступ к решению через web-браузер);
  • функционал и логику работы системы авторизации;
  • функционал системы администрирования (создание и редактирование учетных записей пользователей, объединение пользователей в группы, журнал сессий, журнал действий пользователей в системе);
  • функционал личного кабинета пользователя (редактирование информации о себе, контактных данных, настройка интерфейсов);
  • функционал распределения прав доступа (права на чтение/ редактирование/ создание записей по каждой услуге, межведомственному запросу и т.д.).

Госулуги

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

  • перечень услуг и степень (этап) автоматизации;
  • необходимость функционала обработки в системе заявлений, поступивших в бумажном виде;
  • особенности и бизнес-логика (алгоритм) обработки оператором поступивших заявлений (как формируются ответы заявителю, какие этапы проходит заявление, подразумевается ли передача крупных файлов, требуется ли функционал записи на прием и т.д.);
  • указание на необходимость разработки и тестирования исполнителем видов сведений СМЭВ3 для обеспечения приема заявлений с ЕПГУ через СМЭВ;
  • указание на необходимость разработки исполнителем частных технических заданий на создание интерактивных форм заявлений на ЕПГУ.

Создание и настройка процесса обработки заявлений на предоставление госуслуг в электронном виде – одна из сложнейших задач для разработчика. Очень желательно максимально подробно изложить этот пункт в ТЗ.

Межведомственное взаимодействие

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

  1. оператор направляет из системы запрос к ФОИВ-поставщику данных и получает ответ;
  2. ФОИВ-потребитель данных направляет в систему запрос, а оператор (или система) готовит ответ и направляет его потребителю.

В первом случае все достаточно просто. В ТЗ необходимо указать перечень подключаемых видов сведений ФОИВ-поставщиков и дополнительный функционал обработки ответов (возможность прикрепления к заявлению/делу, возможность выгрузки в PDF и т.д.). Единственный нюанс – для направления запроса к некоторым видам сведений требуется его подписания не только СМЭВ-подписью системы, но и подписью (ЭП) конкретного сотрудника (например, виды сведений «Сведения о доходах физических лиц по справкам 2-НДФЛ», «Прием обращений в ФГИС ЕГРН» и др.). Если такие ВС требуются ведомству, в ТЗ необходимо включить фразу «Стандартный web-интерфейс системы должен поддерживать функционал подписи СМЭВ-запросов ЭП ответственного сотрудника».

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

  • перечень видов сведений, ссылки на ТКМВ;
  • необходимость разработки и тестирования исполнителем видов сведений для их вывода в продуктивную среду СМЭВ3;
  • бизнес-логику обработки поступающих запросов (будет ли оператор отвечать на запросы вручную, или они должны обрабатываться и отправляться системой в автоматическом режиме).

Хранение данных

Обычно помимо информации, относящейся непосредственно к межведомственному взаимодействию в СМЭВ-системах хранятся сопутствующие данные:

  • сведения о физических лицах и организациях, подававших заявления на оказания государственных услуг;
  • данные, необходимые для обработки входящих СМЭВ-запросов;
  • нормативно-справочная информация и др.

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

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

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

Интеграции, обмен данными с другими системами

СМЭВ-системы обычно интегрируются с тремя типами внутренних (ведомственных) систем:

  • системы документооборота;
  • системы-источники данных для ответов на поступившие СМЭВ-запросы;
  • системы-инициаторы межведомственных запросов (СМЭВ-решение выступает в роли транспорта в/из СМЭВ).

Перечень и описание всех интегрируемых систем должны включаться в ТЗ. Как уже указывалось выше, в описании должна содержаться информация о том, на чьей стороне реализуется API, типе сервиса, типах и содержании сообщений (передаваемых данных).

Подробнее стоит рассмотреть сценарии интеграции с системами документооборота. Каждое входящее заявление на предоставление госуслуги должно быть зарегистрировано, а номер и дату входящего желательно вернуть заявителю на ЕПГУ вместе с соответствующим статусом (например, со статусом «Заявление зарегистрировано»). Таким образом, СМЭВ-решение должно передать в систему документооборота содержательную информацию по поступившему заявлению и получить в ответ регистрационные данные. Это первый сценарий интеграции.

Второй сценарий связан с подготовкой результатов оказания услуги. Если услуга переводится в электронный вид до 5-ого этапа (предоставления результата в электронном виде), заявитель должен получить в личный кабинет на ЕПГУ электронный документ, свидетельствующий об оказании услуги. Для этого:

  • СМЭВ-решение должно инициировать создание карточки документа в системе документооборота;
  • документ должен быть подготовлен и передан из СЭД в СМЭВ-систему.

Необходимо также учитывать, что большинство интеграций требуют участия как минимум двух исполнителей – разработчика СМЭВ-решения и разработчика интегрируемой системы. Поэтому требования к интеграции должны быть прописаны в ТЗ у всех.

Формирование отчетов

Обычно ведомства ведут, публикуют и предоставляют в Минкомсвязь статистику межведомственного взаимодействия. Для того чтобы упростить процесс сбора данных можно предусмотреть в СМЭВ-решении функционал формирования (выгрузки) отчетов. Тем более для разработчика его реализация не требует значительных усилий.

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

  • перечень отчетов;
  • состав выгружаемых данных (по каждому отчету);
  • формат выгрузки данных (по каждому отчету);
  • описание механизма работы конструктора отчетов (например, возможность выбора периода построения отчета, состава данных, порядка их отображения и др.).

Автоматизация процессов

Корректное описание автоматизируемых процессов – ключ к созданию качественной и удовлетворяющей потребности конечных пользователей СМЭВ-системы. Наиболее часто в подобных решениях автоматизируются следующие процессы:

  • ответ на поступивший межведомственный запрос;
  • направление уведомлений о событиях в системе;
  • отдельные этапы обработки заявления на предоставление госуслуги (регистрация, направление связанных СМЭВ-запросов к поставщикам данных (в т.ч. проверка корректности представленных данных), отправка уведомлений пользователю на ЕПГУ и др.).

Для понимания и корректного описания всех нюансов автоматизируемого процесса автору ТЗ желательно пообщаться с конечными пользователями системы (операторами), узнать их видение процесса, его алгоритм, участников и т.д.

Структура ТЗ

Ниже в качестве примера представлен наиболее полный вариант структуры ТЗ на создание ИС для СМЭВ.

  1. Термины и сокращения
  2. Основные положения
    1. Наименование работ
    2. Сроки проведения работ
    3. Цель и задачи работ
    4. Нормативное обоснование работ
  3. Объект автоматизации
    1. Цель и задачи системы
    2. Компоненты системы
    3. Пользователи
    4. Базовое ПО
    5. Функции системы
    6. Интеграции
    7. Реализованные госуслуги и сервисы межведомственного взаимодействия
  4. Требования к реализации ИС
    1. Архитектура
    2. Базовое ПО
    3. Технологии (ОС, СУБД и проч.)
    4. Требования к интеграционному API
  5. Требования к функционалу ИС
    1. Обеспечение оказания государственных услуг в электронном виде
    2. Обеспечение межведомственного взаимодействия с ВС поставщиков данных
    3. Обеспечение функционирования ведомственных ВС
    4. Автоматизируемые процессы
      1. Обработка заявлений
      2. Обработка СМЭВ-запросов
      3. Направления уведомлений
    5. Интеграция с ведомственными ИС
    6. Требования к обработке и хранению данных
    7. Требования к формированию отчетов
  6. Требования к администрированию ИС
    1. Управление пользователями
    2. Управление правами доступа
    3. Журнал сессий
    4. Журнал действий пользователя
  7. Прочие требования к ИС
    1. Брендбук и требования к интерфейсам
    2. Требования к режимам функционирования
    3. Требования к надежности
    4. Требования к безопасности и защите информации
    5. Требования к масштабируемости
    6. Требования к эргономике и эстетике
    7. Требования к лингвистическому обеспечению
    8. Требования к лицензионной чистоте
  8. Целевые эксплуатационные характеристики
    1. Число пользователей
    2. Время отклика
    3. Время бесперебойной работы
    4. Качество обработки СМЭВ-запросов
      1. Скорость обработки
      2. Процент потерь
  9. Результаты работ
    1. Этапы выполнения работ
    2. Результаты работ
    3. Сводная таблица работ, сроков и отчетных документов
  10. Гарантия качества

 

 

 

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *