Ciclo de vida de desenvolvimento de produto Axiomatic

Axiomatic Product Development Lifecycle (APDL) (também conhecido como Transdisciplinary System Development Lifecycle (TSDL) e Transdisciplinary Product Development Lifecycle (TPDL) ) é um modelo de desenvolvimento de produto de engenharia de sistemas proposto por Bulent Gumus que estende o método de design Axiomatic (AD). [1] [2] A APDL abrange todo o ciclo de vida do produto , incluindo os fatores iniciais que afetam todo o ciclo, como testes de desenvolvimento, restrições de entrada e componentes do sistema.

A APDL fornece uma maneira iterativa e incremental para uma equipe de membros transdisciplinares abordar o desenvolvimento de produtos holísticos . Um resultado prático inclui capturar e gerenciar o conhecimento de design de produto . O modelo APDL aborda alguns padrões fracos experimentados em modelos de desenvolvimento anteriores em relação à qualidade do design, gerenciamento de requisitos , gerenciamento de mudanças , gerenciamento de projetos e comunicação entre as partes interessadas . A prática de APDL pode reduzir o tempo de desenvolvimento e o custo do projeto .

Visão geral

A APDL adiciona o domínio Teste e quatro novas características ao projeto Axiomático (AD): Restrições de Entrada no Domínio Funcional; Componentes de Sistemas no Domínio Físico; Variáveis ​​de Processo vinculadas a Componentes do Sistema em vez de Parâmetros de Projeto; e Necessidades do Cliente mapeadas para Requisitos Funcionais e Restrições de Entrada.

A APDL propõe um processo em forma de V para desenvolver os Parâmetros de Projeto e Componentes do Sistema (projeto detalhado). Comece de cima para baixo com Variáveis ​​de Processo (PV) e Casos de Teste de Componente (CTC) para concluir o PV, CTC e Casos de Teste Funcional (FTC); E depois de construir, teste o produto com uma abordagem de baixo para cima.

Domínios APDL

Domínio do cliente

As Necessidades do Cliente (NC) são elementos que o cliente busca em um produto ou sistema.

domínio funcional

Os Requisitos Funcionais (FR) caracterizam completamente o desempenho mínimo a ser atendido pela solução de projeto, produto etc. Os FR são documentados nas especificações de requisitos (RS).

As restrições de entrada (IC) estão incluídas no domínio funcional junto com o FR. Os IC são específicos para os objetivos gerais do projeto e são impostos externamente pela CN, usuários do produto ou condições de uso, como regulamentos. IC são derivados do CN e depois revisados ​​com base em outras restrições que o produto deve cumprir, mas não mencionadas no Domínio do Cliente.

domínio físico

Os Parâmetros de Projeto (DP) são os elementos da solução de projeto no domínio físico que são escolhidos para satisfazer os FRs especificados. DPs podem ser soluções de design conceitual, subsistemas, componentes ou atributos de componentes.

Os Componentes do Sistema (SC) fornecem uma solução de design categórico no DP, onde as categorias representam partes físicas no Domínio Físico. A hierarquia SC representa a arquitetura do sistema físico ou a árvore de produtos. O método de categorização varia. Eppinger retrata categorias gerais como sistema, subsistema e componente Eppinger (2001). A NASA usa sistema, segmento, elemento, subsistema, montagem, submontagem e parte (NASA, 1995).

O SC torna possível realizar Matrizes de Estrutura de Projeto (DSM), gerenciamento de mudanças, gerenciamento de custos baseado em componentes e análise de impacto, e fornece uma estrutura para capturar informações estruturais e rastreabilidade de requisitos.

Domínio do processo

Variáveis ​​de Processo (PV) identificam e descrevem os controles e processos para produzir SC.

domínio de teste

Um teste funcional consiste em um conjunto de Casos de Teste Funcional (FTC). FTC são testes de sistema usados ​​para verificar se os FR são atendidos pelo sistema. O teste de caixa preta é o software análogo ao FTC. Ao final do desenvolvimento do sistema, um teste funcional verifica se os requisitos do sistema foram atendidos.

Os casos de teste de componentes (CTC) são um análogo físico do teste de caixa branca . O CTC verifica se os componentes satisfazem os FRs e ICs alocados. Cada componente do sistema é testado antes de ser integrado ao sistema para garantir que os requisitos e restrições atribuídos a esse componente sejam todos atendidos.

Veja também

Referências

  1. ^ Bulent Gumus (2005). Modelo Axiomático de Ciclo de Vida de Desenvolvimento de Produto (APDL) . Dissertação de Doutoramento, TTU, 2005, "Cópia arquivada" (PDF) . Arquivado do original (PDF) em 20/07/2011 . Recuperado 2008-01-22 .{{cite web}}: CS1 maint: cópia arquivada como título ( link )
  2. ^ Suh (1990). The Principles of Design , Oxford University Press, 1990, ISBN 0-19-504345-6 

Leitura adicional

  • B. Gumus, A. Ertas, D. Tate e I. Cicek, Transdisciplinary Product Development Lifecycle , Journal of Engineering Design, 19(03), pp .
  • B. Gumus, A. Ertas e D. TATE, "Estrutura de ciclo de vida de desenvolvimento de produto transdisciplinar e sua aplicação a um sistema aviônico", Conferência integrada de design e tecnologia de processo, junho de 2006.
  • B. Gumus e A. Ertas, "Gestão de Requisitos e Design Axiomático", Journal of Integrated Design and Process Science, vol. 8 Número 4, pp. 19–31, dezembro de 2004.
  • Suh, Complexity: Theory and Applications , Oxford University Press, 2005, ISBN 0-19-517876-9 
  • Suh, Axiomatic Design: Advances and Applications , Oxford University Press, 2001, ISBN 0-19-513466-4