Товары в корзине: 0 шт Оформить заказ
Стр. 1 

102 страницы

861.00 ₽

Купить ГОСТ Р МЭК 62279-2016 — бумажный документ с голограммой и синими печатями. подробнее

Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

 Скачать PDF

Идентичен IEC 62279(2015)

Оглавление

1 Область применения

2 Нормативные ссылки

3 Термины, определения и сокращения

     3.1 Термины и определения

     3.2 Сокращения

4 Цели, соответствие и уровни полноты безопасности программного обеспечения

5 Организация и управление программным обеспечением

     5.1 Организация, роли и обязанности

     5.2 Компетентность персонала

     5.3 Жизненный цикл и документация

6 Гарантированное программное обеспечение

     6.1 Тестирование программного обеспечения

     6.2 Проверка программного обеспечения

     6.3 Подтверждение соответствия программного обеспечения

     6.4 Оценка программного обеспечения

     6.5 Обеспечение качества программного обеспечения

     6.6 Управление модификациями и изменениями

     6.7 Инструментальные средства поддержки и языки

7 Разработка универсального программного обеспечения

     7.1 Жизненный цикл и документация универсального программного обеспечения

     7.2 Требования к программному обеспечению

     7.3 Архитектура и проектирование

     7.4 Проектирование компонент

     7.5 Реализация и тестирование компонент

     7.6 Интеграция

     7.7 Тестирование всего программного обеспечения. Заключительное подтверждение соответствия

8 Разработка прикладных данных или алгоритмов. Системы, сконфигурированные прикладными данными или алгоритмами

     8.1 Цели

     8.2 Входные документы

     8.3 Выходные документы

     8.4 Требования

9 Развертывание и сопровождение программного обеспечения

     9.1 Развертывание программного обеспечения

     9.2 Сопровождение программного обеспечения

Приложение А (обязательное) Критерии выбора методов и мер

Приложение В (обязательное) Основные роли и обязанности специалистов в области программного обеспечения

Приложение С (справочное) Контроль прохождения технической документации

Приложение D (справочное) Цель и описание методов

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов национальным стандартам

Библиография

 
Дата введения01.01.2018
Добавлен в базу05.05.2017
Актуализация01.01.2019

Этот ГОСТ находится в:

Организации:

30.11.2016УтвержденФедеральное агентство по техническому регулированию и метрологии1881-ст
ИзданСтандартинформ2016 г.
РазработанООО Корпоративные электронные системы

Railway applications. Communication, signaling and processing systems. Software for railway control and protection systems

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ



Железные дороги

СИСТЕМЫ СВЯЗИ, СИГНАЛИЗАЦИИ И ОБРАБОТКИ ДАННЫХ. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ СИСТЕМ УПРАВЛЕНИЯ И ЗАЩИТЫ НА ЖЕЛЕЗНЫХ ДОРОГАХ

(IEC 62279:2015, ЮТ)

Издание официальное

Стандартинформ

2017

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Корпоративные электронные системы» на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 58 «Функциональная безопасность»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии России от 30 ноября 2016 г. № 1881-ст

4    Настоящий стандарт идентичен международному стандарту МЭК 62279:2015 «Железные дороги. Системы связи, сигнализации и обработки данных. Программное обеспечение систем управления и защиты на железных дорогах» (IEC 62279:2015, «Railway applications — Communication, signalling and processing systems — Software for railway control and protection systems», IDT).

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

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2017

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

II

ГОСТ Р МЭК 62279-2016

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

3.1.43    класс инструментальных средств Т1 (tool class Т1): Созданный инструментом результат не может прямо или косвенно повлиять на исполнимый код (включая данные) программного обеспечения.

Примечание — Примеры класса Т1 включают: редактор текста либо инструментальное средство проектирования без возможностей автоматической генерации объектного кода; средства управления конфигурацией.

3.1.44    класс инструментальных средств Т2 (tool class Т2): Инструментальные средства, поддерживающие тестирование или проверку проекта или исполнимого кода, ошибки в которых не позволяют выявить дефекты, но они не могут непосредственно создавать ошибки в исполнимом программном обеспечении.

Примечание — Примеры класса Т2 включают: генератор испытания ремня безопасности; инструментальное средство измерения тестового охвата; инструментальное средство статического анализа.

3.1.45    класс инструментальных средств ТЗ (tool class ТЗ): Созданный инструментом результат может прямо или косвенно повлиять на исполнимый код (включая данные) связанной с безопасностью системы.

Примечание — Примеры класса ТЗ включают: компилятор исходного кода, компилятор данных/алгорит-мов, инструмент для изменения уставок во время работы системы; оптимизирующий компилятор, где отношения между исходным кодом программы и сгенерированным объектным кодом не очевидны; компилятор, который включает выполняемый программный пакет времени выполнения в выполнимый код.

