Ciclo de vida axiomático del desarrollo de productos

El ciclo de vida de desarrollo de productos axiomático ( APDL ), también conocido como ciclo de vida de desarrollo de sistemas transdisciplinarios ( TSDL ) y ciclo de vida de desarrollo de productos transdisciplinarios ( TPDL ), es un modelo de desarrollo de productos de ingeniería de sistemas propuesto por Bulent Gumus que extiende el método de diseño axiomático (AD). ^{[ 1 ] [ 2 ]} APDL cubre todo el ciclo de vida del producto, incluidos los factores iniciales que afectan a todo el ciclo, como las pruebas de desarrollo, las restricciones de entrada y los componentes del sistema.

APDL proporciona un método iterativo e incremental para que un equipo transdisciplinario aborde el desarrollo holístico de productos. Un resultado práctico es la captura y gestión del conocimiento del diseño del producto . El modelo APDL corrige algunas deficiencias de modelos de desarrollo anteriores en cuanto a la calidad del diseño, la gestión de requisitos , la gestión del cambio , la gestión de proyectos y la comunicación entre las partes interesadas . La aplicación de APDL puede reducir el tiempo de desarrollo y el coste del proyecto .

APDL añade el dominio de pruebas y cuatro nuevas características al diseño axiomático (AD): restricciones de entrada en el dominio funcional; componentes del sistema en el dominio físico; variables de proceso vinculadas a componentes del sistema en lugar de parámetros de diseño; y necesidades del cliente mapeadas a requisitos funcionales y restricciones de entrada.

APDL propone un proceso en forma de V para desarrollar los parámetros de diseño y los componentes del sistema (diseño detallado). Se comienza de arriba hacia abajo con las variables de proceso (PV) y los casos de prueba de componentes (CTC) para completar los PV, CTC y los casos de prueba funcionales (FTC); y después de la construcción, se prueba el producto con un enfoque de abajo hacia arriba.

Dominio del cliente

Las necesidades del cliente (NC) son los elementos que el cliente busca en un producto o sistema.

Dominio funcional

Los requisitos funcionales (RF) caracterizan completamente el rendimiento mínimo que debe cumplir la solución de diseño, el producto, etc. Los RF se documentan en las especificaciones de requisitos (ER).

Las restricciones de entrada (CI) se incluyen en el dominio funcional junto con las restricciones funcionales (RF). Las CI son específicas de los objetivos generales de diseño y son impuestas externamente por la CN, los usuarios del producto o las condiciones de uso, como las normativas. Las CI se derivan de la CN y luego se revisan en función de otras restricciones que el producto debe cumplir, pero que no se mencionan en el dominio del cliente.

Dominio físico

Los parámetros de diseño (PD) son los elementos de la solución de diseño en el dominio físico que se eligen para satisfacer los requisitos funcionales (RF) especificados. Los PD pueden ser soluciones de diseño conceptuales, subsistemas, componentes o atributos de componentes.

Los componentes del sistema (CS) proporcionan una solución de diseño categórica en el dominio físico (DP), donde las categorías representan partes físicas en dicho dominio. La jerarquía de CS representa la arquitectura del sistema físico o el árbol del producto. El método de categorización varía. Eppinger describe las categorías generales como sistema, subsistema y componente (Eppinger, 2001). La NASA utiliza los términos sistema, segmento, elemento, subsistema, ensamblaje, subensamblaje y pieza (NASA, 1995).

SC permite realizar matrices de estructura de diseño (DSM), gestión de cambios, gestión de costes basada en componentes y análisis de impacto, y proporciona un marco para capturar información estructural y trazabilidad de requisitos.

Dominio del proceso

Las variables de proceso (VP) identifican y describen los controles y procesos para producir la cadena de suministro (CS).

Dominio de prueba

Una prueba funcional consiste en un conjunto de casos de prueba funcionales (CPF). Los CPF son pruebas de sistema que se utilizan para verificar que el sistema cumpla con los requisitos funcionales (RF). Las pruebas de caja negra son el equivalente en software a los CPF. Al finalizar el desarrollo del sistema, una prueba funcional verifica que se cumplan los requisitos del mismo.

Los casos de prueba de componentes (CTC) son un análogo físico de las pruebas de caja blanca . Los CTC verifican que los componentes cumplan con los requisitos funcionales (FR) y las restricciones de integración (IC) asignados. Cada componente del sistema se prueba antes de su integración para asegurar que se cumplan todos los requisitos y restricciones asignados a dicho componente.

• Ciclo de vida del desarrollo de sistemas
• Desarrollo de nuevos productos
• Gestión del ciclo de vida del producto
• Proceso de diseño de ingeniería
• Diseño y construcción
• Entrega integrada de proyectos

• B. Gumus, A. Ertas, D. Tate e I. Cicek, Ciclo de vida del desarrollo de productos transdisciplinarios , Journal of Engineering Design, 19(03), pp.  185–200, junio de 2008. doi : 10.1080/09544820701232436 .
• B. Gumus, A. Ertas y D. Tate, "Marco de ciclo de vida de desarrollo de productos transdisciplinario y su aplicación a un sistema de aviónica", Conferencia sobre tecnología de diseño y procesos integrados, junio de 2006.
• B. Gumus y A. Ertas, "Gestión de requisitos y diseño axiomático", Journal of Integrated Design and Process Science, vol. 8, número 4, págs.  19-31, diciembre de 2004.
• Suh, Complejidad: Teoría y aplicaciones , Oxford University Press, 2005, ISBN 0-19-517876-9
• Suh, Diseño axiomático: avances y aplicaciones , Oxford University Press, 2001, ISBN 0-19-513466-4