Uma coisa que aprendi em minha carreira como engenheiro de sistemas é que ainda tenho momentos incríveis. E quando meus alunos têm momentos de aha, fico igualmente satisfeito. Recentemente dei uma aula sobre engenharia de sistemas baseada em modelos que inclui exercícios práticos de MBSE em um ambiente de ferramentas. Na aula, examinamos conceitos gerais de engenharia de sistemas, como requisitos, comportamento (como no controle funcional, sequenciamento funcional e acionamento) e análise arquitetural. Também discutimos a importância da integração da engenharia de sistemas em camadas e entre domínios de engenharia de sistemas.
Da forma como minha aula funciona, eu explico um conceito e, em seguida, libero os alunos para trabalharem em um laboratório local para modelar um projeto usando o conceito que acabaram de aprender. Neste caso, pedi aos alunos que construíssem um Diagrama de Blocos de Fluxo Funcional Aprimorado (EFBD), para modelar o comportamento que poderia então ser verificado usando o simulador de eventos discretos integrado no produto GENESYS da Vitech.
Isso permite que os engenheiros vejam gráfica e textualmente a execução de seus modelos. Um aluno construiu cuidadosamente um modelo, pensando ter seguido todos os passos apropriados. Mas, repetidas vezes, ao executar o simulador, ele recebia um erro em que uma função não era executada porque não recebia uma mensagem de acionamento. Curiosamente, ele parecia ao mesmo tempo irritado e, se não exatamente feliz, intrigado. Eu poderia dizer que ele estava tendo um momento de aha – quase pude ver a luz se espalhando por seu rosto quando uma nova ideia lhe ocorreu.
Quando perguntei a ele sobre isso, ele me disse que no ambiente de design de seu local de trabalho, “Este [erro] não teria sido encontrado”. Ele não teria ideia de que eles haviam projetado algo incorretamente. Seu momento decisivo foi a compreensão dos benefícios de um ambiente de engenharia de sistemas integrado e baseado em modelos. Nesse ambiente, as visões padrão têm um significado real. Eles refletem a engenharia e não são caixas e linhas estáticas ou diagramas desconectados publicados no Word.
Em outras palavras, não são o que chamo de visualizações de “belas imagens”, ou seja, artefatos somente de texto que muitos de nós continuamos a usar.
Também discutimos como reconhecer um problema usando engenharia de sistemas baseada em modelo e como os problemas podem ser vistos com muito mais facilidade usando essa ferramenta, porque a visão de engenharia é uma representação ao vivo dos dados de engenharia e significativamente mais do que uma imagem bonita.
“Um desenho ou vista feio”, eu disse à turma, “provavelmente significa que a engenharia por trás da vista é feia”. Talvez não seja feio, mas não totalmente certo. Usando a metodologia STRATA da Vitech, nossa ferramenta GENESYS e um pouco de experiência em engenharia de sistemas, os engenheiros de sistemas podem ver problemas no projeto, fazer alterações em um único local dentro do modelo e, ao fazê-lo, atualizar automaticamente cada visão de engenharia e relatar artefatos para garantir eles refletem consistentemente o design atual. Antes de compartilhar visualizações atualizadas, os engenheiros também podem testar novamente o projeto usando o simulador discreto integrado para ter certeza de que o projeto está correto.
Meu aluno achou seu momento aha simulando comportamento, mas eu pessoalmente tive momentos aha enquanto modelava. Lembro-me claramente de ter construído uma string funcional – alguns as conhecem como cenários ou threads – quando percebi que precisava de uma mensagem de gatilho para que minha funcionalidade fosse executada. Alguém poderia pensar que é uma mudança pequena e, de fato, criar a mensagem desencadeadora no modelo foi fácil. No entanto, esta questão levou a outra questão: Onde foi gerada a mensagem?
Ao procurar a função para gerar a mensagem, descobri que ela não existia. Minha incapacidade de encontrar uma fonte ou função geradora levou ao desenvolvimento de um comportamento adicional. Além disso, a análise da mensagem levou a uma análise da interface, porque a mensagem tinha que ser atendida por uma interface. O trabalho adicional poderia ter sido considerado irritante ou uma distração, mas na verdade era fundamental para um bom design. Pense nas alternativas. Se o projeto tivesse progredido ao longo do ciclo de vida do projeto e a mensagem perdida não fosse encontrada até que um protótipo de primeira construção fosse concluído, o custo para resolver a mensagem perdida teria sido significativo. Encontrar erros no início de um projeto não é glamoroso, mas essa é a vida de um engenheiro.
Em 2004, o Johnson Space Center da NASA lançou um artigo, Error Cost Escalation Through the Project Life Cycle. O documento detalha os custos crescentes de encontrar erros, inconsistências ou incompletudes, e como quanto mais tarde for necessária uma alteração no design, mais custará. O metodologista-chefe da Vitech e primeiro presidente, Jim Long, é citado como tendo dito: “Depois que você escolhe um problema, a quantidade de engenharia de sistemas que você deve fazer é corrigida”. A questão é quando você fará isso e quanto custará. O uso de nossa metodologia e ferramentas facilita a localização de problemas durante os estágios iniciais do design.
Outras maneiras de encontrar ahas são através do uso de ferramentas automatizadas. Eu uso relatórios padrão diariamente – verificações automatizadas de integridade e consistência do projeto e visualizações de hierarquia e rastreabilidade – para identificar o trabalho que preciso realizar para amadurecer meus modelos e projetos. Assim como meu engenheiro, também uso o simulador de eventos discretos para entender as propriedades emergentes do meu projeto que provavelmente não teria visto usando planilhas, desenhos e documentos processados ​​em texto. Não quero que você pense que não uso o MS Office para me comunicar – com certeza uso, mas uso uma metodologia de engenharia de sistemas baseada em modelo e ferramentas integradas para criar designs melhores, mais completos e mais consistentes. Ao fazer isso, mesmo depois de 30 anos de prática, ainda passo por algumas dificuldades ao longo do caminho.
Experimente aplicar nossa metodologia e nossas ferramentas. Você pode experimentar alguns dos seus próprios problemas.