3.1.46    прослеживаемость (traceability): Степень, с которой может быть установлено отношение между двумя или более результатами процесса разработки, особенно между имеющими предшествен-ника/преемника или отношение основной/зависимый между собой.

3.1.47    подтверждение соответствия (validation): Процесс анализа, за которым следует основанное на доказательстве обоснование, при определении того, соответствует ли элемент (например, процесс, документация, программное обеспечение или применение) потребностям пользователя, в особенности относительно безопасности и качества и с учетом пригодности его работы в соответствии с его целью в намеченном для него окружении.

3.1.48    менеджер по подтверждению соответствия (validator): Субъект, ответственный за подтверждение соответствия.

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

Примечание — Проверка главным образом основана на рецензировании выходных документов (проекта, реализации, документов испытаний и т. д.).

3.1.50    менеджер по проверке (verifier): Субъект, ответственный за одно или более действий проверки.

3.2 Сокращения

ASR— оценщик;

COTS— коробочное программное обеспечение;

CGM— менеджер конфигураций;

DES— проектировщик;

HR— настоятельно рекомендуемый;

IMP— разработчик;

INT — интегратор;

JSD — метод JSD;

5

М — обязательный;

MASCOT — модульный подход к созданию программного обеспечения, выполнению и тестированию; NR— не рекомендовано;

РМ— менеджер проекта;

QAM— менеджер контроля качества;

R— рекомендовано;

RAMS— безотказность, готовность, ремонтопригодность и безопасность; RQM — менеджер требований;

SDL—язык спецификации и описания;

SFC— последовательные функциональные схемы;

SIL—уровень полноты безопасности;

SOM— моделирование, ориентированное на сервисы;

SSADM— методика структурного анализа и проектирования систем;

TST — тестировщик;

V&V— проверка и подтверждение соответствия;

VAL— менеджер по подтверждению соответствия;

VER— менеджер по проверке.

4 Цели, соответствие и уровни полноты безопасности программного обеспечения

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

-    функции и интерфейсы;

-    условия применения;

-    конфигурация или архитектура системы;

-    опасности, которыми необходимо управлять;

-    требования полноты безопасности;

-    распределение требований и распределение УПБ для программного обеспечения и аппаратных средств;

-    ограничения синхронизации.

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

4.2    Полнота программного обеспечения должна быть определена как один из пяти уровней от УПБ 0 (самый низкий) до значений полноты безопасности от УПБ 1 до УПБ 4.

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

4.4    Требования УПБ 0 в настоящем стандарте должны быть выполнены для части программного обеспечения функций, которые имеют степень неуверенности о влиянии на безопасность, как правило, ниже УПБ 1.

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

ГОСТ Р МЭК 62279-2016

4.6    Если требование определено словами «до степени, требуемой уровнем полноты безопасности программного обеспечения», то это указывает, что должен использоваться целый ряд методов и мер, чтобы удовлетворить это требование.

4.7    Если применен 4.6, то для помощи в выборе методов и мер, соответствующих уровню полноты безопасности программного обеспечения, должны использоваться таблицы из приложения А. Выбор должен быть зарегистрирован в плане обеспечения качества программного обеспечения или в другом документе, на который ссылается план обеспечения качества программного обеспечения. Указания к этим методам даются в приложении D.

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

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

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

5 Организация и управление программным обеспечением

5.1    Организация, роли и обязанности

5.1.1    Цель

5.1.1.1    Гарантировать, что весь персонал, у кого есть обязанности в области программного обеспечения, был организован, имел полномочия и был способен к выполнению своих обязанностей.

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

5.1.2 Требования

5.1.2.1    Как минимум, поставщик должен реализовать разделы ИСО 9001:2008, посвященные организации и управлению персоналом и обязанностям.

5.1.2.2    Обязанности должны быть совместимы с требованиями, определенными в приложении В.

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

5.1.2.4    Оценщик должен быть назначен поставщиком, клиентом или полномочным органом по безопасности.

5.1.2.5    Оценщик должен быть независим от поставщика. Однако на усмотрение полномочного органа по безопасности оценщик может быть из организации поставщика или организации заказчика, но не должен участвовать в разработке проекта.

5.1.2.6    Оценщик должен быть независим от проекта.

5.1.2.7    Оценщику необходимо обладать полномочиями для выполнения оценки программного обеспечения.

5.1.2.8    Менеджер по проверке должен дать/не дать разрешение на выпуск программного обеспечения.

7

5.1.2.9    На всем жизненном цикле программного обеспечения назначение ролей персоналу должно быть выполнено в соответствии с 5.1.2.10—5.1.2.14 в объеме требований УПБ программного обеспечения.

