Управление требования ALM против PDM
Большинство современных технических систем являются мехатронными, и по мимо традиционных механических систем состоят из систем электрических, электронных и программного обеспечения.
По способу физической реализации технически системы состоят из систем физических (для простоты будем называть их аппаратными) и систем программных.
Аппаратные системы имеют имеют физическое воплощение (они имеют форму, их можно потрогать, у них есть масса и т.д.). Программные системы имею реализацию только в цифровом виде (в виде программного кода).
Жизненный цикл (в том числе разработка) программных и аппаратных систем имеет свою специфику, поэтому для поддержки процессов жизненного цикла используются различные информационные системы:
PDM
PDM-система (англ. product data management — система управления данными об изделии) — организационно-техническая система, обеспечивающая управление всей информацией об изделии. При этом в качестве изделий могут рассматриваться различные сложные технические объекты (корабли и автомобили, самолёты и ракеты, компьютерные сети и др.).
Ключевая задача: Централизованное хранение и контроль всех данных, связанных с физическим воплощением продукта. Это единый источник истины о том, из чего и как продукт сделан.
Чем традиционно управляет PDM:
- Конструкторская документация
- Технологическая документация
- Различные виды состава изделия (как спроектировано, как производится, как изготовлено)
- Данные о проектах и процессах
- Данные о выпусках версий и изменениях
- Взаимосвязи между компонентами
Основные функции:
- Управление версиями и конфигурацией: Отслеживание, какая версия детали или сборки является актуальной.
- Управление изменениями: Регламентированный процесс внесения и утверждения изменений в конструкцию (работа с запросами на изменение).
- Управление структурой изделия (BOM): Создание и управление структурами изделия (конструкторская BOM, производственная BOM).
- Совместная работа: Обеспечение того, чтобы инженеры работали с актуальными версиями файлов и не перезаписывали работу друг друга.
- Поиск и повторное использование: Быстрый поиск существующих компонентов для их повторного использования в новых проектах.
Типичные пользователи: Инженеры-конструкторы, технологи, проектировщики.
Примеры систем: Teamcenter, ENOVIA, Windchill, ЛОЦМАН:PLM
ALM
ALM (Application Lifecycle Management) жизненным циклом разработки программного обеспечения (исходный код, требования, тесты для встроенного ПО и ПО).
Чем управляет ALM:
- Требования к программному обеспечению
- Исходный код
- Тест-кейсы и результаты тестирования
- Задачи и баги (баг-трекинг)
- Результаты сборок (билды)
- Документация для разработчиков
- Артефакты развертывания (дистрибутивы)
Основные функции:
- Управление требованиями: Создание, отслеживание и связывание требований с задачами и кодом.
- Управление исходным кодом (SCM): Системы контроля версий, такие как Git (являются частью ALM-экосистемы).
- Управление задачами и багами: Планирование спринтов, постановка задач, отслеживание ошибок (например, через Jira, который является инструментом ALM).
- Непрерывная интеграция и доставка (CI/CD): Автоматизация сборки, тестирования и развертывания кода.
- Тест-менеджмент: Создание и выполнение тестов, отслеживание покрытия требований тестами.
- Трассируемость: Возможность проследить связь от высокоуровневого требования через код и тесты до конкретной сборки ПО.
Типичные пользователи: Разработчики ПО, тестировщики (QA), бизнес-аналитики, DevOps-инженеры.
Примеры систем: Devprom, Polarion, Jira + дополнительные плагины, IBM Engineering Lifecycle Management.
К сожалению, в отечественных реалиях, наблюдается тенденция когда ALM-системы используются для управления данными относящимися не только к программным но и аппаратным системам. В первую очередь, это относится к требованиям. Распространенным явлением является фиксация, согласование, управление версиями требований, а так же сбор доказательной документации о выполнении требований к аппаратным системам в ALM-решениях.
Причины такой тенденции понятны, однако, современные PLM-решения, и PDM-системы в частности, давно изменили свое отношение к работе с требованиями. Сегодня, поддержку процессов работы с требованиями заявляет каждая уважающая себя PDM-система.
Практики управления требованиями нашли широкое применение при разработке информационных систем, поэтому ALM-системы традиционно уделяли функционалу работы с требованиями особое внимание. В противовес им, управление требованиями при разработке аппаратных систем и их поддержка в рамках PLM-решений всегда находилась в тени других задач (управление составом изделия, управление нормативно-справочной информацией и д.р.) и особой функциональность не отличалась.
Многие ALM системы имеют современный пользовательский интерфейс, в том числе для работы с требованиями, чем дополнительно привлекают к себе потенциальных пользователей.
Почему же для управления требованиями к аппаратным системам не рекомендуется использовать ALM-системы?
Управление требованиями это не обособленная задача, в процессе жизненного цикла изделия, требования находят свою реализацию сначала в конструкторской документации, а потом и в виде физических экземпляров изделия.
Для контроля выполнения требований, необходимо понимать:
- где в конструкции изделия требование реализуется;
- как реализация требования в конструкции доказывается;
- как доказывается реализация требования на основе натурных испытаний физических экземпляров.
Для этого необходимо обеспечить информационные связи между требованиями и реализующими их, на разных стадиях жизненного цикла, результатами.
Как отмечено выше, управление данными о ЖЦ аппаратных систем, выполняется c помощью PLM-решений, а конкретно в PDM-системе" живут" данные о составе изделия, данные о геометрии, технологии, выполненных расчетов испытаний и т.д. Поэтому и требования к изделию должны "жить" в PDM-системе. В этом случае обеспечиваются прямые информационные связи требований с реализующими или доказывающими их данными.
Требования к аппаратными системам, находящиеся в ALM-системе, ни чего знают о данных в PDM-системе, которые:
- Реализуют требования (архитектура, конструкторская документация);
- Валидируют требования (например, данные предварительных CAE-расчетов);
- Влияют на изменение требований (например, изменения в конструкторской документации);
- Доказывают выполнение требований (данные CAE-расчетов, результаты натурных испытаний).
Чаще всего, связь между требованиями к аппаратным системам из ALM и КД к аппаратным системам в PDM, односторонняя. Например, при необходимости выполнить анализ цепочки данных, например: Требование 1 (ALM) - КД 1 (PDM) - Требование 2 (ALM) - КД 2 (PDM). Вы столкнетесь с проблемой, что КД 1 не знает ни чего про требование 2, это требование 2 знает про то что у него есть связь с КД 1 и КД 2 в PDM.
Чтобы КД в PDM знало о требованиях в ALM, требуется сложное интеграционное решений, результатом которого, по факту будет повторение в PDM, функционала управления требованиями аналогичного ALM, что автоматически ставит под вопрос необходимость работы с требованиями к аппаратным системам в ALM, раз ими можно управлять в PDM.
Если резюмировать сказанное, то управление требованиями к аппаратным системам в ALM имеет следующие недостатки:
- Невозможность обеспечить сквозную трассируемость данных между требованиями к аппаратным системам в ALM и всеми данными об аппаратных системах в PDM.
- Невозможность сквозного анализа влияния изменений между требованиями к аппаратным системам в ALM и всеми данными аппаратных систем в PDM.
- Невозможность построения суммарных отчетов о статусе выполнения требований в разрезе данных, формируемых из двух системы.
Вы получаете информационный разрыв между данными которые описывают изделие. Требования к аппаратным системам в ALM, без связи с данными в PDM-системе, не будут иметь практической ценности, кроме управления требованиями ради управления требованиями.
Выводы
- PDM — это про материальный мир (конструкция, детали, сборки).
- ALM — это про цифровой мир (логика системы управления, код, поведение).
Обе системы критически важны для создания сложных изделий. Они не конкурируют, а дополняют друг друга, и их интеграция является ключевым фактором успеха в современной инженерии.
Как PDM и ALM работают вместе?
Рассмотрим взаимодействие PDM и ALM на приеме кофемашины
- В PDM системе хранится спецификация исходных требований к кофемашине;
- В PDM системе, для каждого требования (или набора связанных требований) планируются процедуры верификации и валидации результатов;
- На основании исходных требований разрабатывается архитектура кофемашины, включающая:
- сценарии использования;
- описание окружения;
- описание функций;
- реализация функций в компонентах;
- способы реализации компонентов (программная или аппаратная реализация);
- описание взаимодействия между компонентами (сценарии, межкомпонентный обмен) - В процессе разработки архитектуры формируются требования к составным частям, в том числе к требования к системе управления, эти требования хранятся в PDM-системе как часть общей спецификации требований к изделию.
- Для ранней верификации, на основании описания архитектуры, разрабатывается 1D модель кофемашины, с помощью которой определяется соответствие архитектуры, заданным требованиям.
- Требования к системе управления, через интеграционные механизм из PDM передаются в ALM-систему.
- В ALM системе на основании исходных требований системе управления и описания ее места в общей архитектуре, выполняется декомпозиция требований, выполняется разработка программной архитектуры.
- В ALM системе выполняется разработка алгоритмов управления, программного кода системы управления.
- В ALM системе разрабатываются процедуры тестирования результатов на соответствие требованиям
- Алгоритмы системы управления могут быть валидированы с использованием 1D модели объекта управления, для этого, алгоритмы передаются как входные данные для проведения тестирования
- После валидации алгоритмов выполняется разработка программного кода и его валидация на основе 1D модели объекта управления.
- Когда разработка и тестирование системы управления завершены, в ALM создается артефакт — готовая к установке прошивка.
- Параллельно, под управлением PDM-системы разрабатывается конструкторская документация (3D модели механических электрических и система, разрабатываются электронные блоки, схемы и модели плат)
- При получении из ALM-системы, утвержденной версии прошивки системы управления, она передается в PDM-систему и связывается с актуальной версией КД на электронный блок
- При возникновении изменений, например добавлении нового требования "звуковое уведомление о готовности кофе", формируется набор изменений, в том числе новые требования к системе управления передаются в ALM систему, где выполняются необходимые доработки
- Информация о новой версии ПО попадает в PDM (через интеграцию между системами или вручную) и обновляется в спецификации (BOM). Теперь конструкторы видят, что для сборки кофемашины требуется новая версия прошивки.
- При выпуске нового изделия или обновлении существующих используется актуальная BOM из PDM, которая ссылается на корректную версию ПО из ALM.
