Характеристика объекта автоматизации
3.1. Краткие сведения об объекте автоматизации
Объектом автоматизации является деятельность органов исполнительной власти Пермского края в сфере предупреждения детского и семейного неблагополучия, в том числе в части взаимодействия с органами управления образования муниципальных районов и городских округов Пермского края, образовательными и медицинскими организациями Пермского края, комиссиями по делам несовершеннолетних и защите их прав Пермского края, муниципальных районов и городских округов Пермского края, ГУ МВД РФ по Пермскому краю и территориальными органами внутренних дел Пермского края на районном уровне в части обмена информацией.
Текущее состояние объекта автоматизации
В настоящее время процессы профилактики детского и семейного благополучия не автоматизированы.
3.3. Характеристики окружающей среды
Характеристики окружающей среды в местах установки технических средств соответствуют треованиям следующих документов:
ГОСТ Р ИСО 14001-2007 Системы экологического менеджмента. Требования и руководство по применению;
СанПиН 2.2.4.548-96 Физические факторы производственной среды. Гигиенические требования к микроклимату производственных помещений;
СанПиН 2.2.2/2.4.1340-03 Гигиенические требования к персональным электронно-вычислительным машинам и организации работы.
3.4. Общие принципы создания Системы
При создании Системы необходимо руководствоваться следующими принципами:
|
|
|
принцип системности. При декомпозиции должны быть установлены такие связи между структурными элементами Системы, которые обеспечивают цельность Системы и её взаимодействие с другими системами;
принцип развития (открытости). Исходя из перспектив развития объекта автоматизации, Система должна создаваться с учетом возможности пополнения и обновления функций и состава Системы без нарушения его функционирования;
принцип совместимости. Должны быть реализованы информационные интерфейсы, благодаря которым Система может взаимодействовать с другими системами в соответствии с установленными правилами;
принцип стандартизации (унификации). Должны быть рационально применены типовые, унифицированные и стандартизованные элементы, проектные решения, пакеты прикладных программ, комплексы, компоненты;
принцип эффективности. Должно быть достигнуто рациональное соотношение между затратами на создание Системы и целевыми эффектами, включая конечные результаты, получаемые в результате автоматизации;
принцип открытости. Система должна быть способна к интеграции в свою среду новых систем, расширения функций уже имеющихся, а также обеспечивать возможность интеграции с внешними ИС. При разработке и развитии Системы должны применяться общепринятые стандарты на правила передачи (протоколы, интерфейсы) и хранения информации;
|
|
|
принцип санкционированного доступа к информации. Система должна обеспечивать санкционированный доступ к информации. Система должна иметь функции администрирования, которые позволяют устанавливать пользователям права доступа к информации.
Требования к выполнению работ
4.1 Требования к Системе в целом
4.1.1. Требования к структуре и функционированию
Система должна функционировать в двух контурах информационной безопасности, обеспечивающих раздельную работу с Персональными (Закрытый контур) и обезличенными (Открытый контур) данными, и включать удалённые рабочие места пользователей. Инфраструктура Открытого контура должна обеспечивать работу с источниками общедоступной и/или обезличенной информации. Инфраструктура Закрытого контура должна обеспечивать работу с полным набором данных, в том числе персональных и конфиденциальных, доступных для данного Пользователя. Блок схема взаимодействия ведомств приведена на рис. 1.
|
|
|
Рис. 1. Блок-схема взаимодействия ведомств в рамках Системы.
4.1.1.1. Требования к способам и средствам связи для информационного обмена между компонентами Системы
В качестве протокола взаимодействия между компонентами Системы на транспортно-сетевом уровне необходимо использовать протокол TCP/IP.
Информационное взаимодействие между компонентами Системы осуществляется посредством доступа к единому хранилищу данных (СУБД).
Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня.
4.1.1.2. Требования к взаимодействию с внешними информационными системами
Информационное и технологическое взаимодействие Системы с внешними информационными системами должно осуществляться путём их интеграции посредством программной и технологической инфраструктуры, обеспечивающей обмен информацией между системами. Порядок интеграции определяется регламентами информационного взаимодействия, которые разрабатываются на этапе «Обследование и техническое проектирование».
В состав внешних систем, с которыми должно быть обеспечено взаимодействие, входят:
ЕАИС «Социальный регистр населения»;
|
|
|
«Краевая автоматизированная база данных о детях с ОВЗ»;
Автоматизированная система по мониторингу и анализу открытой информации изинформационно-телекоммуникационной сети Интернет (далее – ИС Мониторинг соц.сетей);
Информационная система учёта контингента обучающихся по основным образовательным программам и дополнительным общеобразовательным программам (далее – ИС Контингент).
Перечень внешних информационных систем, форматы данных и порядок информационного обмена должны быть уточнены на этапе «Обследование и техническое проектирование».
4.1.1.3. Требования к режимам функционирования Системы
Требования к режиму функционирования Системы соответствуют изложенным ниже требованиям, предъявляемым к Системе в целом.
Система должна функционировать в следующих режимах:
штатный режим, при котором обеспечивается выполнение задач в объеме функций, предусмотренных настоящим техническим заданием;
сервисный режим, необходимый для проведения обслуживания, реконфигурации и пополнения технических и программных средств Системы новыми компонентами;
аварийный режим работы.
В штатном режиме функционирования Система должна обеспечивать следующий режим работы: доступность функций Системы в режиме — 24 часа в день, 7 дней в неделю (24х7). Круглосуточный режим работы Системы не требует организации круглосуточной работы пользователей и допускает работу пользователей в соответствии со штатным расписанием.
В сервисном режиме Система должна обеспечивать возможность проведения следующих работ:
техническое обслуживание;
модернизацию аппаратно-программного комплекса;
устранение аварийных ситуаций.
Система переходит в аварийный режим при возникновении нештатной ситуации и невозможности штатной работы. В случае перехода Системы в аварийный режим, обслуживающему персоналу необходимо перевести Систему в сервисный режим в соответствии с инструкциями, которые должны быть изложены в руководстве администратора.
Регламентные работы должны производиться с учётом требований о доступности Системы.
Функционирование Системы при отказах и сбоях серверного общесистемного и специального программного обеспечения и оборудования, в том числе структурных узлов Системы, не предусматривается.
4.1.1.4. Перспективы развития, модернизации Системы
Технические решения, используемые на этапах проектирования и реализации Системы, должны позволять минимизировать трудозатраты по модернизации, требуемые в связи с выпуском новых нормативных актов, приводящих к изменению технологического процесса.
Должна быть предусмотрена возможность масштабирования Системы при увеличении нагрузки на Систему, то есть учитываться требования к увеличению нагрузки, объёмов информации и числа пользователей, последующему расширению функциональности.
4.1.1.5. Требования к надёжности
Для Системы регламентируются показатели надежности следующих видов аварийных ситуаций:
общесистемный отказ – выражается в недоступности всех или большинства пользовательских интерфейсов Системы;
частный сбой – выражается в недоступности одного из интерфейсов какой-либо функциональной подсистемы или его некорректной работе, кроме случаев, когда сбой является воспроизводимым результатом неверной реализации алгоритмов разработчиком и подлежит устранению в порядке и сроки, установленные государственным контрактом на внедрение Системы.
Оценка надежности Системы должна проводиться с использованием следующих основных показателей надежности (ГОСТ 24.701-86 и ГОСТ 27.003-90):
интенсивности отказов;
среднего времени восстановления.
Измерение показателей надежности Системы должно производиться обслуживающим персоналом в ходе эксплуатации Системы путем анализа системных журналов.
Система должна быть устойчива по отношению к программно-аппаратным ошибкам, отказам технических и программных средств, с возможностью восстановления ее работоспособности и целостности информационного содержимого при возникновении ошибок и отказов. В Системе должно предусматриваться автоматическое восстановление работоспособности серверной части Системы в следующих ситуациях:
штатное и аварийное отключение электропитания серверной части;
штатная перезагрузка Системы и загрузка после отключения;
программный сбой общесистемного программного обеспечения, приведший к перезагрузке Системы.
В Системе должно предусматриваться полуавтоматическое восстановление работоспособности серверной части Системы в следующих аварийных ситуациях:
физический выход из строя любого аппаратного компонента, кроме дисковых накопителей – после замены компонента и восстановления конфигурации общесистемного программного обеспечения;
аварийная перезагрузка Системы, приведшая к нефатальному нарушению целостности файловой системы – после восстановления файловой системы;
нарушение целостности данных в БД Системы – после восстановления базы из резервной копии.
4.1.1.6. Требования к информационной безопасности
Информационная безопасность Системы обеспечивается технологической подсистемой «Администрирование и информационная безопасность».
В Техническом проекте должны быть определены и отражены требования и решения по обеспечению информационной безопасности в Системе, программно-аппаратному комплексу, на котором должны разворачиваться Система и ее компоненты. Указанные требования и решения должны определять средства защиты информации в части:
механизмов (способов) аутентификации пользователей сервисов;
защиты идентификационной информации пользователей сервисов, хранимой и обрабатываемой в Системе;
обеспечения и контроля прав доступа к защищенным ресурсам и информации;
минимизации прав доступа;
механизмов (способов) аутентификации Системы при взаимодействии с внешними информационными системами;
обеспечения конфиденциальности и целостности передаваемой/принимаемой по каналам связи информации;
управления доступом к защищаемой информации и персональным данным;
резервирования, резервного копирования и восстановления;
антивирусной защиты;
разграничения доступа, на основании ролевой модели;
анализа защищенности;
межсетевого экранирования;
криптографической защиты;
обнаружения вторжений;
контроля целостности обрабатываемых и технологических данных Системы и ее компонентов.
Должна быть обеспечена возможность защиты информации в Системе от потери и несанкционированного доступа на этапах её передачи и хранения.
Должен быть реализован следующий комплекс мер, направленных на защиту от несанкционированного доступа к функциям административного интерфейса Системы:
возможность ограничения доступа к административному интерфейсу;
возможность ведения журналов действий пользователей Системы и ее компонентов в административном интерфейсе и журнала аутентификаций.
Для настройки прав пользователей Системы должны создаваться отдельные роли пользователей, с назначением разрешений на выполнение отдельных функций и ограничений по доступу к информации, обрабатываемой в Системе и ее компонентах. При формировании ролей пользователей Системы и ее компонентов необходимо руководствоваться принципом, ограничивающим полномочия по доступу к информации и ресурсам по обработке информации на уровне минимально необходимых для выполнения определенных, документально зафиксированных, обязанностей.
Необходимо обеспечить обязательное ведение журнала событий в Системе с указанием следующих значений для каждого события в системе:
уникальный порядковый номер записи;
дата и время события;
имя учетной записи пользователя;
наименование события (выполняемое действие);
успех/неуспех.
Необходимо обеспечить недоступность изменения записей журнала для всех пользователей системы, в том числе всех категорий обслуживающего персонала. Необходимо обеспечить доступность функции очистки журналов только для Администратора информационной безопасности. Функция очистки журнала должна автоматически сопровождаться обязательной записью данного события после очистки в журнал событий.
Внесению в журнал событий подлежат:
все события административного характера;
все события, относящиеся к предоставлению государственных услуг, в том числе и обрабатываемые в автоматическом режиме;
все события, относящиеся к выполнению государственных функций, в том числе и обрабатываемые в автоматическом режиме;
сведения о произошедших ошибках в Системе или процессе предоставления государственных услуг или выполнения государственных функций;
все события, относящиеся к изменению параметров Системы и средств защиты информации.
В отношении средств защиты информации, разрабатываемых Исполнителем в составе Системы, в том числе с применением средств криптографической защиты, должны быть предложены решения, обеспечивающие возможность их последующей сертификации в системе сертификации ФСБ, ФСТЭК.
При разработке программного кода Исполнитель должен применять методы безопасного программирования, включающие:
ручную и автоматизированную проверку кода на предмет недокументированных возможностей;
использование при разработке доверенной аппаратной платформы с функциями защиты от недокументированных вохможностей на системном и прикладном уровне;
контроль версионности исходного кода;
тестирование информационной системы на проникновения (пинтесты).
Детализированные требования к обеспечению информационной безопасности, а также требования по разработке организационно-распорядительных документов по обеспечению информационной безопасности, должны быть уточнены на этапе «Обследование и техническое проектирование».
4.1.2. Требования по сохранности информации при авариях
Для обеспечения сохранности информации в Системе должны быть включены следующие функции:
резервное копирование базы данных Системы;
восстановление данных в непротиворечивое состояние при программно-аппаратных сбоях (отключение электрического питания, сбоях операционной Системы и других) вычислительно-операционной среды функционирования;
восстановление данных в непротиворечивое состояние при сбоях в работе сетевого программного и аппаратного обеспечения.
4.1.2.1. Перечень событий, при которых должна быть обеспечена сохранность информации в Системе
В Системе должно предусматриваться автоматическое восстановление обрабатываемой информации в следующих аварийных ситуациях:
программный сбой при операциях записи-чтения;
разрыв связи с клиентской программой (терминальным устройством) в ходе редактирования/обновления информации.
В Системе должна предусматриваться возможность ручного восстановления обрабатываемой информации из резервной копии в следующих аварийных ситуациях:
физический выход из строя дисковых накопителей;
ошибочные действия обслуживающего персонала.
В Системе должно предусматриваться автоматическое восстановление работоспособности серверной части Системы в следующих ситуациях:
штатное и аварийное отключение электропитания серверной части;
штатная перезагрузка Системы и загрузка после отключения;
программный сбой общесистемного программного обеспечения, приведший к перезагрузке Системы.
В Системе должно предусматриваться полуавтоматическое восстановление работоспособности серверной части Системы в следующих аварийных ситуациях:
физический выход из строя любого аппаратного компонента, кроме дисковых накопителей — после замены компонента и восстановления конфигурации общесистемного программного обеспечения;
аварийная перезагрузка Системы, приведшая к нефатальному нарушению целостности файловой системы — после восстановления файловой системы.
4.1.2.2. Требования к резервному копированию и архивированию данных
Резервное копирование информации может осуществляться в двух режимах:
- создание полной копии базы данных;
- сохранение изменений, внесенных со времени создания последней архивной копии (архивные копии log-файлов).
Периодичность и очерёдность этих операций должны быть определены на этапе «Обследование и техническое проектирование».
4.1.3. Требования к эргономике и технической эстетике
Взаимодействие пользователей с прикладным программным обеспечением, входящим в состав Системы, должно осуществляться посредством визуального графического интерфейса (GUI).
Интерфейс Системы не должен быть перегружен графическими элементами и должен обеспечивать быстрое отображение веб-форм. Навигационные элементы должны быть выполнены Исполнителем в удобной для пользователя форме. Интерфейс должен соответствовать современным эргономическим требованиям, типичным для современных веб-приложений, быть интуитивно понятным и обеспечивать простой и удобный доступ к основным функциям и операциям Системы.
Интерфейс должен быть рассчитан на использование персональных рабочих станций, переносных компьютеров (ноутбуков) и планшетов (в адаптивной вёрстке). Управление Системой должно осуществляться с помощью набора экранных меню, кнопок, значков и прочих графических элементов. Клавиатурный режим ввода должен использоваться при заполнении и/или редактировании текстовых и числовых полей экранных форм.
Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме системных сообщений, зависящих от языка установленной операционной системы) должны быть на русском языке.
Веб-формы и страницы веб-приложения должны проектироваться с учётом требований унификации:
все элементы пользовательского интерфейса должны быть выполнены Исполнителем в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;
- для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций, а также последовательности действий пользователя при их выполнении, должны быть унифицированы;
- внешнее поведение сходных элементов интерфейса должно быть реализовано одинаково для однотипных элементов.
Интерфейс Системы должен быть направлен на:
минимизацию производимых пользователем операций при переходе из одной системы в другую, от одной операции к другой (то есть должен быть эргономичным);
сокращение времени отклика Системы на действия пользователя (при выполнении длительных операций пользователь должен получать предупреждение о предстоящем времени ожидания, а в процессе выполнения операции видеть на экране динамику процесса).
Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных параметров. В указанных случаях Система должна будет выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
4.1.4. Требования к численности и квалификации персонала
Численность технического персонала должна быть достаточной для обеспечения бесперебойной работы Системы в соответствии с требованиями, определёнными в настоящем ТЗ, а также для функционирования Системы в штатном режиме, реализующем выполнение всех заявленных функций и работу в круглосуточном режиме.
Технический персонал, допущенный к эксплуатации и обслуживанию Системы, должен иметь подготовку и квалификацию, необходимую для обеспечения функционирования Системы.
Численность, квалификация и организационная структура технического персонала должны быть определены на этапе «Обследование и техническое проектирование».
Штатный состав персонала Системы должен формироваться на основании нормативных документов Российской Федерации, Трудового кодекса и нормативно-распорядительных документов Правительства Пермского края.
Пользователи Системы должны обладать квалификацией, обеспечивающей:
- базовые навыки работы на персональном компьютере с современными операционными системами (клавиатура, мышь, управление окнами и приложениями, файловая система);
- базовые навыки использования интернет-браузера (доступ к web-сайтам, навигация, формы и другие типовые интерактивные элементы web-интерфейса);
- знание основ информационной безопасности.
Специальные квалификационные требования предъявляются к обслуживающему персоналу Системы, который включает в себя системных администраторов.
Помимо наличия базовых навыков работы на персональном компьютере, к обслуживающему персоналу предъявляются следующие требования:
- знание принципов построения систем управления базами данных;
- наличие навыков работы с серверным и телекоммуникационным оборудованием;
- наличие расширенных знаний в области поддержки пользователей;
- знание основ администрирования операционных систем, серверов приложений и серверов баз данных.
Уровень квалификации обслуживающего персонала должен соответствовать требованиям производителей программного обеспечения и технических средств Системы, а также требованиям эксплуатационной документации.
Для подготовки дополнительного персонала в период эксплуатации Системы Исполнитель должен подготовить обучающие материалы, включающие руководство пользователя, руководство администратора.
4.1.5. Показатели назначения
Система должна обеспечивать следующий режим работы: доступность функций Системы в режиме – 24 часа в день, 7 дней в неделю (24х7), при основной нагрузке с 7:30 до 18:00.
Система должна обеспечивать возможность работы при следующих характеристиках времени отклика Системы:
- для операций навигации по экранным формам Системы (загрузка страниц, не содержащих больших отчетных форм, исключая запросы к внешним системам) – не более 10 сек.;
- для операций поиска (выполнение поискового запроса) – не более 10 сек.;
- для операций выгрузки отчетных форм – в зависимости от объема выгружаемых данных, не более 600 сек.
4.1.6. Требования к безопасности
Система должна соответствовать требованиям государственных стандартов Российской Федерации в области безопасности труда:
ГОСТ Р 50377-92: Безопасность оборудования информационной технологии, включая электрическое конторское оборудование;
ГОСТ Р 12.0.006-2002: Общие требования к управлению охраной труда в организации.
Электробезопасность технических средств Системы должна соответствовать требованиям Правил устройства электроустановок 1998 г.
Пожарная безопасность технических средств Системы должна соответствовать требованиям ГОСТ 12.1.004-91 ССБТ: «Пожарная безопасность».
Технические средства Системы должны соответствовать ГОСТ Р 50628-2000 «Совместимость машин электронных вычислительных персональных электромагнитная. Устойчивость к электромагнитным помехам. Технические требования и методы испытаний» и требованиям Госкомсвязи РФ «Автоматизированные системы управления аппаратурой электросвязи» 1998 г.
Уровень индустриальных помех, создаваемый при работе средств Системы, не должен превышать значений, установленных ГОСТ 21552-84.
Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов Системы (в том числе инфракрасное, ультрафиолетовое, рентгеновское и электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук строчной частоты и т.д.), не должны превышать действующих норм (СанПиН 2.2.2./2.4.1340-03 от 03.06.2003).
4.1.7. Требования к защите информации от несанкционированного доступа
Система должна соответствовать действующим в Российской Федерации законодательным актам и отвечать требованиям, предъявляемым к информационным системам, осуществляющим обработку защищаемой информации (в т.ч. персональных данных).
Система должна быть классифицирована в соответствии с требованиями законодательства и нормативно-правовых актов Российской Федерации. Результаты классификации оформляются соответствующим Актом классификации Системы, утверждаемым рабочей группой в составе Исполнителя, Заказчика и Функционального заказчика системы.
При выполнении работ, предусмотренных настоящим техническим заданием, должны быть определены угрозы безопасности обрабатываемой в Системе информации, оценены их вероятность (актуальность), возможные последствия их реализации. Определение типа угроз безопасности защищаемой информации, актуальных для Системы, проводится с учетом оценки возможного вреда. По отношению к каждой выявленной угрозе должен быть определен механизмы защиты и предложены соответствующие средства из числа входящих в состав Системы, а также средства защиты программно-аппаратного комплекса, на котором должна разворачиваться Система и ее компоненты. Должен быть сформирован документ «Модель угроз безопасности данных» информационной безопасности Системы.
Модель угроз безопасности данных должна определять:
защищаемые объекты;
основные угрозы безопасности информации, включая угрозы техногенного характера, стихийные бедствия и угрозы, реализуемые нарушителями;
критерии уязвимости Системы к деструктивным воздействиям.
классификацию типов возможных нарушителей информационной безопасности;
предположения об имеющейся у нарушителя информации;
основные каналы, цели и объекты атак;
предположения об имеющихся у нарушителя средствах;
перечень атак.
4.1.8. Требования к патентной чистоте
Использование программного обеспечения должно осуществляться в соответствии с требованиями Федерального закона от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации».
Используемое в целях создания и внедрения Системы программное обеспечение должно иметь соответствующие лицензии на его использование и быть свободным от обязательств перед третьими лицами.
В случае если при выполнении работ Исполнитель использует программы для электронных вычислительных машин (далее — ЭВМ) (системы управления базами данных, программные библиотеки, серверы приложений и иные объекты интеллектуальной собственности), разработанные Исполнителем или третьей стороной и не подразумевающие свободного использования, права (исключительные или неисключительные) на использование данных программ для ЭВМ должны быть переданы Заказчику.
Передаваемые права на программы для ЭВМ должны соответствовать требованиям к составу, количеству и характеристикам программного обеспечения (далее – ПО), представленным в рамках настоящего ТЗ. Объем передаваемых прав должен обеспечивать возможность использования СПО Системы на всей территории Пермского края в соответствии с назначением Системы и требованиями настоящего ТЗ. Срок действия прав – бессрочно либо на срок действия исключительных прав. Состав прав должен допускать модификацию ПО с привлечением Заказчиком третьих лиц. При этом, в составе СПО Системы не должны использоваться программы для ЭВМ, не подразумевающее свободного использования и не обеспеченные поддержкой производителя (разработчика). Программы для ЭВМ, не подразумевающие свободного использования, должны быть обеспечены гарантийным и постгарантийным обслуживанием фирмы-производителя, соответствующие обязательства должны быть переданы Заказчику.
До начала работ Исполнитель должен уведомить Заказчика об объектах интеллектуальной собственности, имеющих правовую охрану, принадлежащих Исполнителю или третьим лицам, которые планируется использовать при выполнении работ в соответствии с настоящим ТЗ.
Право собственности на разработанное в результате работ по созданию и внедрению Системы ПО, СПО, Систему в целом, а также иные права, необходимые для нормальной эксплуатации Системы по ее непосредственному назначению, передаются Исполнителем Заказчику в момент подписания Акта сдачи-приемки выполненных работ по последнему принятому этапу выполнения работ.
Создание и внедрение Системы должно осуществляться с учетом требований Постановления Правительства РФ от 16.11.2015 № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд».
4.1.9. Требования по стандартизации и унификации
Экранные формы должны проектироваться с учетом требований унификации:
все экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации;
для обозначения одних и тех же операций должны использоваться одинаковые графические значки, кнопки и другие управляющие (навигационные) элементы;
должны быть унифицированы термины, используемые для описания идентичных понятий, операций и действий пользователя;
реакция Системы на действия оператора (наведение указателя «мыши», переключение фокуса, нажатие кнопки) должна быть типовой для каждого действия над одними и теми же графическими элементами, независимо от их расположения на экране.
4.1.10. Дополнительные требования
Дополнительные требования не предъявляются.
4.1.11. Требования к электронным учебным курсам
Электронные учебные курсы должны быть доступны для каждого пользователя Системы в рамках имеющейся у него роли. Информация в электронных учебных курсах должна быть доступной и понятной.
4.2. Требования к функциям, выполняемым Системой
4.2.1. Требования к сценариям (процессам), автоматизируемым данной Системой
В рамках функционала Системы должен выполняться сценарий (процесс) формально-логического контроля (далее - ФЛК) поступающих в Систему данных.
Назначение сценария. Сценарий предназначен для осуществления формальной проверки поступающих из внешних ИС-источников данных на корректность.
Режимы запуска. Автоматический запуск синхронизации сервисов информационного обмена по расписанию не реже, чем раз в сутки; ручной запуск системным администратором.
Основные алгоритмы. Сценарий выполнения ФЛК состоит из следующих шагов:
1. Инициация сервисом информационного обмена на стороне Системы получения данных из внешних ИС-источников по расписанию (или ручной запуск системным администратором).
2. Загрузка полученных данных в верхний слой БД Системы.
3. Автоматическая проверка корректности загруженных данных по правилам ФЛК:
3.1. при отсутствии ошибок данных по итогам прохождения ФЛК – загрузка и сохранение данных в основном хранилище Системы и отображение данных в пользовательском интерфейсе Системы;
3.2. при выявлении ошибок по итогам прохождения ФЛК – сохранение данных в верхнем слое БД и блокировка данных для отображения в пользовательском интерфейсе Системы.
Логирование. Логирование событий, связанных с работой сценария, осуществляется средствами подсистемы «Администрирование и информационная безопасность».
Дополнительные требования. Автоматическая рассылка уведомлений администраторам Системы о результатах прохождения ФЛК загруженных данных.
Формальные правила проверки поступающих в Систему данных и правила уведомления должны быть разработаны на этапе «Обследование и техническое проектирование».
4.2.2. Требования к функциям подсистемы информационного взаимодействия
В рамках функций, выполняемых Системой, необходимо реализовать:
Разработку технологической подсистемы «Нормативно-справочная информация»;
Разработку технологической подсистемы «Интеграция со смежными системами»;
Разработку технологической подсистемы «Администрирование и информационная безопасность»;
Разработку функциональной подсистемы «Ввод данных»;
Разработку функциональной подсистемы «Аналитика»;
Разработку функциональной подсистемы «Мониторинг»;
Разработку функциональной подсистемы «Профилактика».
В вышеуказанный состав модулей должен быть включён и разработан web-интерфейс пользователя.
Вышеуказанный состав модулей должен обеспечивать работу в двух контурах:
Открытый контур:
1. Открытый контур должен обеспечивать работу с обезличенными данными, в зависимости от Роли Пользователя.
2. Записи данных открытого контура должны иметь уникальные идентификаторы (GUID).
Закрытый контур:
1. Закрытый контур Системы должен обеспечивать работу с информацией, содержащей Персональные данные, в зависимости от Роли Пользователя.
2. Данные из закрытого контура должны отображаться за счёт данных, полученных по уникальному идентификатору (GUID) из открытого контура и персональных данных, получаемых из внешних Систем.
Система должна обеспечивать функционал, необходимый для реализации порядка работы Пользователей. Порядок работы Пользователей описан в приложении Г.
4.2.2.1. Требования к технологической подсистеме «Нормативно-справочная информация»
Технологическая подсистема должна обеспечивать выполнение следующих функций:
- Обеспечение модулей Системы необходимыми справочниками;
- Хранение данных, вводимых в Систему в Базе Данных Системы.
- Обеспечение форматно-логистического контроля данных Системы;
- Обеспечение гибкой настройки форматно-логистического контроля данных Системы;
- Обеспечение функций поиска.
Форматно-логистический контроль данных должен обеспечивать непротиворечивость вводимых в Систему данных, оповещать Администратора Системы о возникающих противоречиях.
Должна быть предусмотрена возможность настройки шаблонов отслеживания противоречий.
Должен быть обеспечен механизм контроля вводимой в Систему информации, валидирующий вводимые Пользователем данные в соответствии с шаблонами отслеживания противоречий, и оповещающий Пользователя о вводе данных, противоречащих данным Системы.
Подсистема должна обеспечивать хранение данных, справочников, классификаторов, загружаемых в Систему.
Должна быть предусмотрена возможность полнотекстового поиска по информации, хранящейся в Системе и доступной в соответствии с ролью Пользователя.
Поля данных Системы описаны в приложении В.
4.2.2.2. Требования к технологической подсистеме «Интеграция со смежными системами»
Технологическая подсистема должна обеспечивать интеграцию с внешними информационными системами в следующем объёме:
| № п/п | Информационная система (ИС) | Владелец информационной системы (ИС) | Описание интеграции | Предоставляемые данные |
| 1 | ЕАИС «Социальный регистр населения» | Министерство социального развития Пермского края | Предоставление данных в ИС Профилактика | Информация о социальном обслуживании семьи; Информация о состоянии семьи; Информация о приёмных семьях; Информация об опеке; Информация о статусе семьи |
| 2 | «Краевая автоматизированная база данных о детях с ОВЗ» | Государственное казённое учреждение Пермского края «Центр психолого-педагогической, медицинской и социальной помощи» | Предоставление данных в ИС Профилактика | Информация о рекомендуемой образовательной программе ребёнка с ограниченными возможностями здоровья |
| 3 | ИС Контингент | Министерство информационного развития и связи Пермского края | Предоставление данных в ИС Профилактика | Персональные данные несовершеннолетних |
| 4 | ИС Мониторинг соц.сетей | Министерство информационного развития и связи Пермского края | Предоставление данных в ИС Профилактика | Аналитические показатели анализа социальных сетей |
Подсистема должна позволять автоматизировано либо автоматически получать данные с заданной периодичностью.
Подсистема должна обеспечивать механизмы настройки наборов данных, получаемых из внешних систем, и приведения даных к виду, используемому для хранения в подсистеме «Нормативно-справочная информация».
Подсистема должна обеспечивать приведение данных к виду, используемому для хранения в подсистеме «Нормативно-справочная информация», и должна обеспечивать гарантированный трансфер данных в подсистему «Нормативно-справочная информация» при получении.
Подсистема должна обеспечивать интеграцию данных из нескольких систем в интерфейсе Пользователя в случае работы с данными разных контуров.
На этапе «Обследование и техническое проектирование» Заказчиком должен быть утвержден перечень показателей, получаемых из внешних ИС-источников, с учетом степени публичности этих данных.
Порядок информационного обмена должен определяться регламентами информационного взаимодействия, которые должны быть подготовлены на этапах 2 и 3 «Разработка программного обеспечения и предварительные испытания» раздела 5 настоящего ТЗ.
Должна быть предусмотрена возможность интеграции Системы с другими внешними информационными системами.
4.2.2.3. Требования к технологической подсистеме «Администрирование и информационная безопасность»
Технологическая подсистема должна обеспечивать выполнение следующих функций:
- Обеспечение разделения прав доступа пользователей к Системе в соответствии с ролевой моделью;
- Обеспечение информационной безопасности при работе с Открытым и Закрытым контурами Системы;
- Обеспечение возможности создания профилей ситуаций для автоматического мониторинга в Системе.
Роли Пользователей описаны в Приложении Б.
4.2.2.4. Требования к функциональной подсистеме «Ввод данных»
Функциональная подсистема должна обеспечивать функционал ввода данных в Систему путём предоставления Пользователю web-форм, соответствующих его Роли.
Требования могут быть уточнены на этапе «Обследование и техническое проектирование».
4.2.2.5. Требования к функциональной подсистеме «Аналитика»
Функциональная подсистема должна обеспечивать вывод информации с помощью различных инструментов (форм, отчётов, таблиц и т. д.) и должна выполнять функции формирования аналитических и статистических отчётов, в зависимости от роли пользователя:
1) Органы управления образования.
a. Специалист Министерства образования и науки Пермского края.
a.i. Форма мониторинга несовершеннолетних, находящихся в "группе риска" образовательных организаций;
a.ii. Форма мониторинга по выявлению фактов насилия в семьях;
a.iii. Форма мониторинга по случаям суицида среди несовершеннолетних;
a.iv. Отчёт по учащимся, не приступившим к занятиям в школе на дату;
a.v. Форма мониторинга учета несовершеннолетних с риском суицидального поведения;
a.vi. Форма мониторинга учета семей и детей группы риска социально опасного положения.
b. Специалист органа управления образования муниципального района (городского округа).
b.i. Форма мониторинга несовершеннолетних, находящихся в "группе риска" образовательных организаций.
2) Образовательное учреждение (школа, профессиональная образовательная организация).
a. Классный руководитель (куратор).
a.i. Форма мониторинга несовершеннолетних, находящихся в "группе риска" образовательных организаций.
b. Заместитель директора по воспитательной работе (социальный педагог).
b.i. Форма мониторинга несовершеннолетних, находящихся в "группе риска" образовательных организаций.
3) Комиссия по делам несовершеннолетних и защите их прав.
a. Специалист краевой комиссии по делам несовершеннолетних и защите их прав.
a.i. Мониторинг учета детей и семей, находящихся в СОП.
b. Специалист районной (городской) комиссии по делам несовершеннолетних и защите их прав.
b.i. Мониторинг учета детей и семей, находящихся в СОП.
4) ГУ МВД РФ по Пермскому краю.
a. Сотрудник отделения организации деятельности ПДН ГУ МВД РФ по Пермскому краю.
a.i. Мониторинг ежеквартальный (статистические сведения).
b. Инспектор ПДН территориального ОВД.
b.i. Мониторинг ежеквартальный (статистические сведения, персональные данные).
5) Министерство здравоохранения Пермского края.
a. Главный внештатный специалист Министерства здравоохранения Пермского края.
a.i. Форма мониторинга несовершеннолетних, находящихся в "группе риска".
b. Районный педиатр, заведующий отделением МСП медицинской организации Пермского края.
b.i. Форма мониторинга несовершеннолетних, находящихся в "группе риска".
c. Специалист по социальной работе медицинской организации Пермского края.
c.i. Форма мониторинга несовершеннолетних, находящихся в "группе риска".
Соответствующие ролям формы описаны в Приложении А.
4.2.2.6. Требования к функциональной подсистеме «Мониторинг»
Функциональная подсистема должна обеспечивать выполнение следующих функций:
оценка рисков в соответствии с картами рисков;
гибкое изменение методики оценки;
отображение данных субъектов разных групп;
уведомление пользователей о событиях, связанных с их субъектами.
Функциональная подсистема должна использовать модели оценки рисков, описанные в приложении Д.
4.2.2.7. Требования к функциональной подсистеме «Профилактика»
Функциональная подсистема предназначена для автоматизации работы сотрудников образовательных учреждений и должна обеспечивать выполнение следующих функций:
уведомление об изменении уровня рисков, связанных с субъектами Пользователя;
ведение плана мероприятий по профилактике рисков;
ведение расписания профилактических работ в разрезе отдельных субъектов;
контроль исполнения мероприятий;
контроль заполнения форм в соответствии с ролями Пользователей.
4.3. Требования к видам обеспечения
4.3.1. Требования к информационному обеспечению
Информационное обеспечение представляет собой совокупность всех необходимых для функционирования Системы данных (нормативно-справочная информация, базы данных, системы управления базами данных, информационные объекты, в т.ч. входные и выходные данные).
В Системе должна использоваться единая система кодирования данных, соответствующая требованиям отраслевых нормативных документов.
Термины и сокращения, применяемые в выходных документах Системы, должны быть общепринятыми в данной предметной области и согласованы с Заказчиком.
Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими функциональными подсистемами использоваться.
Информационный обмен между компонентами Системы должен осуществляться без вмешательства пользователя и без повторного ручного ввода информации.
Информационный обмен между компонентами Системы и клиентскими приложениями должен осуществляться по локальной сети и по сети Интернет.
Для хранения данных должна использоваться реляционная БД в составе Системы, обеспечивающая реализацию встроенных механизмов построения индексов и контроля целостности данных.
Доступ к данным должен быть предоставлен только авторизованным пользователям с учётом их служебных полномочий.
Состав данных должен быть достаточным для выполнения всех функций Системы и отвечать требованиям полноты, достоверности, однозначной идентификации, непротиворечивости и необходимой точности представления.
Требования к составу данных, набору сущностей, атрибутов первичных данных, периодичности обновления данных Системы должны быть уточнены и согласованы с Заказчиком на этапе «Обследование и техническое проектирование».
4.3.2. Требования к лингвистическому обеспечению
Все экранные формы, выходные формы, инструкции по работе, вся документация должны быть выполнены на русском языке.
Исключения могут составлять только системные сообщения, не подлежащие русификации. Данные сообщения не должны отображаться в пользовательском интерфейсе.
4.3.3. Требования к техническому обеспечению
Требования к техническому обеспечению должны быть уточнены на этапе «Обследование и техническое проектирование».
Исполнитель должен сформулировать предложение по размещению Системы, исходя из заданных параметров производительности, доступности и информационной безопасности. Предложение по размещению в части требуемых мощностей должно быть описано в документе «Описание архитектуры ИС Профилактика», обосновано результатами нагрузочного тестирования и согласовано с Заказчиком.
Для размещения серверов Системы должна использоваться виртуальная инфраструктура Заказчика.
4.3.4. Требования к программному обеспечению
Специальное программное обеспечение (СПО) Системы должно обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях программное обеспечение должно выдавать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
При разработке СПО Системы должен производиться учёт версий (с указанием даты выпуска, укрупнённого состава решаемых задач и перечня внесённых изменений).
Разработка СПО Системы должна проходить на базе свободно-распространяемого общего программного обеспечения и общего программного обеспечения с открытым исходным кодом. Программное обеспечение, используемое для выполнения настоящих работ, должно соответствовать требованиям Постановления Правительства РФ от 16 ноября 2015 г. № 1236 «Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд».
4.3.5. Требования к организационному обеспечению
В ходе выполнения работ должно обеспечиваться постоянное взаимодействие между Исполнителем и Заказчиком по вопросам, имеющим непосредственное отношение к выполнению условий Государственного контракта:
решения административных вопросов (организация встреч, предоставление допусков, рассмотрение и согласование документации и т.п.);
решения инженерно-технических вопросов (согласование технических аспектов реализации и администрирования Системы, определение наличия и размещения технических средств, коммуникаций и т.п.);
нормативно-методического и информационного обеспечения проектных работ (уточнение функциональных характеристик, предоставление дополнительных сведений).
Исполнитель по запросу Заказчика направляет специалиста(ов) на рабочие совещания и презентации. Запрос Заказчика на участие в совещании или презентации специалистов Исполнителя направляется не позднее 2 (двух) рабочих дней до срока проведения.
4.3.6. Требования к телекоммуникационному обеспечению Системы
4.3.6.1. Необходимые линии и каналы связи
Связь между компонентами разрабатываемой Системы должна осуществляться с использованием локальной сети и сети Интернет.
4.3.6.2. Среда передачи
Связь между компонентами разрабатываемой Системы должна осуществляться с использованием локальной сети и сети Интернет.
4.3.6.3. Технические параметры каналов связи
Специальные требования не предъявляются.
4.3.6.4. Пропускная способность, интерфейсы, топология и т.п.
Пропускная способность каналов связи должна быть не ниже 2 Мбит/с.
4.3.6.5. Необходимость организации новых каналов связи либо возможность использования существующей телекоммуникационной инфраструктуры
Требования к организации новых каналов не предъявляются.
Дата добавления: 2018-11-24; просмотров: 239; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!