«Министерство труда и социальной защиты населения Республики Башкортостан методика формирования и обновления ...»

ОБЩИЕ СВЕДЕНИЯ

Наименования и обозначения

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

Сокращенные наименования: муниципальный сегмент ИС «Доступная среда» (далее - Система).

Наименование Заказчика

Наименование муниципального образования Республики Башкортостан

Основания для разработки

Постановление Правительства Российской Федерации от 17 марта 2011 г. №175 «О государственной программе Российской Федерации «Доступная среда» на 2011-2015 годы»;

Постановление Правительства Республики Башкортостан от 28.04.2011 г. № 130 «О республиканской целевой программе «Доступная среда» на 2011-2015 годы.

Источник финансирования заказа

Размер средств бюджета муниципального образования

Форма, сроки и порядок оплаты товара, работ, услуг

Оплата осуществляется по факту оказания услуг на основании акта сдачи-приемки, подписанного сторонами.

Оплата осуществляется по безналичному расчету путем перечисления Заказчиком денежных средств на расчетный счет Исполнителя в полном объеме после получения от Исполнителя счета на оплату.

Изменение объема оказываемых услуг. Процент изменения объема оказываемых услуг.

Не допускается.

Заключение договора (контракта, соглашения) с несколькими участниками размещения заказа

Не допускается.

Сроки оказания услуг

Не позднее ________________, гарантийное обслуживание в течение календарного года с момента подписания акта сдачи-приемки выполненных работ.

НАЗНАЧЕНИЕ И ЦЕЛИ

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

Муниципальный сегмент предназначен для автоматизации следующих операций:

• автоматизация оценки доступности ОСИ для МГН;
• автоматизация планирования проверок ОСИ;
• обеспечение процесса обследования ОСИ (как плановое, так и внеплановое, в том числе по обращениям граждан);
• формирование форм анкет для оценки доступности ОСИ.

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

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

Цели поставки муниципальный сегмента

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

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

ХАРАКТЕРИСТИКА ОБЪЕКТА АВТОМАТИЗАЦИИ

Общие сведения об автоматизируемой деятельности

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

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

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

Конвенция ООН о правах инвалидов;

Градостроительный кодекс Российской Федерации от 29 января 2004 г. № 190-ФЗ;

Федеральный закон от 24.11.1995 №181-ФЗ «О социальной защите инвалидов в Российской Федерации»;

Постановление Правительства Российской Федерации от 07 декабря 1996 г. № 1449 «О мерах по обеспечению беспрепятственного доступа инвалидов к информации и объектам социальной инфраструктуры»;

Постановление Правительства Российской Федерации от 16 февраля 2008 г. № 87 «О составе разделов проектной документации и требованиях к их содержанию»;

Постановление Правительства Российской Федерации от 17 марта 2011 г. № 175 «О государственной программе Российской Федерации «Доступная среда» на 2011-2015 годы»;

Постановление Правительства Республики Башкортостан от 28.04.2011 г. № 130 «О республиканской целевой программе «Доступная среда» на 2011-2015 годы»;

СП 59.13330.2012 Свод правил «СНиП 35-01-2001 “Доступность зданий и сооружений”».

Для паспортизации действующих объектов проводятся следующие работы:

инвентаризация собственных, подведомственных и курируемых объектов городской инфраструктуры;

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

составление по установленной форме паспортов доступности обследованных объектов и внесение данных сведений в информационную систему;

актуализация паспорта доступности объекта после выполнения работ по его приспособлению.

Проблемами существующей процедуры паспортизации являются:

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

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

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

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

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

Автоматизируемые административные функции и процессы

Анкетирование и паспортизация общественных зданий и сооружений

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

В целях повышения оперативности указанных процедур в рамках Системы необходимо:

реализовать мобильное АРМ, обеспечивающее непосредственный ввод данных анкетирования в централизованную базу данных, таким образом, стадии анкетирования и паспортизации должны быть в значительной степени объединены с исключением необходимости в составлении промежуточных бумажных документов;

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

ТРЕБОВАНИЯ К СИСТЕМЕ

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

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

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

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

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

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

