Introdução ao Gerenciamento de Qualidade
A qualidade de um software está ligada aos requisitos solicitados pelo cliente e em conformidade as regras de desenvolvimento. Veremos nesse artigo os princípios e práticas do gerenciamento.
A qualidade de um produto hoje tem importância fundamental para disputar a concorrência com as empresas do ramo. A qualidade hoje é um pré-requisito para as empresas que querem estar sempre no mercado de forma ativa. Embora a ideia de qualidade possa parecer um tanto intuitiva e de pouca complexidade, quando estudada com mais atenção, podemos ver que é algo que exige além do que imaginado.
Um software sem qualidade pode ocasionar erros catastróficos e de grande custo de manutenção para as empresas de softwares. A qualidade de hoje é a grande motivadora em todas as áreas, todos querem receber e fornecer produtos com qualidade. Um software de qualidade tem impacto sobre milhares de pessoas, pois ele poderá disponibilizar serviços essenciais, irá gerar competitividade entre empresas e etc.
A qualidade de um software está ligada aos requisitos solicitados pelo cliente e em conformidade as regras de desenvolvimento. Existem inúmeros conceitos que nos auxiliam a manter a qualidade do software. Visando melhorar o entendimento sobre o assunto, esse artigo apresenta o conceito de qualidade de software, tratando a importância dos requisitos.
Princípios da Qualidade de Software
Um dos principais desafios encontrados pelos profissionais é definir o que é qualidade na atualidade. Muitas são as definições de qualidade de software propostas hoje em dia. Qualidade de software pode ser definida como: “Conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todos software profissionalmente desenvolvido.”(PRESMANN, 2007) Ou seja a qualidade de um software se refere não só a padrões de desenvolvimento, mas também garantir que o produto final satisfaça as expectativas do cliente, dentro daquilo que foi requisitado.
Em todas as fases do processo de desenvolvimento de um software acontecem defeitos e imprevistos, eles são causados geralmente por erros lógicos, de interpretação, desconhecimento de técnicas, falta de atenção, de motivação, falta de requisitos detalhados e outros. Sabendo disso podemos afirmar que a garantia de qualidade não é algo que deve ser pensado no fim do projeto, mas sim durante todo o processo de desenvolvimento do projeto ou produto. Essa atividade irá ajudar a remover os defeitos existentes em cada fase. O fato de ser detectado no começo do desenvolvimento traz benefícios para o projeto, pois quanto mais tarde uma falha for corrigida mais cara será sua correção.
A garantia da qualidade no desenvolvimento de um software tem uma série de prevenções que podem ser tomadas para que os problemas que possam por ventura surgir num projeto, sejam mínimos, ou não existam. E existem técnicas/práticas que podem nos auxiliar na missão de manter a qualidade do software. Entre elas estão a utilização das práticas, CMM, CMMI, norma ISO /IEC 9126 e também os testes.
Práticas
CMM
O CMM (Capability Maturity Model) é uma série de práticas que estão organizadas em cinco níveis crescentes de maturidade. Os níveis são:
- Inicial: Nesse nível a organização ainda está instável, os projetos custam mais do que previsto e por mais que o projeto seja concluído ele poderá extrapolar os prazos e custos que foram definidos;
- Repetitivo: Começa a se existir políticas e procedimentos para se desenvolver o software, o desenvolvimento do projeto é acompanhado e os planos são revisados;
- Definido: Os processos que serão utilizados serão padrão em toda a organização;
- Gerenciado: Nesse nível se define as métricas quantitativas para seu projeto, essas medidas são avaliadas e analisadas com frequência;
- Otimização: Neste nível a organização atingiu todas as metas especificas na área de processos dos níveis anteriores. É necessário manter o foco, para continuar a diminuir o retrabalho e custos desnecessários.
CMMI
O CMMI é uma coleção das melhores práticas necessárias, para apoiar o desenvolvimento, serviços aquisições e manutenção de um projeto. O CMMI foi desenvolvido em 1992 pela SEI (Software Engineering Institute), um centro de pesquisas e desenvolvimento que é patrocinado pelo departamento de defesa dos EUA. Possui o foco voltado para a capacidade de maturidade de processos de software, a versão atual possui três modelos:
- CMMI for Developmet, que é voltado ao processo de desenvolvimento de produtos e serviços;
- CMMI for Acquisition, que tem enfoque voltado aos processos de aquisição e terceirização de bens e serviços;
- CMMI for Services, que é voltado aos processos de empresas prestadoras de serviços.
O CMMI possui duas formas de representação, são elas: representação contínua e representação por estágios. A organização que irá decidir qual representação utilizar para o desenvolvimento do seu projeto.
A representação contínua é caracterizada por níveis de capacidade:
- Nível 0 Incompleto: Nesse nível o processo não é realizado, ou ele é implementado, porém um ou mais objetivos da área de processo não é satisfatório;
- Nível 1 Realizado: É necessário que todos os objetivos específicos sejam executados e alcançados;
- Nível 2 Gerenciado: Define-se objetivos e requisitos, o processo é monitorado, revisado e controlado;
- Nível 3 Definido: É definido um processo que será utilizado e ele deve ser melhorado constantemente. Esse processo que foi definido deve ser descrito e executado de maneira mais rigorosa;
- Nível 4 Gerenciado quantitativamente: O processo é definido e controlado quantitativamente, por exemplo, aplicando-se técnicas estatísticas. Esse nível foi removido no CMMI 1.3;
- Nível 5 Em otimização: Foco na melhoria contínua do desempenho, é realizado melhorias tecnológicas. Também removido no CMMI 1.3.
O CMMI proporciona maior confiabilidade no que se refere prazos e custos que são acordados no início do desenvolvimento do sistema. A qualidade dos softwares criados baseados no CMMI é ocasionada por processos bem definidos e controlados e a busca contínua nos processos cotidianos.
O CMMI foi criado para integrar os modelos CMM apresentados nesse artigo, a fim de suprir as limitações desses modelos, com a criação de um método comum, permitindo a representação contínua com áreas de processos independentes dos níveis de maturidade.
ISO /IEC 9126
A norma ISO (Organização Internacional para Normalização) 9126 foi criada para a qualidade de software, que se enquadra no modelo das normas da família ISO 9000, que é composta por uma série de normas internacionais que cuidam da manutenção de um sistema de gestão de qualidade com base nos oito princípios de gestão da qualidade, que são: foco no cliente, liderança, envolvimento das pessoas, abordagem por processos, abordagem sistêmica para a gestão, melhoria contínua, abordagem factual para a tomada de decisão e relações mutuamente benéficas com os fornecedores. Contudo, o detalhamento desses princípios não é o foco desse artigo.
A norma ISO/IEC 9126 estabelece os seguintes componentes:
- O Processo de desenvolvimento afeta a qualidade do software gerado. Além disso, é influenciado pela natureza do produto;
- O Produto, que compreende a qualidade do produto de software, estes por sua vez divididos em internos e externos;
- A qualidade em uso, que compreende na comparação da qualidade do software em cada contexto específico.
Essa norma propõe atributos de qualidade, e são distribuídos em seis características e cada características é dividida em sub características, são elas:
- Funcionalidade – Verifica a capacidade de o software prover as funcionalidades que foram definidas e requisitadas. As sub características são: Adequação, onde mede o quanto as funcionalidades são adequadas às necessidades do usuário. Precisão, é a capacidade de o software fornecer os resultados precisos de acordo com o que foi solicitado. Interoperabilidade, como o software interage com outro sistema. Segurança, a capacidade de o software proteger os dados do sistema.
- Confiabilidade – Verifica se o produto continua no nível de desempenho das condições que foram estabelecidas. As sub-características são: Maturidade, onde se evita que as falhas do software sejam decorrentes de outro software. Tolerância a falhas, o software se mantém funcionando independente dos defeitos que ocorrem nele ou externamente. Recuperabilidade, o software se recupera depois de uma falha e restabelece seus níveis de desempenho.
- Usabilidade – O software é compreendido, o funcionamento aprendido e é atraente para o usuário. Possui quatro sub-características, inteligibilidade onde é avaliado se o usuário compreende as funcionalidades do sistema e avalia se satisfaz as suas necessidades, apreensibilidade identifica a facilidade de aprendizado do sistema para os usuários, operacionalidade verifica a maneira que o produto facilita a operação por parte do usuário, atratividade são as características que podem atrair um potencial usuário.
- Eficiência – Se o tempo de execução e os recursos são compatíveis com o nível de desempenho do sistema. Comportamento em relação ao tempo, avalia se o tempo de resposta estão de acordo com as requisições e Utilização de recursos, identifica tanto os recursos consumidos quanto a capacidade quem o sistema possui para utilizar os recursos. São as sub-características.
- Manutenibilidade – A capacidade que o software tem em ser modificado, melhorado e sua capacidade de inclusão de extensões. As sub-características: Analisibilidade verifica a facilidade de diagnosticar os problemas e as suas causas. Modificabilidade, a capacidade do software em ser alterado. Estabilidade, identifica a capacidade de o sistema evitar efeitos colaterais devidos as modificações.
- Portabilidade – Verifica a capacidade do sistema se transferido de um ambiente para outro. Adaptabilidade, capacidade para ser instalado, coexistência e capacidade para substituir são as sub-características.
Contudo, para que possa existir a melhoria de um software deve ser feito uma definição dos aspectos de qualidade para o projeto que está em foco e antes da projeção dessa qualidade deve ser decidido entre os desenvolvedores do sistema as características que de dentam a qualidade e os termos que vão descrever essas características, já que a norma não apresenta métricas para as seis características da qualidade, deixando a cargo de cada empresa desenvolver suas próprias métricas. Para isso, a empresa deve considerar a classe de aplicação do produto que está desenvolvendo com base na confiabilidade (tendo como missão crítica), o desempenho deve ser menor que o tempo real e a usabilidade deve tomar como base o usuário não especializado para aquele produto.
Embora seja elevado o custo para a utilização de sistemas de gerenciamento de qualidade, é importante que utilizem para que a empresa possa passar por um longo sem precisar de retrabalho, custos fora de escopo e prazos extrapolados e que o software continue com qualidade.
A norma brasileira NBR 13596 foi substituída pela ISO/IEC 9126-1, se tornando NBR ISO/IEC 9126-1.
Testes de software
Os testes de software têm a finalidade de fornecer informações sobre o comportamento do seu software. Mesmo realizando testes é impossível garantir que sua aplicação fique isenta de erros, porém eles lhe dão uma margem de segurança maior. As falhas podem surgir por diversos motivos, à especificação do projeto/atividade pode está incompleta ou errada, deve ser levado em conta também as limitações que o software pode possuir, o tamanho do projeto pode ser extenso e muitas pessoas trabalharem no mesmo, podendo gerar assim inúmeros conflitos no desenvolvimento. Os testes de software identificam apenas as falhas em um produto. Com base nelas é que são tomadas atitudes para resolver os defeitos e erros.
Existem vários tipos de teste, dentre os quais podemos citar: teste de configuração, de instalação, de integridade, de segurança, funcional, de unidade, de integração, de volume, de performance, de usabilidade, de caixa branca e preta (uns dos mais usados), de regressão e de manutenção.
Custos de Qualidade
É utópico conseguir alcançar a perfeição em um software, então é importante definir o nível de qualidade que é suficiente para o seu cliente em questão e quais os custos que estão associados. Todas as atividades no desenvolvimento de um software possui um custo, no controle de qualidade devem ser considerados três elementos: custo da falha, custo da prevenção e custo da avaliação.
O custo de falha está associado aos defeitos entregue ao cliente, eles são divididos em falhas internas que inclui: retrabalho, análise de falhas e consertos de bugs e falhas externas que inclui: resolução de queixas, devolução do produto, suporte e trabalhos de segurança.
Custo de prevenção pode ser considerado um investimento para que seja evitado erros na tentativa de realizar o trabalho certo de primeira vez. É um custo que acontece antes da criação do produto. É criado treinamento, realizado definição de métodos e procedimentos, planejamento da qualidade, testes de equipamentos e revisões técnicas formais.
No custo de avaliação nos referimos a todos os gastos em procedimentos de verificação e em testes para a identificação dos erros do software após sua construção e antes que seja disponibilizado para uso. Podemos incluir nele manutenção dos equipamentos, tempo gasto na automação e inspeções.
Controle de Qualidade
O controle de qualidade envolve uma série de inspeções, revisões e teste com os propósitos de assegurar que todos os procedimentos e padrões sejam seguidos. Controle de qualidade referente a softwares procura identificar inconformidades dentro dos requisitos dados pelos usuários.
O processo de qualidade tem seus próprios procedimentos a serem seguidos no desenvolvimento de um software, estes procedimentos devem ser fáceis de compreensão pelos engenheiros que estão desenvolvendo. Existem duas abordagens para o controle de qualidade, são elas: revisões de qualidade e avaliação automática de software.
Nas revisões de qualidade, a documentação e os processos utilizados são revisados por um grupo de pessoas, responsável por conferir se os padrões dos projetos foram seguidos e se a documentação está em conformidade com os padrões. O que não estiver conforme os padrões, são anotados e submetidos à atenção da gerência do projeto. Já a Avaliação automática de software envolve medição quantitativa de alguns atributos de software.
O foco do controle de qualidade é nas revisões e remoção dos erros antes mesmo da entrega final do produto. Um exemplo clássico de controle de qualidade são as inspeções de software feitas com base em critérios de entrada e saída bem definidos.
Revisões de Qualidade
O método de revisão envolve um grupo de pessoas que verificam parte ou todo o processo de desenvolvimento, com o objetivo de descobrir possíveis problemas. As conclusões da revisão são registradas formalmente e transferidas para o autor ou responsável sobre os problemas verificados. Existem três tipos de revisão:
- Tipo 1 – Inspeções de projeto, onde é detectado os erros detalhados nos requisitos, nos projetos ou no código. É orientada por um checklist de erros;
- Tipo 2 – Revisão de progresso informa à gerência sobre o processo geral, se preocupa com os custos, planos e prazos;
- Tipo 3 – Revisões de qualidade, é realizada uma análise técnica da documentação do produto, com finalidade de encontrar inconsistências entre as especificações e o projeto, código ou documentação.
O objetivo da equipe de revisões é detectar erros e mostrá-los ao projetista do documento. Elas são baseadas em documentos, porém não se limitam as especificações, projeto ou código.
O benefício das revisões técnicas é a descoberta precoce dos defeitos de software, desta forma os defeitos podem ser corrigidos antes do próximo passo. As técnicas de revisão têm se mostrado até 75% efetivas na descoberta de falhas. No momento que é detectado o erro, o processo de revisão reduz os custos dos próximos passos na fase de desenvolvimento e na manutenção.
Saiu na DevMedia!
- Teste unitário: Descubra erros no código antes que ele falhe!:
O teste unitário é uma metodologia que procura aferir a corretude do código, em sua menor fração. - SQL nível Jedi: Subqueries:
Grande parte dos desenvolvedores recorrem somente ao JOIN para resolver consultas que envolvem múltiplas tabelas. Hoje falaremos sobre uma outra ferramenta para isso que pode resolver cenários em que o JOIN não atenda, as subqueries.
Saiba mais sobre Gerência de Projeto ;)
- MVC e Regras de negócio:
Em uma arquitetura MVC, temos três camadas com diferentes responsabilidades. Em qual destas camadas deveria estar a regra de negócio da aplicação? Saiba isso e muito mais nesta série. - Gestão de Projeto:
Neste guia você encontrará o conteúdo que precisa para saber como gerenciar projetos de software. Confira abaixo a sequência de posts que te guiarão do básico ao avançado em Gestão de Projetos.
- SOMMERVILLE, I an. Engenharia de Software; tradução André Maurício de Andrade Ribeiro; revisão técnica Kechi Hirama - São Paulo: Pearson Addison Wesley, 2003.
- PRESSMAN, Roger S. Engenharia de software; tradução José Carlos Barbosa dos Santos; revisão técnica José Carlos Maldonado, Paulo Cesar Masieiro, Rosley Sanches. – São Paulo: Makron Books,1995.
- PAULA FILHO, Wilson de Pádua. Engenharia de software: fundamentos, métodos e padrões. - 3.ed. – Rio de Janeiro: LTC,2009. – Rio de Janeiro: LTC,2009.
Artigos relacionados
-
Artigo
-
Vídeo
-
Vídeo
-
DevCast
-
DevCast