|
O que é Qualidade de Software?
O que um determinado produto apresenta para considerarmos que o mesmo tem qualidade?
Ex.: Carro
Conceito relativo.
Diversos aspectos são levados em conta.
Automóvel: Conforto, segurança, desempenho, beleza e custo.
A qualidade está fortemente relacionada à conformidade com os requisitos.
O que é “conformidade em relação a requisitos”?
Observado x Especificado
Pode haver problemas na Observação.
Pode haver problemas na Especificação.
Qualidade diz respeito à satisfação do cliente.
Requisitos são especificados por pessoas e com o objetivo de satisfazer outras pessoas.
Uma especificação depende das escolhas feitas (clientes alvo).
Pode haver problemas na especificação.
Requisitos são então a fundação a partir da qual a qualidade é medida.
Falta de conformidade com os requisitos é falta de qualidade
Normas especificadas definem um conjunto de critérios de desenvolvimento.
Se os critérios não são seguidos, faltará qualidade.
Há um conjunto de requisitos implícitos não mencionados.
Se o software satisfaz seus requisitos explícitos mas deixa de satisfazer seus requisitos implícitos, faltará qualidade.
HISTÓRICO
2.000 AC no Egito.
Marco: Revolução Industrial
1920: Controle Estatístico da Produção
1940: Surgimento de vários organismos ligados à qualidade
ASQC (American Society for Quality Control)
ABNT (Associação Brasileira de Normas Técnicas)
ISO (International Standardization Organization)
1940: Japão destaca-se.
1970: termo “Qualidade de Software”
Conferência da NATO (1968) –Crise de Software
- Problemas detectados:
- Cronogramas não observados.
- Projetos abandonados.
- Módulos que não operam corretamente quando combinados.
- Programas que não fazem exatamente o que era esperado.
- Sistemas tão difíceis de usar que são descartados.
- Sistemas que simplesmente param de funcionar.
Passados quase 40 anos, o que mudou?
O aspecto não repetitivo do desenvolvimento de software torna essa atividade difícil e em boa medida imprevisível.
- Delimitar o escopo de um sistema nãoé trivial.
- A volatilidade dos requisitosé lugar comum no desenvolvimento de software.
Necessidades do cliente nem sempre refletem as suas necessidades reais:
- Usuário não conhece suas necessidades.
- Essas necessidades podem mudar com o tempo
- Usuários diferentes podem ter ambientes operacionais diferentes
- Pode ser impossível consultar todos os usuários de um determinado sistema.
Fatores que afetam o desenvolvimento e que influenciam no julgamento dos usuários:
- Tamanho e complexidade do software;
- Número de pessoas envolvidas no projeto;
- Métodos, técnicas e ferramentas utilizadas;
- Custo x benefício do sistema;
- Custos associados à existência de erros;
- Custos associados à detecção e remoção de erros;
- Etc.
ISO 9126
Histórico do Controle da Qualidade
Anos 50
CQS visto simplesmente como verificação de que o produto já estava terminado.
Anos 60
Conceito expandido para conter a atividade de Teste.
Anos 70
Inclui verificação do cumprimento de normas definidas para as várias atividades.
Atualmente
CQS visto como atividade de todo o ciclo de vida (como entrada para todas as fases de desenvolvimento).
Qualidade de Produto
Planejamento da qualidade.
Controle da qualidade.
Qualidade de Processo.
Definição, avaliação e melhoria de processos de software adequados ao produto.
Características de Qualidade
- Validar a completude de uma especificação de requisitos.
- Identificar requisitos de software.
- Identificar objetivos do projeto de software.
- Identificar objetivos dos testes de software.
- Identificar critérios de garantia de qualidade de software.
- Identificar critérios de aceitação para um produto final de software.
1977: Proposta de McCall.
1991: ISO define a ISO 9126 (NBR 13596).
1997: ISO define a ISO 12119 (NBR 12119).
2001: Nova versão da ISO 9126.
Características de McCall
Para cada uma das características pode-se definir um conjunto de métricas.
- Muitas serão medidas de forma subjetiva.
- As métricas podem estar na forma de um checklist.
Normas de Qualidade de Produto
- Avaliação da qualidade de produtos de software ao longo do desenvolvimento
- Norma ISO/IEC 9126 (NBR 13596).
- Avaliação da qualidade de pacotes de software
- Norma ISO/IEC 12119 (NBR ISO/IEC 12119).
ISO/IEC 9126
Software Product Evaluation -Quality Characteristics and Guidelines for their use.
Tem como objetivo definir as características de qualidade desejáveis para um produto de software.
Estas características provêem uma linha base para posteriores refinamentos.
ISO 9126 (2001)
Inclusão de novas características.
Define métricas para as características de qualidade.
Divide-se em:
- 9126-1: modelo de qualidade;
- 9126-2: métricas externas;
- 9126-3: métricas internas;
- 9126-4: métricas para qualidade no uso.
A qualidade é avaliada de acordo com 3 perspectivas:
- Qualidade interna–tipicamente medidas estáticas de produtos intermediários.
- Qualidadeexterna–tipicamente medida a partir do produto quando executado.
- Qualidade em uso–medida durante o uso do produto final.
- A qualidade do processo contribui para a melhoria da qualidade do produto (interna e externa).
Qualidade de Produto e Ciclo de Vida
- Inicialmente estabelecidos sob o ponto de vista do usuário.
- Difere da qualidade dos produtos intermediários, vistos sob o ponto de vista da organização.
- Na medida que caminhamos no ciclo de vida, estabelecemos novas características de qualidade.
Qualidade Interna
Conjunto de características do produto de software que avaliam o produto segundo uma visão interna.
Usados para definir estratégias de desenvolvimento e critérios para avaliação e verificação durante todo o desenvolvimento.
Qualidade Externa
Conjunto de características do produto de software que avaliam o produto segundo uma visão externa.
Qualidade quando o software é executado.
Avaliado através de testes em ambientes simulados.
Funcionalidade: Adequação, Acurácia, Interoperabilidade, Segurança, Conformidade de funcionalidade.
Confiabilidade: Maturidade, Tolerância a falhas, Recuperabildiade, Conformidade de confiabilidadeQualidade.
Usabilidade: Inteligibilidade, Apreensibilidade, Operacionalidade, Atratividade, Conformidade de usabilidade.
Eficiência: Comportamento em relação, ao tempo, Comportamento em relação a recursos, Conformidade de eficiência.
Manutenibilidade: Analisabilidade, Modificabilidade, Estabilidade, Testabilidade, Conformidade de manutenibilidade.
Portabilidade: Adaptabildade, Capacidade para ser instalado, Capacidade para substituir, Co-existência, Conformidade de portabilidade.
Qualidade Interna e Externa
Adequação: presença das funções especificadas.
Acurácia: o produto gera resultados precisos ou dentro do esperado.
Interoperabilidade-capacidade de interagir e interoperar com outros sistemas, de acordo com o especificado.
Ex: Importação de dados.
Segurança-capacidade para prevenir o acesso não autorizado.
Conformidade-observância padrões, convenções ou regras estabelecidas.
Maturidade: baixa presença de falhas.
Ex: Sistema exaustivamente testado e corrigido.
Tolerância a falhas: capacidade do produto para manter determinados níveis de desempenho mesmo na presença de problemas.
Inteligibilidade: medida da facilidade do usuário para reconhecer a lógica de funcionamento do produto e sua aplicação.
Apreensibilidade: medida da facilidade encontrada pelo usuário para aprender a utilizar o produto.
Operacionalidade: medida da facilidade para operar o produto.
Atratividade: capacidade de atrair um potencial usuário para o sistema.: capacidade do produto para re-estabelecer o nível de desempenho desejado e recuperar dados em caso de ocorrência de falha.
Inteligibilidade: medida da facilidade do usuário para reconhecer a lógica de funcionamento do produto e sua aplicação.
Apreensibilidade: medida da facilidade encontrada pelo usuário para aprender a utilizar o produto.
Operacionalidade: medida da facilidade para operar o produto.
Atratividade: capacidade de atrair um potencial usuário para o sistema.
Comportamento em relação ao tempo-medida do tempo de resposta e de processamento, assim como as taxas de processamento (throughput), ao executar a funções prescritas.
Comportamento em relação aos recursos-medida da quantidade de recursos necessários (CPU, disco e memória, dentre outros) e a duração do seu uso ao executar as funções.
Analisabilidade: medida do esforço necessário para diagnosticar deficiências ou causas de falhas, ou localizar as partes a serem modificadas para corrigir os problemas.
Modificabilidade: medida do esforço necessário para realizar alterações, remover falhas ou para adequar o produto a eventuais mudanças de ambiente operacional.
Estabilidade-medida do risco de efeitos inesperados provenientes de modificações.
Testabilidade: medida do esforço necessário para testar o software alterado.
Adaptabilidade: medida da facilidade de se adaptar o produto para funcionar em outros ambientes operacionais diferentes do originalmente especificado.
Capacidade para ser Instalado: medida do esforço necessário para se instalar o produto.
Capacidade para substituir: medida do esforço necessário para usar o produto em substituição a outro produto, previamente especificado.
Co-existência: mede o quão facilmente o software convive com outros instalados no mesmo ambiente.
Qualidade em Uso
- Visão do usuário sobre a qualidade do produto.
- Avalia se o produto alcança seus objetivos em um ambiente específico de uso.
- Avalia a qualidade do software em cenários de tarefas do usuário especificados.
- É medida em relação ao resultado da utilização do software e não em relação a características do produto.
- Efeito combinado da qualidade externa e interna.
- Qualidade em Uso.
Efetividade: Capacidade do produto de software possibilitar ao usuário alcançar seus objetivos com correção e completude no contexto de uso especificado.
Produtividade: Capacidade do produto de software possibilitar ao usuário gastar quantidade de recursos adequados em relação a efetividade alcançada.
Segurança: Capacidade do produto de software alcançar níveis aceitáveis de risco de prejuízo a pessoas, negócios, software ou ao ambiente em um contexto de uso especificado.
Satisfação: Capacidade do produto de software satisfazer os usuários em um contexto de uso.
Garantia da Qualidade, Verificação e Validação
Qualidade de Software:
- Produtos precisam respeitar um conjunto mínimo de requisitos.
- Conformidade com especificações e padrões de desenvolvimento documentados.
- Atendimento das necessidades dos usuários.
- Que necessidades? Que usuários?
Garantia de Qualidade do Software:
Mecanismo planejado e sistemático para assegurar que padrões definidos, práticas, procedimentos e métodos do processo são efetivamente utilizados.
Conjunto de atividades técnicas aplicadas durante todo o processo de desenvolvimento.
O objetivo é garantir que tanto o processo de desenvolvimento quanto o produto de software atinjam níveis de qualidade especificados.
A Garantia da Qualidade envolve:
Avaliar a conformidade dos processos e dos produtos.
Registrar e monitorar os problemas encontrados.
Relatar os resultados destas atividades à alta gerência.
Apoiar no seguimento ao processo e aos padrões de qualidade da organização.
Identificar tendências de qualidade nos processos e nos produtos.
Verificação X Validação
Verificação
É o processo de se avaliar um software ou produto de trabalho relacionado a cada fase para determinar se o produto dessa fase satisfaz ao que foi requerido no início da fase
Os artefatos construídos devem estar de acordo com a especificação do software.
Estamos desenvolvendo o produto corretamente?
Validação
É o processo de se avaliar um software ou produto de trabalho relacionado, durante ou após o desenvolvimento, para determinar se o produto satisfaz aos requisitos.
O software deve atender às necessidades dos usuários.
Estamos desenvolvendo o produto correto?
Validação
Principais Métodos para Validação e Verificação:
- Análise Estática:
- Revisões de Software.
- Análise Dinâmica:
- Testes de Software.
Análise Estática
Não envolve a execução do produto
Visa determinar propriedades do produto válidas para qualquer execução do produto final
Exemplos:
Análise de modelos (model checking)
Análise de segurança (safety analysis)
Revisões técnicas
Prova de correção
Análise Estática
Ferramentas que varrem o código fonte à procura de falhas e anomalias
São um complemento muito útil para a inspeção
Tipos de checagem:
- Falhas de dados
- Falhas de controle
- Falhas de E/S
- Falhas de interface
- Falhas de armazenamento
Falha de dados
- Como são usadas as variáveis do programa?
- Variáveis usadas antes de serem inicializadas
- Variáveis declaradas mas que nunca são utilizadas
- Variáveis definidas duas vezes mas não utilizadas nenhuma vez entre as duas definições
- Possibilidade de índice fora de limites para arrays
- Variáveis não declaradas
Falhas de controle
- Trechos de código não alcançáveis
- Desvio para interior de laços
- Falhas de entradas/saída:
- Variáveis são usadas em comandos de saída duas vezes sem que seu valor seja alterado entre uma e outra
Falhas de interface
- Uso de rotinas é consistente com sua declaração?
- Tipos de parâmetros incompatíveis
- Número de parâmetros incompatível
- Valor de retorno de funções não é utilizado
- Funções ou procedimentos não são chamados
- Falhas de armazenamento
- Apontadores não inicializados
- Aritmética de apontadores
Análise Dinâmica
- Envolve a execução do produto (código ou modelo executável)
- Visa encontrar falhas ou erros no produto
Exemplos:
- Simulação
- Execução simbólica
- Testes
Benefícios:
Resultados de estudos experimentais evidenciam benefícios da utilização destes métodos no desenvolvimento de software.
A utilização destes métodos na indústria têm mostrado resultados positivos considerando tanto produtividade quanto qualidade.
Defeito ==>Erro ==>Falha
Defeito: Deficiência mecânica ou algorítmica que se ativada pode levar a uma falha.
Erro: Item de informação ou estado de execução inconsistente.
Falha: Evento notável onde o sistema viola suas especificações.
A maior parte é de origem humana.
- São gerados na comunicação e na transformação de informações.
- Permanecem presentes nos diversos produtos de software produzidos e liberados.
- A maioria encontra-se em partes do produto de software raramente utilizadas e/ou executadas.
Principal causa:
Tradução incorreta de informações.
Quanto antes a presença do defeito for revelada, menor o custo de correção do defeito e maior a probabilidade de corrigi-lo corretamente.
Solução:
Introduzir atividades de VV&T ao longo de todo o ciclo de desenvolvimento.
Revisões de Software
Processo ou atividade para leitura de um artefato de software visando assegurar que ele cumpre sua especificação e atende às necessidades de seus usuários.
Objetivo:
Realizar validação e verificação estática de artefatos de software.
Pode ser aplicada a qualquer artefato produzido ao longo do processo de desenvolvimento de software.
Revisões por pares (peer-reviews) aumentam a probabilidade de defeitos serem encontrados.
Comumente utilizam:
Anônimidade;
Relacionamentos pessoais não afetam a revisão.
Independência dos revisores em relação ao artefato a ser revisado.
Permite uma avaliação objetiva sem conflitos de interesse.
Quando e em que tipos de artefato aplicar revisões de software?
Muitas organizações realizam revisões de software.
Realização pouco sistematizada e potencial raramente é explorado.
Tipos de Revisão de Software:
4.1 – Inspeções de Software.
4.2 – Walkthroughs.
Inspeções
Tipo particular de revisão.
- Tem sido o tipo de revisão de software mais estudado e utilizado
- Processo rigoroso e bem definido.
- Evidências Experimentais:
- Redução do Esforço
- Aumento da Produtividade
- Redução do Tempo
- Redução dos Custos
- Capturam em média 60% dos defeitos
Walkthrough
Alternativa com um processo menos rigoroso do que o de inspeções de software.
Papéis sugeridos:
Líder, Autor, Escrivão e Revisores
Procedimento:
Os participantes são guiados através dos artefatos pelo líder (que eventualmente é o próprio autor) em uma reunião. Durante esta reunião devem interromper a apresentação caso encontrem defeitos.
Muitas vezes condições de entrada e saída e decisões são pressupostos pelo líder que segue sua linha de raciocínio durante a apresentação.
Possuem custo aproximadamente igual ao de inspeções mas seus resultados são inferiores:
- Não providenciam resultados mensuráveis;
- Não fornecem base para a aplicação de controle estatístico de processos, necessário para evoluir na maturidade
de processos de software.
- Podem ser utilizados para atividades de brainstorming, para explorar alternativas de projeto e resolução de
problemas.
- Inspeções são mais focadas em encontrar defeitos.
Modelos de Maturidade
Produto X Processo
Qualidade do produto não se atinge de forma espontânea.
A qualidade do produto depende fortemente da qualidade do processo de desenvolvimento daquele produto.
Um bom processo não garante que os produtos produzidos são de boa qualidade, mas é um indicativo de que a organização é capaz de produzir bons produtos.
CMMI (Capability Maturity Model Integration)
É um modelo que descreve orientações para a definição e implantação de processos.
O modelo não descreve processo algum, são orientações definidas através das práticas especificadas.
Método de avaliação utilizado: SCAMPI
SCAMPI (Standard CMMI Assessment Method for Process Improvement)
É definido em termos de áreas de Processo (PAs):
Ex: Planejamento de Projeto, Monitoração e Controle de Projetos, etc.
Cada área de processos (PA) é definida em termos de Objetivos Específicos (SGs) e Práticas Específicas (SPs)
que são necessárias para satisfazê-los.
Pode ser implementado em duas representações:
- Contínua (níveis de 0 à 5)
- Estagiada (nível de 1 à 5)
- Estagiada pode-se atribuir nível para a organização como um todo ==> Marketing!
CMMI (Exemplo)
Planejamento do Projeto
- OE 1 Estabelecer Estimativas
- PE 1.1 Estime o escopo do projeto
- PE 1.2 Estabeleça estimativas de produto do trabalho e atributos de tarefas
- PE 1.3 Defina o ciclo de vida do projeto
- PE 1.4 Determine estimativas de esforço e custo
- OE 2 Desenvolver um Plano do Projeto
- PE 2.1 Estabeleça o orçamento e o cronograma
- PE 2.2 Identifique os riscos de projeto
- PE 2.3 Planeje a gestão de dados
- PE 2.4 Planeje a gestão de recursos
MPS.BR
Objetivo: Melhoria de processos de software nas micros, pequenas e médias empresas (PMEs), a um custo acessível, em diversos locais do país.
Como?
Desenvolvimento (e Aprimoramento) do Modelo MPS.BR.
Implementação e Avaliação do Modelo MPS.BR em Empresas, com foco em grupos de empresas
CMMI X MPS.BR
7 níveis de maturidade, o que possibilita uma implantação mais gradual e uma maior visibilidade dos resultados de melhoria de processo, com prazos mais curtos.
Compatibilidade com CMMI, conformidade com as normas ISO/IEC 15504 e 12207.
Adaptado para a realidade brasileira (foco em micro, pequenas e médias empresas).
Custo acessível (em R$)
MPS.BR
Nível de Maturidade: Grau de melhoria de processo para um pré-determinado conjunto de processos no qual todos os objetivos dentro do conjunto são atendidos.
7 Níveis:
A. Em Otimização
B. Gerenciado Quantitativamente
C. Definido
D. Largamente Definido
E. Parcialmente Definido
F. Gerenciado
G. Parcialmente Gerenciado
Estrutura
Cada processo é composto de um propósito e de resultados esperados de sua execução, o que permite avaliar e atribuir graus de efetividade na execução do processo.
A capacidade do processo está relacionada ao atendimento dos atributos de processo associados aos processos de cada nível de maturidade.