Войти
Жизненный цикл разработки продукта Axiomatic (APDL) (также известный как жизненный цикл трансдисциплинарной разработки системы (TSDL) и трансдисциплинарный жизненный цикл разработки продукта (TPDL) ) - это системная инженерия Модель разработки продукта, предложенная Бюлент Гумус, расширяет метод Аксиоматического дизайна (AD). APDL охватывает весь жизненный цикл продукта, включая ранние факторы, влияющие на весь цикл, такие как тестирование разработки, ограничения ввода и системные компоненты.
APDL предоставляет итеративный и инкрементный способ для команды трансдисциплинарных членов подойти к целостной разработке продукта. Практический результат включает получение и управление знаниями о продукте проектирования. Модель APDL устраняет некоторые слабые шаблоны, использованные в предыдущих моделях разработки в отношении качества проектирования, управления требованиями, управления изменениями, управления проектами и общение между заинтересованными сторонами. Использование APDL может сократить время разработки и стоимость проекта.
APDL добавляет тест и четыре новые характеристики в аксиоматический дизайн (AD): входные ограничения в функциональной области; Компоненты систем в физической области; Переменные процесса, привязанные к системным компонентам, а не к параметрам проекта; и потребности клиентов, сопоставленные с функциональными требованиями и ограничениями ввода.
APDL предлагает V-образный процесс разработки проектных параметров и компонентов системы (детальный проект). Начните сверху вниз с переменных процесса (PV) и тестовых примеров компонентов (CTC), чтобы завершить PV, CTC и функциональные тесты (FTC); А после сборки протестируйте продукт снизу вверх.
Потребности клиента (CN) - это элементы, которые заказчик ищет в продукте или системе.
Функциональные требования (FR) полностью характеризуют минимальные характеристики, которым должно соответствовать проектное решение, продукт и т. Д. FR задокументированы в технических требованиях (RS).
Вход Ограничения (IC) включены в функциональную область вместе с FR. IC специфичны для общих целей проектирования и навязываются извне CN, пользователями продукта или условиями использования, такими как правила. IC выводятся из CN, а затем пересматриваются с учетом других ограничений, которым должен соответствовать продукт, но не упомянутых в Домене клиента.
Параметры проекта (DP) - это элементы проектного решения в физической области, которые выбираются для удовлетворения заданных FR. DP могут быть концептуальными проектными решениями, подсистемами, компонентами или атрибутами компонентов.
Системные компоненты (SC) обеспечивают категориальное проектное решение в DP, где категории представляют физические части в физической области. Иерархия SC представляет собой физическую системную архитектуру или дерево продуктов. Методы категоризации различаются. Эппингер описывает общие категории как систему, подсистему и компонент Эппингер (2001). НАСА использует систему, сегмент, элемент, подсистему, сборку, подсборку и деталь (НАСА, 1995).
SC позволяет выполнять Матрицы структуры проекта (DSM), управление изменениями, компонентное управление затратами и анализ воздействия, а также обеспечивает основу для сбора структурной информации и отслеживания требований.
Переменные процесса (PV) идентифицируют и описывают средства управления и процессы для создания SC.
Функциональный тест состоит из набора функциональных тестовых случаев (FTC). FTC - это системные тесты, используемые для проверки соответствия FR системой. Тестирование черного ящика является программным аналогом FTC. В конце разработки системы функциональный тест проверяет соответствие требованиям системы.
Сценарии тестирования компонентов (CTC) являются физическим аналогом тестирования белого ящика. CTC проверяет соответствие компонентов выделенным FR и IC. Каждый компонент системы тестируется перед интеграцией в систему, чтобы убедиться, что все требования и ограничения, назначенные этому компоненту, удовлетворены.
