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

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

Муниципальный сегмент оценки доступности ОСИ должен обеспечивать хранение информации обо всех действиях пользователя (внесение, изменение, удаление и т.п.) в отношении объектов данных Системы. При этом должны быть зафиксированы дата операции, пользователь, тип операции, параметры операции и идентификатор изменяемого объекта.

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

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

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

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

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

Муниципальный сегмент оценки доступности ОСИ должен иметь интуитивно-понятный пользовательский интерфейс.

Элементы интерфейса должны быть стандартизованы для всех форм отображения и редактирования данных.

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

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

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

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

Идентификация пользователей должна осуществляться по связке «имя пользователя и пароль».

В момент запуска ИС «Доступная Среда» должен производиться запрос ввода имени пользователя и пароля доступа к ИС «Доступная Среда». Введенные данные должны определять пользователя на время сеанса работы с ИС «Доступная Среда».

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

Роль должна регламентировать доступ пользователя ИС «Доступная Среда» к функциям и объектам ИС «Доступная Среда».

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

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

Доступ к ИС «Доступная Среда» посредством Web-браузера (тонкий клиент) должен иметь возможность использования SSL сертификатов и защищенного протокола HTTPS, тем самым обеспечивая защиту и конфиденциальность передачи данных.

Авторизация в ИС «Доступная Среда» должна предусматривать доступ к функциям приложения, а не к серверу базы данных.

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

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

Взаимодействие с АРМ пользователей Подсистемы информационного обеспечения должно осуществляться по протоколу HTTP посредством сети «Интернет» и ведомственных информационных сетей, при необходимости с реализацией мер защиты каналов связи. В качестве клиентского приложения должны использоваться универсальные интернет-обозреватели (веб-браузеры). Для реализации функций печати и загрузки файловых объектов допускается использование загружаемых модулей, соответствующих основным типам поддерживаемых браузеров и операционных систем. Доступ к Порталу и АРМ владельца объекта должен осуществляться посредством сети «Интернет».

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

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

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

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

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

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

Требования к численности и квалификации персонала (пользователей)

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

Требования к показателям назначения

Поступление информации в систему с удаленных рабочих мест должно производиться в условиях пропускной способности канала доступа от рабочего места оператора к серверу от 25 кб/c – через WEB-интерфейс (режим «тонкого клиента»).

Муниципальный сегмент оценки доступности ОСИ должен обеспечивать функционирование в штатном режиме круглосуточно, без выходных («режим 24*7») с допустимыми регламентными перерывами на техническое обслуживание суммарной длительностью не более 4 часов в месяц и длительностью каждого перерыва не более 1 часа (с полным отключением Системы).

Муниципальный сегмент оценки доступности ОСИ должен обеспечивать возможность одновременной работы не более 25 служебных пользователей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В целях защиты данных от несанкционированного использования должна использоваться система идентификации пользователей.

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

Идентификация пользователей должна осуществляться по связке «имя пользователя и пароль».

В момент запуска муниципального сегмента оценки доступности ОСИ должен производиться запрос ввода имени пользователя и пароля. Введенные данные должны определять пользователя на время сеанса работы с муниципальным сегментом..

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

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

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

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

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

СУБД должна обеспечивать надежность, безопасность, высокую производительность и удобство в работе.

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

СУБД должна поддерживать мультиплатформенность и должна иметь возможность быть установленной на различные операционные системы – Microsoft Windows, Unix (Linux).

Требования к патентной чистоте и защите авторских прав

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

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

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

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

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

Требования к функциям, выполняемым муниципальным сегментом оценки доступности ОСИ

Общие требования

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

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

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

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

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

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

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

Требования к муниципальному сегменту оценки доступности ОСИ

Муниципальный сегмент должен выполнять задачи автоматизации оценки доступности ОСИ для МГН.

Муниципальный сегмент должен обеспечивать процесс обследования ОСИ муниципального образования (как плановый, так и внеплановый, в том числе с учетом обращений граждан). В муниципальном сегменте должна быть возможность подготовить список ОСИ для планового и/или внепланового обследования состояния доступности для МГН. Этот план должен использоваться ОСЗН (или иными уполномоченными органами) для работы по обследованию ОСИ.

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

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

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

«Черновик». Это состояние означает, что программа проверок находится на редактировании. В этом состоянии программа доступна редактированию.

«На проверке». Это состояние означает, что программа заполнена ответственным органом или пользователем, объекты добавлены в программу;

«К исправлению». Это состояние означает, что данная программа подлежит исправлению. В этом состоянии программа доступна редактированию;

«Проверен». Это состояние означает, что данная программа проверена ответственным органом или пользователем;

