“Nada é tão fácil ou tão difícil quanto parece.”
Ultimamente venho me deparando com um problema muito grande no desenvolvimento de software e que afligem muitos dos desenvolvedores de sistemas. É a de fazer a documentação do sistema. Na verdade fazer a documentação não é o real problema, mas sim a forma como ela é feita e como ela está inserida no processo de desenvolvimento de software. Não vou entrar no grande pensamento filosófico de que a documentação é necessária ou se é perda de tempo ou que devemos fazer uma gama de diagramas ou apenas rascunhos no quadro branco. Aqui estou partindo da premissa de que a documentação tem uma importância de grande relevância para todo o processo de desenvolvimento de software.
Muitos desenvolvedores, gerentes e até mesmo clientes não dão a devida importância à documentação de um sistema e seu impacto dentro do processo de desenvolvimento de software. A maioria sempre acha que a documentação está em segundo plano, que quando o cronograma aperta podemos simplesmente pegá-la e jogá-la “fora” naquele momento até a entrega do sistema e depois voltarmos para trás e fazer toda a documentação como se estivéssemos apenas transpassando o sistema (código-fonte) para o Word, gráficos, matrizes, diagramas e etc.
E é aí que está o vilão da história. A maioria dos desenvolvedores, gerentes e clientes vêem a documentação como o grande empecilho na construção dos sistemas e por simplesmente acharem que ela é pura digitação ou como muitos chamam, “Desenhosinho”, ignoram que ela é o resultado fiel da análise do domínio do problema do sistema e que nela fica registrado a solução encontrada que satisfaz os requisitos necessários para o entendimento do negócio do cliente e a construção do sistema. Em muitos projetos já vi as maiores atrocidades feitas nos sistemas por simplesmente não fazerem a documentação da forma correta, ou seja, fazer a análise do problema e chegar a uma solução coesa que atenda o cliente de forma eficaz. Já me deparei com casos em que um plano de teste não é criado ou caso seja, não contempla todos os cenários de testes impactando dessa forma os testes de QA e de integração do processo de negócio que o sistema deve abranger. Simplesmente todo o processo de desenvolvimento de software é ignorado, pois a maioria dos desenvolvedores, gerentes e clientes não entendem ou não querem entender que cada documentação tem pré-requisitos que são as documentações criadas nas fases anteriores do desenvolvimento.
Como por exemplo, não podemos ter um plano de teste sem ter os casos de uso com as regras de negócio, assim como não podemos ter os casos de uso sem fazer uma análise do levantamento de requisitos e ter o mapeamento do domínio do problema. Isso sem mencionar nas demais documentações que também tem seus pré-requisitos. O que me preocupa muito é que muitos desenvolvedores se preocupam somente com o código, querendo simplesmente sair codificando que nem loucos. Se pelo menos durante a codificação fosse feita a análise do problema de forma clara e coesa, o sistema em termos de código, componentização, integração e arquitetura em geral seria bem feito, mas não é o que acontece. O que acontece é que caem no código sem se preocupar com esses detalhes e transformam o sistema em uma “colcha de retalhos” com muitas redundâncias e sem usar nenhum padrão de software, tornando assim a manutenção e a evolução do sistema muito difícil, pois além de não existir a análise do problema, não existe a documentação mínima necessária para entender o que o sistema faz e porque certas decisões na codificação foram adotadas.
Enquanto vivermos em um mundo onde os desenvolvedores de software acham que são excelentes programadores e não excelentes analistas de sistemas ou de negócio, estaremos fadados a reviver sempre os mesmos problemas no desenvolvimento de software.
