Gerenciamento de Qualidade

Paulo C. Masiero
Cap. 24 - SMVL
 Introdução
• Melhoria nos níveis gerais de qualidade de
software nos anos recentes.
• Diferenças em relação ao gerenciamento da
qualidade na manufatura
– Os requisitos provêm do cliente e da organização
que desenvolve o software
– Dificuldades em especificar características de
qualidade de forma não ambígua ou vaga
– Difícil saber quando a especificação está
completa.
 GQ: Organizado em três atividades
principais
• Garantia de qualidade
– Estabelecer procedimentos e padrões que levam
ao software de alta qualidade
• Planejamento de qualidade
– Processo de desenvolvimento de um plano de
qualidade para um processo específico
• Controle de qualidade
– Garantir que o processo especificado seja seguido.
 GQS: três níveis de preocupações
• Organizacional: estabelecer um “arcabouço”
de processos organizacionais e padrões que
levem a alta qualidade.
• Projeto:
– A. Definir um plano de qualidade: metas,
processos e padrões.
– B. Aplicação de processos específicos de
qualidade, verificar que são seguidos e garantir
que os resultados estejam em conformidade com
os padrões aplicáveis ao projeto.
 Qualidade de Processo e de Produto
• Na manufatura há uma ligação nítida entre
qualidade do processo de produção e
qualidade do produto.
• Na manufatura o processo é relativamente
fácil de padronizar e monitorar.
• No desenvolvimento de software esse
relacionamento é mais complexo.
• É difícil medir os atributos de qualidade do
software.
 Gerenciamento de Qualidade de
Processo

• Definição de padrões de processo.

– Ex. como e quando as revisões devem ser
conduzidas.
• Monitoração do processo de Desenvolvimento
• Relato do processo de software para a
gerência e para os clientes.
A Equipe de Garantia de Qualidade
• Equipe de QA (Quality Assurance) ou GQ
(Garantia de Qualidade)
• Deve ser independente e responder à gerência
acima do nível de gerente de projeto.
• Permite ter uma visão objetiva do software e
fazer relatórios sobre a qualidade do software
sem ser influenciada pelos problemas do
desenvolvimento.
 Garantia de qualidade e padrões
• É o processo que define como a qualidade do
software pode ser atingida e como a
organização de desenvolvimento sabe que o
software possui o nível de qualidade
desejado.
• Padrões de produto e padrões de processo
• São baseados nas melhores práticas, oferecem
um arcabouço de processo e ajudam na
continuidade
 Garantia de qualidade e padrões
(cont.)
• São estabelecidos por instituições diversas: US
DoD, BSI, IEEE, NATO
• Problemas na adoção: aumentam o esfoço e a
burocracia.
 Garantia de qualidade e padrões
(cont.)
• Possíveis soluções para o melhorar a taxa de
adoção:
– Envolver os engenheiros de software na seleção
de padrões de produto
– Revisar e atualizar os padrões regularmente para
acompanhar a evolução tecnológica
– Disponibilizar ferramentas de apoio
 Padrão ISO 9000
• Padrão internacional para todas as indústrias. É
um arcabouço.
• Foi adaptado para a indústria de software
• O padrão ISO 9001 descreve vários aspectos do
processo de qualidade e os procedimentos
organizacionais que as empresas devem definir.
• Deve ser documentado em um manual de
qualidade da organização
• Autoridades certificadoras certificam que o
processo de qualidade está de acordo com o que
é prescrito pelo padrão ISO 9001
Isso garante a
qualidade de um
produto?
ISSO 9001 – Revisão de 2000
 ISO 9001
• Não descreve os processos
• Para ser certificada, uma empesa deve
mostrar que tem esses processos definidos e
os segue, além de mostrar que seus processos
de qualidade são seguidos.
 Padrões de documentação
• Padrões de documentação são importantes por
que os documentos são a única forma tangível de
representação do software e de seu processo de
desenvolvimento.
• Existem três tipos
– Padrões de processo de documentação (como
produzir o documento)
– Padrões de documentos (identificação, estrutura,
apresentação e atualização)
– Padrões de intercâmbio de documentos
Processo de produção de documentos
 Planejamento de qualidade