5.1.2.10    Предпочтительная организационная структура для УПБ 3 и УПБ 4:

a)    Менеджер требований, проектировщик и разработчик компонента программного обеспечения могут быть одним и тем же человеком.

b)    Менеджер требований, проектировщик и разработчик компонента программного обеспечения должны предоставлять отчет менеджеру проектов.

c)    Интегратор и тестировщик компонента программного обеспечения могут быть одним и тем же человеком.

d)    Интегратор и тестировщик компонента программного обеспечения могут предоставлять отчет менеджеру проектов или менеджеру по подтверждению соответствия.

e)    Менеджер по проверке или менеджер контроля качества могут предоставлять отчет менеджеру проектов или менеджеру по подтверждению соответствия.

f)    Менеджер по подтверждению соответствия не должен предоставлять отчет менеджеру проектов, т. е. менеджер проектов не должен иметь никакого влияния на решения менеджера по подтверждению соответствия, но менеджер по проверке сообщает менеджеру проектов о своих решениях.

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

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

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

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

8

УПБ 3 и УПБ 4


УПБ 1 и УПБ 2


RQM, DES, IMP


РМ


INT, TST


VER,

QAM


VAL


ГОСТ Р МЭК 62279—2016


ASR


РМ

ij

ASR

-1-1-1-

RQM, DES, IMP

INT, TST


VER, VAL, QAM


УПБ О

РМ

i i i i i i 1 1

ASR

1

I

| -------

|

RQM, DES, IMP

INT, TST, VER, QAM, VAL

1

1

1


Обозначения


может быть тем же лицом;


!..............1

■    ■    может быть той же    организацией;

•    •


должен отчитываться перед менеджером проекта;

может отчитываться перед менеджером проекта; не должен отправлять отчеты менеджеру проекта.


PM

- менеджер проекта;

ASR

- оценщик;

RQM

- менеджер требований;

INT

- интегратор;

QAM

- менеджер контроля качества;

TST

- тестировщик;

DES

- проектировщик;

VER

- специалист по проверке;

IMP

- разработчик;

VAL

- специалист по подтверждению

соответствия.

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


Рисунок 2 — Иллюстрация предпочтительной организационной структуры

Примечание — Рисунок 2 только иллюстрирует предпочтительную организационную структуру.

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


9


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

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

Однако возможны следующие варианты:

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

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

5.1.2.11 Предпочтительная организационная структуры для УПБ 1 и УПБ 2

a)    Менеджер требований, проектировщик, разработчик компонента программного обеспечения могут быть одним и тем же человеком и должны предоставлять отчет менеджеру проектов.

b)    Интегратор и тестировщик компонента программного обеспечения могут быть одним и тем же человеком.

c)    Интегратор и тестировщик компонента программного обеспечения могут предоставлять отчет менеджеру проектов или менеджеру по подтверждению соответствия.

d)    Менеджер по проверке, менеджер контроля качества и менеджер по подтверждению соответствия могут быть одним и тем же человеком.

e)    Менеджер по проверке, менеджер контроля качества и менеджер по подтверждению соответствия могут предоставлять отчет менеджеру проектов.

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

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

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

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

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

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

Однако возможны следующие варианты:

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

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

ю

ГОСТ Р МЭК 62279-2016

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

5.1.2.12    Предпочтительная организационная структура для УПБ 0

a)    Менеджер требований, проектировщик и разработчик компонента программного обеспечения могут быть одним и тем же человеком и должны управляться менеджером проектов.

b)    Интегратор, тестировщик, менеджер по проверке, менеджер контроля качества и менеджер по подтверждению соответствия компонента программного обеспечения могут быть одним и тем же человеком.

c)    Интегратором, тестировщиком, менеджером по проверке, менеджером контроля качества и менеджером по подтверждению соответствия может руководить менеджер проектов.

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

e)    Лицо, являющееся менеджером по проверке, менеджером контроля качества или менеджером по подтверждению соответствия, не должно быть ни менеджером требований, ни проектировщиком, ни разработчиком.

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

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

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

Однако возможны следующие варианты:

i)    менеджер требований, проектировщик, разработчик, интегратор и тестировщик могут быть одним и тем же человеком;

j)    менеджер по подтверждению соответствия, менеджер по проверке и менеджер контроля качества могут также быть одним и тем же человеком;

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

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

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

5.2 Компетентность персонала

5.2.1    Цели

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

5.2.2    Требования

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

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

11

