ГОСТ 34009—2016
к данному ПО ТПС. Допускается проводить анализ изменений документации в других испытательных
лабораториях (центрах), аккредитованных в установленном порядке, в случае отсутствия возможности
провести данный анализ в испытательной лаборатории (центре), в котором ранее проводились испыта ния
и экспертиза документации к данному ПО ТПС.
9.9 Характер изменений ПО ТПС должен обязательно быть отражен в программной документации
на всех уровнях, включая рабочую (проектную) и эксплуатационную документацию. Документы должны
быть повторно согласованы и утверждены после включения соответствующих изменений.
9.10 Разработчик должен поддерживать принятое экспертами и уполномоченными по изменению
решение по утверждению, отклонению или отсрочке для каждого предложенного изменения, извещая о
принятом решении тех лиц. кого оно касается.
9.11 Если решение отсрочено, разработчику следует представить рекомендации, как действовать
до повторного рассмотрения.
9.12 Если изменение отклонено, то разработчику следует информировать ответственных за ини
циацию внесения изменений, чтобы снять предложенное изменение с рассмотрения.
9.13 Процесс изменения ПО ТПС должен быть закончен формированием новой версии программ
ного обеспечения. Утвержденное изменение записывают на электронный носитель информации, иден
тифицируют надлежащим образом с помощью контрольной суммы (с указанием метода ее
получения) и в дальнейшем данный электронный носитель информации с изменениями используют как
эталонный, с проставлением даты формирования носителя информации и приложением акта и
протокола иденти фикации версии ПО ТПС.
9.14 Для сведения риска повреждения программно-аппаратных комплексов и встроенных систем
к минимуму, необходим жесткий контроль внесения изменений в них. Для этого требуются формальные
процедуры управления процессом внесения изменений. Эти процедурыдолжны гарантировать, чтофунк
циональная безопасность и процедуры управления ею не будут нарушены и что получено
формальное разрешение на внесение изменений.
9.15 Рекомендуется присваивать предложению об изменении уникальный идентификационный
номер на самой ранней стадии, чтобы облегчить прослеживаемость и идентификацию. Следует фик
сировать статус прохождения изменения и связанных с этим решений и распоряжений. Необходимо
выполнять и документировать оценки предложенного изменения с точки зрения:
- его технических достоинств;
- влияния на взаимозаменяемость, средства сопряжения, а также необходимость повторной иден
тификации;
- влияния на график работы и расходы подоговору;
- влияния на методы производства, испытания и контроля;
- влияния на закупки и запасы;
- влияния на техническое обслуживание, справочники для потребителя и руководства.
9.16 После подготовки изменения уполномоченное лицо или группа лиц должны проанализировать
документированные оценки и решить вопрос об утверждении или неутверждении изменения. Внесение и
проверка утвержденного изменения обычно включает следующие шаги:
- официальное утверждение изменения идентификации конфигурации;
- определение необходимых последующих действий соответствующими руководителями;
- проверка соответствия проекта, испытаний, производства и т.д. техническим требованиям.
9.17 Отчет пользователей о выявленных дефектах в программах должен содержать:
- идентификатор пользователя, представившего отчет;
- дату фиксирования дефекта или предложения на изменение ПО ТПС;
- номер и параметры адаптации версии ПО ТПС. на которой обнаружен дефект;
- подробное описание сценария и исходных данных, при которых выявлен дефект;
- описание проявления дефекта и документы результатов его регистрации;
- предположение о причине, вызвавшей проявление дефекта.
Отчет о предложениях по совершенствованию и развитию функций версии ПО ТПС. а также ре
зультатов анализа предполагаемых корректировок должен содержать:
- идентификатор разработчика, которому передан отчет пользователя для анализа предложения;
- дату анализа отчета пользователя;
- признак наличия повторяемости результатов и сценария проявления дефекта и информацию о
необходимости дальнейшего анализа дефекта;
- тесты, исходные данные и сценарий, при которых проявляется дефект;
- результаты анализа предложения на изменение, причины и источника выявленного дефекта;
9