Qualidade de Software. Profa. Cátia dos Reis Machado

Transcrição

1 Qualidade de Software Profa. Cátia dos Reis Machado

2 Evolução da Qualidade na indústria automotiva Quando falamos de administração científica, não podemos ignorar a contribuição de F. W. Taylor e Henry Ford. A principal mudança trazida por eles ao conceito de administração foi a criação de padrões dentro das linhas de montagem, dando origem a um método de produção. Fonte: Engenharia de Software Magazine

3 Evolução da Qualidade na indústria automotiva Tarefas começaram a ser divididas, facilitando o controle de qualidade. Nesse sentido, todas as peças produzidas passaram por uma verificação de qualidade antes de sair da área de produção. Ainda na década de 20, com o desenvolvimento de estudos de especialistas militares e o trabalho de Walter Shewart (1939) do Bell Laboratories, surgiu a base do controle estatístico da qualidade.

4 Evolução da Qualidade na indústria automotiva Agora, não mais toda a linha de produção precisaria ser testada, mas apenas uma amostragem passou a ser utilizada no controle de qualidade dos produtos. Assim, os produtos eram testados em pequenos lotes que eram o identificador de um conjunto total de produtos. Desse modo, houve um ganho de tempo na linha de produção e aumento da qualidade do produto apenas utilizando critérios de certeza estatística que aperfeiçoaram a verificação e, consequentemente, foram eliminados custos desnecessários.

5 Evolução da Qualidade na indústria automotiva Entre as décadas de 40 e 50, o Japão se colocou em destaque no cenário da qualidade como ciência devido ao trabalho de William Edwards Deming (1982) que reforça o conceito de controle de qualidade desviando o foco da qualidade do produto para a qualidade do processo como fator chave para o sucesso da implementação de um sistema de qualidade. Esse modelo de qualidade de processo só foi disseminado na década de 1970.

6 Evolução da Qualidade na indústria automotiva Outro que se destacou neste campo foi Genichi Taguchi (1990) para projetos experimentais. Algumas outras metodologias contemporâneas como 5S e os Diagramas de Causa e Efeito de Ishikawa, conhecido como Diagrama de Espinha de Peixe também colaboraram com a evolução da qualidade no Japão.

7 Evolução da Qualidade na indústria automotiva Na década de 60, Feigenbaum (1991) consolida o conceito de controle da qualidade total que leva à qualidade um sentido não mais focando somente em produção, mas sim em elementos como Marketing, Finanças, Recursos Humanos, Pesquisa e Desenvolvimento. A qualidade total não implica em 100% do produto correto ou zero defeito, mas sim de que todas as pessoas envolvidas são responsáveis pelo produto final.

