Базовая версия
2026-03-20T18:37:01+00:00
1 Введение3 1.1 Цель3 1.2 Ссылки3 1.3 Термины, определения и соглашения3 2 Среда верификации4 2.1 Связь с другими процессами жизненного цикла ПО4 2.2 Независимость4 2.3 Инструменты верификации4 2.4 Методы верификации4 2.4.1 Испытания4 2.4.2 Рассмотрение5 2.4.3 Анализ5 2.4.4 Формальная инспекция5 3 Мероприятия процесса верификации6 3.1 Формальная инспекция6 3.1.1 Входные данные6 3.1.2 Критерии начала мероприятия6 3.1.3 Процедура выполнения мероприятия7 3.1.4 Критерии окончания мероприятия8 3.1.5 Выходные данные8 3.1.6 Исправление несоответствий8 3.2 Разработка тестовых примеров9 3.2.1 Входные данные9 3.2.2 Критерии начала мероприятия9 3.2.3 Процедура выполнения мероприятия9 3.2.4 Критерии окончания мероприятия10 3.2.5 Выходные данные10 3.3 Испытания ПО (формальный прогон тестовых примеров)10 3.3.1 Входные данные10 3.3.2 Критерии начала мероприятия10 3.3.3 Процедура выполнения мероприятия10 3.3.4 Критерии окончания мероприятия10 3.3.5 Выходные данные10 3.4 Анализ трассировки10 3.4.1 Входные данные10 3.4.2 Критерии начала мероприятия11 3.4.3 Процедура выполнения мероприятия11 3.4.4 Критерии окончания мероприятия11 3.4.5 Выходные данные11 3.5 Анализ структурного покрытия11 3.5.1 Входные данные11 3.5.2 Критерии начала мероприятия11 3.5.3 Процедура выполнения мероприятия11 3.5.4 Критерии окончания мероприятия12 3.5.5 Выходные данные12 4 Критерии перехода13 5 Инструкции повторной верификации14 1 Введение Цель Данный документ определяет порядок проведения мероприятий верификации программного обеспечения, разработанного в рамках проекта “Система управления требованиями”. Ссылки КТ-178B. Квалификационные требования. Часть 178В. Требования к ПО бортовой аппаратуры и систем при сертификации авиационной техники. План разработки ПО. План управления конфигурацией ПО. Стандарт на разработку требований к ПО. Стандарт на проектирование ПО. Стандарт на кодирование ПО. Термины, определения и соглашения Таблица 1. Термины, определения и соглашения Термин Определение, толкование Сообщение о проблеме Документ процесса УК ПО, содержащий описание несоответствия в данных ЖЦ ПО или в описании процессов ЖЦ ПО. Запрос на изменение Документ процесса УК ПО, созданный для внесения изменений в данные ЖЦ ПО с целью устранения несоответствия, описанного в СП. Артефакт Атомарное данное ЖЦ ПО. Артефактом может быть, например, требование или файл исходного кода Агрегация Составное данное ЖЦ ПО, которое включает в себя однотипные артефакты и/или агрегации. Конфигурация Составное данное ЖЦ ПО, которое может включать в себя любые артефакты, агрегации и конфигурации Категория запроса на изменение Атрибут запроса на изменение, идентифицирующий процесс ЖЦ ПО, данные которого будут меняться в рамках этого ЗИ. Формальная инспекция Способ верификации документов, основанный на экспертной оценке их правильности, выполняемой одним или несколькими инспекторами, как правило, с использованием проверочных перечней. Первичная инспекция Формальная инспекция называется первичной, если она не является повторной. Повторная инспекция Формальная инспекция называется повторной, если версия объекта инспекции создана с целью устранения замечаний предыдущей инспекции. Тестовый пример Совокупность входных условий и значений входных параметров, ожидаемых результатов, критерия «Прошёл/Не прошёл» (“Pass/Fail”). Gitlab Система версионирования исходного кода, используемая в рамках проекта SQLP-1. Yandex Wiki Система поддержки разработки программного обеспечения, используемая в рамках проекта SQLP-1. Таблица 2. Сокращения Термин Определение, толкование ЖЦ Жизненный цикл ЗИ Запрос на изменение КК1 Категория контроля 1 ПО Программное обеспечение СП Сообщение о проблеме СПР Система поддержки разработки УК Управление конфигурацией ФИ Формальная инспекция Среда верификации Связь с другими процессами жизненного цикла ПО Входными данными процесса верификации являются следующие выходные данные процессов ЖЦ ПО: Планы проекта (План разработки, План УК ПО, План верификации); Требования к ПО; Описание проекта ПО; Исходный код; Исполняемый объектный код; Выходными данными процесса верификации являются: Сообщения о проблемах; Тестовые примеры и процедуры; Результаты прогона тестовых примеров (результаты испытаний); Протокол ФИ и перечень выявленных несоответствий; Независимость Независимость при выполнении мероприятий верификации обеспечивается на персональном уровне, то есть для каждого верифицируемого объекта из множества данных ЖЦ ПО сотрудник проекта, выполняющий мероприятие по верификации, не участвует в создании данного объекта. Можно привести следующие примеры достижения независимости мероприятий верификации: автор объекта формальной инспекции не может быть инспектором в данной инспекции; при проведении инспекции требований к ПО как целого инспектором не может быть ни один из авторов, участвовавших в разработке частей требований; авторы требований, кода и тестовых примеров не могут быть авторами отчета об анализе структурного покрытия. Инструменты верификации Инструменты, использующиеся в процессе верификации ПО, и их предназначение описаны в следующей таблице. Таблица 3. Инструменты верификации Название инструмента Предназначение инструмента Docker/systemd Стенд отладки и испытаний Spyder или VS Code Среда разработки кода бэкенд части. Pytest Средство для автоматизированного тестирования Pytest-cov Средство для отслеживания покрытия тестами TestRail Средство для хранения ручных и автоматизированных тестов Методы верификации Для проведения мероприятий верификации будут использоваться методы, описанные ниже. Порядок применения этих методов детально описан в разделе 3. Испытания Испытания – метод верификации, при котором на вход ПО подаются определенные в тестовых примерах входные воздействия, а результат работы испытуемого ПО, полученный для данных входных воздействий, сравнивается со значениями, ожидаемыми на основании требований. Тестовые примеры разрабатываются на основе требований к ПО и описания проекта ПО таким образом, чтобы обеспечить полное покрытие требований тестовыми примерами. В зависимости от совпадения результатов работы ПО с ожидаемыми значениями, для каждого отдельного тестового примера определяется результат “Прошёл/Не прошёл”. Если существуют тестовые примеры с результатом “Не прошел”, создаются сообщения о проблемах. Рассмотрение Рассмотрение – метод верификации, при котором данным жизненного цикла ПО дается экспертная оценка правильности. В проекте все рассмотрения проводятся в форме формальных инспекций (см. 2.4.4). (подумать о надобности) Анализ Анализ – метод верификации, при котором проводится документальное подтверждение корректности анализируемых данных жизненного цикла ПО. Отличительным свойством анализа является воспроизводимость, т.е. результаты анализа, проведенного по одной и той же процедуре для одних и тех же данных жизненного цикла ПО, но разными людьми, будут идентичными. Несоответствия, выявленные при проведении анализа, документируются в сообщениях о проблемах и таким образом передаются в процессы, результаты которых подвергаются анализу. Формальная инспекция Формальная инспекция – форма проведения рассмотрений и некоторых видов анализа. «Формальная» означает, что результат инспекции является основанием для изменения статуса документа в СПР Yandex Wiki. В ходе формальной инспекции одним или несколькими специалистами (инспекторами) осуществляется независимая проверка соответствия инспектируемых документов исходным документам. Для самоконтроля инспектора при проведении формальных инспекций, как правило, применяются заранее подготовленные и утвержденные проверочные перечни, различные для разных типов объектов инспекции. Ответы на вопросы проверочного перечня даются инспектором на основании экспертной оценки объектов формальной инспекции. Проверочные перечни хранятся в СПР Yandex Wiki и утверждаются первоначально руководителем проекта [3], а в дальнейшем – в процессе ФИ данного плана. После этого Администратор Yandex Wiki интегрирует утвержденные проверочные перечни в СПР Yandex Wiki для формальных инспекций объектов соответствующих типов (см. План УК ПО [3]). Объект формальной инспекции признается соответствующим входным данным, если в результате формальной инспекции не оказалось принятых замечаний к этому объекту. Несоответствия, выявленные при проведении формальной инспекции, документируются в форме замечаний в записи о формальной инспекции и таким образом передаются в процессы, результаты которых являются объектами формальной инспекции. Мероприятия процесса верификации Формальная инспекция В данном разделе дано описание типового процесса формальной инспекции, применимого для любого типа объекта инспекции. Каждая итерация формальной инспекции в данном Плане рассматривается как отдельная инспекция, первичная либо повторная. Исправление найденных несоответствий является мероприятием процессов, выходные данные которых являются объектами формальной инспекции, и описаны в соответствующих планах процессов жизненного цикла ПО. Тем не менее, в процессе переработки совершаются действия с замечаниями в СПР Yandex Wiki, общие для любых объектов инспекции. Эти действия описаны в разделе 3.1.6 данного плана. В контексте мероприятия формальной инспекции выделяются следующие роли: Автор – один из разработчиков объекта инспекции. Если разработчик недоступен, на роль автора назначается сотрудник, который будет исправлять обнаруженные несоответствия в объекте инспекции. Инспектор – сотрудник, хорошо знающий технические подробности проекта, относящиеся к объекту инспекции, и отвечающий за обнаружение несоответствий. Ведущий – сотрудник, отвечающий за надлежащее выполнение процесса формальной инспекции, начиная с момента назначения его на эту роль до завершения инспекции. Обычно ведущий также выполняет роль Инспектора. Таблица 5 дает рекомендации по выбору инспекторов в зависимости от типа объекта инспекции. На роль инспекторов рекомендуется назначать сотрудников, имеющих опыт работы в указанных процессах. Один сотрудник может закрывать несколько пунктов в списке процессов, равно как и допустимо назначать нескольких инспекторов из одного процесса. При назначении инспекторов должны выполняться требования независимости, установленные в разделе 2.2 данного плана. Таблица 5. Роль инспектора в формальной инспекции Тип объекта инспекции Инспектор (процесс) Планы и стандарты проекта Планирование Процесс, который регламентируется инспектируемым планом/стандартом Требования к ПО высокого уровня Разработка системы (необязательно) Разработка требований высокого уровня Проектирование Кодирование (необязательно) Верификация Описание проекта ПО Проектирование Кодирование Верификация Исходный код Кодирование Верификация Тестовые примеры и процедуры Верификация Результаты прогона тестовых примеров Верификация Входные данные План верификации ПО; Запрос на изменение; Объекты формальной инспекции; Входные данные процесса, результаты которого являются объектом формальной инспекции; Запись о предыдущей формальной инспекции (при наличии) Критерии начала мероприятия Одновременно выполнены следующие условия: Установлены базовые версии входных данных, на основе которых разработаны объекты формальной инспекции. По мнению автора, все изменения во все данные ЖЦ, требующие изменения по ЗИ, внесены. Процедура выполнения мероприятия Инициализация Автор помещает объекты инспекции (измененные/созданные по ЗИ данные ЖЦ) в Yandex Wiki. Если формальная инспекция еще не проводилась, Автор создает запись о формальной инспекции в Yandex Wiki из запроса на изменение, связывает ее с необходимыми проверочными перечнями, входными данными, на основании которых разрабатывались объекты инспекции, и справочными данными. СПР Yandex Wiki автоматически устанавливает связь формальной инспекции с последними версиями всех единиц конфигурации, измененных по ЗИ, как с подлежащими инспекции версиями объектов инспекции. Автор переводит формальную инспекцию в состояние «Назначена». Руководитель проекта назначает Ведущего и Инспекторов для данной формальной инспекции. Экспертиза и обсуждение Инспекторы проверяют существенные характеристики объектов инспекции, указанных на титульном листе записи о формальной инспекции. Обнаруженные несоответствия должны быть точно локализованы, сформулированы и записаны; при этом следует стремиться к таким формулировкам, которые идентифицируют проблемы, но не предлагают их решения. Каждое найденное несоответствие следует оформлять отдельно в списке замечаний записи о формальной инспекции в Yandex Wiki. Для самоконтроля Инспектора при проведении формальных инспекций применяются заранее подготовленные и утвержденные проверочные перечни, содержащиеся в записи об инспекции. Проверочные перечни, как правило, содержат достаточно вопросов, чтобы всесторонне оценить соответствие объектов формальной инспекции входным данным. Однако Инспектор может обнаружить и такие несоответствия, которые невозможно отнести ни к одному из вопросов проверочного перечня. Если найденное несоответствие таково, что хотя бы одно из положений, описываемых каким-либо вопросом проверочного перечня, не выполняется, то Инспектор должен ответить “Нет” на данный вопрос и связать с ним замечание, описывающее найденное несоответствие. В общем случае, одно замечание может быть связано с несколькими вопросами проверочного перечня, и наоборот, с одним вопросом может быть связано несколько замечаний. Инспектор оставляет все оформленные замечания в состоянии «Назначено», за исключением ошибочно созданных замечаний, которые следует перевести в состояние «Отменено» с добавлением соответствующего комментария. Если выявлено несоответствие во входных данных, не являющихся объектом формальной инспекции, то вместо замечания, связанного с формальной инспекцией, Инспектор должен открыть сообщение о проблеме, описывающее несоответствие. Рассмотрению подлежат также и замечания, выявленные в ходе предыдущих формальных инспекций, которые находятся в одном из следующих состояний: «Ведется обсуждение», «Исправлено». По итогам рассмотрения каждого замечания принимается решение об изменении его состояния, как указано ниже. Для каждого замечания, выявленного в ходе предыдущих формальных инспекций, находящегося в состоянии «Ведется обсуждение», принимается решение о переводе в одно из следующих состояний: «Отменено» – после обсуждения с Автором установлено, что несоответствия нет; «Назначено» – после обсуждения с Автором установлено, что несоответствие требует устранения; Для каждого замечания, выявленного в ходе предыдущих формальных инспекций и находящегося в состоянии «Исправлено», принимается решение о переводе в одно из следующих состояний: «Закрыто» – несоответствие устранено в текущей версии объекта формальной инспекции; «Назначено» – несоответствие не устранено или устранено некорректно. Регистрация результатов Все замечания, для которых во время обсуждения было принято решение об изменении их состояния, Ведущий переводит в состояние, соответствующее принятому решению, и при необходимости выполняет дополнительные действия: «Отменено» – должен быть заполнен комментарий, описывающий причину снятия несоответствия; «Назначено» – должен быть заполнен комментарий, уточняющий первоначальное описание несоответствия или поясняющий, в чем состоит некорректность исправления; «Закрыто». Ведущий завершает заполнение проверочных перечней, связанных с ФИ. При проведении повторной формальной инспекции ответы на вопросы проверочных перечней должны быть актуализированы, т.е. должны отражать состояние рассматриваемых версий объектов инспекции. На каждый вопрос проверочных перечней должен быть дан один из следующих ответов: “Да” – все положения, описываемые данным вопросом проверочного перечня, выполняются. “Нет” – хотя бы одно из положений, описываемых данным вопросом проверочного перечня, не выполняется. “Не применимо” – ни одно из положений, описываемых данным вопросом проверочного перечня, не может быть оценено для рассматриваемых объектов формальной инспекции. Если выбран этот вариант ответа, то должен быть заполнен поясняющий комментарий. Ведущий устанавливает отметку “штамп” о завершении формальной инспекции. Если хотя бы одно из замечаний находится в состоянии «Назначено», Ведущий переводит запись о формальной инспекции в состояние «Нужно переделать», в противном случае Ведущий переводит запись о формальной инспекции в состояние «Завершено» и связанный с ней ЗИ в состояние «Завершено». Критерии окончания мероприятия Выполнено одно из следующих условий: Формальная инспекция переведена в состояние «Завершено» и связанный с ней ЗИ переведен в состояние «Завершено». Формальная инспекция переведена в состояние «Необходимо переделать». Выходные данные Сообщения о проблемах; Запись о формальной инспекции (актуализированная): Титульный лист формальной инспекции; Список замечаний; Заполненные проверочные перечни. Исправление несоответствий В процессе переработки объектов инспекции по замечаниям проведенной формальной инспекции для каждого зафиксированного в записи о формальной инспекции замечания в состоянии «Назначено»: Если Автор согласен с наличием зафиксированного несоответствия, он вносит необходимые изменения в объекты инспекции и переводит замечание в состояние «Исправлено». Если Автор считает, что исправление несоответствия нецелесообразно и несоответствие должно быть отклонено либо исправление должно быть отложено, то Автор снабжает замечание комментарием и переводит его в состояние «Ведется обсуждение». Разработка тестовых примеров Входные данные План верификации ПО; Описание проекта ПО; Требования к ПО; Стандарт на кодирование; Запрос на изменение; Запись о ФИ тестовых примеров и результатов испытаний ПО (если проводилась ФИ); Тестовые примеры (разработанные ранее). Критерии начала мероприятия Одновременно выполнены следующие условия: Базовые версии для артефактов тестируемого описания проекта ПО и артефактов тестируемых требований к ПО установлены. Формальная инспекция для изменений, выполненных по рассматриваемому ЗИ, не проводилась либо такая формальная инспекция завершена и находится в состоянии «Необходимо переделать». Процедура выполнения мероприятия Тест-инженер разрабатывает тестовые примеры в соответствии с методами, изложенными в разделе 2.4.1 данного документа. Следует разрабатывать как тестовые примеры для нормального диапазона, так и робастные тестовые примеры. Если в ходе разработки тестовых примеров или их неформального прогона обнаружены несоответствия во входных данных процесса, то Тест-инженер должен открыть соответствующие СП. По окончании разработки тестовых примеров Тест-инженер помещает их в необходимый репозиторий системы Gitlab. Выбор тестовых примеров для нормального диапазона Назначение тестовых примеров для нормального диапазона – продемонстрировать способность ПО работать при нормальных входных данных и условиях. При разработке тестовых примеров для нормального диапазона необходимо: выделить классы эквивалентности входных данных и разработать тестовые примеры для каждого класса; для временных зависимостей, таких, как фильтры, интеграторы, задержки, предусмотреть итерационные проверки; для требований, выраженных в терминах состояний и переходов, предусмотреть проверки всех допустимых переходов; для требований, содержащих логические условия, предусмотреть проверки всех элементарных логических условий и булевых операций. В одном тестовом примере для нормального диапазона допускается сочетать проверки классов эквивалентности для различных входных данных. Выбор робастных тестовых примеров Назначение робастных тестовых примеров – продемонстрировать устойчивость ПО по отношению к входным данным, выходящим за рамки допустимых диапазонов, и к нештатным условиям эксплуатации. При разработке робастных тестовых примеров необходимо: выделить классы эквивалентности недопустимых значений и разработать тестовые примеры для каждого класса; проверить инициализацию системы при нештатных условиях; выделить возможные виды отказов входных данных; предусмотреть проверки механизмов защиты от превышения установленных времен ответов системы; для требований, выраженных в терминах состояний и переходов, предусмотреть тестовые примеры, в которых производятся попытки осуществления недопустимых переходов. В каждом робастном тестовом примере должны быть проверки не более, чем на одну нештатную ситуацию. Критерии окончания мероприятия Тестовые примеры разработаны, найденные несоответствия во входных данных процесса описаны посредством СП. Тестовые примеры идентифицированы в Gitlab. Выходные данные Тестовые примеры; Сообщения о проблемах Испытания ПО (формальный прогон тестовых примеров) Входные данные План верификации ПО; Исходный код (для испытаний низкого уровня); Тестовые примеры. Критерии начала мероприятия Базовые версии для исходного кода, исполняемого объектного кода и тестовых примеров установлены. Процедура выполнения мероприятия Тест-инженер осуществляет формальный прогон тестовых примеров с использованием соответствующей среды испытаний на базовой версии исполняемого кода. Тест-инженер помещает результаты формального прогона в Yandex Wiki. Каждая версия результатов прогона должна трассироваться на версии тестовых примеров и версии исполняемого объектного кода. Такую трассировку следует осуществлять созданием текстового файла с указанием идентификаторов теста, исполняемого кода и результатов прогона. Если в ходе формального прогона тестовых примеров обнаружены несоответствия во входных данных процесса, то Тест-инженер должен открыть соответствующие СП. Возможно, некоторые несоответствия были обнаружены при предшествующих формальных прогонах. В таких случаях открывать новое СП не требуется, если изменение входных данных, содержащих несоответствие, еще не завершено, т.е. соответствующий ЗИ не достиг состояния «Закрыто». Критерии окончания мероприятия Тестовые примеры прогнаны с использованием соответствующей среды испытаний, найденные несоответствия во входных данных процесса описаны посредством СП. Результаты прогона тестовых примеров идентифицированы в СПР Yandex Wiki. Выходные данные Результаты испытаний ПО; Сообщения о проблемах. Анализ трассировки Входные данные План верификации; Требования к ПО; Описание проекта ПО; Исходный код; Тестовые примеры; Каталог комплектации Критерии начала мероприятия Базовые версии требований к ПО, описания проекта ПО, исходного кода, а также тестовых примеров установлены и включены в Каталог комплектации. Процедура выполнения мероприятия Анализ трассировки проводится в процессе инициализации формальной инспекции Каталога комплектации ПО. В ходе выполнения процесса Менеджер изменений формирует отчет о трассировке средствами Yandex Wiki для текущей версии Каталога комплектации, экспортирует его в формат PDF и присоединяет полученный файл к ФИ Каталога комплектации как вложение. Все виды данных, подлежащие анализу трассировки, перечислены в таблице 6. Таблица 6. Данные, подлежащие анализу трассировки Трассируемые данные (входные) Трассируемые данные (выходные) Требования к системе Требования к ПО высокого уровня Требования к ПО высокого уровня Требования к ПО низкого уровня Требования к ПО низкого уровня Модуль исходного кода Требования к ПО высокого уровня Требования к ПО низкого уровня Процедура испытаний ПО Для всех входных трассируемых данных, не имеющих соответствующих выходных трассируемых данных, Менеджер изменений должен открыть сообщения о проблемах. Критерии окончания мероприятия Таблица трассировки сформирована в Yandex Wiki, там же открыты сообщения о проблемах для всех найденных несоответствий. Выходные данные Протокол анализа трассировки и полноты испытаний; Сообщения о проблемах. Анализ структурного покрытия Входные данные План верификации; Описание проекта ПО; Требования к ПО; Исходный код ПО; Тестовые примеры. Критерии начала мероприятия Все тестовые примеры разработаны, прогнаны с использованием соответствующей среды испытаний. Процедура выполнения мероприятия Инженер создает версию ПО с использованием Visual Studio Code. Инженер прогоняет тестовые примеры на версии ПО, получая данные о структурном покрытии с использованием библиотеки Pytest. На основе полученных данных инженер средствами инструмента Pytest формирует отчет о структурном покрытии, соответствующий уровню критичности верифицируемого ПО. Инженер сравнивает результаты формального прогона тестовых примеров с результатами прогона, полученными на версии ПО, и убеждается, что они совпадают. В противном случае использование полученного отчета о структурном покрытии не допускается. Используя сформированный отчет, инженер проводит анализ структурного покрытия. Каждый случай непокрытия элемента исходного кода следует отнести к одному из следующих классов и при необходимости открыть СП: Неполнота тестовых примеров. Следует открыть СП для принятия решения о модификации существующих или разработке новых тестовых примеров. Неполнота требований. Следует открыть СП для принятия решения либо об удалении кода, для которого не существует требований, либо о модификации существующих или разработке новых требований, позволяющих разработать основанные на требованиях тестовые примеры. Мертвый код. Следует открыть СП для принятия решения об удалении кода. Если для какого-либо случая непокрытия элемента исходного кода уже существует открытое СП, то открывать новое СП, аналогичное по содержанию, не требуется. При выполнении анализа инженер заполняет отчет об анализе структурного покрытия. В отчете должны быть идентифицированы версии требований к ПО, описания проекта ПО, кода и тестов, использованных для получения данных о покрытии, перечислены случаи непокрытия и соответствующие СП. Критерии окончания мероприятия Отчет об анализе структурного покрытия создан и идентифицирован в Yandex Wiki, все найденные несоответствия зафиксированы в сообщениях о проблемах также в Yandex Wiki. Выходные данные Отчет об анализе структурного покрытия; Сообщения о проблемах. Критерии перехода Критерии начала и окончания для каждого из мероприятий процесса верификации ПО описаны в подразделах “Критерии начала мероприятия” и “Критерии окончания мероприятия” соответствующих разделов главы 3. Инструкции повторной верификации Процесс управления конфигурацией ПО гарантирует, что для внесения любого изменения в данные жизненного цикла ПО должно быть создано сообщение о проблеме. При рассмотрении сообщений о проблемах (см. План УК ПО [3]), группа управления изменениями определяет самый ранний этап жизненного цикла ПО, где требуется изменение начинает влиять на результаты выполняемых процессов жизненного цикла ПО и создает запросы на изменения для этого этапа и всех последующих этапов жизненного цикла ПО, затрагиваемых изменениями. Список тестовых примеров, которые следует изменить и/или перепрогнать в связи с изменениями, определяется при рассмотрении сообщений о проблемах. Этот процесс гарантирует, что необходимые изменения будут внесены и верифицированы для каждого из этапов жизненного цикла, начиная с этапа, где изменение начинает влиять на результаты выполнения процесса.