FATORES E MÉTRICAS DE QUALIDADE

Transcrição

1 FATORES E MÉTRICAS DE QUALIDADE 1

2 2

3 FATORES DE QUALIDADE OPERAÇÃO DO PRODUTO CORRETITUDE (FAZ O QUE EU QUERO?) CONFIABILIDADE (SE COMPORTA COM PRECISÃO?) EFICIÊNCIA (RODARÁ TÃO BEM QUANTO POSSÍVEL?) INTEGRIDADE (É SEGURO?) USABILIDADE (FOI PROJETADO PARA O USUÁRIO?) 3

4 QUALIDADE BASEADA NO PROCESSO DEFINA O PROCESSO DESENVOLVA O PRODUTO AVALIE A QUALIDADE DO PRODUTO MELHORE O PROCESSO NÃO QUALIDADE OK SIM PADRONIZE O PROCESSO 4

5 FATORES E MÉTRICAS DE QUALIDADE Qual a importância de controlarmos os gastos com o software em qualidade? Analisar a qualidade dos resultados obtidos com seu desenvolvimento e manutenção; Permitir que padrões sejam gerados com base nos controles de qualidade; Mas podemos medir o processo de desenvolvimento do software? 5

6 FATORES E MÉTRICAS DE QUALIDADE Podemos medir, se tomarmos como exemplo, o tamanho das aplicações que serão desenvolvidas e a partir daí estimar prazos e custos reais ou o mais próximo possível? Como medir a evolução de produção dos programadores, e assim, avaliar o progresso no projeto e estimar os recursos necessários? Como medir a qualidade do software em desenvolvimento e determinar se deverão ser aplicadas ações corretivas? 6

7 FATORES E MÉTRICAS DE QUALIDADE Os fatores de qualidade são necessárias para: Analisar qualidade e produtividade do processo de desenvolvimento e manutenção bem como do produto de software construído; Qualificar o desempenho técnico dos produtos do ponto de vista do desenvolvedor; Medidas funcionais são necessárias para qualificar o desempenho dos produtos pela perspectiva do usuário; Devem ser independentes das decisões do desenvolvimento técnico e implementação; Utilizadas para comparar a produtividade de diferentes técnicas e tecnologias. 7

8 FATORES E MÉTRICAS DE QUALIDADE Os fatores de qualidade possibilitam realizar uma das atividades mais fundamentais do processo de gerenciamento de projetos que é o planejamento. A partir deste, passamos a identificar a quantidade de esforço, o custo e as atividades que serão necessárias para a realização do projeto. Há bem pouco tempo, a única base para a realização de estimativas era a experiência da equipe técnica envolvida no projeto, podendo ocasionar: Em atropelar as atividades de desenvolvimento, deixando de realizar diversos passos do projeto; Produtos com deficiência funcional; Custo de realização além do previsto; Atraso na entrega do produto. 8

9 FATORES E MÉTRICAS DE QUALIDADE O mercado está cheio de "ferramentas de produtividade". O aumento ideal da produtividade só é obtido quando for possível estabelecer uma sistemática de métricas significativas que reflitam nos resultados do desenvolvimento de software e que possa ser implementado efetivamente ao ser usado. O ato de medir é algo comum no mundo da engenharia. Mas para engenharia de software estamos longe se ter uma medição padrão amplamente aceita e com resultados sem nenhum fator subjetivo. Temos dificuldade em concordar sobre o que medir e como avaliar o resultado das medições obtidas. 9

10 FATORES E MÉTRICAS DE QUALIDADE Algumas razões para se medir o software: Indicar a qualidade do produto; Avaliar a produtividade dos que desenvolvem o produto; Determinar os benefícios derivados de novos métodos e ferramentas de engenharia de software; Formar uma base para as estimativas; Ajudar na justificativa de aquisição de novas ferramentas ou de treinamentos adicionais. 10

11 FATORES E MÉTRICAS DE QUALIDADE As métricas de software, do ponto de vista de medição, podem ser divididas em duas categorias: medidas diretas e indiretas. MEDIDAS DIRETAS Custo Esforço Linhas de Código Velocidade de Execução Memória Nº de Erros MEDIDAS INDIRETAS Funcionalidade Qualidade Complexidade Eficiência Confiabilidade Manutenibilidade 11