Для муниципального сегмента оценки доступности ОСИ должна быть реализована возможность работы в режиме тонкого клиента (работа пользователя осуществляется через Web-браузер), функционирующего в различных операционных средах – Microsoft Windows, Unix (Linux).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Статус;

Категория;

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

ОСИ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание;

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

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

Статус;

Зона;

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

Примечание;

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

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

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

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

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

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

Значение;

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования к видам обеспечения

Информационное обеспечение

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

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

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

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

прикладных и служебных данных;

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

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

При наличии требований к формированию в рамках реализуемых по настоящему ТЗ функций муниципального сегмента юридически значимых документов на бумажном носителе, придание юридического значения электронным документам, должно осуществляться путем использования соответствующих типу документа средств электронной цифровой подписи в соответствии с требованиями Федерального закона Российской Федерации от 6 апреля 2011 г. N 63-ФЗ «Об электронной подписи».

Программное обеспечение

АРМ Системы должны быть рассчитаны на использование браузеров с поддержкой HTML 4.0, CSS Level 2, JavaScript 1.1. и выше, режима асинхронного взаимодействия JavaScript/XML (XMLHttpRequest и т.п.). Как минимум, пользовательские интерфейсы должны быть протестированы на совместимость с браузерами Microsoft Internet Explorer версии 8.0 или выше, Mozilla FireFox версии 6.0 или выше, Google Chrome версии 10.0 или выше.

Мобильные АРМ Системы должны быть рассчитаны на использование, как минимум, планшетных устройств с операционной системой iOS версии 4.0 и выше, Android версии 2.1 и выше, с браузером, предлагаемым в типовой поставке устройства по умолчанию.

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

Поставка общесистемного программного обеспечения (ОС, СУБД) в рамках работ не предусматривается.

Техническое обеспечение

Поставка технического (аппаратного) обеспечения в рамках выполнения проекта не предусматривается.

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

Сервер базы данных:

• Четыре двуядерных процессора с тактовой частотой 2 ГГц,
• Объем оперативной памяти 8Гб,
• Объем жесткого диска 500 Гб.

Web-сервер:

• Четыре двуядерных процессора с тактовой частотой 2 ГГц,
• Объем оперативной памяти 12Гб,
• Объем жесткого диска 200 Гб.

Требования к метрологическому обеспечению

Требования к метрологическому обеспечению не предъявляются.

СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО ВНЕДРЕНИЮ МУНИЦиПАЛЬНОГО СЕГМЕНТА

Этапы работ

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

приведены в таблице 1.

Таблица 1 – Состав и содержание работ по внедрению Системы

Наименование этапа (подэтапа) работ	Результаты этапа, предъявляемые Заказчику
1	2
Этап 1. Поставка муниципального сегмента Сроки оказания услуг: с момента подписания договора - не более 10 дней. Объем: 50% от стоимости услуг.
Поставка программного обеспечения	Муниципальный сегмент как компонент Системы, установлен на технических средствах заказчика/пользователя.
Пуско-наладочные работы	Муниципальный сегмент отвечает всем функциональным требованиям как компонент Системы.
Поставка рабочей документации	Рабочая документация Системы в следующем составе: Инструкция пользователя муниципальный сегмент.
Этап 2. Опытная эксплуатация и внедрение Сроки оказания услуг: не позднее планового срока окончания работ. в соответствии с подразделом 1.9 Плановые сроки начала и окончания работы по внедрению муниципальный сегмента настоящего ТЗ. Объем работ: 50% от стоимости работ по Государственному контракту.
Предварительные испытания	Протокол предварительных испытаний. Акт о допуске муниципального сегмента к опытной эксплуатации.
Обучение пользователей	Программа учебного курса. Отчет о проведении комплексного учебного курса для пользователей Системы.
Ввод муниципальный сегмента в опытную эксплуатацию.	Акт приемки в опытную эксплуатацию.
Опытная эксплуатация	Отчет об опытной эксплуатации, согласованный с Заказчиком и включающий сведения о продолжительности функционирования Системы, отказах, сбоях, аварийных ситуациях, изменениях параметров объекта автоматизации, проводимых корректировках документации и программных средств, наладке технических средств. Акт о завершении опытной эксплуатации и готовности Системы к проведению приемочных испытаний.
Приемочные испытания	Протокол приемочных испытаний. Акт приемки муниципальныого сегмента в промышленную эксплуатацию.

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

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

ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ

