Шифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией»


Скачать 441.5 Kb.
НазваниеШифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией»
страница4/7
ТипДокументы
filling-form.ru > Договоры > Документы
1   2   3   4   5   6   7

Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды


Условия эксплуатации должны соответствовать Гигиеническим требованиям к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации работы (Санитарные правила и нормы. СанПиН 2.2.2/2.4.1340-03 от 30 мая 2003 г., утвержденные Главным государственным санитарным врачом Российской Федерации).

Характеристики окружающей среды в помещениях объектов внедрения Системы должны соответствовать Гигиеническим требованиям к видеодисплейным терминалам, персональным электронно-вычислительным машинам и организации работы (Санитарные правила и нормы. СанПиН 2.2.2/2.4.1340-03 от 30 мая 2003 г., утвержденные Главным государственным санитарным врачом Российской Федерации), а также условиям эксплуатации технических средств (требования поставщиков и производителей оборудования).

4.требования к системе

    1. Требования к системе в целом

4.1.1.Требования к структуре и функционированию системы

4.1.1.1Перечень подсистем, их назначение и основные характеристики


Система должна состоять из следующих функциональных подсистем:

  • Централизованное хранилище данных;

  • Подсистема интеграции с базами операторов ПД;

  • Подсистема информационного обмена информацией о ПД;

  • Подсистема консолидации информации о ПД;

  • Подсистема анализа информации о ПД;

  • Подсистема информационной безопасности и защиты информации о ПД.

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

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

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

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

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

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

4.1.1.2Требования к способам и средствам связи для информационного обмена между компонентами системы


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

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


Система должна взаимодействовать с информационными ресурсами операторов ПД.

Взаимодействие между Системой и информационными ресурсами операторов ПД должно быть организовано посредством веб-сервисов, разрабатываемых с учетом требований СМЭВ.

4.1.1.4Требования к режимам функционирования системы


Для Системы должны быть определены следующие режимы функционирования:

  • штатный режим функционирования;

  • аварийный режим функционирования.

Штатный режим является основным режимом функционирования, обеспечивающим работу пользователей с Системой.

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

  • должен исправно работать весь комплекс технических средств;

  • должно исправно функционировать программное обеспечение;

  • в Системе должны исполняться все запущенные процессы.

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

Аварийный режим функционирования Системы используется при отказе одного или нескольких компонент программного и (или) технического обеспечения.

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

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

4.1.1.5Требования по диагностированию системы


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

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

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

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

4.1.1.6Перспективы развития, модернизации системы


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

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

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

4.1.2.Требования к численности и квалификации персонала системы и режиму его работы


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

  • структура и конфигурация Системы должны быть спроектированы и реализованы с целью минимизации количественного состава обслуживающего персонала;

  • структура Системы должна предоставлять возможность управления всем доступным функционалом Системы как одному администратору, так и предоставлять возможность разделения ответственности по администрированию между несколькими администраторами;

  • к администратору Системы не должны предъявляться требования по знанию функциональности Системы;

  • для функционирования Системы не должно требоваться круглосуточного обслуживания КСА и присутствия администраторов у консоли управления.

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

4.1.3.Показатели назначения

4.1.3.1Степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления


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

Требования к приспособляемости Системы заключаются в обеспечении возможности ее работоспособности в следующих случаях:

  • при изменении количества потребителей информации;

  • при изменении количества автоматизируемых функций;

  • при изменении требований к безопасности Системы;

  • при изменении количества поставщиков информации.

4.1.3.2Допустимые пределы модернизации и развития системы


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

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

4.1.3.3Вероятностно-временные характеристики, при которых сохраняется целевое назначение системы


Система должна поддерживать работу не менее 100 пользователей одновременно в круглосуточном режиме.

Система должна обеспечивать обслуживание не менее 20 запросов пользователей в секунду и среднее временя отклика не более 10 секунд при условии использования канала с шириной полосы пропускания 100 Мбит/с.

В соответствии с результатами проведённого анализа Система должна обеспечивать хранение и выдачу схем метаданных о ПД, содержащихся в 22 информационных ресурсах операторов ПД (из них 14 - Минздравсоцразвития России, 5 - ГИБДД МВД России, 3 – ФНС России) в разрезе 418 полей ПД (из них 24 - Минздравсоцразвития России, 167 - ГИБДД МВД России, 227 – ФНС России). Учетный объем данных не превосходит 1 Кб на каждую запись.

Максимально расчетная нагрузка на Систему должна обеспечивать до 50 Гб в месяц, что составляет 50 млн. записей в месяц по обмену схемами метаданных о ПД.

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

4.1.4.Требования к надежности

4.1.4.1Состав и количественные значения показателей надежности


Оценка надежности Системы должна проводиться с использованием следующих основных показателей надежности:

  • коэффициент готовности;

  • среднее время восстановления работоспособности.

Оценка надежности Системы должна проводиться по следующим группам отказов:

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

    • самоустраняющиеся отказы (сбои) программного обеспечения;

    • отказы, после которых для восстановления работоспособности Системы достаточно перезагрузки;

    • отказы, после которых для восстановления работоспособности Системы достаточно перенастройки установочных параметров;

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

Значения показателей надежности Системы должны быть не хуже, указанных в таблице (Таблица ):

Таблица . Допустимые значения показателей надежности Системы

Коэффициент готовности, %

Среднее время восстановления, час

Отказы первой группы

Отказы второй группы

Отказы первой группы

Отказы второй группы

98,96

91,67

0,25

2

4.1.4.2Перечень аварийных ситуаций


