Гост 34 Программа Опытной Эксплуатации
Журнал о системах электронного документооборота (СЭД) Приемочные испытания «по понятиям» и «по науке» 27 января 2014 г. 08:45 'А мы тут, знаете, всё плюшками балуемся.' Из мультфильма 'Карлсон вернулся' Приемка информационной системы, безусловно, апофеоз всего проекта создания информационной системы. Пусть Вас не обманывает цитата в начале статьи, мероприятие это важное и серьезное.
Думаю, что это праздник для обеих сторон, но, как известно, чтобы праздник прошел хорошо, к нему надо хорошо подготовиться. Начать стоит с формата проведения приемочных испытаний, хотя, скорее всего он уже давно был определен, например, в контракте или техническом задании.
Программа опытной эксплуатации СЗИ АСЗИ. В компании Исполнителя системы менеджмента качества, соответствующей требованиям ГОСТ Р ИСО. ГОСТ 34.603-92. Программа и методика испытан ий. Во время опытной эксплуатации АС ведут.
Тем не менее, я бы выделил два варианта проведения этого мероприятия и назвал их условно: приемка системы «по понятиям» и приемка системы «по науке». С первым все достаточно понятно, но описать такую процедуру невозможно. Это может быть полная формальность — веселые посиделки с бодрящими напитками или же настоящая вакханалия, где упоминание технического задания является чем-то неприличным и даже оскорбительным. А вот на втором варианте хотелось бы остановиться поподробнее, возможно данная статья приоткроет начинающим специалистам, а боюсь что и некоторым старым воякам, занавесу таинства приемочных испытаний. Постараюсь также дать несколько советов, чтобы испытания прошли более продуктивно.
Немного о стандартах. В далекие времена, будучи студентом, я, как и многие молодые люди своего поколения скептически относился с различным стандартам и руководствам СССР, при этом, даже не вникая в их суть. Но прошло совсем немного времени и здравый смысл взял вверх, не только сам применяю ГОСТы, но и рекомендую их к применению другим. Конечно, в ГОСТах 80-90-хх годах есть явные атавизмы, тем не менее, сравниваю их с уставом вооруженных сил, они что называется «на крови писались» и поверьте, там много здравых мыслей.
Специалистов знающих ГОСТы, равно как и документы, оформленные в соответствии с ГОСТ и РД, видно издалека и отличаются они явно в лучшую сторону. Приемочные испытания проводятся в соответствии с ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем». Данный вид испытаний завершающий после предварительных испытаний и опытной эксплуатации. Цель данных испытаний — проверить соответствие автоматизированной системы требованиям Технического задания и сделать заключение о готовности Системы к вводу в постоянную эксплуатации.
Испытания проводятся по документу Программа и методикой приемочных испытаний (ПМИ). ПМИ разрабатывается с применением РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов». Благодаря в первую очередь этому документу приемочные испытания «по понятиям» превращаются в приемочные испытания «по науке». ПМИ описывает все требования (функциональные и нефункциональные) Технического задания и ожидаемые результаты проверки. ПМИ — это последний шанс для Заказчика повлиять на характеристики принимаемой информационной системы. Особенно если в ходе проекта разрабатывалось Техническое задание, которое в классическом понимании говорит «что делать» (цели и задачи, общие требования, требования к программному, техническому и документационному обеспечению, требования к персоналу и др.) и не разрабатывался Технический проект, который говорит «как делать» (конкретные технические решения по реализации конкретных требований Технического задания).
Уделите достаточное время на разработку и согласование Программы и методики приемочных испытаний. Если хотите, это будет ваш устав на приемочных испытаниях. Заказчику помимо согласования ПМИ не забыть издать приказ о составе приемочной комиссии, и каждого его члена под подпись ознакомить с ПМИ. Кого включать в комиссию — личное дело Заказчика. Рекомендую, чтобы в ней обязательно были:.
Функциональные заказчики. Представители подразделений — ключевые пользователи Системы. Представители технических подразделений, которые в дальнейшем будут обслуживать Систему А также не были (относится к обеим сторонам):. Слабонервные и неуравновешенные сотрудники. Сотрудники не умеющие слушать и плохо выражающие свои мысли. Внештатные сотрудники, представляющие компании конкурентов Совет №2.
Хотите, чтобы на приемочных испытаниях автоматизированной системы все было «по-взрослому»? Помимо проверки функциональных требований выполните:. Развертывание программного обеспечения Системы «с нуля».
Проверку заявленных временных показателей полного и частичного восстановления Системы. Проверку быстродействия Системы путем замера времени выполнения ключевых функций, пусть и в монопольном режиме. Конечно, данные показатели должны быть изначально описаны в Техническом задании, или стороны будут обречены на спор, что есть «комфортное время» выполнения той или иной операции. Мое субъективное мнение уже много лет остается прежним — до 3 сек. На выполнение основных простых операций, далее нужно исходить из конкретной ситуации. Проверку устойчивости и надежности Системы. Даже такого элементарного теста будет вполне достаточно – открываем интерфейсную форму внесения данных, выдергиваем сетевой шнур или разрываем соединение Wi-Fi, пытаемся сохранить данные, получаем адекватное сообщение, восстанавливаем соединение и повторяем попытку сохранения.
Если это веб-приложение рекомендую проверять корректность повторной загрузки страниц, то есть после открытия той или иной формы/страницы, после выполнения команды сохранения данных и т.п., принудительно вызвать команду обновления (в браузерах это обычно клавиша F5). Проверку комплектности и качества документации. Лучше эту часть выполнить до начала испытаний, т.к. Она требует достаточно много времени. Непосредственно на самих испытаниях озвучить результаты данной проверки А вообще начните с проверки соответствия общесистемного программного (операционные системы, офисные пакеты, системы управления базами данных и др.) и технического обеспечения Системы (сервера, клиентские станции, каналы связи и др.) заявленным требованиям в Техническом задании. Несоответствия в этих пунктах может стать обоснованной причиной недостижения характеристик Системы заявленным показателям и даже полного невыполнения отдельных функций Системы.
Приемочные испытания проводите на контрольном наборе данных. В Систему должны быть в загружены данные как минимум сопоставимые с плановым объемом данных за первый год работы.
Пусть это будет автоматически сгенерированная информация, качество контента тут не на первом месте. Если в процессе опытной эксплуатации необходимый объем данных уже был сформирован — отлично. Часто в Технических заданиях пишется фраза «Система должна обеспечивать одновременную работу N пользователей». Исполнитель в первую очередь обеспечивает наличие необходимого количества конкурентных лицензий (если такая политика лицензирования предусмотрена). Не стесняйтесь спросить каким образом организационно или технически было обеспечено выполнение данного требования. Если были проведены нагрузочные испытания (в автоматизированном и/или ручном режиме), попросите предоставить протокол и программу проведения.
Гост 34.201
Если данные тесты будут запущены прямо на испытаниях, честь и хвала Исполнителю. По результатам проведения приемочных испытаний оформляется протокол (отчет) о результатах испытаний, в его составе может быть приложение с описанием выявленных замечаний и сроках их устранения (не забывайте об этом), а также акт технического состояния Системы и готовности ее приемки в промышленную эксплуатацию. Содержание данных документов также описано в РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию документов». После успешных испытаний по старой русской традиции новорожденную Систему нужно «обмыть», правда этого я так и не нашел ни в одном ГОСТе. Оригинал статьи опубликован по адресу.
Аргументы (если внедряем водопадом):. При формулировании ТЗ (до старта проекта) почти всегда нет даже адекватных функциональных требований бизнеса. Далее собираем ФТ. Меняется очень многое. Далее делаем проектные решения (не важно как называется - главное описываем как реализуем ФТ в конкретной ИС). Тоже что-то меняется относительно ФТ, ибо жизнь и разработчики вносят свои коррективы. Далее идем на тестовую и опытную эксплуатации.
Бизнес вносит правки. На выходе снова что-то относительно новое. В итоге относительно чего делать контроль? Современная динамика бизнеса требует быстрого и гибкого управлениям изменениями, а не фиксирования на первоначальной техническом задании. Если внедряем по Agile, Scrum например применяем, то никакого ТЗ нет в принципе. Product backlog и User Stories - это наше все.
Ну и методики крупных вендоров/интеграторов, подтверждают аргументов. Например, ни в MS Dynamics Sure Step, ни в методиках вендоров СЭД (как минимум две знаю хорошо) такого нет. Да Вы их не нюхайте, завязывайте с этой гадостью:) Вот Вы когда в процессе тестовой эксплуатации или опытной,что-то меняете вы где-то это фиксируете или все устно?:) А вот после того как реализовываете очередное требование (после зафиксированного ТЗ, или списка требований), каким образом 'демонстрируете' его реализацию? А как Заказчик принимает решение о начале промышленной эксплуатации (тут понятно о чем речь, термин каждый свой любит)?
Вообщем если ответов нет, то это путь в первый вариант 'приемка по понятиям' (устно 'по-пацански' договорится, по-быстрому 'доточить', в обеденный перерыв 'на бегу показать', а потом долго искать инициатора доработки и доказывать 'мы ровно так и договаривались делать'), где-то это наверное уместно, но по мне так не пример для подражания и предмет для гордости. Не вижу ни сложности ни рисков принятые решения запротоколировать, должностным лицам официально 'достижения' продемонстрировать под подпись. Назовите эти мероприятия как вам нравится в соответствии с принятой методологией управления проектом, устава проекта, слово ГОСТ вообще не произносите, не пугайте никого:) Вы уже проводите аналогии с протоколированием истории разработки продукта, некой базой знаний и т.п. Итого: тот же смысл, 'десиженсы' запротоколировать, 'ивенты' провести, только более современными и модными словами, ок:).хотя нет, риски есть, при исполнении гос.контрактов и реализации сверх ТЗ могут Заказчика обвинить в 'давлении', поэтому он и не любит протоколы связанные с изменением требований, хотя закон и позволяет изменить объем на 10%, правда и стоимость тоже:) Ну и тут можно найти 'цивилизованный' выход. Вот Вы когда в процессе тестовой эксплуатации или опытной,что-то меняете вы где-то это фиксируете Для водопада.
Если в процессе сбора функциональных требований, проектирования, разработки, тестовой или опытной эксплуатации заказчик формулирует требования, которые следует трактовать как изменение 'содержания проекта', то оформляется запрос на изменение, разумеется. Если это 'рабочий момент', что-то уточнили или переформулировали - то все в протоколы. Дальше все зависит от фазы и управления проектом. Но в целом все единообразно - все вносится в текущие документы (их много, но ключевых у нас несколько - Функциональные требования, Проектные решения, Технический проект, Паспорт системы и т.д.). Тут все просто - на спринте никаких изменений. Каким образом 'демонстрируете' его реализацию? Для водопада.
Главный минус 'классического' подхода во внедрении, как известно, сложный переход на шаг назад в этапах проекта. Но всегда есть 'запасные пути'. На тестовой эксплуатации предусматривается возможность нескольких итераций - на первой итерации проводим функциональное и нагрузочное тестирование. Выявляем ошибки/пожелания - все в журнал. Все поправили - вторая итерация, ровно так же и по той же программе. На опытно-промышленной также есть 'запас' на 'исправления'.
Первый месяц (условно) работаем - собираем проблемы/пожелания - все в журнал. Исправляем - и заказчик принимает исправления. Были изменения к ТЗ отразите это и в ПМИ Итого, если резюмировать, то при завершении опытно-(промышленной) эксплуатации надо все проверить, что 'все хорошо'. И делать это осознано по заранее разработанному плану. Теперь к плану (ПМИ). Ядро его не есть первоначальное ТЗ, хотя ГОСТ вроде как на это указывает.
А что такое план? 'контрольный пример для проверки работоспособности АС'? Так а для чего тогда опытная эксплуатация у нас идет, скажем три месяца? Система уже работает в масштабе предприятия, уже собрали и устранили даже мелкие замечания пользователей.
Зачем еще один контрольный пример, когда есть готовая и работающая система, к которой ни у рабочей группы, ни у пользователей нет замечаний? В итоге ваше предложение не соответствует ни ГОСТу (я кстати ничего против него не имею, хороший артефакт), ну здравому экономическому смыслу.
Ибо прогнать еще одно тестирование готовой системы можно, если не встанут два вопроса - зачем и кто за это заплатит. На том что ГОСТ это нечто старое, совковое. Да нет, не так.
Просто время другое и работа у нас другая. Раньше был заказчик в лице государства, был исполнитель (например НИИ какой-то), был бенефициар - завод какой-то. Заказчик конечно хотел, чтобы то что сделал исполнитель соответствовало первоначальным требованиям бенефициара. Иначе коррупция, не целевое расходование средств и все такое.
Вот новая контрактная система, которая идет на смену 94 ФЗ тоже хочет на выходе контролировать итог работ. Там, вероятно, потребуются 'приемочные испытания' именно для заказчика. Для того и стандарты обновят со временем (в законодательстве таможенного союза такое уже есть для оборудования и машин). И заплатит за это сам заказчик, т.е. В теории такие же требования могут выставлять крупный бизнес. У того же Газпрома подобные процедуры описаны как обязательные, если внедрение контролирует 'голова'. Так что я не категорически против, я.
Но как вынужденная мера когда без нее никуда. Ну давайте на пальцах: 1. Предварительные испытания. После них Система передается в опытную эксплуатацию (ОЭ). Проводятся для того чтобы на ОЭ при первом же клике у пользователей все 'не рухнуло', или они после 1-2 шагов не обнаружили 'тупики' (например отсутствие функции) и как следствие невозможность продолжать испытания. После испытаний - протокол, устранение замечаний и возможно, повторные испытания. Опытная эксплуатация (еще ее называют тестовой), и опытно-промышленная эксплуатация. В любом случае для выявления и дальнейшего устранения замечаний, ошибок и т.п.
Замечания, как правило, устраняются без остановки испытаний. Приемочные испытания. После них Система сдается в постоянную эксплуатацию (без всяких приставок 'опытно'), для этого нужно основание, протокол устранения замечаний ОЭ (ОПЭ) это конечно хорошо. Но в рамках ОЭ никто не проверяет абсолютно все характеристики Системы, например:. механизмы передачи дел в случае увольнения сотрудников или перевода их в другое подразделение.
назначение нового руководителя организации. выдачу рег. Номеров в следующем году.
рубрицирование документов из разных лет (если не делалась миграция такого объема данных просто нет). копирование номенклатуры дел старого года и работа с новой номенклатурой. и т.п. Это делает разработчик, конечно. Вот и получается, что Систему принимают 'на веру'. Можно применять любые термины, идти в каком-то другом порядке, но цель то одна - чтобы пользователи 'не мучились' с сырым продуктом ни до, ни после официального начала работы в Системе.
Одним словом, я уверяю всю общественность, если завтра вы напишите полную программу и методику приемочных испытаний, сядете с Заказчиком и 2 дня уделите приемке Вашей 'уже принятой' Системы - вы нароете очень много интересного. Можно сказать что и проведя испытания еще раз, вы опять что-то нароете?:) Да, но уже в разы меньше!
И рано или поздно все это 'интересное' всплывет, но к горечи Заказчика уже не в рамках контракта создания Системы (а как уж тут себя Исполнитель поведет зависит только от него):) Самое главное, мои статьи во многом Заказчикам, а не Исполнителям. То есть я не 'учу жить' никого, но если хоть одна компания обойдет хоть одни 'грабли', которые описываются практически в каждом моем посыле - значит пару килобайт места этими статьями я занял не зря:). Меня лично больше задевает появление/изменение требований после окончания разработки - заказчик зачастую не понимает, что именно хочет. Известно, пользователь не знает, чего он хочет, пока не увидит то, что он получил. Но это уже больше касается технологии управления требованиями. А в рамках текущего контекста - первоначальные требования и все последующие изменения оных обязательно надо вести, с составлением сопутствующих сценариев использования.
И приемочное проводить по этим требованиям, остальные пожелалки оценивать отдельно как по адекватности, так и по трудозатратам. Меня лично больше задевает появление/изменение требований после окончания разработки - заказчик зачастую не понимает, что именно хочет. А почему вас это задевает? Во-первых, изменение бизнес-процессов, это норма в современном мире. Они должны меняться. Во-вторых, заказчик обращается к компании-внедренцу именно потому, что сам не знает, что именно ему нужно! Если бы он это знал, ему не нужна была бы ни коробочная система, ни компания-внедренец.
Он вполне мог бы разработать и внедрить все сам. И если компания-внедренец не способна сказать заказчику что же именно ему нужно, то виноват не заказчик, а исполнитель.
ЗАКРЫТОЕ АКЦИОНЕРНОЕ ОБЩЕСТВО ЛАБОРАТОРИЯ НОВЫХ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ «ЛАНИТ» УТВЕРЖДАЮ Генеральный директор // «» 2013 г. Типовая поддержки деятельности многофункциональных центров предоставления государственных и муниципальных услуг ПРОГРАММА ОПЫТНОЙ ЭКСПЛУАТАЦИИ Этап 1 Тема: «Программа опытной эксплуатации АИС МФЦ СПО с АМ ОКГУ в пилотных субъектах Российской Федерации» Москва 2013 Оглавление 1. Условия и порядок функционирования частей Системы и Системы в целом 4 2.1.
Скачать хентай порно аниме бесплатно. Автор: sergej10| 20 марта 2018| категория: Порно торренты » Порно Хентай| Просмотров: 1287. Крупнейший открытый пороно торрент трекер, начните скачать порно фильмы через торрент, без регистрации и рейтинга. Порно аниме хентай. Многосерийные аниме мультфильмы разных жанров непременно удивят Вас. Которые свойственны экстравагантной японской культуре С тегом хентай. 11 Сен 17, Magnet-ссылка download torrent В палате / Rensa Byoutou / Rensa. Magnet-ссылка download torrent Эротический аниме квест / Idols Galore! Хентай скачать торрент Международный торрент-трекер Rustorka| Русторь до последнего! Модераторы: Модераторы аниме, Супермодераторы. Как скачать фильм через торрент.
Полное наименование системы, обозначение. Комплектность опытной системы. Цели проведения опытной эксплуатации. Перечень подсистем, их назначение и основные характеристики. Способы и средства связи для между компонентами системы 8 2.6. Характеристики взаимосвязей Системы со смежными системами.
Перечень руководящих документов, на основании которых проведения опытной эксплуатации. Организации, участвующие в опытной эксплуатации. Условия проведения опытной эксплуатации. Продолжительность опытной эксплуатации. Порядок устранения недостатков, выявленных в процессе опытной эксплуатации 12 Приложение 1.Шаблон журнала опытной эксплуатации. (Автономное учреждение «Многофункциональный центр предоставления государственных и муниципальных услуг Алтайского края»).
Опытная эксплуатация является одним из видов испытаний и проводится после проведения предварительных испытаний Системы с АМ ОКГУ. По результатам опытной эксплуатации выявляются дополнительные замечания к работоспособности и функционированию АМ ОКГУ, которые затем устраняются к моменту проведения приемочных испытаний. Условия и порядок функционирования частей Системы и Системы в целом 3.1. Полное наименование системы, обозначение Полное наименование объекта опытной эксплуатации: Автоматизированная информационная система поддержки деятельности многофункциональных центров предоставления государственных и муниципальных услуг на базе свободно распространяемого программного обеспечения с автоматизированным модулем оценки качества услуг. Условное обозначение: Система с АМ ОКГУ, АИС МФЦ СПО с АМ ОКГУ.
Комплектность опытной системы В состав проверяемой системы входят: - Дистрибутив АИС МФЦ СПО с АМ ОКГУ (программа ЭВМ), представленный на электронных носителях информации (на CD или DVD диске). Техническая и эксплуатационная документация на АИС МФЦ СПО с АМ ОКГУ, представленная на бумажном и электронном носителях информации (на CD или DVD диске): o на АМ ОКГУ в соответствии с РД 50-34.698-90; o программа и методика автономных испытаний АМ ОКГУ согласно требованиям ГОСТ 34.603-92; o руководство пользователя АМ ОКГУ в соответствии с РД 50-34.698-90; o руководство администратора АМ ОКГУ в соответствии с РД 50-34.698-90. Программа опытной эксплуатации АМ ОКГУ в пилотных субъектах Российской Федерации. Протокол и акт предварительных автономных испытаний АИС МФЦ СПО с модулем АМ ОКГУ в части работы модуля АМ ОКГУ. Цели проведения опытной эксплуатации Опытная эксплуатация Системы с АМ ОКГУ проводится с целью определения: - фактических значений количественных и качественных характеристик Системы с АМ ОКГУ.
Фактической эффективности Системы с АМ ОКГУ; - возможности работы пользователей. Экспертная подсистема поддержки принятия решения обеспечивает поддержку деятельности пользователей в системе в зависимости от роли и текущего задания.
Основные этапы и функции поддержки принятия решения – этап приема документов и этап формирования запросов в ОГВ. На этапе приема документов Система на основании преднастроенных экспертных данных о необходимых документах и способах получения промежуточных данных, а также данных о категориях заявителя формирует динамически изменяющийся шаблон комплекта документов, позволяющий учесть все специфические особенности конкретной ситуации. На этапе формирования запросов в ОГВ экспертная подсистема обеспечивает предварительную их подготовку на основании имеющихся документов, атрибутов текущего процесса и шага. Экспертная подсистема оставляет за пользователем контролирующую функцию с возможностью вмешаться этапе в процесс получения результата услуги. Подсистема информационного обмена данными построена на базе JBoss ESB, обеспечивает регистрацию внешних и внутренних веб-сервисов, маршрутизацию и журналирование запросов, обеспечивает контроль доставки сообщений. В Системе данная подсистема так же обеспечивает интеграцию с базовыми информационными ресурсами, системой идентификации и аутентификации и обеспечивает взаимодействие с региональным порталом государственных услуг в части подачи заявления и отслеживания состояния о ходе исполнения услуги.
Аналитическая подсистема работает в тесной интеграции с подсистемой хранения архивных данных. В состав аналитической подсистемы входят преднастроенные аналитические отчеты, сводные формы с возможностями фильтрации данных, конфигурирования полей и форматов отображения данных форм.
Данные для аналитической подсистемы формируются в процессе исполнения. Структура хранимых данных универсальная и позволяет использовать данные о жизненном цикле процессов оказания услуг в любых формах аналитической и статистической отчетности. Подсистема миграции конфигурации системы обеспечивает возможность переноса настроек между экземплярами МФЦ, установленных как в пределах одной технологической площадки, так и на разных физических серверах. Обеспечивается функция связывания тестового и рабочего экземпляров организационных единиц МФЦ с возможностью выборочного переноса настроек справочников, настроек системы в части исполнения услуг, интеграции с порталом государственных услуг и информационными системами. Внутренний формат обмена данными при этом соответствует спецификации языка XML.
Гост Сайт
Подсистема жестко интегрирована с настроечной частью экспертной подсистемой поддержки принятия решения. Обеспечена возможность экспорта отдельных сущностей и элементов справочников, а также автоматическое определение зависимостей и формирование пакетов экспортируемых данных. В Системе соответственно предусмотрена возможность пакетного импорта с предварительным просмотром и корректировки импортируемых данных. Подсистема конфигурирования и управления организационной структурой МФЦ включает в себя ряд функций и методов для построения сети МФЦ, настройки межфилиального взаимодействия и управления правам доступа к организационным единицам.
Рассматриваемая подсистема тесно интегрирована с ИУПП и экспертной подсистемой принятия решений. Обеспечивается управление всем данными Системы в контексте экземпляров организационных единиц на уровне хранения данных, получения контекста и на уровне разделения прав пользователей. Отчетная подсистема построенная на основе BIRT 3.7.0 имеет основной функцией формирование печатных и отчетных форм. Под печатными формами понимаются отчеты, формируемые пользователями по ходу исполнения бизнес-процессов, данные для которых формируются на основе оперативных данных ИУПП.
Под отчетными формами понимаются статистические и реестровые формы, формируемые вне времени исполнения частных бизнес-процессов оказания услуг, данные для которых хранятся и обрабатываются подсистемой хранения архивных данных. В составе Систем есть ряд типовых статистических форм. Гибкость механизма интеграции рассматриваемой подсистемы позволяет разрабатывать и использовать произвольные статистические формы без модификации системы.
Регистрация новых печатных форм осуществляется на уровне настроек организационных единиц МФЦ. Подсистема балансировки нагрузки – подсистема системного уровня. Обеспечивающее минимизацию времени отклика как всей Системы в целом, так и отдельных его подсистем и серверов.
В штатном режиме Система имеет в своем составе три экземпляра подсистемы балансировки нагрузки: сервера приложений, сервера и сервера файлового хранилища. Подсистема балансировки нагрузки используется для варианта развертывания при условии дублирования.
Программный модуль АМ ОКГУ, предназначенный для сбора и передачи оценок качества услуг, должен иметь возможность работы в режиме без настройки процессов предоставления оцениваемых услуг в АИС МФЦ СПО с обеспечением функции сбора и передачи данных о качестве предоставления услуг в ИАС МКГУ. Способы и средства связи для информационного обмена между компонентами системы Для обеспечения информационного обмена, компоненты системы работают в составе единой вычислительной сети, построенной по технологии интранет. В качестве базового протокола сетевого и межсетевого взаимодействия используется TCP/IP (сокращение от английского Transfer Control Protocol / Internet Protocol, протокол управления передачей/протокол-Интернет) – стек протоколов Интернет. Разрабатываемый модуль не требуют большого числа информационных потоков для связи с остальными модулями Системы, имеет общую систему навигации. Характеристики взаимосвязей Системы со смежными системами В ходе работ по государственному контракту должна быть реализована функциональная возможность интеграции Системы (с АМ ОКГУ) с ИАС МКГУ. В рамках интеграции должны быть реализованы следующие информационные потоки: - запрос актуальной анкеты; - ответ на запрос анкеты – актуальная анкета; - пакет собранных оценок с соответствующим перечнем атрибутов. Перечень руководящих документов, на основании которых проведения опытной эксплуатации Опытная эксплуатация Системы с АМ ОКГУ проводится на основании следующих документов: - Государственный контракт, заключенный между Заказчиком и Исполнителем, определяющих основные условия по развитию Системы. Проектная и эксплуатационная документация на Систему с АМ ОКГУ, предусмотренная Техническим заданием, и определяющие технические и функциональные характеристики Системы с АМ ОКГУ, а также требования к условиям функционирования (эксплуатации) Системы с АМ ОКГУ.
Организации, участвующие в опытной эксплуатации Проведение опытной эксплуатации осуществляется персоналом Заказчика (Министерства экономического развития Российской Федерации) и Исполнителя. Условия проведения опытной эксплуатации Исполнителем должна быть проведена опытная эксплуатация АМ ОКГУ в одном МФЦ в каждом пилотном субъекте Российской Федерации. Опытная эксплуатация проводится МФЦ пилотного субъекта Российской Федерации согласно проектной и эксплуатационной документации, а также внутренних организационно-распорядительных документов. Опытная эксплуатация в пилотных субъектах Российской Федерации должна включать в себя следующие работы: - развертывание АМ ОКГУ на оборудовании, предоставленном уполномоченным представителем субъекта Российской Федерации. В случае, необходимости Исполнителем осуществляется развертывание или обновление актуальной версии АИС МФЦ СПО в пилотном субъекте Российской Федерации; - настройка (конфигурирование) АИС МФЦ СПО с АМ ОКГУ; - настройка в АМ ОКГУ 3-х услуг, согласованных с Заказчиком на этапе выполнения работ по государственному контракту; - опытная эксплуатация АМ ОКГУ в соответствии с разработанной программой опытной эксплуатации. Участие Исполнителя в опытной эксплуатации регламентируется условиями Государственного контракта.
На период опытной эксплуатации Заказчик и Исполнитель назначают лиц, ответственных за взаимодействие по вопросам проведения и технической поддержки опытной эксплуатации, и согласовывают контакты и способы взаимодействия этих лиц. Отчетность Во время проведения опытной эксплуатации в каждом пилотном субъекте Российской Федерации должен вестись журнал опытной эксплуатации, в который заносят сведения о продолжительности функционирования АМ ОКГУ, отказах, сбоях, аварийных ситуациях, изменениях параметров объекта автоматизации, проводимых корректировках документации и программных средств, наладке, технических средств. В журнале фиксируются: - дата и московское время обращения; - контактные данные обратившегося лица (ФИО, телефон и/или e-mail); - содержание обращения; - дата и московское время полной отработки обращения; - содержание принятых по обращению мер.
Все вносимые сведения должны быть зафиксированы в журнале с указанием даты и ответственного лица. В журнал помещаются сведения об ответе Исполнителя и/или об устранении недостатков и внесении изменений. Продолжительность опытной эксплуатации Опытная эксплуатация должна длиться не менее 10 рабочих дней.
Порядок устранения недостатков, выявленных в процессе опытной эксплуатации Рабочие журналы опытной эксплуатации согласуются с Заказчиком, в результате чего формируется список доработок (в части несоответствия требованиям данного документа и частного ) которые должны быть проведены Исполнителем в рамках работ по государственному контракту. По результатам доработки Исполнитель должен сформировать Отчет о доработке АМ ОКГУ. Приложение 1.Шаблон журнала опытной эксплуатации № Текст замечания Источник замечания Принятые действия Дата уведомления Исполнителя Ответ Исполнителя 1 2. Домашний очаг.:. История:.
Окружающий мир:. Справочная информация.:.:.:.:.:. Техника.:.
Гост 34 Журнал Опытной Эксплуатации
Образование и наука:. Предметы:. Мир:.:. Бизнес и финансы:.:.:.