Qualidade de Software Ltda

O software é o combustível utilizado pelos negócios modernos, construir e manter software de qualidade, de forma repetitível e previsível é difícil hoje e se tornará cada vez mais difícil. São sintomas típicos de problemas no desenvolvimento de software: falha no entendimento das necessidades dos usuários; inabilidade de tratar mudança de requisitos; descobrimento tardio de demandas importantes do projeto; falta de um processo definido para o desenvolvimento de software

Geralmente os projetos de desenvolvimento de software falham devido às seguintes causas: gerência “por demanda” dos requisitos; comunicação ambígua e imprecisa; arquitetura fracamente definida; complexidade sub-estimada; inconsistências não identificadas nos requisitos, projeto e no código e testes insuficientes. Ao tratar essas causas, através de uma metodologia de desenvolvimento de software, os sintomas serão eliminados e será mais fácil desenvolver e manter um software de qualidade de forma previsível e que possa ser repetida.

Segundo o dicionário Aurélio metodologia é o estudo dos métodos; caminho pelo qual se atinge um objetivo. Modo de proceder, maneira de agir.

As principais características de uma metodologia de desenvolvimento são Leia mais …

Você conhece algum desenvolvedor de software que gosta de metodologia para desenvolvimento?  Desenvolvedor gosta de exercer sua criatividade, gosta de imprimir seu estilo de codificar, gosta de liberdade e geralmente não gosta de regras!

E do ponto de vista da empresa? Adotar uma metodologia rígida, uma metodologia flexível ou nenhuma metodologia ?

Independentemente do tamanho da empresa e do seguimento de sua atuação toda empresa precisa de alguma metodologia para o desenvolvimemto de software, pois os funcionários tiram férias, ficam doentes e pedem as contas e nesses casos haverá alguma documentação do software que permitirá uma manutenção emergencial ou mesmo evolutiva sem sobressaltos.

Duas abordagens que eu não acredito são:

1- Metodologia rígida -São boas para desenvolvimento de software de missão critica (principalmente aqueles que podem fazer com que haja perda de vidas) Fora desse domínio a metodologia rígida vira favas contadas, peça de museu, piada em “happy hour”

2 – Bom senso – Deixe por conta do bom senso dos desenvolvedores que eles produzirão um com junto mínimo de documentos, além do próprio código do software.

Então qual abordagem adotar?

Pense em uma metodologia flexível, adaptativa adequada a natureza de cada projeto. Estabeleça processos de entregas, por exemplo, um para novos desenvolvimentos, outro para manutenção evolutiva. Cada processo de entrega define uma raia que orienta o desenvolvedor nas suas atividades.

Não delegue o cumprimento dos processos de entrega para o bom senso. Estabeleça um indicador de conformidade ao processo e defina uma meta a ser atingida a cada nova entrega.

Esse indicador pode ser baseado em artefatos e cada artefato pode ter um peso diferente, por exemplo, um documento de visão do sistema, pode ter um peso maior para um processo de entrega de novo desenvolvimento do que numa manutenção corretiva.

E para garantir que o processo de entrega seja realmente adotado pela organização e necessário o patrocínio da alta gerência, o que irá demonstrar o comprometimento da organização com a metodologia proposta.

Penso que metodologia flexível seja melhor do que nenhuma metodologia. E você o que acha?

É 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!