System Life Cycle Process Models: Vee

Líder Autores: Dick Fairley, Kevin Forsberg, Autor Contribuinte: Ray Madachy

Existe um grande número de modelos de processos de ciclo de vida. Como discutido no artigo System Life Cycle Process Drivers and Choices, esses modelos se encaixam em três categorias principais: (1) principalmente processos pré-especificados e seqüenciais; (2) principalmente processos evolutivos e simultâneos (por exemplo, o processo unificado racional e várias formas dos modelos Vee e espiral); e (3) principalmente processos interpessoais e sem restrições (por exemplo, desenvolvimento ágil, Scrum, programação extrema (XP), o método dinâmico de desenvolvimento de sistemas e processos baseados em inovação).

Este artigo foca especificamente no Modelo Vee como o principal exemplo de processos pré-especificados e seqüenciais. Nesta discussão, é importante notar que o modelo Vee, e variações do modelo Vee, todos abordam o mesmo conjunto básico de atividades de engenharia de sistemas (SE). A principal diferença entre esses modelos é a forma como eles agrupam e representam as atividades do SE acima mencionadas.

As implicações gerais do uso do modelo Vee para projeto e desenvolvimento de sistemas são discutidas abaixo; para uma compreensão mais específica de como este modelo de ciclo de vida impacta as atividades de engenharia de sistemas, por favor veja as outras áreas de conhecimento (KAs) na Parte 3.

A Primariamente o Modelo de Processo Sequencial e Pré-especificado: O Modelo Vee

A versão sequencial do Modelo Vee é mostrada na Figura 1. Seu núcleo envolve uma progressão seqüencial de planos, especificações e produtos que são baselinados e colocados sob gerenciamento de configuração. A seta vertical de duas pontas permite aos projetos realizar análises simultâneas de oportunidades e riscos, assim como validação contínua em processo. O Modelo Vee abrange os três primeiros estágios do ciclo de vida listados na tabela “Fases Genéricas do Ciclo de Vida” do Manual de Engenharia de Sistemas INCOSE: pesquisa exploratória, conceito e desenvolvimento (INCOSE 2012).

Figura 1. Lado Esquerdo do Modelo Sequencial Vee (Forsberg, Mooz, e Cotterman 2005). Reproduzido com permissão de John Wiley & Sons Inc. (Sons Inc.). Todos os outros direitos são reservados pelo proprietário dos direitos autorais.

O Modelo Vee endossa a definição do Manual de Engenharia de Sistemas INCOSE (INCOSE 2012) dos estágios do ciclo de vida e seus propósitos ou atividades, como mostrado na Figura 2 abaixo.

Figura 2. Um Exemplo de Etapas, Seus Objetivos e Principais Portões de Decisão. (SEBoK Original)

O Manual de Engenharia de Sistemas INCOSE 3.2.2 contém uma versão mais detalhada do diagrama Vee (2012, Figuras 3-4, p. 27) que incorpora as atividades do ciclo de vida no modelo mais genérico Vee. Um diagrama semelhante, desenvolvido na U.S. Defense Acquisition University (DAU), pode ser visto na Figura 3 abaixo.

Figura 3. O Diagrama de Atividades Vee (Prosnik 2010). Lançado pela Universidade de Aquisição de Defesa (DAU)/ Departamento de Defesa dos EUA (DoD).

>

>

Aplicação do Modelo Vee

Lawson (Lawson 2010) elabora as atividades em cada estágio do ciclo de vida e observa que é útil considerar a estrutura de um modelo genérico de estágio do ciclo de vida para qualquer tipo de sistema de interesse (SoI) conforme retratado na Figura 4. Este modelo (T) indica que um ou mais estágios de definição precedem um estágio de produção onde a implementação (aquisição, provisionamento ou desenvolvimento) de dois ou mais elementos do sistema foi realizada.

Figura 4. Estrutura Genérica (T) dos Modelos de Ciclo de Vida do Sistema (Lawson 2010). Reimpresso com permissão de Harold Lawson. Todos os outros direitos são reservados pelo proprietário dos direitos autorais.

