produtos
A Evolução do ‘Artesanato’ Para a ‘Engenharia de Sistemas’
por Gefferson de Medeiros
Este artigo foca na relevância das teorias e práticas de desenvolvimento de software e sistemas criadas pela dra. Margaret Hamilton, diretora da Divisão de Software do Laboratório de Instrumentação do MIT. Ela cunhou o termo Engenharia de Software e foi responsável pelo desenvolvimento do software dos projetos Apollo e Skylab, da NASA. O estudo empírico destes projetos e seus desenvolvimentos inverteram o paradigma equivocado, aceito então como padrão e ingenuamente ainda usado por profissionais de TI na Era Digital para desenvolver sistemas. Tais inovações foram comprovadas em uma situação crítica que levou o primeiro homem à lua, em 1969. Meio século depois, ela declarou publicamente:
“O computador (ou melhor, o software nele) foi inteligente o suficiente para reconhecer, que estava sendo solicitado a executar mais tarefas do que deveria estar realizando ( …) Se o SW do computador não tivesse reconhecido esse problema e tomado a ação de recuperação, eu duvido, que a Apollo 11 teria tido o pouso bem sucedido na lua.”
As empresas, em plena Era Digital, ainda usam ambientes tradicionais de engenharia de sistemas, que são lentos e ineficientes, baseados em um paradigma anacrônico de desenvolvimento de sistemas, tendo em vista desenvolver os seus aplicativos, quaisquer que sejam os seus tamanhos, as suas complexidades, arquiteturas, plataformas de produção e outras singularidades. O problema desta abordagem de desenvolvimento de sistemas, que é usada desde os anos 1960, a assim chamada ‘Desenvolvimento Após os Fato’, é que as descobertas de erros – se acontecerem – somente ocorrem na fase de testes do sistema, a qual é a última etapa do ciclo de vida de desenvolvimento de qualquer sistema.
O GGN ESTÁ EM CAMPANHA NO SITE “CATARSE” PARA LANÇAR UMA SÉRIE DE REPORTAGENS E UM DOCUMENTÁRIO INÉDITO SOBRE PREVIDÊNCIA, TOMANDO AS CONSEQUÊNCIAS DA CAPITALIZAÇÃO NO CHILE COMO EXEMPLO DO QUE O GOVERNO BOLSONARO DESENHA PRO BRASIL. PARA SABER MAIS E APOIAR ESSE PROJETO, ACESSE: www.catarse.me/oexemplodochile
Entretanto, os erros descobertos podem estar localizados, por exemplo, nas atividades de requisitos, análise, ou modelagem, as quais fazem parte da primeira etapa do ciclo de vida de desenvolvimento de um sistema. Os erros também, frequentemente, estão localizados nas etapas posteriores, tais como no projeto, e na criação de códigos das aplicações. Projetistas de sistemas costumam pensar e projetar de maneira limitada, uma vez que são suportados por metodologias antigas. Na definição de requisitos, os projetistas usam técnicas incompatíveis para capturar aspectos de até mesmo uma única definição. Fluxo de dados, transições de estado, dinâmicas, tipos de dados e estruturas, todos são definidos, usando técnicas diferentes. Após obter as definições, não há como integrá-las e esta é a razão pela qual a TI tem produzido este incrível número de silos de dados durante as últimas décadas.
Em síntese, as atividades críticas de desenvolvimento de sistemas ainda são práticas artesanais ou realizadas, eventualmente, por ferramentas que não se integram harmonicamente ao ciclo de vida de desenvolvimento de sistemas, de tal forma que promovam a automação de todo o ciclo de vida de desenvolvimento de sistemas, até mesmo se o sistema alvo for muito simples. O suporte aos usuários acaba sendo a norma, que corrige as coisas erradas, em vez de construir coisas, que funcionem na primeira vez. No mundo inteiro, a entrega de sistemas de baixa qualidade aos usuários de negócios está frequentemente atrasada, bilhões de dólares costumam ser desperdiçados e a produtividade dos desenvolvedores de sistemas é quase sempre considerada baixíssima. Definições de requisitos em cenários de desenvolvimento tradicionais concentram-se nas necessidades da aplicação do usuário, desconsideram o potencial de mudanças na área de negócios – sejam elas internas e/ou externas – ou do próprio ambiente alvo do sistema do usuário. A portabilidade do sistema se torna um novo desenvolvimento para cada nova arquitetura, sistema operacional, Database, ambiente gráfico, linguagem de programação ou configuração de linguagem.
Claramente, o paradigma ‘Desenvolvimento Após os Fatos’ usado no desenvolvimento de sistemas deve ser descartado para se buscar reduzir drasticamente os custos de desenvolvimento, elevar a qualidade dos sistemas entregues aos usuários de negócios e promover uma engenharia reversa de sistemas, que precisam evoluir para aprimorar as inovações de negócios da empresa na Era Digital.
A automação em si é um processo inerentemente reutilizável – os desenvolvedores tentam promover reuso, tardiamente, na atividade de codificação. Se um sistema não existe para reutilização, certamente não existe para automação. É evidente que a maior parte do processo de desenvolvimento atual é desnecessariamente artesanal. Os sistemas ainda hoje são definidos com inteligência insuficiente para que ferramentas automatizadas possam usá-los como entrada em todas as etapas de desenvolvimento de sistemas. Na verdade, as práticas comprovam que as ferramentas automatizadas utilizadas se concentram em apoiar o processo artesanal em vez de fazer o trabalho real de desenvolvimento de um sistema.
Conforme pode ser constatado nos itens acima expostos, a Abordagem ‘Artesanal’ de Desenvolvimento de Sistemas foca primordialmente em corrigir o que está errado. Portanto, não faz mais sentido insistir na sua utilização na Era Digital. Ao serem repensadas, as práticas de desenvolvimento de sistemas usadas na abordagem ‘artesanal’ deverão ser alvo de uma transformação digital, de tal forma que ela possa conduzir a TI a adotar o novo paradigma da abordagem de engenharia de sistemas, o ‘Desenvolvimento Antes do Fato’.
A ‘nova’ abordagem de desenvolvimento de sistemas baseada na engenharia de software já provada em 1969
A Abordagem de ‘Engenharia de Software e Sistemas’, o ‘Novo’ Paradigma de ‘Desenvolvimento Antes dos Fatos’
Um ambiente de desenvolvimento de software e sistemas foi criado para automatizar o paradigma matematicamente fundamentado, assim chamado Desenvolvimento Antes do Fato (DBTF – acrônimo de Development Before The Fact). Juntamente com a sua automação (o 001 Tool Suite), o DBTF tem sido utilizado em pesquisas, e organizações “trail blazer” e agora está sendo adotado para uso comercial.
Além de suas raízes no desenvolvimento de sistemas e projetos de sistemas do mundo real, o DBTF tem origens em outros mundos, incluindo teoria de sistemas, métodos formais, linguística formal e tecnologia de objetos. Por ser ainda algo ‘novo’, seria natural fazer suposições sobre o que é possível e impossível com base em sua semelhança superficial com outras tecnologias, como a tecnologia de objetos. No entanto, ajuda a eliminar todas e quaisquer noções preconcebidas quando projetistas e desenvolvedores são introduzidos pela primeira vez no DBTF, visto que o DBTF é um mundo em si – uma maneira completamente nova de pensar sobre sistemas de negócios e software. O DBTF engloba um paradigma preventivo, o qual se concentra em evitar que problemas de desenvolvimento aconteçam, ao invés de deixar que eles ocorram “após o fato” e corrigí–los mais tarde, quando eles surgirem no ponto mais inoportuno e caro ao longo do tempo de desenvolvimento (e às vezes até mesmo já em produção).
Uma linguagem de sistemas formal baseada nos fundamentos do DBTF, a USL, é usada para definir um sistema DBTF. Com esta linguagem, um sistema tem propriedades, que pegam “carona”, as quais em essência controlam seu próprio destino. Por causa dessas propriedades, muitas coisas até então não consideradas possíveis com métodos tradicionais são agora possíveis com o DBTF [ver tabela comparativa, imediatamente abaixo].
O software de automação do ciclo de vida de desenvolvimento pode ser usado para projetar um sistema, prototipar um sistema ou desenvolver um sistema completamente, e muito mais. O foco do novo estilo de desenvolvimento é “fazer as coisas certas da primeira vez”, evitando assim a abordagem tradicional de “corrigir coisas erradas”. O software de automação do desenvolvimento deve fornecer recursos de rastreabilidade de requisitos para o projeto e a implementação. Dessa forma , o sistema em desenvolvimento será, naturalmente, gerenciável e passível de manutenção/evolução, no limite, por exemplo, para fazer uma engenharia reversa para promover a simplificação das especificações de um sistema legado, tendo em vista eliminar a redundância desnecessária de dados persistidos nos diversos silos de dados da empresa.
A filosofia preventiva do DBTF, para resolver um problema o mais cedo possível, implica em descobrir os problemas antes de implementá–los. Definitivamente, inibir os problemas pela maneira como o sistema é definido é ainda muito melhor. Parafraseando Neil Armstrong, ‘Esse é um pequeno passo para qualquer TI, um salto gigantesco para as EMPRESAS‘, tendo em vista diferenciá-las para ser altamente competitivas na na ‘Era Digital’.
Faça login para comentar Você pode fazer o Jornal GGN ser cada vez melhor.
Apoie e faça parte desta caminhada para que ele se torne um veículo cada vez mais respeitado e forte.
Falou, falou e no final é só propaganda da USL.
Não deixa claro o quer quer, qual o público nem o perfil de usuários se quer atingir.
Não se destina aos desenvolvedores, talvez aos gerentes de desenvolvimento de produtos de software.
O que temos hoje são realidades muito distintas com necessidades mais distintas ainda. Querer usar um único modelo para resolver todas as soluções não funciona.
Um software militar para controle de mísseis é bem diferente de um software comercial para controle de pedidos. Mesmo o último pode variar enormemente se colocarmos como clientes grandes ou pequeno varejistas, se a operação se dá em nuvem ou nas instalações do próprio cliente.
É um bom assunto, mas o texto é ruim.
Que nada! O futuro é o “artesanato” com nióbio!!!!