Виды, состав, объем и методы испытаний Системы

Испытания должны быть организованы и проведены в соответствии с ГОСТ 34.603 «Информационная технология. Виды испытаний автоматизированных систем».

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

предварительные испытания;

приемочные испытания.

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

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

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

Предусмотренные испытания проводятся комиссией, формируемой Заказчиком на основании приказа.

В состав комиссии включаются представители организаций Заказчика и Исполнителя.

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

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

В случае значительного отклонения Системы от требований, предъявляемых на испытаниях, сроки проведения испытаний могут быть перенесены Заказчиком в пределах сроков выполнения работ в соответствии с календарным планом Государственного контракта.

Сведения о гарантийном обслуживании

Гарантийное обслуживание проводится в сроки, определенные Государственным контрактом. Гарантийное обслуживание в течение календарного года с момента подписания акта сдачи-приемки выполненных работ.

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

Исполнитель не гарантирует отсутствие недостатков или сбоев, возникающих по причине несоответствия технических средств и общесистемного программного обеспечения требованиям настоящего ТЗ.

Порядок выполнения доработок и устранения допущенных исполнителем ошибок, выявленных на этапе приемки

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

ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ В ДЕЙСТВИЕ

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

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

- Обеспечить присутствие пользователей на обучении работе с системой, проводимом Исполнителем;

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

- Совместно с Исполнителем подготовить план развертывания системы на технических средствах Заказчика;

Провести опытную эксплуатацию муниципального сегмента.

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

Подготовка персонала

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

Исполнитель должен разработать и согласовать с Заказчиком учебный план, охватывающих все категории (АРМ) служебных пользователей муниципального сегмента. План должен предусматривать:

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

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

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

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

ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

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

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

Содержание и оформление проектной и рабочей документации должны соответствовать требованиям ГОСТ 34.201-89 «Виды, комплектность и обозначения документов при создании автоматизированных систем» и РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов». Состав разрабатываемой проектной и рабочей документации определен в подразделах Ошибка! Источник ссылки не найден.-0 настоящего ТЗ. При необходимости по усмотрению Исполнителя допускается дополнительная разработка иных видов проектной и рабочей документации из числа предусмотренных ГОСТ 34.201-89.

Документы на Систему должны быть оформлены в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания.

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

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

Методическая документация

Комплект методической документации должен содержать:

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

Рабочая документация

В состав рабочей документации должны быть включены, как минимум:

• инструкция пользователя ИС «Доступная среда» (допускается разбивка на несколько томов по подсистемам);

Комплект эксплуатационной документации на Систему должен содержать сведения, достаточные для эксплуатации Системы.

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

По итогам испытаний Исполнителем должны быть оформлены и согласованы с Заказчиком:

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

ИСТОЧНИКИ РАЗРАБОТКИ

1. Федеральный закон от 24.11.1995 № 181-ФЗ «О социальной защите инвалидов в Российской Федерации»;
2. Постановление Правительства Российской Федерации от 07.12.1996 г. № 1449 «О мерах по обеспечению беспрепятственного доступа инвалидов к информации и объектам социальной инфраструктуры»;
3. СНиП 35-01-2001 «Доступность зданий и сооружений для маломобильных групп населения» (приняты и введены в действие с 1 сентября 2001 г. постановлением Госстроя России от 16.07.2001 г. № 73);
4. Градостроительный кодекс Российской Федерации от 29.01.2004 г. № 190-ФЗ;
5. Постановление Правительства Российской Федерации от 16.02.2008 г. № 87 «О составе разделов проектной документации и требованиях к их содержанию»;
6. Федеральный закон Российской Федерации от 06.04.2011 г. № 63-ФЗ «Об электронной подписи»;
7. ГОСТ 2.105 «Общие требования к текстовым документам»;
8. ГОСТ 2.301-68 «Единая система конструкторской документации. Форматы»;
9. ГОСТ 34.201-89 «Виды, комплектность и обозначения документов при создании автоматизированных систем»;
10. РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов».

Список использованной литературы:

Конвенция ООН о правах инвалидов

Конституция Российской Федерации