Figure 5 mostra os estágios genéricos do ciclo de vida para uma variedade de partes interessadas, desde uma organização de padrões (ISO/IEC) até organizações comerciais e governamentais. Embora esses estágios sejam diferentes em detalhes, todos eles têm um formato sequencial semelhante que enfatiza as atividades principais, conforme observado na Figura 2 (definição, produção e utilização/aposentadoria).

Figura 5. Comparações de Modelos de Ciclo de Vida (Forsberg, Mooz, e Cotterman 2005). Reimpresso com permissão de John Wiley & Sons. Todos os outros direitos são reservados pelo proprietário dos direitos autorais.

É importante notar que muitas das atividades ao longo do ciclo de vida são iteradas. Este é um exemplo de recursividade (glossário)recursividade (glossário) como discutido na Parte 3 Introdução.

Fundamentals of Life Cycle Stages and Program Management Phase

Para esta discussão, é importante notar que:

• O termo stagestage refere-se aos diferentes estados de um sistema durante seu ciclo de vida; alguns estágios podem se sobrepor no tempo, como o estágio de utilização e o estágio de suporte. O termo “estágio” é usado na ISO/IEC/IEEE 15288.

• O termo fase refere-se às diferentes etapas do programa que suportam e gerenciam a vida do sistema; as fases geralmente não se sobrepõem. O termo “fase” é usado em muitos modelos bem estabelecidos como um equivalente ao termo “fase”,

Gestão do programaA gestão do programa emprega fases, marcos-milestones, e portões de decisão – portões de decisão que são usados para avaliar a evolução de um sistema através das suas várias fases. As etapas contêm as atividades realizadas para alcançar os objetivos e servem para controlar e gerenciar a seqüência de etapas e as transições entre cada etapa. Para cada projeto, é essencial definir e publicar os termos e definições relacionadas utilizadas nos respectivos projetos para minimizar a confusão.

Um programa típico é composto das seguintes fases:

• A fase de pré-estudo, que identifica oportunidades potenciais para atender às necessidades dos usuários com novas soluções que façam sentido para os negócios.
• A fase de viabilidade consiste no estudo da viabilidade de conceitos alternativos para se chegar a uma segunda porta de decisão antes de iniciar a fase de execução. Durante a fase de viabilidade, são identificados os requisitos das partes interessadas e os requisitos do sistema, são identificadas e estudadas soluções viáveis e podem ser implementados protótipos virtuais (glossário) de protótipos (glossário). Durante esta fase, a decisão de avançar é baseada em:
  • se um conceito é viável e é considerado capaz de combater uma ameaça identificada ou explorar uma oportunidade;
  • se um conceito é suficientemente maduro para garantir o desenvolvimento contínuo de um novo produto ou linha de produtos; e
  • se aprovar uma proposta gerada em resposta a um pedido de proposta.
• A fase de execução inclui atividades relacionadas a quatro etapas do ciclo de vida do sistema: desenvolvimento, produção, utilização e suporte. Tipicamente, existem duas portas de decisão e dois marcos associados às atividades de execução. O primeiro marco fornece a oportunidade para a gerência rever os planos de execução antes de dar luz verde para a execução. O segundo marco fornece a oportunidade de rever o progresso antes que a decisão de iniciar a produção seja tomada. Os portões de decisão durante a execução podem ser usados para determinar se o SoI desenvolvido deve ser produzido e se deve ser melhorado ou retirado.

Estas visões de gerenciamento do programa se aplicam não apenas ao SoI, mas também aos seus elementos e estrutura.

Fases do Ciclo de Vida

Variações do modelo Vee tratam das mesmas fases gerais de um ciclo de vida:

• Novos projetos tipicamente começam com uma fase de pesquisa exploratória que geralmente inclui as atividades de definição do conceito, especificamente os tópicos de análise de negócios ou missão e a compreensão das necessidades e requisitos das partes interessadas. Estes amadurecem à medida que o projeto vai da fase exploratória à fase de conceito até a fase de desenvolvimento.
• A fase de produção inclui as atividades de definição e realização do sistema, bem como o desenvolvimento dos requisitos do sistema (glossário)requisitos (glossário) e arquitetura (glossário)arquitetura (glossário) através de verificação e validação.
• A fase de utilização inclui as atividades de implantação e operação do sistema.
• A fase de suporte inclui as atividades de manutenção do sistema, logística e gerenciamento da vida útil do produto e serviço, que podem incluir atividades como extensão de vida útil ou atualizações de capacidade, upgrades e modernização.
• A fase de reforma inclui as atividades de descarte e reforma, embora em alguns modelos, atividades como extensão da vida útil ou atualizações de capacidade, atualizações e modernização sejam agrupadas na fase de “reforma”.