5.2.2.3    Если подтверждением оценщика или сертификацией было доказано, что для всего персонала, назначенного на различные роли, была продемонстрирована компетентность, то каждый человек должен продемонстрировать непрерывное развитие и повышение своей квалификации. Это может быть продемонстрировано, ведением регистрационного журнала, показывающего, что регулярно выполняемые работы правильны и в соответствии с ИСО 9001 и ИСО/МЭК 90003:2014, 6.2.2 «Компетентность, осведомленность и обучение» реализуется дополнительное обучение.

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

5.3 Жизненный цикл и документация

5.3.1    Цели

5.3.1.1    Структурировать разработку программного обеспечения на определенные стадии и действия.

5.3.1.2    Фиксировать всю информацию, относящуюся к программному обеспечению, на всем жизненном цикле программного обеспечения.

5.3.2    Требования

5.3.2.1    Должна быть выбрана модель жизненного цикла для разработки программного обеспечения. Это должно быть подробно представлено в плане обеспечения качества программного обеспечения в соответствии с 6.5.

На рисунках 3 и 4 показаны два примера моделей жизненного цикла.

5.3.2.2    Модель жизненного цикла должна учитывать возможность итераций внутри стадий и между ними.

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

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

5.3.2.5    Все выполняемые на каждой стадии действия должны быть определены и спланированы до начала стадии.

5.3.2.6    Все документы должны быть структурированы, чтобы обеспечить их непрерывное увеличение в процессе разработки.

5.3.2.7    Для каждого документа должна быть обеспечена прослеживаемость с помощью уникального ссылочного номера, а также определенного и документально оформленного отношения с другими документами.

5.3.2.8    Каждый термин, условное обозначение или сокращение должен иметь одно и то же значение в каждом документе. Если по историческим причинам это будет невозможно, то различные значения должны быть перечислены и даны ссылки.

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

-    он должен содержать или реализовывать все применимые условия и требования предыдущего документа, с которым он иерархически связан;

-    он не должен противоречить предыдущему документу.

5.3.2.10    Каждый элемент или понятие должно быть названо одним и тем же именем или одинаково описанием во всех документах.

5.3.2.11    Содержание всех документов должно быть оформлено в виде, подходящем для манипулирования, обработки и хранения.

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

5.3.2.13    Документы могут быть объединены или разделены в соответствии с 5.3.2.12. Некоторые шаги разработки могут быть объединены, разделены или, если обоснованы, устранены по решению руководителя проекта и с согласия менеджера по подтверждению соответствия.

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


Документы проектирования и    Деятельность    по

тестирования    проверке


Стадии


Требования к программному Обеспечению

Архитектура программного обеспечения

Проект программного обеспечения

Проект компонента программного обеспечения

Реализация и тестирование компонента

Интеграция программного обеспечения

Подтверждение соответствия программного обеспечения

Развертывание программного обеспечения

Сопровождение программного обеспечения


Оценка программного обеспечения является внешней деятельностью и может выполняться на протяжении всего жизненного цикла


Рисунок 3 — Пример жизненного цикла разработки 1



Стадия сопровождения программного обеспечения (подраздел 9.2)


Стадия разработки системы (внешняя)


Спецификация требований к системе. Спецификация требований к безопасности системы. Описание архитектуры системы.

План обеспечения безопасности системы/план V&V


Журнал сопровождения программного обеспечения.

Журнал изменений программного обеспечения.

Отчет о проверке сопровождения программного обеспечения


Стадия оценки программного обеспечения


I


Стадия формирования требований к программному обеспечению (подраздел 7,2)


Стадия развертывания программного обеспечения (подраздел 9.1)


Спецификация требований к программному обеспечению.

Спецификация тестирования всего программного обеспечения


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

Руководство по развертыванию программного обеспечения.

Информация о версии.

Журнал развертывания.

Отчет о проверке развертывания_


План оценки программного обеспечения.

Отчет о результатах оценки программного обеспечения


Отчет о проверке требований к программному обеспечению


I


Стадия подтверждения соответствия программного обеспечения (подраздел 7.7)


Стадия планирования программного обеспечения


Стадия архитектуры и проектирования программного обеспечения (подраздел 7,3)


План обеспечения качества программного обеспечения.

План менеджмента конфигурации программного обеспечения.

План проверки программного обеспечения.

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

План сопровождения программного обеспечения.

Отчет о проверке обеспечения качества программного обеспечения


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

Спецификация проекта программного обеспечения.

Спецификация интерфейса программного обеспечения.

Спецификация тестирования интеграции, программного обеспечения.

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


Отчет о тестировании всего программного обеспечения.

Отчет о подтверждении соответствия программного обеспечения.

Отчет о проверке тестирования всего программного обеспечения


Z


Стадия интеграции программного обеспечения (подраздел 7.6)


Отчет о проверке архитектуры и проекта программного обеспечения