• É o processo que define o processo de
desenvolvimento de um plano de qualidade
para um projeto específico.
• Deve selecionar os padrões organizacionais
para cada produto e processo de
desenvolvimento.
• Diferem em detalhes de acordo com o
tamanho e tipo de sistema a ser desenvolvido.
Humphrey propõe em seu livro clássico
sobre gerenciamento de software, a
seguinte estrutura:
Atributos de qualidade do software

No P. de Q. deve-se definir quais são os atributos de

qualidade mais importantes para o software em
desenvolvimento
Geralmente é muito difícil otimizar todos os atributos
 Controle de Qualidade
• Monitorar os processos de desenvolvimento
de software para assegurar que os
procedimentos e os processos de garantia de
qualidade estão sendo seguidos.
• Existem duas abordagem mais usadas para
atingir esse objetivo:
– Revisões de qualidade
– Avaliação automatizada
 Revisões de qualidade
• Um grupo de pessoas examina uma parte ou o
todo de um processo de software e sua
documentação associada
• As conclusões do exame são formalmente
registradas e passadas para os autores para
corrigir os problemas detectados.
 Revisões de qualidade: resumo
• Três a quatro revisores: projetista senior,
usuários, projetistas de subsistemas,
programadores (convidados e variável)
• Distribuir a documentação antecipadamente
• Revisão de no máximo duas horas. Definir um
moderador.
• O autor percorre, ou lê o documento com a
equipe de revisão. O moderador registra os
problemas e as ações a serem executadas.
 Medições e métricas de software
• A medição de software busca encontrar um
valor numérico para um atributo de software
• Comparando-se esses valores uns com os
outros e com valores históricos, é possível
chegar a conclusões sobre a qualidade do
software
• Há dois usos principais para as medições
– Fazer previsões gerais sobre um sistema
– Identificar componentes anômalos (controle)
 Medições e métricas de software
• Algumas empresas usam métricas (ou usaram em
algum momento), como a HP, a Nokia e a AT&T
• Na maioria das empresas os processos de
desenvolvimento não são bem definidos e isso
torna difícil definir padrões para métricas.
• Há também um apoio limitado de ferramentas.
• Geralmente é impossível definir os atributos de
software diretamente
• As métricas podem ser estáticas ou dinâmicas.
 Medições e métricas de software
• Geralmente é impossível medir diretamente
os atributos de qualidade
• Alguns atributos internos (AE) podem ser
medidos e eles ajudam a estimar a qualidade
dos atributos de qualidade (AQ):
– Os AI devem ser medidos com precisão
– Deve haver um relacionamento entre os AI e os
AQ.
– Esse relacionamento é compreendido, foi validado
(Ex. COCOMO) e pode ser expresso em termos de
uma fórmula ou modelo
O processo de medição
 Métricas de produto
• As principais métricas que podem ser
coletadas automaticamente, muitas vezes não
tem relacionamentos claros com os AQ.
• Ex. facilidade de manutenção e de
compreensão vs tamanho e complexidade
ciclomática
• É preciso experiência e coletar e analisar
grande quantidade de dados.
 Métricas de produto
• As métricas podem ser:
– Dinâmicas
• Têm relacionamento mais estreito com os atributos de
qualidade.
• Ex. Tempo de execução vs Desempenho
– Estáticas
• Têm relacionamento indireto com os atributos de
qualidade.
 Exemplos de métricas estáticas
genéricas
• Fan-in/Fan-ou
• Extensão de código (tamanho)
• Complexidade ciclomática
• Extensão de identificadores
• Profundidade do aninhamento de declarações
condicionais
• Índice de Fog ( compreensão de textos, com base
no tamanho das sentenças e das palavras)
 Métricas orientadas a objetos
• Profundidade da árvore de herança
• Fan-in/Fan-out de método
• Métodos ponderados por classe
• Número de operações sobrescritas

Deve-se tomar muito cuidado com a análise das

medições. Ex. número de solicitações de mudanças.
 Aprimoramento de processos
• Compreender os processos existentes e alterá-los
para incrementar a qualidade do produto e/ou
reduzir tempo e custo de desenvolvimento.
• O aprimoramento é uma atividade cíclica:
 Aprimoramento (melhoria) de
