Жизненный цикл разработки продукта Axiomatic - Axiomatic product development lifecycle

Axiomatic Product Development Lifecycle (APDL) (также известный как Transdisciplinary System Development Lifecycle (TSDL) и Transdisciplinary Product Development Lifecycle (TPDL) ) - это модель разработки продукта системной инженерии, предложенная Bulent Gumus, которая расширяет метод Axiomatic Design (AD). APDL охватывает весь жизненный цикл продукта, включая ранние факторы, влияющие на весь цикл, такие как тестирование разработки, ограничения ввода и системные компоненты.

APDL предоставляет коллективу трансдисциплинарных членов итеративный и поэтапный способ подойти к целостной разработке продукта. Практический результат включает сбор и управление знаниями о дизайне продукта . Модельные адреса APDL некоторые слабые модели опыт предыдущих моделей развития в отношении качества проектирования, управления требованиями , управление изменениями , управление проектами , и связь между заинтересованными сторонами . Использование APDL может сократить время разработки и стоимость проекта .

Обзор

APDL добавляет в Axiomatic Design (AD) тестовую область и четыре новые характеристики: входные ограничения в функциональной области; Компоненты систем в физической области; Переменные процесса, привязанные к компонентам системы, а не к параметрам проекта; и потребности клиентов, сопоставленные с функциональными требованиями и ограничениями ввода.

APDL предлагает V-образный процесс для разработки параметров проектирования и компонентов системы (детальный проект). Начните сверху вниз с переменных процесса (PV) и тестовых примеров компонентов (CTC), чтобы завершить PV, CTC и функциональные тесты (FTC); А после сборки протестируйте продукт снизу вверх.

APDL домены

Домен клиента

Потребности клиента (CN) - это элементы, которые клиент ищет в продукте или системе.

Функциональная область

Функциональные требования (FR) полностью характеризуют минимальную производительность, которой должно соответствовать проектное решение, продукт и т. Д. FR документируются в технических требованиях (RS).

Входные ограничения (IC) включены в функциональную область вместе с FR. IC специфичны для общих целей проектирования и навязываются извне CN, пользователями продукта или условиями использования, такими как правила. IC выводятся из CN, а затем пересматриваются с учетом других ограничений, которым должен соответствовать продукт, но не упомянутых в Домене клиента.

Физический домен

Параметры проекта (DP) - это элементы проектного решения в физической области, которые выбираются для удовлетворения заданных FR. DP могут быть концептуальными проектными решениями, подсистемами, компонентами или атрибутами компонентов.

Системные компоненты (SC) обеспечивают категориальное проектное решение в DP, где категории представляют физические части в физической области. Иерархия SC представляет собой архитектуру физической системы или дерево продукта. Методы категоризации различаются. Эппингер изображает общие категории как систему, подсистему и компонент Eppinger (2001). НАСА использует систему, сегмент, элемент, подсистему, сборку, подсборку и деталь (НАСА, 1995).

SC позволяет выполнять матрицы структуры проекта (DSM), управление изменениями, управление затратами на основе компонентов и анализ воздействия, а также обеспечивает основу для сбора структурной информации и отслеживания требований.

Область процесса

Переменные процесса (PV) идентифицируют и описывают средства управления и процессы для создания SC.

Тестовый домен

Функциональный тест состоит из набора наборов функциональных тестов (FTC). FTC - это системные тесты, используемые для проверки соответствия FR системой. Тестирование черного ящика - это программный аналог FTC. В конце разработки системы функциональный тест проверяет соответствие требованиям системы.

Сценарии тестирования компонентов (CTC) являются физическим аналогом тестирования белого ящика . CTC проверяет соответствие компонентов выделенным FR и IC. Каждый компонент системы тестируется перед интеграцией в систему, чтобы убедиться, что все требования и ограничения, назначенные этому компоненту, удовлетворены.

Смотрите также

Ссылки

дальнейшее чтение

  • Б. Гумус, А. Эртас, Д. Тейт и И. Чичек, Трансдисциплинарный жизненный цикл разработки продукта , Журнал инженерного проектирования, 19 (03), стр. 185–200, июнь 2008 г. doi : 10.1080 / 09544820701232436 .
  • Б. Гумус, А. Эртас и Д. ТЕЙТ, «Трансдисциплинарная концепция жизненного цикла разработки продукта и ее применение в системе авионики», Конференция по интегрированному проектированию и технологическим процессам, июнь 2006 г.
  • Б. Гумус и А. Эртас, «Управление требованиями и аксиоматический дизайн», Журнал интегрированного проектирования и науки о процессах, Vol. 8 Номер 4, стр. 19–31, декабрь 2004 г.
  • Сух, Сложность: теория и приложения , Oxford University Press, 2005, ISBN  0-19-517876-9
  • Сух, Аксиоматический дизайн: достижения и приложения , Oxford University Press, 2001, ISBN  0-19-513466-4