Informações adicionais sobre cada uma dessas fases podem ser encontradas nas seções abaixo (consulte os links para os artigos adicionais da Parte 3 acima para obter mais detalhes). É importante notar que estas fases do ciclo de vida, e as atividades em cada etapa, são suportadas por um conjunto de processos de gerenciamento de engenharia de sistemas.

Etapa de Pesquisa Exploratória

Análise e concordância dos requisitos do usuário é parte da etapa de pesquisa exploratória e é fundamental para o desenvolvimento de sistemas bem sucedidos. Sem uma compreensão adequada das necessidades do usuário, qualquer sistema corre o risco de ser construído para resolver os problemas errados. O primeiro passo na fase de pesquisa exploratória é definir os requisitos e restrições do usuário (e partes interessadas). Uma parte fundamental deste processo é estabelecer a viabilidade de satisfazer os requisitos do utilizador, incluindo a avaliação da prontidão tecnológica. Como em muitas atividades do SE, isso é feito de forma iterativa, e as necessidades e requisitos das partes interessadas são revisados à medida que novas informações se tornam disponíveis.

Um estudo recente do Conselho Nacional de Pesquisa (National Research Council 2008) focado na redução do tempo de desenvolvimento de projetos da Força Aérea Americana. O relatório observa que, “simplesmente afirmou, a engenharia de sistemas é a tradução das necessidades de um usuário em uma definição de um sistema e sua arquitetura através de um processo iterativo que resulta em um projeto de sistema eficaz”. O envolvimento iterativo com as partes interessadas é fundamental para o sucesso do projeto.

Exceto para a primeira e última porta de decisão de um projeto, as portas são realizadas simultaneamente. Ver Figura 6 abaixo.

Figura 6. Agendamento das Fases de Desenvolvimento. (SEBoK Original)

Etapa do Conceito

Durante a etapa do conceito, conceitos alternativos são criados para determinar a melhor abordagem para atender às necessidades das partes interessadas. Ao visualizar alternativas e criar modelos, incluindo protótipos apropriados, as necessidades das partes interessadas serão esclarecidas e as questões de condução serão destacadas. Isto pode levar a uma abordagem incremental ou evolutiva para o desenvolvimento do sistema. Vários conceitos diferentes podem ser explorados em paralelo.

Estágio de desenvolvimento

O(s) conceito(s) selecionado(s) identificado(s) no estágio de conceito são elaborados em detalhes até o nível mais baixo para produzir a solução que atenda aos requisitos das partes interessadas. Ao longo desta etapa, é vital continuar com o envolvimento do usuário através da validação em processo (a seta para cima nos modelos Vee). No hardware, isto é feito com revisões freqüentes do programa e um representante(s) residente(s) do cliente (se apropriado). No desenvolvimento ágil, a prática é ter o representante do cliente integrado na equipe de desenvolvimento.

Estágio de produção

O estágio de produção é onde o SoI é construído ou fabricado. Modificações no produto podem ser necessárias para resolver problemas de produção, para reduzir custos de produção ou para melhorar as capacidades do produto ou do SoI. Qualquer uma dessas modificações pode influenciar os requisitos do sistema e pode exigir a requalificação, a re-validação ou a re-validação do sistema. Todas essas alterações exigem uma avaliação do SE antes que as alterações sejam aprovadas.

Estágio de utilização

Um aspecto significativo do gerenciamento do ciclo de vida do produto é o fornecimento de sistemas de suporte que são vitais para sustentar a operação do produto. Embora o produto ou serviço fornecido possa ser visto como o sistema de interesse estreito (NSOI) para um adquirente, o adquirente também deve incorporar os sistemas de suporte em um sistema de interesse mais amplo (WSOI). Estes sistemas de apoio devem ser vistos como activos do sistema que, quando necessário, são activados em resposta a uma situação que tenha surgido relativamente ao funcionamento do NSOI. O nome coletivo do conjunto de sistemas de apoio é o sistema integrado de apoio logístico (ILS).

