ГОСТ Р 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")
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных и региональных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА
5 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012** (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 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, и выделенные полужирным курсивом* требования, определения и примечания, специфические для программного обеспечения.
________________
* В бумажном оригинале обозначения и номера стандартов и нормативных документов приводятся обычным шрифтом, кроме отмеченного в разделе "Предисловие" знаком "**". - .
Необходимо обратить внимание на то, что требования, установленные в настоящем стандарте, являются дополнительными (не альтернативными) по отношению к контрактным и действующим законодательным и другим обязательным требованиям. В случае противоречия между требованиями настоящего стандарта и действующими законодательными и другими обязательными требованиями последние имеют приоритет.
Настоящий стандарт устанавливает требования к системе менеджмента качества в тех случаях, когда организация: |
1.2 Применение
Требования настоящего стандарта являются общими и предназначены для применения всеми организациями независимо от их вида, размера и поставляемой продукции. |
Исключения из требований раздела 7 должны приниматься только после анализа характеристик программного обеспечения (например, размер, безопасность, защищенность, сложность, критичность, риск).
2 Нормативные ссылки
Настоящий стандарт разработан на основе приведенных ниже документов, использованных применительно к соответствующей области распространения. При пользовании настоящим стандартом должны быть применены последние опубликованные редакции документов SAE. Применение редакций остальных приведенных документов должно зависеть от срока приобретения данных публикаций. При наличии противоречий между текстом настоящего стандарта и приведенными ниже документами приоритетным считается текст настоящего стандарта. При этом требования настоящего стандарта не заменяют применимые правовые нормы и нормативные требования, кроме случаев специфичных исключений.
В настоящем стандарте использованы нормативные ссылки на следующие документы*:
________________
* Таблицу соответствия национальных стандартов международным см. по ссылке. - .
2.1 Документы SAE
SAE AS9006 Deliverable Aerospace Software Supplement for AS9100A, Quality Management Systems - Aerospace - Requirements for Software (Программное обеспечение, поставляемое для аэрокосмической промышленности. Дополнение к стандарту AS9100A "Системы менеджмента качества. Аэрокосмическая отрасль. Требования к программному обеспечению")
Примечание 1 - Требования SAE AS9100 применяются со следующими разъяснениями для программного обеспечения.
SAE AS9100:2009 Quality Management Systems - Requirements for Aviation, Space and Defense Organizations (Системы менеджмента качества. Требования к организациям авиационной, космической и оборонной отраслей)
Примечание 2 - При наличии недатированных ссылок необходимо применять последнюю опубликованную редакцию ссылочного документа, включая дополнения. Ссылочные документы носят информационный характер, требования ссылочных документов не являются дополнительными требованиями настоящего стандарта.
2.2 Документы IEEE
IEEE-STD-610.12-1990 Standard Glossary of Software Engineering Terminology (Стандартный глоссарий терминов в области разработки программного обеспечения)
IEEE-STD-982.1-1998 IEEE Standard Dictionary of Measures to Produce Reliable Software (IEEE Стандартный справочник действий по производству надежного программного обеспечения)
2.3 Документы ИСО
ИСО/МЭК 12207:1995 Information technology - Software life cycle processes (Информационная технология. Процессы жизненного цикла программных средств)
ИСО/МЭК 15288 Systems engineering - System life cycle processes (Системная инженерия. Процессы жизненного цикла систем)
2.4 Документы RTCA
RTCA/DO-178, EUROCAE ED-12 Software Considerations in Airborne Systems and Equipment Certification (Обзор программного обеспечения в бортовых электронных системах и сертификация оборудования)
RTCA/DO-254, EUROCAE ED-80 Design Assurance Guidance for Airborne Electronic Hardware (Обеспечение надежности конструкции в бортовом электронном оборудовании)
3 Термины и определения
В настоящем стандарте применены термины и определения, содержащиеся в SAE AS9100 и ИСО 9000, а также следующие термины с соответствующими определениями:
3.1 базовая версия: Утвержденная зарегистрированная конфигурация одной или нескольких единиц конфигурации, которая используется в качестве базы для дальнейшей разработки и изменяется только посредством процедуры управления изменениями (RTCA/DO-178, EUROCAE ED-12).
3.2 имеющиеся на рынке программные средства: Имеющиеся на рынке программные приложения, продаваемые поставщиками по общедоступным каталогам. Имеющиеся на рынке программные средства не модифицируются в соответствии с требованиями заказчика и не усовершенствуются под конкретный заказ. Программное обеспечение, созданное по контракту для конкретного применения, не является имеющимися на рынке программными средствами.
Примечание - Имеющиеся на рынке программные средства являются видом неразрабатываемого программного обеспечения.
3.3 элемент конфигурации: Один или несколько компонентов программного или аппаратного обеспечения, которые в целях управления конфигурацией рассмотрены в качестве единого целого, либо данные жизненного цикла программного обеспечения, которые в целях управления конфигурацией рассмотрены в качестве единого целого (RTCA/DO-178, EUROCAE ED-12).
3.4 критические элементы: Применяется формулировка, приведенная в стандарте SAE AS9100, пункт 3.3, со следующими разъяснениями для программного обеспечения. Критические элементы программного обеспечения представляют собой характеристики, требования или свойства, определенные как наиболее важные для достижения устойчивого жизненного цикла продукта (например, безопасность, удобство обслуживания, тестопригодность, практичность, эффективность). Критические элементы необходимо надлежащим образом контролировать и принимать соответствующие действия для обеспечения их различимости на протяжении жизненного цикла продукта. Например, в программном обеспечении системы управления полетами время отклика можно сделать критическим элементом с целью обеспечения соответствия характеристикам эффективности. Более того, если проект характеризуется специфическими требованиями тестопригодности, цикломатическая сложность может стать критическим элементом.
3.5 циклический избыточный код: Тип функции, принимающий в качестве вводной информации поток данных любой продолжительности и выдающий в качестве выходных данных определенное значение, обычно 32-битное число. Циклический избыточный код можно также использовать для определения изменения данных во время передачи или хранения.
3.6 электронная цифровая подпись: Тип ассиметричной криптограммы, применяемой для выражения соответствия характеристикам безопасности собственноручной подписи на бумаге. Также именуется схемой электронной подписи.
3.7 ключевая характеристика: Применяется формулировка, приведенная в стандарте SAE AS9100, пункт 3.4, со следующими разъяснениями для программного обеспечения. Ключевые характеристики в программном обеспечении представляют собой поддающиеся измерению качества, переменчивость которых можно измерить в рамках проекта, а если их оставить без внимания, они способны оказать неблагоприятное воздействие на проект или продукт в различных областях (например, график, стоимость, удобство обслуживания, тестопригодность, надежность, портативность). Примеры ключевых характеристик включают в себя степень серьезности дефекта, факторы сложности, вложенные меню, память, цикличность, время отклика и пропускную способность.
3.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.1 Общие требования
Организация должна разработать, задокументировать, внедрить и поддерживать в рабочем состоянии систему менеджмента качества и постоянно улучшать ее результативность в соответствии с требованиями настоящего стандарта. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
4.2 Требования к документации
4.2.1 Общие положения
Документация системы менеджмента качества должна включать в себя: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
4.2.2 Руководство по качеству
Организация должна разработать и поддерживать в рабочем состоянии руководство по качеству, содержащее: |
Руководство по качеству должно охватывать систему менеджмента качества применительно к программному обеспечению посредством включения или наличия ссылок.
4.2.3 Управление документацией
Документы системы менеджмента качества должны быть управляемыми. Записи, представляющие собой специальный вид документов, должны быть управляемыми согласно требованиям 4.2.4. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
4.2.4 Управление записями
Записи, установленные для представления свидетельств соответствия требованиям и результативного функционирования системы менеджмента качества, должны находиться под управлением. |
В том случае, если записи размещены на электронных носителях, в отношении данных о сроках хранения и доступности записей должны быть учтены степень ухудшения свойств электронных носителей информации, а также доступность оборудования и программного обеспечения, необходимых для доступа к указанным записям.
5 Ответственность руководства
5.1 Обязательства руководства
Руководство должно обеспечивать наличие свидетельств принятия своих обязательств по разработке и внедрению системы менеджмента качества, а также постоянному улучшению ее результативности посредством: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
5.2 Ориентация на потребителя
Руководство должно обеспечивать определение и выполнение требований потребителей для повышения их удовлетворенности (см. 7.2.1 и 8.2.1). |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
5.3 Политика в области качества
Руководство должно обеспечивать, чтобы политика в области качества: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
5.4 Планирование
5.4.1 Цели в области качества
Руководство организации должно обеспечивать, чтобы цели в области качества, включая необходимые для выполнения требований к продукции [см.7.1, перечисление а)], были установлены в соответствующих подразделениях и на соответствующих уровнях организации. Цели в области качества должны быть измеримыми и согласуемыми с политикой в области качества. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
5.4.2 Планирование системы менеджмента качества
Высшее руководство должно обеспечивать: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
5.5 Ответственность, полномочия и обмен информацией
5.5.1 Ответственность и полномочия
Руководство должно обеспечивать определение и доведение до сведения персонала организации ответственности и полномочий. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
5.5.2 Представитель руководства
Руководство должно назначить представителя из состава руководства организации, который независимо от других обязанностей должен нести ответственность и иметь полномочия, распространяющиеся: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
5.5.3 Внутренний обмен информацией
Высшее руководство должно обеспечивать установление в организации соответствующих процессов обмена информацией, включая информацию, относящуюся к результативности системы менеджмента качества. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
5.6 Анализ со стороны руководства
5.6.1 Общие положения
Руководство должно анализировать через запланированные интервалы времени систему менеджмента качества организации в целях обеспечения ее постоянной пригодности, достаточности и результативности. Этот анализ должен включать в себя оценку возможностей улучшений и потребности в изменениях в системе менеджмента качества организации, в том числе в политике и целях в области качества. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
5.6.2 Входные данные для анализа
Входные данные для анализа со стороны руководства должны включать в себя следующую информацию: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
5.6.3 Выходные данные анализа
Выходные данные анализа со стороны руководства должны включать в себя все решения и действия, относящиеся: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
6 Менеджмент ресурсов
6.1 Обеспечение ресурсами
Организация должна определить и обеспечивать ресурсы, требуемые: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
6.2 Человеческие ресурсы
6.2.1 Общие положения
Персонал, выполняющий работу, влияющую на соответствие продукции требованиям, должен быть компетентным на основе полученного образования, подготовки, навыков и опыта. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
6.2.2 Компетентность, подготовка и осведомленность
Организация должна: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
6.3 Инфраструктура
Организация должна определять, обеспечивать и поддерживать в рабочем состоянии инфраструктуру, необходимую для достижения соответствия требованиям к продукции. Инфраструктура может включать в себя, если применимо: |
Организация должна определять, обеспечивать и поддерживать в рабочем состоянии инфраструктуру, необходимую для поддержки жизненного цикла программного обеспечения.
Подобная инфраструктура может включать в себя, если применимо:
a) инструменты и утилиты, необходимые для разработки программного обеспечения, включая хост-компьютер и программную поддержку;
b) инструменты верификации программного обеспечения, в том числе тестовое оборудование и тестовое программное обеспечение;
c) инструменты, утилиты и оборудование, необходимые для архивирования и хранения, восстановления в аварийных ситуациях, защиты, репликации, загрузки программного обеспечения, передачи, сохранения записей, менеджмента качества и управления конфигурацией программного обеспечения;
d) инструменты и утилиты верификации целостности (например, проверка/защита от вирусов, электронно-цифровые подписи, алгоритмы криптографического хеширования, циклические избыточные коды);
e) оборудование и программное обеспечение, обеспечивающие выполнение требований к резервному копированию;
f) средства защиты программной среды от внешних атак (например, от вредоносных программ, программ-червей, вирусов, "черных ходов", следящего программного обеспечения, защитные цифровые коды, защита с помощью отпечатков пальцев).
6.4 Производственная среда
Организация должна создавать производственную среду, необходимую для достижения соответствия требованиям к продукции, и управлять ею. |
Организация должна уделять внимание тому, чтобы обеспечить, где это применимо, управление производственной средой программного обеспечения для надлежащего обновления конфигурации.
7 Процессы жизненного цикла продукции
7.1 Планирование процессов жизненного цикла продукции
Организация должна планировать и разрабатывать процессы, необходимые для обеспечения жизненного цикла продукции. Планирование процессов жизненного цикла продукции должно быть согласовано с требованиями к другим процессам системы менеджмента качества (см. 4.1). |
Планирование процессов жизненного цикла программного обеспечения должно учитывать всю деятельность, связанную с программным обеспечением, от планирования проекта до поставки продукции и обслуживания, включая, где применимо:
a) цели в области качества и требования, выраженные в измеримых показателях, включая ключевые характеристики и критичные показатели;
b) жизненный цикл программного обеспечения;
c) идентификацию, квалификацию, выбор и управление поставщиками;
d) оценку, квалификацию, верификацию и утверждение неразрабатываемого программного обеспечения и программной поддержки;
e) необходимые средства инфраструктуры (см. 6.3);
f) мониторинг, оценку и аудит программного обеспечения и связанной с ним деятельности;
g) уровень критичности программного обеспечения, основанный на "вкладе" программного обеспечения в потенциальные состояния отказов;
h) требования к безопасности и защите продукции и данных;
i) стандарты (например, стандарты разработки и кодирования), правила, практики, соглашения, техники и методологии разработки и тестирования;
j) инструменты, шаблоны, вспомогательные средства;
k) распределение задач и ответственности между заинтересованными сторонами;
l) установку и поддержку продукта;
m) верификацию, валидацию, приемку и поставку продукции;
n) авторские права, лицензионные соглашения, права интеллектуальной собственности, экспортный контроль.
7.1.1 Управление проектом
Соответственно особенностям организации и продукции организация должна планировать и управлять созданием продукции четким и контролируемым способом, для того чтобы отвечать требованиям с приемлемым уровнем риска в рамках действующих ресурсных и временных ограничений. |
Необходимо применять требования SAE AS9100 со следующими разъяснениями для программного обеспечения.
Помимо стандартных средств управления проектом проекты по разработке программного обеспечения должны учитывать другие индикаторы прогресса (например, требования, строки кода, выполнение теста), устаревание отчетов о проблемах или открытые отчеты о проблемах при приближении к завершению разработки программного обеспечения.
7.1.2 Управление рисками
Организация для выполнения применяемых к ней требований должна разработать, внедрить и поддерживать в рабочем состоянии процесс управления рисками, включающий в себя соответственно особенностям организации и продукции: |
Необходимо применять требования SAE AS9100 со следующими разъяснениями для программного обеспечения.
Управление рисками должно отражать специальные требования (см. 3.19) к программному обеспечению.
Примечание - Меры по снижению рисков могут включать в себя дополнительное обучение применению новых инструментов или оборудования или моделирование интерфейса.
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. Дополнительных требований к программному обеспечению нет.
7.2 Процессы, связанные с потребителями
7.2.1 Определение требований, относящихся к продукции
Организация должна определить: |
Где применимо, организация должна планировать метод извлечения требований от прототипов и демонстрационных программ (например, для определения требований к программному обеспечению может использоваться графический интерфейс пользователя).
7.2.2 Анализ требований, относящихся к продукции
Организация должна анализировать требования, относящиеся к продукции. Этот анализ должен проводиться до принятия организацией обязательства поставлять продукцию потребителю (например, участия в тендерах, принятия контрактов или заказов, принятие изменений к контрактам или заказам) и обеспечивать: |
Процесс анализа требований в организации должен включать в себя:
a) взаимодействие с заинтересованными сторонами;
b) методы согласования требований и уровней прослеживаемости;
c) методы допуска изменений в требования, относящиеся к программному обеспечению.
7.2.3 Связь с потребителями
Организация должна определять и осуществлять эффективные меры по поддержанию связи с потребителями, касающиеся: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
7.3 Проектирование и разработка
7.3.1 Планирование проектирования и разработки
Организация должна планировать проектирование и разработку и управлять этими процессами. |
Планирование проектирования и разработки должно включать в себя:
a) определение и управление входными и выходными критериями, связанными с ними входами и выходами, в том числе документации по каждому этапу проектирования и разработки;
b) уровни прямой и обратной прослеживаемости, применимой к программному обеспечению (например, каждое требование к программному обеспечению прослеживается от системных требований через детализированные требования, чертежи, коды и верификацию).
7.3.2 Входные данные для проектирования и разработки
Входные данные, относящиеся к требованиям к продукции, должны быть определены, а записи должны поддерживаться в рабочем состоянии (см. 4.2.4). |
Входные данные для проектирования и разработки должны включать в себя распределение требований, которым должно соответствовать программное обеспечение. Требования к программному обеспечению, в том числе требования к интерфейсу, должны быть верифицируемы, прослеживаемы и согласованы с требованиями более высокого уровня. Те требования, которые не могут быть прослеживаемы до требований более высокого уровня, должны быть идентифицированы в качестве производных требований, и информация об этом должна быть доведена до сведения заинтересованных сторон.
Результаты анализа требований должны быть доведены до сведения заинтересованных сторон для обеспечения того, что их потребности и ожидания были выражены и учтены.
Примечание - Примерами входных данных для проектирования и разработки программного обеспечения могут являться: проект архитектуры системы, анализ безопасности системы, анализ защищенности и надежности системы, критические элементы, документация по управлению внешним интерфейсом, результаты исследований.
7.3.3 Выходные данные проектирования и разработки
Выходные данные проектирования и разработки должны быть представлены в форме, подходящей для проведения верификации относительно входных требований к проектированию и разработке, а также должны быть официально одобрены до их последующего использования. |
Выходные данные проектирования и разработки должны быть определены (7.3.1), задокументированы и проанализированы в соответствии с планом. Организация должна определить критические объекты программного обеспечения, включая любые ключевые характеристики программных продуктов и процессов в сравнении с запланированными (заданными) уровнями или пороговыми значениями. Выходные данные должны быть оценены на корректность, полноту и непротиворечивость относительно входных требований к программному обеспечению.
Примечание - Примерами выходных данных проектирования и разработки программного обеспечения могут являться: разработка архитектуры, разработка требований к робастности, детализированный проект, исходный и исполняемый код, анализ безопасности, надежности и защищенности, документация по управлению внешним интерфейсом, руководство пользователя, инструкции по установке и планы.
7.3.4 Анализ проекта и разработки
На соответствующих стадиях должны проводиться систематический анализ проекта и разработки в соответствии с запланированными мероприятиями (см. 7.3.1) в целях: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
7.3.5 Верификация проекта и разработки
Верификацию должны осуществлять в соответствии с запланированными мероприятиями (см.7.3.1) с целью удостовериться в том, что выходные данные проектирования и разработки соответствуют входным требованиям. Записи результатов верификации и всех необходимых действий должны поддерживаться в рабочем состоянии (см. 4.2.4). |
В тех случаях, когда неразрабатываемое программное обеспечение интегрируется в поставляемую продукцию, требования к конечному изделию, отнесенные к неразрабатываемому программному обеспечению, должны быть верифицированы в ходе верификации и валидации конечного изделия. Неразрабатываемое программное обеспечение, а также любая сопроводительная документация (например, данные по описанию версии, руководство пользователя, данные о верификации) должны быть идентифицированы, а их конфигурация должна управляться для поддержания соответствия, сертификации и утверждения потребителем.
В некоторых случаях продукция не может быть полностью верифицирована посредством тестирования (например, когда критичное с точки зрения безопасности программное обеспечение не может быть верифицировано в существующих условиях, не подвергаясь при этом существенным рискам, либо когда необходимые условия являются достаточно редкими и трудно создаваемыми). В связи с невозможностью проведения тестирования некоторых программных продуктов исчерпывающе и в полном объеме организация может использовать альтернативные методы верификации (например, проведение анализа, проверок, демонстраций, интеграция более высокого уровня, имитационные проверки).
7.3.6 Валидация проекта и разработки
Валидацию проекта и разработки следует осуществлять в соответствии с запланированными мероприятиями (см. 7.3.1) с целью удостовериться в том, что полученная в результате продукция соответствует требованиям к установленному или предполагаемому использованию, если оно известно. Где это практически возможно, валидация должна быть завершена до поставки или применения продукции. Записи результатов валидации и всех необходимых действий следует поддерживать в рабочем состоянии (см. 4.2.4). |
В некоторых случаях продукция не может быть полностью валидирована посредством тестирования (например, когда критичное с точки зрения безопасности программное обеспечение не может быть валидировано в существующих условиях, не подвергаясь при этом существенным рискам, либо когда необходимые условия являются достаточно редкими и трудно создаваемыми). В связи с невозможностью проведения тестирования некоторых программных продуктов исчерпывающе и в полном объеме организация может использовать альтернативные методы валидации (например, проведение анализа, проверок, демонстраций, интеграция более высокого уровня, имитационные проверки).
Объем применяемых методов валидации должен соответствовать риску и последствиям ошибок в проектировании и разработке. Любые отличия между внешней средой, в которой проводят валидацию, и внешней средой, в которой применяется программное обеспечение, должны быть задокументированы и оценены.
7.3.6.1 Испытания для верификации и валидации проекта и разработки
Если для верификации и валидации необходимо проведение испытаний, то такие испытания должны быть запланированы, проконтролированы, проанализированы и задокументированы, чтобы обеспечить и подтвердить, что: |
Внешняя среда, в которой осуществляются испытания, должна быть задокументирована и управляема для обеспечения повторяемости.
Примечание 1 - Испытания при верификации и валидации должны соответствовать размеру, критичности и области применения продукции.
Примечание 2 - Использование регрессионного тестирования должно быть задокументировано для проведения повторных испытаний составляющих программного обеспечения, которые подверглись изменениям. Возвратное тестирование должно соответствовать размеру, критичности и области применения изменений.
7.3.6.2 Документация верификации и валидации проекта и разработки
По окончании проектирования и/или разработки организация должна убедиться в том, что отчеты, расчеты, результаты испытаний и т.д. подтвердили точное соответствие продукции требованиям технических условий на всех установленных для нее режимах эксплуатации. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
7.3.7 Управление изменениями проекта и разработки
Изменения проекта и разработки должны быть идентифицированы, а записи должны поддерживаться в рабочем состоянии. Изменения должны быть проанализированы, верифицированы и валидированы соответствующим образом, а также одобрены до внесения. Анализ изменений проекта и разработки должен включать в себя оценку влияния изменений на составные части и уже поставленную продукцию. |
Должен быть разработан и внедрен процесс управления изменениями проекта и разработки, включающий в себя результативный процесс управления изменениями в программном обеспечении. Процесс должен включать в себя схему категорирования и ранжирования изменений. Каждое изменение должно быть классифицировано по своей категории и приоритетности для содействия в проведении анализа тренда и разрешения проблем.
Изменения в проекте и разработке программного обеспечения должны быть оценены с точки зрения своего воздействия на применяемую продукцию и процессы на протяжении жизненного цикла. Оценка должна включать в себя потенциальное воздействие на совокупное функционирование системы, безопасность, надежность и ремонтопригодность.
В том случае, если изменение в системе является следствием несоответствия, должна быть предоставлена ссылка на процедуры управления несоответствиями (8.3).
7.4 Закупки
7.4.1 Процесс закупок
Организация должна обеспечивать соответствие закупленной продукции установленным требованиям к закупкам. Тип и степень управления, применяемые по отношению к поставщику и закупленной продукции, должны зависеть от ее воздействия на последующие стадии жизненного цикла продукции или готовую продукцию. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
7.4.2 Информация по закупкам
Информация по закупкам должна описывать заказанную продукцию, включая, где это необходимо, требования: |
Организация должна гарантировать, что информация по закупкам одобрена в соответствии с закрепленными в организации должностными обязанностями (например, закупки, разработка программного обеспечения, качество программного обеспечения, управление конфигурацией).
Информация о закупках должна включать в себя применимые стандарты, используемые при создании программного продукта (например, протоколы связи, архитектурные спецификации, требования к интерфейсу, технологические стандарты, руководящие указания, требования защиты и безопасности).
7.4.3 Верификация закупленной продукции
Организация должна разработать и осуществлять контроль или другую деятельность, необходимую для обеспечения соответствия закупленной продукции установленным требованиям к закупкам. |
Верификацию имеющегося на рынке программного обеспечения, интегрируемого в поставляемое программное обеспечение, осуществляют в соответствии с 7.3.5.
7.5 Производство и обслуживание
В отношении программного обеспечения термин "производство" используется только в отношении применения утвержденного разработанного программного обеспечения в целевых компьютерных системах или устройствах.
7.5.1 Управление производством и обслуживанием
Организация должна планировать и осуществлять производство и обслуживание в управляемых условиях. Управляемые условия должны включать в себя там, где это применимо: |
Организация должна разработать задокументированную процедуру поставки программной продукции в управляемой конфигурации. Поставку можно обеспечивать посредством физического перемещения носителей или аппаратных средств, содержащих программное обеспечение, либо передачей в электронной форме. Процедура может предусматривать использование инструментов для обеспечения целостности передачи, хранения и извлечения программного обеспечения, если это применимо.
В тех случаях, когда программный продукт поставляется в аппаратных средствах, организация должна разработать процедуру по установке программного обеспечения в данные аппаратные средства.
Записи, свидетельствующие о верификации целостности при установке программного обеспечения, должны поддерживаться в рабочем состоянии (4.2.4.).
7.5.1.1 Верификация производственного процесса
Организация должна использовать типовое изделие из первой изготовленной партии новых изделий или узлов для подтверждения того, что производственные процессы, производственная документация и инструментальная оснастка обеспечивают производство изделий и узлов, соответствующих требованиям. Этот процесс необходимо повторять в случае внесения изменений, аннулирующих первоначальные результаты (например, конструктивные изменения, изменения в процессе производства, изменения инструмента). |
Организация должная проводить верификацию процедур производства, обеспечивающих установку программного обеспечения. Производственные процедуры должны обеспечивать правильность, целостность операций загрузки и возможность инициализации целевой системы после загрузки.
Примечание - Аудит конфигурации, иногда упоминаемый как анализ соответствия программного обеспечения или контроль первого изделия, описан в 7.1.3.5.
7.5.1.2 Управление изменениями производственного процесса
Следует назначить полномочный персонал для утверждения изменений производственных процессов. |
Изменения в процедурах установки и верификации программного обеспечения должны быть верифицированы персоналом, ознакомленным с требованиями к установке программного обеспечения. Изменения должны быть выполнены в соответствии с формальными процедурами управления конфигурации.
7.5.1.3 Контроль производственного оборудования, инструмента и программного обеспечения
Производственное оборудование, инструменты и программное обеспечение, используемые для управления процессами жизненного цикла продукции, их автоматизации и контроля, должны пройти валидацию до их использования и поддерживаться в рабочем состоянии. |
Оборудование (в том числе испытательное) и инструменты, передающие и верифицирующие исполняемое программное обеспечение от считываемых носителей (например, компакт-диск, файлы сервера) к целевой системе, должны быть валидированы для обеспечения целостности операции по загрузке.
Примечание - Репликация носителей данных описана в 7.1.3.1.
7.5.1.4 Обслуживание после поставки
Обслуживание после поставки должно обеспечивать там, где это применимо: |
Примечание - Схемы восстановления программного обеспечения упомянуты в 7.1.3 в части требований к управлению конфигурацией.
7.5.2 Валидация процессов производства и обслуживания
Организация должна валидировать все процессы производства и обслуживания, результаты которых не могут быть верифицированы последующим мониторингом или измерениями, из-за чего недостатки становятся очевидными только после начала использования продукции или после предоставления услуги. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
7.5.3 Идентификация и прослеживаемость
Если это возможно и целесообразно, организация должна идентифицировать продукцию с помощью соответствующих средств на всех стадиях ее жизненного цикла. |
Организация должна определить конфигурацию программного обеспечения с целевой системой, в которой оно установлено.
7.5.4 Собственность потребителей
Организация должна проявлять заботу о собственности потребителя, пока она находится под управлением организации или используется ею. Организация должна идентифицировать, верифицировать, защищать и сохранять собственность потребителя, предоставленную для использования или включения в продукцию. Если собственность потребителя утеряна, повреждена или признана непригодной для использования, организация должна известить об этом потребителя и поддерживать записи в рабочем состоянии (см. 4.2.4). |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
7.5.5 Сохранение соответствия продукции
Организация должна сохранять продукцию в ходе внутренней обработки и в процессе поставки к месту назначения в целях поддержания ее соответствия установленным требованиям. Если это применимо, сохранение соответствия продукции должно включать в себя идентификацию, погрузочно-разгрузочные работы, упаковку, хранение и защиту. Требование сохранения соответствия должно быть также применено и к составным частям продукции. |
Организация должна обеспечивать корректное использование программных продуктов в соответствии с планированием управления конфигурации, включая там, где это применимо:
a) архивирование и восстановление;
b) восстановление в аварийных ситуациях и планирование возможных аварийных ситуаций;
c) устаревание носителей;
d) хранение и обращение носителей программного обеспечения в защищенных условиях среды с учетом соответствующих внешних факторов (например, температура, влажность, электромагнитные или электростатические разряды);
e) кодирование/декодирование;
f) сжатие/распаковку данных;
g) защиту от программных вирусов и преднамеренных негативных действий;
h) период, в который организация сохраняет обязательства по поставке копий носителей информации и способности считывания данных копий.
7.6 Управление оборудованием для мониторинга и измерений
Организация должна определить мониторинг и измерения, которые предстоит осуществлять, а также оборудование для мониторинга и измерений, необходимое для обеспечения свидетельства соответствия продукции установленным требованиям. |
Организация должна определить и задокументировать, как испытательное оборудование, использованное для верификации, валидации или одобрения поставляемого программного продукта, разработано, поддерживается и контролируется.
Примечание - Поверка (калибровка), как метод верификации, как правило, не применима для программного обеспечения. Тем не менее она может быть применена для аппаратных средств и проверки или моделирования программного обеспечения, используемого для тестирования и валидации поставляемого программного обеспечения, сопутствующих аппаратных средств и системы.
8 Измерение, анализ и улучшение
8.1 Общие положения
Организация должна планировать и применять процессы мониторинга, измерения, анализа и улучшения, необходимые: |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
8.2 Мониторинг и измерение
8.2.1 Удовлетворенность потребителей
Организация должна проводить мониторинг информации, касающийся восприятия потребителем выполнения организацией его требований, как одного из способов измерения работы системы менеджмента качества. Должны быть установлены методы получения и использования этой информации. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
8.2.2 Внутренние аудиты (проверки)
Организация должна проводить внутренние аудиты (проверки) через запланированные интервалы времени в целях установления того, что система менеджмента качества: |
Программа внутренних аудитов организации должна включать в себя аспекты системы менеджмента качества, связанные с программным обеспечением.
Примечание - Аудиты проектов могут рассматриваться и использоваться в качестве объективных свидетельств при проведении внутренних аудитов, в то же время они не полностью отвечают требованиям к внутренним аудитам.
8.2.3 Мониторинг и измерение процессов
Организация должна использовать подходящие методы мониторинга и, где это применимо, измерения процессов системы менеджмента качества. Эти методы должны демонстрировать способность процессов достигать запланированных результатов. Если запланированные результаты не достигаются, то должны предприниматься необходимые коррекции и корректирующие действия. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
8.2.4 Мониторинг и измерение продукции
Организация должна осуществлять мониторинг и измерять характеристики продукции в целях верификации соблюдения требований к продукции. Это должны осуществлять на соответствующих стадиях процесса жизненного цикла продукции согласно запланированным мероприятиям (см. 7.1). |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
8.3 Управление несоответствующей продукцией
Организация должна обеспечивать идентификацию продукции, не соответствующую требованиям, и управление ею в целях предотвращения непреднамеренного использования или поставки такой продукции. Должна быть установлена документированная процедура для определения средств управления и соответствующей ответственности и полномочий для действий с несоответствующей продукцией. |
Организация должна разработать документированную процедуру по управлению и обращению с несоответствующим программным обеспечением, включающую в себя:
a) ведение записей о выявленных несоответствиях;
b) проведение анализа возможного воздействия на другие части программного обеспечения/системы;
c) оценку и ранжирование несоответствий;
d) уведомление ответственных сторон для обеспечения необходимой прослеживаемости при принятии решений;
e) методы верификации модификации продукции;
f) обеспечение записей в отношении причин и утверждения каждой из модификаций;
g) ведение записей по окончательным решениям, которые могут включать в себя:
- модификацию для обеспечения соответствия требованиям;
- согласие от потребителя в том случае, если принятое решение приводит к отклонениям от контрактных требований;
- использование в качестве соответствующей продукции после дополнения требований;
- изъятие продукции.
Информация о проблемах, выявленных с неразрабатываемым программным обеспечением, должна быть доведена до поставщика продукции, в зависимости от потенциального риска.
8.4 Анализ данных
Организация должна определять, собирать и анализировать соответствующие данные для демонстрации пригодности и результативности системы менеджмента качества, а также оценивания, в какой области возможно постоянное повышение результативности системы менеджмента качества. Данные должны включать в себя информацию, полученную в результате мониторинга и измерения и из других соответствующих источников. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
8.5 Улучшение
8.5.1 Постоянное улучшение
Организация должна постоянно повышать результативность системы менеджмента качества посредством использования политики и целей в области качества, результатов аудитов, анализа данных, корректирующих и предупреждающих действий, а также анализа со стороны руководства. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
8.5.2 Корректирующие действия
Организация должна предпринимать корректирующие действия в целях устранения причин несоответствий для предупреждения повторного их возникновения. Корректирующие действия должны быть адекватными последствиям выявленных несоответствий. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
8.5.3 Предупреждающие действия
Организация должна определять действия, направленные на устранение причин потенциальных несоответствий для предупреждения их появления. Предупреждающие действия должны соответствовать возможным последствиям потенциальных проблем. |
Необходимо применять требования SAE AS9100. Дополнительных требований к программному обеспечению нет.
Приложение ДА (справочное). Сведения о соответствии ссылочных международных и региональных стандартов ссылочным национальным стандартам Российской Федерации
Приложение ДА
(справочное)
Таблица ДА.1
Обозначение ссылочного международного, регионального стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
SAE AS9006 | - | * |
SAE AS9100:2009 | IDT | ГОСТ Р ЕН 9100-2011 "Системы менеджмента качества организаций авиационной, космической и оборонных отраслей промышленности. Требования" |
IEEE-STD-610.12-1990 | - | * |
IEEE-STD-982.1-1998 | - | * |
ИСО/МЭК 12207:1995 | IDT | ГОСТ Р ИСО/МЭК 12207-2010 "Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств" |
ИСО/МЭК 15288 | ГОСТ Р ИСО/МЭК 15288-2005 "Информационная технология. Системная инженерия. Процессы жизненного цикла систем" | |
RTCA/DO-178, | - | * |
RTCA/DO-254, | - | * |
* Соответствующий национальный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык международного (регионального) стандарта. Перевод данного международного (регионального) стандарта находится в Федеральном информационном фонде технических регламентов и стандартов. |
УДК [004.4+658.5+62]:006.354 | ОКС 01.120 |
03.120 | |
49.020 | |
|
Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2016