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

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

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

СИСТЕМЫ МЕНЕДЖМЕНТА КАЧЕСТВА

Требования к организациям авиационной, космической и оборонной промышленности

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

Предисловие

1    ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием «Научно-исследовательский институт стандартизации и унификации» (ФГУП «НИИСУ») на основе собственного перевода на русский язык стандарта, указанного в пункте 4

2    ВНЕСЕН Управлением технического регулирования и стандартизации Федерального агентства по техническому регулированию и метрологии

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

4    Настоящий стандарт идентичен международному стандарту SAE AS9115 «Системы менеджмента качества. Требования к организациям авиационной, космической и оборонной промышленности. Поставляемое программное обеспечение» (SAE AS9115 «Quality management systems. Requirements for aviation, space and defense organizations. Deliverable software»)

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

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

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

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

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

таких факторов, как:

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

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

c)    возможность обеспечения необходимого управления посредством применения требований 7.4.

[SAE AS9100:2009, пункт 4.1]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

4.2 Требования к документации

4.2.1    Общие положения

Документация системы менеджмента качества должна включать в себя:

a)    документально оформленные заявления о политике и целях в области качества;

b)    руководство по качеству;

c)    документированные процедуры и записи, требуемые настоящим стандартом;

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

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

Примечание 1 — Если в настоящем стандарте встречается термин «документированная процедура», это означает, что процедура разработана, документально оформлена, внедрена и поддерживается в рабочем состоянии. Один документ может содержать требования одной или более процедуры. Требование о наличии документированной процедуры может быть реализовано более чем одним документом.

Примечание 2    —    Степень    документированное™    системы менеджмента качества одной

организации может отличаться от степени документированное™ другой в зависимости:

a)    от размера организации и вида деятельности;

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

c)    компетентности персонала.

Примечание 3 — Документация может быть в любой форме и на любом носителе.

[SAEAS9100:2009, пункт 4.2.1]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

4.2.2    Руководство по качеству

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

a)    область применения системы менеджмента качества, включая подробности и обоснование любых исключений (см. 1.2);

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

c)    описание взаимодействия процессов системы менеджмента качества.

[SAE AS9100:2009, пункт 4.2.2]

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

4.2.3    Управление документацией

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

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

a)    официальное одобрение документов с точки зрения их достаточности до выпуска;

b)    анализ и актуализацию по мере необходимости и повторное официальное одобрение документов;

c)    обеспечение идентификации изменений и статуса пересмотра документов;

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

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

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

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

[SAE AS9100:2009, пункт 4.2.31__

ГОСТ Р 56569-2015

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

4.2.4 Управление записями

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

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

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

Примечание — Записи включают в себя (но не ограничиваются этим):

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

b)    сертификаты соответствия (изготовителя, субпоставщика), копии сертификатов летной годности;

c)    записи о несоответствии, разрешении использовать продукцию с отклонениями и корректирующих

действиях;

d)    записи, обеспечивающие прослеживаемость партий продукции;

e)    сведения об условиях или сроках хранения продукции.

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

[SAE AS9100:2009, пункт 4.2.4]_

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

5 Ответственность руководства

5.1    Обязательства руководства

Руководство должно обеспечивать наличие свидетельств принятия своих обязательств по разработке и внедрению системы менеджмента качества, а также постоянному улучшению ее результативности посредством:

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

b)    разработки политики в области качества;

c)    обеспечения разработки целей в области качества;

d)    проведения анализа со стороны руководства;

e)    обеспечения необходимыми ресурсами.

[SAE AS9100:2009, пункт 5.1]_

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

5.2    Ориентация на потребителя

Руководство должно обеспечивать определение и выполнение требований потребителей для повышения их удовлетворенности (см. 7.2.1 и 8.2.1).

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

[SAE AS9100:2009, пункт 5.2]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

5.3    Политика в области качества

Руководство должно обеспечивать, чтобы политика в области качества:

a)    соответствовала целям организации;

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

c)    создавала основы для постановки и анализа целей в области качества;

