Modelos do Ciclo de Vida

Autores Líderes: Kevin Forsberg, Rick Adcock, Autor Contribuinte: Alan Faisandier

O modelo do ciclo de vida é um dos conceitos-chave da engenharia de sistemas (SE). Um ciclo de vida para um sistema de sistemas geralmente consiste de uma série de etapas reguladas por um conjunto de decisões gerenciais que confirmam que o sistema está maduro o suficiente para sair de uma etapa e entrar em outra.

Tópicos

Cada parte do SEBoK está dividida em áreas de conhecimento (KAs), que são agrupamentos de informação com um tema relacionado. As KAs, por sua vez, estão divididas em tópicos. Esta KA contém os seguintes tópicos:

• Condutores e Escolhas de Processos do Ciclo de Vida do Sistema
• Modelos de Processos do Ciclo de Vida do Sistema: Vee
• System Life Cycle Process Models (Modelos de Processos do Ciclo de Vida do Sistema): Iterativo
• Integração de Modelos de Processo e Produto
• Engenharia do Sistema

Veja o artigo Matriz de Exemplos de Implementação para um mapeamento de estudos de caso e vinhetas incluídas na Parte 7 para tópicos cobertos na Parte 3.

Tipo de Produtos/Serviços de Valor Agregado

O Modelo de Ciclo de Vida Genérico mostra apenas a abordagem de um único passo para prosseguir através das etapas do ciclo de vida de um sistema. Adicionar valor (como um produto, um serviço ou ambos), é um propósito compartilhado entre todas as empresas, públicas ou privadas, com ou sem fins lucrativos. O valor é produzido pelo fornecimento e integração dos elementos de um sistema em um produto ou serviço de acordo com a descrição do sistema e sua transição para o uso produtivo. Estas considerações de valor conduzirão a várias formas da abordagem genérica de gestão do ciclo de vida na Figura 1. Alguns exemplos são os seguintes (Lawson 2010):

• Uma empresa de manufatura produz porcas, parafusos e produtos de lavagem de fechaduras e depois vende seus produtos como elementos de valor agregado para serem usados por outras empresas; por sua vez, essas empresas integram esses produtos em seu sistema de valor agregado mais abrangente, como uma aeronave ou um automóvel. Seus requisitos serão geralmente pré-especificados pelo cliente ou pelos padrões da indústria.

• Uma empresa de atacado ou varejo oferece produtos aos seus clientes. Seus clientes (particulares ou empresas) adquirem os produtos e os utilizam como elementos em seus sistemas. O sistema de suporte empresarial irá provavelmente evoluir oportunisticamente, à medida que novas capacidades de infra-estrutura ou padrões de demanda surgirem.

>

• Uma empresa de serviços comerciais como um banco vende uma variedade de produtos como serviços aos seus clientes. Isto inclui contas correntes, contas poupança, empréstimos e gestão de investimentos. Esses serviços agregam valor e são incorporados aos sistemas de clientes de indivíduos ou empresas. O sistema de suporte da empresa de serviços também provavelmente evoluirá oportunisticamente, à medida que novas capacidades de infra-estrutura ou padrões de demanda surgirem.

• Uma empresa de serviços governamentais fornece aos cidadãos serviços que variam amplamente, mas podem incluir serviços como cuidados de saúde, rodovias e estradas, pensões, aplicação da lei ou defesa. Quando apropriado, estes serviços tornam-se elementos de infra-estrutura utilizados em sistemas mais abrangentes de interesse para indivíduos e/ou empresas. As principais iniciativas, como um sistema de controle de tráfego aéreo de próxima geração ou um sistema de gestão de crises na área metropolitana (furacão, tufão, terremoto, tsunami, enchente, incêndio), serão suficientemente complexas para seguir uma abordagem evolutiva de desenvolvimento e de campo. No nível elementar, provavelmente haverá ciclos de vida pré-especificados de passagem única.

• Para aeronaves e sistemas automotivos, provavelmente haverá um ciclo de vida pré-especificado de passagem múltipla para capitalizar as capacidades iniciais na primeira passagem, mas arquitetado para agregar mais capacidades de valor agregado em passagens posteriores.

• Uma empresa de desenvolvimento de software diversificado fornece produtos de software que atendem aos requisitos (necessidades) das partes interessadas, fornecendo assim serviços aos usuários do produto. Será necessário desenvolver capacidades que possam ser adaptadas para serem utilizadas em diferentes abordagens do ciclo de vida dos clientes e também com capacidades de linha de produtos que possam ser rápida e facilmente aplicadas a desenvolvimentos de sistemas similares de clientes. Seu modelo de negócios também pode incluir o fornecimento ao cliente de suporte ao ciclo de vida do sistema e capacidades de evolução.

