Qualidade de Software Ltda

5: Afastar o cliente do processo de desenvolvimento – o desenvolvimento de software é de competência exclusiva de analistas e programadores, assim uma vez que já se obteve uma descrição funcional do software a ser desenvolvimento não se faz mais necessário a participação do cliente no processo de desenvolvimento. Com o afastamento do cliente a equipe de desenvolvimento se mantém mais focada, o software tem mais chances de ser entregue no prazo e de acordo com as necessidades do cliente.

4º: Não utilizar uma equipe de teste independente - As atividades de testes são onerosas em termos de custos e prazos, assim não se faz necessário a utilização de uma equipe independente de testes. Na maioria das vezes os testes realizados pelo próprio programador garantem um software de boa qualidade, entregue no prazo e com custos controlados.

3º: Utilizar o programador cowboy: aquele que faz todo o desenvolvimento do software sozinho – A divisão de papéis na equipe de desenvolvimento, como analista de negócios, analista de requisitos, arquiteto, programador e testador só burocratiza o processo de desenvolvimento sem trazer benefícios relevantes para a qualidade do software. Assim utilizar apenas um profissional desempenhado todos esses papéis resulta sempre em melhores resultados.

2º: Codificar antes de especificar – Iniciar a codificação do software o mais rápido possível, ainda que os requisitos não tenham sido claramente definidos torna o processo de desenvolvimento mais ágil, permite ao cliente ter uma melhor noção do que ele precisa, além de garantir entregas mais rápidas e de melhor qualidade.

1º: Estabelecer cronograma irreal – Atualmente em função das demandas de mercado, os cronogramas de desenvolvimento de software devem ser agressivos, ainda que pareçam irreais. Sempre é possível aumentar a equipe de desenvolvimento, reduzir prazos com atividades de arquitetura e testes, e em último caso renegociar o prazo com o cliente.

Essas práticas realmente são muito ruins! Mantenha-se afastado delas, por uma qualidade de software melhor!

É muito comum encontrar literatura sobre as melhores práticas para o desenvolvimento de software. Mas vou dedicar alguns posts para elencar em ordem decrescente as dez piores práticas para o desenvolvimento de software. Espero que você não se identifique com essas práticas!

Neste post vou elencar do 10º ao 6º lugar:

10 º : Não estabelecer métricas para o desenvolvimento de software – cada software é desenvolvido de uma forma particular, em função das suas características, e também cada desenvolvedor tem um estilo próprio de codificação. Assim não é possível nem necessário estabelecer métricas como produtividade por linha de código, quantidade de erros por pontos de função detectados em ambiente de produção, cumprimento dos prazos de desenvolvimento, etc. A equipe, mesmo sem métricas tende a melhorar organicamente.

9 º : Não prever capacitação dos usuários para utilização do software – Atualmente as interfaces gráficas são muito intuitivas e de fácil utilização. As crianças já utilizam computadores desde a tenra idade e crescem em contato com esse ambiente. Como hoje os prazos de desenvolvimento são apertados não se faz necessário gastar tempo com a capacitação dos usuários para a utilização do software. Havendo dúvidas de utilização, o usuário sempre pode ligar para o help-desk.

8º : Não utilizar um processo definido para relato de defeitos – durante o processo de desenvolvimento e as diversas etapas de testes, à medida que os defeitos vão sendo encontrados, eles vão sendo priorizados e corrigidos segundo a própria experiência dos programadores. Não há necessidade de um software para gestão de defeitos, o que iria só burocratizar a agilidade da correção dos mesmos. Raramente ocorre de um software ir para a produção com defeitos já conhecidos, que foram esquecidos de serem consertados pelos programadores.

7º : Não utilizar um software de controle de versão – os códigos fontes são mantidos nas máquinas dos programadores envolvidos em cada projeto de desenvolvimento, de forma a dar maior liberdade e velocidade ao programador. O que importa é a experiência e o controle efetuado pelo programador na hora de colocar o software em produção. Um software de controle de versão é caro e burocrático.

6º : Definir a arquitetura do software à medida que o código vai ficando pronto – Pensar e desenhar a arquitetura do software antes do código estar pelo menos 60 a 80 % pronto não é produtivo, e acaba sendo uma atividade de abstração que quase sempre se demonstra inútil. O programador de acordo com a necessidade do código vai definindo a arquitetura necessária e assim o resultado é sempre um software com boa funcionalidade, usabilidade e performance.

Se você conseguiu ler essas cinco piores práticas, é sinal que tem o coração forte. Aguarde as cinco primeiras e faça o teste definitivo do seu coração!

Uma das boas práticas para o desenvolvimento de sistemas é a de testar o código o mais cedo possível. Nesta linha a revisão estática de código é uma técnica que se adotada continuamente contribui para a melhoria da qualidade de código produzido. Ela pode ser feita manualmente utilizando a programação em pares, ou de forma automatizada, com o uso de uma ferramenta de software que apresenta as seguintes vantagens:

1. Utilização de uma base padrão de regras para a revisão de código

2. Execução da revisão de código de forma automatizada durante a geração do "build" do software

3. Estabelece uma cultura voltada às boas práticas de codificação, evitando a geração de códigos ruins.

A revisão de código permite a otimização do código associado à internacionalização; performance; portabilidade; facilidade de uso; lógica; API do Windows e banco de dados.

Uma boa estratégia de implantação é garantir que todos os desenvolvedores tenham acesso a uma ferramenta de revisão de código e a uma base corporativa, com os padrões customizados para as necessidades das equipes de desenvolvimento.

Os desenvolvedores devem garantir que o seu código esteja em conformidade com a base corporativa, antes de liberá-lo para o ambiente de produção. Visando certificar a conformidade do código colocado em produção, deve-se ainda executar de forma automatizada a revisão de código em tempo de geração de build e publicação em produção. Detectando-se alguma inconformidade, pode-se decidir se o código deve ou não ser implantado em produção, informando o desenvolvedor sobre o tipo de ocorrência detectada.

Segue abaixo dois links para acesso a ferramentas de uso gratuito para os ambientes de desenvolvimento .NET e Java:

Fxcop – Plataforma .NET: http://code.msdn.microsoft.com/codeanalysis/Release/ProjectReleases.aspx?ReleaseId=553

Jupiter – plugin para o Eclipse (Java) : http://code.google.com/p/jupiter-eclipse-plugin/