d)    была доведена до сведения персонала организации и понятна ему;

e)    анализировалась на постоянную пригодность.

[SAE AS9100:2009, пункт 5.3]

7

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

5.4    Планирование

5.4.1    Цели в области качества

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

[SAE AS9100:2009, пункт 5.4.1]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

5.4.2    Планирование системы менеджмента качества

Высшее руководство должно обеспечивать:

a)    планирование создания, поддержания и улучшения системы менеджмента качества для выполнения требований 4.1, а также для достижения целей в области качества;

b)    сохранение целостности системы менеджмента качества при планировании и внедрении в нее изменений.

[SAE AS9100:2009, пункт 5.4.2]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

5.5    Ответственность, полномочия и обмен информацией

5.5.1    Ответственность и полномочия

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

[SAE AS9100:2009, пункт 5.5.1]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

5.5.2    Представитель руководства

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

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

b)    представление отчетов руководству о функционировании системы менеджмента качества и необходимости ее улучшения;

c)    содействие распространению понимания требований потребителей по всей организации;

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

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

[SAE AS9100:2009, пункт 5.5.2]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

5.5.3    Внутренний обмен информацией

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

[SAE AS9100:2009, пункт 5.5.3]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

5.6    Анализ со стороны руководства

5.6.1 Общие положения

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

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

Записи об анализе со стороны руководства должны поддерживаться в рабочем состоянии (см. 4.2.4).

[SAE AS9100:2009, пункт 5.6.1]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

5.6.2    Входные данные для анализа

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

a)    результаты аудитов (проверок);

b)    обратную связь от потребителей;

c)    функционирование процессов и соответствие продукции;

d)    статус предупреждающих и корректирующих действий;

e)    последующие действия, как следствия проведения предыдущих анализов со стороны руководства;

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

д) рекомендации по улучшению.

[SAE AS9100:2009, пункт 5.6.2]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

5.6.3    Выходные данные анализа

Выходные данные анализа со стороны руководства должны включать в себя все решения и действия, относящиеся:

a)    к повышению результативности системы менеджмента качества и ее процессов;

b)    улучшению продукции по отношению к требованиям потребителей;

c)    потребности в ресурсах.

[SAE AS9100:2009, пункт 5.6.3]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

6 Менеджмент ресурсов

6.1    Обеспечение ресурсами

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

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

b)    для повышения удовлетворенности потребителей путем выполнения их требований.

[SAE AS9100:2009, пункт 6.1]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

6.2    Человеческие ресурсы

6.2.1    Общие положения

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

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

[SAE AS9100:2009, пункт 6.2.1]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

6.2.2    Компетентность, подготовка и осведомленность

Организация должна:

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

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

_с) оценивать результативность принятых мер;_

9

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

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

[SAE AS9100:2009, пункт 6.2.2]

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

6.3    Инфраструктура

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

a)    здания, рабочее пространство и связанные с ним средства труда;

b)    оборудование для процессов (как технические, так и программные средства);

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

[SAE AS9100:2009, пункт 6.3]

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

Подобная инфраструктура может включать в себя, если применимо:

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

b)    инструменты верификации программного обеспечения, в том числе тестовое оборудование и тестовое программное обеспечение;

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

d)    инструменты и утилиты верификации целостности (например, проверка/защита от вирусов, электронно-цифровые подписи, алгоритмы криптографического хеширования, циклические избыточные коды);

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

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

6.4    Производственная среда

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

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

[SAE AS9100:2009, пункт 6.4]_

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

7 Процессы жизненного цикла продукции

7.1 Планирование процессов жизненного цикла продукции

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

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

а) цели в области качества и требования к продукции.

Примечание — Цели в области качества и требования к продукции включают в себя рассмотрение

таких аспектов, как:

- безопасность продукции и персонала;

_- надежность, доступность и ремонтопригодность;_

10

ГОСТ P 56569—2015

-технологичность и контролепригодность;

-    пригодность деталей и материалов, используемых в продукции;

-    выбор и совершенствование встроенного программного обеспечения;

