Quality management systems. Requirements for enterprises of aviation, aerospace and defence industries. Deliverable software ГОСТ Р 56569-2015 Системы менеджмента качества. Требования к организациям авиационной, космической и оборонной промышленности. Поставляемое программное обеспечение / 56569 2015

     
ГОСТ Р 56569-2015

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

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

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

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


ОКС 01.120
         03.120     

         49.020

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

     
     

Предисловие

Предисловие

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

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

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

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

________________

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

           

Наименование настоящего стандарта изменено относительно наименования указанного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

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

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

6 ПЕРЕИЗДАНИЕ. Февраль 2020 г.



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



Введение

Введение


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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




Рисунок 1 - Модель системы менеджмента качества, основанной на процессном подходе

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

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

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


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

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

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



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

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

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



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

           

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

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

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

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

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

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

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

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



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

     
     

     1.2 Применение

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

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

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

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

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


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



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

     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.2 Документы IEEE


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

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



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


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

________________

Заменен на ISO/IEC/IEEE 12207:2017.



ISO/IEC 15288, Systems engineering - System life cycle processes (Системная инженерия. Процессы жизненного цикла систем)

________________

Заменен на ISO/IEC/IEEE 15288:2015.

           

     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 Термины и определения

     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.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 специальные требования: Требования, устанавливаемые потребителем или определяемые организацией, имеющие высокие риски невыполнения, что требует их включения в процесс управления рисками. Факторами, влияющими на отнесение требований к специальным, являются сложность продукции или процесса, прошлый опыт и освоенность продукции или отлаженность процесса. Примеры специальных требований включают в себя предельные относительно возможностей их выполнения эксплуатационные требования потребителя или требования организации, предельные по отношению к ее техническим или технологическим возможностям (SAE AS9100).

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

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

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



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

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

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



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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 - Документация может быть в любой форме и на любом носителе.



[SAE AS9100: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) обеспечение идентификации и управление рассылкой документов внешнего происхождения, определенных организацией как необходимые для планирования и функционирования системы менеджмента качества;

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

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


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

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

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

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

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

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

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

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

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

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

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



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

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


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



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

     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]


Необходимо применять требования 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) изменения, которые могли бы повлиять на систему менеджмента качества;

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

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


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

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

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

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

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

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

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


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



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

     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) где это возможно, обеспечивать подготовку или предпринимать другие действия в целях достижения необходимой компетентности;

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

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 Процессы жизненного цикла продукции
     

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

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

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

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

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

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

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

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

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

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

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



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) мониторинг, оценку и аудит программного обеспечения и связанной с ним деятельности;

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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) где применимо, управление и контроль неразрабатываемого программного обеспечения и программной поддержки;

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание 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) методы допуска изменений в требования, относящиеся к программному обеспечению.

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]


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

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

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



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]


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

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

7.3.6 Валидация проекта и разработки

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

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


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

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

7.3.6.1 Испытания для верификации и валидации проекта и разработки

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

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

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

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

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

e) соблюдены критерии приемки.

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


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

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

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



7.3.6.2 Документация верификации и валидации проекта и разработки

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

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


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

7.3.7 Управление изменениями проекта и разработки

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

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

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

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


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

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

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



     7.4 Закупки

7.4.1 Процесс закупок

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

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

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

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

           

Организация обязана:

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

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

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

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

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

f) выявлять риски и управлять рисками при выборе и привлечении поставщиков.

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


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

7.4.2 Информация по закупкам

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

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

b) квалификации персонала;

c) системе менеджмента качества;

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

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

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

g) в отношении обязанностей поставщика:

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

- получать одобрение организации в отношении действий с несоответствующей продукцией;

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

- передавать вниз по цепи поставки соответствующие требования, включая потребительские;

h) по сохранению записей;

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

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

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


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

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

7.4.3 Верификация закупленной продукции

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

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

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

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

- контроль и аудит на месте производства поставщика;

- проверку необходимой документации;

- входной контроль продукции;

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



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

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

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

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


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



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


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

7.5.1 Управление производством и обслуживанием

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

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

Примечание 1 - Эта информация может включать в себя чертежи, перечни деталей, спецификации на материалы и процессы;



b) наличие рабочих инструкций в случае необходимости.

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



c) применение подходящего оборудования.

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



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

e) проведение мониторинга и измерений;

f) осуществление выпуска, поставки и действий после поставки продукции;

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

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

i) меры по предотвращению попадания инородных тел, их обнаружению и удалению;

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

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

Если это необходимо, планирование должно учитывать:

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

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

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

- специальные процессы (см. 7.5.2).

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


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

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

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

7.5.1.1 Верификация производственного процесса

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

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



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


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

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



7.5.1.2 Управление изменениями производственного процесса

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

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

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

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


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

7.5.1.3 Контроль производственного оборудования, инструмента и программного обеспечения

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

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

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


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

Примечание - Репликация носителей данных описана в 7.1.3.1.



7.5.1.4 Обслуживание после поставки

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

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

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

c) контроль и обновление технической документации;

d) утверждение, контроль и использование ремонтных схем;

e) необходимые средства контроля в отношении работ, производимых вне организации (например, работ, осуществляемых на производстве потребителя).

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


Примечание - Схемы восстановления программного обеспечения упомянуты в 7.1.3 в части требований к управлению конфигурацией.



