ГОСТ Р 56569-2015. Национальный стандарт Российской Федерации. Системы менеджмента качества. Требования к организациям авиационной, космической и оборонной промышленности. Поставляемое программное обеспечение

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).