-    переработка или утилизация продукции после окончания срока ее службы;

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

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

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

e)    управление конфигурацией, соответствующее продукции;

f)    ресурсы, необходимые при эксплуатации и техническом обслуживании продукции.

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

организации.

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

Примечание 2 — При разработке процессов жизненного цикла продукции организация может также применять требования 7.3.

[SAE AS9100:2009, пункт 7.1]_

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

a)    цели в области качества и требования, выраженные в измеримых показателях, включая ключевые характеристики и критичные показатели;

b)    жизненный цикл программного обеспечения;

c)    идентификацию, квалификацию, выбор и управление поставщиками;

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

e)    необходимые средства инфраструктуры (см. 6.3);

f)    мониторинг, оценку и аудит программного обеспечения и связанной с ним деятельности;

д) уровень критичности программного обеспечения, основанный на «вкладе» программного обеспечения в потенциальные состояния отказов;

h)    требования к безопасности и защите продукции и данных;

i)    стандарты (например, стандарты разработки и кодирования), правила, практики, соглашения, техники и методологии разработки и тестирования;

j)    инструменты, шаблоны, вспомогательные средства;

k)    распределение задач и ответственности между заинтересованными сторонами;

l)    установку и поддержку продукта;

т) верификацию, валидацию, приемку и поставку продукции;

п) авторские права, лицензионные соглашения, права интеллектуальной собственности, экспортный контроль.

7.1.1    Управление проектом

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

[SAEAS9100:2009, пункт 7.1.1]_

Необходимо применять требования SAE AS9100 со следующими разъяснениями для программного обеспечения.

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

7.1.2    Управление рисками

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

11

ГОСТ Р 56569-2015

a)    распределение ответственности по управлению рисками;

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

c)    идентификацию, оценку и передачу информации о рисках на всех этапах жизненного цикла продукции;

d)    идентификацию, осуществление и управление действиями по снижению рисков, которые превышают определенный критерий принятия риска;

e)    принятие рисков, оставшихся после осуществления действий по их снижению.

[SAE AS9100:2009, пункт 7.1.2]

Необходимо применять требования SAE AS9100 со следующими разъяснениями для программного обеспечения.

Управление рисками должно отражать специальные требования (см. 3.19) к программному обеспечению.

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

7.1.3 Управление конфигурацией

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

a)    планирование управления конфигурацией;

b)    идентификацию конфигурации;

c)    управление изменениями;

d)    учет статуса конфигурации;

e)    аудит конфигурации.

Примечание — См. ИСО 10007 для руководства.

[SAE AS9100:2009, пункт 7.1.3]_

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

7.1.3.1    Планирование управления конфигурацией

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

a)    распределение задач и ответственности в управлении конфигурацией;

b)    деятельность по управлению конфигурацией, графики и записи;

c)    критерии и руководящие указания по верификации и валидации изменений;

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

e)    критерии, при которых элементы конфигурации попадают под управление изменениями;

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

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

h)    процессы сохранения соответствия продукции согласно 7.5.5;

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

j)    период сохранения, изъятия, устаревания и уничтожения программных продуктов.

Планирование также должно обеспечивать, чтобы следующие положения

принимались во внимание при процессах репликации:

k)    идентификация мастер-копии и копий, включая формат и версию;

l)    тип носителя программного продукта и соответствующая ему маркировка;

т) управление условиями внешней среды, при которых осуществляется репликация для обеспечения повторяемости;

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

7.1.3.2    Идентификация конфигурации

Идентификация конфигурации должна обеспечить процесс уникальной идентификации элементов конфигурации программного обеспечения на протяжении всего жизнен-

ГОСТ Р 56569-2015

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

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

7.1.3.3    Управление изменениями

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

a)    уникальной идентификации версии каждого элемента конфигурации;

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

c)    управления доступом или изменениями контролируемых элементов;

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

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

7.1.3.4    Учет статуса конфигурации

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

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

b)    запросам на изменения и внедрению утвержденных изменений;

c)    каждой формальной базовой версии программного обеспечения, включая:

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