Com estes exemplos, há sistemas que permanecem estáveis durante períodos de tempo razoavelmente longos e aqueles que mudam rapidamente. A diversidade representada por esses exemplos e seus processos ilustra porque não há um processo de tamanho único que possa ser usado para definir um ciclo de vida específico do sistema. As abordagens de gestão e liderança devem considerar o tipo de sistemas envolvidos, a sua longevidade e a necessidade de adaptação rápida a mudanças imprevistas, seja na concorrência, tecnologia, liderança ou prioridades de missão. Por sua vez, as abordagens de gestão e liderança impactam o tipo e o número de modelos de ciclo de vida que são implantados, bem como os processos que serão utilizados dentro de qualquer ciclo de vida específico.

Existem várias abordagens incrementais e evolutivas para seqüenciar os estágios do ciclo de vida para lidar com algumas das questões levantadas acima. A área de conhecimento de Modelos do Ciclo de Vida resume uma série de modelos incrementais-incrementais e evolucionários do ciclo de vida, incluindo seus principais pontos fortes e fracos e também discute critérios para escolher a abordagem mais adequada.

Categorias do Modelo do Ciclo de Vida

O Modelo Genérico do Ciclo de Vida do Sistema na Figura 1 não se ajusta explicitamente a todas as situações. Um sistema simples, precedencial e de seguimento pode precisar apenas de uma fase na fase de definição, enquanto um sistema complexo pode precisar de mais de duas. Com sistemas build-upon (vs. throwaway) protótipos-protótipos, uma boa parte do desenvolvimento pode ocorrer durante a fase de definição. A integração do sistema, verificação, verificação e validação podem seguir a implementação ou aquisição dos elementos do sistema. Com o software, particularmente o test-first e as construções diárias, a integração, verificação e validação são entrelaçadas com a implementação dos elementos. Além disso, com a próxima Terceira Revolução Industrial de impressão tridimensional e fabricação digital (Whadcock 2012), não apenas o desenvolvimento inicial, mas também a produção inicial pode ser feita durante a fase de conceito.

Software é um meio flexível e maleável que facilita a análise iterativa, projeto, construção, verificação e validação em um grau maior do que é normalmente possível para os componentes puramente físicos de um sistema. Cada repetição de um modelo de desenvolvimento iterativo adiciona material (código) à crescente base de software, na qual a base de código expandida é testada, retrabalhada conforme necessário e demonstrada para satisfazer os requisitos da base.

Software pode ser eletronicamente comprado, vendido, entregue e atualizado em qualquer lugar do mundo ao alcance da comunicação digital, tornando sua logística significativamente diferente e mais econômica do que o hardware. Ele não se desgasta e suas correções mudam seu conteúdo e comportamento, tornando os testes de regressão mais complexos do que com as correções de hardware. Sua natureza discreta dita que seus testes não podem contar com a continuidade analítica como com o hardware. Adicionar 1 a 32767 em um registro de 15 bits não produz 32768, mas sim 0, como experimentado em situações graves, como com o uso do Míssil Patriot.

Existe um grande número de modelos de processo de ciclo de vida útil potencial. Eles se encaixam em três categorias principais:

1. processos prioritariamente pré-especificados e seqüenciais (por exemplo, o modelo de cachoeira de um único passo)
2. processos prioritariamente evolutivos e simultâneos (por exemplo, desenvolvimento enxuto, o processo unificado racional, e várias formas dos modelos vee e em espiral)
3. processos prioritariamente interpessoais e emergentes (por exemplo desenvolvimento ágil, scrum, programação extrema (XP), o método dinâmico de desenvolvimento de sistemas e processos baseados em inovação)

A emergência de sistemas integrados e interativos de software de hardware tornou os processos pré-especificados potencialmente prejudiciais, já que as interfaces mais eficazes de sistemas humanos tenderam a emergir com seu uso, levando a variações adicionais de processos, como o soft SE (Warfield 1976, Checkland 1981) e processos de integração de sistemas humanos (Booher 2003, Pew e Mavor 2007). Até recentemente, os padrões de processo e modelos de maturidade tentaram cobrir todas as eventualidades. Eles incluíram extensos processos de gerenciamento de aquisições, seleção de fontes, revisões e auditorias, garantia de qualidade, gerenciamento de configuração e gerenciamento de documentos, que em muitos casos se tornariam excessivamente burocráticos e ineficientes. Isso levou à introdução de abordagens mais lean (Ohno 1988; Womack et al. 1990; Oppenheim 2011) e agile (Beck 1999; Anderson 2010) para abordagens concorrentes de fatores hardware-software-humanos, tais como os modelos vee concorrentes (Forsberg 1991; Forsberg 2005) e o Modelo Espiral de Compromisso Incremental (Pew e Mavor 2007; Boehm e Lane 2007).

