WikiDer > Жизненный цикл разработки продукта Axiomatic

Axiomatic product development lifecycle

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

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

Обзор

APDL добавляет тест домен и четыре новых характеристики аксиоматического дизайна (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).

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

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

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

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

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

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

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

Рекомендации

  1. ^ Бюлент Гумус (2005). Модель жизненного цикла разработки продукта Axiomatic (APDL). Кандидатская диссертация, ТТУ, 2005 г., «Архивная копия» (PDF). Архивировано из оригинал (PDF) на 2011-07-20. Получено 2008-01-22.CS1 maint: заархивированная копия как заголовок (связь)
  2. ^ Suh (1990). Принципы дизайна, Oxford University Press, 1990, ISBN 0-19-504345-6

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

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