Engenharia de Sistemas

Engenharia de Sistemas é um processo interdisciplinar que assegura que todas as necessidades do cliente serão satisfeitas durante a totalidade do ciclo de vida do sistema. Este processo compreende as sete seguintes tarefas:

1. Situar (definir) o problema (State the problem). Definir o problema é a tarefa mais importante da engenharia de sistemas. Abrange identificar os clientes, compreender suas necessidades, estabelecer a necessidade de mudança, identificar os requisitos e definir as funções do sistema.
2. Investigar alternativas (Investigate alternatives). As alternativas são investigadas e avaliadas baseadas em desempenho, custos e riscos.
3. Modelar o sistema (Model the system). O uso de modelos torna os requisitos mais claros, revela pontos de estrangulamento e atividades fragmentadas, reduz custos e expõe duplicidades de esforços.
4. Integrar (Integrate). Integração significa projetar interfaces e agrupar os elementos de um sistema de modo a funcionarem como um todo. Tal requer uso intensivo das comunicações e muita coordenação.
5. Lançar o sistema (Launch the system). Lançar o sistema significa fazê-lo funcionar e produzir saídas - é fazer com que o sistema faça aquilo para que foi projetado fazer.
6. Avaliar o desempenho (Assess performance). O desempenho é medido usando critérios de avaliação, medidas técnicas de desempenho e medidas -- a mensuração é a chave. Se não se pode medir um sistema, também não se pode controlá-lo. E se não se pode controlá-lo, também não se pode aperfeiçoá-lo.
7. Re-avaliar (Re-evaluation). Re-avaliação deve ser um processo diuturno e iterativo, segundo muitos laços paralelos.

Este processo é conhecido pelo acrônimo SIMILAR (Bahill and Gissing, 1998).

O material deste texto foi compilado de trabalhos de experientes engenheiros de Engenharia de Sistemas da BAE Systems, da Sandia National Laboratories, da Hughes Missile Systems, da Lockheed Martin Tactical Defense Systems, da The Boeing Company, e da Idaho National Engineering and Environmental Laboratories, e, também, segundo as referências gerais: Chapman, Bahill and Wymore (1992); Wymore (1993); IEEE P1220 (1994); Grady (1994, 1995); Hughes Aircraft Company (1994); Martin-Marietta (1994); Shishko and Chamberlain (1995); Martin (1997); Blanchard and Fabrycky (1998); EIA-632 (1999); Sage and Rouse (1999); DSMC (1999); Buede (2000); Rechtin (2000); Proceedings of the IEEE Systems, Man, e Cybernetics International Conferences; NCOSE e INCOSE Symposia e o Proceedings.

As primeiras versões do texto foram publicadas no IEEE Systems, Man, and Cybernetics Newsletter Dezembro 1994, pg. 11-12 e nos Proceedings of the Sixth Annual Symposium of the International Council on Systems Engineering (INCOSE), Julho, 1996, Boston, Vol. 1, pg. 503-508.

O ciclo de vida do sistema

O ciclo de vida de um sistema é composto de cinco fases: (1) levantamento dos requistos do sistema, (2) avaliação das alternativas, (3) projeto de engenharia para produção plena, (4) implementação, (5) integração e testes do sistema, (6) operação, manutenção e avaliação e (7) retirada de serviço, eliminação e substituição. Contudo, devemos levar em conta que o ciclo de vida dos sistemas é diferente para diferentes indústrias, produtos e clientes. Chapman, Bahill and Wymore (1992); Wymore (1993); Kerzner (1995); Shishko and Chamberlain (1995).

1. Definir o problema (State the problem)

Definir o problema tem início com a descrição da(s) função(ões) que o sistema deve desempenhar ou da deficiência que deve ser melhorada. Isto impõe que os requisitos do sistema devam ser declarados em termos do que deve ser feito, e não de como deve ser feito. Isto pode ser expresso por palavras ou por modelos. Os diferentes Inputs derivam dos utilizadores finais, dos operadores, de quem paga as contas, dos proprietários, das agências reguladoras, das vítimas, dos patrocinadores, do Marketing, das manufaturas, etc. No ambiente empresarial moderno a declaração do problema começa com uma razão para a mudança, seguido da declaração da visão e da missão da empresa. A declaração do problema é um dos mais importantes produtos da Engenharia de Sistemas. Não tem nenhum valor uma elegante solução para o problema errado.

Na definição do problema não utilizar a palavra ótimo.

A palavra ótimo não deve aparecer na declaração de um problema, uma vez que não há uma simples solução ótima para um problema referente à sistemas complexos. A maioria dos projetos têm diversos critérios de desempenho e de custos. A Engenharia de Sistemas cria várias alternativas de projeto que satisfazem a esses critérios, nos mais variados graus. Passar de uma para outra alternativa normalmente otimiza pelo menos um dos critérios, enquanto que simultaneamente piora, pelo menos, um outro, dando origem à negociações, ou soluções de compromisso. Provavelmente nenhuma das alternativas exeqüíveis otimizará todos os critérios. Deste modo a Engenharia de Sistemas provavelmente chegará a um resultado quase ótimo. Não é muito provável que algum sistema complexo possa ser otimizado segundo a ótica de todas as pessoas, por todo o tempo. Pode ser que seja possível otimizar algum subsistema, mas quando forem interconectados, o sistema global pode não ser otimizado. O melhor sistema possível pode ser aquele que não seja o resultado da interconexão de subsistemas otimizados. Um time de estrelas pode ter pessoal cobra em todas as posições, mas se pode afirmar ser provável que tal time vença os campeões do mundo? Mesmo que os requisitos do sistema demandem um sistema ótimo, não haverá dados que possam provar que o sistema resultante seja realmente ótimo. Em geral, pode ser provado que um sistema é localmente ótimo, mas não que ele é globalmente ótimo.

