Geum.ru

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

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

Содержание


4Направление 4. Руководящий документ (РД) по процедурам подтверждения соответствия программных систем требованиям СПО.
Подобный материал:
1   ...   6   7   8   9   10   11   12   13   ...   47

.4Направление 4. Руководящий документ (РД) по процедурам подтверждения соответствия программных систем требованиям СПО.


Текст руководящего документа приведен в Приложении 22. Предусматриваются следующие способы определения соответствия систем Своду:
  1. Путем декларирования соответствия поставщиком (разработчиком). Применяется:
  • При конкурсном отборе поставщиков и разработчиков программного обеспечения государственных информационных систем.
  • При поставках готового программного обеспечения, не требующего специальной доработки для использования в государственных информационных системах (в т.ч. комплексной настройки, в ходе которой изменяются протоколы и/или форматы данных, используемые для информационного взаимодействия со смежными системами).
  1. По проектной и рабочей документации. Применяется:
  • При принятии решения о допуске систем к предварительным испытаниям, опытной эксплуатации и приемочным испытаниям систем.
  • При вводе государственных информационных систем в промышленную эксплуатацию, если планом внедрения не предусмотрено проведение приемочных испытаний (например, при вводе в эксплуатацию типовых проектов, прошедших испытание на головном образце).
  • При конкурсном отборе поставщиков и разработчиков программного обеспечения государственных информационных систем в случае необходимости проверки и уточнения информации, представленной в декларации соответствия, в т.ч. при сопоставлении (оценке) заявок различных поставщиков, если это прямо предусмотрено конкурсной документацией.
  • При плановых проверках соблюдения требований Свода и положений Концепции СПО уполномоченными контролирующими органами.
  • При первичном и повторном аудите унаследованных систем.
  • В других случаях, когда определение путем декларирования невозможно или не производилось.
  1. Путем натурных испытаний. Применяется:
  • В отношении интерфейсов со смежными системами, в т.ч. внешних пользовательских интерфейсов на базе веб-браузеров - при предварительных и приемочных испытаниях систем.
  • В отношении прочих интерфейсов: при предварительных и приемочных испытаниях вновь разработанных систем и компонентов, если это предусмотрено техническим заданием или в тех случаях, если.
  • При первичном аудите унаследованных систем в случаях, если имеющейся документации недостаточно для определения соответствия.
  1. Путем полного аудита системы. Применяется:
  • При выявлении отклонений от требований стандартизованных спецификаций или обнаружения не декларированных и/или не описанных в проектной и рабочей документации интерфейсов, подпадающих под требования технологического раздела Свода.
  • При выборочной проверке соблюдения требований Свода и положений Концепции СПО уполномоченными контролирующими органами.
  • При первичном аудите унаследованных систем в случае отсутствия проектной и рабочей документации на них.
  • В качестве дополнительной экспертизы при комплексном анализе государственных информационных систем, проводимом по основаниям, не связанным с определением соответствия Своду (например, при сертификации систем).

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

Руководящий документ по определению соответствия основан в значительной мере опирается на методики и положения существующих ГОСТов в области автоматизированных систем.

Принят за основу следующий жизненный цикл информационной системы, установленный в ГОСТ 34.601:

Таблица 7. Стадийность разработки систем по ГОСТ.

Стадии
Этапы работ

1. Формирование требований к АС
1.1. Обследование объекта и обоснование необходимости создания АС.

1.2. Формирование требований пользователя к АС.

1.3. Оформление отчёта о выполненной работе и заявки на разработку АС (тактико-технического задания)

2. Разработка концепции АС.
2.1. Изучение объекта.

2.2. Проведение необходимых научно-исследовательских работ.

2.3. Разработка вариантов концепции АС, удовлетворяющего требованиям пользователя.

2.4. Оформление отчёта о выполненной работе.

3. Техническое задание.
Разработка и утверждение технического задания на создание АС.

4. Эскизный проект.
4.1. Разработка предварительных проектных решений по системе и её частям.

4.2. Разработка документации на АС и её части.

5. Технический проект.
5.1. Разработка проектных решений по системе и её частям.

5.2. Разработка документации на АС и её части.

5.3. Разработка и оформление документации на поставку изделий для комплектования АС и (или) технических требований (технических заданий) на их разработку.

5.4. Разработка заданий на проектирование в смежных частях проекта объекта автоматизации.

6. Рабочая документация.
6.1. Разработка рабочей документации на систему и её части.

6.2. Разработка или адаптация программ.

7. Ввод в действие.
7.1. Подготовка объекта автоматизации к вводу АС в действие.

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

7.3. Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями).

7.4. Строительно-монтажные работы.

7.5. Пусконаладочные работы.

7.6. Проведение предварительных испытаний.

7.7. Проведение опытной эксплуатации.

7.8. Проведение приёмочных испытаний.

8. Сопровождение АС
8.1. Выполнение работ в соответствии с гарантийными обязательствами.

8.2. Послегарантийное обслуживание.



Как правило, при объявлении конкурса на поставку систем уровень проработки их проектов соответствует 1-2 стадиям.

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

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

Практическая проверка соответствия систем требованиям проводится методом испытаний. Испытания, согласно определениям ГОСТ 34.603, представляют собой процесс проверки выполнения заданных функций системы, определения и проверки соответствия требованиям ТЗ количественных и (или) качественных характеристик системы, выявления и устранения недостатков в действиях системы, в разработанной документации.

Для ИС устанавливают следующие основные виды испытаний:
  • 1) предварительные;
  • 2) опытная эксплуатация;
  • 3) приемочные.

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

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