8 Evolução da Qualidade na indústria automotiva Na década de 80 se popularizou as normas ISO (International Organization for Standardization As montadoras de automóveis se destacaram nessa época e as normas contribuíram na definição de padrões de processos de garantia da qualidade.

9 Evolução da Qualidade na indústria automotiva A qualidade na indústria de software não seguiu uma evolução tão diversa assim da indústria automotiva. O rumo que a Qualidade de Software tomou na história se iniciou a partir da reunião da OTAN em 1968 onde o termo Engenharia de Software foi utilizado pela primeira vez por F. L. Bauer.

10 Evolução da Qualidade na indústria automotiva Nessa reunião foi utilizado também o termo Crise do Software para definir a situação em que a indústria do software atravessava naquele momento. E a crise foi atribuída à complexidade de desenvolver sistemas cada vez maiores, bem como à falta de gerenciamento no processo de desenvolvimento de software.

11 Qualidade de Software a partir da década de 70

12 A Década de 70: Medição do Código Fonte Caracterizada por Métricas para código fonte propostas por Halstead (ex: número de operadores distintos, número de operandos distintos, etc.) Métricas de Complexidade Ciclomática de McCabe Medida do número de caminhos linearmente independentes num módulo Influenciada por: Aceitação crescente da programação estruturada Primeiras noções de complexidade cognitiva

13 A Década de 80: Medição no início do ciclo de vida Estimativas de medição: esforço e custo Medidas na etapa de projeto Medidas na etapa de especificação

14 A Década de 90: Um perspectiva mais ampla Surgimento de relatórios sobre programas de métricas aplicados em empresas Benchmarking Impacto do modelo CMM Surgimento de ferramentas para medição Surgimento de uma teoria de medição como um framework unificado Surgimento de padrões internacionais de medição de software (ex: Análise de pontos de função)

15 Tendências: procura por métricas mais específicas Medidas que: capturem a complexidade cognitiva capturem a complexidade estrutural capturem a complexidade funcional sejam independentes de linguagem possam ser extraídas nas etapas iniciais do ciclo de vida

16 Engenharia de Software O principal objetivo da Engenharia de Software (ES) é ajudar a produzir software de qualidade

17 Software de qualidade Mas afinal o que é um software de qualidade?

18 Software entregue ao cliente com quantidade mínima de defeitos e que atenda as expectativas do cliente. Qualidade é tudo aquilo que melhora o produto no ponto de vista do cliente. Deming

19 Empresas que desenvolvem software de qualidade são mais competitivas. Cliente satisfeito: volta empresa Indica a empresa em sua rede de relacionamento Empresas que utilizam software de alta qualidade podem, em geral, oferecer um melhor serviço a um preço mais competitivo.

20 Conceito Qualidade é estar em conformidade com os requisitos dos clientes; Qualidade é antecipar e satisfazer os desejos dos clientes; Qualidade é escrever tudo o que se deve fazer e fazer tudo o que foi escrito. 1º) capturar com eficácia os requisitos do cliente Dificuldade de capturar requisitos Dificuldade de entender corretamente o problema Dificuldade de o usuário passar os requisitos 2 ) Transformar os requisitos corretamente em um produto que esteja refletindo aquilo que o cliente pediu Nessas transformações nós humanos podemos inserir defeitos ao longo do processo

21 Conceitos de Qualidade A totalidade das características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas. (NBR ISO 8402) Conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissional desenvolvido. (Pressman, 2011)

22 O conceito é simples, entretanto atingir a qualidade não é tão trivial.

23 Eficiência / Eficácia A eficiência envolve a forma com que uma atividade é feita, a eficácia se refere ao resultado da mesma. Fazer a coisa certa de forma certa é a melhor definição de trabalho eficiente e eficaz. Paulo Sandroni (1996)

24 Fatores de qualidade de software A noção de qualidade de software pode ser descrita por um grupo de fatores, requisitos ou atributos, tais como: confiabilidade, eficiência, facilidade de uso, modularidade, legibilidade, etc. Podemos classificar estes fatores em dois tipos principais: externos e interno;

25 Fatores de qualidade de software Fatores externos são concebidos tanto pelas pessoas que desenvolvem software quanto pelos usuários. Por exemplo, confiabilidade, eficiência e facilidade de uso são fatores externos; Fatores internos são percebidos apenas pelas pessoas que desenvolvem software. Por exemplo, modularidade e legibilidade são fatores internos; Se os fatores internos forem observados, os fatores externos serão consequentemente observados. De fato, os fatores internos são um meio para alcançar os fatores externos.

26 Fatores externos de qualidade

27 Fatores externos de qualidade Facilidade de uso: a facilidade de aprender como usar o software; Eficiência: o bom uso dos recursos computacionais; Portabilidade: a facilidade de transferir software entre ambientes operacionais.

28 Fatores externos da qualidade Correção: habilidade do software executar suas tarefas exatamente como definida pelos requisitos e especificação; Robustez: habilidade de um software funcionar mesmo em condições anormais; Integridade: habilidade do sistema de proteger seus vários componentes contra acessos ou modificações indevidas.

29 Diferentes visões da qualidade

30 Padrões de qualidade de software Provêem um framework conceitual para a implementação do processo de garantia de qualidade. Considerando que esses padrões englobam as melhores práticas, a garantia da qualidade envolve assegurar que padrões apropriados foram selecionados e usado.

