Vejo a manutenção e a implementação como as fases do processo de software mais afetadas pela questão da qualidade. Isso é bem óbvio.
Primeiramente, vou falar da manutenção que, dependendo do tempo de vida da aplicação, é a fase mais longa do processo.
Manutenção, resumidamente, é qualquer procedimento que leve a alteração do código, durante a implementação e após a release final.
O negócio do cliente muda constantemente. O sistema precisa acompanhar este dinamismo. Requisitos nascem, mudam e morrem a todo instante. A aplicação deve se adaptar. Complexidade de implementação vai depender da complexidade do requisito, dessa forma, é relativa. Mas a questão é: seu código não deveria ser uma pedra no caminho.
Já precisei reconstruir uma aplicação inteira, pois ficou impossível adicionar mais requisitos. Era um monstro quase monolítico, em Delphi 6. As units eram enormes e toda a regra de negócio era programada nos eventos. TODA!
Era o tipo de aplicação que se mudasse ou acrescentasse uma vírgula acontecia um desastre. Usando uma expressão do Page-Jones neste livro, era Conascença de Aplicação. Pelo menos o desenvolvedor criou um tipo de conascença.
Expliquei a situação para o dono da empresa que sabia se tratar de uma aplicação crítica. Depois de algumas negociações de prazo, iniciamos o projeto.
Esta situação foi razoavelmente fácil de contornar, pois não havia ninguém (líder, gerente) entre o desenvolvedor e os responsáveis pelo negócio. Compreenderam que a reconstrução era o melhor para o negócio, investiram nela por alguns meses e ainda estão colhendo os frutos. Este fato ocorreu no final de 2005 e a aplicação funciona até hoje, sendo mantida por outra pessoa desde o fim de 2007.
Primeiramente, vou falar da manutenção que, dependendo do tempo de vida da aplicação, é a fase mais longa do processo.
Manutenção, resumidamente, é qualquer procedimento que leve a alteração do código, durante a implementação e após a release final.
O negócio do cliente muda constantemente. O sistema precisa acompanhar este dinamismo. Requisitos nascem, mudam e morrem a todo instante. A aplicação deve se adaptar. Complexidade de implementação vai depender da complexidade do requisito, dessa forma, é relativa. Mas a questão é: seu código não deveria ser uma pedra no caminho.
Já precisei reconstruir uma aplicação inteira, pois ficou impossível adicionar mais requisitos. Era um monstro quase monolítico, em Delphi 6. As units eram enormes e toda a regra de negócio era programada nos eventos. TODA!
Era o tipo de aplicação que se mudasse ou acrescentasse uma vírgula acontecia um desastre. Usando uma expressão do Page-Jones neste livro, era Conascença de Aplicação. Pelo menos o desenvolvedor criou um tipo de conascença.
Expliquei a situação para o dono da empresa que sabia se tratar de uma aplicação crítica. Depois de algumas negociações de prazo, iniciamos o projeto.
Esta situação foi razoavelmente fácil de contornar, pois não havia ninguém (líder, gerente) entre o desenvolvedor e os responsáveis pelo negócio. Compreenderam que a reconstrução era o melhor para o negócio, investiram nela por alguns meses e ainda estão colhendo os frutos. Este fato ocorreu no final de 2005 e a aplicação funciona até hoje, sendo mantida por outra pessoa desde o fim de 2007.
Nem sempre a solução é simples, pois, normalmente, existem pessoas entre o cliente e o desenvolvedor que, muitas vezes, têm interesses que os impedem de pensar na qualidade. O crédito desse parágrafo vai para um diálogo que acabei de ter com Paulo Cereigido, companheiro de embarcação. É um assunto que será abordado em um post futuro.
O ponto é: ficar resmungando com os botões, reclamando do cliente, não resolve nada. Só trará desgostos e mágoa com a profissão. Precisamos fazer algo para mudar esse tipo de mentalidade nociva e imediatista. E é basicamente essa a pretensão deste blog. Buscar caminhos para implantação definitiva da qualidade.
EDIT: Quero deixar claro duas coisas:
O ponto é: ficar resmungando com os botões, reclamando do cliente, não resolve nada. Só trará desgostos e mágoa com a profissão. Precisamos fazer algo para mudar esse tipo de mentalidade nociva e imediatista. E é basicamente essa a pretensão deste blog. Buscar caminhos para implantação definitiva da qualidade.
EDIT: Quero deixar claro duas coisas:
- Estou considerando desenvolvimento = análise + programação + teste unitário;
- Quando falo em qualidade, falo em qualidade de código.
É, realmente a única certeza que temos é a de que concerteza algo vai mudar no sistema hehehe... trabalhar com manutenção de sistemas nos faz ter um cuidado muito especial na hora de criar um, pois só quem trabalha sabe como é difícil corrigir código ruim.
ResponderExcluirParabéns pelo post, abraços.
Excelente post. Infelizmente em muitos lugares (senão todos) a prioridade é tempo... E a qualidade é moldada com o tempo que é dado. Dificilmente encontramos um cliente que esteja realmente preocupado com a qualidade entregue. É do tipo, funciona? então tá bom! Fato é que a empresa que entende o funcionar como consequencia de um projeto bem modelado e com qualidade está bem a frente de seus concorrentes!
ResponderExcluir@evieira
ResponderExcluirSim, é verdade. Essa é, para mim, a grande preocupação que devemos ter: Ter a sempre a qualidade em mente, como grande prioridade.
@The Gaph
Grande cientista. Mas é justamente por isso que criei esse blog e essa questão de Tempo X Prioridade será um dos focos principais. Acho que é um trabalho de conscientização a longo prazo de alguns dos envolvidos no processo: Cliente, Consultoria e Desenvolvedor.
Abraços!
Meu camarada,
ResponderExcluirQueria lhe parabenizar pelo Blog. A idéia foi muito legal.
Abs,
@Leandro
ResponderExcluirObrigado Valcace.
Obrigado por prestigiar esse singelo espaço.
Abraços!
@The Gaph
ResponderExcluirCientista, onde eu disse "Tempo x Prioridade" leia "Tempo x Qualidade". A coisa estava enrolada na hora que respondi e acabei me equivocando.
Abraços!