12 FATORES E MÉTRICAS DE QUALIDADE As medições de software podem ser organizadas em outros modelos de classes: Métricas da produtividade Baseadas na saída do processo de desenvolvimento do software com o objetivo de avaliar o próprio processo; Métricas da qualidade Que permitem indicarem o nível de resposta do software às exigências explícitas e implícitas do cliente; Métricas técnicas Nas quais encaixam-se aspectos como funcionalidade, modularidade, manutenibilidade, etc... 12

13 FATORES E MÉTRICAS DE QUALIDADE Se desejarmos organizar sob uma outra ótica, seria possível definir uma nova classificação das medições, como: Métricas orientadas ao tamanho Baseadas nas medições diretas da Engenharia de Software; Métricas orientadas à função Que oferecem medidas indiretas; Métricas orientadas às pessoas As quais dão indicações sobre a forma como as pessoas desenvolvem os programas de computador. Também podemos dividir as métricas de software, sob o ponto de vista de aplicação, em duas categorias: 1. Métricas de Produtividade Se concentram na saída do processo de engenharia de software; 2. Métricas de Qualidade Indicam o quanto o software atende aos requisitos definidos pelo usuário. 13

14 MÉTRICAS ORIENTADAS AO TAMANHO A medida de software mais familiar é a contagem de linhas de código. Apesar desta métrica parecer simples, temos um problema sobre o que seria uma linha de código para uma contagem correta. As medidas de linhas de código não deveriam contar as linhas de comentário e linhas em branco, pois na compilação essas linhas são ignoradas e não possuem funções no aplicativo. Está fortemente ligado à linguagem de programação utilizada, impossibilitando a utilização de dados históricos para projetos que não utilizam a mesma linguagem. 14

15 MÉTRICAS ORIENTADAS À FUNÇÃO Podemos dizer que seria um outro conjunto de métricas de qualidade e produtividade que poderá ser desenvolvido. Em vez de contar as linhas de código, a métrica orientada à função concentra-se na funcionalidade do software. Foi uma proposta da IBM no início da década de 70 por seus pesquisadores, cujo trabalho era identificar as variáveis críticas que determinam a produtividade da programação. Essa pesquisa descobriu que poderiam basear a avaliação de um software, simplesmente medindo o valor das funções executadas pelos programas. 15

16 MÉTRICAS ORIENTADAS À FUNÇÃO Em 1979, Allan Albrecht, prosseguindo com estas pesquisas, introduziu uma técnica de avaliação conhecida como Pontos por Função, que era: Baseada na visão externa do usuário; Independente da linguagem utilizada; Permite calcular o esforço de programação; Auxilia o usuário final a melhorar o exame e avaliação de projetos. Seus objetivos são: Medir o que foi requisitado e recebido do usuário; Medir independente da tecnologia utilizada para a implementação; Prover uma métrica de medição para apoiar a análise de produtividade e qualidade; Prover uma forma de estimar o tamanho do software; Prover um fator de normalização para comparação de software. 16

17 O FATOR HUMANO Quando os objetivos para o desenvolvimento de sistemas não estão claros, as pessoas passam a deduzir e criar o produto dentro de suas próprias visões, consequentemente, teremos métricas falhando, gerando uma expectativa divergente entre o cliente e os técnicos responsáveis, causando uma estimativa de qualidade irreal. As pessoas são sensíveis aos estímulos externos e por meio de tais estímulos suas atitudes e pensamentos são influenciados. O analista com o propósito de estimar o tempo e custo de um projeto não pode deixar de dar a devida relevância a este fato. 17

18 O FATOR HUMANO Para tentar amenizar a dificuldade e se estabelecer critério para a estimativa em relação ao fator humano, surge o conceito de "Engenharia Humana", que consiste em aplicar conceitos de psicologia para se projetar uma interação homem-computador. Do ponto de vista do especialista em engenharia humana, o homem e a máquina são partes integrantes de todo um sistema homem-máquina, onde o homem é visto como um elo de coleta e processamento de dados. 18

19 O FATOR HUMANO CONTROLE E GARANTIA DA QUALIDADE 19

