CC BY
0
Information Science, Computing Technology and Control
УДК 004.658+621.4:658.5
DOI: 10.18287/2541-7533-2024-23-2-167-177
АКТУАЛЬНОСТЬ ВНЕДРЕНИЯ СИСТЕМЫ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ В ПРОИЗВОДСТВЕННЫЙ ПРОЦЕСС АВИАДВИГАТЕЛЕСТРОИТЕЛЬНОЙ ОТРАСЛИ
© 2024
И. М. Малиновский
А. В. Стародумов
К. А. Мягков
Б. Х. Юсипов
инженер-конструктор расчётно-исследовательского управления;
Опытно-конструкторское бюро им. А. Люльки - филиал публичного
акционерного общества «ОДК - Уфимское моторостроительное
производственное объединение», г. Москва;
аспирант кафедры «Конструкция и проектирование двигателей»;
Московский авиационный институт (национальный исследовательский
университет);
driven95@gmail.com
начальник расчётно-исследовательского управления, руководитель проекта «Цифровой двойник»;
Опытно-конструкторское бюро им. А. Люльки - филиал публичного акционерного общества «ОДК - Уфимское моторостроительное производственное объединение», г. Москва; старший преподаватель кафедры «Конструкция и проектирование двигателей»;
Московский авиационный институт (национальный исследовательский
университет);
andrev-star@vandex.ru
начальник бригады развития технологий проектирования в расчётно-исследовательском управлении, заместитель руководителя проекта «Цифровой двойник»;
Опытно-конструкторское бюро им. А. Люльки - филиал публичного акционерного общества «ОДК - Уфимское моторостроительное производственное объединение», г. Москва; mvagkov k@list.ru
ведущий инженер отдела надёжности;
Опытно-конструкторское бюро им. А. Люльки - филиал публичного
акционерного общества «ОДК - Уфимское моторостроительное
производственное объединение», г. Москва;
аспирант кафедры «Конструкция и проектирование двигателей»
Московский авиационный институт (национальный исследовательский
университет);
Usb83@mail.ru
В процессе проектирования исполнителям необходим доступ к документам с требованиями к изделию. Поиск и обработка этих данных значительно замедляют проектирование изделия. Сокращение затрат времени на проектирование требует наличия соответствующего программного инструмента. В работе рассмотрены программы, способные создать систему управления требованиями, предложена концепция системы управления требованиями, использование которой позволит повысить эффективность процесса проектирования технического изделия. Тестирование отечественных продуктов выявило потенциал этих программ и позволило говорить о возможности внедрения этого программного обеспечения в производственный процесс предприятий авиадвигателестроительной отрасли.
Система управления требованиями; система управления жизненным циклом; база данных; авиадвигателестроительная отрасль; программное обеспечение
Цитирование: Малиновский И.М., Стародумов А.В., Мягков К.А., Юсипов Б.Х. Актуальность внедрения системы управления требованиями в производственный процесс авиадвигателестроительной отрасли // Вестник Самарского университета. Аэрокосмическая техника, технологии и машиностроение. 2024. Т. 23, № 2. С. 167-177. DOI: 10.18287/2541-7533-2024-23-2-167-177
Vestnik of Samara University. Aerospace and Mechanical Engineering
V. 23, no. 2, 2024
При проектировании технически сложных изделий заказчиком предъявляется множество требований, которые содержатся в различных источниках: ГОСТ, ТЗ, договорах поставки и т. д. Большая часть требований - это требования к изделию.
Проектирование изделия - это сложный процесс, который осуществляется множеством исполнителей, каждому исполнителю необходим доступ к большому количеству документов, содержащих требования, предъявляемые к изделию. Поиск и использование этих документов значительно увеличивают продолжительность проектирования изделия, также много времени уходит на поиск требований для осуществления контроля при завершении очередного этапа разработки изделия, ещё одним пунктом затрат времени является реагирование на изменение требований и данных, которые внесены в процессе доводки изделия и изменения потребительских предпочтений [1].
Для повышения производительности предприятия необходимо сокращать затраты времени на проектирование. Задача сбора технических требований к изделию, классификация и контроль дальнейшей реализации в изделии и сопутствующих процессах -непростая, для её решения необходим соответствующий программный инструмент.
Одним из способов повышения производительности является использование открытой, в рамках предприятия, цифровой системы, объединяющей в себе базу данных, со всей необходимой для проектирования документацией, и систему управления этими данными. Подобным функционалом обладают современные системы управления жизненным циклом изделия - PLM (рис. 1), которые подразумевают слаженную работу всех служб предприятия в едином информационном пространстве.
Рис. 1. Структура системы управления жизненным циклом
Разработчиками известных PLM систем, внедрённых в производственные процессы различных предприятий, являются иностранные и отечественные фирмы: Siemens (Teamcenter), Autodesk (PLM 360), Oracle (Agile PLM), PTC (Windchill), Топ системы (T-flex), АСКОН (Лоцман).
Для сбора, классификации и контроля требований необходимо создать систему управления требованиями (СУТ), которая является инструментом повышения эффективности проектирования, и внедрить её в PLM систему [2].
Для повышения эффективности работы с требованиями необходимо следовать изложенной далее концепции СУТ.
Целью внедрения СУТ в производственный процесс предприятия является создание требований и контроль их структуры, изменения, утверждения, правильности, а также соответствия расчётных и экспериментальных данных требованиям, что приве-
Information Science, Computing Technology and Control
дёт к сокращению времени проектирования, уменьшению количества ошибок и повышению эффективности процесса проектирования изделий.
Задачи, решение которых позволит достичь поставленную цель:
- разработка программного обеспечения (ПО), способного создать СУТ;
- разработка инструмента в этом ПО, способного создать и работать с требованиями в виде отдельных информационных объектов и спецификаций;
- разработка инструмента в этом ПО, способного содержать полный перечень требований, предъявляемых к изделию;
- разработка объекта требования, содержащего следующие атрибуты: идентификатор, родительское требование, название требования, условия эксплуатации, единицу измерения, целевое значение, этап жизненного цикла, метод обоснования соответствия, заказчик, исполнитель, источник требования, статус, вид требования и комментарии
[3];
- двухсторонняя связь спецификации требований с чертежами и расчётными моделями узлов и деталей, к которым требования относятся (с автоматической проверкой расчётных параметров на соответствие требованиям);
- двухсторонняя связь спецификации требований с источниками, подтверждающими достоверность и актуальность требований;
- обеспечение доступа к данным СУТ всем исполнителям;
- обеспечение права вносить изменения;
- разработка системы оповещения исполнителя об изменениях данных в СУТ;
- формирование процесса утверждения требования;
- создание механизма изменения утверждённого требования в случае, когда оно утратило актуальность;
- разработка инструмента подтверждения выполняемости требования (подтверждение на основе представления объективных свидетельств того, что объект разработан в соответствии с заданными требованиями);
- разработка инструмента верификации требования (проверка содержания и оформления требований на соответствие установленным критериям качества.);
- обеспечение создания отчётов по требованиям, их верификации и проверки соответствия требованиям расчётных и экспериментальных данных.
В перечисленных выше задачах использованы следующие термины: идентификатор - представляет собой номер требования, состоящий из номера изделия, к которому относится требование, номера системы, номера подсистемы, порядковый номер требования, относящегося ко всем указанным выше пунктам, номер последней версии требования;
родительское требование - общее требование, выполнение которого обеспечивается удовлетворением данного требования;
название требования - свойство объекта, к которому предъявляется требование; условия эксплуатации - режим работы;
единица измерения - величина, измеряющая данное свойство, согласно требованиям международной СИ;
целевое значение - количественное значение свойства, указанного в требовании; этап жизненного цикла - процесс, который в данный момент осуществляется с изделием (проектирование, испытание, эксплуатация);
метод обоснования соответствия - метод, в соответствии с которым будет уточняться требование (расчёт, эксперимент, анализ конструкции и прочее);
заказчик - предъявитель требования, составляющий техническое задание на изделие, выполнение требований к которому нужно обеспечить;
Vestnik of Samara University. Aerospace and Mechanical Engineering
V. 23, no. 2, 2024
исполнитель - обеспечивает контроль и соответствие изделия требованиям;
источник требования - документ или пособие, содержащее перечень требований к изделию;
статус - утверждено, предложено, на рассмотрении;
вид требования - качественное, количественное, функциональное, требование заказчика и прочие виды требований;
комментарии - комментарии к некоторым характерным особенностям требования или методу установления соответствия расчётных или экспериментальных данных требованию.
В данной статье предложен новый подход к созданию СУТ, который заключается в методе классификации требований и их распределения по уровням, реализованном в ОКБ им. А. Люльки при отсутствии в авиадвигателестроительной отрасли однозначной методики формирования спецификаций требований для СУТ, а также рассмотрение развития данной технологии как неотъемлемой части концепции цифрового двойника
(ЦД).
В ходе работы проведён анализ функций, оказывающих помощь в проектировании:
- прозрачный контроль параметров изделия на стадии расчётов и проектирования;
- отслеживание загруженности имеющихся трудовых ресурсов;
- возможности планирования для работ по закрытию внутренних требований, требований государственных стендовых испытаний и прочих.
В рамках данной работы выполнено тестирование отечественного ПО «Лоцман» и «Т-йех» с целью уточнения соответствия этих программ концепции, изложенной выше. Как и мировые лидеры создания PLM систем, ПО «Лоцман» и «Т-йех» включают в себя базу данных и систему управления этими данными. Описание теста, его результаты, сравнение применимости и функциональности этих программ изложено далее. Тест позволил определить функционал представленных отечественными разработчиками приложений и их удобство в использовании для выполнения поставленных задач.
Задачи тестирования ПО представлены в табл. 1:
Таблица 1. Задачи для тестирования системы управления требованиями
№ Задача
1 Внесение требований в систему
2 Отработать процесс изменения требований
3 Отработать процесс утверждения требований
3.1 Отработать процесс частичного утверждения требований
3.2 Отработать процесс изменения требований после утверждения
3.3 Отработать процесс контроля работы над требованиями
3.4 Отработать процесс выдачи задания на изменение утверждённых требований и не утверждённых
3.5 Отработать процесс выдачи задания на разработку требования
4 Внесение в систему расчётных или экспериментальных данных
5 Формирование матрицы соответствия
6 Выпуск спецификации требований из СУТ
7 Формирование заключения по тестированию СУТ
ПО «Лоцман» и «Т-йех» обладают следующим набором объектов:
- спецификация;
- требование;
- источник требования;
- проверка соответствия расчётных и экспериментальных данных требованиям;
- матрица соответствия.
Операции с этими объектами проводятся с помощью бизнес-процессов:
Information Science, Computing Technology and Control
- процесс согласования и утверждения требования;
- процесс выдачи задания на любые операции с требованием;
- процесс изменения утверждённого требования;
- процесс проверки соответствия расчётных и экспериментальных данных требованию.
Спецификация требований классифицируется по уровню требований, а также по их принадлежности к узлам и деталям двигателя. Многоуровневая иерархия спецификации требований нужна для создания логической цепочки между общими требованиями, заданными к изделию в ТЗ, и требованиями к узлам и деталям, обеспечивающими выполнение требований заказчика к изделию, изложенных в ТЗ. Для демонстрации процесса и результата работы, структуры и принципа действия ПО «Лоцман» и «Т-йех», а также более наглядного восприятия вышеизложенного материала ниже представлены окна программы на разных этапах формирования СУТ.
Выполнение поставленных для тестирования задач в ПО «Лоцман» происходило следующим образом. Создаётся рабочая папка, в которой должна находиться спецификация требований, после этого в папке производится создание спецификации требований и её последующее наполнение (рис. 2). Следует отметить, что при работе в системе необходимо постоянно производить смену режима работы, в зависимости от выполняемой задачи (рис. 3).
Создание требования подразумевает внесение его названия, индекса, единицы измерения и так далее. Все эти атрибуты в тестируемом ПО находятся в разных объектах. При формировании спецификации, для создания полноценного требования в нём необходимо создать объекты (характеристика и проверка), содержащие все атрибуты, ха-растеризующие данное требование.
Разделение требований по уровням позволяет определить влияние одного требования на другое. Требование, которое обеспечивает выполнение другого требования, является ему дочерним. Распределение по уровням осуществляется по следующему принципу (рис. 4): родительское требование (зависимое) находится на первом уровне, дочернее требование (влияющее на родительское) на втором, дочернее относительно второго уровня располагается на третьем. Предложенный разработчиками PLM систем метод создания цифровой спецификации подразумевает два этапа классификации требований: сначала - распределение требований по уровням, затем проставление связей влияющих требований с зависимыми. Распределение по уровням осуществляется созданием раздела (группы требований) одного уровня и наполнением этого раздела требованиями, а связь влияющего требования с зависимым проставляется отдельным атрибутом при создании требования, то есть требование содержит в себе ссылку на влияющее, либо зависимое требование и отследить эти связи возможно исключительно открытием окна свойств требования.
В настоящей работе предлагается новый метод формирования цифровой спецификации требований, подразумевающий создание дочернего требования (требования второго уровня) вложением в родительское (требование первого уровня) (рис. 2). Таким образом одним действием осуществляются две операции - распределение требований по уровням и осуществление между ними связи, а так как на изделие может предъявляться несколько тысяч связанных между собой требований различных уровней, такая оптимизация рабочего процесса позволит существенно сократить время сбора требований к изделию. Такой подход к классификации требований также значительно облегчает работу со спецификацией, делая её более наглядной и увеличивая прослеживаемость влияния требований друг на друга.
После создания требований необходимо направлять спецификацию или группу требований на согласование и утверждение, для этого в ПО предусмотрен бизнес-
Вестник Самарского университета. Аэрокосмическая техника, технологии и машиностроение Vestnik of Samara University. Aerospace and Mechanical Engineering_
Т. 23, № 2, 2024 г. V. 23, no. 2, 2024
процесс «Задание». Объект «Задание» также позволяет отправить спецификацию, группу требований или требование на доработку исполнителю, или направить на изменение уже утверждённое требование.
После того как требования или спецификация утверждены осуществляется проверка соответствия расчётных или экспериментальных данных требованиям. Поскольку функционал добавления и хранения расчётных и экспериментальных данных отсутствует, используется объект «Проверка», который создаётся в требовании. Выполнение проверок во всех требованиях спецификации позволяет создать матрицу соответствия, которая показывает результаты проверки соответствия расчётных или экспериментальных данных требованиям (рис. 5).
После вывода матрицы соответствия выводится спецификация требований в формате, предлагаемом разработчиками (рис. 6).
X Условия по числу циклов деталей ТНД должны быть выполнены, версия 1.0 X Требования по вибрационным характеристикам деталей ТНД должны быть выполнены, версия 1X)
"В/
Рабочая лопатка ТНД должна ммпъ запас по сопротивлению усталости профильной части и
удлинительной ножки не менее, версии 1.0
[г] & Предел выносливости рабочей лопатки ТНД должен быть определен экспериментально, версия 1.0
р. у, Собственные частоты рабочих лопаток ТНД в комплекте на установке должны быть определены ^ экспериментально, версия 1.0
р. . Разброс напряжений по рабочим лопаткам ТНД на установке должен быть определен ™ экспериментально, версия 1.0
О £ Резонансные режимы работы ротора ВД должны быть определены экспериментально, версия 1.0
Р| а Уровни напряжений рабочих лопаток ТНД при изменении давлений и температур на входе должны ™ быть определены экспериментально, версия 1.0
р. у, Уровни напряжений рабочих лопаток ТНД при отладке и крайних положениях допусков САУ должны ™ быть определены экспериментально, версия 1.0
|»ч л Уровни напряжений рабочих лопаток ТНД при отборах воздуха должны быть определены ™ экспериментально, версий 1.0
Уровни напряжений рабочих лопаток ТНД в крайних положениях допусков натягов должны быть определены экспериментально, версия 1.0
в/
Рабочая лопатка ТНДдолжнл иметь запвс по сопротивлению усталости замкового соединения не менее.
версия 1.0
> Е) X Предел выносливости рабочей лопатки ТНДдолжен быть определен экспериментально, версия 1,0
р, * Собственные частоты рабочих лопаток ТНД в комплекте на установке должны быть определены ™ экспериментально, версия 1,0
^ |] / Диск ротора ТНДдолжен иметь запас по сопротивлению многоциклоеой усталости не менее, версия 1.0
> Ц[| £ Предел выносливости рабочей лопатки ТНДдолжен быть определен экспериментально, версия 1.0
Состоит из...
^ Состоит из
ф Уточняется.. Ф Влияет на... ф влияет на ...
ф Уточняется.. ф Уточняется -ф Уточняется..
ф Уточняется ..
ф Уточняется
ф Уточняется ..
ф Уточняется..
Ф Влияет на...
ф Влияет на...
Ф Уточняется .. Ф Влияет на ...
Рис. 2. Спецификация требований
Рис. 3. Перечень режимов работы в ПО (компоновок)
Information Science, Computing Technology and Control
Рис. 4. Классификация требований по уровням
1 i 3 4 5 24 10« матрица трассировки: I реоования • контрольны« т< Система управления требованиями к цифровому двор И И 1 Y OBI МИНИНУ изделия
Состояние * X 1 а. X 0 с Контрольный ТОЧКИ Проверки
о о о s s О о о о о о о о о в
Условия функционирования подшипников ТНД должны быть •ЦМЛММЫ в
G ПОДШИПНИК Щ^ОФПИ ""AÇTfr НПК ПО ДОЛгдцч-Н'ФСТИ Hf ftWHft О ✓
109 о tafllNM дисбаланса ротор Л ТНД должна быть н# боя?* о ✓
110 О Мансшшшш температура «мла^отяедпмото от подынаштЛВД. "6 должна приымртьамичину ^пускаемой яогвниимтыа l о ✓
111 О величину ни мгн<к; о
168 169 ?№ < Величин роюра ВЛ полона сост*ил«т. V
&0ли-<ина oGoporo« pO'Opi нд должна СОСТ ЛМИЦ, <9 V
и Лгр4шчи1.1й К ПЛ. ТНД Jin i: «с и гост л я лип. «гличину |'с ^апусмлгмаи а
¿09 о Раскол t* м а юплс CA тнл должен f ост»«л«г». «сличит 11 йОП«И»СЫЮЙ погрсшыосп,« 141 о
210 211 212 о Clcnruu Лрнижгнин^лвлсмив й ТНДдргжмл соСГлилнп. «гличину [С допускаемой погрешность^ 1 4J о V
о »ТМяо^длосэдд^клич^ te доптенкмой погрешностью 1 is} ® V
о ПрОПуСннJH СПОСОБНОСТЬ ТНД ДОЛмнА СОСТЛЦЛЯТь Величину (с йопускасмой погрешностью 14} о ✓
Рис. 5. Матрица соответствия
Спецификация требований к цифровому двойнику изделия
1 Величина оборотов ротора ВД должна составлять
Величина соеротое ротора ВД должна составлять оо мин
Характеристики
№п/ Наименование параметра Единица измерения Значени
1 Частота вращений ротона ВД
2 Величина расхода воздуха, отбираемого от ВЗ КС, должна быть достаточна для охлаждения ТВД
Величина расхода воздуха, отбираемого от ВЗ КС. должна быть достаточна для охлаждения ТВД (. • Сеед)
Характеристики
Наименование параметра Единица измерения Знамени
1 Величина расхоса воздуха, отбираемого от ВЗ КС %
Рис. 6. Вывод из ПО «Лоцман» спецификации требований в отдельный отчётный документ
Вестник Самарского университета. Аэрокосмическая техника, технологии и машиностроение Т. 23, № 2, 2024 г. Vestnik of Samara University. Aerospace and Mechanical Engineering_V. 23, no. 2, 2024
Тестирование ПО «Т-flex» происходило по плану, идентичному тесту ПО «Лоцман», решались аналогичные задачи. Сначала была создана спецификация и наполнена требованиями (рис. 7). В данной программе переключение режима работы происходит автоматически, в зависимости от выполняемой задачи, для смены интерфейса и активации необходимых инструментов, функций и атрибутов. Название, индекс, единица измерения и численная величина в ПО «T-flex», также находятся в разных объектах. При формировании спецификации для создания полноценного требования в нём необходимо создать объекты (требуемая характеристика и проверка соответствия), содержащие все атрибуты, характеризующие данное требование. После создания требований необходимо направлять спецификацию или группу требований на согласование и утверждение, для этого в ПО предусмотрен бизнес-процесс «Задание». Бизнес-процесс «Задание» в ПО «T-flex» обладает темиже возможностями и функциями, что и в ПО «Лоцман»: отправить спецификацию, группу требований или требование на доработку исполнителю, или направить на изменение уже утверждённое требование. После утверждения требований в систему управления данными вносятся результаты расчёта или эксперимента - проверяется соответствие расчётных или экспериментальных данных требованиям. В данном ПО после проверок во всех требованиях спецификации нет возможности создать матрицу соответствия.
Вывод спецификации требований в формат файла PDF выглядит следующим образом (рис. 8).
Е Треневапил
Спецификация требовании к составной части * цифрового
днойника уз'рь "Турбина" изделия
Величина
убораЮН jJ01Qp<J
ВД должна составлять
I ОДвИЧНЫЙ КПДТНД должен ; СрС'ЭвЛЯТЬ ПГ'ЛИЧ.шу (С дш1ускаемш
ППГ|№|11ИЛГ11>Ю
Срсд| 1ий
Выполнено с заме...
Средний
Средний
Рис. 7. Спецификация требований
Текст Номер Код Приоритет Стадия
В ¡Требования
В Спецификация требований к составной части цифрового двойника узла "Турбина" изделия Средний Выполнено с замеч.,
а Величина оборотов ротора ВД должна составлять об/мин 1 Средний Выполнено
□ Первичный КПД ТВД должен составлять величину (с допускаемой погрешностью 10 Средний Выполнено
Рис. 8. Вывод из ПО «T-flex» спецификации требований в отдельный отчётный документ
Information Science, Computing Technology and Control
Выполнив последние операции, которые были запланированы для теста программ с системой управления требованиями, можно подвести итог и представить результаты теста (табл. 2).
Таблица 2. Результаты тестирования
№ Задача ПО «Лоцман» ПО «T-flex»
Результат
1 Внесение требований в систему Выполнено Выполнено
2 Отработать процесс изменения требований Выполнено Выполнено
3 Отработать процесс утверждения требований Выполнено Выполнено
3.1 Отработать процесс частичного утверждения требований Выполнено Выполнено
3.2 Отработать процесс изменения требований после утверждения Выполнено Выполнено
3.3 Отработать процесс контроля работы над требованиями Выполнено Выполнено
3.4 Отработать процесс выдачи задания на изменение утверждённых требований и не утверждённых Выполнено Выполнено
3.5 Отработать процесс выдачи задания на разработку требования Выполнено Выполнено
4 Внесение в систему расчётных или экспериментальных данных Не выполнено Не выполнено
5 Формирование матрицы соответствия Выполнено Не выполнено
6 Выпуск спецификации требований из СУТ Не Выполнено Выполнено
7 Формирование заключения по тестированию СУТ Выполнено Выполнено
Тест СУТ в ПО «Лоцман» позволил определить его основные положительные и отрицательные особенности.
К достоинствам данной программы стоит отнести:
- возможность создания электронной спецификации требований, содержащей информацию о требованиях, их величинах;
- уникальное состояние требований: черновик, согласование, утверждено;
- версионность требований;
- работающие бизнес-процессы отправки требований на проверку, подписание и утверждение требований, запуска заданий на создание и изменение требований;
- инструмент вывода матрицы соответствия (матрица трассировки);
- хорошая техническая поддержка.
Недостатками являются:
- необходимость отслеживать функционал программы при её установке;
- необходимость правильного ручного выбора «Компоновки» для выполнения различных операций;
- отсутствие в требовании необходимых атрибутов, перечисленных в концепции;
- множество манипуляций при создании требований, выдаче заданий, утверждении требований;
- утверждение и подписание каждого названия требования и его характеристики (величины) отдельно;
- визуальная проверка выполняемости требований, при этом значения отображаются каждое в своей компоновке (интерфейсе);
- выводятся только требования верхнего уровня, требования ниже уровнем игнорируются.
На основании проведённого теста СУТ в ПО «Т-йех» можно сформулировать перечень его достоинств и недостатков, что позволит выявить мероприятия, необходимые
Vestnik of Samara University. Aerospace and Mechanical Engineering
V. 23, no. 2, 2024
для совершенствования и повышения эффективности данной программы и разработать новое более эффективное ПО.
В число достоинств выше изученного ПО входят:
- возможность создания электронной спецификации требований, содержащей информацию о требованиях, их величинах;
- уникальная стадия требований: предложено, выполнено, одобрено;
- бизнес-процессы отправки задания и поручения на создание, изменение, проверку, подписание и утверждения требований;
- инструмент вывода спецификации требований;
- хорошая техническая поддержка.
Недостатки ПО «Т-йех»:
- отсутствие в требовании необходимых атрибутов, перечисленных в концепции;
- различные процессы создания требований, выдача заданий, утверждение включают в себя множество манипуляций;
- каждое название требования и его характеристика (величина) утверждается и подписывается отдельно;
- проверка выполняемости требований происходит только визуально, при этом значения требования и расчётных данных в «Проверке» отображаются каждая в своей вкладке;
- отсутствует отображение версии требования;
- матрица соответствия отсутствует.
Заключение
Проведённый тест и сравнительный анализ его результатов позволяет сформулировать следующее заключение. Несмотря на выявленные в ходе тестирования недостатки разработанных систем управления требованиями, программы имеют существенный потенциал в дальнейшем совершенствовании СУТ, их внедрение в производственный процесс позволит повысить эффективность и сократить время проектирования изделия.
Библиографический список
1. Халл Э., Джексон К., Дик Дж. Инженерия требований. М.: ДМК Пресс, 2017.
218 с.
2. Вигерс К., Битти Д. Разработка требований к программному обеспечению. СПб: БХВ, 2019. 736 с.
3. Положение организации П ОДК 423-2021. Управление разработкой. Управление требованиями на стадии разработки изделия. М.: АО «Объединённая двигателе-строительная корпорация», 2021. 46 с.
Information Science, Computing Technology and Control
THE RELEVANCE OF INTRODUCING A REQUIREMENTS MANAGEMENT SYSTEM IN THE PRODUCTION PROCESS OF THE AIRCRAFT ENGINE CONSTRUCTION INDUSTRY
© 2024
Design Engineer, Computation and Research Department; Experimental Design Office named after A. Lyulka, Moscow, Russian Federation;
Postgraduate Student of the Department of Engine Construction and Design; Moscow Aviation Institute (National Research University), Moscow, Russian Federation; driven95@gmail.com
Head of the Computation and Research Department, "Digital Twin" Project Head Manager;
Experimental Design Office named after A. Lyulka, Moscow, Russian Federation; Senior Lecturer, Department of Engine Construction and Design; Moscow Aviation Institute (National Research University), Moscow, Russian Federation; andrey-star@yandex.ru
Head of the Team of Design Technology Development, Computation and Research Department; "Digital Twin" Project Deputy Head Manager; Experimental Design Office named after A. Lyulka, Moscow, Russian Federation; myagkov k@list.ru
Lead Engineer of the Reliability Department;
Experimental Design Office named after A. Lyulka, Moscow, Russian Federation; Postgraduate Student of the Department of Engine Construction and Design; Moscow Aviation Institute (National Research University), Moscow, Russian Federation; Usb83@mail.ru
It is necessary to have access to documents containing product requirements during the design process. Search and processing of this data slows down the product design significantly. The reduction of time losses calls for the availability of a proper software tool. In this work, programs for the creation of requirements management systems are considered. The proposed concept of the requirements management system will make it possible to increase the efficiency of the product design process. The identified potential of the software allows us to talk about the possibility of introducing this program into the production process of enterprises in the aircraft engine industry.
Requirements management system; life cycle management; database; aircraft engine industry; software
Citation: Malinovskiy I.M., Starodumov A.V., Myagkov K.A., Yusipov B.Kh. The relevance of introducing a requirements management system in the production process of the aircraft engine construction industry. Vestnik of Samara University. Aerospace and Mechanical Engineering. 2024. V. 23, no. 2. P. 167-177. DOI: 10.18287/2541-7533-2024-232-167-177
References
1. Hull E., Jackson K., Dick J. Requirements engineering. London: Springer, 2002. 216 p. DOI: 10.1007/978-1-4471-3730-6
2. Wiegers K., Beatty J. Software requirements. Washington: Microsoft Press, 2013. 639 p.
3. P ODK 423-2021. Development management. Requirements management at the product development stage. Moscow: Joint Stock Company «United Engine Corporation» Publ., 2021. 46 p. (In Russ.)
I. М. Malinovskiy
A. V. Starodumov
K. A. Myagkov
B. Kh. Yusipov