É vital ter uma visão holística ao definir, produzir e operar os produtos e serviços do sistema. Na Figura 7, a relação entre o projeto e desenvolvimento do sistema e os requisitos do ILS é retratada.

Figura 7. Relacionando o ILS ao ciclo de vida do sistema (Eichmueller e Foreman 2009). Reimpresso com a permissão do Comitê Diretivo do ASD/AIA S3000L. Todos os outros direitos são reservados pelo proprietário dos direitos autorais.

Os requisitos de confiabilidade, resultando na necessidade de manutenção e testabilidade, são fatores determinantes.

Estágio de Suporte

No estágio de suporte, o SoI é fornecido serviços que permitem a operação contínua. Modificações podem ser propostas para resolver problemas de suporte, para reduzir custos operacionais ou para prolongar a vida útil de um sistema. Estas alterações requerem uma avaliação do SE para evitar a perda das capacidades do sistema enquanto este estiver em operação. O processo técnico correspondente é o processo de manutenção.

Etapa de aposentadoria

Na etapa de aposentadoria, o SoI e seus serviços relacionados são removidos da operação. As atividades do SE nesta etapa estão focadas principalmente em garantir que os requisitos de descarte sejam satisfeitos. Na verdade, o planejamento para o descarte faz parte da definição do sistema durante a fase de conceito. As experiências do século XX demonstraram repetidamente as consequências quando a reforma e o descarte do sistema não foram considerados desde o início. No início do século XXI, muitos países mudaram suas leis para responsabilizar o criador de um SoI pelo descarte adequado do sistema.

Reavaliações do Ciclo de Vida

Para controlar o progresso de um projeto, são planejados diferentes tipos de reavaliações. Os mais comumente usados são listados a seguir, embora os nomes não sejam universais:

• A revisão dos requisitos do sistema (SRR) é planejada para verificar e validar o conjunto de requisitos do sistema antes de iniciar as atividades de projeto detalhado.
• A revisão preliminar do projeto – revisão preliminar do projeto (PDR) está planejada para verificar e validar o conjunto de requisitos do sistema, os artefatos do projeto e elementos de justificação no final do primeiro loop de engenharia (também conhecido como a porta “design-to”).
• A revisão crítica do projeto (CDR) está planejada para verificar e validar o conjunto de requisitos de sistema, os artefatos de projeto e os elementos de justificação no final do último loop de engenharia (os projetos “build-to” e “code-to” são lançados após esta revisão).
• As revisões de integração, verificação, verificação e validação de validação são planejadas à medida que os componentes são montados em subsistemas e elementos de nível superior. Uma sequência de revisões é realizada para assegurar que tudo se integra corretamente e que há evidência objetiva de que todos os requisitos foram cumpridos. Também deve haver uma validação em processo de que o sistema, à medida que evolui, irá satisfazer os requisitos das partes interessadas (ver Figura 7).
• A revisão final de validação é realizada no final da fase de integração.
• Outras revisões relacionadas à gestão podem ser planejadas e conduzidas a fim de controlar o correto progresso do trabalho, com base no tipo de sistema e nos riscos associados.

Figura 8. Lado Direito do Modelo Vee (Forsberg, Mooz, e Cotterman 2005). Reimpresso com permissão de John Wiley & Sons Inc. (Sons Inc.) Todos os outros direitos são reservados pelo proprietário do copyright.

Works Cited

Eichmueller, P. e B. Foreman. 2010. S3000LTM. Bruxelas, Bélgica: Aerospace and Defence Industries Association of Europe (ASD)/Aerospace Industries Association (AIA).

Faisandier, A. 2012. Arquitetura e Design de Sistemas. Belberaud, França: Sinergy’Com.

Forsberg, K., H. Mooz, e H. Cotterman. 2005. Visualizing Project Management, 3ª ed. Nova York, NY, EUA: J. Wiley & Sons.