processos
• Processos de software são complexos
• Geralmente não é possível atender (ou otimizar
todas as características).
– Ex. Processo rápido vs visibilidade
• De um modo geral, os processo precisam ser
adaptados para uma organização, considerando
sua cultura organizacional, procedimentos e
padrões.
• Simplesmente não é possível transplantar um
processo que é usado em outro lugar.
 Fatores principais de qualidade de
produtos de software
• Qualidade do processo
• Tecnologia de Desenvolvimento
• Qualidade (e treinamento?) de pessoas
• Custo, tempo e cronograma
 Classificação de processos
• Processos informais
• Processos gerenciados: existe um processo que
define os procedimentos sua programação e
relacionamento entre os procedimentos.
• Processos metódicos: existe um método definido
e ferramentas de apoio
• Processos em aprimoramento: têm um
orçamento específico para aprimoramento e
procedimentos para conduzir esses
aprimoramentos.
 Medições de processos
• São dados quantitativos sobre o processo de
software. Ex.
– Esforço (Pessoa-dia, viagens, recursos)
– Tempo gasto em cada atividade
– Eventos específicos (Ex. defeitos por inspeção de
código, número de solicitações de mudanças de
requisitos etc)
• É preciso saber o que medir.
– GQM: objetivos, questões métricas (Basili e Rombach)
Análise e modelagem de processos
• Estudo dos processos existentes e criação de um
modelo abstrato do processo captando suas
características principais.
• Técnicas usadas incluem: Questionários e entrevistas,
estudos etnográficos
• Há uma interação envolvida: a análise permite definir o
que deve ser medido e ao medir se conhece melhor o
processo, levando ao aprimoramento.
• O processo representa geralmente uma situação ideal,
mas podem ocorrer muitas exceções e imprevisto.
Modelos de processos são incompletos e os Gerentes
deve lida com as exceções e imprevistos
Processo de mudança de processo
 O Framework CMMI
• SEI - Software Engineering Institute
• Início dos anos 90 CMM (Capability Maturity
Model) (Paulk et all)
• CMMI (Ahern et all, 2001): evolução do CMMI para
incluir a capacidade de aprimoramento e aplicação
em um conjunto mais amplo de empresas
• Modelo básico utilizado:
– Áreas de processo (24)
– Objetivos (descrições abstratas de um estado desejado)
– Práticas (como atingir um objetivo)
•É compatível com o CMM para software
•Escala de 6 pontos: 1 - não realizado, 2 – Inícial ...
•Prescreve os objetivos a serem alcançados em cada nível
•O aprimoramento é conseguido galgando-se níveis e
incorporando novas práticas ao processo
 Princípio básico
• Cada nível tem um conjunto de áreas de
processo associada e objetivos genéricos
• Exemplos de áreas para o nível “gerenciado”
– Gerenciamento de requisitos
– Planejamento de projeto
– Monitoração e controle de projeto
– Gerenciamento de acordos com os fornecedores
– Medição e análise
– Garantia de qualidade de processo e produto
– Gerenciamento de Configuração
 Modelo CMMI contínuo
• Muitas vezes pode ser mais adequado
introduzir uma prática de nível mais elevado
antes de uma prática de nível inferior.
• O CMMI-Contínuo avalia cada área de
processo e estabelece um nível de avaliação
de capacitação de 1 a 6
 MPS.BR
• OSCIP: Melhoria de Processo de Software
Brasileiro (MPS.BR)
• Baseado no CMMI
• Ligado ao Softex
• MPS: Modelo de Processo de Software
• Treina e certifica implementadores e
avaliadores (pessoas e instituições)
 MPS.BR - Níveis
• G – Parcialmente gerenciado
– G. Projetos
– G. Requisitos
• F – Gerenciado
– G. Aquisição
– Configuração
– G. Qualidade (GQA)
– G. Portfolio de Projetos
– Medição
• E – Parcialmente Definido
– Avaliação e medição do processo organizacional
– Definição do processo organizacional
– G. Recursos Humanos
– G. de Reutilização
 MPS.BR - Níveis
• D – Largamente Definido
– Desenvolvimento de Requisitos
– Integração do Produto
– Projeto e Construção do Produto
– Validação
– Verificação
• C – Definido
– Desenvolvimento para reutilização
– G. de Decisões
– G. de Riscos
• B – Gerenciado Quantitativamente
• A – Em Otimização