Pesquisa

sexta-feira, 29 de janeiro de 2016

TI em foco: Qualidade de Software - parte 1

Bom sei que muita gente desconhece minha profissão, e agora decidi por vezes postar aqui assuntos relacionados a minha área: a de Tecnologia da Informação, ou TI. O tema de hoje é muito atual, e fica para reflexão dos profissionais que atuam principalmente com sistemas.

Não sou expert no assunto, porém após mais de 9 anos respirando TI aprendi muitas coisas. E dentre todos os aprendizados, alguns para esquecer... rsrs...aprendi e entendi que é prática comum em muitas "fábricas" de software, entregar aplicações ruins e cheias de bugs...infelizmente! E isto, na maioria das vezes, está intimamente relacionado ao fato de muitas fábricas/consultorias focarem mais na entrega e no cumprimento de prazos, do que na qualidade do produto final.

Mas como tudo pode mudar, e eu acredito que muitas empresas busquem essa mudança, vamos focar no lado bom da "força" e falar de qualidade e seus benefícios. Abaixo falaremos de uma etapa importantíssima do processo de "concepção" de uma aplicação/sistema: a análise.

Muitas empresas acham que o mais importante é desenvolver, e nessa linha dedicam pouco tempo a analisar o escopo e documentar. Acham que a documentação "pode ficar pro final", e focam mais em "pular" esta etapa, ou torna-la breve. Pois é, se você trabalha em empresas que têm essa ideia "na mente", provavelmente seus sistemas serão daqueles que demorarão e muito para sair do papel! Provavelmente verá um cronograma fortemente desenhado para a fase de desenvolvimento...o que é ruim!

Analisar sem dúvida é uma etapa extremamente importante, e talvez a mais importante, pois é nesta etapa que tudo que o sistema deve possuir e realizar será definido. Eu, particularmente, considero esta etapa o "termômetro" de todas as demais etapas, pois quando se analisa mal, ou de forma preguiçosa a tendência é termos um loop de "bate e volta" onde muita coisa se detecta no momento de desenvolver, e isto além de ser terrível, praticamente sentencia todo o resto ao fracasso! Inclusive já trabalhei em sistemas que só no momento de homologar foi detectada uma necessidade que "passou batida" pela análise...gerando um retorno a fase inicial, resultando em atraso e muita confusão!

Para realizar uma análise mais profunda e detalhada, cabe documentar os requisitos, tirar dúvidas e, por fim, diagramar todo o conteúdo. Tem gente que acha que diagrama é chato e trabalhoso, mas fazer a diagramação (usando UML, por exemplo) permite uma reflexão ainda mais profunda, pois neste momento se inicia a transcrição do negócio para uma lógica ou escopo do que será realizado pelo sistema. Um exemplo legal, é o diagrama de classe, onde inicialmente definimos as principais entidades e a partir desta primeira definição, partimos para o detalhamento de atributos, relacionamentos (generalização e especialização) e outros. Ou seja, o ato de criar diagramas não é mero "fru fru"...mas sim uma grande oportunidade de analisar cenário a cenário, e ponto por ponto. Para entender melhor, basta imaginar que para construir uma casa necessariamente precisamos primeiro preparar o terreno, e no nosso caso esta preparação se refere a análise do escopo.

O que quero deixar para você, é que somente dando o devido valor a esta etapa importante, se terá a oportunidade de conceber um produto de qualidade e que atenda ao que foi idealizado pelo cliente. Ou seja, analisar é um "divisor de águas" entre o sucesso e o fracasso.

Por fim, espero ter feito você refletir e entender que, caso venha no futuro desenvolver um sistema, deve se certificar que o mesmo foi profundamente analisado, pois a análise bem realizada certamente irá permitir o entendimento do que foi passado pelo cliente. Assim como também dará base, com qualidade e riqueza, para a próxima etapa: o desenvolvimento.

Até a próxima!