4.Требования к системе
4.1.Требования к системе в целом
4.1.1.Требования к структуре и функционированию системы
4.1.1.1.Перечень подсистем, их назначение, основные характеристики и состав
4.1.1.1.1.Требования к ГИС-платформе
ГИС-платформа должна содержать следующие функциональные модули:
Модуль работы с пространственными данными;
Модуль публикации пространственных данных.
Модуль работы с пространственными данными – это модуль, обеспечивающий работу по ведению пространственных данных (создание, изменение, удаление).
Модуль публикации пространственных данных – это модуль, обеспечивающий публикацию пространственных данных для обеспечения в дальнейшем их общего просмотра или скачивания.
4.1.1.1.2.Требования к ГИС-порталу
ГИС-портал должен содержать следующие функциональные модули:
Модуль предоставления справочных сведений
Модуль работы с метаданными
Модуль работы с пространственными продуктами
Модуль мониторинга качества
Модуль управления доступом
Модуль лицензирования
Модуль предоставления справочной информации – модуль, обеспечивающий предоставление пользователям справочной информации о проекте, сведений о популярных продуктах, последних обновлений, информации для разработчиков, а также обеспечивающий возможности просмотра общей и детальной информации о картах.
Модуль предоставления справочной информации должен решать следующие задачи:
Возможность получения статистической информации;
Получение информации о последних обновлениях;
Работа с картами.
Модуль работы с метаданными – это модуль, обеспечивающий процессы создания метаданных пространственных данных, их централизованного хранения, публикации и предоставления к ним доступа.
Модуль работы с метаданными должен решать следующие задачи:
создание и децентрализованное хранение метаданных по всем пространственным данным в едином формате;
возможность быстрого поиска метаданных по различным критериям и различным местам хранения;
управление пользователями и их правами;
обмен метаданными.
Модуль должен представлять Пользователям метаданные в открытом формате XML. Метаданные пространственных данных должны включать:
уникальный идентификатор набора метаданных;
ключевые слова для обеспечения поиска информации;
описание данных (наименование, дата создания, система координат, масштаб или пространственное разрешение, географическое положение и т.д.);
сведения об административных органах, которые отвечают за создание наборов пространственных данных и WEB-сервисов, их актуализацию и распространение;
условия доступа к данным и WEB-сервисам;
существующие ограничения на доступ к данным и их использование;
качество и степень достоверности пространственных данных;
другие характеристики в соответствии со спецификой описываемых наборов данных и WEB-сервисов.
Модуль работы с пространственными продуктами – модуль, предоставляющий возможность просмотра общей и детальной информации о пространственных продуктах и возможность их скачивания
Модуль мониторинга качества – модуль, обеспечивающий мониторинг качества и уровня доступности сервисов, гибкую настройку правил мониторинга и уведомление ответственных сотрудников в случае некорректной работы контролируемых сервисов.
Модуль мониторинга качества обеспечивает выполнение следующих групп функций:
-
Регистрация – группа функций, позволяющая регистрировать сервисы для мониторинга и управлять списком заданий мониторинга
Управление – группа функций управления списком зарегистрированных для мониторинга сервисов. Если для одного сервиса создано несколько заданий мониторинга, то для каждого задания в список добавляется запись.
Статистика – группа функций, реализующих возможности сбора и отображения статистической информации о качестве и доступности сервисов.
Модуль управления доступом – модуль, обеспечивающий работу по администрированию системы, по созданию и контролю пользователей, групп пользователей, ведению учетных записей и пр., настройке политик безопасности и организации защищенного доступа к продуктам.
Модуль лицензирования – модуль, обеспечивающий выполнение лицензионных соглашений, управление лицензиями, реализующий функциональность по созданию и ведению лицензионных моделей и работу с лицензионно-защищенными сервисами.
4.1.1.2.Требования к режимам функционирования системы
Система должна функционировать в трех режимах:
Штатный – режим работы, при котором осуществляется обслуживание запросов пользователей.
Профилактический – режим работы, при котором проводятся плановые профилактические работы. Обслуживание запросов пользователей ограничено.
Аварийно-восстановительный – режим восстановления работоспособности системы после аварий и сбоев, при котором обслуживание запросов пользователей не выполняется.
Штатный режим функционирования является основным при эксплуатации системы и должен выполняться в условиях стабильной работы СПО, КТС и каналов передачи данных. В данном режиме система должна обеспечивать выполнение всех заявленных функций.
В профилактическом режиме должны осуществляться профилактические работы по обслуживанию системы, а также обновление ПО и ППО. Техническое обслуживание должно проводиться эксплуатационным персоналом системы и включает в себя следующие работы:
контроль технического состояния оборудования;
замена оборудования (в случае необходимости);
обслуживание оборудования в соответствии с требованиями инструкций по эксплуатации этого оборудования фирм-производителей;
обновление ПО;
резервное копирование.
В профилактическом режиме допускается остановка системы. В этом случае доступ пользователей к системе невозможен.
В аварийно-восстановительном режиме эксплуатационным персоналом должно осуществляться восстановление работоспособности системы после сбоев.
Данный режим должен использоваться в следующих ситуациях:
отказ серверного оборудования и серверного программного обеспечения;
отказ активного сетевого оборудования;
отказ внутренних линий связи между компонентами системы.
При восстановлении после сбоев должны осуществляться работы:
по текущему ремонту оборудования;
по настройке (установке/переустановке) программного обеспечения;
работы по восстановлению данных из резервных копий.
В аварийно-восстановительном режиме после сбоев доступ пользователей к системе невозможен.
4.1.2.Требования к характеристикам взаимосвязей создаваемой системы со смежными системами
Минимальным требованием к внешним системам для интеграции в качестве частного узла в ИПД РФ является развертывание портала метаданных и подготовка метаданных на предоставляемые пространственные продукты в соответствии с утвержденным в ИПД РФ профилем метаданных.
4.1.3.Требования по диагностированию системы
В системе должны быть предусмотрены следующие мероприятия по диагностированию:
Проверка доступности взаимосвязанных систем и баз данных;
Диагностирование подсистем и модулей подготовки, хранения и публикации пространственных данных.
Система должна выдавать диагностические сообщения о нарушении работоспособности на русском языке.
4.1.4.Перспективы развития, модернизации системы
При разработке системы должны быть предусмотрены возможности ее последующего развития и модернизации по следующим направлениям:
расширение функциональных возможностей за счет дополнительной разработки и/или внедрения новых подсистем и модернизации штатных;
расширение числа поставщиков и потребителей информации в рамках разработанной технологии информационного взаимодействия.
4.1.5.Требования к численности, квалификации персонала и режиму его работы
Численность персонала, имеющего доступ к Системе, и режим его работы определяется Государственным заказчиком на этапе опытной эксплуатации.
Количество пользователей Системы ограничено только мощностями ПТК Государственного заказчика.
Для обеспечения функционирования Системы должен быть выделен администратор баз данных и системный администратор.
При обслуживании Системы допускается совмещение сотрудниками функциональных обязанностей.
Для обеспечения круглосуточного режима работы Системы необходимо круглосуточное обслуживание аппаратного и программного обеспечения Системы.
Штатный состав персонала, эксплуатирующего Систему, должен формироваться на основании нормативных документов Российской Федерации и Трудового кодекса РФ.
Допускается обслуживание программного обеспечения Системы с использование инструментов удалённого администрирования.
4.1.6.Требования к надёжности системы
Система должна обеспечивать работоспособность круглые сутки ежедневно в течение календарного года за исключением периодов проведения плановых регламентных работ по обслуживанию и восстановления Системы после аварий.
Система должна предоставлять возможность проведения плановых регламентных работ по обслуживанию оборудования и программного обеспечения: обновление версий ПО, обновление баз данных, резервное копирование и т.п.
На период опытной эксплуатации Системы время начала восстановительных работ после аварий не должно превышать 2 часов после аварии.
Система должна сохранять работоспособность и обеспечивать восстановление своих функций при возникновении следующих внештатных ситуаций:
При сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке операционной системы (ОС), восстановление программы должно происходить после перезапуска ОС и запуска исполняемого файла Системы;
При ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функции Системы возлагается на ОС;
При ошибках, связанных с программным обеспечением (ОС и драйверы устройств), восстановление работоспособности возлагается на ОС.
4.1.7.Требования к безопасности
Защита технических средств, на которых реализованы компоненты Системы, от воздействий электрического тока, электромагнитных полей, акустических шумов и т.п. должна осуществляться в соответствии с требованиями по эксплуатации, предъявляемыми к оборудованию его разработчиками.
4.1.8.Требования к эргономике и технической эстетике
Взаимодействие пользователей с системой должно осуществляться посредством визуального графического интерфейса. Ввод-вывод данных, прием управляющих команд и отображение результатов их исполнения должны выполняться в интерактивном режиме, в реальном масштабе времени. Интерфейс должен соответствовать современным эргономическим требованиям и обеспечивать удобный доступ к основным функциям и операциям, выполняемым системой.
Интерфейс должен быть рассчитан на преимущественное использование манипулятора типа «мышь», то есть управление системой должно осуществляется с помощью набора экранных меню, кнопок, значков и тому подобных элементов. Клавиатурный режим ввода должен использоваться, главным образом, при заполнении/редактировании текстовых и числовых полей экранных форм.
В разделах интерфейса для обозначения сходных операций должны использоваться сходные графические значки, кнопки и другие управляющие (навигационные) элементы. Термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных и т.п.), а также последовательности действий пользователя при их выполнении, должны быть унифицированы.
Внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки и т.п.) должно реализовываться одинаково для однотипных элементов.
Необходима стандартизация с формами и страницами графического интерфейса, используемыми в базовом или системном ПО, а также с ПО аналогичного назначения.
Интерфейс системы должен быть выполнен в едином стилевом решении с типовыми примерами: портал государственных и муниципальных услуг, публичная кадастровая карта (http://maps.rosreestr.ru/Portal/).
Все надписи экранных форм, а также сообщения, выдаваемые пользователю должны быть на русском языке. Исключения могут составлять только системные сообщения, не подлежащие русификации.
Система должна обеспечивать отображение информации о назначении своих элементов управления в виде надписей или подсказки о назначении инструмента при наведении курсора мыши на пиктограммы.
Система должна обеспечивать корректную обработку аварийных ситуаций, вызванных неверными действиями пользователей, неверным форматом или недопустимыми значениями входных данных. В указанных случаях система должна возвращать пользователю соответствующие сообщения, после чего возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой) команде или некорректному вводу данных.
Система должна позволять однозначно интерпретировать информацию о своем состоянии: работает или находится в нерабочем состоянии.
4.1.9.Требования к эксплуатации, техническому обслуживанию и ремонту компонентов системы
В штатном режиме система должна функционировать 24 часа в сутки, 7 дней в неделю, в течение года с заданными показателями надежности с плановыми перерывами для проведения регламентного или разового обслуживания.
Условия и режим эксплуатации должны обеспечивать использование системы с заданными показателями.
Обслуживание системы должно производиться системными администраторами и сертифицированными специалистами в период плановых перерывов или в случае сбоев в арботе системы.
4.1.10.Требования к защите информации от несанкционированного доступа
Обеспечение информационной безопасности в системе должно быть организовано в соответствии с требованиями российского законодательства.
Система должна включать следующие уровни защиты доступа к программным компонентам Системы:
безопасность доступа к операционной системе;
защита доступа к исполняемым файлам системы;
разграничение прав доступа пользователей к системе.
4.1.11.Требования по сохранности информации при авариях
В случае возникновения аварии или сбоя в процессе выполнения пользовательских задач должно быть обеспечено восстановление базы данных до состояния на момент последней завершённой системой транзакции.
4.1.12.Требования к патентной чистоте и лицензированию
Система должна отвечать требованиям по патентной чистоте согласно действующему законодательству Российской Федерации.
Используемое программное обеспечение системы (за исключением вновь разрабатываемого в рамках проекта) должно иметь лицензии производителей.
Система должна отображать копирайты и ссылки на информацию о правообладателях на данные, на оформление данных и карт и программные приложения.
Система должна предоставлять пользователям соглашение об использовании (пользовательское соглашение).
4.1.13.Требования к стандартизации и унификации
При выполнении работы должны использоваться международные стандарты и документы, разработанные в ходе реализации Директивы Европейского Парламента и Совета ЕС по созданию инфраструктуры пространственных данных Евросоюза (INSPIRE), принятой 14 марта 2007 г.
|
