Сертификация информационно и программных средств

Сертификация информационно и программных средств

Сертификация информационно-программных средств учебного назначения

Осуществляется на основе следующего документа:

Порядок проведения сертификации информационно-программных средствв сфере образования, который описывает порядок проведения работ по сертификации, отвечающий специфике информационно-программных средств (ИПС) в сфере образования и общим требованиям системы сертификации средств и систем в сфере информатизации "РОСИНФОСЕРТ", а также определяет взаимодействие и организационно-правовые отношения между участниками процесса сертификации (головным научно-методическим центром и головными организациями, органом по сертификации, испытательной лабораторией, заказчиками и разработчиками информационно-программных средств в cфере образования).

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

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

Процедура сертификации ИПС в сфере образования включает следующие основные этапы

1) Оформление заявки на проведение работ по сертификации

2) Рассмотрение заявки в отраслевом органе по сертификации и головном научно-методическом центре по сертификации ИПС в сфере образования.

3)Экспертиза тестового образца ИПС в отраслевом органе

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

5) Оформление протокола испытаний тестового образца ИПС и передача его в отраслевой орган по сертификации (срок - в течение недели).

6) Экспертиза результатов испытаний тестового образца ИПС).

7.)Оформление сертификата и лицензии на применение знака соответствия с регистрацией сертификата в реестрах отраслевого органа по сертификации и головного научно-методического центра по сертификации ИПС в сфере образования.

8) Инспекционный контроль качества сертифицированной продукции (один раз в год).

Порядок оплаты работ по сертификации

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

Игровые ПС

Обеспечение различных видов игровой и учебно-игровой деятельности

3.6. ГОСТ Р ИСО/МЭК ТО 12182-2002. Классификация программных средств.

 

Структура видов

Схема классификации состоит из 16 видов. Данные виды ПС могут быть объединены в следующие группы.

Внутренние виды:

- режим эксплуатации (7.3);

- масштаб ПС (7.4);

- стабильность ПС (7.9);

- функциональные возможности;

- функция ПС (7.1);

- требование защиты (7.13);

- требование надежности (7.14);

- требуемые рабочие характеристики (7.12);

- исходный язык (7.6).

Виды среды:

- прикладная область информационной системы (7.2);

- вычислительная система и среда (7.15);

- класс пользователя (7.8);

- требование к вычислительным ресурсам (7.16);

- критичность ПС (7.7);

- готовность программного продукта (7.10).

Виды данных:

- представление данных (7.5);

- использование программных данных (7.11).

Выбор видов и классов

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

При применении схемы классификации к приложениям, для которых необходимо подмноже­ство видов, должны быть использованы все соответствующие виды и связанные с ними классы. Например, если характеризуют ПС по отношению к его среде, может быть пригоден набор видов, составляющих подмножество «Среда» из 6.1. В зависимости от специфики приложения может быть необходимым использование дополнительных видов, таких как требования защиты или надежности.

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

Схема классификации.

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

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

Классы, соответствующие виду, необязательно абстрагированы на одном уровне.

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

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

Процесс заказа.

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

1) подготовка;

2) подготовка заявки на подряд;

3) подготовка и корректировка договора;

4) надзор за поставщиком;

5) приемка и закрытие договора.

Процесс поставки.

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

Данный процесс состоит из следующих работ:

1) подготовка;

2) подготовка ответа;

3) подготовка договора;

4) планирование;

5) выполнение и контроль;

6) проверка и оценка;

7) поставка и закрытие договора.

Процесс разработки.

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

Данный процесс состоит из следующих работ:

1) подготовка процесса;

2) анализ требований к системе;

3) проектирование системной архитектуры;

4) анализ требований к программным средствам;

5) проектирование программной архитектуры;

6) техническое проектирование программных средств;

7) программирование и тестирование программных средств;

8) сборка программных средств;

9) квалификационные испытания программных средств;

10) сборка системы;

11) квалификационные испытания системы;

12) ввод в действие программных средств;

13) обеспечение приемки программных средств.

Процесс эксплуатации.

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

Данный процесс состоит из следующих работ:

1)подготовка процесса;

2)эксплуатационные испытания;

3)эксплуатация системы;

4)поддержка пользователя.

5. Процесс сопровождения.

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

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

Данный процесс состоит из следующих работ:

1) подготовка процесса;

2) анализ проблем и изменений;

3) внесение изменений;

4) проверка и приемка при сопровождении;

5) перенос;

6) снятие с эксплуатации.

3.7.3. Вспомогательные процессы ЖЦ ПС.

Существуют следующие вспомогательные процессы ЖЦ:

Процесс документирования.

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

Данный процесс состоит из следующих работ:

1) подготовка процесса;2) проектирование и разработка;3) выпуск;4) сопровождение.

Основные положения

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

Область регулирования

Требования СПО обеспечивают защиту интересов государства при:

• создании новых информационных систем;

• интеграции унаследованный информационных систем, разработанных до принятия СПО;

• организации и поддержке информационного взаимодействия субъектов электронного государства.

Содержание
1. Стандартизация и сертификация программного обеспечения
2. Техническое регулирование и стандартизация в области ИКТ
3. Закон о техническом регулировании. Основные положения
4. Управление качеством и обеспечение качества на основе стандартов серии ИСО 9000
5. Требования стандарта ISO 9000
6. Зрелость процессов. Измерение зрелости
7. Процессы проектирования сложных программных систем
8. Основные положения стандартов ГОСТ Р ИСО/МЭК 15288-2005 и ISO/IEC 12207-1999
9. Принципы обеспечения качества программных средств
10. Оценка программной продукции
11. Организация работ по стандартизации в области ИКТ и открытые системы
12. Основные направления создания открытых информационных систем
13. Нормативно-правовые документы и стандарты в области защиты информации и информационной безопасности
14. Нормативно-правовая база сертификации продукции и услуг в области ИКТ
15. Схемы сертификации
вом.

 

 

Сертификация информационно и программных средств