Qualidade de Software Ltda

Em 29 abril de 2010 tive a oportunidade de participar do seminário Fábricas de Software, organizado peal Recriando Educação & Estratégia em parceria com a Sucesu-SP Sociedade de Usuários de Informática e Telecomunicações – São Paulo.  Esse seminário foi organizado em quatro palestras, conforme descrito abaixo. Compartilho aqui um breve resumo que capturei de cada palestra:

 
Imagem disponível em http://www.recriandoonline.com.br/fsoft/

1. Cenários e Tendências para as Fábricas de Software: Uma Visão das Principais Mudanças de Paradigma que estão Ocorrendo. Palestrante: Aguinaldo Aragon Fernandes

Na abertura o palestrante destacou a importância do uso de controles para uma Fábrica de Software traçando um paralelo com a indústria automobilística. Em seguida comentou sobre qual seria o real valor das certificações como o CMMI, ressaltando os desafios que a cultura brasileira impõe na adoção desses modelos, e como as empresas que possuem essas certificações pouco se beneficiam delas. Comentou-se sobre a queda atual na procura por esse tipo de certificação.

Leia mais …

As primeiras ferramentas de testes de software surgiram por volta de 1980 e eram focadas em testes funcionais. Eram também baseadas em atividades que eram extensão de debuging do software.

Após essas ferramentas ganharem popularidade, surgiram as ferramentas de gerenciamento de testes que tinham como propósito organizar e manter dados e comandos de testes, organizarem o resultado da execução dos testes, e apresentar relatórios de testes.

Por volta de 1990 os fornecedores passaram a integrar numa suite única ferramentas para testes funcionais e de gerenciamento de testes. Já em 1995 surgiram as primeiras ferramentas para automação de testes de performance que inicialmente eram focadas em medições básicas para algumas plataformas. Posteriormente foram abrangendo diversas plataformas com medições mais complexas de performance.

Leia mais …

Para os estudandes, praticantes e demais interessados no tema “Teste de Software”, aqui vai relação de livros e sites para consultas:

Bibliográficas

Paton, Ron. Software Testing. Sams Publishing. 2005.

H. Kan, Stephen. Metrics and Models in Software Quality Engineering. Second Edition. Addison Wesley. 2002

D. Everett, Gerald. McLeod Jr, Raymond. Software Testing Testing Across the Entire Software Development Life Cycle. IEEE Press. 2007

Eduardo Delamaro, Marcio. Carlos Maldonado, José. Jino, Mario. Introdução ao Teste de Software. Campus. 2007.

A. Menascé, Daniel. A.F.Almeida, Virgilio. Planejamento de Capacidade para Serviços na Web. Campus. 2003.

U.Smith, Connie. G. Williams, Lloyd. Performance Solutions A Practical Guide to Creating Responsive, Scalable Software. Addison-Wesley. 2002

Leia mais …

É sabido que programas de certificação como o CMMI e o seu primo brasileiro MPS.BR tem colocado os olofotes sobre os processos de desenvolvimento. Muitas empresas denvolvedoras de software fizeram o seu trabalho de casa no que tange a definir, documentar, e divulgar seu processo de desenvolvimento. Feito isso o próximo passo e obter um nível de certificação. Obtida a certificação (nível 2, ou nível 3 ou…) aí e só alegria! Almoços de comemoração e muita publicidade, afinal de contas deu um bocado dc trabalho para conseguir a certificação. Mas e a qualidade do produto de software?

Bem, este é o ponto. Certificação do processo, não significa certificação do produto! É aí que mora o perigo! Deitado em berço esplêndido de uma certificação muitas empresas se esquecem da qualidade do produto.

Para garantir que um processo certificado produza um produto de software de qualidade será necessário uma boa equipe de qualidade assegurada, que não só execute checklists, mas faça inspeções em cada etapa do processo de desenvolvimento para se verificar a conformidade entre o que foi especificado e o que foi construído. Um produto de software pode ser produzido e até funcionar e mesmo assim não estar em conformidade com a especificação. Por exemplo, a especificação descreve uma arquitetura lógica de três camadas e o programador implementa em uma camada única. A especificacao descreve um determinado método de acesso e o programador implementa um método diferente, e assim vai sendo comprometida a qualidade do produto mesmo de uma empresa certificada.

E você o que pensa sobre a qualidade do produto de empresas certificadas? Dá para confiar cegamente?

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?