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

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

 

 

 

5 1 голос
Рейтинг статьи
Подписаться
Уведомить о
guest
1 Комментарий
Межтекстовые Отзывы
Посмотреть все комментарии
Вольхин Николай
Вольхин Николай
1 месяц назад

Здравствуйте. мы в РПНе сейчас внедряем СМЭВ3, и всё ок, но один вопрос не понятен. Описание кодов возвратов при ошибках и неуспешных проверок Поставщик сведений может отказать в предоставлении запрашиваемых сведений. Все возможные отказы в предоставлении сведений делятся на четыре типа: 1. Отказ в предоставлении сведений. Отсутствуют права на получение информации (например, в случае, если поставщик проверяет ЭП-СП). 2. Отказ в предоставлении сведений. Невозможно определить объект запроса информации. 3. Уведомление об отсутствии сведений. 4. Ошибка при предоставлении сведений. Это должны быть какие то служебные сообщения адаптера, где бы посмотреть как сказать адаптеру что надо ответить именно одним и этих специальных… Подробнее »