0

Deu ruim no levantamento de Requisitos: A Síndrome de Dr. Ivon SaF.

#Arquitetura de Sistemas #Logística #Produto Digital
Vagner Bellacosa
Vagner Bellacosa

Analise de requisitos, sistemas legados e IBM Mainframe



O trabalho inicial para um projeto de software garante o sucesso ou fracasso da equipe, atualmente temos inúmeras metodologias para o desenvolvimento de código, é independente da tecnologia utilizada, existe um ponto que costuma dar bem ruim, um atalho rápido e direto para o infortúnio.


Neste artigo irei comentar sobre um problema muito comum no levantamento de requisitos, que geram lacunas e má coleta de dados. Segundo a lenda um médico alemão, na idade média, perdia muitos pacientes devido a ter pressa em cura-los, apressando-se no diagnostico, sem ao menos compreender realmente quais os sintomas da doença, contando com a sorte e acaso nas suas poucas curas.


Em informática a síndrome do Dr. Ivon Saf, se multiplicou rapidamente e expandiu-se para diversos ambientes de desenvolvimento, atrapalhando e elevando os custos de codificação, estourando orçamentos e prazos, enlouquecendo programadores e arruinando reputações, foi-me apresentada  pelo grande mestre Jedi Marcio Martini, um consultor de Análise de Sistemas com muitas técnicas e ferramentas aprendida s com o próprio Mestre Yoda dos mainframes , Martini que atuou durante décadas, treinando gerações de analistas nos anos de 80 e 90 do século passado e 2yk ajudando a combater essa síndrome e a gerarmos bons códigos.


Conheça mais detalhes da SINDROME do Dr. IVON SAF, ou síndrome da Incrível VONtade de SAir Fazendo, levando inúmeros projetos rumo ao fracasso, que graças a inexperiência, inocência e necessidade de colocar-se em evidencia. O analista de sistemas e sua equipe de desenvolvimento fazem um mal trabalho, gerando erros de entendimento, erros de programação e nos casos mais graves, enviando a produção software incompatível com as necessidades do cliente, causando danos de imagem e custos ao cliente pelo uso ineficaz de ferramenta.


Afinal, em detalhes, o que é esta síndrome, resumidamente é a sanha, a vontade de sair codificando, sem antes fazer uma boa analise e reflexão sobre o problema, para uma boa codificação, recomenda-se que use o maior computador de todos os tempos: com seus periféricos poderosos: Lápis, Papel e Borracha, juntamente com um processador multitarefas potente o seu cérebro. Entre em ação, rascunhe, desenhe, faça teste de mesa, entenda a necessidade, verifique a problemática sob várias óticas, a continuação irei apresentar algumas técnicas utilizadas em Mainframe, aprendida no antigo Banco Real e utilizada durante décadas nos diversos Bancos em seu ambiente de mainframe por gerações de programadores.


Independente da sua posição, Junior, Pleno ou Sênior todos somos analistas, devendo obter informações bem detalhadas sobre o software a ser desenvolvido, sejam ela desenhos técnicos legados, fluxogramas, software descontinuado, entrevista com analista de sistemas e a mais importante entrevista com o cliente para sanar dúvidas e entender o que se deseja ser feito.


Lembre-se que ao desenvolver um software devemos sempre atender a 3 tipos de requisitos: requisitos funcionais, requisitos nao funcionais e regras de negócio. Lembrando em linhas gerais que Funcionais são aqueles requisitos que tratam da função; Nao Funcionais referem-se as questões de ambiente, performance, espaço em disco, infraestrutura de modo gerais e finalizando Regras de Negócios por exemplo legislação, regras de formatação, workflow e especificidades do produto.


Existem inúmeras técnicas para o Levantamento, a seguir deixo algumas não exaustiva, de forma reduzida apenas para nos situar sobre o trabalho:


1) Entrevista técnica: o analista irá reunir-se com os programadores que conhecem bem o software para entender seu funcionamento, input, outputs, dependências o e o ambiente;


2) Entrevista Funcional: o analista se reúne com a área cliente e outros players, conhece a realidade e as necessidade do utilizador;


3) Questionário: após a primeira e segunda bateria de entrevistas, ocorre um refinamento das necessidades e com as dúvidas surgidas se faz um questionário com as principais dúvidas e questões;


4) JAD -Joint Application Design: é um projeto de interação continua, onde todas as equipes envolvidas se reúnem para discutir, num circuito de retroalimentação para refinar as necessidades e as suas possíveis soluções.


5) Prototipação: após as inúmeras reuniões, refino, levantamento, desenho técnico, desenho funcional e desenho arquitetural; a equipe produz um protótipo para ser validado com o utilizador antes de iniciar a codificação a sério.


Em conclusão a síndrome do Dr. Ivon Saf, prejudica muito o trabalho da equipe de sistemas, pois ao sair codificando, desenhando, modelando afobadamente, sem conhecer a real dimensão do problema, a necessidade do cliente, as limitações técnicas e custos ocultos. O produto final entregue estará com inúmeras anomalias e erros estruturais que poderão comprometer a competitividade da empresa, a imagem da equipe e causar sérios problemas ao usuário.


Então antes de sair fazendo, contenha-se, respire, pense, reúna-se e converse. Crie um documento técnico, valide os principais pontos, sane todas as dúvidas, veja se a solução se adequa a realidade do cliente, veja se os equipamentos suportam a solução.


Cuidado com a pressa de entregar. Não gere retrabalhos desnecessários, que gerem o aumento do custo do projeto exponencialmente. Lembre-se lápis e papel são baratos e permitem inúmeras versões.


Espero ter ajudado, aproveito para perguntar se conhece alguém que sofre ou sofreu desta síndrome? Escreva nos contando o que aconteceu, as implicações e as solução. Caso tenham interesse poderei num próximo artigo explanar um pouco mais sobre JAD, Levantamentos e procedimentos para analise em Mainframe. Fiquem bem, estudem, evoluem, compartilhem, unidos somos mais fortes.


#AnaliseSistemas #Legado #IvonSaf #Requisitos #Programaçao #codificaçao

0
8

Comentários (0)

Analista Programador dinossauro IBM Mainframe

Brasil