Отчет о тестировании интеграции программного обеспечения.

Отчет о тестировании интеграции программного обеспечения и аппаратных средств.

Отчет о проверке интеграции программного обеспечения


I


Стадия проектирования компонента программного обеспечения (подраздел 7.4)


Стадия реализации и тестирования компонента программного обеспечения (подраздел 7.5)


Спецификация проекта компонента программного обеспечения.

Спецификация тестирования компонента программного обеспечения_


Исходный код и сопроводительная документация программного обеспечения


Отчет о тестировании компонента программного обеспечения


Отчет о проверке проекта компонента программного обеспечения


Отчет о проверке исходного кода программного обеспечения


Рисунок 4 — Пример жизненного цикла разработки 2


6 Гарантированное программное обеспечение

6.1    Тестирование программного обеспечения

6.1.1    Цель

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

6.1.2    Входные документы

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

6.1.3    Выходные документы

a)    Спецификация тестирования всего программного обеспечения.

b)    Отчет об испытаниях всего программного обеспечения.


ГОСТ Р МЭК 62279-2016

Содержание

1    Область применения.................................................................1

2    Нормативные ссылки.................................................................2

3    Термины, определения и сокращения...................................................2

3.1    Термины и определения ..........................................................2

3.2    Сокращения ....................................................................5

4    Цели, соответствие и уровни полноты безопасности программного обеспечения ...............6

5    Организация и управление программным обеспечением ...................................7

5.1    Организация, роли и обязанности...................................................7

5.2    Компетентность персонала .......................................................11

5.3    Жизненный цикл и документация..................................................12

6    Гарантированное программное обеспечение............................................14

6.1    Тестирование программного обеспечения...........................................14

6.2    Проверка программного обеспечения ..............................................15

6.3    Подтверждение соответствия программного обеспечения..............................17

6.4    Оценка программного обеспечения ................................................18

6.5    Обеспечение качества программного обеспечения ...................................20

6.6    Управление модификациями и изменениями ........................................22

6.7    Инструментальные средства поддержки и языки .....................................23

7    Разработка универсального программного обеспечения...................................26

7.1    Жизненный цикл и документация универсального программного обеспечения.............26

7.2    Требования к программному обеспечению ..........................................27

7.3    Архитектура и проектирование....................................................29

7.4    Проектирование компонент.......................................................34

7.5    Реализация и тестирование компонент .............................................36

7.6    Интеграция ....................................................................37

7.7    Тестирование всего программного обеспечения. Заключительное подтверждение

соответствия......................................................................39

8    Разработка прикладных данных или алгоритмов. Системы, сконфигурированные

прикладными данными или алгоритмами ................................................41

8.1    Цели..........................................................................41

8.2    Входные документы .............................................................41

8.3    Выходные документы............................................................41

8.4    Требования ....................................................................42

9    Развертывание и сопровождение программного обеспечения ..............................46

9.1    Развертывание программного обеспечения..........................................46

9.2    Сопровождение программного обеспечения .........................................47

Приложение А (обязательное) Критерии выбора методов и мер..............................50

Приложение В (обязательное) Основные роли и обязанности специалистов в области

программного обеспечения................................................61

Приложение С (справочное) Контроль прохождения технической документации ................68

Приложение D (справочное) Цель и описание методов .....................................70

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам...............................................93

Библиография.......................................................................94

ГОСТ Р МЭК 62279-2016

c)    Спецификация тестирования интеграции программного обеспечения.

d)    Отчет об испытаниях интеграции программного обеспечения.

e)    Спецификация тестирования интеграции программного обеспечения/аппаратных средств.

f)    Отчет об испытаниях интеграции программного обеспечения/аппаратных средств.

д)    Спецификация тестирования компонента программного обеспечения.

h) Отчет об испытаниях компонента программного обеспечения.

6.1.4 Требования

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

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

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

6.1.4.4    Документ для каждой спецификации тестирования должен содержать следующее:

a)    цели испытаний;

b)    тестовые сценарии, данные испытаний и ожидаемые результаты;

c)    типы тестов, которые будут выполнены;

d)    окружение, инструменты, конфигурацию и программы испытаний;

е)    критерии испытаний, по которым будет завершен тест;

f) критерии и уровень тестового охвата, который должен быть достигнут;

д)    роли и обязанности персонала, участвующего в процессе испытаний;

h)    требования, которые охвачены спецификацией тестов;

i)    выбор и использование оборудования для испытания программного обеспечения.

6.1.4.5    Отчет об испытаниях должен быть представлен следующим образом:

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

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

c)    тесты должны быть воспроизводимыми и, если это реально, должны быть выполнены автоматическими средствами;

d)    тестовые сценарии для автоматического выполнения испытаний должны быть проверены;

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