20 DEFINIÇÃO Atividade e técnica operacional que é utilizada para satisfazer os requisitos de qualidade (McDermid). 20

21 Possui funções gerenciais e estão relacionadas às atividades de verificação e validação; Consome tempo no desenvolvimento de sistemas de software e vai além da entrega do sistema, (entra na fase de manutenção); Técnicas usadas para cada atividade podem contribuir para o respectivo controle de qualidade; Algumas técnicas têm controle embutido, outras não; Gerentes procuram ter sempre os melhores projetistas para seu produto, mas em geral nem sempre podem tê-los. 21

22 ATIVIDADES SQA Necessidade de se concentrar esforços em métodos de SQA (Software Quality Assurance ou Garantia da Qualidade de Software); Monitorar métodos e padrões que os engenheiros de software usam; Pessoas podem ser experientes em SQA, sem, no entanto, serem experientes em projetos de software; 22

23 ATIVIDADES SQA SQA possui uma variedade de tarefas, divididas em dois grandes grupos: 1. Engenheiros de software Fazem o desenvolvimento dos sistemas, ou seja, o trabalho técnico; 2. Grupos de SQA Suas responsabilidades estão: Sobre o plano de qualidade; Inspeção; Conservação de registros históricos; Análise do produto desenvolvido; Reporting (reportar) das atividades de SQA ao gerente do projeto. 23

24 ATIVIDADES SQA O SEI (Software Engineering Institute) recomenda as seguintes atividades para o grupo de SQA: Preparar um plano de SQA; Participar da descrição do projeto de software; Revisar as atividades dos engenheiros de software; Documentar e consertar os desvios; Registrar discordâncias e reportar para o gerente; Gerenciar mudanças e métricas de software. 24

25 REVISÕES DE SOFTWARES São um filtro no processo de Engenharia de Software; Não são limitadas à especificação, projeto e código; Defeito Anomalia do produto (IEEE Instituto de Engenharia de Eletro e Eletrônico); IEEE É uma organização composta por engenheiros, cientistas e estudantes, que desenvolvem padrões para a indústria de computadores e eletro-eletrônicos, sem fins lucrativos. Revisões Técnicas Formais (RTF) Encontrar erros durante o processo antes que eles se tornem defeitos; RTF podem descobrir cerca de 75% desses erros. Entre 50% a 60% do total de erros são introduzidos durante o projeto de software; 25

26 MEDIDAS DE PRODUTIVIDADE DE PROGRAMAÇÃO A qualidade do software está diretamente ligada a produtividade de programação, a qual é afetada pela: Qualidade da documentação; Linguagem de programação; Disponibilidade de ferramentas; Experiência do programador; Comunicação no projeto; Grau de dependência entre módulos; Práticas de programação bem definidas. 26

27 MEDIDAS DE CONFIABILIDADE Probabilidade de uma operação de programa de computador estar livre de falha, onde: o Falha - Não conformidade com os requisitos de software. É um elemento importante para a qualidade do software; Exemplo: Um software que opera corretamente em 96 das suas 100 execuções tem uma confiabilidade de 0.96 ou 96%. 27

28 CONFIABILIDADE X SEGURANÇA Confiabilidade Usa a análise estatística para determinar a probabilidade de que uma falha venha a ocorrer. Segurança Examina as possibilidades segundo as quais as falhas resultam em condições que podem levar a uma deformação. 28

29 PLANOS SQA Especifica: Os objetivos; As tarefas de SQA a serem realizadas; Os padrões; Os procedimentos da estrutura organizacional; Os mecanismos de auditoria; 29

30 PLANOS SQA Documentos de Engenharia de Software exigidos: Especificação de Requisitos; Descrição de Projeto; Plano (e Relatório) de Verificação e Validação; Documentação do Usuário. 30

31 AULAS DE APOIO Estarão disponibilizadas nos descritos a baixo para downloads os arquivos nos formatos: PowerPoints ou Word das aulas. Alguns estarão disponíveis para impressão, outros, somente para leitura, mas não para edição. Em alguns casos em que se fizer necessário a impressão, o professor estará liberando para um melhor desenvolvimento dos trabalhos a ser solicitados. ou Contato: celsocan@gmail.com 31

32 FIM 32