No próximo artigo sobre os Drivers e Escolhas do Ciclo de Vida do Sistema, estas variações sobre o tema dos modelos de ciclo de vida serão identificadas e apresentadas.

Responsabilidade da Engenharia de Sistemas

Independentemente dos modelos de ciclo de vida implantados, o papel do engenheiro de sistemas abrange todo o ciclo de vida do sistema de interesse. Os engenheiros de sistemas orquestram o desenvolvimento e a evolução de uma solução, desde a definição de requisitos até a operação e, finalmente, até a aposentadoria do sistema. Eles garantem que os especialistas de domínio sejam devidamente envolvidos, que todas as oportunidades vantajosas sejam perseguidas e que todos os riscos significativos sejam identificados e, quando possível, mitigados. O engenheiro de sistemas trabalha em estreita colaboração com o gerente de projeto na adaptação do ciclo de vida genérico, incluindo portões de decisão chave, para atender às necessidades do seu projeto específico.

As tarefas de engenharia de sistemas são geralmente concentradas no início do ciclo de vida; entretanto, tanto organizações comerciais quanto governamentais reconhecem a necessidade de SE ao longo de todo o ciclo de vida do sistema. Muitas vezes esse esforço contínuo é para modificar ou alterar um sistema, produto ou serviço depois que ele entra em produção ou é colocado em operação. Consequentemente, o SE é uma parte importante de todos os estágios do ciclo de vida. Durante os estágios de produção, suporte e utilização (PSU), por exemplo, o SE executa análise de desempenho, monitoramento de interface, análise de falhas, análise logística, rastreamento e análise das mudanças propostas. Todas essas atividades são essenciais para o suporte contínuo do sistema.

Todos os gerentes de projeto devem assegurar que o aspecto comercial (custo, cronograma e valor) e o aspecto técnico do ciclo do projeto permaneçam sincronizados. Muitas vezes, o aspecto técnico é o motor do projeto. É responsabilidade dos engenheiros de sistemas assegurar que as soluções técnicas que estão sendo consideradas sejam consistentes com os objetivos de custo e cronograma. Isso pode exigir um trabalho com os usuários e clientes para revisar os objetivos de forma a se enquadrar dentro dos limites do negócio. Estas questões também conduzem à necessidade de que as portas de decisão sejam adequadamente espaçadas ao longo do ciclo do projeto. Embora a natureza desses portões de decisão varie de acordo com as principais categorias acima, cada um envolverá validação em processo de validação em processo entre os desenvolvedores e os usuários finais. A validação em processo coloca a questão: “O que estamos a planear ou a criar irá satisfazer as necessidades das partes interessadas?” A validação em processo começa na inicialização do projeto durante a descoberta das necessidades do usuário e continua através de atividades diárias, revisões formais da porta de decisão, entrega do produto ou solução final, operações e, finalmente, até o fechamento e descarte do sistema.

Works Cited

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

Beck, K. 1999. Extreme Programming Explained. Boston, MA: Addison Wesley.

Boehm, B. e J. Lane. 2007. “Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering.” CrossTalk. Outubro de 2007: 4-9.

Booher, H. (ed.) 2003. Handbook of Human Systems Integration. Hoboken, NJ, EUA: Wiley.

Checkland, P. 1999. Systems Thinking, Systems Practice, 2ª ed. Hoboken, NJ, EUA: Wiley.

Cusumano, M., e D. Yoffie. 1998. Competing on Internet Time, Nova York, NY, EUA: The Free Press.

Forsberg, K. e H. Mooz. 1991. “The Relationship of System Engineering to the Project Cycle”, Proceedings of INCOSE, Outubro de 1991.

Forsberg, K., H. Mooz, e H. Cotterman. 2005. Visualizing Project Management, 3ª ed. Hoboken, NJ: J. Wiley & Sons.

ISO/IEC/IEEE. 2015.Engenharia de sistemas e software – processos do ciclo de vida do sistema.Genebra, Suíça: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers.ISO/IEC 15288:2015.

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

Ohno, T. 1988. Toyota Production System. Nova York, NY: Productivity Press.

Oppenheim, B. 2011. Lean para Engenharia de Sistemas. Hoboken, NJ: Wiley.

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.