f) оценка тестового охвата и завершение теста должны быть обеспечены, а любые отклонения зафиксированы.

6.2 Проверка программного обеспечения

6.2.1    Цель

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

6.2.2    Входные документы

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

6.2.3    Выходные документы

a)    План проверки программного обеспечения.

b)    Отчет(ы) о проверке программного обеспечения.

c)    Отчет о проверке обеспечения качества программного обеспечения.

15

Введение

Настоящий стандарт входит в группу связанных стандартов вместе с МЭК 62278:2002 «Железные дороги. Технические условия и демонстрация надежности, эксплуатационной готовности, ремонтопригодности и безопасности» и МЭК 62425:2007 «Железные дороги. Системы связи, сигнализации и обработки данных. Связанные с безопасностью электронные системы сигнализации».

МЭК 62278:2002 рассматривает проблемы крупных систем, а в МЭК 62425:2007 рассмотрен порядок утверждения отдельных систем, которые могут существовать внутри общей системы управления и защиты на железнодорожном транспорте. Настоящий стандарт уделяет внимание практическим методам создания программного обеспечения, удовлетворяющего требованиям полноты безопасности, которые определяются в результате анализа таких крупных систем.

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

Ключевое понятие настоящего стандарта — это понятие уровней полноты безопасности программного обеспечения. Настоящий стандарт рассматривает пять уровней полноты безопасности программного обеспечения, где УПБ 0 является самым низким, а УПБ 4 — самым высоким связанным с безопасностью уровнем полноты. Чем выше риск, возникающий из-за ошибки в программном обеспечении, тем выше уровень полноты безопасности программного обеспечения будет. Чем более опасны последствия ошибки программного обеспечения, тем будет выше его уровень полноты безопасности.

Настоящий стандарт определяет методы и меры для пяти уровней полноты безопасности программного обеспечения. Требуемые методы и меры для каждого из пяти уровней полноты безопасности программного обеспечения представлены в нормативных таблицах приложения А. В настоящей версии требуемые методы для уровня 1 совпадают с методами для уровня 2, а требуемые методы для уровня 3 совпадают с методами для уровня 4. Настоящий стандарт не дает рекомендаций о том, какой уровень полноты программного обеспечения подходит для данного риска. Это решение будет зависеть от многих факторов, включая природу приложения, насколько другие системы выполняют функции безопасности, также от социально-экономических факторов.

Определение процесса спецификации функций безопасности, выполняемых программным обеспечением, входит в область применения МЭК 62278 и МЭК 62425.

Настоящий стандарт определяет те меры, которые необходимы для достижения таких требований.

МЭК 62278 и МЭК 62425 требуют, чтобы был использован систематический подход:

a)    для определения опасностей, оценки рисков и получения решения на основе критериев риска;

b)    определения необходимого снижения риска, удовлетворяющего критериям риска;

c)    определения спецификации требований для всей системы безопасности, необходимых для гарантированного достижения требуемого снижения риска;

d)    выбора подходящей архитектуры системы;

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

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

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

Принципы, применяемые при разработке программного обеспечения с высокими требованиями по безопасности, включают в себя, но не ограничены:

IV

ГОСТ Р МЭК 62279-2016

-    нисходящие методы разработки;

-    модульный принцип;

-    проверка каждой стадии жизненного цикла разработки;

-    проверенные модули и библиотеки модулей;

-    понятная документация и прослеживаемость;

-    аудирование документов;

-    подтверждение соответствия;

-    оценка;

-    управление конфигурацией и управление изменениями;

-    надлежащее рассмотрение проблем компетентности организации и персонала.

Спецификация требований безопасности к системе идентифицирует все функции безопасности,

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

a)    определение спецификации требований для программного обеспечения и параллельно рассмотрение архитектуры программного обеспечения. В рамках формирования архитектуры программного обеспечения разрабатывается основная стратегия безопасности для программного обеспечения и его уровня полноты безопасности (см. 7.2 и 7.3);

b)    проектирование, разработка и тестирование программного обеспечения выполняется согласно плану обеспечения качества программного обеспечения, уровню полноты безопасности программного обеспечения и жизненному циклу программного обеспечения (см. 7.4 и 7.5);

c)    реализация интеграции программного обеспечения и программного обеспечения с аппаратными средствами на целевых аппаратных средствах, а также проверка функциональности (см. 7.6);

d)    выполнение приемки и внедрение программного обеспечения (см. 7.7 и 9.1);

e)    если в период эксплуатации программного обеспечения требуется его поддержка, то повторно выполняются надлежащие процедуры настоящего стандарта (см. 9.2).

