Аксиоматический жизненный цикл разработки продукта

Аксиоматический жизненный цикл разработки продукта (APDL) (также известный как трансдисциплинарный жизненный цикл разработки системы (TSDL) и трансдисциплинарный жизненный цикл разработки продукта (TPDL) ) — это модель разработки продукта системной инженерии, предложенная Бюлентом Гумусом, которая расширяет метод аксиоматического проектирования (AD). ^[1]^[2] APDL охватывает весь жизненный цикл продукта, включая ранние факторы, которые влияют на весь цикл, такие как тестирование разработки, входные ограничения и компоненты системы.

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

Обзор

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

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

Домены APDL

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

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

Функциональный домен

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

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

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

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

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

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

Домен процесса

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

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

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

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

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

Ссылки

^ Бюлент Гумус (2005). Аксиоматическая модель жизненного цикла разработки продукта (APDL) . Кандидатская диссертация, TTU, 2005, "Архивная копия" (PDF) . Архивировано из оригинала (PDF) 20 июля 2011 г. 20. Получено 22 января 2008 г.{{cite web}}: CS1 maint: архивная копия как заголовок ( ссылка )
^ Suh (1990). Принципы дизайна , Oxford University Press, 1990, ISBN 0-19-504345-6

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

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

[1] Бюлент Гумус (2005). Аксиоматическая модель жизненного цикла разработки продукта (APDL) . Кандидатская диссертация, TTU, 2005, "Архивная копия" (PDF) . Архивировано из оригинала (PDF) 20 июля 2011 г. 20. Получено 22 января 2008 г.{{cite web}}: CS1 maint: архивная копия как заголовок ( ссылка )

[2] Suh (1990). Принципы дизайна , Oxford University Press, 1990, ISBN 0-19-504345-6