31 Métricas de qualidade de software Várias métricas foram desenvolvidas para medir os atributos ou fatores de qualidade; Independente da métrica usada, sempre se busca os mesmos objetivos Melhorar o entendimento da qualidade do produto; Atestar a efetividade do processo; Melhorar a qualidade do trabalho realizado a nível de projeto; Formar uma base para as estimativas; Auxiliar na justificativa de aquisição de novas ferramentas ou de treinamentos adicionais; Avaliar o retorno de investimento; Gerenciar contratos de software;

32 Propriedades desejáveis de uma métrica Facilmente calculada, entendida e testada Passível de estudos estatísticos Expressa em alguma unidade Obtida o mais cedo possível no ciclo de vida do software Passível de automação Repetível e independente do observador Sugere uma estratégia de melhoria

33 Medição A medição é o processo pelo qual números ou símbolos são atribuídos aos atributos de entidades no mundo real, descrevendo-os de acordo com regras claramente definidas. (FENTON, 94) Exemplo: Utilizar medidas para analisar a produtividade, o esforço gasto numa tarefa, a confiabilidade do sistema desenvolvido, etc.

34 Categorização de Métricas Métricas diretas (fundamentais ou básicas) Medida realizada em termos de atributos observados (usualmente determinada pela contagem) Ex.: custo, esforço, no. linhas de código, capacidade de memória, no. páginas, no. diagramas, etc. Métricas indiretas (derivadas) Medidas obtidas a partir de outras métricas Ex.: complexidade, eficiência, confiabilidade, facilidade de manutenção

35 Categorização de Métricas Métricas orientadas a tamanho São medidas diretas do tamanho dos artefatos de software associados ao processo por meio do qual o software é desenvolvido. Ex.: esforço, custo, no. KLOC, no. páginas de documentação, no. erros Métricas orientadas por função Consiste em um método para medição de software do ponto de vista do usuário, determinando de forma consistente o tamanho e a complexidade de um software.

36 Categorização de Métricas Métricas de produtividade Concentram-se na saída do processo de engenharia de software. Ex.: no. de casos de uso/iteração. Métricas de qualidade Oferecem uma indicação de quanto o software se adeqüa às exigências implícitas e explícitas do cliente. Ex.: erros/fase Métricas técnicas Concentram-se nas características do software e não no processo por meio do qual o software foi desenvolvido. Ex.: complexidade lógica e grau de manutenibilidade

37 Possíveis problemas com métricas Ex: Comparar a produtividade de engenheiros em termos de linha de código Está sendo utilizado a mesma unidade de medida? O que é uma linha de código válida? O contexto considerado é o mesmo? Todos os engenheiros são familiarizados com a linguagem de programação? O que se quer realmente é o tamanho do código? E a qualidade do código? Como o resultado será interpretado? Produtividade média de um engenheiro? O que se quer com o resultado? Comparar a produtividade do processo de software?

38 Por que medir? Você não pode controlar o que não pode medir Tom DeMarco Medição ajuda, por exemplo, a saber: Qual será a duração de um projeto? Quanto custará o desenvolvimento de uma nova versão de um produto de software? Que percentual do produto já foi concluído? Quantos erros foram detectados e corrigidos antes da entrega do produto? Que percentual do esforço do projeto foi gasto em re-trabalho?

39 Por que medir? Você não pode controlar o que não pode medir Tom DeMarco Medição ajuda, por exemplo, a saber: Utilizando o nosso processo de software, o nível da qualidade dos nossos produtos está estável? Existe algum problema na execução do projeto e o que está causando este problema? A mudança da plataforma de desenvolvimento diminui o esforço gasto no teste?

40 Fornecendo informações para responder estas questões, a medição pode oferecer dados quantitativos e qualitativos para que, sistematicamente, os projetos sejam gerenciados e os processo e produtos de software sejam controlados. Somente a medição fornece a base para a criação de modelos organizacionais e estimativas de esforço e custo que podem ser empregados no planejamento de novos projetos.

41 Desafios enfrentados pelas organizações O que medir? Como coletar os dados de forma eficiente e válida? Como analisar os dados e como utilizar os resultados da medição?