-    вспомогательное программное обеспечение;

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

-    изменение или сводный отчет о проблеме;

-    соответствующую программную документацию для конкретной версии;

-    процедуры и результаты тестирования;

-    соответствующие инструменты разработки и верификации;

-    интерфейсы с другими программными продуктами и целевым компьютерным аппаратным обеспечением;

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

ф версиям программного обеспечения и различиям между этими версиями.

7.1.3.5    Аудит конфигурации

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

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

b)    все отчеты о проблемах и запросы на изменения идентифицированы и управляются;

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

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

e)    программное обеспечение может быть загружено в целевой компьютер и инициализировано;

f)    программное обеспечение было протестировано и принято в соответствии с требованиями;

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

h)    программное обеспечение и его носители должным образом идентифицированы;

i)    программное обеспечение и его носители не повреждены;

j)    программное обеспечение и его носители защищены от вредоносных программ (например, вирусов);

k)    исходный код идентифицирован и находится под управлением конфигурацией.

13

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

Примечание 2 — Аудит процессов в системе управления конфигурацией может быть составной частью внутреннего аудита (8.2.2) и/или запланированной деятельности по аудиту, определенной в 7.1.

7.1.4 Управление передачей работ

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

[SAE AS9100:2009, пункт 7.1.4]_

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

7.2 Процессы, связанные с потребителями

7.2.1    Определение требований, относящихся к продукции

Организация должна определить:

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

b)    требования, не определенные потребителем, но необходимые для конкретного или предполагаемого использования, когда оно известно;

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

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

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

требования.

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

[SAE AS9100:2009, пункт 7.2.1]_

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

7.2.2    Анализ требований, относящихся к продукции

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

a)    определение требований к продукции;

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

c)    способность организации выполнять определенные требования;

d)    определение специальных требований к продукции;

e)    идентификацию рисков (например, новые технологии, сжатые сроки поставки).

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

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

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

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

[SAE AS9100:2009, пункт 7.2.2]_

Процесс анализа требований в организации должен включать в себя:

a)    взаимодействие с заинтересованными сторонами;

b)    методы согласования требований и уровней прослеживаемости;

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

ГОСТ Р 56569-2015

7.2.3 Связь с потребителями

Организация должна определять и осуществлять эффективные меры по поддержанию связи с потребителями, касающиеся:

a)    информации о продукции;

b)    прохождения запросов, контракта или заказа, включая поправки;

c)    обратной связи от потребителей, включая жалобы потребителей.

[SAE AS9100:2009, пункт 7.2.3]_

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

7.3 Проектирование и разработка

7.3.1    Планирование проектирования и разработки

Организация должна планировать проектирование и разработку и управлять этими процессами.

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

a)    стадии проектирования и разработки;

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

c)    ответственность и полномочия в области проектирования и разработки.

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

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

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

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

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

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

[SAE AS9100:2009, пункт 7.3.1]

Планирование проектирования и разработки должно включать в себя:

a)    определение и управление входными и выходными критериями, связанными с ними входами и выходами, в том числе документации по каждому этапу проектирования и разработки;

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

7.3.2    Входные данные для проектирования и разработки

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

Входные данные должны включать в себя:

a)    функциональные и эксплуатационные требования;

b)    соответствующие законодательные и другие обязательные требования;

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

d)    другие требования, важные для проектирования и разработки.

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

[SAE AS9100:2009, пункт 7.3.2]_

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

ГОСТ Р 56569-2015

Содержание

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

1.1    Общие положения................................................................................................................................1

1.2    Применение...........................................................................................................................................2

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

2.1    Документы SAE.....................................................................................................................................2

2.2    Документы IEEE....................................................................................................................................3

2.3    Документы ИСО....................................................................................................................................3

2.4    Документы RTCA..................................................................................................................................3

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

4    Система менеджмента качества.................................................................................................................5

4.1    Общие требования...............................................................................................................................5

4.2    Требования к документации................................................................................................................6

5    Ответственность руководства.....................................................................................................................7