INCOSE. 2012. Manual de Engenharia de Sistemas: A Guide for System Life Cycle Processes and Activities, versão 3.2.2. San Diego, CA, EUA: Conselho Internacional de Engenharia de Sistemas (INCOSE), INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. Uma Viagem Através da Paisagem dos Sistemas. Londres, UK: College Publications, Kings College, UK.

Primary References

Beedle, M., et al. 2009. “The Agile Manifesto” (O Manifesto Ágil): Principles behind the Agile Manifesto”. in The Agile Manifesto . Acessado em 04 de dezembro de 2014 em www.agilemanifesto.org/principles.html

Boehm, B. e R. Turner. 2004. Equilibrando Agilidade e Disciplina. Nova York, NY, EUA: Addison-Wesley.

Fairley, R. 2009. Gerenciando e Liderando Projetos de Software. Nova York, NY, EUA: J. Wiley & Sons.

Forsberg, K., H. Mooz, e H. Cotterman. 2005. Visualizando Gerenciamento de Projeto. 3rd ed. New York, NY, USA: J. Wiley & Sons.

INCOSE. 2012. Manual de Engenharia de Sistemas: A Guide for System Life Cycle Processes and Activities, versão 3.2.2. San Diego, CA, EUA: Conselho Internacional de Engenharia de Sistemas (INCOSE), INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. Uma Viagem Através da Paisagem dos Sistemas. Kings College, UK: College Publications.

Pew, R., e A. Mavor (eds.) 2007. Integração Homem-Sistema no Processo de Desenvolvimento de Sistemas: Um Novo Olhar. Washington, DC, EUA: The National Academies Press.

Royce, W.E. 1998. Software Project Management: Uma Estrutura Unificada. Nova York, NY, EUA: Addison Wesley.

Referências Adicionais

Anderson, D. 2010. Kanban. Sequim, WA, EUA: Blue Hole Press.

Baldwin, C. e K. Clark. 2000. Regras de Desenho: O Poder da Modularidade. Cambridge, MA, USA: MIT Press.

Beck, K. 1999. Extreme Programming Explained (Programação extrema explicada). Nova York, NY, EUA: Addison Wesley.

Beedle, M., et al. 2009. “The Agile Manifesto”: Principles behind the Agile Manifesto”. in The Agile Manifesto . Acessado em 2010. Disponível em: www.agilemanifesto.org/principles.html

Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, e P. Gruenbacher (eds.). 2005. Engenharia de Software Baseado em Valores. Nova York, NY, EUA: Springer.

Boehm, B. 1988. “A Spiral Model of Software Development.” (Um Modelo Espiral de Desenvolvimento de Software). IEEE Computer 21(5): 61-72.

Boehm, B. 2006. “Algumas Tendências e Implicações Futuras para Processos de Engenharia de Sistemas e Software”. Engenharia de Sistemas. 9(1): 1-19.

Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, e R. Madachy. 1998. “Using the WinWin Spiral Model”: Um Estudo de Caso.” Computador IEEE. 31(7): 33-44.

Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (no prelo). Abraçando o Modelo Espiral: Criando sistemas bem sucedidos com o Modelo Espiral de Compromisso Incremental. Boston, MA, USA: Addison Wesley.

Castellano, D.R. 2004. “Top Five Quality Software Projects”. CrossTalk. 17(7) (Julho 2004): 4-19. Disponível em: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf

Checkland, P. 1981. Pensamento de Sistemas, Prática de Sistemas. New York, NY, USA: Wiley.

Crosson, S. e B. Boehm. 2009. “Adjusting Software Life Cycle Anchorpoints”: Lições Aprendidas em um Sistema de Contexto de Sistemas”. Proceedings of the Systems and Software Technology Conference, 20-23 April 2009, Salt Lake City, UT, USA.

Dingsoyr, T., T. Dyba. e N. Moe (eds.). 2010. “Agile Software Development”: Pesquisa Atual e Direções Futuras”. Capítulo em B. Boehm, J. Lane, S. Koolmanjwong, e R. Turner, Architected Agile Solutions for Software-Reliant Systems. Nova York, NY, EUA: Springer.