С разработкой программного обеспечения связаны несколько действий таких, как тестирование (см. 6.1), проверка (см. 6.2), подтверждение соответствия (см. 6.3), оценка (см. 6.4), контроль качества (см. 6.5), а также управление модификацией и изменениями (6.6).

Представлены требования к средствам поддержки (см. 6.7) и системам, которые сконфигурированы с помощью данных приложения или алгоритмов (см. 8).

Также даны требования к независимости ролей и компетентности штата, участвующего в разработке программного обеспечения (см. 5.1,5.2 и приложение В).

Настоящий стандарт не рассматривает использование конкретного жизненного цикла разработки программного обеспечения. Однако в 5.3, рисунки 3 и 4, и 7.1 представлены иллюстративный пример жизненного цикла и необходимые комплекты документации.

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

V

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


Идентифицировать все функции безопасности, назначенные программному обеспечению


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


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


<■


Спроектировать, разработать и провести верификацию или тестирование программного обеспечения в соответствии с планом обеспечения качества программного обеспечения, уровнем полноты безопасности программного обеспечения и жизненным циклом программного обеспечения


Выполнить подтверждение соответствия программного обеспечения и передать системным инженерам


Период эксплуатации системы


Поддержка программного обеспечения


Рисунок 1 — Маршрутная карта программного обеспечения


НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Железные дороги

СИСТЕМЫ СВЯЗИ, СИГНАЛИЗАЦИИ И ОБРАБОТКИ ДАННЫХ. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ СИСТЕМ УПРАВЛЕНИЯ И ЗАЩИТЫ НА ЖЕЛЕЗНЫХ ДОРОГАХ

Railway applications. Communication, signalling and processing systems. Software for railway control and protection systems

Дата введения —2018—01—01

1 Область применения

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

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

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

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

-    прикладное программирование;

-    операционные системы;

-    инструменты поддержки;

-    встроенное микропрограммное обеспечение.

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

1.5    Настоящий стандарт также рассматривает использование существующего ранее программного обеспечения и инструментальных средств. Такое программное обеспечение может использоваться, если выполнены конкретные требования 7.3.4.7 и 6.5.4.16 для уже существующего программного обеспечения и требования 6.7 для инструментальных средств.

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

Издание официальное

1.7    Настоящий стандарт полагает, что современное проектирование приложений часто использует универсальное программное обеспечение, которое является базовым для различных приложений. Такое универсальное программное обеспечение конфигурируется данными, алгоритмами или тем и другим при создании исполнимого программного обеспечения для приложения. Разделы 1—6 и 9 настоящего стандарта применяются к универсальному программному обеспечению, а также к данным приложения или алгоритмам. Раздел 7 применяется только для универсального программного обеспечения, а раздел 8 содержит конкретные требования для данных приложения или алгоритмов.

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

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

2    Нормативные ссылки

В настоящем стандарте использованы следующие международные стандарты. Для датированных ссылок применяют только указанное издание ссылочного стандарта. Для недатированных ссылок применяют последнее издание ссылочного стандарта.

IEC 62278:2002, Railway applications — Specification and demonstration of reliability, availability, maintainability and safety (RAMS) (Железные дороги. Технические условия и демонстрация надежности, эксплуатационной готовности, ремонтопригодности и безопасности (RAMS))

ISO/IEC 90003:2014, Software engineering — Guidelines forthe application of ISO 9001:2008 to computer software (Разработка программных продуктов. Руководящие указания по применению ИСО 9001:2008 при разработке программных продуктов)

ISO/IEC 25010 series, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models (Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модели качества систем и программных продуктов)

ISO 9000, Quality management systems — Fundamentals and vocabulary (Системы менеджмента качества. Основные положения и словарь)

ISO 9001:2008, Quality management systems — Requirements (Системы менеджмента качества. Требования)

3    Термины, определения и сокращения

3.1    Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями.

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

Примечание — Оценивание безопасности направлено, но не ограничивается, на оценку свойств безопасности системы.

3.1.2    оценщик (assessor): Субъект, выполняющий оценку.

3.1.3    коробочное программное обеспечение (commercial off-the-shelf (COTS) software): Программное обеспечение, определенное потребностью рынка, коммерчески доступное, пригодность для определенной цели которого было продемонстрировано широким спектром коммерческих пользователей.

2

ГОСТ Р МЭК 62279-2016

3.1.4    компонент (component): Составная часть программного обеспечения, которая имеет хорошо определенные интерфейсы и ее поведение соответствует проекту и архитектуре программного обеспечения.

Примечание — Компонент программного обеспечения удовлетворяет следующим критериям:

-    он разработан согласно «Компонентам» (см. таблицу А.20);

-    он реализует определенное подмножество требований к программному обеспечению;

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

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