5.1    Обязательства руководства................................................................................................................7

5.2    Ориентация на потребителя................................................................................................................7

5.3    Политика в области качества..............................................................................................................7

5.4    Планирование.......................................................................................................................................8

5.5    Ответственность, полномочия и обмен информацией.....................................................................8

5.6    Анализ со стороны руководства..........................................................................................................8

6    Менеджмент ресурсов..................................................................................................................................9

6.1    Обеспечение ресурсами......................................................................................................................9

6.2    Человеческие ресурсы.........................................................................................................................9

6.3    Инфраструктура..................................................................................................................................10

6.4    Производственная среда...................................................................................................................10

7    Процессы жизненного цикла продукции...................................................................................................10

7.1    Планирование процессов жизненного цикла продукции.................................................................10

7.2    Процессы, связанные с потребителями...........................................................................................14

7.3    Проектирование и разработка...........................................................................................................15

7.4    Закупки.................................................................................................................................................18

7.5    Производство и обслуживание..........................................................................................................20

7.6    Управление оборудованием для мониторинга и измерений..........................................................23

8    Измерение, анализ и улучшение...............................................................................................................24

8.1    Общие положения..............................................................................................................................24

8.2    Мониторинг и измерение....................................................................................................................24

8.3    Управление несоответствующей продукцией..................................................................................26

8.4    Анализ данных....................................................................................................................................27

8.5    Улучшение...........................................................................................................................................27

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

региональных стандартов ссылочным национальным стандартам

Российской Федерации.....................................................................................................29

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

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

7.3.3    Выходные данные проектирования и разработки

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

Выходные данные проектирования и разработки должны:

a)    соответствовать входным требованиям к проектированию и разработке;

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

c)    содержать критерии приемки продукции или ссылки на них;

d)    определять характеристики продукции, существенные для ее безопасного и правильного использования;

e)    определять все соответствующие критические элементы, включая все ключевые характеристики, и особые действия, которые необходимо предпринять в отношении этих элементов.

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

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

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

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

[SAE AS9100:2009, пункт 7.3.3]

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

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

7.3.4    Анализ проекта и разработки

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

a)    оценки способности результатов проектирования и разработки удовлетворять требованиям;

b)    выявления любых проблем и внесения предложений по необходимым действиям;

c)    принятия решения о переходе к следующей стадии.

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

[SAE AS9100:2009, пункт 7.3.4]_

Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.

7.3.5    Верификация проекта и разработки

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

[SAE AS9100:2009, пункт 7.3.5]

16

Введение

Общие положения

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

Настоящий стандарт — это первая редакция, представляющая собой разъяснения к соответствующим требованиям стандарта SAE AS9100, применяемым поставщиками программного обеспечения. В некоторых случаях, при необходимости, в связи со сложностью программного обеспечения потребовалось произвести декомпозицию обязательных требований (формулировки «должен») в более подробные требования. В тех случаях, когда дополнительные разъяснения, связанные со спецификой программного обеспечения, не требуются, в настоящем стандарте использована следующая фраза: «Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет».

Процессный подход

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

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

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

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

При применении в системе менеджмента качества такой подход подчеркивает важность:

a)    понимания и выполнения требований;

b)    необходимости рассмотрения процессов сточки зрения добавляемой ими ценности;

c)    достижения запланированных результатов выполнения процессов и обеспечения их результативности;

d)    постоянного улучшения процессов, основанного на объективном измерении.

Приведенная на рисунке 1 модель системы менеджмента качества, основанной на процессном

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

Примечание — Кроме того, ко всем процессам может быть применен цикл «Plan-Do-Check-Act» (PDCA). Цикл PDCA можно кратко описать следующим образом:

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

-    осуществление (do) — внедрение процессов;

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

-    действие (act) — принятие действий по постоянному улучшению показателей процессов.

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

СИСТЕМЫ МЕНЕДЖМЕНТА КАЧЕСТВА Требования к организациям авиационной, космической и оборонной промышленности Поставляемое программное обеспечение