«Утвержден». Это состояние означает, что программа утверждена контролирующим органом. Переход между состояниями «Черновик – Проверен» может быть доступен как для операторов ответственного за заполнение органа или пользователя, так и для операторов контролирующего органа. Переход между состояниями «Проверен – Утвержден» может быть доступен только для контролирующего учреждения.

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

Основанием могут выступать:

- обращения граждан;

- проведенная реконструкция объекта;

- распоряжение руководства.

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

Статус;

Категория;

Номер обследования;

ОСИ;

Адрес объекта;

Дата актуальности нормативов;

Дата актуальности обследования.

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

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

Сохраненная карточка обследования должна открываться при: двойном клике на запись; клике на кнопку «Редактировать», которая должна располагаться напротив каждой записи. Удаление обследования должно осуществляться при клике на кнопку «Удалить», которая должна располагаться напротив каждой записи.

Карточка обследования объекта должна содержать следующие характеристики из соответствующей карточки объекта:

Наименование объекта;

Адрес объекта.

Карточка обследования объекта должна содержать следующие дополнительные характеристики:

Номер обследования;

Дата актуальности нормативов;

Дата актуальности обследования;

Программа обследования;

Руководитель рабочей группы;

Члены рабочей группы;

Таблица анкет обследования;

Обращения прикрепленные к обследованию.

Непосредственно процесс обследования ОСИ должен сопровождаться заполнением формы «Анкета обследования». Для одного ОСИ должна быть возможность формирования нескольких разных анкет. Заполнение анкет должно быть доступно для уполномоченных пользователей ОСЗН или других ОИВ. Кроме того, должна быть предусмотрена возможность заполнения анкеты зарегистрированным собственником или арендатором ОСИ. Однако в таком случае необходимо использование инструмента согласования заполненной анкеты с ответственным ОСЗН или другим ОИВ.

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

Сохраненная карточка обследования должна открываться при: двойном клике на запись; клике на кнопку «Редактировать», которая должна располагаться напротив каждой записи. Удаление обследования должно осуществляться при клике на кнопку «Удалить», которая должна располагаться напротив каждой записи.

Карточка анкеты должна содержать следующие характеристики:

Номер анкеты;

Примечание;

Таблица зон обследования.

Зоны обследования должны автоматически добавляться в анкету обследования из структуры объекта, созданной в карточке объекта. Если в карточке объекта не добавлены зоны, пользователю, должно выводиться соответствующие сообщение. Зоны в анкете обследования должны быть представлены в виде таблицы со следующими полями:

Статус;

Зона;

Территориальный элемент;

Примечание;

Светофор доступности зоны.

Переход к заполнению анкеты обследования должен быть осуществлен из таблицы зон обследования после нажатия кнопки «Анкетирование».

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

Наименование норматива;

Описание норматива;

Отметка об обязательности;

Значение;

Светофор доступности;

Рекомендации;

Примечание.

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

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

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

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

«Черновик». Это состояние означает, что функциональный элемент находится на редактировании. В этом состоянии функциональный элемент доступен для редактирования.

«На проверке». Это состояние означает, что функциональный элемент заполнен ответственным органом или пользователем;

«К исправлению». Это состояние означает, что данный функциональный элемент подлежит исправлению. В этом состоянии функциональный элемент доступен для редактирования;

«Утвержден». Это состояние означает, что функциональный элемент утвержден контролирующим органом. Переход между состояниями «Черновик – На проверке» может быть доступен как для операторов ответственного за заполнение органа или пользователя, так и для операторов контролирующего органа. Переход между состояниями «На проверке – Утвержден» может быть доступен только для контролирующего учреждения.

Муниципальный сегмент должен обеспечивать проверку корректности введенных данных и степени заполнения обязательных полей. Данная проверка должна осуществляться в момент перевода статуса между состоянии «Черновик – На проверке» и «К исправлению – На проверке». Если в муниципальном сегменте обнаружена ошибка корректности данных или незаполненные обязательные поля, в момент перевода статуса пользователю должно выводиться соответствующие сообщение с указанием причины появления сообщения.

При переводе статуса у анкеты обследования на состояние «Утверждено» муниципальный сегмент должен автоматически создавать карточку Паспорта доступности объекта в реестре паспортов.

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

АРМ инспектора. Должен обеспечивать доступ к функциям заполнения паспортов объектов (в части анкетирования), а также к просмотру планов мероприятий и регистрации их результатов;

АРМ владельца объекта социальной инфраструктуры.

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

просмотр планов выездных мероприятий;

поиск и просмотр паспортов ОСИ, в т.ч. по данным о местонахождении пользователя;

просмотр положения ОСИ на карте;

заполнение опросных листов (анкет) и протоколов обследования ОСИ.