Uma visão geral sobre qualidade de software - Blog CMMI & MPS.Br
Home > Geral > Uma visão geral sobre qualidade de software
By Autor Externo on May 31, 2009
Todos nós temos conhecimento que o desenvolvimento de projetos de software é uma tarefa árdua e extremamente difícil. Um sistema mal construído pode gerar milhões de reais em prejuízos em poucas horas, dependendo do tamanho do cliente e do porte da operação suplantada. O primeiro registro de "bug" foi em 1945 quando a Oficial Naval Grace Murray Hopper, encontrou uma traça dentro de um dos computadores da marinha americana. O fato de ter encontrado um "bug" (inseto em inglês) dentro de um computador que estava com mau funcionamento por conta dessa ocorrência, permitiu com que o termo se tornasse comum na área de desenvolvimento de software e associado a falhas durante a execução.
Ao longo da história evolutiva do computador e do desenvolvimento de aplicativos, é muito comum totalmente normal encontrarmos situações na qual existiram, existem e ainda irão existir situações de problemas durante a realização de alguma tarefa em um determinado sistema. Mas em muitos desses casos, as conseqüências desses atos foram resultados de tragédias calamitosas que sacrificaram vidas humanas ou até mesmo prejudiciais ao meio ambiente. Um caso interessante, foi à explosão do ônibus espacial Columbia em 1986, quando alguns funcionários da própria NASA que haviam sido demitidos após o fracasso do projeto, declararam para a imprensa que o acidente aconteceu por conta de falhas no software na hora do lançamento, pois não tiveram testes suficientes no software.
Hoje no mercado existem centenas de empresas de tecnologia que atuam impreterivelmente com o desenvolvimento de softwares, e para satisfazer as necessidades do cliente de forma íntegra e válida, utilizam-se da criação de uma área específica para controle e qualidade do software. A área que cuida da qualidade é uma das mais críticas (e criticadas) quanto à análise do sistema e os erros encontrados na aplicação. No geral, os profissionais que atuam nessa área são considerados os "chatos" ou "dedo duros", pois apontam internamente onde estão os erros do projeto, e muitas vezes acabam sendo mal interpretados e colocados em situações constrangedoras onde deixa-se o profissionalismo e acredita-se ser pessoal, mas não faz parte do escopo abordar essa discussão.
A linha de tempo do desenvolvimento de um software, sempre passa por altos e baixos durante as diferentes fases necessárias para sua concepção. Contudo, mesmo as melhores práticas de desenvolvimento de código fonte, metodologias de controle de processo, estrutura de desempenho operacional e entre outras opções, não garantem plenamente que quando o sistema for disponibilizado para homologação no cliente, tudo irá ocorrer como esperado. Deveria. E pode. A questão crucial é que por trás de todo este cenário existe uma equipe formada por profissionais e que deveriam (sim, no passado mesmo) estabelecer suas atividades de forma criteriosa sob as plataformas existentes de processo. De modo geral, essa etapa do projeto é extremamente crítica e altamente estressante, pois nessa situação o relacionamento entre a fornecedora e o cliente será definido para projetos futuros.
Em muitas situações, os membros envolvidos para a área de qualidade são imaginados como sendo profissionais que possuem habilidades sobrenaturais, como "telepatia", "adivinhação" ou "previsão do futuro". Durante as etapas em que os membros da equipe da qualidade são envolvidos, é extremamente importante que todos possuam conhecimento das regras de negócios do projeto e acima de tudo, da solução do cliente que está sendo elaborada para verificar se a mesma é condizente com a realidade do cliente.
Junto à estrutura de testes que avalia especificamente o produto gerado no final, temos também uma área que é exclusiva para processo. Geralmente, essa área é conhecida como PPQA (Process and Product Quality Assurance). Um exemplo bem simples para entender melhor a diferença entre as duas áreas de qualidade envolvidas em um projeto.
Imagine uma receita de bolo. Ela possui vários ingredientes que devem ser utilizados e um modo de preparo a ser executado. Logo, uma pessoa usa e receita com base nos ingredientes informados e nos procedimentos para poder fazer o bolo.
Vejamos agora o que cada área irá conferir:
1) Todos os ingredientes foram utilizados?
2) Os procedimentos foram seguidos conforme informado?
3) O tempo informado para o bolo ficar pronto foi seguido corretamente?
4) O recheio foi feito após o bolo ter ido para o forno?
Testes (não do software, mas do bolo)
1) O bolo possui o sabor estipulado pela receita?
2) O bolo foi feito na assadeira estipulada?
3) A cobertura do bolo é a mesma informada na receita?
OU seja, a área de PPQA avalia se o processo está sendo seguido corretamente, já à área de testes verifica se o bolo saiu conforme o esperado.
Estas áreas trabalham conjuntamente, e são extremamente importantes para manter a estrutura do projeto "dentro dos trilhos". Se ambas as etapas forem seguidas adequadamente, teremos controle das atividades e principalmente estaremos garantindo a qualidade do produto.