Gerenciamento de Qualidade. Paulo C. Masiero Cap SMVL

Transcrição

1 Gerenciamento de Qualidade Paulo C. Masiero Cap SMVL

2 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.

3 GQ: Organizado em três atividades Garantia de qualidade principais 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.

4 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.

5

6 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.

7 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.

8

9 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.

10 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

11 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.

12 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

13 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?

14 ISSO 9001 Revisão de 2000

15 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.

16

17 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

18 Processo de produção de documentos

19 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.

20 Humphrey propõe em seu livro clássico sobre gerenciamento de software, a seguinte estrutura:

21 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

22

23 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

24 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.

25

26 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.

27

28 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)

29 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.

30

31 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

32

33 O processo de medição

34 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.

35 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.

36 Exemplos de métricas estáticas Fan-in/Fan-ou genéricas 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)

37 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.

38

39 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:

40

41 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.

42 Fatores principais de qualidade de produtos de software Qualidade do processo Tecnologia de Desenvolvimento Qualidade (e treinamento?) de pessoas Custo, tempo e cronograma

43 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.

44

45 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)

46 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

47 Processo de mudança de processo

48 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)

49

50

51

52 É 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

53 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

54 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

55

56 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)

57 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

58 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