Dorner, D. 1996. The Logic of Failure (A Lógica da Falha). Nova York, NY, EUA: Basic Books.

Forsberg, K. 1995. “‘Se eu pudesse fazer isso, então eu poderia…’ Engenharia de Sistemas em um Ambiente de Pesquisa e Desenvolvimento.” Anais do 5º Simpósio Internacional Anual do Conselho Internacional de Engenharia de Sistemas (INCOSE). 22-26 de Julho de 1995. St. Louis, MO, USA.

Forsberg, K. 2010. “Projetos Não Começam com Requisitos”. Anais da IEEE Systems Conference, 5-8 Abril 2010, San Diego, CA, USA.

Gilb, T. 2005. Engenharia Competitiva. Maryland Heights, MO, EUA: Elsevier Butterworth Heinemann.

Goldratt, E. 1984. The Goal. Great Barrington, MA, EUA: North River Press.

Hitchins, D. 2007. Engenharia de Sistemas: Uma Metodologia de Sistemas do Século XXI. Nova York, NY, EUA: Wiley.

Holland, J. 1998. Emergência. Nova York, NY, EUA: Perseus Books.

ISO/IEC. 2010. Engenharia de Sistemas e Software, Parte 1: Guia para Gestão do Ciclo de Vida. Genebra, Suíça: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 24748-1:2010.

ISO/IEC/IEEE. 2015. Engenharia de Sistemas e Software — Processos do Ciclo de Vida do Sistema. Genebra, Suíça: International Organization for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

ISO/IEC. 2003. Engenharia de Sistemas – Um Guia para a Aplicação da ISO/IEC 15288 Processos do Ciclo de Vida do Sistema. Genebra, Suíça: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).

Jarzombek, J. 2003. “Top Five Quality Software Projects”. CrossTalk. 16(7) (Julho de 2003): 4-19. Disponível em: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.

Kruchten, P. 1999. The Rational Unified Process. Nova York, NY, EUA: Addison Wesley.

Landis, T. R. 2010. Lockheed Blackbird Family (A-12, YF-12, D-21/M-21 & SR-71). North Branch, MN, USA: Specialty Press.

Madachy, R. 2008. Software Process Dynamics (Dinâmica de Processos de Software). Hoboken, NJ, USA: Wiley.

Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. “Architecture Reviews”: Prática e Experiência”. IEEE Software. 22(2): 34-43.

National Research Council of the National Academies (USA). 2008. Engenharia de Sistemas Pré-Milestone A e Early-Phase. Washington, DC, EUA: The National Academies Press.

Osterweil, L. 1987. “Software Processes are Software Too.” Anais do SEFM 2011: 9ª Conferência Internacional de Engenharia de Software. Monterey, CA, USA.

Poppendeick, M. e T. Poppendeick. 2003. Desenvolvimento de Software Lean: um Agile Toolkit. Nova York, NY, EUA: Addison Wesley.

Rechtin, E. 1991. Arquitetura de Sistemas: Criando e Construindo Sistemas Complexos. Upper Saddle River, NY, EUA: Prentice-Hall.

Rechtin, E., e M. Maier. 1997. A Arte da Arquitetura de Sistemas. Boca Raton, FL, EUA: CRC Press.

Schwaber, K. e M. Beedle. 2002. Agile Software Development with Scrum. Upper Saddle River, NY, EUA: Prentice Hall.

Spruill, N. 2002. “Top Five Quality Software Projects.” CrossTalk. 15(1) (Janeiro de 2002): 4-19. Disponível em: http://www.crosstalkonline.org/storage/issue-archives/2002/200201/200201-0-Issue.pdf.

Stauder, T. 2005. “Top Five Department of Defense Program Awards.” CrossTalk. 18(9) (Setembro de 2005): 4-13. Disponível em http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.

Warfield, J. 1976. Sistemas Societários: Planejamento, Política e Complexidade. Nova York, NY, EUA: Wiley.

Womack, J. e D. Jones. 1996. Lean Thinking. Nova York, NY, EUA: Simon and Schuster.

Vídeos Relevantes=

• Introdução Básica da Engenharia de Sistemas (Método-V)
• Basic Introduction to Systems Engineering (Método-V) Part 2 of 2