El ciclo de vida de desarrollo de producto axiomático (APDL) (también conocido como ciclo de vida de desarrollo de sistema transdisciplinario (TSDL) y ciclo de vida de desarrollo de producto transdisciplinario (TPDL) ) es un modelo de desarrollo de producto 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 primeros factores que afectan todo el ciclo, como las pruebas de desarrollo, las restricciones de entrada y los componentes del sistema.
APDL ofrece una forma iterativa e incremental para que un equipo de miembros transdisciplinarios aborde el desarrollo holístico de productos. Un resultado práctico incluye la captura y gestión del conocimiento de diseño de productos . El modelo APDL aborda algunos patrones débiles experimentados en modelos de desarrollo anteriores con respecto a la calidad del diseño, la gestión de requisitos , la gestión de cambios , la gestión de proyectos y la comunicación entre las partes interesadas . La práctica de APDL puede reducir el tiempo de desarrollo y el costo del proyecto .
APDL agrega el dominio de prueba y cuatro nuevas características al diseño axiomático (AD): restricciones de entrada en el dominio funcional; componentes de sistemas 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 asignadas 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 compilación, se prueba el producto con un enfoque de abajo hacia arriba.
Las necesidades del cliente (CN) son elementos que el cliente busca en un producto o sistema.
Los requisitos funcionales (FR) caracterizan completamente el rendimiento mínimo que debe cumplir la solución de diseño, el producto, etc. Los FR se documentan en las especificaciones de requisitos (RS).
Las restricciones de entrada (IC) se incluyen en el dominio funcional junto con las restricciones de entrada. Las IC son específicas de los objetivos generales de diseño y son impuestas externamente por CN, los usuarios del producto o las condiciones de uso, como las regulaciones. Las IC se derivan de 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.
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 FR especificados. Los PD pueden ser soluciones de diseño conceptual, subsistemas, componentes o atributos de componentes.
Los componentes del sistema (SC) proporcionan una solución de diseño categórica en el DP, donde las categorías representan partes físicas en el dominio físico. La jerarquía de SC representa la arquitectura del sistema físico o el árbol de productos. El método para categorizar varía. Eppinger describe las categorías generales como sistema, subsistema y componente (Eppinger, 2001). La NASA utiliza sistema, segmento, elemento, subsistema, ensamblaje, subensamblaje y parte (NASA, 1995).
SC permite realizar Matrices de Estructura de Diseño (DSM), gestión de cambios, gestión de costos basada en componentes y análisis de impacto, y proporciona un marco para capturar información estructural y trazabilidad de requisitos.
Las variables de proceso (PV) identifican y describen los controles y procesos para producir SC.
Una prueba funcional consiste en un conjunto de casos de prueba funcionales (FTC). Los FTC son pruebas del sistema que se utilizan para verificar que el sistema cumple con los requisitos de rendimiento. Las pruebas de caja negra son el análogo del software a los FTC. Al final del desarrollo del sistema, una prueba funcional verifica que se cumplan los requisitos del sistema.
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 de componentes y componentes asignados. Cada componente del sistema se prueba antes de integrarlo en el sistema para asegurarse de que se cumplan todos los requisitos y las restricciones asignadas a ese componente.
{{cite web}}: CS1 maint: copia archivada como título ( enlace )