Ниже приводится перечень возможных аварийных ситуаций с указанием требований к средствам восстановления работоспособности Системы:

  • Сбой общего или специального программного обеспечения Системы (отдельного АРМ или сервера(ов) баз данных). После сбоя операционной системы сервера(ов) баз данных или СУБД в процессе выполнения пользовательских задач должно быть обеспечено восстановление данных в базе данных до состояния на момент окончания последней нормально завершенной перед сбоем операции (транзакции). Время восстановления работоспособности при сбоях и отказах не должно превышать 2-х часов. В это время не входит разворачивание и настройка специального программного обеспечения Системы на сервере(ах) баз данных. В указанное время не входит решение проблем с техническим обеспечением и инсталляцией операционных систем сервера(ов).

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

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

  • Импульсные помехи, сбои или прекращение электропитания. Импульсные помехи, сбои или прекращение электропитания не должны приводить к выходу из строя технических средств Системы и/или нарушению целостности данных в БД Системы. Прекращение электропитания на время до 15 минут не должно приводить к прекращению функционирования Системы. Должны быть предусмотрены средства оповещения пользователей о прекращении электропитания (или должно быть обеспечено использование резервных источников).

4.1.4.3Требования к надежности технических средств и программного обеспечения


Система должна обладать надежностью, обеспечивающей работу пользователей в произвольном режиме и оперативное восстановление работоспособности при сбоях.

Для этих целей Система должна предусматривать:

  • контроль целостности данных на уровне СУБД;

  • сохранение целостности данных при нештатном завершении программы (отказ рабочей станции и т.п.);

  • сохранение работоспособности программного обеспечения при некорректных действиях пользователя;

  • резервное копирование базы данных средствами СУБД для восстановления работоспособности Системы в случае ее логического или физического разрушения.

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

4.1.5.Требования безопасности


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

Все внешние элементы технических средств Системы, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь зануление или защитное заземление в соответствии с ГОСТ 12.1.030-81 и ПУЭ.

Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов Системы (в том числе инфракрасное, ультрафиолетовое, рентгеновское и электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук строчной частоты и т.д.), не должны превышать действующих норм (СанПиН 2.2.2./2.4.1340-03 от 03.06.2003 г.).

4.1.6.Требования к эргономике и технической эстетике


Компьютерные программы, входящие в состав Системы, должны удовлетворять требованиям, предъявляемым к человеко-машинному интерфейсу.

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

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

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

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

Экранные формы должны проектироваться с учетом требований унификации:

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

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

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

4.1.7.Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы


Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы должны быть определены на этапе технического проектирования.

4.1.8.Требования к защите информации от несанкционированного доступа


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

  • идентификация и аутентификация пользователей;

  • разделение доступа пользователей к ресурсам на основе администрируемой ролевой политики;

  • протоколирование действий пользователей и хранение протоколов;

  • обеспечение информационной безопасности на основе:

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

    • дублирования и резервирования ключевых элементов Системы для повышения надежности работы.

4.1.9.Требования по сохранности информации при авариях


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

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

В случае повреждения журналов транзакций СУБД должно быть обеспечено восстановление состояния Системы на момент создания последней резервной копии данных, но не позднее, чем за сутки до момента сбоя.

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

4.1.10.Требования к защите от влияния внешних воздействий


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

4.1.11.Требования к патентной чистоте


Используемые при проектировании, разработке и вводе в опытную эксплуатацию Системы аппаратное обеспечение, инструменты разработки программного обеспечения и СУБД должны быть лицензионными и сертифицированы на территории Российской Федерации для работы в используемых режимах. В случае использования собственных разработок должно быть наличие документальных свидетельств на владение интеллектуальной собственностью и авторскими правами.

4.1.12.Требования по стандартизации и унификации


При разработке Системы должно быть максимизировано использование общероссийских классификаторов.

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

В случае применения исполнителем специфицированных, но не стандартизированных решений должно быть представлено обоснование на каждый такой случай.
1   2   3   4   5   6   7

Похожие:

Шифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией» iconСтатья 1 Федеральный закон «О банках и банковской деятельности»
Таблица-пояснение к Федеральному закону "О внесении изменений в отдельные законодательные акты Российской Федерации" (по вопросам...

Шифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией» iconДолжна содержать следующую информацию
...

Шифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией» iconДолжна содержать следующую информацию
...

Шифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией» iconОтчет по результатам разработки предложений по внесению изменений...
Предложений по разработке иных документов, обеспечивающих реализацию концепции оптимизации механизмов проектирования и реализации...

Шифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией» iconИ. М. Хворенкова Современные методы электронного обмена информацией...
Современные методы электронного обмена информацией на примере конфигурации «Бухгалтерский и налоговый учет», редакция 3 (управляемое...

Шифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией» icon«Реализация антикоррупционной политики Республики Татарстан на 2015 – 2020 годы»
Совершенствование инструментов и механизмов, в том числе правовых и организационных, противодействия коррупции

Шифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией» icon1. Общие сведения Назначение документа
Протокол обмена информацией при осуществлении переводов: http- и email-уведомления

Шифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией» iconПорядок обмена между Банком и Клиентом документами и информацией...
Банк и Клиент при осуществлении валютных операций обеспечивают соблюдение требований Федерального закона от 10. 12. 2003 №173-фз...

Шифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией» iconСпорные вопросы по ндс; Имущественные налоги: вопрос-ответ
«В цифровом формате». Практика обмена информацией в РФ соответствует международным стандартам

Шифр 2115-09-10 «Выработка требований, механизмов и инструментов межведомственного обмена информацией» iconРуководство нато по каталогизации
Автоматическая обработка данных (adp) для обмена информацией в системе кодификации нато

Вы можете разместить ссылку на наш сайт:


Все бланки и формы на filling-form.ru




При копировании материала укажите ссылку © 2019
контакты
filling-form.ru

Поиск