Базовая версия
2026-03-20T18:37:01+00:00
Вкладка 1
Введение
Цель
Данный документ определяет мероприятия, которые будут выполняться в рамках создания Системы управления требованиями для достижения целей процесса управления конфигурацией ПО, определенных в документе КТ-178B.
Область применения
Требования и положения настоящего плана распространяются на все работы, выполняемые в рамках создания Системы управления требованиями, и обязательны для всех участников.
Ссылки
КТ-178В. Квалификационные требования. Часть 178В. Требования к ПО бортовой аппаратуры и систем при сертификации авиационной техники.
План разработки ПО.
План верификации ПО.
Стандарт на кодирование ПО
Yandex Wiki Docs. Руководство пользователя программного продукта. Инструкция по применению.
Yandex Tracker Docs. Руководство пользователя программного продукта. Инструкция по применению.
Термины, определения и соглашения
Таблица 1. Термины, определения и соглашения
Термин
Определение, толкование
Сообщение о проблеме
Документ процесса УК ПО, содержащий описание несоответствия в данных ЖЦ ПО или в описании процессов ЖЦ ПО.
Запрос на изменение
Документ процесса УК ПО, созданный для внесения изменений в данные ЖЦ ПО с целью устранения несоответствия, описанного в СП.
Артефакт
Атомарное данное ЖЦ ПО. Артефактом может быть, например, требование или файл исходного кода
Конфигурация
Составное данное ЖЦ ПО, которое может включать в себя любые артефакты, агрегации и конфигурации
Формальная инспекция
Способ верификации документов, основанный на экспертной оценке их правильности, выполняемой одним или несколькими инспекторами, как правило, с использованием проверочных перечней. Её проводит преподаватель, т.к. реального заказчика не существует
Единица конфигурации
Совокупность данных ЖЦ ПО, которая в целях УК ПО рассматривается как единое целое.
Тип единицы конфигурации
Тип документов ЖЦ ПО, соответствует разделам 11.1 – 11.20 КТ-178В
Yandex Wiki
Система управления базами знаний предназначенная для внутреннего использования в компаниях разработки ПО.
Git
Распределённая система контроля версий
Gitlab
Веб-сервис для хостинга и совместной разработки проектов, использующий Git в качестве системы контроля версий
Merge conflict
Проблема, возникающая при слиянии веток, связанная с наличием в сливаемых ветках разных изменений в одних и тех же файлах.
Индексированные файлы
Это файлы, отслеживаемые git, текущие версии которых были добавлены в список изменений для следующего commit‘а при помощи команды add
Таблица 2. Сокращения
Термин
Определение, толкование
ГК
Гарантия качества
ГУИ
Группа управления изменениями
ЕК
Единица конфигурации
ЖЦ
Жизненный цикл
ЗНИ
Запрос на изменение
МИ
Менеджер изменений
ПО
Программное обеспечение
СП
Сообщение о проблеме
УК
Управление конфигурацией
ФИ
Формальная инспекция
Среда управления конфигурацией ПО
Инструменты УК ПО
В качестве среды управления конфигурацией ПО используется Gitlab. Gitlab - это веб-сервис для хостинга и совместной разработки проектов, использующий Git в качестве системы контроля версий.
Единицы конфигурации хранятся в git-репозиториях, представляющих собой каталоги файловой системы, содержащие файлы конфигурации репозитория, файлы журналов, хранящие операции, выполняемые над репозиторием, индекс, описывающий расположение файлов, и хранилище отслеживаемых файлов. Участники проекта могут клонировать репозитории, тем самым обеспечивается тиражируемость документации и исполняемого кода.
Gitlab хранит полную историю изменений проекта в виде наборов состояний - коммитов. В случае необходимости любое из состояний проекта может быть восстановлено. Состояние может быть выбрано в качестве очередной базовой версии разрабатываемого продукта. Версия может только увеличиваться при движении вперед по истории состояний.
В Gitlab новые задачи или проблемы, возникающие в течение жизненного цикла ПО, фиксируются в системе отслеживания задач. Вносимые в проект изменения могут быть одобрены и добавлены в последнюю актуальную версию ПО только после прохождения процедуры ревью и тестирования.
Организация и ответственность
Все участники процесса разработки так или иначе вовлечены в процесс УК ПО. В течение процесса реализации ПО существуют разные наборы ролей в зависимости от контекста. В данном случае рассматриваются роли, связанные с доступом к репозиториям и с выполнением задачи.
Каждый участник проекта в рамках процесса УК ПО может иметь одну или несколько ролей:
Роли, дающие определенные полномочия касательно доступа к репозиториям:
Owner (владелец). Имеет полномочия на просмотр репозиториев и запись в них, а также владеет полными правами администратора;
Maintainer (сопровождающий). Имеет полномочия на просмотр репозиториев и запись в них, а также владеет частичными правами администратора;
Developer (разработчик). Имеет полномочия на просмотр репозиториев и запись в них;
Guest (гость). Не имеет полномочий на просмотр содержимого репозиториев;
Reporter (репортер). Имеет полномочия на просмотр репозиториев;
Роли, дающие определенные полномочия касательно определенной задачи:
Author (автор задачи). Особых полномочий не имеет, фактически является заказчиком;
Commiter (создатель commit’а). Имеет полномочия на просмотр и редактирование содержимого репозиториев, создание commit’ов; кроме того, commiter может иметь ограниченные права (например, никто из commiter’ов не имеет прав на создание commit’ов в master);
Assignee (исполнитель задачи). Имеет полномочия на создание merge request’ов, всегда является commiter’ом для своей задачи;
Approver (утверждающий). Имеет полномочия на утверждение merge request’ов, то есть на слияние ветки master и ветки с изменениями;
Participant (участник задачи). Особых полномочий не имеет, фактически является тем, кто как-либо поучаствовал в жизненном цикле задачи, и имеет одну из следующих ролей: commiter, assignee, approver, author.
Единицы конфигурации
Единицей конфигурации является единица передачи части системы между участниками процесса. Единица конфигурации имеет набор последовательных версий, каждая из которых имеет собственный идентификатор. Список единиц конфигурации:
Задача. Задача представлена сущностью issue в gitlab. Задача однозначно идентифицируется по её номеру (он автоматически присваивается задаче при создании в gitlab). Кроме того задача имеет имя, которое не обязательно уникально. Если две задачи имеют одинаковое имя, их номера нужно интерпретировать также как своеобразные идентификаторы версий, однако такие ситуации не желательны. Версий в классическом понимании у задач нет. Вместо этого существует история обсуждения задачи.
Merge request. Merge request является запросом на слияние веток в gitlab. Merge request идентифицируется так же, как и задача, то есть имеет уникальный номер и название, которое может быть не уникальным. Также как и для задачи существует история обсуждения merge request’а. Кроме того, merge request всегда создается в ходе решения задачи, то есть существует сюръективное отображение множества задач на множество merge request’ов.
Отдельное требование. Отдельное требование представлено одной или несколькими строками в файле. Идентификация требований описана в Стандарте на разработку требований. Идентификаторами версий отдельного требования являются идентификаторы версий файла, его содержащего, в которых вносились изменения в это требование.
Класс. Класс представлен структурой с прикрепленными методами языка Python или классом языка TypeScript. Класс идентифицируется по названию. Версии класса идентифицируются теми идентификаторами версий файла, в которых производились изменения в коде описывающем класс. Если код, относящийся к одному классу находится в нескольких файлах, то идентификатором является кортеж из идентификаторов файлов.
Функция. Функция представлена кодом функции на языке Python или TypeScript. Функция идентифицируется именем пакета и именем функции в Python или именем файла и именем функции в TypeScript. Версии функции идентифицируются теми идентификаторами версий файла, содержащего функцию, в которых производились изменения в коде функции.
Артефакт проектирования. Описание артефакта проектирования содержится в стандарте на проектирование. Чаще всего он представлен схемой или диаграммой (расположенными в отдельном файле). Идентификатором артефакта на проектирование является название файла. Версия артефакта на проектирование идентифицируется через идентификатор версии файла, содержащего его.
Взаимодействие УК ПО с другими процессами ЖЦ ПО
Все процессы разработки ПО и интегральные процессы взаимодействуют посредством процесса УК ПО, таким образом, все данные, создающиеся или модифицирующиеся в ходе выполнения процессов разработки ПО и интегральных процессов, являются входными данными для процесса УК ПО, все процессы разработки ПО и интегральные процессы получают входные данные из процесса УК ПО.
Управление конфигурацией требований к системе осуществляется с помощью GitLab.
Мероприятия процесса УК ПО
Идентификация конфигурации
Цель мероприятия по идентификации конфигурации – однозначно определить каждую единицу конфигурации (ЕК), включая ее последовательные версии, для того, чтобы обеспечить основу для управления единицами конфигурации и возможность ссылаться на них.
Для идентификации единиц конфигурации и их версий могут использоваться следующие вспомогательные сущности:
Файл. Файл представляет из себя индексированный системой контроля версий git текстовый или бинарный файл, загруженный на gitlab. Идентификатором файла является его расположение и имя. Для идентификации версии служит хэш последнего commit’а, в котором был изменен файл.
Репозиторий. Репозиторий является местом, где хранятся и поддерживаются взаимосвязанные данные. В данном случае - это репозиторий gitlab, содержащий в себе структуру из папок и файлов. Идентификатором репозитория является его адрес. Идентификатором версии репозитория является кортеж из идентификаторов версий последних commit’ов в каждой ветке репозитория. Идентификация таких единиц конфигурации как задача и merge request происходит средствами gitlab при их создании (их создание регламентировано дальнейшими разделами документа). Идентификация остальных единиц конфигурации использует идентификаторы соответствующих файлов и происходит при помощи git при их добавлении или изменении по следующему алгоритму:
Участник проекта локально создает файл в папке репозитория или вносит изменения в существующий файл.
Созданный файл добавляется в commit при помощи команды git add.
В директории .git/objects/ создается блоб-файл, который содержит сжатый добавляемый файл, располагается в папке .git/objects/<first 2 symbols of commit hash> и имеет имя, являющееся остальной частью упомянутого ранее хэша.
Файл добавляется в индекс - список, содержащий все файлы (хранится в .git/index), где каждый файл представлен как комбинация .
Таким образом мы можем получить данные необходимые для вышеописанной идентификации файла и его версии.
Базовые версии и трассируемость
Правила введения новых версий
Различные базовые версии проекта вводятся следующим образом:
Базовая версия репозитория. Базовая версия репозитория представлена последним commit’ом в ветке master, то есть меняется при каждом новом изменении, занесенным в master, и идентифицируется хэшом commit’а.
Базовые версии единиц конфигурации. Базовые версии ЕК совпадают с той базовой версией репозитория, при которой были внесены изменения и эти ЕК.
Релизная версия проекта. Так как используется каскадная модель жизненного цикла, то новая релизная версия проекта будет вводиться при завершении разработки текущей части проекта. Некоторому коммиту присваивается специальный тег, символизирующий очередную базовую версию приложения. Для этого предназначена команда git tag. Номер новой версии формируется в соответствии со спецификацией Semantic Versioning 2.0.0 [5]. Согласно этому стандарту номер формируется в соответствии с шаблоном MAJOR.MINOR.PATCH. MAJOR - целое число номера версии, увеличивающееся при релизе обновлений, несовместимых с предыдущими. MINOR - целочисленный идентификатор номера версии, увеличивающийся при внесении обратно совместимых изменений функционала. PATCH - идентификатор версии, увеличивающийся только при внесении обратно совместимых изменений функционала для исправления некорректного поведения.
Базовая версия для review. Базовая версия для review представлена последним в истории определённого merge request commit’ом и идентифицируется хэшом этого commit’а.
Базовая версия для merge в master. Базовая версия для merge в master представлена commit’ом, соответствующим тем же требованиям, что и в случае с базовой версией для review, но после rebase.
Контроль библиотек ПО
Управление библиотеками ПО будет осуществляться с помощью пакетных менеджеров. В JavaScript используется npm, а в Python pip. В специальных конфигурационных файлах указываются все библиотеки, от которых зависит данное ПО и версии этих библиотек. При сборке проекта пакетный менеджер устанавливает библиотеки нужных версий.
Библиотеки js скачиваются из стандартного хранилища npm: https://registry.npmjs.org/ (этот источник используется по умолчанию; его изменение в настройках npm в рамках данного проекта запрещено). npm использует конфигурационный файл с именем package.json.
Для скачивания всех зависимостей, указанных в package.json, необходимо в директории с этим файлом использовать команду npm install. При этом пакеты будут загружены из источника, указанного в настройках npm (то есть из https://registry.npmjs.org/, если не был изменён источник по умолчанию).
Пример package.json файла:
{
"dependencies": {
"vue": "2.5.2"
}
}
Для Python библиотеки записываются в файле requirements.txt. Для установки всех зависимостей, указанных в requirements.txt, необходимо в директории с этим файлом использовать команду pip install -r requirements.txt.
Пример файла requirements.txt:
fastapi==0.95.2
greenlet==1.1.2
h11==0.14.0
httpcore==0.17.0
Трассируемость
Трассируемость единиц конфигурации осуществляется встроенными механизмами Gitlab.
Трассируемость требований к ПО высокого уровня на системные требования осуществляется с помощью установления связи идентификаторов между соответствующими единицами конфигурации.
Трассировка между функциями кода (являющимися частью ЕК исходного кода) и требованиями реализуется посредством введения трассировочной информации в тело ЕК исходного кода: шапка каждой функции исходного кода должна содержать идентификаторы ЕК проекта ПО и требований к ПО, реализованных в данной функции, в формате, определенном в Стандарте на кодирование.
Трассируемость между предыдущей и последующей версиями единицы конфигурации устанавливается с помощью запросов на изменения и истории изменений, сохраняющейся в Gitlab для каждой единицы конфигурации.
Трассируемость между базовыми версиями единицы конфигурации устанавливается в рамках процесса управления изменениями.
Трассируемость между причинами изменений и изменениями устанавливается с помощью связи сообщений о проблемах и запросов на изменения.
Регистрация проблем
При возникновении проблемы заводится issue с специальной меткой type::Incident. Issue является отдельной сущностью системы gitlab и представляет собой сообщение о проблеме. Для того, чтобы добавить issue, необходимо в меню gitlab выбрать вкладку Issues и далее нажать New issue. После этого нужно заполнить поля в соответствии с тем, как это описано в данном документе и нажать Submit issue.
Issue оформляется по шаблону Suggestion, который можно выбрать при ее создании (выпадающее меню Choose template около заголовка issue):
Краткое описание. (Краткое изложите найденную ошибку)
Действия по воспроизведению. (Как можно воспроизвести проблему - это очень важно)
Текущее ошибочное поведение. (Что на самом деле происходит)
Какое ожидаемое правильное поведение? (Что вы должны увидеть вместо этого)
Соответствующие логи и/или скриншоты. (Используйте форматирование для логов. Это сильно повысит читаемость)
Возможные исправления. (Если есть предположения, то указание на строку кода, которая может быть ответственна за проблему)
Список единиц конфигурации и их версий, в которых несоответствие было обнаружено.
Любое предполагаемое изменение в данных ЖЦ ПО, в том числе и не связанное с устранением проблем (например, добавление новой функциональности), также обрабатывается через сообщение о проблеме. В этом случае описание проблемы заполняется по шаблону Task:
Расположение. link
Задача. (Полная формулировка задачи)
Дополнительно. (Некоторые дополнительные сведения)
Зависимости. (Какие другие issue необходимо выполнить, прежде чем начинать эту задачу)
Управление изменениями
Цель мероприятий управления изменениями – обеспечить регистрацию, оценку, принятие решений и утверждение изменений в течение жизненного цикла ПО.
Процесс управления изменениями организуется следующим образом:
Assignee ищет в списке текущих issue то, в котором он находится в списке Assignees. Issue создаются на этапе регистрации проблем.
Assignee присваивает этому issue метку stage::InProgress, обозначая, что issue взята в разработку, и создает merge request, который автоматически помечается флагом Work in progress (WIP). Автоматически создается ветка, которая должна содержать будущие изменения. Её название указано на странице merge request’а в блоке Request to merge into master. В качестве исходной версии изменяемой единицы конфигурации будет выступать последняя на данный момент версия, находящаяся в ветке master.
Assignee вносит изменения в рамках поставленной issue. Есть два варианта: локально и на gitlab.
Внесение изменений локально:
Предполагается, что мероприятие идентификации конфигурации уже выполнено.
Необходимо обновить состояние локального репозитория при помощи команды git pull.
Переключиться на ветку, соответствующую решаемой issue: git checkout <branch_name>. Название ветки указано на странице с merge request в блоке Request to merge into master.
Далее Assignee должен изменить текст в файлах так, как это указано в issue.
После должен выполнить git status и убедиться, что не внесено лишних изменений.
При помощи команды git add <file_path> добавить все файлы, в которых требовались изменения. В случае, если изменились только нужные файлы, выполнить команду git add --all. Если необходимо откатить изменения в файле или в нескольких файлах в некоторой папке, то можно выполнить git checkout -- <path>.
После необходимо закоммитить изменения путём выполнения команды git commit -m ”<commit_message>”. Текст, написанный в commit_message, должен удовлетворять следующему регулярному выражению: ˆIssue #\d+: .+. В 12 секции \d+ необходимо указать номер issue, которая выполняется в рамках данного коммита.
Передать коммит (или несколько коммитов) в общий репозиторий при помощи git push.
Внесение изменений через Gitlab Web IDE:
Идентификация конфигурации выполняется автоматически.
Открыть Gitlab Web IDE можно при помощи кнопки Open Web IDE на странице с merge request, либо нажав кнопку Edit на странице с интересующим файлом.
Внести изменения в требуемые файлы.
Нажать кнопку Commit....
В открывшемся окне дважды нажать левой кнопкой мыши по файлам, изменения в которых необходимо добавить в коммит.
Убедиться, что изменения будут переданы в нужную ветку. Выбор ветки производится при помощи радио-кнопок в нижней части. Из предложенных вариантов можно выбрать внесение в текущую ветку или создание новой.
Записать сообщение коммита, удовлетворяющее регулярному выражению: ˆIssue #\d+: .+. В секции \d+ необходимо указать номер issue, которая выполняется в рамках данного коммита.
Нажать кнопку Stage&Commit.
Рекомендации:
При внесении изменений в markdown-файлы можно использовать Gitlab Web IDE, так как это может сэкономить время.
При внесении изменений в исходный код проекта Gitlab Web IDE не рекомендуется использовать, однако её использование позволительно для внесения небольших изменений (переименование файла, изменение 3-5 строк кода).
На странице с merge request снять флаг WIP: из заголовка нажатием кнопки Resolve WIP status. После начинается мероприятие рассмотрения изменений.
Примечания касательно отклонения от стандартной процедуры:
В случае, если в ходе выполнения issue возникают сложности, которые Assignee не в состоянии разрешить самостоятельно, он присваивает ей метку stage::Problem и описывает в комментариях к issue суть проблемы. Затем может позвать других членов команды к обсуждению получившейся проблемы.
В случае, если необходимость внесения изменений, соответствующих issue, в ходе разработки проекта оказалось под сомнением, и issue уже долгое время остается в числе открытых, но не выполненных, метка важности такой issue меняется на priority::Optional и в комментариях к issue решается вопрос о её удалении или актуализации.
Рассмотрение изменений
Рассмотрение изменений происходит следующим образом:
При добавлении коммитов в репозиторий (в случае push'а в master или в ветку, которая является исходной для текущего merge request'a) инструмент continuous integration (CI) начинает установку зависимостей, сборку проекта и запускает автотесты.
Commiter проверяет, что сборка успешна. Если во время сборки или тестирования возникают ошибки, то Commiter должен внести дополнительные изменения, исправляющие выявленные ошибки, либо обратиться к другому члену команды за помощью.
Commiter на странице с merge request убирает префикс WIP: из заголовка merge request’a, показывая, тем самым, что изменения, которые он внёс, готовы к ревью. Это можно сделать путём нажатия на кнопку Resolve WIP status.
Author регулярно просматривает состояние merge request’ов. Когда появляется merge request, готовый к ревью, Author назначает Approver’а для данного merge request’а. Commiter не может получить роль Approver’а.
Approver фиксирует выявленные ошибки в виде комментариев к merge request’у. Если ошибки были найдены, то Approver добавляет в описание merge request префикс WIP: путём непосредственного редактирования описания merge request’а, либо при помощи записи команды /wip в комментарии к merge request’у.
Commiter вносит дополнительные изменения, устраняющие выявленные ошибки, и добавляет их в свой merge request. Если Approver считает, что issue полностью решена, а изменения не содержат ошибок, они нажимают кнопку Approve на merge request. Это значит, что изменения можно добавлять в основную версию проекта.
Оповещение о том, что ревью завершено приходит на электронную почту Author’а. После этого он должен выполнить rebase ветки merge request’а по отношению к ветке master. Либо при помощи соответствующей кнопки на странице с merge request, либо через консоль следующими командами: git checkout <branch_name> && git rebase master && git push -f. Если в процессе rebase возникают конфликты, то Author самостоятельно принимает решение об их исправлении. Если это решение принять невозможно, то он обсуждает его с Commiter’ом и Approver’ом.
Хранение, воспроизведение и выпуск
Все данные ЖЦ хранятся в облаке Gitlab, а также в локальных репозиториях участников проекта. В связи с этим:
средствами gitlab регулируются права доступа к данным ЖЦ. Возможные права доступа описаны в разделе “Организация и роли”.
файлы, хранящиеся в git-репозитории не могут быть повреждены или искажены со временем.
у каждого члена проекта имеется собственная локальная копия всего git-репозитория (возможно, не самой последней версии), что минимизирует риски утраты наиболее важных данных.
Контроль загрузки ПО
Загрузка ПО не проводится.
Контроль среды ЖЦ
Актуальные версии единиц конфигурации расположены основной ветке проекта ( ветке master ). Доступ к инструментам:
редактор Visual Studio Code с официального сайта (https://code.visualstudio.com/download)
средство построения диаграмм https://www.draw.io/
платформа Node.js с официального сайта (https://nodejs.org/en/download/)
пакетный менеджер Npm загружается автоматически с Node.js
интерпретатор языка Python с официального сайта (https://www.python.org/downloads/)
пакетный менеджер Pip устанавливается вместе с Python автоматически.
платформа для ведения базы знаний организации Yandex Wiki (https://wiki.yandex.ru/)
Учет состояния конфигурации
Учет состояния конфигурации обеспечивается непосредственно Gitlab.
Документы управления конфигурацией
Сообщения о проблемах и запросы на изменения - issue и merge request
История изменений - git-репозиторий.
Критерии перехода
Процесс УК ПО начинается одновременно с процессом планирования создания ПО и заканчивается с выпуском последней версии ПО.