Entender as necessidades do cliente

Raramente os clientes sabem o que querem ou desejam. Os Engenheiros de Sistemas devem adentrar o ambiente do consumidor e verificar como ele usa o sistema. Deve-se exceder, e não somente atender, as expectativas do cliente. Projetos flexíveis e prototipagem rápida ajudam a identificar aspectos que possam ter sido relevados. Falar com os clientes do seu cliente e os fornecedores do seu fornecedor pode ser de muita utilidade. Os termos customer e stakeholder abrangem todas as pessoas que tenham o direito de impor algum tipo de requisito para o sistema: são os utilizadores finais, operadores, proprietários, pagadores de contas, agências reguladoras, beneficiários, vítimas, etc. Chapman, Bahill e Wymore (1992); Wymore (1993).

Levantar os requisitos do sistema

Há dois tipos de requisitos dos sistemas: os mandatórios e os acessórios: (Bahill and Dean, 1999). Requisitos mandatórios asseguram que o sistema satisfaça a necessidade operacional do cliente. Requisitos mandatórios (1) especificam as condições necessárias e suficientes que um sistema mínimo deva ter a fim de ser aceitável (eles são usualmente escritos com as palavras deve ou é necessário.), (2) devem ser aceitos ou recusados, não havendo meio termo (i.e. eles não usam funções de valores para graduá-los.), e (3) não devem ser suscetíveis de negociações entre dois requisitos. Requisitos mandatórios típicos devem ter a seguinte forma: O sistema não deve violar leis federais, estaduais ou locais. Requisitos mandatórios estabelecem os requisitos mínimos necessários para satisfazer a necessidade do cliente.

Uma vez compreendidos os requisitos mandatórios, os Engenheiros de Sistemas propõe projetos alternativos candidatos, todos satisfazendo àqueles requisitos. Os requisitos acessórios são, então, avaliados, a fim de ser selecionado o projeto preferido. Os requisitos acessórios (1) devem estabelecer as condições que possam fazer o cliente mais feliz. (Eles são freqüentemente escritos com a palavra podem.), (2) podem usar funções de valores para graduá-los (Daniels, Werner and Bahill, 2001: Wymore, 1993) na avaliação do critério, e (3) devem ser avaliados com o auxílio de técnicas de decisão multicritério (Szidarovszky, Gershon e Duckstein, 1986; Daniels, Werner e Bahill, 2001) devido ao fato de que ocorrerão conflitos entre eles. Requisitos acessórios típicos devem ter a seguinte forma: O jantar deve conter itens de cada um dos quatro principais grupos de alimentos.

