Slides 3 Gerenciamento De Qualidade

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Gerenciamento de Qualidade
1
Problemas com a qualidade de software foram inicialmente descobertos na década de 1960 com o desenvolvimento do primeiro grande sistema.
O software entregue era
 lento e pouco confiável,
difícil de manter,
difícil de reusar.
Principais preocupações no gerenciamento de qualidade
Estabelecer um framework de processos e padrões que levem a software de alta qualidade.
Os processos planejados foram seguidos, e a garantia de que as saídas de projeto estejam em conformidade com os padrões aplicáveis.
Estabelecimento de um plano de qualidade. O plano de qualidade deve definir as metas de qualidade para o projeto e quais processos e padrões devem ser usados.
O gerenciamento de qualidade de software para sistemas de software cobre três principais preocupações:
1. No nível organizacional, o gerenciamento de qualidade está preocupado com o estabelecimento de um framework de processos organizacionais e padrões que levem a software de alta qualidade. Isso significa que a equipe de gerenciamento de qualidade deve assumir a responsabilidade de definir os processos de desenvolvimento do software que serão usados e os padrões que devem ser usados no software, bem como a documentação relacionada, incluindo os requisitos de sistema, projeto e código.
2. No nível de projeto, o gerenciamento de qualidade envolve a aplicação de processos específicos de qualidade, certificando-se que os processos planejados foram seguidos, e a garantia de que as saídas de projeto estejam em conformidade com os padrões aplicáveis.
3. No nível de projeto, o gerenciamento de qualidade também está preocupado com o estabelecimento de um plano de qualidade. O plano de qualidade deve definir as metas de qualidade para o projeto e quais processos e padrões devem ser usados.
3
Garantia de qualidade e controle de qualidade
A garantia de qualidade (QA, do inglês quality assurance) é a definição de processos e padrões que devem conduzir a produtos de alta qualidade e a introdução de processos de qualidade na fabricação.
O controle de qualidade é a aplicação desses processos de qualidade visando eliminar os produtos que não atingiram o nível de qualidade exigido.
Na indústria de software, diferentes empresas e setores industriais interpretam a garantia de qualidade e controle de qualidade de maneiras diferentes. Às vezes, garantia de qualidade significa simplesmente a definição de procedimentos, processos e padrões que visam reforçar que a qualidade de software seja atingida. Em outros casos, a garantia de qualidade também inclui todo o gerenciamento de configuração, atividades de verificação e validação aplicadas após o produto ter sido entregue por uma equipe de desenvolvimento. Neste capitulo, utilizo o termo 'garantia de qualidade' para incluir a verificação e validação e os processos de verificação se os procedimentos de qualidade foram aplicados corretamente. O termo 'controle de qualidade’ foi evitado, pois não é amplamente usado na indústria de software.
4
Qualidade de software
Os fundamentos do gerenciamento de qualidade foram estabelecidos pela indústria manufatureira em um esforço para melhorar a qualidade dos produtos em produção.
Conformidade com uma especificação detalhada e na noção de tolerâncias.
Produtos poderiam ser completamente especificados e avaliados se fabricados de acordo com a especificação.
Produtos nunca cumprirão todas as especificações, então se admitiu alguma tolerância.
Produto 'quase certo’ é classificado como aceitável.
Qualidade de software
Não e diretamente comparável a qualidade na manufatura.
A ideia de tolerâncias não é aplicável aos sistemas digitais.
Difícil concluir objetivamente se um sistema de software cumpre ou não suas especificações:
Difícil escrever especificações de software completas e precisas.
Clientes e desenvolvedores de software podem interpretar os requisitos de maneiras diferentes.
Especificações integram requisitos de várias classes de stakeholders.
Impossível medir determinadas características de qualidade diretamente.
A qualidade de software não e diretamente comparável a qualidade na manufatura. A ideia de tolerâncias não é aplicável aos sistemas digitais e, pelas razoes apresentadas a seguir, pode ser impossível concluir objetivamente se um sistema de software cumpre ou não suas especificações:
1. Conforme discutido no Capitulo 4, no qual abordo a engenharia de requisitos, e difícil escrever especificações de software completas e precisas. Os clientes e desenvolvedores de software podem interpretar os requisitos de maneiras diferentes e pode ser impossível chegar a um acordo sobre se o software cumpre ou não suas especificações.
2. Geralmente, as especificações integram requisitos de várias classes de stakeholders (partes interessadas). Esses requisitos são, inevitavelmente, um compromisso e podem não incluir os requisitos de todos os grupos de stakeholders. Os stakeholders excluídos podem perceber o sistema como um sistema de baixa qualidade, mesmo que este implemente os requisitos acordados.
3. E impossível medir determinadas características de qualidade diretamente (por exemplo, manutenibilidade), assim, elas não podem ser especificadas de forma não ambígua. As dificuldades de medição são discutidas na Seção 24.4.
6
Qualidades de Software
Externas
Visível ao usuário
Internas
de importância para os desenvolvedores
do Produto
do Processo
Podemos classificar qualidade em externa vs. interna e do produto vs. do processo. Qualidade externa é aquela visível ao usuário. Interna é de importância para os desenvolvedores.
Exemplos: Confiabilidade é uma qualidade externa. Verificabilidade é interna.
Processo: Produção do Produto.
Algumas qualidades são atribuídas ao processo mas são frequentemente relacionadas também com o produto. Ex.: Planejamento cuidadoso de dados de teste antes do projeto aumenta confiabilidade do produto.
Eficiência é qualidade do produto e também do processo.
Produto: Não só o que o usuário recebe (Código e manual) mas Requisitos, código fonte, massa de testes, tudo que é produzido no processo. 
7
Qualidades Externas
Correção
Um programa é correto se se comporta de acordo com a especificação de sua função.
Confiabilidade
Um software é confiável se o usuário pode depender dele.
Robustez
Um programa é robusto se se comporta de forma “razoável” frente ao inesperado.
Às vezes os termos correção, confiabilidade e robustez são confundidos. tentamos apresentar a diferença.
Para que um programa seja correto é necessário que haja uma especificação e seja possível de forma não ambígua dizer que ele está de acordo com a especificação. Muitas vezes a especificação não existe ou foi feita de forma informal. Aí é difícil dizer que o programa está correto. Correção é uma propriedade matemática que estabelece a equivalência entre o software e sua especificação.
Produtos não confiáveis desaparecem rapidamente do mercado. Às vezes programas são liberados (released) junto com uma lista de “Bugs” conhecidos.
Versão 1 é sempre com problemas. Sinal de imaturidade da área. Compare com um prédio ou com carros. Você tem coragem de viajar na versão 1 de um avião?
Em vez de ficarmos surpresos ao achar erro em um programa a gente os espera.
8
Desempenho
Rapidez, uso de recursos como espaço em disco e memória.
Facilidade de Uso
Fácil de usar tanto por um novato quanto por um usuário experiente.
Possibilidade de Evolução
Facilidade de incorporar novas funções.
Qualidades Externas
Qualidades Internas
Verificabilidade
Manutenibilidade
Corrigibilidade
Reuso
Portabilidade
Legibilidade
Interoperabilidade
As propriedades do sistema devem ser possíveis de se verificar de forma fácil. Análise formal ou testes. Modularidade, codificação disciplinada, uso da linguagem apropriada facilitam a verificação.
Manutenção é o que geralmente consome mais tempo e normalmente para corrigir erros devido a falhas de especificação (erros e omissões.) Manutenção pode ser corretiva, adaptiva (mudança
no ambiente) ou para melhorar as qualidades. Manutenção pode ser corretiva ou de evolução.
Corrigibilidade é a facilidade de se corrigir defeitos com pouco esforço. Afetada pelo número de partes do produto. Necessidade de correção decresce com o aumento de confiabilidade.
 Reuso nos leva a facilidade de se produzir novos produtos onde algumas partes já foram desenvolvidas. Redução do custo de produção.