3.1.6    заказчик (customer): Субъект, который покупает железнодорожную систему управления и систему защиты включая программное обеспечение.

3.1.7    проектировщик (designer): Субъект, который анализирует и преобразовывает конкретные требования в приемлемые проектные решения, имеющие требуемый уровень полноты безопасности.

3.1.8    субъект (entity): Человек, группа или организация, которые выполняют роль, как определено в настоящем стандарте.

3.1.9    сбой (fault): Аварийное состояние, которое может привести к ошибке в системе.

Примечание — Сбой может быть случайным или систематическим.

3.1.10    ошибка (error): Отклонение от намеченного проекта, которое может привести к непреднамеренному поведению системы или отказу.

3.1.11    отказ (failure): Недопустимое различие между требуемой и наблюдаемой характеристикой.

3.1.12    отказоустойчивость (fault tolerance): Встроенная способность системы обеспечить дальнейшее корректное оказание услуги согласно спецификации, в присутствии ограниченного количества сбоев аппаратных средств или программного обеспечения.

3.1.13    встроенное микропрограммное обеспечение (firmware): Программное обеспечение, размещенное в постоянной или в полупостоянной памяти (например такой как флэш-память), так, что оно функционально не зависит от прикладного программного обеспечения.

3.1.14    универсальное программное обеспечение (generic software): Программное обеспечение, которое может использоваться для множества установок просто благодаря появлению возможности определять конкретные для применения данные и/или алгоритмы.

3.1.15    разработчик (implementer): Субъект, который преобразует конкретные проекты в их физическую реализацию.

3.1.16    интеграция (integration): Процесс объединения программного обеспечения и/или элементов аппаратных средств в соответствии со спецификацией архитектуры и проекта, также тестирование интегрированного устройства.

3.1.17    интегратор (integrator): Субъект, который выполняет интеграцию программного обеспечения.

3.1.18    существующее ранее программное обеспечение (pre-existing software): Программное обеспечение, разработанное до рассматриваемого в настоящее время применения, включающее коммерческое программное обеспечение и открытое программное обеспечение.

3.1.19    открытое программное обеспечение (open source software): Доступный широкой публике исходный код с ослабленными или отсутствующими ограничениями на авторские права.

3.1.20    программируемый логический контроллер (programmable logic controller): Полупроводниковая система управления с программируемой памятью пользователя для хранения команд, осуществляющих конкретные функции.

3.1.21    управление проектами (project management): Административное и/или техническое выполнение проекта, включая вопросы безопасности.

3.1.22    менеджер проекта (project manager): Субъект, который выполняет управление проектом.

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

3.1.24    робастность (robustness): Способность элемента обнаруживать и обрабатывать ненормальные ситуации.

з

3.1.25    менеджер требований (requirements manager): Субъект, выполняющий управление требованиями.

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

Примечание — Управление требованием — непрерывный процесс в течение выполнения проекта.

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

3.1.28    безопасность (safety): Отсутствие неприемлемого риска опасности для человека.

3.1.29    уполномоченный орган по безопасности (safety authority): Организация, ответственная за подтверждение того, что связанные с безопасностью программное обеспечение или услуги удовлетворяют соответствующим установленным требования безопасности.

3.1.30    функция безопасности (safety function): Функция, которая реализует часть или все требование безопасности.

3.1.31    связанное с безопасностью программное обеспечение (safety-related software): Программное обеспечение, которое выполняет функции безопасности.

3.1.32    программное обеспечение (software): Интеллектуальный продукт, включающий программы, процедуры, правила, данные и любую связанную документацию, относящуюся к работе системы.

3.1.33    базовая конфигурация программного обеспечения (software baseline): Завершенный и согласованный набор исходных кодов, исполняемых файлов, конфигурационных файлов, инсталляционных подлинников и документации, которые необходимы для выпуска программного обеспечения.

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

3.1.34    развертывание программного обеспечения (software deployment): Передача, установка и активизация поставляемой базовой версии программного обеспечения, которое было уже выпущено и оценено.

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

Примечание —Жизненный цикл программного обеспечения, как правило, включает стадии формирования требований, проектирования, испытаний, интеграции, развертывания и сопровождения.

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

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

3.1.38    уровень полноты безопасности программного обеспечения (software safety integrity level): Классификационный индекс, который определяет методы и меры, которые должны быть применены к программному обеспечению.

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

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

3.1.40    уровень полноты безопасности системы (system safety integrity level); Классификационный индекс, который указывает необходимую степень уверенности, что интегрированная система, включающая аппаратные средства и программное обеспечение, удовлетворяет заданным для нее требованиям безопасности.

3.1.41    тестировщик (tester): Субъект, который выполняет тестирование.

4