Quality management systems. Requirements for enterprises of aviation, aerospace and defence industries.

Deliverable software

Дата введения — 2016—07—01

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

1.1 Общие положения

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

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

Примечание 1 — В отношении бортового электронного оборудования наведения рекомендуется использовать RTCA/DO-254 или EUROCAE ED-80; в отношении требований к созданию продукции - SAE AS9100.

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

Для целей настоящего стандарта термин «продукт» и термин «продукт программного обеспечения» считаются синонимами.

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

Настоящий стандарт включает в себя требования к системе менеджмента качества, установленные в SAE AS9100, и выделенные полужирным курсивом требования, определения и примечания, специфические для программного обеспечения.

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

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

ГОСТ P 56569—2015

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

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

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

Примечание 1 — В настоящем стандарте термин «продукция» применим только:

a)    к предназначаемой для потребителя или затребованной им продукции;

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

Примечание 2 — Законодательные и другие обязательные требования могут быть выражены как правовые требования.

[SAE AS9100:2009, пункт 1.1]

1.2 Применение

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

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

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

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

[SAE AS9100:2009, пункт 1.21_

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

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

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

В настоящем стандарте использованы нормативные ссылки на следующие документы:

2.1 Документы SAE

SAE AS9006 Deliverable Aerospace Software Supplement for AS9100A, Quality Management Systems — Aerospace — Requirements for Software (Программное обеспечение, поставляемое для аэрокосмической промышленности. Дополнение к стандарту AS9100A «Системы менеджмента качества. Аэрокосмическая отрасль. Требования к программному обеспечению»)

Примечание 1 — Требования SAE AS9100 применяются со следующими разъяснениями для программного обеспечения.

SAE AS9100:2009 Quality Management Systems — Requirements for Aviation, Space and Defense Organizations (Системы менеджмента качества. Требования к организациям авиационной, космической и оборонной отраслей)

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

2

ГОСТ P 56569—2015

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

2.2    Документы IEEE

IEEE-STD-610.12—1990 Standard Glossary of Software Engineering Terminology (Стандартный глоссарий терминов в области разработки программного обеспечения)

IEEE-STD-982.1—1998 IEEE Standard Dictionary of Measures to Produce Reliable Software (IEEE Стандартный справочник действий по производству надежного программного обеспечения)

2.3    Документы ИСО

ИСО/МЭК 12207:1995 Information technology - Software life cycle processes (Информационная технология. Процессы жизненного цикла программных средств)

ИСО/МЭК 15288 Systems engineering - System life cycle processes (Системная инженерия. Процессы жизненного цикла систем)

2.4    Документы RTCA

RTCA/DO-178, EUROCAE ED-12 Software Considerations in Airborne Systems and Equipment Certification (Обзор программного обеспечения в бортовых электронных системах и сертификация оборудования)

RTCA/DO-254, EUROCAE ED-80 Design Assurance Guidance for Airborne Electronic Hardware (Обеспечение надежности конструкции в бортовом электронном оборудовании)

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

В настоящем стандарте применены термины и определения, содержащиеся в SAE AS9100 и ИСО 9000, а также следующие термины с соответствующими определениями:

3.1    базовая версия: Утвержденная зарегистрированная конфигурация одной или нескольких единиц конфигурации, которая используется в качестве базы для дальнейшей разработки и изменяется только посредством процедуры управления изменениями (RTCA/DO-178, EUROCAE ED-12).

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

Примечание — Имеющиеся на рынке программные средства являются видом неразрабатываемого программного обеспечения.

3.3    элемент конфигурации: Один или несколько компонентов программного или аппаратного обеспечения, которые в целях управления конфигурацией рассмотрены в качестве единого целого, либо данные жизненного цикла программного обеспечения, которые в целях управления конфигурацией рассмотрены в качестве единого целого (RTCA/DO-178, EUROCAE ED-12).

3.4    критические элементы: Применяется формулировка, приведенная в стандарте SAE AS9100, пункт 3.3, со следующими разъяснениями для программного обеспечения. Критические элементы программного обеспечения представляют собой характеристики, требования или свойства, определенные как наиболее важные для достижения устойчивого жизненного цикла продукта (например, безопасность, удобство обслуживания, тестопригодность, практичность, эффективность). Критические элементы необходимо надлежащим образом контролировать и принимать соответствующие действия для обеспечения их различимости на протяжении жизненного цикла продукта. Например, в программном обеспечении системы управления полетами время отклика можно сделать критическим элементом с целью обеспечения соответствия характеристикам эффективности. Более того, если проект характеризуется специфическими требованиями тестопригодности, цикломатическая сложность может стать критическим элементом.

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

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

3.7    ключевая характеристика: Применяется формулировка, приведенная в стандарте SAE AS9100, пункт 3.4, со следующими разъяснениями для программного обеспечения. Ключевые характеристики в программном обеспечении представляют собой поддающиеся измерению качества, переменчивость которых можно измерить в рамках проекта, а если их оставить без внимания, они способны оказать неблагоприятное воздействие на проект или продукт в различных областях

3

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

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

Мониторинг обычно ассоциируется с видами деятельности, выполняемыми в течение продолжительного периода времени, в рамках которых стопроцентное наблюдение считается непрактичным или не имеющим необходимости. В рамках мониторинга допускается подтверждение, что указанная деятельность была выполнена согласно плану (RTCA/DO-178, EUROCAE ED-12).

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

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

3.11    выпуск: Определенная версия элемента конфигурации, выпущенная с конкретной целью (например, пробный выпуск) (ИСО/МЭК 12207).

3.12    надежность: Вероятность безотказной эксплуатации компьютерной программы в конкретных условиях в течение определенного периода времени (на основании IEEE-STD-982.1).

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

3.13    риск: Применяется формулировка, приведенная в стандарте SAE AS9100, пункт 3.1. Дополнительных разъяснений для программного обеспечения не требуется.

3.14    выносливость: Рамки, в которых программное обеспечение способно продолжать корректную работу, несмотря на ошибочные вводные данные (RTCA/DO-178, EUROCAE ED-12).

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

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

3.16    программное обеспечение: Компьютерные программы, сопутствующая документация и данные, относящиеся к эксплуатации компьютерной системы (на основании RTCA/DO-178, EUROCAE ED-12).

Примечание 1    — В приведенную формулировку входят исполнимые программы и данные,

заключенные в аппаратных устройствах (т. е. встроенные программы).

Примечание 2    — Встроенные программы представляют собой совокупность аппаратного

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

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

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

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

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

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

4

ГОСТ P 56569—2015

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

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

3.20    заинтересованная сторона: Сторона, обладающая правом, долей или притязаниями в системе или на владение ее характеристиками, отвечающими потребностям и ожиданиям стороны (ИСО/МЭК 15288).

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

3.21    программная поддержка: Программное обеспечение, задействованное при разработке и обслуживании другого программного обеспечения (например, компилирующие программы, загрузчики, прочие служебные программы) (IEEE-STD-610.12).

3.22    валидация: Подтверждение соответствия определенным требованиям в рамках конкретного целевого назначения посредством проверки и предоставления объективного свидетельства (ИСО/МЭК 12207).

Примечание — Валидация предполагает, что «построен правильный элемент».

3.23    верификация: Подтверждение соответствия установленным требованиям посредством проверки и предоставления объективного свидетельства (ИСО/МЭК 12207).

Примечание — Верификация предполагает, что «элемент построен правильно».

4 Система менеджмента качества

4.1 Общие требования

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

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

Организация должна:

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

b)    определять последовательность и взаимодействие этих процессов;

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

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

e)    осуществлять мониторинг, измерение, там, где это возможно, и анализ этих процессов;

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

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

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

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

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

Примечание 3 — Обеспечение управления процессами, переданными сторонним организациям, не освобождает организацию от ответственности за соответствие всем требованиям потребителей и обязательным гребованиям. Выбор вида и степени управления процессом, переданным сторонней организации, зависит от

5