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

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

Отчет

Содержание 3порядок определения соответствия 3.2Определение соответствия по проектной и рабочей документации 3.3Определение соответствия путем испытаний 3.4Определение соответствия путем полного аудита системы

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

• Отчет нии экспериментальной медицины сзо рамн о выполнении плана нир за 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.

.3порядок определения соответствия

.3.1Определение соответствия путем декларирования

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

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

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

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

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

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

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

В заключительной части декларации приводится официальное заявление составителя декларации о соответствии системы требованиям Свода.

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

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

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

В конкурсную документацию рекомендуется включать положительные критерии оценки (сопоставления) заявок, учитывающие:

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

.3.2Определение соответствия по проектной и рабочей документации

Состав документации, представляемой на проверку, определяется ТЗ с учетом рекомендаций ГОСТ 34.201. На проверку должен быть представлен полный комплект документации, предусмотренный ТЗ и соответствующий стадии разработки (по ГОСТ 34.601 или согласно ТЗ). Если в наличии имеется рабочая документация – проверка соответствия проводится по ней, документация проектных стадий используется в качестве справочной в случае, если информации рабочей документации недостаточно для установления соответствия.

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

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

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

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

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

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

.3.3Определение соответствия путем испытаний

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

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

Перечень и регламент необходимых испытаний приводится в документе ПМ («Программа и методики испытаний»), оформляемом разработчиком (поставщиком) системы по РД 50 34.698 90 в соответствии с требованиями ГОСТ 34.603 или ТЗ, если оно устанавливает иной порядок испытаний и приёмки системы.

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

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

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

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

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

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

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

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

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

Результаты испытаний на соответствие заносятся в общий протокол испытаний согласно требований ГОСТ 34.603 или ТЗ, если оно устанавливает иной порядок испытаний и приёмки системы. Отдельным пунктом в протокол включается заключение приемочной комиссии (или иного уполномоченного органа/лица в соответствии с регламентом испытаний)

.3.4Определение соответствия путем полного аудита системы

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

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

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

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

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

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