Axiomatic Product Development Lifecycle (APDL) (также известный как Transdisciplinary System Development Lifecycle (TSDL) и Transdisciplinary Product Development Lifecycle (TPDL) ) - это модель разработки продукта системной инженерии, предложенная Bulent Gumus, которая расширяет метод Axiomatic Design (AD). [1] [2] 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 представляет собой архитектуру физической системы или дерево продукта. Методы категоризации различаются. Эппингер изображает общие категории как систему, подсистему и компонент Эппингер (2001). НАСА использует систему, сегмент, элемент, подсистему, сборку, подсборку и деталь (НАСА, 1995).
SC позволяет выполнять матрицы структуры проекта (DSM), управление изменениями, компонентное управление затратами и анализ воздействия, а также обеспечивает основу для сбора структурной информации и отслеживания требований.
- Область процесса
Переменные процесса (PV) идентифицируют и описывают средства управления и процессы для создания SC.
- Тестовый домен
Функциональный тест состоит из набора наборов функциональных тестов (FTC). FTC - это системные тесты, используемые для проверки соответствия FR системой. Тестирование черного ящика - это программный аналог FTC. В конце разработки системы функциональный тест проверяет соответствие требованиям системы.
Сценарии тестирования компонентов (CTC) являются физическим аналогом тестирования белого ящика . CTC проверяет соответствие компонентов выделенным FR и IC. Каждый компонент системы тестируется перед его интеграцией в систему, чтобы убедиться, что все требования и ограничения, назначенные этому компоненту, удовлетворены.
Смотрите также
Рекомендации
- ^ Бюлент Gumus (2005). Модель жизненного цикла разработки продукта Axiomatic (APDL) . Кандидатская диссертация, ТТУ, 2005, «Архивная копия» (PDF) . Архивировано из оригинального (PDF) 20 июля 2011 года . Проверено 22 января 2008 . CS1 maint: не рекомендуется параметр ( ссылка ) CS1 maint: заархивированная копия как заголовок ( ссылка )
- ^ Suh (1990). Принципы дизайна , Oxford University Press, 1990, ISBN 0-19-504345-6
дальнейшее чтение
- Б. Гумус, А. Эртас, Д. Тейт и И. Чичек, Трансдисциплинарный жизненный цикл разработки продукта , Журнал инженерного проектирования, 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