7.5.2 Валидация процессов производства и обслуживания

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

Примечание - Эти процессы часто называют специальными процессами.



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

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

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

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

c) применение конкретных методов и процедур;

d) требования к записям (см. 4.2.4);

e) повторную валидацию.

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


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

7.5.3 Идентификация и прослеживаемость

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

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

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

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

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

Примечание 1 - Требования по прослеживаемости могут включать в себя:

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

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

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

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

Примечание 2 - В ряде отраслей промышленности управление конфигурацией является средством поддержания идентификации и прослеживаемости (см. 7.1.3).



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


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

7.5.4 Собственность потребителей

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

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



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


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

7.5.5 Сохранение соответствия продукции

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

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

a) по очистке;

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

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

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

e) контролю за сроками хранения и обновления запасов;

f) особому обращению с опасными материалами.

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


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

a) архивирование и восстановление;

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

c) устаревание носителей;

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

e) кодирование/декодирование;

f) сжатие/распаковку данных;

g) защиту от программных вирусов и преднамеренных негативных действий;

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



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

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

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

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

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

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

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

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

b) отрегулировано или повторно отрегулировано по мере необходимости;

c) идентифицировано в целях установления статуса калибровки;

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

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

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

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

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

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

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



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


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

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



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

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

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

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

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

b) обеспечения соответствия системы менеджмента качества;

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

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

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

- верификации конструкции (например, надежности, ремонтопригодности, безопасности);

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

- проверки;

- анализа характера, последствий и критичности отказов (FMEA).



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


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



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

8.2.1 Удовлетворенность потребителей

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

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

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



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


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

8.2.2 Внутренние аудиты (проверки)

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

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

Примечание 1 - Запланированные мероприятия включают в себя контрактные требования потребителя;



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

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

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

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

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

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



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


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

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



8.2.3 Мониторинг и измерение процессов

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

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



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

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

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

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

d) идентифицировать всю несоответствующую продукцию и управлять ею (см. 8.3).

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


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

8.2.4 Мониторинг и измерение продукции

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

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

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

a) критерии приемки и/или отклонения;

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

c) требуемые записи результатов измерений (как минимум, отметку о приемке или отклонении);

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

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

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

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

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

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

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

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

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


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



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

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

Примечание 1 - Термин "несоответствующая продукция" включает в себя и несоответствующую продукцию, возвращенную потребителем.



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

Если применимо, организация должна предпринимать в отношении несоответствующей продукции следующие действия (одно или несколько):

a) устранение обнаруженного несоответствия;

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

c) предотвращение ее первоначального предполагаемого использования или применения;

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

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

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



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

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

Примечание 3 - Уполномоченным представителем является лицо, имеющее делегированные полномочия от проектной организации.



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

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

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

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

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


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

a) ведение записей о выявленных несоответствиях;

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

c) оценку и ранжирование несоответствий;

d) уведомление ответственных сторон для обеспечения необходимой прослеживаемости при принятии решений;

e) методы верификации модификации продукции;

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

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

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

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

- использование в качестве соответствующей продукции после дополнения требований;

- изъятие продукции.

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



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

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

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

a) к удовлетворенности потребителей (см. 8.2.1);

b) соответствию требованиям к продукции (см. 8.2.4);

c) характеристикам и тенденциям процессов и продукции, включая возможности проведения предупреждающих действий (см. 8.2.3 и 8.2.4);

d) поставщикам (см. 7.4).

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


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



     8.5 Улучшение

8.5.1 Постоянное улучшение

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

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

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



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


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

8.5.2 Корректирующие действия

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

Должна быть разработана документированная процедура для определения требований:

a) к анализу несоответствий (включая жалобы потребителей);

b) установлению причин несоответствий;

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

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

e) записям результатов предпринятых действий (см. 4.2.4);

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

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

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

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

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


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

8.5.3 Предупреждающие действия

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

Должна быть разработана документированная процедура для определения требований:

a) к установлению потенциальных несоответствий и их причин;

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

c) определению и осуществлению необходимых действий;

d) записям результатов предпринятых действий (см. 4.2.4);

е) анализу результативности предпринятых предупреждающих действий.

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



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


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



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

Приложение ДА
(справочное)

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

           

Таблица ДА.1

Обозначение ссылочного стандарта

Степень соответствия

Обозначение и наименование соответствующего национального стандарта

SAE AS9006
     

-

*

SAE AS9100:2009
     

-

*

IEEE-STD-610.12-1990
     

-

*

IEEE-STD-982.1-1998
     

-

*

ISO/IEC 12207:1995

-

*,

________________

Действует ГОСТ Р ИСО/МЭК 12207-2010 "Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств", идентичный ISO/IEC 12207:2008.



ISO/IEC 15288

IDT

ГОСТ Р ИСО/МЭК 15288-2005 "Информационная технология. Системная инженерия. Процессы жизненного цикла систем"

________________

Действует ГОСТ Р 57193-2016 "Системная и программная инженерия. Процессы жизненного цикла систем", не эквивалентный ISO/IEC/IEEE 15288:2015.





RTCA/DO-178,
EUROCAE ED-12
     

-

*

RTCA/DO-254,
EUROCAE ED-80
     

-

*

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

Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов:

- IDT - идентичные стандарты.



                

УДК [004.4+658.5+62]:006.354

ОКС 01.120

         03.120

         49.020

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