Portabilidade: Utilização do software em várias plataformas.
Interoperabilidade: Facilidade de coexistir com outros sistemas. Melhor exemplo: MICROSOFT Office.
10
Qualidades do Processo
Produtividade
Pontualidade - “Timeliness”
Visibilidade - “Glasnost”
Função
Tempo
Necessidades
Capacidades
do
Sistema
Produtividade é a eficiência do processo de produção de software. Modernas ferramentas de desenvolvimento e linguagens. Reuso está intimamente ligado com produtividade.
Timelines: qualidade referente a possibilidade de entregar o produto no tempo previsto. Normalmente as necessidades do usuário estão atrás do software. Para evitar grandes atrasos a distribuição incremental é feita. Requer determinação precisa de datas, estimativa acurada de trabalho. Existem ferramentas automatizadas de gerenciamento de projeto. Mas é muito difícil estimar o tempo necessário para produzir uma parte de software. Difícil também medir a produtividade dos engenheiros. Problema também na variação contínua dos requisitos do usuário. Entrega incremental é uma solução.
Visibilidade: documentação clara de todas as etapas do desenvolvimento. Transparência, abertura. Todos os participantes devem estar cientes do estado do projeto, todos caminham na mesma direção. Visibilidade é também uma qualidade externa, até o cliente pode querer saber do estado do projeto. Muitas vezes o conhecimento do projeto é transmitido de forma informal entre os participantes. Isto pode ser problema em uma equipe onde há rotatividade. Um novo membro ao entrar vai atrasar o projeto até adquirir os conhecimentos.
11
Requisitos de Qualidade em Diferentes Aplicações
Sistemas de Informação
Integridade de Dados
Segurança
Disponibilidade
Desempenho das Transações
Sistemas de Tempo Real
Tempo de Resposta
Segurança
Interface Homem-Máquina
Em sistemas de informação: Em quais circunstâncias os dados estão danificados? Como é a proteção contra acesso não autorizado? É possível os dados deixarem de ser disponíveis? Por quanto tempo? Qual é o tempo de resposta das transações?
Tempo de resposta é o mais crítico em tempo real. Nem sempre o mais rápido possível é o melhor. Deve ser no tempo certo. Em outros sistema tempo de resposta e questão de desenpenho, em tempo real é questão de correção.
Segurança é usado para denotar a ausência de comportamento indesejado. Requisitos de segurança descrevem o que o sistema não deve fazer.
A interface deve ser a mais precisa de forma a evitar ao máximo erros de operador.
12
Requisitos de Qualidade em Diferentes Aplicações
Sistemas Distribuídos
Suporte a desenvolvimento em ambiente distribuído
Tolerância a particionamento da rede
Tolerância a falhas de um computador
Sistemas Agregados
Interface com equipamentos ou sistemas
Processamento feito em vários computadores -> desenvolvimento também
O que distribuir? Dados ou processamento?
Pode-se e como tolerar um particionamento na rede?
Como reagir a falha de um computador da rede?
Sistemas embutidos são aqueles onde o software é um componente que não tem nenhuma interface com o usuário. Exemplo o controle de velocidade de um robô.
Muitos sistemas exibem características comuns a várias destas áreas. Monitoramento de paciente em um hospital: Tem um banco de dados com a história do paciente, pode ser distribuído, é de tempo real.
13
Adequado à Especificação
Não é fácil definir qualidade de software como adequado à especificação
A especificação pode estar ambígua, incompleta ou inconsistente
Alguns requisitos podem não aparecer na especificação
É difícil especificar todos os requisitos
Atributos Implícitos de Qualidade
Alguns atributos são difíceis de serem especificados
Mas tem grande efeito na qualidade do sistema
Exemplos
Como especificar a facilidade de Manutenção
Como garantir Proteção / Segurança
Como garantir Eficiência, etc.
Qualidade de Processo x Produto
Acredita-se que a qualidade do processo afeta diretamente a qualidade do produto
Esta crença veio da indústria de manufatura
Configurar e operar as máquinas envolvidas
Uma vez que as máquinas estejam funcionando corretamente, a qualidade do produto segue normalmente
Mede-se a qualidade do produto e altera-se o processo até atingir o nível de qualidade requerida
Em software, a relação entre qualidade de processo e qualidade de produto é complexa
Qualidade Baseada no Processo
Equipe de Qualidade
Idealmente, a equipe de garantia da qualidade deve ser diferente da equipe de desenvolvimento
O processo de qualidade envolve
Definir padrões de processo
Monitorar o processo para verificar o adequado uso dos padrões
Emitir relatórios para a gerência de projeto e da organização
O Tamanho do Projeto
Mesmo em sistemas pequenos, o gerenciamento da qualidade é importante
Entretanto, ele pode seguir um abordagem mais informal
Em sistemas grandes, o gerenciamento de qualidade requer três atividades
Garantia de Qualidade
Planejamento de Qualidade
Controle de Qualidade
Atividades de Gerenciamento
Garantia de Qualidade
Estabelece um framework com os procedimentos e padrões
Planejamento de Qualidade
Seleção dos procedimentos e padrões apropriados ao projeto
Controle de Qualidade
Verifica se os procedimentos e padrões estão sendo seguidos
Garantia da Qualidade (QA)
A garantia da qualidade de software define busca saber
Como a qualidade pode ser atingida
Se a qualidade foi atingida
Tipos de padrões para QA
Padrões de produto: padrões de documentação, padrões de codificação, etc.
Padrões de processo: definem as atividades do processo e os seus resultados
Exemplos (Padrões de Produto)
Formulário de revisão do projeto
Estrutura do documento de requisitos
Formato da assinatura de métodos
Estilo de programação Java
Formato do plano de projeto
Formato do formulário de solicitação de mudanças
Exemplos (Padrões de Processo)
Conduta de revisão de projeto
Envio de documentos para gerência
Processo de liberação de versões
Processo de aprovação do plano de projeto
Processo de controle de mudanças
Processo de registro de testes
Importância de Padrões
Documentam o conhecimento das melhores práticas
Indicam o caminho para se obter qualidade (aos menos experientes)
Facilitam a comunicação entre os membros da equipe
O uso de fato de padrões
Alguns cuidados para que os padrões sejam de fato implementados
Envolver a equipe de desenvolvimento na escolha dos padrões
Revisar os padrões regularmente para refletir mudanças de tecnologia
Não incluir apenas o que seguir, mas também o porque de seguir um padrão
Prover ferramentas para apoiar a adoção dos padrões
Planejamento da Qualidade
É o processo de desenvolvimento de um plano de qualidade para um projeto
Estabelece os padrões apropriados para um produto e processo
Estrutura de Planejamento
Descrição do produto, mercado e das expectativas de qualidade
Plano com as datas críticas e responsabilidades
Descrição dos métodos e serviços usados no desenvolvimento e gerenciamento do produto
Definição das metas de qualidade e respectivas justificativas
Descrição dos riscos e ações para minimizá-los
Controle de Qualidade
Envolve a monitoração do processo de desenvolvimento
Busca assegurar que os procedimentos e padrões são de fato aplicados 
Abordagens de Controle
Revisões de qualidade
A equipe de qualidade verifica a documentação e o processo de desenvolvimento
Avaliação automatizada
O produto (ou documentação) é processado automaticamente
Métricas são usadas para verificar a qualidade
Alguns Atributos de Qualidade
Segurança
Compreensibilidade
Portabilidade
Proteção
Testabilidade
Usabilidade
Confiabilidade
Adaptabilidade
Reusabilidade
Resiliência
Modularidade
Eficiência
Robustez
Complexidade
Capacidade de aprendizado
Medições de Software
Por que medir?
Revisão para avaliação da qualidade é uma atividade demorada
Geralmente causa atraso na conclusão do projeto.
Para acelerar a revisão, ferramentas devem ser empregadas para permitir avaliações automatizadas.
Métrica de software
Uma métrica de software é qualquer medição que se refere ao sistema
Medições de tamanho (exemplo, LOC)
Número de defeitos relatados, etc.
Medições se dedicam a obter um ou mais valores numéricos para uma atributo de qualidade
Comparando os números, é possível tirar conclusões sobre a qualidade do produto
Uso de Medições
Medições de software podem ser usadas de duas maneiras
Para fazer previsões gerais sobre um sistema (exemplo, número de defeitos)
Para identificar partes (ou módulos) problemáticos
Adoção pela Indústria
Muitas empresas ainda não usam medições sistemáticas para avaliar a qualidade
Algumas razões
Os processos das empresas não são maduros o suficiente
A ausência de métricas padronizadas
Limitado apoio de ferramentas de medição
Problemas com Medições
Geralmente é impossível medir um atributo de qualidade diretamente
Atributos de qualidade são fatores externos ao software
Métricas medem fatores internos
Exemplos de atributos de qualidade
Facilidade de manutenção
Facilidade de uso
Confiabilidade
Solução: Modelos de Qualidade
Uma solução é medir atributos que podem estar relacionados aos atributos de qualidade
Idealmente, deve haver um relacionamento claro e válido entre atributos de qualidade e atributos internos
Um Modelo de Qualidade
Validade dos Modelos
Três condições devem ser verificadas em modelos de qualidade
O atributo interno deve ser precisamente medido
Deve haver relacionamentos entre o que podemos medir e o que queremos saber
Os relacionamentos são compreendidos e válidos
O Processo de Medição
O processo de medição deve fazer parte do processo de controle da qualidade
Utilizam dados históricos de projetos anteriores
As atividades do processo
Escolher medições a serem realizadas
Selecionar componentes a serem avaliados
Medir características dos componentes
Identificar medições anômalas
Analisar componentes anômalos
Modelo do Processo
Escolher Medições
Uma abordagem para escolher as medições é o GQM
Goal-Question-Metric
As questões são formuladas para atender um objetivo
As métricas são escolhidas para responderem as questões
O Modelo de Medição GQM
Objetivos
Definem o que a organização quer melhorar (exemplo: produtividade)
Questões
Refinamento dos objetivos em áreas de incertezas (exemplo: linhas de código produzidas podem ser aumentadas?)
Métricas
Medições necessárias para responder as questões (exemplo: LC por desenvolvedor)
Selecionar Componentes
Pode não ser necessários (ou desejável) medir todo o sistema
Estratégias de escolha
Escolher um subconjunto representativo de todos os componentes
Escolher os componentes que podem ser particularmente críticos na aplicação
Medir os Atributos de Qualidade
Os componentes selecionados são medidos
As medidas são então associadas aos atributos de qualidade
Geralmente envolve uma representação dos componentes 
Ferramentas de medição podem estar incorporadas a outras ferramentas (ou ambientes) de desenvolvimento
Analisar Medições
Uma vez feita as medições, é necessário compará-las a medições anteriores
Dados históricos são utilizados
A análise deve procurar valores incomuns
Ou seja, valores muito altos ou muito baixos para cada métrica
Analisar Componentes
Se um componente tem valores anômalos, este deve ser examinado
A inspeção é responsável por decidir se existe (ou não) problema no componente
Um valor incomum para um componente não necessariamente significa que o componente tem baixa qualidade
Métricas de Produto
Métricas de Produto
Quantificam atributos internos do software
Exemplos de atributos
Tamanho
Acoplamento dentre componentes
Coesão de um componente, etc.
Tipos de Métricas
Métricas Dinâmicas
São coletadas por medições realizadas durante a execução do programa
Métricas Estáticas
São coletadas por medições realizadas na documentação de projeto ou código fonte do programa
Dinâmicas x Estáticas
Métricas dinâmicas ajudam a avaliar atributos de qualidade como eficiência e confiabilidade
São medidas após o sistema ter sido implementado
Métricas estáticas ajudam a avaliar atributos como complexidade e facilidade de manutenção
Podem ser medidas na fase de projeto
Algumas Métricas Estáticas
Fan-in / Fan-out
Tamanho do código
Complexidade Ciclomática
Tamanho do Vocabulário
Profundidade de Aninhamento
Fan-in e Fan-out
Fan-in
Conta o número de funções que chama uma determinada função
Valor alto significa grande impacto em mudanças (propagação)
Fan-out
Conta o número de funções chamadas pela função
Valor alto significa grande complexidade da função
Tamanho e Complexidade
Tamanho
Tamanho tem se mostrado como as métricas mais confiáveis e úteis
Em geral, quanto maior, mais complexo e propenso a erro será o componente
Complexidade Ciclomática
Mede a complexidade de controle do programa (if, while, for, etc.)
Está relacionada a facilidade de compreensão
Vocabulário e Aninhamento
Tamanho do Vocabulário
Conta a quantidade de identificadores (exemplo, nome de classes) do programa
Mais identificadores podem significar que eles são mais significativos
Profundidade de Aninhamento
Conta estruturas internas como if e while aninhados
Estruturas aninhadas são mais difíceis de se compreender
Métricas de Programas OO
Profundidade da Herança (DIT)
Acoplamento entre Objetos (CBO)
Métodos Ponderados por Classes (WMC)
Número de Operações Sobreescritas
Profundidade de Herança (DIT)
Representam o número de níveis indiretos que uma classe herda métodos e atributos
Quanto maior a profundidade
Mais complexo o projeto
Mais difícil de se entender um módulo
DIT = 0
DIT = 1
DIT = 2
Acoplamento entre Objetos (CBO)
Semelhante a Fan-out
Conta classes chamadas por uma classe
Quanto mais acoplado uma classe
Mais difícil de entender e de manter
CBO = 0
CBO = 1
CBO = 2
Métricas para Métodos
Métodos Ponderados por Classes (WMC)
Atribui pesos aos métodos de uma classe
Exemplo, pode-se “pesar” por linhas de código ou por número de parâmetros
Valores altos indicam complexidade
Número de Operações Sobrescritas
Conta as operações da superclasse que são sobrescritas na subclasse
Valores altos indicam problemas de herança
Análise de Medições
Nem sempre é óbvio o que os dados significam
Entender uma grande quantidade de números é muito difícil
Estatísticos devem ser consultados, se estiverem disponíveis
A análise de dados deve levar em conta as circunstâncias locais
Resumo
Gerenciamento de qualidade de software assegura que o software atende aos padrões adequados
Padrões encapsulam conhecimento de boas práticas
Revisões são amplamente usadas para avaliação de qualidade
Revisões são demoradas e podem atrasar o projeto
Resumo
Medição podem ser aplicadas tanto ao processo quanto ao produto de software
Métricas de produto devem ser usadas para identificar componentes potencialmente problemáticos
Métricas são difíceis de serem usadas e compreendidas
Nem sempre são padronizadas
Bibliografia Principal
Ian Sommerville. Engenharia de Software, 9ª Edição. Pearson Education, 2011.
Cap. 24 Gerenciamento de Qualidade