Отчет о нир листов

Вид материала

Отчет

Содержание Приложение 23. Руководящий документ «Требования по совместимости с унаследованными системами и поддержке выбывающих спецификаций 1аудит унаследованных систем 1.1.2Повторный аудит 1.2Порядок проведения аудита

Подобный материал:

• Отчет нии экспериментальной медицины сзо рамн о выполнении плана нир за 2009г и план, 29.72kb.
• Отчет о научно-исследовательской работе за 2007 год Тема нир: Разработка и создание, 107.74kb.
• Отчет о научно-исследовательской работе за 2007 год Тема нир: Разработка новых радиоволновых, 53.72kb.
• Отчет о научно-исследовательской работе за 2008 год Тема нир: Разработка новых радиоволновых, 49.86kb.
• Отчет о научно-исследовательской работе за 2008 год Тема нир: Исследование новых механизмов, 65.37kb.
• Лексикология для высших учебных заведений1[1], 2831.98kb.
• Отчет о научной деятельности Сибирского государственного индустриального университета, 292.94kb.
• Р. И. об итогах нир университета за 2009 год на Ученом совете от 8 февраля 2010 год, 887.59kb.
• Отчет о нир/окр (бумажная версия) (наименование отчета), 45.75kb.
• Отчет по нир, 650.93kb.

Приложение 23. Руководящий документ «Требования по совместимости с унаследованными системами и поддержке выбывающих спецификаций»

введение. Общие положения

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

Документ содержит указания и методические рекомендации по:

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

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

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

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

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

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

Термины, не определенные в вышеуказанном документе – по ГОСТ 34.003

.1аудит унаследованных систем

.1.1Виды аудита

.1.1.1Первичный аудит

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

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

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

.1.1.2Повторный аудит

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

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

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

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

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

.1.2Порядок проведения аудита

Аудит должен включать следующие этапы.

• Предварительное обследование
  
• Формирование плана аудита
  
• Непосредственное осуществление аудита
  
• Составление отчета о результатах аудита
  

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

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

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

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

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

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

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

По итогам аудита составляется отчет, содержащий следующие разделы:

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