Em certas ocasiões poderá ocorrer o relacionamento entre requisitos mandatórios e os acessórios, por exemplo, um requisito mandatório pode ter um limite menor do que o valor de um requisito acessório. As palavras, otimizar, maximizar, minimizar e simultâneo não devem ser usadas quando declarando requisitos (Grady, 1993). A Função de Desenvolvimento da Qualidade (Quality Function Deployment (QFD) é útil na identificação dos requisitos de sistemas: (Bahill e Chapman, 1993; Bicknell e Bicknell, 1994).

Validar os requisitos

Validar os requisitos significa assegurar que (1) a solução recomendada satisfaz a necessidade real do consumidor, (2) a descrição dos requisitos é consistente e completa, (3) um modelo do sistema pode satisfazer os requisitos e (4) uma solução real pode ser testada de modo a provar que ela satisfaz aos requisitos. Se os Engenheiros de Sistemas descobrirem que o cliente solicitou uma máquina de movimento perpétuo, o projeto deve ser interrompido. Os requisitos são freqüentemente validados tomando-se como referência um sistema já existente, o qual satisfaça a sua maioria.

2. Investigar alternativas

Projetos alternativas são avaliados baseados em critérios de desempenho, custos, programação e riscos. Provavelmente nenhum projeto será o melhor em todos os critérios, de modo que o auxílio de técnicas de decisão multicritério deve ser usado de modo a revelar quais alternativas serão as preferidas. Tal análise deve ser repetida sempre que mais dados forem disponibilizados. Por exemplo, o critério deve ser, inicialmente, computado na base de estimativas feitas pelos engenheiros projetistas, sendo, então, elaborados e avaliados modelos. Uma nova simulação dos dados deve derivar daí. Protótipos subseqüentes devem ser medidos e finalmente os dados devem ser testados num modelo real do sistema. Para o projeto de sistemas complexos o estudo de projetos alternativos serve para reduzir os riscos de projeto envolvidos. A investigação de alternativas bizarras ajuda a clarear a definição do problema. Este é um dos principais processos usados para definir a arquitetura dos sistemas.

Definir medidas quantitativas

Os critérios de avaliação, as medidas de desempenho técnico e as medidas de um modo geral são todas usadas para quantificar o desempenho do sistema. Esses termos são, freqüentemente, usados de modo intercambiável, mas acreditamos que seja necessário diferenciá-los: Critérios de avaliação (freqüentemente referidos como números de mérito) são usados para quantificar requisitos. Medidas de desempenho técnico são usadas para reduzir o risco durante o projeto e a fabricação. Medidas (ou métricas) são usadas para auxiliar o gerenciamento dos processos de uma empresa. (Moody, et al., 1997).

Critérios de desempenho e de custo

Esses critérios mostram quanto adequadamente o sistema atende aos seus requisitos, como por exemplo - neste teste o carro acelera de 0 a 60 em 6.5 segundos. Os critérios de avaliação são freqüentemente chamados de Medidas de Eficácia. Tais medidas são realizadas ao longo da evolução dos sistema: primeiramente baseadas em estimativas feitas pelos engenheiros de projeto, a seguir em modelos, simulações, protótipos e, finalmente, no sistema real. Os critérios de avaliação são usados a fim de auxiliar na seleção de um projeto, entre os projetos alternativas, e são usados para quantificar os requisitos dos sistemas. Durante a seleção conceptual, os critérios permitem negociações, isto é, passando de uma para outra alternativa aumenta um determinado número de mérito enquanto diminui outro. Os critérios de avaliação devem servir de base para a maioria dos requisitos.

Medidas técnicas de desempenho (Technical performance measures TPM)

As medidas técnicas de desempenho (TPM's) são usadas para acompanhar o progresso do projeto e da fabricação. Elas são medidas feitas durante os processo de projetar e de fabricar/produzir a fim de permitirem a avaliação da probabilidade de satisfação dos requisitos do sistema. Nem todos os requisitos têm TPMs. TPMs são, usualmente, associadas somente a requisitos de altíssimo risco, de vez que são dispendiosas de manter e acompanhar. Protótipos iniciais não atenderão as metas de TPM. Deste modo requer-se, somente, que os valores de TPM permaneçam dentro de uma faixa de tolerância. Espera-se que na medida em que avancem os processos de projeto e de fabricação/produção os valores de TPM se tornem cada vez mais próximos das metas estabelecidas.

Medidas

As medidas, ou métricas, são freqüentemente relacionadas aos processos, não ao produto. (Moody et al., 1997). Deste modo, elas nem sempre se relacionam com requisitos específicos do sistema. Muitas vezes algumas medidas se relacionam à declaração da missão da empresa e metas subseqüentes. Uma medida útil é a percentagem dos requisitos que mudaram depois de procedida a Revisão dos Requisitos do Sistema.

3. Modelar o sistema

Serão desenvolvidos modelos para a maioria das alternativas de projeto. O modelo da alternativa selecionada será expandido e usado para auxiliar no gerenciamento do sistema durante todo seu ciclo de vida. Serão usados muitos tipos diferentes de modelos , tais como os físicos analógicos, as equações analíticas, as state machines, diagramas de bloco, diagramas de fluxo funcional, modelos orientados à objetos, simulações computacionais e modelos mentais. A Engenharia de Sistemas é responsável pela criação de um produto e, também, de um processo para concretizá-lo. Deste modo, os modelos devem ser construídos para representar a realidade tanto do produto como dos processos Os modelos de processo permitem-nos, por exemplo, o estudo de alterações de programação, criar cartas dinâmicas PERT, e realizar análise de sensibilidade a fim de mostrar as conseqüências de atrazos e acelerações em certos subprojetos. Por para funcionar os modelos de processo revela gargalos e atividades fragmentadas, reduz custos e expões duplicidades de esforços. Os modelos de produtos ajudam a explicar o sistema. Esses modelos são usados em estudos de negociações, e gerenciamento de riscos.

Projetar (Design) o sistema

O sistema global deve ser particionado em subsistemas, os subsistemas particionados em conjuntos, etc. A Re-usabilidade deve ser considerada na criação dos subsistemas. Para novos projetos, os subsistemas devem ser criados de modo a poderem ser re-usados em produtos futuros. Para re-projetos, os subsistemas devem ser criados de modo a maximizarem o uso de produtos já existentes, particularmente os disponíveis comercialmente. Os Engenheiros de Sistema devem igualmente decidir entre construir/fabricar ou comprar os subsistemas, tentando em primeiro lugar a utilização de subsistemas comercialmente disponíveis. Se não houver nenhum deles que satisfaça a todos os requisitos, deve ser considerada, então, a possibilidade de modificação de um subsistema já existente. Se mesmo assim for insatisfatório, então alguns subsistemas terão que ser desenvolvidos em casa. Os engenheiros ao projetarem um subsistema devem ter perfeita compreensão dos demais subsistemas com os quais o seu sistema vai interagir. A flexibilidade é mais importante do que a otimização. Devem ser considerados o hardware, o software e o bioware. Bioware (ou wetware) significa organismos humanos e outros biológicos que sejam parte do sistema. Por exemplo, projetar uma pista de corridas para cavalos ou cachorros faz parte do bioware. Instalações para seus cuidados e manuseio devem ser consideradas, do mesmo modo que provisões para educação, fatores humanos e segurança. Essas atividades são conhecidas como Projeto de Sistemas (System Design) para novos sistemas e Análise de Sistemas (Systems Analysis) para os sistemas já existentes.

Criar diagramas de seqüências

Indubitavelmente o primeiro passo ao projetar um sistema deve ser a criação de diagramas de seqüência de eventos. Em outras palavras, isto quer dizer colecionar seqüências típicas de eventos que o sistema proposto irá desempenhar. As seqüências podem ser a descrição de comportamentos históricos ou podem ser baseadas em modelos mentais para comportamento futuro. Tais descrições de comportamentos de entrada e de saída como funções do tempo são chamadas de diagramas de seqüências , cenários comportamentais, cenários operacionais, conceitos operacionais, seqüências operacionais, trilhas, trajetórias de entradas e saídas, diagramas de colaboração, diagramas logísticos ou de interações. Os diagramas de seqüências são fáceis de serem descritos e discutidos, sendo fácil, igualmente, convertê-los em um projeto de sistema. Seqüências adicionais podem ser adicionadas incrementalmente à coleção. (Bahill and Dean, 1999; Bahill and Daniels, 2003).

Definir a arquitetura do sistema

Definir a arquitetura de um sistema significa escolher os elementos chaves de alto nível que irão determinar os componentes e sub-componentes do sistema. O que se segue são algumas escolhas que têm que ser feitas: (1) projeto orientado-à-objetos, análise estruturada ou decomposição funcional, (2) computação distribuída ou centralizada, (3) produtos comerciais (COTS) ou projetados customizadamente (NDI), e (4) Ada versus C++ ou Java. Rechtin and Maier (1997) esclarece que a arquitetura do Sistema é feita nas duas primeiras fases do ciclo de vida do sistema : no descobrimento dos requisitos do sistema e na exploração conceptual.

Decomposição funcional

Os Engenheiros de Sistema procedem a decomposição funcional em novos sistemas (1) para mapear funções aos seus componentes físicos, assegurando desse modo que cada função tem um correspondente proprietário, (2) para mapear funções aos requisitos de sistema,e (3) para garantir que todas as tarefas necessárias sejam levantadas e relacionadas e que nenhuma tarefa desnecessária será solicitada. Esta lista se torna a base para a Estrutura Analítica de Decomposição dos Trabalhos (a conhecida Work Breakdown Structure.)

Quando analisando ( ou realizando engenharia reversa) em um sistema existente, os Engenheiros de Sistema fazem a análise funcional de modo a observarem o que o sistema faz, a fim de aprimorar seu desempenho (freqüentemente conhecido como engenharia de agregação de valor), e fazem, também, decomposição funcional para observarem o que o sistema, supostamente, deve fazer. Deste modo, eles podem descrever o estágio atual do sistema e o estado desejado (ou meta) para o sistema. Podem, então, sugerir como o sistema pode ser alterado. Proceder à dramáticas mudanças radicais no sistema é conhecido como Re-engenharia. Proceder a pequenas mudanças incrementais é conhecido como Gerenciamento da Qualidade Total.

Ícaro, e muitos pretendentes a voar que se seguiram, tentavam compreender como voar analisando os componentes físicos que as aves usavam para voar: Pernas, Olhos, Cérebro e Asas. Usando este paradigma o homem não foi capaz de conseguir voar. Em contrapartida, os irmãos Wright identificaram as seguintes funções para o problema do vôo: Decolar e aterrisar, determinar a posição e a velocidade, navegar, produzir força de translado horizontal, e produzir força de sustentação. Uma vez entendido que empuxo horizontal e empuxo vertical eram duas diferentes funções dois componentes físicos lhes foram assinalados. Usando um hélice para produzir a força de deslocamento horizontal e asas para produzir a sustentação, foi possível dominar o vôo. A tabela específica seguinte mostra o mapeamento das funções e seus componentes físicos:

Decomposição funcional versus física

Função Componente física da aeronave Componente física da ave

Decolar e aterrisar Rodas, skis ou pontões Pernas

Determinar posição e velocidade Visão ou radar Olhos

Navegar Cérebro ou computador Cérebro

Produzir propulsão horizontal Hélice ou jato Asas

Produzir propulsão vertical Asas Asas

As aves usam um componente físico para duas funções: força de deslocamento horizontal e sustentação. O homem teve que usar dois componentes físicos para executar estas duas funções. Como este exemplo mostra, é perfeitamente aceitável assinalar duas ou mais funções a um componente físico. Contudo, provavelmente será um equivoco assinalar uma função a dois componentes físicos.

Identificar as funções que um sistema tem que desempenhar é somente uma parte da sua descrição: os objetos (Fowler e Scott, 2000; Jacobson, Booch e Rumbaugh, 1999; Douglas, 2000; Gomaa, 2000; Cockburn, 2001; Bahill and Daniels, 2003) e estados devem ser, também, descritos (Bahill, et al., 1998; Wymore e Bahill, 2000).

Análise de sensibilidade

Numa análise de sensibilidade cada parâmetro ou requisito é variado e os efeitos de saída são observados. A análise de sensibilidade pode ser usada para apontar quais parâmetros e requisitos têm os efeitos mais pronunciados sobre custos, programação e desempenho. Eles auxiliam na alocação de recursos. Karnavas, Sanchez e Bahill (1993).

Avaliar e gerenciar riscos

Existem dois tipos de riscos: risco da falha do projeto (devido a estouro dos gastos, estouro no tempo ou falha em atender as especificações de desempenho) e riscos de acidentes pessoais (usualmente chamado de segurança do pessoal). Deve ser realizada uma análise de modo de falha e seus efeitos e providenciada um modo de redução dos riscos (Bahill and Karnavas, 2000). O risco de falha do projeto pode ser reduzido pela supervisão da qualidade e o fornecimento oportuno dos itens comprados. Kerzner (1995).

Análise de confiabilidade

Os principais modos de falhas devem ser analisados quanto à probabilidade de ocorrência e severidade de ocorrência. Kapur e Lamberson (1977); O'Connor (1991).

4. Integrar os componentes do sistema

Integração significa colocar tudo junto de modo a funcionar como um todo. Integração do sistema significa colocar juntos os subsistemas de modo a produzirem o resultado desejado e assegurar que eles interajam de modo a satisfazer as necessidades do cliente. Os utilizadores finais e engenheiros necessitam saber operar o sistema por meio de cursos, manuais e treinamentos em protótipos. Grady (1994).

Projetar (design) e gerenciar interfaces

Interfaces entre subsistemas e interfaces entre o sistema principal e o mundo externo devem ter seus limites naturais perfeitamente definidos. Os subsistemas devem ser definidos segundo limites naturais. Quando uma mesma informação vai e volta entre diferentes subsistemas uma atividade natural pode ter sido fragmentada. Os subsistemas devem ser definidos de modo a minimizar a quantidade de informações a ser trocada entre eles. Subsistemas bem desenvolvidos enviam produtos acabados aos demais subsistemas. Laços de realimentação entre subsistemas individuais são mais fáceis de administrar do que laços de realimentação entre subsistemas inter-conectados. Quando projetando subsistemas e suas interfaces assegure-se de considerar a possibilidade de re-usá-los.

5. Lançar o sistema

Lançar o sistema significa fazê-lo funcionar da maneira como foi projetado para fazê-lo, isto é, fazendo-o operar produzindo suas saídas desejadas (Bahill e Gissing, 1998). Engenheiros de Projeto produzem projetos para produtos e processos para tal.

Gerenciar a configuração

O Gerenciamento da Configuração (também chamado de gerenciamento das alterações) assegura que quaisquer mudanças nos requisitos, projeto ou implementações, são controladas, cuidadosamente identificadas e registradas com precisão. Todos os interessados no projeto (stakeholders) devem ter a oportunidade de opinar sobre as mudanças propostas. As decisões de adotar uma alteração devem ser registradas numa base de dados referencial. Uma configuração de referência é um projeto congelado em determinado instante no tempo com registro dos requisitos para as funções, desempenho, interfaces, verificações, testes, custos, etc. Tais referências só podem ser alteradas em determinados pontos específicos no ciclo de vida. Todas as partes concernentes devem ser notificadas das alterações de modo a garantir que trabalhem no mesmo projeto. A expressão acompanhamento dos requisitos (requirements tracking) está sendo agora usada como um importante subconjunto do Gerenciamento da Configuração.

Gerenciar o projeto

Gerenciamento do projeto é o planejamento, organização, direção e controle dos recursos da instituição a fim de alcançar metas e objetivos específicos num tempo e custo pré-determinado, e num nível de desempenho desejado. (Kerzner, 1995: Tichy e Sherman, 1993). O gerenciamento de projetos cria uma estrutura analítica de decomposição, na forma de uma árvore de hardware, software, dados, instalações e serviços orientada-ao-produto. Tal estrutura mostra e define os produtos a serem desenvolvidos e relaciona os elementos do trabalho a serem realizados entre si e com o produto final. Esta decomposição analítica provê estrutura para guiar as atribuições das equipes e controle de custos e acompanhamento. (Martin, 1997).

Documentação

Todos essas atividades de Engenharia de Sistemas devem ser documentadas num repositório comum, freqüentemente chamado de Caderno de Engenharia (Engineering Notebook) As informações armazenadas devem indicar a localização, plataforma e apresentação independente: o que quer dizer que qualquer pessoa ou qualquer computador usando qualquer ferramenta deve ser capaz de trabalhar com os dados fundamentais. Assunções, resultados de estudos de compromisso e razões para a tomada de decisões críticas devem ser registradas. Esses documentos devem estar em vigor e serem dinâmicos. Por exemplo, ao final do ciclo de vida do sistema deve existir um modelo preciso do sistema existente, a fim de auxiliar na sua baixa. Chapman, Bahill e Wymore (1992); Wymore (1993).

Equipes líderes

Sistemas complexos não podem ser projetados por uma única pessoa. Conseqüentemente, os engenheiros trabalham em Equipes Integradas de Desenvolvimento de Produtos (Integrated Product Development Teams (IPDTs)). Essas equipes são interdisciplinares com membros especialistas em Negócios, Engenharia, Manufatura,Testes, etc. IPDTs são freqüentemente dirigidos por Engenheiros de Sistemas, formal ou informalmente. Katzenback and Smith, (1993).

6. Avaliar o desempenho

Durante as fases de operação e manutenção do ciclo de vida do sistema, seu desempenho deve ser medido. Inicialmente, essas medidas servirão para verificar se o sistema se comporta conforme seus requisitos. Mais tarde serão usadas para detectar deterioração e iniciar a manutenção.

Prescrever testes

Logo nos primórdios do ciclo de vida de um sistema a Engenharia de Sistemas deve descrever os testes que serão usados para provar o aderência do sistema aos seus requisitos. Contudo, muitos testes devem ser realizados por equipamentos de testes embutidos (built-in self-test equipment). Esses auto-testes devem ser usados como testes de instalação inicial, testes de pós-instalação, diagnósticos de energização (power-up diagnostics), serviços de campo e reparos de nível depot. O destinatário de cada resultado de teste realizado e a ação a ser tomada se o sistema passar ou falhar em cada teste devem estar claramente indicados.

Conduzir revisões

Os Engenheiros de Sistemas devem assegurar que serão conduzidas e documentadas revisões adequadas. A definição exata de cada revisão depende do tamanho, complexidade e do cliente do projeto. O seguinte conjunto é comum: Revisão do Conceito da Missão (Mission Concept Review), Revisão dos Requisitos do Sistema (System Requirements Review (SRR)), Revisão de Definição do Sistema (System Definition Review), Revisão de Projeto Preliminar (Preliminary Design Review (PDR)), Revisão Crítica do Projeto (Critical Design Review (CDR)), Revisão de Prontificação para Construção (Production Readiness Review (PRR)), e Testes do Sistema (System Test). O projeto de engenharia para produção em série começa depois da Revisão de Projeto Preliminar. A construção/fabricação começa depois da Revisão Crítica do Projeto. (Shishko e Chamberlain, 1995; Bahill e Dean, 1999).

Verificar requisitos

A Engenharia de Sistemas deve provar que o sistema final atende a cada um dos requisitos de sistema. Os requisitos devem ser verificados por inspeção, análise, demonstração, testes, argumentação lógica, modelagem ou simulação.

Testar o sistema global

O sistema que finalmente for construído deve ser testado para ver se (1) satisfaz os requisitos mandatórios, e (2) qual o grau com que satisfaz os requisitos acessórios. A fim de economizar dinheiro não foi feito um teste global antes do lançamento do telecópio espacial Hubble. Como conseqüência despendeu-se $850,000,000 para reparar o erro do sistema.

7. Reavaliar

Re-avaliação é inegavelmente a mais importante tarefa da Engenharia de Sistemas. Por séculos, os engenheiros vêm usando realimentação para controlar os sistemas e melhorar o desempenho. Esta é uma das mais fundamentais ferramentas de engenharia. Re-avaliar significa observar saídas e usando as informações, modificar as entradas para o sistema , o produto ou o processo. A re-avaliação deve ser um processo contínuo com muitos laços paralelos. Cada um deve re-avaliar continuamente aspectos do sistema de modo a melhorar sua qualidade. As principais ferramentas usadas nesse processo abrangem a engenharia concorrente básica, os conceitos de melhoria da qualidade de Deming, a função de desenvolvimento da qualidade (quality function deployment (QFD)), os princípios da Gestão pela Qualidade Total, bem como as técnicas de engenharia da qualidade de Taguchi. Deming (1982); Bicknell and Bicknell (1994); Latzko and Saunders (1995).

Categorias de Engenheiros de Sistemas

Muitas empresas dividem a Engenharia de Sistemas que praticam em trêss categorias, de acordo com seus fluxos principais de trabalhos: Definição de Requisitos, Projeto Arquitetônico e Testes e Verificações.

Criando Engenheiros de Sistema

O método tradicional de criar Engenheiros de sistemas era o de selecionar engenheiros bem organizados e cheios de senso comum e deixá-los adquirir cerca de 30 anos de diversas experiências em engenharia. Porém, recentemente, esses tradicionais Engenheiros de Sistemas escreveram livros e padrões que explicam o que eles fazem e como fazem. Desse modo, agora que foram formalizadas ferramentas, conceitos e procedimentos, em quatro anos de ensino no nível de graduação podem ser formados Engenheiros de Sistemas que terão nível de desempenho de 50% com relação aos tradicionais Engenheiros de Sistemas mais antigos (Esses números se baseiam em dados de média salarial nos EUA, de modo que quem quiser, pode desacreditá-los). Dez anos de experiência em Engenharia de Sistemas melhoram o desempenho em 80% e outros dez anos mais aumentarão tal experiência para 100%.

Conclusão

Será que o dr. Victor Frankenstein foi um bom Engenheiro de Sistemas? A resposta é SIM. Ele construiu um sistema complexo com muitos componentes, e seu sistema funcionou! Além do mais, marcou pontos quanto aos baixos custos, alto desempenho, respeito à programação e grande re-usabilidade. Contudo, pagou mico quanto à análise de riscos, análise do ciclo de vida e testes finais do sistema. A discussão que se segue é baseada numa novela de Mary Shelley, em 1818, e não em filmes.

Definindo o problema: Frankenstein entrou em depressão quando sua mãe morreu. Em conseqüência passou a querer dominar a morte por meio da infusão de vida num corpo inanimado.

Entendendo as necessidades do cliente: Penso que aqui ele explodiu, sendo que a compaixão e o consolo da tristeza são o que melhor pode atender às necessidades desse consumidor.

Levantando os requisitos do sistema: O único requisito que Victor considerou foi o de criar vida, de modo que seu trabalho em levantar requisitos foi extremamente pobre.

Validando os requisitos: Com validar requisitos se não foram levantados requisitos?

Investigando alternativas: Quando o monstro dialogou com Frankenstein, ele disse que estava solitário e queria que o dr. lhe construísse uma companheira. Ao projetar esta companhia Frankenstein considerou várias alternativas.

Definindo medidas quantitativas: Ele não tinha medidas de eficácia.

Modelando o sistema: Victor Frankstein tinha modelos mentais e desenhos em seu livro, mas não um modelo formal. Conseqüentemente, ficou surpreso com a feiura alcançada para sua criatura: embora vendo que já era feia [durante a construção]; mas quando juntou aqueles músculos e articulações e os cobriu de pele, tornando-a capaz de movimento, a criatura tornou-se uma coisa que nem mesmo Dante poderia ter concebido.

Decomposição funcional: Victor procedeu uma decomposição analítica física (não funcional).

Produzindo o Design do Sistema: Ele projetou um sistema muito bom. E obteve nota muito alta quanto à re-usabilidade!

Análise de sensibilidade: Ele nada sabia sobre análise de sensibilidade. Este é uma ferramenta moderna.

Gerenciamento de riscos: Ele teve nota muito baixa no gerenciamento de riscos. De fato o monstro culminou por matar seu irmão, seu melhor amigo e sua noiva. Mas antes de Frankenstein terminar seu segundo monstro, ele considerou os riscos envolvidos e destruiu seu trabalho.

Análise de confiabilidade: Seu monstro era muito robusto. Não precisava de alimentos, não sentia frio congelante e nem ferimentos a bala, tudo por sua constituição.

Integrando o sistema: Este foi seu feito máximo, ao colocar todas as partes juntas, e fazê-las funcionar.

Lançando o sistema: Frankenstein não lançou seu monstro no mundo. De fato, o monstro é que fugiu imediatamente após ganhar vida.

Gerenciamento da configuração: Ele não poderia gerenciar a configuração uma vez que não tinha requisitos.

Gerenciamento do Projeto: Ele fez um excelente trabalho de gerenciamento de projeto: seu sistema tinha custo baixo, alto desempenho e foi produzido como programado.

Documentação: O dr. Frankenstein mantinha um livro de notas com registros, no laboratório.Este livro de notas foi o que permitiu ao monstro seguir sua pista e capturá-lo um ano e mais tarde, num país diferente.

Equipes líderes: Frankenstein trabalhou sozinho e nunca disse, a ninguém, o que tinha feito.

Avaliando o desempenho: o que inclui realizar testes, conduzir revisões, verificar requisitos e testar o sistema globalmente. Frankenstein não realizou nenhuma dessas tarefas.

Reavaliando e melhorando a qualidade. A razão por que Frankenstein foi para a Inglaterra foi a consultar filósofos, por que ele queria que seu segundo monstro fosse melhor do que o primeiro.

Engenharia de sistemas é a disciplina responsável por assegurar que todas essas tarefas são realizadas num ambiente de engenharia concorrente. Contudo, o processo de Engenharia de Sistemas deve ser dimensionado adequadamente segundo cada projeto. Freqüentemente isto significa omitir determinadas tarefas, o que reduz custos, mas em compensação aumenta os riscos. Se você escolher omitir uma dessas tarefas, você deve se questionar - Por quê?

Referências:

ANSI/EIA 632, Standard, Process for Engineering a System, January 1999.

Bahill, A.T. and Briggs, C, The systems engineering started in the middle process: a consensus of system engineers and project managers, Systems Engineering, 4(2): 156-167, 2001.

Bahill, A.T. and Daniels, J, Using object-oriented and UML tools for hardware design: a case study, Systems Engineering, 6(1): 28-48, 2003.

Bahill, A.T. and Karnavas, W.J, Risk analysis of a Pinewood Derby: A case study, Systems Engineering, 3(3): 143-155, 2000.

Bahill, A.T., Alford, M., Bharathan, K., Clymer, J.R., Dean, D.L., Duke, J., Hill, G., LaBudde, E.V., Taipale, E.J. and Wymore, A.W., The design-methods comparison project, IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, 28(1), 80-103, February 1998.

Bahill, A.T. and Dean, F.F., Discovering system requirements, in A.P. Sage and W.B. Rouse (Eds), Handbook of Systems Engineering, John Wiley & Sons, 175-220, 1999.

Bahill A.T. and Chapman, W.L., A tutorial on quality function deployment, Engr Management J, 5(3):24-35, 1993.

Bahill, A.T. and Gissing, B., Re-evaluating systems engineering concepts using systems thinking, IEEE Transactions on Systems, Man and Cybernetics, Part C: Applications and Reviews, Volume 28, Number 4, pp. 516-527, November 1998.

Bicknell, K.D. and Bicknell, B.A., The Road Map to Repeatable Success: Using QFD to Implement Changes, CRC Press, Boca Raton, 1994.

Blanchard, B.S. and Fabrycky, W.J., Systems Engineering and Analysis, Prentice-Hall, 1998.

Buede, D. M., The Engineering Design of Systems, John Wiley, New York, 2000.

Chapman, W.L., Rozenblit, J. and Bahill, A.T., Systems design is an NP-complete problem, Systems Engineering, 4(3): 222-229, 2001.

Chapman, W.L., Bahill, A.T. and Wymore, W., Engineering Modeling and Design, CRC Press, Boca Raton, 1992.

Cockburn, A., Writing Effective Use Cases, Addison-Wesley, 2001.

Daniels, J., Werner, P.W., and Bahill, A.T., Quantitative Methods for Tradeoff Analyses, Systems Engineering, 4(3), pp. 199-212, 2001.

Deming, W.E., Out of the Crisis, MIT Center for Advanced Engineering Study, Cambridge MA, 1982.

DSMC, Systems Engineering Fundamentals, Defense System Management College, http://www.dsmc.dsm.mil/pubs/gdbks/pdf/systengfund.pdf 1999.

Douglas, B.P., Real-Time UML, Addison-Wesley, Reading, 2000.

Fowler, M. and Scott K., UML Distilled: A brief guide to the standard object modeling language, Addison-Wesley, 2000.

Grady, J.O., System Requirements Analysis, McGraw Hill Inc., 1993.

Grady, J.O., System Integration, CRC Press, Boca Raton, 1994.

Grady, J.O., System Engineering Planning and Enterprise Identity, CRC Press, Boca Raton, 1995.

Gomaa, H., Designing Concurrent, Distributed, and Real-Time Applications with UML, Addison-Wesley, Reading, 2000.

Hooks, I. F. and Farry, K. A., Customer Centered Products: Creating Successful Products Through Smart Requirements Management, American Management Association, 2001.

Hughes Aircraft Co., Systems Engineering Handbook, 1994.

IEEE 1220 Standard, Application and Management of the Systems Engineering Process, IEEE Standards Dept., NY, December 1998.

ISO/IEC 15288, System Life Cycle Processes, October 2002.

Jacobson, I., Ericsson, M. and Jacobson, A., The Object Advantage: Business Process Reengineering with Object Technology, Addison-Wesley, New York, 1995.

Jacobson, I. Booch, G. and Rumbaugh J., The Unified Software Development Process, Addison-Wesley, 1999.

Kapur, K.C. and L.R. Lamberson, Reliability in Engineering Design, John Wiley and Sons, New York, 1977.

Karnavas, W.J., Sanchez, P. and Bahill A.T., Sensitivity analyses of continuous and discrete systems in the time and frequency domains, IEEE Trans Syst Man Cybernetics, SMC-23:488-501, 1993.

Katzenbach, J.R. and Smith, D.K., The Wisdom of Teams, HarperCollins Publishers, 1993.

Kerzner, H., Project Management: a Systems Approach to Planning, Scheduling, and Controlling, Van Nostrand Reinhold, New York, 1995.

Latzko, W.J. and Saunders, D.M., Four Days with Dr. Deming, Addison-Wesley, Reading, Mass, 1995.

Martin, J., Systems Engineering Guidebook: A Process for Developing Systems and Products, CRC Press, Boca Raton, 1997.

Martin-Marietta, Systems Engineering Methodology Handbook EPI 270-01, 1994.

MIL-STD-499B, Draft Military Standard for Systems Engineering, AFSC/EN, 1992. This standard was not signed by the Department of Defense. Spokesmen said that the government should not be in the business of writing standards and therefore they would adopt standards written by professional societies.

Moody, J.A., Chapman, W.L., Van Voorhees, F.D. and Bahill, A.T., Metrics and Case Studies for Evaluating Engineering Designs, Prentice Hall PTR, Upper Saddle River, NJ, 1997.

O'Connor, P.D.T., Practical Reliability Engineering, 3rd Edition, John Wiley and Sons, 1991.

Rechtin, E., Systems Architecting of Organizations: Why Eagles Can't Swim, CRC Press, Boca Raton, 2000.

Rechtin, E. and Maier, M.W., The Art of Systems Architecting, CRC Press, Boca Raton, 1997.

Rumbaugh J., Jacobson, I. and Booch, G., The Unified Modeling Language Reference Manual, Addison-Wesley, 1999.

Sage, A.P., Systems Engineering, John Wiley and Sons Inc., 1992.

Sage, A.P. and Rouse, W.B. (Eds), Handbook of Systems Engineering, John Wiley & Sons, 1999.

Shelley, M.W., Frankenstein, Barnes and Nobel Books, New York, 1993.

Shishko, R. and Chamberlain, R.G., NASA Systems Engineering Handbook, SP-6105, 1995.

Szidarovszky, F., Gershon, M. and Duckstein, L., Techniques for Multiobjective Decision Making in Systems Management, Elsevier Science Publishers, Amsterdam, 1986.

Tichy, M. and Sherman, S. Control Your Destiny or Someone Else Will, Currency Doubleday, New York, 1993.

Wymore, W., Model-Based Systems Engineering, CRC Press, Boca Raton, 1993.

Wymore, A.W., and Bahill, A.T., When can we safely reuse systems, upgrade systems, or use COTS components? Systems Engineering, 3(2): 82-95, 2000.