Гражданский кодекс Российской Федерации

Градостроительный кодекс Российской Федерации

Кодекс РФ об административных правонарушениях

Федеральный закон РФ «О социальной защите инвалидов в Российской Федерации» от 24.11.1995 г. № 181-ФЗ

Федеральный закон РФ «О техническом регулировании» от 27.12.2002 г. № 184-ФЗ

Федеральный закон РФ «Технический регламент о безопасности зданий и сооружений» от 30.12.2009 г. № 384-ФЗ

Федеральный закон РФ «Об архитектурной деятельности в Российской Федерации» от 17.11.1995 г. № 169-ФЗ

Указ Президента Российской Федерации «О мерах по формированию доступной для инвалидов среды жизнедеятельности» от 02.10.1992 г. № 1156

Указ Президента Российской Федерации «О мерах по обеспечению государственной поддержки инвалидов» от 01.07.1996 г. № 1011

Постановление Правительства Российской Федерации «О мерах по обеспечению беспрепятственного доступа инвалидов к информации и объектам социальной инфраструктуры» от 07.12.1996 г. № 1449

Постановление Государственного Комитета Российской Федерации по строительству и жилищно-коммунальному комплексу № 74 и Министерства труда и социального развития Российской Федерации № 51 от 22.12.1999 г. «Об утверждении «Порядка реализации требований доступности для инвалидов к объектам социальной инфраструктуры»

Государственная программа «Доступная среда» на 2011-2015 годы»

Конституция Республики Башкортостан

Республиканская целевая программа «Доступная среда» на 2011-2015 годы»

СНиП 35-01-2001 «Доступность зданий и сооружений для маломобильных групп населения»

РДС 35-201-99 «Порядок реализации требований доступности для инвалидов к объектам социальной инфраструктуры»

СП 35-101-2001 «Проектирование зданий и сооружений с учетом доступности для маломобильных групп населения. Общие положения»

СП 35-102-2001 «Жилая среда с планировочными элементами, доступными инвалидам»

СП 35-103-2001 «Общественные здания и сооружения, доступные маломобильным посетителям»

СП 35-104-2001 «Здания и помещения с местами труда для инвалидов»

СНиП 31-06-2009 «Общественные здания и сооружения»

ГОСТ Р 52131-2003 «Средства отображения информации знаковые для инвалидов. Технические требования»

ГОСТ Р 51671-2000 «Средства связи и информации технические общего пользования, доступные для инвалидов. Классификация. Требования доступности и безопасности.

ГОСТ Р 52875-2007 «Указатели тактильные наземные для инвалидов по зрению. Технические требования»

ГОСТ 51261-99 «Устройства опорные стационарные реабилитационные. Типы и технические требования»

Методические рекомендации Министерства труда и социальной защиты Российской Федерации от 18.09.2012 г. «Методика формирования и обновления карт доступности объектов и услуг»

Методические рекомендации Министерства труда и социальной защиты Российской Федерации от 18.09.2012 г. «Методика паспортизации и классификации объектов и услуг с целью их объективной оценки для разработки мер, обеспечивающих их доступность»

---

^[1] указывается один из вариантов: «А», «Б»

^[2] указывается: ДП-В - доступен полностью всем; ДП-И (К, О, С, Г, У) - доступен полностью избирательно (указать, каким категориям инвалидов); ДЧ-В - доступен частично всем; ДЧ-И (К, О, С, Г, У) – доступен частично избирательно (указать категории инвалидов); ДУ - доступно условно, ВНД – недоступно;

^[3] указывается один из вариантов (видов работ): не нуждается; ремонт (текущий, капитальный); индивидуальное решение с ТСР; технические решения невозможны – организация альтернативной формы обслуживания

^[4] указывается: ДП-В - доступен полностью всем; ДП-И (К, О, С, Г, У) - доступен полностью избирательно (указать, каким категориям инвалидов); ДЧ-В - доступен частично всем; ДЧ-И (К, О, С, Г, У) – доступен частично избирательно (указать категории инвалидов); ДУ - доступно условно

^[5] дается оценка результата исполнения плановых мероприятий в сравнении с ожидаемыми результатами (по состоянию доступности) – аналогично гр.17