ТТ Модернизация Реестра МО_2x
advertisement
МИНИСТЕРСТВО ГОСУДАРСТВЕННОГО УПРАВЛЕНИЯ, ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И СВЯЗИ МОСКОВСКОЙ ОБЛАСТИ УТВЕРЖДАЮ Заместитель Министра государственного управления, информационных технологий и связи Московской области ________________ Белозерова С.М. «__» __________2014г м.п. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ на выполнение работ модернизации Реестра государственных услуг (функций) Московской области СОГЛАСОВАНО Начальник Управления электронного правительства Министерства государственного управления, информационных технологий и связи Московской области _____________ Кондакова Н.П. «__» __________2014г м.п. Красногорск 2016 2 Содержание 1 Общие положения 5 1.1 Полное наименование системы 5 1.2 Полное наименование работ 5 1.3 Условное обозначение системы 5 1.4 Заказчик 5 1.5 Пользователь 5 1.6 Исполнитель 5 1.7 Основание для модернизации системы 5 1.8 Плановые сроки модернизации системы 6 1.9 Источник финансирования 6 1.10 Порядок финансирования 6 1.11 Порядок оформления и предъявления Государственному Заказчику результатов работ 6 1.12 Особые условия 6 1.13 Перечень нормативно-технических документов, методических материалов, регламентирующих разработку Системы 8 1.14 Перечень сокращений 8 1.15 Термины и определения, используемые в ТТ 1.16 Порядок внесения изменений и дополнений 2 Цель и задачи выполнения работ 11 Error! Bookmark not defined. 13 2.1 Цель выполнения работ 13 2.2 Решаемые задачи в рамках выполняемых работ 3 Характеристика объекта автоматизации 13 15 3.1 Краткие сведения об объекте автоматизации 15 3.2 Сведения об условиях эксплуатации 16 3.3 Описание места объекта автоматизации в совокупности окружающих автоматизированных информационных систем 17 3.3.1 Сведения о внешней среде 17 3.3.2 Основные функции взаимодействующих сторонError! Bookmark not defined. 3.4 Текущее состояние объекта автоматизации 4 Требования к системе Error! Bookmark not defined. 18 4.1 Требования к системе в целом 4.1.1 Требования к структуре и функционированию системы 4.1.2 Требования к численности и квалификации персонала системы 4.1.3 Показатели назначения 4.1.4 Требования к надежности 4.1.5 Требования безопасности 18 18 19 19 19 19 3 4.1.6 Требования к эргономике и технической эстетике 20 4.1.7 Требования к транспортабельности для подвижных АС 20 4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы 20 4.1.9 Требования к защите информации от несанкционированного доступа 20 4.1.10 Требования по сохранности информации при авариях 20 4.1.11 Требования к патентной чистоте 21 4.1.12 Требования по стандартизации и унификации 21 4.2 Требования к функциям (задачам), выполняемым системой 4.2.1 Требования к функциям Модуля контроля качества 4.2.2 Требования к функциям Модуля информационного обмена 4.2.3 Требования к функциям Модуля аналитики 22 22 28 32 4.3 Требования к видам обеспечения 34 4.3.1 Требования к математическому обеспечению 34 4.3.2 Требования к информационному обеспечению 34 4.3.3 Требования к лингвистическому обеспечению 34 4.3.4 Требования к программному обеспечению на серверах и клиентских рабочих местах 35 4.3.5 Требования к техническому обеспечению 35 4.3.6 Требования к организационному обеспечению 36 4.3.7 Требования к методическому обеспечению 37 4.3.8 Требования к телекоммуникационному обеспечению системы 39 5 Состав и содержание работ по модернизации системы 40 6 Порядок контроля и приемки системы 43 6.1 Общие требования к контролю этапа разработки Системы 43 6.2 Виды, состав, объем и методы испытаний системы и ее составных частей 43 6.3 Общие требования к приемке работ по стадиям 44 6.4 Сведения о гарантийном обслуживании системы 45 6.5 Порядок выполнения доработок и устранения допущенных исполнителем ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания45 6.6 Сведения об обслуживании системы 46 7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие 49 8 Требования к документированию 51 9 Источники разработки 55 ПРИЛОЖЕНИЕ А ФОРМА АКТА ПРИЕМА-ПЕРЕДАЧИ НАУЧНО-ТЕХНИЧЕСКОЙ ПРОДУКЦИИ 56 А.1 ТИПОВАЯ ФОРМА АКТА ПРИЕМА-ПЕРЕДАЧИ НАУЧНО-ТЕХНИЧЕСКОЙ ПРОДУКЦИИ 56 ПРИЛОЖЕНИЕ Б (ОБЯЗАТЕЛЬНОЕ) 58 Приложение № 1 62 Приложение № 2 64 Приложение № 3 66 4 ПРИЛОЖЕНИЕ В (ОБЯЗАТЕЛЬНОЕ) 66 ПРОВЕРКА СООТВЕТСТВИЯ ТРЕБОВАНИЯМ К ДОКУМЕНТИРОВАНИЮ 66 1. Методика проверки комплектности документов 66 2. Методика проверки содержания и оформления технических документов66 3. Методика проверки содержания и оформления эксплуатационных документов 66 4. Методика оценки качества эксплуатационной документации 66 5. Использование нормативных документов 67 Критерии успешности проверок 68 Оформление результатов проверок 68 5 1 Общие положения 1.1 Полное наименование системы Полное наименование системы: Реестр государственных услуг (функций) Московской области. 1.2 Полное наименование работ Полное наименование работ: Модернизация Реестра государственных услуг (функций) Московской области. 1.3 Условное обозначение системы Условное обозначение: Реестр, Система. 1.4 Заказчик Государственный заказчик: Министерство государственного управления, информационных технологий и связи Московской области. Место нахождения: 143405, Московская область, г. Красногорск, Ильинское шоссе, д. 4. Почтовый адрес: 143407, Московская область, г. Красногорск, бульвар Строителей, д.1 (Дом Правительства Московской области). 1.5 Пользователь Пользователями Системы являются сотрудники ЦИОГВ и ОМСУ, ответственные за формирование и размещение сведений о государственных и муниципальных услугах (функциях). 1.6 Исполнитель Определяется по результатам проведения конкурсной процедуры в соответствии с Федеральным Законом Российской Федерации от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд». 1.7 Основание для модернизации системы Основанием для модернизации Реестра государственных услуг (функций) Московской области является п 7.2. «Перевод государственных услуг в электронный вид и развитие соответствующих информационных систем ОГВ Московской области, обеспечивающих реализацию данных задач» Подпрограммы «Развитие информационно-коммуникационных технологий для повышения эффективности процессов управления и создания благоприятных условий жизни и ведения бизнеса в Московской области» государственной программы Московской области «Эффективная власть» на 2014-2018 годы1. Постановление Правительства Московской области от 23.08.2013 № 660/37 “Об утверждении государственной программы Московской области «Эффективная власть» на 2014 - 2018 годы” 1 6 1.8 Плановые сроки модернизации системы I этап: В течение 15 календарных дней с даты заключения государственного контракта на выполнение работ по теме «Модернизация Реестра государственных услуг (функций) Московской области» (далее – Государственный контракт). II этап: не позднее 5 декабря 2014 года III этап: не позднее 20 декабря 2014 года. 1.9 Источник финансирования Средства бюджета Московской области на 2014 год. 1.10 Порядок финансирования Порядок финансирования работ определяется условиями Государственного контракта. 1.11 Порядок оформления и предъявления Государственному Заказчику результатов работ Порядок оформления и предъявления Государственному заказчику результатов работ приведен в разделах 5 и 8 данных ТТ. Результаты работ передаются Государственному заказчику в порядке, определенном Государственным контрактом в соответствии с Календарным планом работ на основании Актов приема-передачи выполненных работ. Требования к оформлению указанных актов приведены ниже (Приложение А). Состав передаваемых на машинных носителях результатов работ оформляется документом «Ведомость машинных носителей информации». Документация, подготовленная в ходе выполнения работ, передается на бумажных (два экземпляра) и на машинных носителях (CD|DVD). Текстовые документы, передаваемые на машинных носителях, должны быть представлены в форматах Microsoft Office. Все материалы передаются с сопроводительными документами Исполнителя. 1.12 Особые условия Результаты работ по модернизации Реестра государственных услуг (функций) Московской области, должны быть совместимы на уровне программного, технического, информационного и других видов обеспечения с типовым решением региональных реестров и порталов государственных и муниципальных услуг, разработанного и распространяемого Министерством экономического развития Российской Федерации в рамках государственной программы Российской Федерации «Информационное общество (2011-2020 годы)», доступным на Портале поддержки типовых решений Министерства экономического развития Российской Федерации (pgu-support.ru), а также с результатами технологических работ по сопровождению Реестра государственных услуг (функций) Московской области2 и не нарушать требований к Реестру. Технологические работы по сопровождению Реестра государственных услуг (функций) Московской области (Государственный контракт № 0148200002413000102 от 22.10.2013 г. на выполнение технологических работ по сопровождению Реестра государственных услуг (функций) Московской области, номер реестровой записи в едином реестре государственных и муниципальных контрактов № 0148200002413000102 на официальном сайте Российской Федерации для размещения информации о размещении заказов (ссылка в информационнокоммуникационной сети Интернет: www.zakupki.gov.ru) 2 7 Для анализа общих требований к Системе должно использоваться Техническое задание на доработку Типового решения регионального (муниципального) узла Системы, в соответствии с ГОСТ 34.602-89, разработанное в рамках темы: «Развитие и методическое сопровождение федерального реестра государственных и муниципальных услуг и методическая поддержка типового решения региональных реестров и порталов государственных и муниципальных услуг» по государственному контракту № ГК-81-ЛА/Д01 от «17» июля 2013 г. Для выполнения работ по п. 4.1.9 настоящих ТТ в части реализации механизмов подписания квалифицированной электронной подписью основных сущностей модели данных Реестра к участникам размещения заказа предъявляется обязательное требование по предоставлению копии действующей лицензии ФСБ России в составе конкурсной заявки на осуществление следующих лицензируемых видов деятельности3: монтаж, установка (инсталляция), наладка шифровальных (криптографических) средств; монтаж, установка (инсталляция), наладка защищенных с использованием шифровальных (криптографических) средств информационных систем. Для выполнения работ по п. 4.1.9. настоящих ТТ в части разработки раздела с описанием проектных решений, технических и программных средств обеспечения информационной безопасности Реестра в составе технического проекта на Реестр к участникам размещения заказа предъявляется обязательное требование по предоставлению в составе конкурсной заявки копии действующей на протяжении всего срока исполнения работ по настоящим ТТ лицензии ФСТЭК на осуществление деятельности по проектированию в защищенном исполнении средств и систем информатизации. Исполнитель обязан в рамках государственного контракта подготовить и предъявить необходимые документы в соответствии с требованиями по регистрации и государственному учету результатов выполняемых по государственному контракту работ, установленными действующими нормативными правовыми актами Московской области. До начала работ Государственный заказчик предоставляет Исполнителю техническую и эксплуатационную документацию на Реестр. Требования к модернизируемым модулям Реестра определены в п. 4.2. Приказ Федеральной службы безопасности Российской Федерации от 30.08.2012 г. № 440 г. Москва «Об утверждении Административного регламента Федеральной службы безопасности Российской Федерации по предоставлению государственной услуги по осуществлению лицензирования деятельности по разработке, производству, распространению шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнению работ, оказанию услуг в области шифрования информации, техническому обслуживанию шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств (за исключением случая, если техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, осуществляется для обеспечения собственных нужд юридического лица или индивидуального предпринимателя)» 3 8 1.13 Перечень нормативных правовых актов, нормативнотехнических документов, методических материалов, регламентирующих разработку Системы Выполняемая работа и оформление ее результатов должны отвечать требованиям нормативно-правовых актов, а также соответствующих государственных стандартов из числа Комплекса стандартов на автоматизированные системы: Федеральный закон от 26 декабря 2008 г. № 294-ФЗ «О защите прав юридических лиц и индивидуальных предпринимателей при осуществлении государственного контроля (надзора) и муниципального контроля». Федеральный закон от 27 июля 2010 г. № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг». Постановление Правительства Российской Федерации от 24 октября 2011 г. N 861 «О федеральных государственных информационных системах, обеспечивающих предоставление в электронной форме государственных и муниципальных услуг (осуществление функций)». Постановление Правительства Российской Федерации от 16 мая 2011г. №373 «О разработке и утверждении административных регламентов исполнения государственных функций и административных регламентов предоставления государственных услуг». Постановление Правительства Московской области от 23 августа 2013 № 660/37 «Об утверждении государственной программы Московской области «Эффективная власть» на 2014-2018 годы». Постановление Правительства Московской области от 6 августа 2013 г. N 593/33 «О реестре государственных услуг (функций) Московской области». Постановление Правительства Московской области от 2 июля 2013 г. N 482/27 «О государственной информационной системе Московской области «Портал государственных и муниципальных услуг (функций) Московской области». Постановление Правительства Московской области от 25 апреля 2011 г. N 365/15 «Об утверждении порядка разработки и утверждения административных регламентов исполнения государственных функций и административных регламентов предоставления государственных услуг центральными исполнительными органами государственной власти Московской области, государственными органами Московской области». Постановление Правительства Московской области от 18 мая 2010 г. N 350/20 «Об утверждении системы показателей для оценки эффективности деятельности центральных исполнительных органов государственной власти Московской области, государственных органов Московской области». ГОСТ 34.602-89 – «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на автоматизированные системы». ГОСТ 19.301-79 – «Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению». РД 50-34.698-90 – «Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов». 1.14 Перечень сокращений АИС — Автоматизированная информационная система АС — Автоматизированная система 9 АИС МО МФЦ — Государственная информационная система «Автоматизированная информационная система многофункциональных центров предоставления государственных и муниципальных услуг Московской области» АИС НПА — Автоматизированная информационная система нормативных правовых актов АРМ — Автоматизированное рабочее место БД — База данных БТИ — Бюро технической инвентаризации ВИС — Ведомственная информационная система ГО — Государственные органы Московской области ГОСТ — Государственный стандарт ЕИС МО ОРД — Единая информационная система учета нормативных правовых и организационно-распорядительных актов Губернатора Московской области, Правительства Московской области, ЦИОГВ и муниципальных образований Московской области, а также организаций и учреждений, находящихся в их ведении ИС — Информационная система ИТ — Информационные технологии КТС — Комплекс технических средств МО — Московская область МФЦ — Многофункциональные муниципальных услуг НПА — Нормативный правовой акт ОГВ — Орган (органы) государственной власти Московской области ОМСУ — Орган (органы) местного самоуправления Московской области ОПО — Общее программное обеспечение ОС — Операционная система ОЭ — Опытная эксплуатация ПГУ МО — Портал государственных услуг Московской области ПК — Персональный компьютер ПО — Программное обеспечение ПТК ГМУ — Программно-технический комплекс "Государственные и муниципальные услуги" ПЭВМ — Персональная электронно-вычислительная машина РД — Руководящий документ РСМЭВ МО — Региональная система межведомственного электронного взаимодействия Московской области РФ — Российская Федерация СМК — Система менеджмента качества СМЭВ — Система межведомственного электронного взаимодействия СПО — Специальное программное обеспечение центры предоставления государственных и 10 СУБД — Система управления базой данных ТС — Техническое средство ТТ — Технические требования УНП — Подсистема универсальных начислений платежей, выступающая в качестве универсальной платежной шины ФЗ — Федеральный закон ФИО — Фамилия, имя, отчество ФРГУ — Федеральный реестр государственных и муниципальных услуг (функций) ФСТЭК — Федеральная служба по техническому и экспортному контролю ЦИОГВ — Центральные исполнительные органы государственной власти Московской области ЭП — Квалифицированная электронная подпись GUI — Визуальный графический интерфейс XML — Расширяемый язык разметки (от англ. eXtensible Markup Language) 11 1.15 Термины и определения, используемые в ТТ Внешние системы — Информационные системы, взаимодействие Реестра с которыми реализовано Государственная услуга — Деятельность по реализации функций Правительства Российской Федерации, федерального органа исполнительной власти, государственного внебюджетного фонда, исполнительного органа государственной власти субъекта Российской Федерации, а также органа местного самоуправления при осуществлении отдельных государственных полномочий, переданных федеральными законами и законами субъектов Российской Федерации, которая осуществляется по запросам заявителей в пределах установленных нормативными правовыми актами Российской Федерации и нормативными правовыми актами субъектов Российской Федерации полномочий органов, предоставляющих государственные услуги Государственная функция — Деятельность федерального органа исполнительной власти, органа государственного внебюджетного фонда, а также органа исполнительной власти субъекта Российской Федерации по реализации полномочий в сфере осуществлении государственного контроля (надзора) Государственный Заказчик — Министерство государственного управления, информационных технологий и связи Московской области. Государственный контракт — Государственный контракт на выполнение работ по теме «Модернизация Реестра государственных услуг (функций) Московской области» Единый портал, ЕПГУ — Федеральная государственная информационная система Единый портал государственных и муниципальных услуг (функций) (далее — Единый портал) —(gosuslugi.ru) Нотация BPMN 2.0 — Business Process Model and Notation, нотация и модель бизнеспроцессов – система условных обозначений (нотация) для моделирования бизнес-процессов Исполнитель — Организация, с которой будет заключен Государственный контракт на выполнение работ в рамках настоящих технических требований по результатам открытого конкурса Муниципальная услуга — Предоставляемая органом местного самоуправления, деятельность по реализации функций органа местного самоуправления, которая осуществляется по запросам заявителей в пределах полномочий органа, предоставляющего муниципальные услуги, по решению вопросов местного значения Муниципальная функция — Деятельность органа местного самоуправления по реализации полномочий в сфере осуществлении муниципального контроля (надзора) Объект автоматизации — деятельность Министерства государственного управления, информационных технологий и связи Московской области в части ведения и согласования сведений о государственных и муниципальных услугах и функциях. 12 Подуслуга — Отдельный сценарий предоставления государственной или муниципальной услуги, состоящий из последовательности административных процедур и действий, направленных на предоставление услуги заявителю. Подуслуги различаются требованиями к заявителю и/или перечню документов, необходимых для предоставления услуги, и/или результатом предоставления услуги. Подуслугами не являются отдельные этапы предоставления услуги (например, приём документов, рассмотрение документов, принятие решения по результатам рассмотрения документов), а также услуги, необходимые и обязательные для получения данной услуги (например, проведение обязательной экспертизы материальных объектов) Подфункция — Отдельный сценарий исполнения государственной функции, состоящий из последовательности административных процедур и действий, направленных на исполнение государственной функции. Подфункции различаются субъектами, в отношении которых осуществляется государственный контроль (надзор), и/или основанием (поводом для) проведения мероприятий по контролю и иных действий в рамках осуществления государственного контроля (надзора), и/или результатом исполнения государственной функции Портал государственных — Государственная информационная система «Региональный услуг Московской портал государственных услуг Московской области» области Реестр, Система — Реестр государственных услуг (функций) Московской области. Сервис инкрементального обновления — Сервис Системы, отвечающий за передачу во внешние информационные системы (в частности, в ПГУ МО) информации, размещенной в Системе Типовая услуга Услуга, формируемая Министерством государственного управления, информационных технологий и связи Московской области и используемая в качестве эталона для формирования муниципальных услуг в ОМСУ 13 2 Цель и задачи выполнения работ 2.1 Цель выполнения работ Текущая версия Реестра обладает рядом недостатков, ухудшающих качество описания услуг и функций, и снижающих эффективность работы с Реестром: отсутствуют эффективные инструменты контроля качества описаний государственных услуг и функций; не предусмотрена возможность описания типовых услуг, на основе которых могут подготавливаться и актуализироваться описания муниципальных услуг; отсутствует аналитическая подсистема, позволяющая осуществлять мониторинг качества описаний государственных услуг и функций на основе настраиваемых уполномоченными пользователями правил выявления возможных ошибок и несоответствий в описаниях; перечень формируемых отчетов недостаточен для проведения эффективного анализа качества описаний государственных и муниципальных услуг и принятия решений по оптимизации порядка их оказания и исполнения; отсутствует возможность подготовки перечня услуг, которые должны оказываться конкретным ЦИОГВ и ОМСУ согласно нормативноправовым актам, с дальнейшим планированием и отслеживанием ввода описаний соответствующих услуг в Реестр. Описанные недостатки не позволяют эффективно использовать Реестр в качестве единого источника достоверных сведений о государственных и муниципальных услугах, оказываемых ЦИОГВ и ОМСУ и, в конечном итоге, негативно влияют на качество предоставления услуг. Таким образом, целью выполнения работ по модернизации Системы является устранение вышеуказанных недостатков, а именно: создание дополнительных инструментов для осуществления контроля качества описаний государственных и муниципальных услуг и функций; создание механизмов работы с типовыми услугами, на основе которых могут подготавливаться и актуализироваться описания муниципальных услуг; создание аналитической подсистемы для осуществления мониторинга качества описаний государственных услуг и функций на основе настраиваемых уполномоченными пользователями правил выявления возможных ошибок и несоответствий в описаниях; создание дополнительных отчетов для проведения анализа качества описаний государственных и муниципальных услуг и принятия решений по оптимизации порядка их оказания и исполнения; обеспечение возможности подготовки перечня услуг, которые должны оказываться конкретным ЦИОГВ и ОМСУ согласно нормативноправовым актам, с дальнейшим планированием и отслеживанием ввода описаний соответствующих услуг в Реестре. 2.2 Решаемые задачи в рамках выполняемых работ Для достижения указанных целей должны быть решены следующие задачи: разработка «Модуля контроля качества»; разработка «Модуля информационного обмена»; 14 разработка «Модуля аналитики»; проведение предварительных испытаний; проведение подготовки персонала; конвертация сведений из текущей версии в модернизированную версию Реестра; проведение опытной эксплуатации; проведение приемочных испытаний. Исполнителем должны быть проведены работы по модернизации Системы и подготовке ее к вводу в постоянную эксплуатацию в объеме требований настоящих ТТ. В частности, должна быть осуществлена подготовка сотрудников 3-х пилотных ЦИОГВ и 3-х пилотных ОМСУ. Точный состав пилотных ЦИОГВ и ОМСУ определяется по согласованию с Государственным заказчиком на этапе технического проектирования до проведения опытной эксплуатации. В целях обеспечения возможности самостоятельной подготовки к работе с модернизированной Системой пользователей остальных ЦИОГВ и ОМСУ, которые не попали в вышеуказанный пилотный перечень, Исполнителем должна быть подготовлена и передана Государственному заказчику эксплуатационная документация и методические материалы в объеме требований настоящего ТТ. 15 3 Характеристика объекта автоматизации 3.1 Краткие сведения об объекте автоматизации В качестве средства автоматизации деятельности по ведению сведений о государственных и муниципальных услугах (функциях) используется Реестр государственных услуг (функций) Московской области – государственная информационная система, зарегистрированная в Реестре информационных систем Московской области № 35, дата регистрации 05.07.2011. Реестр обеспечивает ведение сведений о государственных и муниципальных услугах (функциях) в соответствии с требованиями нормативных правовых актов, указанных в п. 1.13 настоящих ТТ. Реестр реализован на базе типового решения региональных реестров и порталов государственных и муниципальных услуг, разработанного и распространяемого Министерством экономического развития Российской Федерации в рамках государственной программы Российской Федерации «Информационное общество (2011-2020 годы)». Типовое решение распространяется на безвозмездной основе Министерством экономического развития Российской Федерации. В настоящий момент деятельность по ведению сведений о государственных и муниципальных услугах (функциях) осуществляется следующим образом: Размещение (изменение, удаление) сведений об услуге (функции) инициализируется на основании событий, изменяющих существенные условия порядка и стандарта предоставления услуги, в том числе: o изменение полномочий ведомства; o изменение нормативных правовых актов, определяющих порядок исполнения функций ведомства; o создание или изменение нормативных правовых актов, регулирующих отношения, возникающие в связи с предоставлением государственных и муниципальных услуг и (или) осуществлением государственного контроля (надзора) и муниципального контроля; o создание или изменение нормативного правового акта, непосредственно регулирующего предоставление услуги (исполнение функции) – административного регламента; o создание или изменение внутриведомственных административных документов, влияющих на отдельные аспекты предоставления услуги (исполнения функции), в том числе на: места, в которых происходит взаимодействие с органом, предоставляющим услугу (исполняющим функцию); контактную информацию должностных лиц, участвующих в предоставлении услуги (исполнении функции). Формирование сведений о государственных и муниципальных услугах (функциях) осуществляется с учетом нормативных правовых актов, приведенных в п. 1.13. При разработке и утверждении сведений о государственных и муниципальных услугах (функциях) обеспечивается согласованность содержания сведений о государственных и муниципальных услугах (функциях) с положениями указанных выше нормативных правовых актов, а также других нормативных правовых актов (в том числе ведомственных), регулирующих предоставление услуги. 16 Формирование сведений об органах власти и организациях, предоставляющих услуги (исполняющих функции) производится на основании Положения об органе исполнительной власти Московской области (органе местного самоуправления), внутриведомственных административных документов, влияющих на отдельные аспекты реализации полномочий органа власти в части предоставления услуги (исполнения функции). Согласование представленных сведений об услугах (функциях) и размещение поступивших от участников информационного взаимодействия сведений об услугах (функциях) после проверки их содержания на предмет полноты и достоверности осуществляется ответственным лицом Государственного заказчика. Ответственное лицо проверяет их полноту и достоверность и согласовывает их посредством подписания ЭП ответственного лица. При размещении сведений об услугах (функциях) осуществляются следующие проверки полноты и достоверности сведений, предоставленных к размещению: o проверка соответствия сведений об услуге (функции) тексту административного регламента или его проекта; o проверка соответствия сведений об услуге (функции) требованиям нормативных правовых актов, регулирующих предоставление государственных (муниципальных) услуг (исполнение государственных (муниципальных) функций); o проверка на полноту заполнения сведений об услуге; o проверка на корректное использование справочников, классификаторов и реестров объектов, непосредственно связанных с предоставлением услуг (исполнением функций), в том числе на отсутствие дублирующих записей. Объектом автоматизации Системы является деятельность ЦИОГВ и ОМСУ, связанная с процессами ведения сведений о государственных и муниципальных услугах (функциях). Количество установленных рабочих мест пользователей – более 1000. 3.2 Сведения об условиях эксплуатации Текущая версия Реестра эксплуатируется ЦИОГВ и ОМСУ. В соответствии с Государственным контрактом № 0148200002413000102 от 22.10.2013 г. в 2013 году были выполнены технологические работы по сопровождению Реестра государственных услуг (функций) Московской области (более подробные сведения о работах в рамках указанного государственного контракта приведены в п. 3.4). Условия эксплуатации доработанной Системы в рамках настоящих ТТ не должны противоречить условиям эксплуатации, предъявляемым к текущей версии Реестра. В порядке и в соответствие с настоящими ТТ Система должна быть размещена и корректно функционировать на оборудовании Государственного Заказчика. Техническая и физическая защита аппаратных компонентов Системы, носителей данных, бесперебойное энергоснабжение, реализуется техническими и организационными средствами, предусмотренными в ИТ-инфраструктуре Государственного заказчика. Система установлена в Центре обработки данных Правительства Московской области. 17 3.3 Описание места объекта автоматизации в совокупности окружающих автоматизированных информационных систем 3.3.1 Сведения о внешней среде Реестр представляет собой централизованное хранилище сведений о государственных (муниципальных) услугах и функциях и является источником информации для следующих внешних систем Московской области: ПГУ МО. Портал государственный услуг Московской области обеспечивает доступ физических и юридических лиц к сведениям о государственных и муниципальных услугах, государственных функциях по контролю и надзору, об услугах государственных и муниципальных учреждений, об услугах организаций, участвующих в предоставлении государственных и муниципальных услуг, а также предоставление в электронной виде государственных и муниципальных услуг на территории Московской области. ФРГУ. Федеральный реестр государственных услуг (функций). Информационная система, содержащая информацию обо всех государственных и муниципальных услугах (функциях), предоставляемых ОГВ и ОМСУ в Российской Федерации.. В настоящий момент существующая версия Реестра взаимодействует с ПГУ МО, на который передается информация об опубликованных государственных и муниципальных услугах. Для этого на стороне Системы реализован сервис инкрементального обновления, передающий актуальную информацию об услугах по запросу ПГУ МО. Кроме того, информация об услугах (функциях) передается из Реестра в ФРГУ. 18 4 Требования к системе 4.1 Требования к системе в целом 4.1.1 Требования к структуре и функционированию системы В рамках проведения работ должны быть разработаны функциональные модули, отсутствующие в действующей версии Реестра. Разрабатываемые модули Системы должны функционировать с использованием единой базы данных. Разрабатываемые электронные формы Системы должны функционировать как единое рабочее место пользователя, объединенное общими требованиями к авторизации, единообразными решениями по эргономике и технической эстетике. 4.1.1.1 Перечень характеристики модулей, их назначение и основные В результате модернизации Системы в ее состав должны быть включены следующие функциональные компоненты: Модуль контроля качества. Модуль информационного обмена. Модуль аналитики. Модуль контроля качества предназначен для повышения эффективности процесса проверки описаний государственных и муниципальных услуг и функций в Системе и должен включать в себя: Механизм контроля качества описаний услуг и функций. Механизм контроля доработок описаний услуг и функций (механизм уведомлений пользователей Реестра). Механизм работы с типовыми услугами. Возможность раздельного представления описаний услуг и функций. Возможность определения нормативно-утвержденного перечня услуг, предоставляемых ЦИОГВ или ОМСУ. Механизм ведения расширенных сведений об объектах Реестра. Механизм ведения пользовательских справочников. Модуль информационного обмена предназначен для улучшения качества предоставления описания государственных и муниципальных услуг (функций) и ЦИОГВ, ОМСУ в электронном виде, а также для обеспечения обратной связи. Модуль должен включать в себя: Механизм, обеспечивающий обратную связь с ПГУ МО и иными внешними системами согласно п. 4.2.2.2.1 . Механизм информационного взаимодействия с внешними системами. Модуль аналитики предназначен для обеспечения возможности мониторинга качества описаний государственных и муниципальных услуг (функций), а также для более эффективной обработки хранящейся информации. Модуль должен включать в себя: Аналитический механизм мониторинга качества описаний государственных и муниципальных услуг (функций). Возможность формирования преднастроенных аналитических отчетов. Механизм подготовки и реализации пользовательских запросов на выборку информации из базы данных. 19 4.1.1.2 Требования к способам и средствам информационного обмена между компонентами системы связи для Требования к способам и средствам связи для информационного обмена между компонентами Системы определены техническим заданием, указанным в п. 1.12. настоящих ТТ. Дополнительных требований не предъявляется. 4.1.1.3 Требования по взаимосвязям системами, обеспечению ее совместимости системы с внешними Программные средства Системы должны соответствовать стандартам обмена данными с использованием стека протоколов TCP/IP. Программные средства Системы должны осуществлять обмен информацией на основе открытых форматов обмена данными. Детализированные требования к порядку взаимодействия Системы с внешними системами и составу внешних систем приведены в разделе 4.2.2. 4.1.1.4 Требования к режимам функционирования Системы Требования к режимам функционирования Системы определены техническим заданием, указанным в п. 1.12. настоящих ТТ. Дополнительных требований не предъявляется. 4.1.1.5 Требования по диагностированию системы Требования по диагностированию Системы определены техническим заданием, указанным в п. 1.12. настоящих ТТ. Дополнительных требований не предъявляется. 4.1.1.6 Перспективы развития, модернизации системы Перспективы развития Системы определяются Государственным Заказчиком по итогам выполнения работ в соответствии с установленными процедурами. Государственным Заказчиком также может быть принято решение о дальнейшей модернизации Реестра. 4.1.2 Требования к численности и квалификации персонала системы Требования к численности и квалификации персонала Системы определены техническим заданием, указанным в п. 1.12. настоящих ТТ. Дополнительных требований не предъявляется. 4.1.3 Показатели назначения Требования к эксплуатационным показателям назначения Системы определены техническим заданием, указанным в п. 1.12. настоящих ТТ. Дополнительных требований не предъявляется. 4.1.4 Требования к надежности Требования к надежности Системы определены техническим заданием, указанным в п. 1.12. настоящих ТТ. Дополнительных требований не предъявляется. 4.1.5 Требования безопасности Требования к безопасности Системы определены техническим заданием, указанным в п. 1.12. настоящих ТТ. Дополнительных требований не предъявляется. 20 4.1.6 Требования к эргономике и технической эстетике Требования к эргономике и технической эстетике Системы определены техническим заданием, указанным в п. 1.12. настоящих ТТ. Дополнительных требований не предъявляется. 4.1.7 Требования к транспортабельности для подвижных АС Требования предъявляются. к транспортабельности модернизируемой Системе не 4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов Системы определены техническим заданием, указанным в п. 1.12. настоящих ТТ. Дополнительных требований не предъявляется. 4.1.9 Требования к защите несанкционированного доступа информации от На основании настоящих ТТ должен быть разработан технический проект на Систему. По результатам технического проектирования должна быть составлена Пояснительная записка к техническому проекту на Систему, содержащая, в том числе раздел по информационной безопасности. Раздел по информационной безопасности должен содержать как минимум следующую информацию: классификация информационной системы требованиям по безопасности; определение требований к подсистеме защиты информации. В результате выполнения работ в рамках настоящих ТТ Система должна предоставлять следующие интерфейсы доступа к каталогу учетных записей пользователей: Создать учетную запись пользователя в каталоге; Изменить значения атрибутов учётной записи в каталоге; Прочитать значения атрибутов учетной записи в каталоге; Удалить учётную запись пользователя в каталоге. Для реализации механизмов подписания ЭП основных сущностей модели данных Реестра на рабочих станциях пользователей Реестра должна быть обеспечена возможность монтажа и установки шифровальных (криптографических) средств. Дополнительные технические требования по защите информации уточняются в ходе подготовки Пояснительной записки к техническому проекту на Систему. Требования к защите информации от несанкционированного доступа определены техническим заданием, указанным в п. 1.12. настоящих ТТ. Дополнительных требований не предъявляется. Результаты работ по модернизации Реестра не должны изменять состав угроз. 4.1.10 Требования по сохранности информации при авариях Требования по сохранности информации при авариях определены техническим заданием, указанным в п. 1.12. настоящих ТТ. Дополнительных требований не предъявляется. 21 4.1.11 Требования к патентной чистоте 4.1.11.1 Перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей Патентная чистота Системы и её частей должна быть обеспечена в отношении патентов, действующих на территории Российской Федерации. Реализация технических, программных, организационных и иных решений, предусмотренных проектом Системы не должна приводить к нарушению авторских и смежных прав третьих лиц. 4.1.11.2 Требования программного обеспечения к использованию лицензионного В случае, если в модернизируемой Системе Исполнитель использует компоненты (программные библиотеки, сервера приложений, СУБД и иные объекты интеллектуальной собственности), подтвержденно разработанные Исполнителем или третьей стороной, не подразумевающие свободного использования, права (исключительные или неисключительные) на использование данных компонент должны быть переданы Государственному заказчику в объеме, необходимом для использования Системы всеми пользователями как на момент приемки, так и в дальнейшей перспективе. При этом, в составе Системы не должны использоваться программные модули, не обеспеченные поддержкой производителя (разработчика). Программные средства должны быть обеспечены гарантийным и постгарантийным обслуживанием фирмы-производителя. Соответствующие обязательства должны быть переданы Государственному заказчику. При использовании в Системе программ (программных комплексов или компонентов), разработанных третьими лицами, условия, на которых передается право на использование (исполнение) этих программ, не должны накладывать ограничений, препятствующих использованию Системы по ее прямому назначению. До начала работ Исполнитель должен уведомить Государственного заказчика о результатах интеллектуальной деятельности, имеющих правовую охрану, принадлежащих Исполнителю, которые планируется использовать при выполнении Государственного контракта. Все созданные и использованные при исполнении Государственного контракта объекты интеллектуальной собственности подлежат отражению в отчетных документах Исполнителя о результатах выполнения работ по Государственному контракту. 4.1.12 Требования по стандартизации и унификации Интерактивные средства редактирования информации должны удовлетворять принятым соглашениям в части использования функциональных клавиш, режимов работы, поиска, использования оконной системы: для обозначения сходных операций используются сходные графические значки, кнопки и другие управляющие (навигационные) элементы. экранные формы пользовательского интерфейса должны быть выполнены в едином графическом дизайне, с одинаковым расположением основных элементов управления и навигации; термины, используемые для обозначения типовых операций (добавление информационной сущности, редактирование поля данных), а также последовательности действий пользователя при их выполнении, должны быть унифицированы; внешнее поведение сходных элементов интерфейса (реакция на наведение указателя «мыши», переключение фокуса, нажатие кнопки) 22 реализовываются одинаково для однотипных элементов. При этом обеспечивается: o однофункциональность, то есть каждому пункту меню (или его аналогу) соответствует только одна выполняемая функция; o однозначность в понимании, то есть пункты меню (или их аналоги) называются или изображаются так, чтобы пользователь однозначно понимал их назначение; все поясняющие надписи в экранных формах, а также сообщения, выдаваемые пользователю (кроме системных сообщений), должны быть выполнены на русском языке. 4.2 Требования системой к функциям (задачам), выполняемым 4.2.1 Требования к функциям Модуля контроля качества 4.2.1.1 Требования к механизмам контроля качества описания государственных и муниципальных услуг (функций) Для повышения эффективности процесса проверки описаний государственных и муниципальных услуг (функций) в Системе требуется разработать инструменты, обеспечения качества описаний государственных и муниципальных услуг (функций): механизмы оповещения о выявленных ошибках в описаниях государственных и муниципальных услуг (функций) и мониторинга процесса внесения исправлений; механизмы, обеспечивающие получение и обработку замечаний к качеству описания государственных и муниципальных услуг (функций), фиксацию соответствующих заявок и контроль над их обработкой; механизмы мониторинга качества описаний государственных и муниципальных услуг (функций) по настроенным бизнес-правилам (на основе референтных значений параметров государственных и муниципальных услуг (функций). 4.2.1.2 Требования к функциям контроля доработок описаний государственных и муниципальных услуг (функций) Требуется реализовать в Системе возможность информирования авторов описания государственных и муниципальных услуг (функций) (ЦИОГВ и ОМСУ) о выявленных в описаниях ошибках и неточностях, а также обеспечить механизмы отслеживания доработок описаний. Для этого требуется предоставить возможность комментирования отдельных полей описаний. Кроме того, требуется обеспечить возможность настройки оповещений об изменении статуса описаний государственных и муниципальных услуг (функций): пользователь с ролью «Публикатор» (далее – публикатор) может настроить получение сообщений о факте изменения статуса дорабатываемых услуг (функций) (о передаче доработанного описания услуги/функции на публикацию). Требуется фиксировать информацию обо всех итерациях доработки отдельных описаний услуг или функций. Разрабатываемый механизм должен поддерживать следующий сценарий осуществления проверки описаний услуг и функций и контроля над ходом их доработки: Уполномоченный сотрудник ЦИОГВ и ОМСУ создает описание новой государственной или муниципальной услуги (функции) и передает его на публикацию. 23 Публикатор получает оповещение о передаче для публикации новой государственной или муниципальной услуги (функции). Публикатор проверяет описание новой государственной или муниципальной услуги (функции). В случае выявления ошибок в описании государственной или муниципальной услуги (функции), оно передается для доработки в ЦИОГВ и ОМСУ с указанием требуемых доработок и возможными комментариями к отдельным полям описания. Система фиксирует все доработки, произведенные в ЦИОГВ и ОМСУ, с указанием даты (времени) и автора внесенных изменений. Доработанное описание передается на публикацию повторно. Публикатор получает сообщение с указанием факта передачи доработанного описания на публикацию и перечнем измененных в ходе доработки полей. В случае если в ходе проверки (первичной либо повторной) публикатор не выявляет ошибок в описании государственной или муниципальной услуги (функции), оно публикуется в Системе. При разработке функций контроля доработок описаний государственных или муниципальных услуг (функций) необходимо провести анализ процесса доработки описаний и, в случае необходимости, дополнить статусную модель услуги/функции. 4.2.1.3 Требования к механизму работы с типовыми услугами Требуется реализовать в Системе механизм описания типовых услуг и их использования в качестве основы для подготовки описаний муниципальных услуг с обеспечением возможности актуализации описаний муниципальных услуг при изменении соответствующих им типовых услуг. Разрабатываемый механизм должен обеспечивать следующие возможности: Создание уполномоченными сотрудниками Государственного заказчика описаний типовых услуг, которые могут быть использованы в качестве основы для подготовки описаний муниципальных услуг на уровне отдельных услуг. Указание полей (параметров) типовых услуг, которые могут быть изменены в созданном описании услуги на уровне ОМСУ на основе типового (перечень полей, доступных для редактирования по умолчанию, должен быть определен Исполнителем, согласован с Государственным Заказчиком и внесен в техническую и эксплуатационную документацию на Систему). Возможность редактирования уполномоченным сотрудником Государственного заказчика описания типовой услуги, с дальнейшей актуализацией соответствующих параметров всех услуг, созданных на основе измененной типовой услуги. При этом уполномоченные сотрудники ОМСУ, параметры услуг которых актуализируются, оповещаются средствами Системы об изменениях и должны актуализировать описание услуги и заново подписать услугу своей ЭП (отправить измененную услугу на публикацию). Возможность создания уполномоченными сотрудниками Государственного заказчика описаний типовых услуг на основе уже существующих и описанных услуг. Основной ход исполнения сценария создания новой типовой услуги и формирования на ее основе муниципальной услуги на уровне ОМСУ может быть описан следующей последовательностью действий: 24 1. Создание новой типовой услуги: Уполномоченный сотрудник Государственного заказчика создает новую типовую услугу и заполняет значениями ее поля. Типовая услуга включает в себя те же поля, которые входят в описание обычной услуги. Уполномоченный сотрудник Государственного заказчика определяет перечень ОМСУ, которым доступна для использования (создания на ее основе своих описаний услуг) типовая услуга. По умолчанию типовая услуга доступна для использования всем ОМСУ. 2. Создание на основе типовой услуги муниципальной услуги на уровне ОМСУ: Уполномоченный сотрудник ОМСУ инициирует процесс создания услуги и указывает, что услуга должна быть создана на основе типовой. Осуществляется выбор типовой услуги, которая будет использоваться в качестве основы. Создается услуга на основе типовой. Все поля описания услуги заполнены значениями соответствующих полей типовой услуги. В описании услуги приводится ссылка на типовую услугу, на основе которой она была создана. В случае необходимости уполномоченный сотрудник ОМСУ изменяет те поля описания услуги, которые были определены как доступные для редактирования. Описание услуги, созданной на основе типовой, передается на согласование уполномоченному сотруднику Государственного заказчика. После опубликования описания услуги в Системе оно может быть передано в ПГУ МО. При этом передается не только информация о самой услуге, но и информация о типовой услуге, на основе которой было сформировано описание услуги. В случае если описание услуги, соответствующей типовой, уже было введено в Систему на уровне ОМСУ до определения типовой услуги на уровне Государственного заказчика, необходимо предоставить ОМСУ возможность привязки ранее введенного описания к новой типовой услуге. При этом требуется обеспечить возможность редактирования предзаполненных полей (для тех полей, для которых допускается возможность редактирования значений). Уполномоченному сотруднику Государственного заказчика должна предоставляться возможность редактирования описаний типовых услуг. При изменении параметров типовой услуги должна осуществляться актуализация соответствующих параметров услуг, созданных на ее основе. Основной ход исполнения сценария актуализации может быть описан следующей последовательностью действий: Уполномоченный сотрудник Государственного заказчика изменяет параметры (описание) ранее введенной типовой услуги. Система определяет перечень услуг, созданных на основе изменяемой типовой услуги. Для каждой услуги в перечне услуг, созданных на основе изменяемой типовой услуги, изменяется статус – услуги направляются “на доработку”. В описаниях услуг, созданных на основе изменяемой типовой услуги, корректируются измененные в соответствующей типовой услуге поля. ОМСУ, которыми были сформированы услуги, основанные на измененной типовой услуге, отправляются соответствующие оповещения (средствами Системы). 25 Услуга, основанная на измененной типовой услуге, передается на повторное согласование и публикацию уполномоченным сотрудником ОМСУ (подписывается его ЭП). После согласования услуга передается для согласования и публикации публикатору Системы. Услуга публикуется в Системе. После разработки механизма ведения перечня типовых услуг должен быть доработан сервис инкрементального обновления. В настоящее время указанный сервис отвечает за передачу во внешние информационные системы (в частности, в ПГУ МО) информации, размещенной в Реестре государственных услуг (функций) Московской области. Требуется обеспечить возможность передачи сервисом информации о привязке отдельной услуги к типовой услуге (если описание услуги было подготовлено на основе типовой услуги) и сведений о типовой услуге. 4.2.1.4 Требования к раздельному представлению описаний услуг и функций в Системе Требуется обеспечить раздельное представление в Системе услуг и функций, с возможностью подготовки отчетности, отдельно для услуг и функций. Должны быть проведены работы по представлению в отдельном разделе модели данных и пользовательских интерфейсов Системы описаний контрольнонадзорных функций. Таким образом, в Системе должны быть представлены два раздела: «Услуги» и «Функции». При этом модели статусов (жизненные циклы) описаний услуг и функций должны остаться идентичными. Инициация процесса создания описаний услуг и функций должна происходить в соответствующих разделах, формы для ввода сведений об услугах и функциях должны различаться по наличию полей, специфичных для услуг и функций. Разделение услуг и функций также должно быть учтено при формировании отчетности: пользователь должен иметь возможность сформировать отдельные отчеты по сведениям о государственных и муниципальных услугах и о контрольно-надзорных функциях. После реализации механизма необходимо обеспечить корректное разделение по разделам уже хранящихся в ПТК ГМУ Государственного Заказчика сведений об услугах и функциях. 4.2.1.5 Требования к возможности определения нормативноутвержденного перечня государственных и муниципальных услуг (функций), предоставляемых ЦИОГВ или ОМСУ В карточке сведений о ЦИОГВ и ОМСУ необходимо реализовать механизм ввода обязательных государственных и муниципальных услуг (описания государственных и муниципальных услуг не обязательно должны быть внесены к этому моменту) с возможностью указания для сформированного перечня нормативного правового акта, утверждающего перечень. Для каждой услуги из списка также должна быть обеспечена возможность указания опубликованного описания услуги, оказываемой соответствующим ЦИОГВ и ОМСУ. Указание перечня услуг не должно являться обязательным при вводе сведений о ЦИОГВ и ОМСУ. Сведения в перечень утвержденных услуг вводятся уполномоченным сотрудником соответствующего ЦИОГВ и ОМСУ. В системе должна быть предусмотрена возможность редактирования перечня услуг: ввода, изменения и удаления его элементов. Кроме того, необходимо обеспечить возможность импорта перечня утвержденных услуг из файла установленного формата (xml, xls, csv) и из 26 буфера обмена (порядок форматирования текста перечня, требуемый для его корректного импорта в Систему, должен быть предложен Исполнителем, согласован с Государственным Заказчиком и внесен в техническую и эксплуатационную документацию на Систему). В форме ввода/редактирования описания услуги необходимо предусмотреть возможность указания (ссылки) на элемент перечня услуг, утвержденных для оказания соответствующим ЦИОГВ и ОМСУ. При просмотре перечня услуг, обязательных для оказания ЦИОГВ и ОМСУ (в карточке сведений о ЦИОГВ и ОМСУ) необходимо предусмотреть индикацию тех услуг списка, для которых отсутствует опубликованное описание услуги. Кроме того, при наличии для элемента утвержденного перечня услуг описания услуги, требуется отображать текущий статус соответствующего описания услуги. Для каждой позиции, введенной в перечне утвержденных для оказания услуг, пользователь должен иметь возможность заполнения справочника стадий (контрольных точек) процесса ввода и согласования услуги (к примеру, «подготовка административного регламента», «передача описания услуги на согласование», «согласование описания услуги» и т. д.). Элементы справочника должны быть использованы в ходе формирования плана перевода в электронный вид утвержденной услуги: пользователь инициирует процесс создания плана для отдельной утвержденной услуги из списка и формирует перечень стадий с указанием плановой даты их окончания. На основании введенного справочника необходимо реализовать систему оповещения о достижении времени окончания тех или иных стадий процесса: пользователям, отвечающим за создание и актуализацию информации об услугах конкретного ЦИОГВ и ОМСУ, должны отсылаться соответствующие предупреждения при наступлении определенных в плане дат. Также должна быть предоставлена возможность определения пользователем фактической даты достижения окончания тех или иных стадий перевода услуги в электронный вид. 4.2.1.6 Требования к возможности расширения модели данных Системы пользовательской информацией Требуется обеспечить возможность ведения в Системе дополнительных сведений. Для этого необходимо разработать механизм ведения расширенных сведений об объектах Реестра, а именно реализовать возможность определения дополнительных реквизитов, задаваемых Администратором, для основных информационных сущностей: описаний государственных (муниципальных) услуг и функций и сведений об ЦИОГВ и ОМСУ. Также необходимо разработать механизм, обеспечивающий ведение пользовательских справочников. 4.2.1.6.1 Требования к механизму ведения расширенных сведений Для расширения реквизитного состава сведений, относящихся к тем или иным информационным сущностям, хранящимся в ПТК ГМУ Государственного заказчика, требуется обеспечить возможность указания дополнительных пользовательских атрибутов описания услуг, функций и сведений об ЦИОГВ и ОМСУ. Администратор Системы должен иметь возможность определить дополнительные поля, которые могут быть заполнены при описании услуги и функции или при вводе сведений об ЦИОГВ и ОМСУ. При этом должна быть предоставлена возможность указания типа атрибутов (в том числе, возможность указания в качестве атрибута поля-списка из ранее определенного пользовательского справочника), обязательности его заполнения, ограничений на значения, указываемые в нем. 27 Должен быть разработан механизм информационного обмена на базе сервиса инкрементального обновления, входящего в ПТК ГМУ Государственного Заказчика, обеспечивающий возможность выгрузки определенных пользователями дополнительных сведений во внешние информационные системы, использующие информацию из Системы. 4.2.1.6.2 Требования справочников к механизму ведения пользовательских Необходимо предоставить пользователю возможность ведения в Системе, с целью дальнейшего использования и предоставления внешним системам, пользовательских справочников: справочной информации, расширяющей модель данных ПТК ГМУ Государственного Заказчика. Пользователь должен иметь возможность: вводить, просматривать и редактировать сведения пользовательских справочников; импортировать сведения в пользовательские справочники из файлов в формате xml, csv. Для обеспечения возможности ведения пользовательских справочников в Системе должен быть разработан соответствующий раздел, в котором пользователь должен иметь возможность инициировать процесс создания пользовательского справочника. При этом Администратору Системы должен передаваться запрос на введение нового справочника и предоставлению соответствующему пользователю прав на его редактирование (новый справочник может быть создан только Администратором Системы, заполнение и редактирование содержимого справочника должно быть доступно пользователям с соответствующими правами). Также должны быть разработаны формы редактирования отдельного справочника и ввода сведений в справочник. Необходимо предусмотреть жизненный цикл согласования пользовательских справочников, позволяющий определять ответственных за ведение и согласование отдельных пользовательских справочников. Права по редактированию и согласованию отдельных пользовательских справочников должны предоставляться Администратором Системы. 4.2.2 Требования к функциям Модуля информационного обмена 4.2.2.1 Требования к обеспечению обратной связи с ПГУ МО и иными внешними системами с целью повышения качества описаний услуг и функций С целью повышения качества описания государственных услуг (функций) и органов государственной власти в электронном виде в Системе должна быть обеспечена обратная связь Системы с внешними информационными системами в соответствии с перечнем п.3.3.1 (в которых публикуются сведения, полученные из Системы), позволяющая пользователям и службе поддержки указанных систем передавать в Систему замечания к качеству описания услуг. Для обеспечения обратной связи в Системе должен быть разработан механизм, обеспечивающий следующий сценарий взаимодействия при поступлении из внешних информационных систем сообщений о необходимости исправления сведений о государственной услуге (функции): сообщения поступают из внешних информационных систем посредством использования разработанного для этих целей веб-сервиса; 28 пользователи Системы, ответственные за размещение сведений, информируются средствами Системы о поступивших сообщениях; пользователи Системы, ответственные за размещение сведений, фиксируют результат обработки сообщения (исправление ошибки либо комментарий к сообщению); ответы на сообщения передаются в службу поддержки внешних информационных систем путем использования разработанного для этих целей веб-сервиса; формируется отчетность по результатам поступивших сообщений. 4.2.2.2 Требования к предоставлению внешним информационным системам актуальных сведений об услугах и функциях Реестр должен выступать в роли системы, предоставляющей основные данные об услугах и функциях для информационных систем, функционирующих в ЦИОГВ и ОМСУ , которые используют информацию об услугах и функциях. Таким образом, должна быть обеспечена возможность экспорта информации, хранящейся в Системе. 4.2.2.2.1 Требования к механизмам информационного взаимодействия с внешними информационными системами для экспорта сведений из Системы Требуется проанализировать целесообразность и особенности получения информации из Системы основными внешними информационными системами, использующими информацию об услугах и функциях, в частности: ПГУ МО. Портал государственных услуг Московской области обеспечивает доступ физических и юридических лиц к сведениям о государственных и муниципальных услугах, государственных функциях по контролю и надзору, об услугах государственных и муниципальных учреждений, об услугах организаций, участвующих в предоставлении государственных и муниципальных услуг, а также предоставление в электронной виде государственных и муниципальных услуг на территории Московской области. ФРГУ. Федеральный реестр государственных услуг (функций). Информационная система, содержащая информацию обо всех государственных и муниципальных услугах (функциях), предоставляемых ОГВ и ОМСУ в Российской Федерации. РСМЭВ МО. Система межведомственного взаимодействия Московской области, обеспечивающая возможность информационного обмена (запроса и получения информации, требуемой для предоставления услуг и исполнения функций) между различными ЦИОГВ и ОМСУ. В системе также хранится информация обо всех доступных межведомственных взаимодействиях (веб-сервисах, предоставляющих информацию). АИС МФЦ МО. Информационная система автоматизации деятельности многофункциональных центров предоставления государственных и муниципальных услуг Московской области, обеспечивающая организацию предоставления государственных и муниципальных услуг в режиме «одного окна». УНП. «Централизованная информационная система «Учет начислений и платежей Московской области», выступающая в качестве 29 универсальной платежной шины. В рамках данной работы Исполнителем должна быть обеспечена совместимость интеграционных механизмов взаимодействия Системы с перечисленными системами посредством разработки механизма информационного обмена на базе сервиса инкрементального обновления. Разрабатываемый механизм должен передавать расширенный состав сведений об государственных и муниципальных услугах (функциях), передаваемых из Системы. Для повышения эффективности использования внешними информационными системами сведений, хранящихся в Системе, требуется расширить перечень передаваемых сервисом инкрементального обновления параметров государственных и муниципальных услуг (функций). Сервис должен обеспечивать внешние информационные системы необходимым набором сведений о государственных и муниципальных услугах (функциях) для их автономного и комплексного взаимодействия. Формируемый и передаваемый сервисом по запросу внешних информационных систем набор данных должен быть структурирован как иерархический справочник, содержащий сведения о государственной (муниципальной) услуге (функции) и об ЦИОГВ и ОМСУ, ее предоставляющим. Должна быть обеспечена передача следующих сведений: Орган власти / Организация: o идентификатор; o идентификатор во внешней системе; o вышестоящий орган; o полное наименование; o краткое наименование; o тип органа власти (организации); o руководитель органа власти (организации); o тип подчинения; o административный уровень; o веб-сайт; o электронная почта; o регион; o перечень офисов: наименование офиса; идентификатор офиса; o перечень контактов: контактное лицо (ФИО); телефон/факс; электронная почта; офис. Паспорт государственной (муниципальной) услуги (функции): o идентификатор; o полное наименование государственной (муниципальной) услуги (функции); o краткое наименование государственной (муниципальной) услуги (функции); o участвующие организации: орган власти (организация); тип участия (предоставление услуги (исполнение функции), участие в предоставлении услуги (исполнении функции); o классификатор услуг (функций); 30 o адрес предоставления услуги (исполнения функции) в электронном виде; o сведения об административном регламенте предоставления услуги (исполнения функции), в том числе: текст административного регламента; дата утверждения административного регламента; нормативный правовой акт, утвердивший административный регламент; орган власти, утвердивший административный регламент. o Шаблон заявления на предоставление услуги; o Сведения о местах предоставления услуги и информирования об услуге; o Основания для отказа в предоставлении услуги (исполнении функции); o сведения о подуслугах (подфункциях), в том числе: Стоимость и порядок оплаты; Реквизиты, необходимые для оплаты; Сроки предоставления услуги (исполнения функции); Типы и категории получателей; Жизненные ситуации; Возможные результаты предоставления услуги (исполнения функции); Документы, необходимые для предоставления услуги (исполнения функции), в том числе: Предоставляемые заявителем; Находящиеся в распоряжении органов власти, участвующих в предоставлении услуги (исполнении функции). Для каждого документа при этом передаются: Тип документа; Вид документа; Шаблон и пример документа. Для документов, находящихся в распоряжении органов власти, участвующих в предоставлении услуги (исполнении функции), дополнительно передаются: Орган власти, предоставляющий документ; Срок предоставления документов; Перечень входящих документов по запросу. o Описание административных процедур, исполняемых в процессе предоставления услуги (исполнения функции), в соответствии с административным регламентом, в формате, совместимом с нотацией BPMN 2.0, в том числе: Состав, последовательность и сроки выполнения административных процедур (действий); Исполнители по каждому действию; Сведения, обрабатываемые при каждом действии; Сведения, передаваемые от исполнителя исполнителю; Должна быть реализована возможность выделения типизированных шагов в процессе предоставления государственных (муниципальных) услуг (исполнения государственных (муниципальных) функций). 31 В ходе исполнения Государственного контракта Исполнителем должен быть предложен уточненный состав данных, передаваемых разрабатываемым сервисом. Спецификация сервиса должна быть разработана Исполнителем, согласована с Государственным заказчиком и включена в техническую и эксплуатационную документацию на Систему. 4.2.3 Требования к функциям Модуля аналитики 4.2.3.1 Требования к аналитическим механизмам мониторинга качества описаний услуг и функций Для обеспечения возможности мониторинга качества описаний услуг и функций должен быть разработан механизм использования «референтных профилей» – наборов правил, описывающих референтные значения отдельных полей описаний услуг и функций. В референтный профиль может быть включено произвольное количество полей описаний услуг и функций. Правила, описывающие референтные значения полей, должны зависеть от формата поля. Одному полю могут соотноситься несколько правил. Варианты типов правил должны быть предложены Исполнителем, согласованы с Государственным заказчиком и приведены в технической и эксплуатационной документации на Систему. К возможным типам правил относятся: определение точного значения поля (применимо для всех форматов полей); определение диапазона, в котором должно находиться значение в поле (применимо для полей с числовыми значениями и датами); определение словоформ, которые должны встречаться/отсутствовать в значении поля (применимо для текстовых полей). Для ввода и просмотра референтных профилей должен быть реализован отдельный раздел Системы. В разделе пользователь, которому были предоставлены соответствующие права в настройках Системы, должен иметь возможность ввести, отредактировать, скопировать и удалить референтный профиль. Для проведения анализа должна быть обеспечена возможность выбора требуемого референтного профиля и перечня услуг, с которыми он будет сравниваться. По результатам анализа выявляются описания, удовлетворяющие и неудовлетворяющие референтным значениям профиля. По итогам проведения анализа должен формироваться отчет, в котором должны быть отражены те описания, в которых выявляются отклонения от референтных значений каких-либо полей. Структура и порядок заполнения отчета должны быть предложены Исполнителем, согласованы с Государственным заказчиком и приведены в технической и эксплуатационной документации на Систему. Необходимо предоставить возможность проведения анализа корректности заполнения для отдельной услуги или функции. При этом требуется обеспечить возможность запуска процедуры анализа как из формы отдельного референтного профиля (на основе которого проводится анализ), так и из формы ввода сведений услуги или функции, для которой должен быть проведен анализ. После проведения анализа необходимо обеспечить индикацию тех полей описаний услуги или функции, в которых выявлены отклонения от референтных значений используемого референтного профиля. Также должна быть реализована возможность использования референтных профилей для настройки публикатором оповещений о передаче для публикации либо актуализации информации описаний услуг и функций, соответствующих либо несоответствующих определенным референтным профилям. 32 4.2.3.2 Требования аналитических отчетов к формированию преднастроенных В Системе должна быть реализована возможность формирования в табличной форме не менее 5 и не более 10 преднастроенных аналитических отчетов, предназначенных для анализа следующей информации, представленной в Системе: Общая статистика по услугам и функциям в следующих разрезах: o государственные/муниципальные; o услуги/функции; o платные/бесплатные; o типовая/не типовая; o по возможности получить в МФЦ; o по сферам деятельности; o по жизненным ситуациям; o по текущему и плановому этапу оказания (межвед /не межвед); o по категориям и социальному статусу заявителей. Сведения о типовых услугах, основная статистика и сведения по ним (наименование, количество муниципальных услуг, базирующихся на типовых, дата создания). Сведения об измененных и опубликованных услугах и функциях за определенный период. Сведения об услугах, не соответствующих требованиям качества. Сведения об исправлениях. Перечень, структура и форматы представления отчетов должны быть предложены Исполнителем, согласованы с Государственным Заказчиком на этапе проектирования и включены в техническую и эксплуатационную документацию на Систему. 4.2.3.3 Требования к аналитическому инструментарию для анализа информации, хранящейся в Системе, с целью контроля над качеством описаний услуг и функций Для повышения качества описаний услуг и функций и более эффективной обработки хранящейся в ней информации требуется разработать аналитический инструментарий, позволяющий подготавливать пользовательские запросы к базе данных Системы, представлять хранящиеся в Системе сведения в различных разрезах, настраивать и формировать пользовательские аналитические отчеты по сформированным разрезам информации. Аналитический инструментарий должен представлять механизм подготовки и реализации пользовательских запросов на выборку информации из базы данных. Требуется разработать механизм, позволяющий пользователю формировать собственные типы запросов к информации, размещенной в базе данных Системы, инициировать выполнение сформированных запросов, просматривать и выгружать сведения, полученные в ходе их выполнения. Для реализации механизма запросов необходимо разработать соответствующий подраздел, в котором пользователю должна быть предоставлена возможность настраивать пользовательские запросы по полям информационных сущностей, хранящихся в Системе: описаниям услуг и функций, сведениям об ЦИОГВ, ОМСУ и пр. Должна быть предоставлена возможность задания основных правил для фильтрации запрашиваемой выборки по различным полям (колонкам) с учетом взаимосвязей информационных сущностей, информация о которых должна быть получена в ходе выполнения запроса. Интерфейс пользователя для подготовки запросов должен быть максимально упрощен, для возможности его использования 33 широким кругом пользователей. Предоставление пользователям Системы прав на формирование запросов должно осуществляться администратором Системы. Подготовленные запросы должны храниться в Системе: требуется реализовать возможность их редактирования и удаления. Требуется обеспечить доступ пользователя только к тем запросам, которые были подготовлены им. Просмотр запросов других пользователей должен быть доступен лишь администратору Системы. Результаты запроса должны быть доступны для просмотра пользователем. Кроме того, должна быть реализована функция экспорта результатов в файлы наиболее распространенных форматов (csv, pdf и т.п.). 4.3 Требования к видам обеспечения 4.3.1 Требования к математическому обеспечению Требования к математическому обеспечению не предъявляются. 4.3.2 Требования к информационному обеспечению 4.3.2.1 Требования к составу, структуре и способам организации данных в системе Основными информационными объектами Системы являются: Орган власти / Организация. Паспорт государственной услуги (функции). Справочник документов. Справочник НПА. Требования к составу, структуре и способам организации данных Системы должны быть определены на этапе технического проектирования и утверждены Государственным заказчиком (документ «Пояснительная записка к техническому проекту»). 4.3.2.2 Требования к организации ввода данных в систему Система должна обеспечивать однократный ввод данных вне зависимости от того, в каких информационных массивах или базах данных они будут храниться и какими функциональными модулями использоваться. 4.3.2.3 Требования компонентами системы к информационному обмену между Информационный обмен между компонентами Системы должен осуществляться без вмешательства пользователя и без повторного ручного ввода информации. 4.3.2.4 Требования по использованию общероссийских и других утвержденных классификаторов, унифицированных документов и др. Требования по использованию общероссийских и других утвержденных классификаторов определены техническими заданиями на создание и развитие Системы. Дополнительных требований не предъявляется. Требования, определённые указанными техническими заданиями, реализованы в рамках соответствующих государственных контрактов и не подлежат проверке при приёмке результатов работ по настоящим ТТ. 34 4.3.2.5 Требования к разработке дополнительных классификаторов Требований по разработке дополнительных классификаторов при реализации доработок Системы не предъявляется. 4.3.2.6 Требования по применению систем управления базами данных Для хранения данных в Системе должны использоваться реляционные базы данных, обеспечивающие реализацию встроенных механизмов построения индексов и контроля целостности данных. 4.3.2.7 Требования к защите данных от разрушений при авариях и сбоях в электропитании системы Требования к защите данных от разрушений при авариях и сбоях в электропитании системы определены техническими заданиями на создание и развитие Системы. Дополнительных требований не предъявляется. Требования, определённые указанными техническими заданиями, реализованы в рамках соответствующих государственных контрактов и не подлежат проверке при приёмке результатов работ по настоящим ТТ. 4.3.2.8 Требования восстановлению данных к контролю, хранению, обновлению и Требования к контролю, хранению, обновлению и восстановлению данных определены техническими заданиями на создание и развитие Системы. Дополнительных требований не предъявляется. Требования, определённые указанными техническими заданиями, реализованы в рамках соответствующих государственных контрактов и не подлежат проверке при приёмке результатов работ по настоящим ТТ. Исполнителем должен быть разработан регламент резервного копирования и восстановления в соответствии с приложением Б. 4.3.2.9 Требования к процедуре придания юридической силы документам, продуцируемым техническими средствами Системы Придание юридической силы электронным документам должно обеспечиваться комплексом организационно-технических мероприятий, разрабатываемых, планируемых и проводимых в соответствии с нормативными требованиями, установленными согласно Федеральному закону Российской Федерации от 6 апреля 2011 г. № 63-ФЗ «Об электронной подписи». Основным требованием для придания юридической силы электронным документам является использование ЭП. Технические средства, информационные и программные средства развиваемой модернизируемой Системы должны обеспечивать выполнение требований нормативных документов и Федерального закона Российской Федерации от 6 апреля 2011 г. № 63-ФЗ «Об электронной подписи» к применению ЭП для придания документам юридической силы. 4.3.3 Требования к лингвистическому обеспечению Все экранные формы, выходные формы, инструкции по работе, вся документация должны быть выполнены на русском языке. Исключения могут составлять только системные сообщения, не подлежащие русификации. 35 4.3.4 Требования к программному обеспечению на серверах и клиентских рабочих местах Система должна функционировать на аппаратно-программных средствах, предоставляемых Государственным Заказчиком, обладающих характеристиками, указанными ниже (Таблица 1 - Таблица 66): Таблица 1 Требования к программному обеспечению сервера приложений Класс ПО Операционная система Системное обеспечение Продукт и версия Microsoft Windows 2003 64 bit или серверная Linux 64 bit и выше или аналоги программное Sun Java Development Kit 7 Таблица 2 Требования к программному обеспечению сервера БД Класс ПО Продукт и версия Операционная система Microsoft Windows 2003 64 bit или серверная Linux 64 bit и выше или аналоги Сервер БД PostgreSQL 9.2 Таблица 3 Требования к конфигурации программного обеспечения клиентской части Компонент Операционная система Веб-обозреватель Конфигурация Microsoft Windows XP, Windows Vista, Windows 7, или Ubuntu Linux 11.04 Gnome 3.2 и выше или аналоги В ОС Linux должны быть установлены следующие системные библиотеки с версиями не ниже указанных: GTK 2.2.1; ATK 1.2.0; glib 2.2.1; Pango 1.2.1; Freetype 2.1.3 Mozilla FireFox 12.0 и выше 4.3.5 Требования к техническому обеспечению Система должна функционировать на аппаратных средствах, предоставляемых Государственным заказчиком, с характеристиками, указанными в Таблицах 4, 5, 6. 36 Таблица 4 Требования к конфигурации аппаратного обеспечения сервера базы данных Компонент Конфигурация Центральный процессор 2x Intel® XEON® 5500 (Nehalem) или аналог Оперативная память Не менее 32 Гб Дисковая подсистема Не менее 3000 ГB Устройство резервного копирования Внешний накопитель, обеспечивающий хранение требуемого объема информации Сетевая плата 2х Ethernet 1 Гбит Таблица 5 Требования к конфигурации аппаратного обеспечения сервера приложений Компонент Конфигурация Центральный процессор 2х Intel® XEON® 5500 (Nehalem) или аналог Оперативная память Не менее 16 Гб Дисковая подсистема Не менее 5х 500 Гб, SAS RAID 5E или RAID 6 Устройство резервного копирования Внешний накопитель, обеспечивающий хранение требуемого объема информации Сетевая плата 2х Ethernet 1 Гбит Таблица 6 Требования к конфигурации аппаратного обеспечения клиентской части (рабочая станция пользователя) Компонент Конфигурация Центральный процессор Intel Core i3 и выше или аналог Оперативная память Не менее 4 Гбайт Дисковая подсистема Не менее 40 Гбайт Дополнительное оборудование Монитор не менее SVGA 1280x720, мышь, клавиатура Сетевая плата Не менее 100 Мбит 4.3.6 Требования к организационному обеспечению Требования к организационному обеспечению определены техническими заданиями на создание и развитие Системы. 37 В рамках реализации работ по модернизации Системы Исполнителем должны быть подготовлены проекты организационно-распорядительных документов, которые приведены в п.8. Исполнителем должен быть разработан и представлен на согласование и утверждение Государственному заказчику Регламент по работе с Реестром, который должен быть согласован с Государственным заказчиком. В разрабатываемом Регламенте по работе с Реестром должна быть отражена следующая информация: ответственность и полномочия должностных лиц при создании, изменении и удалении объектов Реестра (как на муниципальном уровне, так и на уровне ЦИОГВ Московской области); правила выдачи квалифицированной ЭП ответственным лицам; правила подписания квалифицированной ЭП объектов Реестра при их согласовании их описания и публикации. 4.3.7 Требования к методическому обеспечению В рамках реализации работ по модернизации Системы должны быть разработаны методические материалы, регламентирующие реализацию доработанных функциональных возможностей системы и оформленные в виде следующих документов: Методические материалы для работы с Системой. В данный документ должны быть включены методические рекомендации по использованию Системы в форме вопрос-ответ (FAQ). Методические материалы для изучения теоретических основ. Объем документации должен соответствовать требованиям п. 8. В виде приложения к Методическим материалам для работы с Системой Исполнителем должен быть разработан и передан Государственному заказчику обучающий видеокурс по работе с модернизированной Системой. Исполнителем должна быть обеспечена консультационная и экспертная поддержки пользователей модернизированной версии Реестра государственных услуг (функций) Московской области в соответствии с требованиями п. 4.3.7.1. Исполнителем должны осуществляться удаленные консультации и экспертная поддержка пилотных ЦИОГВ и ОМСУ в ходе опытной эксплуатации модернизированной Системы в соответствии с требованиями п. 4.3.7.2. 4.3.7.1 Обеспечение консультационной и экспертной поддержки пользователей Государственного заказчика модернизированной версии Реестра государственных услуг (функций) Московской области Исполнитель должен обеспечить консультационную и методическую экспертную поддержку представителей Государственного Заказчика, являющихся пользователями модернизированной версии Реестра государственных услуг (функций) Московской области, по вопросам перехода на доработанную версию Реестра. Консультационная поддержка осуществляется посредством очных и удаленных консультаций. Очные консультации осуществляются Исполнителем посредством присутствия экспертов на совещаниях по запросу Государственного Заказчика. Удаленные консультации должны осуществляться по телефону горячей линии и электронной почте. Очные консультации должны предоставляться в рабочее время с 9-00 до 18-00 (время московское) по запросу Государственного заказчика. 38 4.3.7.2 Удаленные консультации и экспертная поддержка пилотных ЦИОГВ и ОМСУ в ходе опытной эксплуатации модернизированной Системы Удаленные консультации по телефону горячей линии (в коде (495) и (8-800)) и при помощи электронной почты (e-mail) по вопросам, возникающим в ходе опытной эксплуатации (требования к порядку и срокам проведения опытной эксплуатации приведены в п. 6.2) модернизированной Системы, должны осуществляться в режиме 9.00–18.00 (время московское). При этом при обслуживании по горячей линии: среднее время ожидания ответа с момента подачи заявки должно составлять не более 8 рабочих часов; максимальное время ожидания ответа с момента подачи заявки не должно превышать 16 рабочих часов. Для обеспечения опытной эксплуатации Исполнителем должны проводиться мероприятия по методической и технической поддержке, для этого должна быть создана двухуровневая служба поддержки: первая линия поддержки, осуществляющая «горячую линию» поддержки и дающая разъяснения по типовым методическим вопросам и вопросам о поддерживаемой системе; вторая линия поддержки, оказывающая поддержку в части возникающих проблем и вопросов, не являющихся типовыми. Первая линия поддержки должна обеспечивать предоставление единой точки входа для всех обращений представителей ЦИОГВ и ОМСУ и осуществлять следующие функции: прием обращений от представителей ЦИОГВ и ОМСУ по телефону или электронной почте; ведение базы данных поступающих обращений; предоставление ответа на типовые вопросы; передача нетиповых запросов на 2-ю линию поддержки; контроль над исполнением обращений. Вторая линия поддержки должна обрабатывать поступившие запросы от первой линии поддержки и осуществлять следующие функции: прием и анализ поступивших запросов от первой линии поддержки на предмет принципиальной решаемости запроса; уточнение деталей запроса у контактного лица, указанного при регистрации запроса; решение проблемы, описанной в заявке (в случае ее решаемости), или подготовка обоснования, по которому проблема не может быть решена; внесение поступивших предложений по доработке Системы в Перечень возможных доработок и рекомендаций. Запросы, находящиеся вне сферы компетенции Исполнителя (согласно настоящим требованиям), должны не позднее чем в течение 8-и рабочих часов передаваться на уровень Государственного Заказчика. Ответы, полученные от Государственного Заказчика, должны не позднее чем в течение 8-ми часов после их получения доводиться до авторов запроса. В ходе проведения опытной эксплуатации Системы Исполнитель должен вести журнал учета обращений, содержащий: порядковый номер запроса; дата, время поступления запроса; вид запроса (по телефону/электронной почте); дата, время направления ответа; 39 ФИО обратившегося представителя ЦИОГВ и ОМСУ; контактный телефон; контактный e–mail; содержание запроса; содержание ответа/предпринятые меры. По завершению опытной эксплуатации Системы Исполнитель должен предоставить Государственному Заказчику отчет об оказанной методической и технической поддержке, включающий: основные параметры работы: среднее и максимальное время ожидания, среднее и максимальное время предоставления ответа, количество запросов переданных на уровень Государственного Заказчика; информацию об обращениях: дату и время обращения; способ обращения; контактные данные обратившегося за поддержкой, описание вопроса, по которому произошло обращение; краткое содержание обращения; содержание ответа на обращение. Журнал учета обращений, а также справочные и аналитические материалы, подготавливаемые для участия в совещаниях, должны войти в состав отчетных материалов о результатах выполненных работ. 4.3.8 Требования к телекоммуникационному обеспечению системы В результате модернизации Реестра не предполагается рост количества пользователей системы и увеличение пропускной способности каналов связи. Требования к телекоммуникационному обеспечению предоставляемому Государственным заказчиком, приведены в таблице 7. Системы, Таблица 7 Требования к телекоммуникационному обеспечению Системы Канал связи Требование Сервер приложений – сервер Не ниже 1000Мбит/с сервер приложений и сервер СУБД СУБД должны находиться в одной подсети Приложение – Приложение Сервер реестра – место пользователя Не ниже 100Мбит/с рабочее Не ниже 1 Мбит/с 40 5 Состав и содержание работ по модернизации системы Система должна модернизироваться в 3 этапа. Этапы проведения работ по модернизации Системы приведены в таблице ниже (см. Таблица 8). Таблица 8 — Этапы проведения работ по модернизации Системы № этапа 1 Работа Результаты / Отчётные документы объекта Пояснительная записка к техническому проекту содержащая, как минимум: описание автоматизируемых Проведение технического функций, информационного и проектирования Системы на основании программного обеспечения и результатов обследования объекта технических средств, схему автоматизации и требований ТТ. функциональной структуры Разработка технического проекта на Системы; основании результатов обследования описание проектных решений, объекта автоматизации и требований ТТ, технических и программных средств содержащего конкретные предложения обеспечения информационной Исполнителя в форме вариантов безопасности Системы. решений, в том числе по составу и Программа и методика автономных содержанию отчетной документации, и предварительных испытаний разработанного методических рекомендаций по модуля контроля качества и доработанного использованию Системы. модуля аналитики. Разработка Модуля контроля качества в Проекты организационно-распорядительных следующем объеме: документов предварительных автономных раздельное представление испытаний (Протокол предварительных описаний услуг и функций в автономных испытаний и Акт проведения Системе в соответствии с предварительных автономных испытаний). требованиями п. 4.2.1.4 ТТ; определение нормативноутвержденного перечня услуг, предоставляемых ЦИОГВ или ОМСУ в соответствии с требованиями п. 4.2.1.5 ТТ. Доработка механизма формирования преднастроенных аналитических отчетов в модуле аналитики в соответствии с требованиями п. 4.2.3.2 ТТ. Проведение предварительных автономных испытаний разработанного модуля контроля качества и доработанных функциональных возможностей модуля аналитики. Проведение обследования автоматизации. Срок 15 календарных дней с даты заключения государствен ного контракта 41 № этапа 2 Результаты / Отчётные документы Работа Разработка технической эксплуатационной документации. и Техническая и эксплуатационная 5 декабря документация на Систему: 2014 Разработка регламента по работе с Реестром в соответствии с требованиями п. 4.3.6 ТТ. Развертывание ПО модернизированной версии Системы Настройка информационного обеспечения. Общее описание Системы; Описание программного обеспечения и комплекса технических средств; Руководство пользователя; Руководство администратора; Руководство системного программиста; Настройка интерфейсов для Руководство программиста; взаимодействия с внешними Описание программы. информационными системами. Регламент по работе с Реестром. Конвертация данных из текущей версии Ведомость машинных носителей Реестра в разработанную Систему в информации. соответствии с требованиями п. 7 ТТ. Программа и методика предварительных Подготовка и проведение испытаний. предварительных автономных и Проекты организационно-распорядительных комплексных испытаний в соответствии с документов предварительных испытаний Программой и методикой (Протокол предварительных испытаний, Акт предварительных испытаний. проведения предварительных испытаний, Разработка программного обеспечения в Приказ о начале опытной эксплуатации, Акт соответствии с требованиями п. 4.2 ТТ в о завершении опытной эксплуатации составе: Системы и допуске системы к приемочным Модуль контроля качества. испытаниям) доработанной версии Реестра. Модуль информационного обмена. Программа опытной эксплуатации Системы. Модуль аналитики. Дистрибутив (программа ЭВМ) и исходные коды Системы Разработка Программы эксплуатации Системы. Срок опытной 42 № этапа 3 Результаты / Отчётные документы Работа Срок Подготовка персонала в соответствии с Методические материалы для работы с 20 декабря требованиями п. 7 ТТ, а именно: Системой. 2014 года подготовки Программа подготовки персонала. Методические материалы для изучения теоретических основ. разработка комплекта материалов; составление графика подготовки Обучающий видеокурс по работе с модернизированной Системой. персонала; разработка персонала; методики проведение подготовки персонала; График подготовки персонала. формирование отчета о подготовке Отчет (ведомость) прохождения подготовки персонала. персонала. Обеспечение консультационной и Журнал опытной эксплуатации Системы экспертной поддержки пользователей модернизированной версии Реестра государственных услуг (функций) Московской области в соответствии с требованиями п. 4.3.7.1 ТТ. Удаленные консультации и экспертная поддержка пилотных ЦИОГВ и ОМСУ в ходе опытной эксплуатации разработанной Системы в соответствии с требованиями п. 4.3.7.2 ТТ. Проведение Системы. опытной Программа испытаний. и методика приемочных Проекты организационно-распорядительных документов приемочных испытаний (Протокол приемочных испытаний доработанной версии Реестра, Акт с заключением о возможности передачи доработанной версии Реестра в постоянную эксплуатацию, Приказ о вводе в постоянную эксплуатацию). эксплуатации Дистрибутив (программа ЭВМ) и исходные коды доработанной по результатам опытной доработанного по эксплуатации Системы Развертывание результатам опытной эксплуатации ПО модернизированной версии Системы Проведение приёмочных испытаний. 43 6 Порядок контроля и приемки системы 6.1 Общие требования к контролю этапа разработки Системы Каждый этап закрывается актом о выполненных работах. Государственный Заказчик имеет право осуществлять контроль и запрашивать информацию о ходе выполнения работ по своему усмотрению, но не чаще 1 раза в неделю. 6.2 Виды, состав, объем и методы испытаний системы и ее составных частей В рамках настоящих работ должны быть проведены следующие виды испытаний: предварительные испытания; опытная эксплуатация (ОЭ); приемочные испытания. Испытания должны быть организованы и проведены в соответствии с ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем». Испытания Системы должны проводиться в следующем порядке: проведение предварительных испытаний модернизированной версии Системы; проведение опытной эксплуатации модернизированной версии Системы; проведение приемочных испытаний модернизированной версии Системы. Устранение недостатков в функционировании Системы, выявленных в ходе предварительных испытаний и в ходе опытной эксплуатации должно осуществляться в соответствии с порядком, приведенным в п. 6.5. Объем и методы предварительных и приемочных испытаний определяются соответствующей «Программой и методикой испытаний». Опытная эксплуатация Системы производится на технических средствах, определенных Государственным Заказчиком, соответствующих п. 4.3.5 настоящих ТТ. Срок проведения опытной эксплуатации Системы определяется по согласованию с Государственным Заказчиком в ходе предварительных испытаний Системы, но не может превышать сроки выполнения работ, определенные в настоящих ТТ. Опытная эксплуатация Системы проводится по Программе опытной эксплуатации Системы, разработанной Исполнителем и согласованной с Государственным Заказчиком. Для проведения опытной эксплуатации должны быть реализованы следующие мероприятия: разработана и согласована с Государственным Заказчиком Программа проведения опытной эксплуатации Системы; определен точный перечень пилотных ЦИОГВ и ОМСУ, которые должны принять участие в опытной эксплуатации, обеспечены соответствующие согласования с пилотными организациями. В опытной эксплуатации должны принять участие 6 пилотных организаций, в частности, должно участвовать: 3 пилотных ЦИОГВ; 3 пилотных ОМСУ. 44 Все замечания, предложения и аварийные ситуации, возникающие в ходе проведения опытной эксплуатации должны фиксироваться в Рабочем журнале опытной эксплуатации Системы. По окончанию опытной эксплуатации должен быть составлен Акт о завершении опытной эксплуатации Системы и допуске системы к приемочным испытаниям. Проект Акта о завершении опытной эксплуатации Системы и допуске системы к приемочным испытаниям должен быть подготовлен Исполнителем. Для проведения приемочных испытаний должна быть подготовлена Программа и методика приемочных испытаний, включающая в себя требования к автономным и комплексным предварительным испытаниям. Программа и методика приемочных испытаний разрабатывается с учетом результатов ОЭ. При разработке программы и методики приемочных испытаний Исполнитель должен включить в документ требования по проведению испытаний корректности работы реализованных в Системе функций, протоколов и форматов взаимодействия. По итогам проведения испытаний должен быть оформлен Протокол приемочных испытаний и Акт с заключением о возможности передачи доработанной версии Реестра в постоянную эксплуатацию. 6.3 Общие требования к приемке работ Приемка результатов работ осуществляется поэтапно в соответствии с календарным планом выполнения работ по Государственному контракту с оформлением Акта сдачи-приемки работ. Основанием для составления и подписания Акта сдачи-приемки работ по отдельному этапу является передача Исполнителем результатов работ в соответствии с условиями Государственного контракта и утвержденных сторонами соответствующих Актов приемки в эксплуатацию. После проведения опытной эксплуатации Исполнитель передает Государственному заказчику полный набор логинов, паролей и других параметров доступа к Системе, необходимых для ее развертывания и эксплуатации. Указанные данные включаются в состав эксплуатационной документации. Государственный заказчик в срок не более 5 (пяти) календарных дней с момента получения научно-технической продукции (НТП) производит ее приемку и утверждение Акта сдачи-приемки научно-технической продукции. При приемке научно-технической продукции Государственным заказчиком в части документации на Систему производится проверка соответствия требованиям к документированию Системы (раздел 8). Если в результате выполненных проверок установлены несоответствие требованиям к документации на Систему и\или неактуальность, противоречивость либо неполнота сведений, представленных в отчетных материалах, Государственный заказчик в порядке, определенном Государственным контрактом, возвращает Исполнителю указанную НТП на доработку с указанием причин отказа в приемке. В этом случае приемка работ по этапу откладывается в порядке, определенном Государственным контрактом, до момента полного устранения замечаний Государственного заказчика по представленной НТП. При нарушении сроков исполнения этапа применяются соответствующие положения Государственного контракта. В случае отсутствия замечаний к представленной НТП, Государственный заказчик утверждает Акт приема-передачи научно-технической продукции. Предусмотренные испытания (п. 6.2) проводятся комиссией, формируемой Государственным Заказчиком на основании распорядительного документа, который должен определять состав комиссии проведения испытаний (предварительных и приемочных испытаний), порядок ее работы, место и сроки проведения испытаний. 45 В состав комиссии должны быть включены представители Государственного Заказчика и Исполнителя. Результаты проведения испытаний должны быть зафиксированы в соответствующих Протоколах испытаний. Как недостатки реализации оформляются исключительно выявленные отклонения от настоящих ТТ. Выявленные недостатки ранжируются по степени критичности (критичные, менее критичные, не критичные) Условием сдачи работ по этапу или Государственному контракту в целом является устранение всех недостатков с высоким и среднем уровнем критичности. В случае значительного отклонения Системы от требований, предъявляемых на испытаниях, сроки проведения испытаний могут быть перенесены / расширены Государственным заказчиком в пределах сроков выполнения работ, определенных в Государственном контракте. 6.4 Сведения о гарантийном обслуживании системы Исполнитель должен предоставить гарантии качества работ, проведенных в рамках Государственного контракта, сроком на 1 год на весь объем работ, реализованный в рамках настоящих ТТ. Под сроком предоставления гарантии качества работ понимается период времени, начинающийся с момента завершения работ по Государственному контракту и подписания Акта сдачи-приемки работ 3 этапа, в течение которого Исполнитель обязуется в отношении Системы выполнять работы по устранению выявляемых технических ошибок (дефектов) в следующем объеме: организация «горячей линии» по телефону и электронной почте с целью приема и обработки информации о технических ошибках (дефектах) и нештатных ситуациях в работе системы по рабочим дням; обращения, поступившие на «горячую линию», должны быть обработаны не позднее 2-х рабочих дней с момента регистрации обращения; анализ информации о технических ошибках (дефектах) в работе системы, выработка с ответственным сотрудником объекта автоматизации предложений по срокам и способам их преодоления; при необходимости внесении изменений в Систему в целях устранения выявленных технических ошибок (дефектов) и предоставление Государственному заказчику обновлений Системы; восстановление работоспособности Системы и баз данных при возникновении внештатных ситуаций с выездом специалистов Исполнителя на объект автоматизации. Исполнитель не гарантирует отсутствие недостатков или сбоев в процессе работы, возникающих по причине несоответствия оборудования или установленного на рабочем месте программного обеспечения конечного пользователя требованиям, предъявляемым к характеристикам клиентских мест. 6.5 Порядок выполнения доработок и устранения допущенных исполнителем ошибок, которые выявлены в процессе испытаний и в период гарантийного обслуживания Недостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний, должны быть устранены Исполнителем в рамках выполнения работ по Государственному контракту. Порядок устранения замечаний и реализации рекомендаций комиссии должен быть определен в документах «Программа и методика испытаний» и «Программа опытной эксплуатации». Сроки устранения замечаний и рекомендаций, данных приемочной комиссией в ходе испытаний, определяются в Актах приемки в эксплуатацию. 46 В ходе проведения опытной эксплуатации должен быть осуществлен анализ показателей функционирования доработанной версии Реестра, с учетом замечаний и предложений пользователей, задействованных в проведении опытной эксплуатации. На основе проведенного анализа должен быть сформирован перечень замечаний к работе компонентов Реестра, которые необходимо устранить. В качестве основного документа для выявления замечаний к работе компонентов Реестра должен выступать Журнал опытной эксплуатации Системы. Возможными основаниями для проведения доработки являются: предложения пользователей по оптимизации (доработка функциональных возможностей, деталей реализации функциональности, логики взаимодействия с пользователем и пр.); дефекты, выявленные в ходе опытной эксплуатации. Перечень замечаний к работе Реестра, которые необходимо устранить, должен быть оформлен в виде отдельного документа, согласованного Государственным Заказчиком и Исполнителем до начала доработок вместе с предлагаемыми решениями по реализации. По результатам проведенных доработок должна быть актуализирована эксплуатационная и техническая документация на Систему. Исполнитель производит устранение замечаний к работе Реестра до проведения приемочных испытаний. По согласованию с Государственным Заказчиком часть замечаний к работе Реестра, которые необходимо устранить, может быть перенесена на период гарантийных обязательств Исполнителя в рамках настоящих ТТ. Недостатки и ошибки в реализации Системы, выявленные в период гарантийного обслуживания устраняются Исполнителем в рамках очередного обновления системы, или в рамках внеочередного экстренного обновления в случае, если обнаруженные ошибки препятствуют или ограничивают эксплуатацию Системы в штатном режиме. Исполнителем должны быть внесены соответствующие актуализирующие исправления в техническую и рабочую документацию, связанные с устранением замечаний к работе Системы и предъявлены Государственному заказчику на приемосдаточные испытания или до завершения срока гарантийного обслуживания для замечаний опытной эксплуатации или гарантийного обслуживания соответственно. 6.6 Сведения об обслуживании системы Состав работ (услуг) по эксплуатации Системы, а также их периодичность и требования к составу и квалификации обслуживающего персонала определяются в эксплуатационной документации на Систему. При этом требования к эксплуатации компьютерного оборудования, системного и прикладного программного обеспечения, входящего в состав Системы, указываемые в эксплуатационной документации, должны соответствовать требованиям к эксплуатации соответствующего оборудования и программного обеспечения, изложенным в документации, поставляемой вместе с данным оборудованием и программным обеспечением при его приобретении. 47 7 Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие Система должна быть установлена Исполнителем при содействии специалистов Государственного заказчика на оборудовании, предоставленном Государственным Заказчиком (перечень требований к оборудованию приведен в п. 4.3.5). Предварительно Исполнителем должен быть сформирован запрос к Государственному заказчику на предоставление оборудования и сетевых ресурсов, на которых должна быть впоследствии установлена Система. Запрос должен содержать описание конфигурации требуемого оборудования. Должен быть установлен передаваемый на машинных носителях дистрибутив и проведена предварительная конфигурация. Дальнейшее конфигурирование должно быть выполнено Исполнителем (сервисным оператором) в соответствии с инструкцией по развертыванию системы, приведенной в Руководстве администратора. После установки модернизированной версии Реестра должна быть обеспечена конвертация данных из текущей версии Реестра государственных услуг (функций) Московской области в доработанную версию Реестра. Для этого должны быть проведены следующие мероприятия: определен перечень данных для миграции; определена логика осуществления миграции данных; разработаны программные механизмы миграции (скрипты миграции); проведена миграция данных; осуществлена проверка полноты, целостности и непротиворечивости мигрированных данных в БД Системы. В рамках конвертации данных должна быть перенесена информация о государственных и муниципальных услугах и функциях, информация о ЦИОГВ и ОМСУ. Для сохранения целостности и корректности экспортируемых данных по услугам, функциям и ЦИОГВ и ОМСУ также должны быть перенесены актуальные на момент миграции справочники Системы. Создание необходимых для функционирования системы подразделений и служб обеспечивается Государственным заказчиком. В целях обеспечения эффективной работы пользователей с доработанной версией Реестра Исполнителем должна быть проведена подготовка персонала пилотных ЦИОГВ и ОМСУ. Для проведения подготовки пользователей Исполнитель должен: разработать комплект материалов, а именно: o программу подготовки персонала, включающую в себя названия тем, краткое содержание и продолжительность по каждой теме; o методические материалы для изучения теоретических основ работы с Реестром и для практических занятий, позволяющих закрепить теоретический материал; o тестовые задания для оценки знаний слушателей; o ведомость прохождения курса подготовки персонала; составить график подготовки персонала. Государственный заказчик должен обеспечить технически оснащенные помещения для проведения подготовки персонала. АРМ для подготовки персонала должны соответствовать требованиям, приведенным в эксплуатационной документации на Систему. Допускается применение технических средств Исполнителя для 48 организации и проведения подготовки персонала, в частности, проведение Исполнителем курсов по подготовке персонала в формате вебинаров. Курс должен быть рассчитан на пользователей ПК, обладающих уверенными навыками работы в рамках общепринятых стандартов графических интерфейсов, умеющих использовать офисные приложения работы с текстом и таблицами. Максимальное количество слушателей в группе не должно превышать 20 человек. Количество групп не должно превышать 8. В случае если количество желающих пройти подготовку превысит емкость запланированного количества групп, то Исполнителем по согласованию с Государственным заказчиком может быть принято решение об увеличении количества групп. Государственный заказчик определяет специалистов, для которых проводятся консультации и передает перечень специалистов Исполнителю в письменном виде с указанием требуемого объема подготовки для групп специалистов (целевые группы). По результатам подготовки персонала должен быть составлен отчет, включающий ведомости прохождения курса подготовки персонала, в которых указаны информация о теме консультации, ФИО и должности сотрудников, участвующих в консультировании. 49 8 Требования к документированию Техническая и эксплуатационная документация на Систему (далее – документы на Систему) должна быть разработана в составе, указанном в таблице 8, и должна удовлетворять требованиям комплекса стандартов и руководящих документов на автоматизированные системы: ГОСТ 34.003-90 – в части терминологии; ГОСТ 34.201-89 - в части наименования и обозначения документов; ГОСТ 34.603-92 – в части определения видов испытаний; РД 50-34.698-90 – в части структуры и содержания документов. Документы на Систему оформляют в соответствии с требованиями ГОСТ 2.105 на листах формата А4 по ГОСТ 2.301 без рамки, основной надписи и дополнительных граф к ней. Допускается для размещения рисунков и таблиц использование листов формата А3 с подшивкой по короткой стороне листа. Документы объемом более 25 листов должны содержать информационную часть, состоящую из аннотации и содержания. Документы не должны содержать в колонтитулах указаний на организацию Исполнителя (логотипы, реквизиты, контактную информацию и т.п.). Комплект эксплуатационной документации на Систему должен содержать сведения, достаточные для эксплуатации Системы в соответствии с требованиями нормативных правовых актов4. До ввода Системы в действие Исполнитель передает Государственному Заказчику: полный набор логинов, паролей и других параметров доступа к Системе, необходимых для ее развертывания и эксплуатации. комплект эксплуатационной документации на Систему в части ПО Системы должен содержать исчерпывающее описание СПО, обеспечивающее его установку, настройку, эксплуатацию и сопровождение (технические требования (спецификации), руководства администратора, руководства пользователя). Исполнителем должны быть переданы Государственному заказчику дистрибутив (программа ЭВМ) и исходные коды Системы. Передача исходных кодов СПО должна сопровождаться передачей всех необходимых для сборки библиотек, компиляторов, интерпретаторов, специальной среды разработки (если сборка может быть выполнена только в среде разработки) и т.п. В части организации процесса учета и контроля над предоставлением доступа к информационным системам документ «Руководство администратора» И3 по РД 5034.698-90 должен в том числе определять: порядок процесса выдачи и оперативного отзыва параметров административного доступа к элементам системы (доступ к СУБД, к серверу приложений, доступ на сервер по RDP и т.п.). порядок и формы учета фактов выдачи доступа: кому, на основании чего, на какой период, когда отозваны и т.д. Формальное полное соответствие документов на Систему требованиям РД 50-34.698-90 и ГОСТ 19.ХХХ по составу и структуре разделов не требуется, исключая документ «Руководство пользователя». При этом должно быть достигнуто Закон Московской области от 10.07.2009 г.№ 80/2009-ОЗ «О государственных информационных системах Московской области и обеспечении доступа к содержащейся в них информации». 4 50 адекватное описание всех видов обеспечения Системы, достаточное для подготовки персонала, развертывания, эксплуатации и сопровождения Системы по всем позициям, определяемым РД 50-34.698-90 и ГОСТ 19.ХХХ для отдельных документов. Документы «Руководство пользователя», «Руководство администратора» по РД 50-34.698-90 и другие документы, регламентирующие деятельность персонала, должны содержать описание выполнения операций (действий) персонала в технологическом процессе Пользователя Системы5, т.е. описание должно строиться на основе технологических задач персонала с использованием возможностей Системы и не должно сводиться к простому описанию (перечислению) функций Системы. Документ «Общее описание системы» должен включать описание всех составляющих модулей Системы и их внутренней структуры до уровня отдельных функций (задач). Состав документации на Систему определен ниже (Таблица 8). Разработка указанной документации на Систему по стадиям и этапам определена в разделе 5. Таблица 8 Состав документации на Систему Наименование6 Программа и методика предварительных автономных испытаний разработанного модуля контроля качества и доработанного модуля аналитики Проекты организационнораспорядительных документов предварительных автономных испытаний разработанного модуля контроля качества и доработанного модуля аналитики (Протокол предварительных испытаний прототипа Реестра и Акт проведения предварительных испытаний) Пояснительная записка к Техническому проекту на Систему Общее описание системы Руководство пользователя Руководство администратора Описание программного Обозн ачение Вид обеспечения Входит в Этап в экспл. соответствии с документацию ТТ Общесистемные решения ПМ.01 ПМ.03 П2.01 Общесистемные решения Общесистемные решения Нет 1 этап Нет 1 этап Нет 1 этап ПД Общесистемные решения Да 2 этап И3.01 Организационное обеспечение Да 2 этап Да 2 этап Нет 2 этап И3.02 ПА Организационное обеспечение Программное В соответствии с разделами 1 и 2 ТТ Классификация документов и обозначение документов – в соответствии с ГОСТ 34.201-89, ГОСТ 19.101-77-82 и ГОСТ 7.32-91 5 6 51 Наименование6 обеспечения и комплекса технических средств Руководство системного программиста Обозн ачение Вид обеспечения Входит в Этап в экспл. соответствии с документацию ТТ обеспечение 32 Организационное обеспечение Да 2 этап Руководство программиста 33 Организационное обеспечение Да 2 этап Описание программы 13 Программное обеспечение Да 2 этап Ведомость машинных носителей информации ВМ Информационное обеспечение Нет 2 этап Нет 2 этап Программа и методика предварительных испытаний доработанной версии Реестра ПМ.01 Проекты организационнораспорядительных документов предварительных испытаний (Протокол предварительных испытаний, Акт проведения предварительных испытаний, Приказ о начале опытной эксплуатации, Акт о завершении опытной эксплуатации Системы и допуске системы к приемочным испытаниям) доработанной версии Реестра ПМ.03 Общесистемные решения Нет 2 этап Программа опытной эксплуатации Системы ОЭ.01 Общесистемные решения Нет 2 этап Методические материалы для работы с Системой ПП.01 Организационное обеспечение Да 3 этап Программа персонала ПП.02 Организационное обеспечение Нет 3 этап ПП.04 Организационное обеспечение Нет 3 этап ПП.05 Организационное обеспечение Нет 3 этап Нет 3 этап подготовки Методические материалы для изучения теоретических основ График подготовки персонала Отчет прохождения персонала (ведомость) подготовки ПП.06 Общесистемные решения Организационное обеспечение Журнал опытной эксплуатации Системы ОЭ.02 Общесистемные решения Нет 3 этап Программа и методика приемочных испытаний ПМ.02 Общесистемные решения Нет 3 этап Проекты организационнораспорядительных документов приемочных испытаний (Протокол приемочных ПМ.03 Нет 3 этап Общесистемные решения 52 Наименование6 испытаний доработанной версии Реестра, Акт с заключением о возможности передачи доработанной версии Реестра в постоянную эксплуатацию, Приказ о вводе в постоянную эксплуатацию) Обозн ачение Вид обеспечения Входит в Этап в экспл. соответствии с документацию ТТ 53 9 Источники разработки ТТ разработаны с использованием следующих источников: Государственная программа Российской Федерации «Информационное общество (2011-2020 годы)». Федеральный закон от 27 июля 2010 г. № 210-ФЗ «Об организации предоставления государственных и муниципальных услуг». Федеральный закон от 26 декабря 2008 г. № 294-ФЗ «О защите прав юридических лиц и индивидуальных предпринимателей при осуществлении государственного контроля (надзора) и муниципального контроля». Постановление Правительства РФ от 24 октября 2011 г. N 861 «О федеральных государственных информационных системах, обеспечивающих предоставление в электронной форме государственных и муниципальных услуг (осуществление функций)». Постановление Правительства РФ от 16 мая 2011г. №373 «О разработке и утверждении административных регламентов исполнения государственных функций и административных регламентов предоставления государственных услуг». Приказ Министерства связи и массовых коммуникаций Российской Федерации от 27 декабря 2010 г. № 190 «Об утверждении технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия». Государственная программа Московской области «Эффективная власть на 2014-2018 годы». Постановление Правительства Московской области от 6 августа 2013 г. N 593/33 «О реестре государственных услуг (функций) Московской области». Постановление Правительства Московской области от 2 июля 2013 г. N 482/27 «О государственной информационной системе Московской области "Портал государственных и муниципальных услуг (функций) Московской области». Постановление Правительства Московской области от 25 апреля 2011 г. N 365/15 «Об утверждении порядка разработки и утверждения административных регламентов исполнения государственных функций и административных регламентов предоставления государственных услуг центральными исполнительными органами государственной власти Московской области, государственными органами Московской области». Постановление Правительства Московской области от 18 мая 2010 г. N 350/20 «Об утверждении системы показателей для оценки эффективности деятельности центральных исполнительных органов государственной власти Московской области, государственных органов Московской области». ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы». РД 50-34.698-90 «АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. Требования к содержанию документов». 54 ПРИЛОЖЕНИЕ А ФОРМА АКТА ПРИЕМА-ПЕРЕДАЧИ НАУЧНО-ТЕХНИЧЕСКОЙ ПРОДУКЦИИ А.1 ТИПОВАЯ ФОРМА АКТА ПРИЕМА-ПЕРЕДАЧИ НАУЧНО-ТЕХНИЧЕСКОЙ ПРОДУКЦИИ Документ «Акт приема-передачи научно-технической продукции» должен быть оформлен в соответствии со следующим примером. АКТ № __ приема-передачи научно-технической продукции по Государственному контракту № ______ от «__» ________ 201_ г. Московская область, г. Красногорск «__» ________ 201_ г. Мы, нижеподписавшиеся, представитель Государственного Заказчика в лице <_д_о_л_ж_н_о_с_т_ь_> <_Ф_а_м_и_л_и_я_ _И_м_я_ _О_т_ч_е_с_т_в_о_>, действующ___ на основании <_Д_о_к_у_м_е_н_т_>, и представитель Исполнителя в лице <_д_о_л_ж_н_о_с_т_ь_> <_о_р_г_а_н_и_з_а_ц_и_я_> <_Ф_а_м_и_л_и_я_ _И_м_я_ _О_т_ч_е_с_т_в_о_>, действующего на основании <_Д_о_к_у_м_е_н_т_>, составили настоящий акт о том, что в соответствии с Государственным контрактом от __.__.201_ г. № _________________ на выполнение работ по теме «Модернизации Реестра государственных услуг (функций) Московской области» (далее – Государственный контракт) Исполнитель передал, а Государственный Заказчик принял научно-техническую продукцию по пп. __, __, __ Календарного плана выполнения работ (Приложение 2 к Государственному контракту). Переданная программно-аналитическая продукция полностью удовлетворяет условиям указанного Государственного контракта и оформлена в установленном порядке. Все претензии третьих лиц в части использования Государственным Заказчиком переданных результатов Исполнитель решает своими силами за свой счет без изменения объемов, сроков и стоимости Государственного контракта. 55 Научно-техническая продукция представлена на бумажном и машинном носителях (оптический диск – CD/DVD) в следующем составе: Обозначение документа Наименование документа СДАЛ ИСПОЛНИТЕЛЬ Кол-во листов Кол-во экз. ПРИНЯЛ ГОСУДАРСТВЕННЫЙ ЗАКАЗЧИК <_д_о_л_ж_н_о_с_т_ь_> <_о_р_г_а_н_и_з_а_ц_и_я_> <_д_о_л_ж_н_о_с_т_ь_> ________________ И.О. Фамилия _______________ И.О. Фамилия «__» ___________ 201_ г. «__» ___________ 201_ г. 56 ПРИЛОЖЕНИЕ Б (ОБЯЗАТЕЛЬНОЕ) РЕГЛАМЕНТ резервного копирования АС «ХХХХ» Общие положения Регламент резервного копирования АС «ХХХХ» (далее - Регламент) разработан в соответствии с Федеральным законом от 27.07.2006 N 149-ФЗ «Об информации, информационных технологиях и о защите информации» и в целях: 1.1 обеспечения бесперебойной работы АС «ХХХХ; 1.2 определения порядка резервного копирования АС «ХХХХ»; 1.3 определения порядка восстановления АС «ХХХХ» при полной или частичной потере информации, вызванной сбоями или отказами аппаратного или программного обеспечения, ошибками пользователей, стихийными бедствиями или иными чрезвычайными обстоятельствами. Настоящим Регламентом определяется порядок действий администратора резервного копирования при выполнении следующих мероприятий: 1.4 резервное копирование информационных ресурсов (далее – ИР) и программного обеспечения (далее – ПО) АС «ХХХХ»; 1.5 контроль резервного копирования ИР и ПО АС «ХХХХ»; 1.6 восстановление ИР и ПО АС «ХХХХ». Резервному копированию подлежат: 1.7 компоненты ИР АС «ХХХХ»: 1.7.1 ____________________________________________________ 1.7.2 ____________________________________________________ 1.7.3 ____________________________________________________ 1.8 компоненты ПО АС «ХХХХ»: 1.8.1 ____________________________________________________ 1.8.2 ____________________________________________________ 1.8.3 ____________________________________________________ Резервное копирование ИР и ПО АС «ХХХХ», обслуживание которых выполняется сторонними организациями в соответствии с государственными контрактами и договорами, осуществляется данными организациями. В целях настоящего Регламента применяются следующие основные понятия: 1.9 резервная копия (архив) - копия ИР или ПО АС «ХХХХ» по состоянию на определенный момент времени, состоящая из группы файлов или папок на одном устройстве хранения резервных копий; 1.10 сервер резервного копирования - сервер, выполняющий резервное копирование ИР и ПО и регистрацию выполненных операций резервного копирования; 1.11 типы процедур резервного копирования: 1.11.1 полное копирование - в одну резервную копию сохраняется весь ИР или ПО АС «ХХХХ» целиком. С помощью полной копии можно восстановить состояние ИР или ПО АС «ХХХХ» на момент создания резервной копии; 57 1.11.2 разностное копирование - сохраняется только та информация, которая изменилась с момента создания последней полной копии; 1.11.3 создание полного образа дисковой подсистемы сервера - данная процедура создает образ сервера со всеми размещенными на нем ИР и ПО АС «ХХХХ» на момент создания образа; 1.12 устройства хранения резервных копий: 1.12.1 жесткие диски с USB интерфейсом, 1.12.2 NAS - сетевая система хранения данных; 1.13 администратор резервного копирования - государственный гражданский служащий _____________________________________, выполняющий функции настройки программного обеспечения и оборудования резервного копирования, восстановления информационных ресурсов ______________________, обслуживаемых _________________________________________ Комплекс технических средств размещения АС «ХХХХ» ИР и ПО АС «ХХХХ» размещены на следующих серверах: 1.14 Сервер 1 _________________________________ 1.15 Сервер 2 _________________________________ 1.16 Сервер 3 _________________________________ 1.17 Контроллеры домена, серверы DNS: ________________________ 1.18 Серверы сетевых сервисов (DHCP, печать, антивирусный, др.) __________________________________________________________ 1.19 Серверы - межсетевые экраны ___________________________ 1.20 Почтовый сервер _______________________ 1.21 Серверы приложений __________________________ Аппаратное обеспечение, применяемое для резервного копирования Для резервного копирования применяется следующее аппаратное обеспечение: 1.22 съемные жесткие диски с USB интерфейсом; 1.23 NAS - сетевые системы хранения данных. Программное обеспечение резервного копирования Резервное копирование осуществляется с использованием следующего программного обеспечения: 1.24 встроенные средства Microsoft Windows Server 2003/2008, Microsoft SQL Server, встроенные средства других систем управления базами данных; 1.25 программное обеспечение CA (Computer Associates) BrightStor ARCserve Backup; 1.26 программное обеспечение Acronis TrueImage EE Server/Acronis Backup&Recovery Server. Плановое резервное копирование информации Администратор резервного копирования настраивает процедуры резервного копирования ИР и ПО АС «ХХХХ» с периодичностью их выполнения не реже, чем указано в Периодичности резервного копирования информационных ресурсов и систем (Приложение 3). 58 Состав копируемой информации, используемые устройства хранения резервных копий, выбор методов резервного копирования и программных средств для выполнения данных операций, ротация резервных копий определяются администратором резервного копирования самостоятельно и могут быть изменены им с целью оптимизации процесса резервного копирования и использования устройств хранения резервных копий. Администратор резервного копирования вправе изменять периодичность проведения операций резервного копирования в сторону уменьшения временных интервалов между процедурами резервного копирования. Ежедневное резервное копирование ИР и ПО АС «ХХХХ» проводится с 19.00 до 8.00 через локальную вычислительную сеть Министерства на сервер резервного копирования. Еженедельное копирование ИР и ПО АС «ХХХХ» проводится в субботу и воскресенье с 00.00 до 24.00 через локальную вычислительную сеть на сервер резервного копирования. Для еженедельного резервного копирования ИР и ПО АС «ХХХХ» применяется полное копирование. Запуск операций резервного копирования информации производится с помощью встроенных средств Microsoft Windows Server 2003/2008, встроенных средств управления базами данных, встроенных средств программ резервного копирования (CA (Computer Associates) BrightStor ARCserve Backup, Acronis TrueImage EE Server/Acronis Backup&Recovery Server). Внеплановое резервное копирование ИР и ПО АС «ХХХХ» Внеплановое резервное копирование ИР и ПО АС «ХХХХ» выполняется администратором резервного копирования в следующих случаях: 1.27 сбоя планового резервного копирования ИР и ПО АС «ХХХХ»; 1.28 установки на сервер нового программного обеспечения, модификации установленного, внесения изменений в конфигурацию локальной вычислительной сети (для контроллеров домена и почтовых серверов). 1.29 Действия администратора резервного копирования при внеплановом сохранении информационных ресурсов и систем описаны в Инструкции администратора резервного копирования при выполнении процедур внепланового резервного копирования ИР и ПО АС «ХХХХ» (Приложение 1). Контроль результатов резервного копирования Контроль результатов выполнения процедур резервного копирования осуществляется администратором резервного копирования в срок до 12.00 рабочего дня, следующего за установленной датой выполнения этих процедур. Контроль результатов резервного копирования производится путем просмотра журналов событий операционной системы и специализированного программного обеспечения. В случае обнаружения сбоя планового резервного копирования администратор резервного копирования выполняет процедуру внепланового резервного копирования ИР и ПО АС «ХХХХ». Восстановление информации из резервных копий Восстановление данных из резервных копий производится администратором резервного копирования самостоятельно в случаях неработоспособности серверов или сервисов либо на основании служебной записки <подразделение>, <должность>, 59 <Фамилия И.О.>, ответственного за наполнение ИР и работоспособность ПО, если содержимое ИР повреждено или нарушена работоспособность ПО АС «ХХХХ». Действия администратора резервного копирования при восстановлении ИР и ПО АС «ХХХХ»описаны в Инструкции администратора резервного копирования при выполнении процедур восстановления ИР и ПО АС «ХХХХ» (Приложение 2). 60 Приложение № 1 к Регламенту ИНСТРУКЦИЯ АДМИНИСТРАТОРА РЕЗЕРВНОГО КОПИРОВАНИЯ ПРИ ВЫПОЛНЕНИИ ПРОЦЕДУР ВНЕПЛАНОВОГО РЕЗЕРВНОГО КОПИРОВАНИЯ ИР и ПО АС «ХХХХ» Причина выполнения процедуры внепланового N Действия администратора резервного копирования п/п копирования ИР и ПО АС «ХХХХ» Сбой выполнения 1. Проверка и устранение причины сбоя выполнения процедуры еженедельного планового резервного 1. процедуры еженедельного копирования: планового резервного 1.1. Проверка функционирования аппаратной части, операционной системы и системных сервисов копирования ИР и ПО АС сервера-источника: «ХХХХ» 1.1.1. Проверка функционирования аппаратной части сервера-источника (дисковые массивы, оперативная память, сетевая карта). Устранение причины сбоя путем замены вышедших из строя компонентов. 1.1.2. Проверка функционирования операционной системы сервера-источника. Устранение причины сбоя путем перенастройки, установки патчей, переустановки операционной системы. 1.1.3. Проверка доступности сервера-источника из локальной вычислительной сети. Проверка функционирования сетевых сервисов операционной системы, сетевых настроек. Устранение причины сбоя путем переустановки и перенастройки сетевых сервисов. 1.2. Проверка функционирования аппаратной части, операционной системы и системных сервисов сервера резервного копирования: 1.2.1. Проверка функционирования аппаратной части сервера резервного копирования NAS (дисковые массивы). Устранение причин сбоя путем ремонта оборудования. 1.2.2. Проверка доступности сервера резервного копирования из локальной вычислительной сети. Проверка сетевых настроек. Устранение причины сбоя путем перенастройки сетевых сервисов. 2. Проверка выполнения процедуры резервного копирования 2. Сбой выполнения 1. Проверка и устранение причины сбоя выполнения процедуры ежедневного планового резервного 61 Причина выполнения процедуры внепланового N Действия администратора резервного копирования п/п копирования ИР и ПО АС «ХХХХ» процедуры ежедневного копирования: резервного копирования ИР 1.1. Проверка функционирования аппаратной части, операционной системы и системных сервисов и ПО АС «ХХХХ» сервера-источника: 1.1.1. Проверка функционирования аппаратной части сервера-источника (дисковые массивы, оперативная память, сетевая карта). Устранение причины сбоя путем замены вышедших из строя компонентов. 1.1.2. Проверка функционирования операционной системы сервера-источника. Устранение причины сбоя путем перенастройки, установки патчей, переустановки операционной системы. 1.1.3. Проверка доступности сервера-источника из локальной вычислительной сети. Проверка функционирования сетевых сервисов операционной системы, сетевых настроек. Устранение причины сбоя путем переустановки и перенастройки сетевых сервисов. 1.2. Проверка функционирования аппаратной части, операционной системы и системных сервисов сервера резервного копирования: 1.2.1. Проверка функционирования аппаратной части сервера резервного копирования NAS (дисковые массивы). Устранение причин сбоя путем ремонта оборудования. 1.2.2. Проверка доступности сервера резервного копирования из локальной вычислительной сети. Проверка сетевых настроек. Устранение причины сбоя путем перенастройки сетевых сервисов. 2. Проверка выполнения процедуры резервного копирования 3. Установка на сервер нового 1. Выполнение процедуры полного резервного сохранения дисковой подсистемы сервера перед установкой, программного обеспечения, модификацией программного обеспечения, внесением изменений в конфигурацию локальной модификация вычислительной сети. установленного. Внесение 2. Выполнение процедуры полного резервного сохранения дисковой подсистемы сервера после установки, изменений в конфигурацию модификации программного обеспечения, внесения изменений в конфигурацию локальной вычислительной ЛВС (для контроллеров сети и проверки работоспособности сервера домена и почтовых серверов) 62 Приложение № 2 к Регламенту ИНСТРУКЦИЯ АДМИНИСТРАТОРА РЕЗЕРВНОГО КОПИРОВАНИЯ ПРИ ВЫПОЛНЕНИИ ПРОЦЕДУР ВОССТАНОВЛЕНИЯ ИР и ПО АС «ХХХХ» N п/п 1. 2. 3. 4. Описание состояния сервера Описание состояния ИР и/или ПО АС Действия администратора резервного копирования Срок восстановлени я ИР и/или ПО АС до 3 часов Аппаратная часть и системное программное обеспечение сервера функционируют корректно Аппаратная часть сервера исправна, системное программное обеспечение функционирует некорректно Аппаратная часть сервера неисправна из-за сбоя дисковой подсистемы ИР и/или ПО АС недоступны, данные ИР и/или ПО АС неверны Восстановление ИР и/или ПО АС из последней резервной копии ИР и/или ПО АС недоступны, данные ИР и/или ПО АС неверны, сервисы недоступны Восстановление состояния сервера из образа дисковой подсистемы до 6 часов ИР и/или ПО АС недоступны, данные ИР и/или ПО АС неверны, сервисы недоступны до 12 часов Аппаратная часть сервера неисправна из-за выхода из строя материнской платы, контроллера RAID-массива ИР и/или ПО АС недоступны, данные ИР и/или ПО АС неверны, сервисы недоступны Замена вышедших из строя дисков. Восстановление состояния сервера из образа дисковой подсистемы или восстановление информационного ресурса из последней резервной копии 1. Перенос сервисов и данных на другой сервер 2. Ремонт вышедших из строя компонентов, восстановление информационного ресурса из последней резервной копии до 12 часов Время проведения ремонта сервера + 12 часов Приложение № 3 к Регламенту ПЕРИОДИЧНОСТЬ РЕЗЕРВНОГО КОПИРОВАНИЯ ИР и ПО АС «ХХХХ» N Тип (роль) сервера Периодичность резервного копирования Ежедневно по рабочим дням + Еженедельно в выходные дни Ежедневно по рабочим дням + Еженедельно в выходные дни Еженедельно в выходные дни Еженедельно в выходные дни Еженедельно в выходные дни Еженедельно в выходные дни 1. Контроллеры домена, серверы DNS 2. Серверы сетевых сервисов (DHCP, печать, антивирусный, др.) Серверы - межсетевые экраны Почтовый сервер Серверы приложений Файловые ресурсы, подлежащие резервному копированию Файловые серверы, содержащие Еженедельно по рабочим дням конфиденциальную информацию, в том числе персональные данные 3. 4. 5. 6. 7. 64 ПРИЛОЖЕНИЕ В (ОБЯЗАТЕЛЬНОЕ) ПРОВЕРКА СООТВЕТСТВИЯ ТРЕБОВАНИЯМ К ДОКУМЕНТИРОВАНИЮ Проверка соответствия требованиям к документированию производится по описанным ниже методикам. 1. Методика проверки комплектности документов Проверка комплектности документов выполняется визуально путем сверки их состава, фактически представленного на испытания, с их составом, определенным Государственным контрактом и Техническим заданием. Оценка целостности комплекта документов производится в ходе выполнения других указанных в настоящей программе и методике проверок и включает контроль взаимной непротиворечивости документов (отсутствия противоречий в описании функций в разных документах, противоречий в описании диагностических сообщений, отсутствие противоречий в описании действий пользователей и пр.), а также единства оформления комплекта документов. 2. Методика проверки содержания и оформления технических документов Проверка содержания и оформления представленных на испытания технических документов выполняется визуально путем контроля соблюдения в документах требований нормативных документов (см. п.5): к структуре и содержанию документов; к построению, изложению и оформлению текстовых документов; к используемой терминологии. Также выполняется проверка соответствия содержания документов фактически представленным на испытания программным и техническим средствам и документации производителей на эти средства. Дополнительные требования к структуре и содержанию технических документов содержит раздел 8 Технического задания. 3. Методика проверки содержания и оформления эксплуатационных документов В ходе данной проверки оценивается качество комплекта эксплуатационных документов с точки зрения пригодности эксплуатационных документов для использования персоналом при эксплуатации и сопровождении, включая подготовку персонала. Дополнительные требования к структуре и содержанию технических документов содержит раздел 8 Технического задания. Проверка выполняется в соответствии с Методикой оценки качества эксплуатационной документации (п.4). 4. Методика оценки качества эксплуатационной документации Каждый документ оценивается путем экспертных оценок по следующим направлениям: 65 Соответствие требованиям (п.5) к построению, изложению и оформлению документов установленным для текстовых документов, в том числе: o наличие оглавления (содержания) и аннотации и его соответствие фактическому наполнению документа; o наличие и правильность нумерации страниц; o наличие необходимых рисунков, таблиц и формул и ссылок на них; o грамматическая правильность изложения; o правильность использования терминов, четкость и однозначность формулировок и описаний; o наличие необходимых ссылок на внешние документы; o наличие необходимых ссылок на элементы структуры внутри документа; o отсутствие неправильных ссылок, в т.ч. и на внешние документы; o отсутствие незаконченных разделов, абзацев, предложений; o отсутствие ненужных повторений; o отсутствие противоречий. Уровень технического исполнения документа, единство форматирования документа. Соответствие содержания документа фактически представленным на испытания программным и техническим средствам и документации производителей на эти средства, а также другим эксплуатационным документам. Соответствие структуры и содержания установленным требованиям (п.4). Полнота изложения (содержание разделов) с точки зрения пригодности документа для использования: o при подготовке персонала; o персоналом при эксплуатации; o персоналом в ходе сопровождения (технического и сервисного обслуживания). Первичность информации в документе, отсутствие нелокализованных по документу фрагментов текстов других документов, отсутствие признаков плагиата, включая внутренний, наличие необходимых ссылок на авторство. Соответствие наименований и обозначений документов установленным требованиям (п.4). Оценки по решению комиссии выставляются по итогам общего обсуждения на основе индивидуальных оценок членов комиссии. 5. Использование нормативных документов Перечни нормативных документов и их использование при проведении испытаний для соответствующих проверок содержит таблица (Таблица 9). Таблица 9 Перечни нормативных документов и их использование при проведении испытаний Нормативные документы Использование при контроле ГОСТ 34.003-90, ГОСТ 19.004-80-82, ГОСТ в части терминологии; 66 Нормативные документы Использование при контроле Р ИСО МЭК 12ХХХ, использованные в разработке нормативные правовые документы Московской области ГОСТ 34.201-89, ГОСТ 19.101-77-82 в части наименования и обозначения документов; ГОСТ 34.601-90, ГОСТ 19.102-77-82 в части определения стадий и этапов работ; ГОСТ 34.602-89, ГОСТ 19.201-78-82 в части состава, содержания и правил оформления документов «Техническое задание», «Частное техническое задание». ГОСТ 34.603 -92 в части испытаний; определения видов РД 50-34.698-90, ГОСТ 19.ХХХ, в части структуры и содержания специальные требования к структуре и документов; содержанию документов, установленные в Техническом задании ГОСТ 2.105-95, ГОСТ Р 6.30-97, ГОСТ 7.32- в части требований к построению, 91 и др. изложению и оформлению текстовых документов Критерии успешности проверок Проверка считается выполненной успешно, если соблюдены все следующие условия: Установлено соответствие комплектности представленных на испытания документов; Для технических документов: o установлено соответствие структуры и содержания установленным требованиям; o не установлено нарушений построения, изложения и оформления текстовых документов; o не установлено нарушений использования терминологии; o установлено соответствие содержания документов фактически представленным на испытания программным и техническим средствам и документации производителей на эти средства. Установлена пригодность эксплуатационных документов для эксплуатации и сопровождения, включая подготовку персонала; Сделан итоговый вывод о целостности комплекта документов. Оформление результатов проверок При проведении предварительных или приемочных испытаний Протокол испытаний в разделе «Проверка отчетной документации» должен содержать позиции: проверка комплектности представленных на испытания документов; проверка содержания и оформления представленных на испытания документов: 67 o технических документов; o эксплуатационных документов; o оценка целостности комплекта документов. По результатам проведения проверок соответствия документов требованиям к документации представитель Заказчика вносит запись в разделе «Проверка отчетной документации» Протокола испытаний о соответствии (не соответствии) требованиям. При установлении несоответствия требованиям в соответствующей графе Протокола испытаний вносится запись об отмеченных нарушениях (замечание, документ к которому оно относится). 68 СОСТАВИЛИ Наименование организации, предприятия Должность исполнителя Фамилия, отчество имя, Подпись Фамилия, отчество имя, Дата СОГЛАСОВАНО Наименование организации, предприятия Должность Подпись Дата