Gerenciamento_de_Qualidade

Prévia do material em texto

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 dassentenç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