Warfield, J. 1976. Engenharia de Sistemas. Washington, DC, EUA: US Department of Commerce (DoC).

Whadcock, I. 2012. “Uma terceira revolução industrial.” The Economist. 21 de Abril de 2012.

Womack, J.P., D.T. Jones, e D. Roos 1990. A Máquina Que Mudou o Mundo: A História da Produção Lean. Nova York, NY, EUA: Rawson Associates.

Primary References

Blanchard, B.S., e W.J. Fabrycky. 2011. Engenharia e Análise de Sistemas, 5ª ed., 2010. Série Prentice-Hall International em Engenharia Industrial e de Sistemas. Englewood Cliffs, NJ, USA: Prentice-Hall.

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management, 3rd Ed. Hoboken, NJ: J. Wiley & Sons.

INCOSE. 2012. Manual de Engenharia de Sistemas, versão 3.2.2. San Diego, CA, EUA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. Uma Viagem Através da Paisagem dos Sistemas. Londres, Reino Unido: 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.

Referências Adicionais

Chrissis, M., M. Konrad, e S. Shrum. 2003. CMMI: Diretrizes para Integração de Processos e Melhoria de Produtos. Nova York, NY, EUA: Addison Wesley.

Larman, C. e B. Vodde. 2009. Dimensionamento Lean e Desenvolvimento Ágil. Nova York, NY, EUA: Addison Wesley.

Os três livros seguintes não são referenciados no texto SEBoK, nem são “textos” de engenharia de sistemas; entretanto, eles contêm lições importantes de engenharia de sistemas, e os leitores deste SEBOK são encorajados a lê-los.

Kinder, G. 1998. Navio de Ouro no Mar Azul Profundo. New York, NY, USA: Grove Press.

Este é um excelente livro que segue uma idéia desde o início até a sua implementação com sucesso final. Embora a engenharia de sistemas não seja discutida, ela é claramente ilustrada em todo o processo, desde a definição inicial do projeto até o desenvolvimento de conceitos alternativos, passando pela exploração em fases e “experimentos de pensamento” até a abordagem de desafios ao longo do caminho. Também mostra o problema de não antecipar problemas críticos fora do escopo usual do projeto e da engenharia. Foram necessários cerca de cinco anos para localizar e recuperar as 24 toneladas de barras e moedas de ouro do navio afundado no oceano de 2.500 metros de profundidade, mas foram necessários dez anos para ganhar a batalha legal com os advogados representantes das companhias de seguros que reivindicaram a propriedade com base nas apólices de 130 anos que emitiram para os proprietários do ouro em 1857.

McCullough, D. 1977. O Caminho Entre os Mares: A Criação do Canal do Panamá (1870 – 1914). Nova York, NY, EUA: Simon & Schuster.

Embora “engenharia de sistemas” não seja mencionado, este livro destaca muitas questões de engenharia de sistemas e ilustra a necessidade do SE como disciplina. O livro também ilustra o perigo da aplicação de um conceito anteriormente bem sucedido (o canal de nível do mar usado no Suez uma década antes) em uma situação semelhante, mas diferente. Ferdinand de Lesseps liderou os projetos do Suez e do Panamá. Ele ilustra o perigo de faltar um ciclo de projeto baseado em fatos e portões de decisão significativos durante todo o ciclo do projeto. Também destaca o perigo de fornecer status de projeto sem visibilidade. Depois de cinco anos, os investidores foram informados de que o projeto estava mais de 50% concluído, quando na verdade apenas 10% do trabalho estava concluído. A segunda fase de desenvolvimento sob Stevens em 1904 concentrou-se na “terra em movimento”, em vez de cavar um canal, um conceito de engenharia de sistemas chave para a conclusão do canal. O Caminho entre os Mares ganhou o Prêmio Nacional do Livro de História (1978), o Prêmio Francis Parkman (1978), o Prêmio Samuel Eliot Morison (1978) e o Prêmio Cornelius Ryan (1977).

Shackleton, Sir E.H. 2008. (Publicado originalmente por William Heinemann, Londres, 1919). Sul: The Last Antarctic Expedition of Shackleton and the Endurance. Guilford, CT, EUA: Lyons Press.

Esta é a incrível história da última expedição antártica de Shackleton and the Endurance em 1914 a 1917. A lição de engenharia de sistemas é a avaliação contínua e diária de risco pelo capitão, líder da expedição e tripulação enquanto eles ficam presos no gelo ártico por 18 meses. Todos os 28 membros da tripulação sobreviveram.

Vídeos relevantes

• A Aproximação da NASA à Engenharia de Sistemas – Engenharia de Sistemas Espaciais 101 c/ NASA