42 Padrões de qualidade de software São baseados no conhecimento sobre as melhores e mais apropriadas práticas para a empresa. Ajudam a empresa a evitar a repetição de erros cometidos no passado.

43 Medição de software Existem vários tipos de referência para medição: Referências que descrevem o que deve ser feito norma internacional ISO / IEC sobre o processo de medição de software; Referências que descrevem como isto pode ser feito GQM Goal / Question / Metric e o PSM Pratical Software & Systems Measurement; Referências que visam a implementação e avaliação da capacidade de medição Quão bom - modelos e normas de melhoria de processo de software modelo CMMI (Capability Maturity Model Integration), norma ISO / IEC e o modelo Brasileiro de melhoria de processo MPS.BR

44 Qualidade é? Estar em conformidade com os requisitos dos clientes Antecipar e satisfazer os desejos dos clientes Escrever tudo o que se deve fazer e fazer tudo o que foi escrito

45 Medições de software para serem efetivas precisam estar alinhadas às necessidades de negócio da organização, isto é, aos seus objetivos estratégicos, e estarem direcionadas às necessidades de informação de gerentes de projetos e engenheiros de software. Essas necessidades devem ser explicitadas e devem orientar a definição do que medir e de como analisar e comunicar o resultado das medidas. (ISO/IEC 2002; BASILI et al., 1994; BARRETO, 2011)

46 Melhoria de processo de software Processos devem ser tecnicamente corretos e devem ser capazes de atender às necessidades do negócio. Um objetivo de melhoria de processo é um conjunto de características desejadas, definidas para orientar o esforço de melhoria de processos de modo específico e mensurável (SEI, 2010). Esses objetivos devem agregar valor ao negócio da organização e melhorar a qualidade dos produtos desenvolvidos (BARRETO, 2011).

47 Melhoria de processo de software Relacionam-se a : Galgar níveis mais altos de maturidade; Realizar mudanças visando a uma maior adequação às necessidades da organização ou melhorias no desempenho dos processos.

48 O que é necessário para realizar melhorias nos processo de software???? MEDIÇÃO

49 Objetivos para medição Coletar dados para medir o desempenho do processo; Analisar o desempenho do processo; Armazenar e utilizar os dados para interpretar os resultados de observações e análises, predizer custos e desempenho futuros, fornecer baselines e benchmarks, identificar tendências e avaliar a estabilidade e capacidade do processo. Florac e Carleton (1999)

50 Normas internacionais ISO/IEC ISO/IEC Modelos de maturidade CMMI-DEV MR-MPS

51 Métodos para apoio a medição GQM (Goal Question Metric) PSM (Pratical Software Measurement)

52 Processo de medição nas organizações Um programa de medição para ser efetivo em uma organização deve estar apoiado em um processo capaz de garantir a execução disciplinada do conjunto de atividades envolvidas.

53 Atividade Identifique algumas orientações sobre o processo de medição (Capítulo 2) Livro: Ana Regina Cavalcanti da Rocha; Gleison dos Santos Souza; Monalessa Perini Barcellos. Medição de Software e Controle Estatístico de Processos, 2012, 232 p. Disponível em: /Medicao_de_Software_e_Controle_Estatistico_de_P rocesso.html

54 Referências BARRETO, A. Definição e Gerência de Objetivos de Software Alinhados ao Planejamento Estratégico. Tese de Doutorado, universidade Federal do Rio de Janeiro BASILI. V.; CALDIERA, G.; ROMBACH, H. Goal Question Metric Paradigm, In: Encyclopedia of Software Engineering, V.2, pp: FENTON, N. Software Measurement: A Necessary Scientific Basis. IEEE Transactions on Software Engineering, vol. 20, No. 3, March Florac, W. A.; Carleton, A. D. Measuring the Software Process, Addison-Weslwy

55 Referências ISO/IEC. Software Engineering Software Measurement Process, The International Organization for Standardization and the International Electrotechnical Commission, PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7ª Edição. Porto Alegre: AMGH, p. SEI. Capability maturity Model Integration (CMMI) for Development, version 1.3, Carnegie Mellon university, Software Engineering Institute, Technical Report CMU/SEI