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