Qualidade de Software Aula de Revisão

1. Qualidade de SoftwareAula de Revisão Prof. Guilherme Alexandre Monteiro Reinaldo Recife

2. Contatos • Prof. Guilherme Alexandre Monteiro Reinaldo • Apelido: Alexandre Cordel • E-mail/gtalk: alexandrecordel@gmail.com • Site: http://www.alexandrecordel.com.br/fbv • Celular: (81) 9801-1878

3. SE CM EIA 731 Software CMM SystemsEngr CMM Systems SecurityEngr CMM SoftwareAcq CMM IPD CMM FAA iCMM People CMM Motivação • Proliferação de Modelos e Padrões em diversas áreas • Diferentes estruturas, formatos, termos, maneiras de medir maturidade • Causa confusão, especialmente quando mais de um modelo é utilizado • Difícil de integrar num único programa de melhoria

4. Motivação • O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas • Systems Engineering (SE); • Software Engineering (SW); • Integrated Product and Process Development (IPPD); • Supplier Sourcing (SS). • Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon • CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.

5. Modelos CMMI 1.3 • CMMI apresenta três modelos: • CMMI for Development (CMMI-DEV), voltado ao processo de desenvolvimento de produtos e serviços. • CMMI for Acquisition (CMMI-ACQ), voltado aos processos de aquisição e terceirização de bens e serviços. • CMMI for Services (CMMI-SVC), voltado aos processos de empresas prestadoras de serviços. • Uma das premissas do modelo é "A qualidade é influenciada pelo processo“.

6. Objetivos do CMMI • Além da integração dos modelos e redução dos custos com melhorias de processo, osseguintesobjetivostambémfazem parte do projeto CMMI: • Aumento do foco das atividades; • Integração dos processosexistentes; • Eliminarinconsitências; • Reduzirduplicações; • Fornecerterminologiacomum; • Assegurarconsistência com a norma ISO 15504; • Flexibilidade e Extensão para outrasdisciplinas.

7. Introdução • Método de avaliação utilizado: SCAMPI • SCAMPI (Standard CMMI Assessment Method for Process Improvement): Desenvolvido pelo Software Engineering Institute (SEI) • Método que reune as melhores práticas do CBA-PI e SCE • Métodos amplamente utilizados pelo SW-CMM e outros modelos de melhoria de processos • Existem cerca de 180 avaliadores SCAMPI no mundo: • Autorizados pelo SEI a realizar avaliações do CMMI.

8. Por que duas representações? • Herança de Modelos • Software CMM – Staged • SECM – Continuous • IPD CMM – Hybrid • Proponentes de cada representação participaram do time de desenvolvimento do produto CMMI. • Escolher uma única abordagem para representação tornou-se “muito difícil”. • Ficou acordado que inicialmente seriam abordadas duas representações do modelo com conteúdos equivalentes.

9. Staged ML5 Process Area Capability ML4 0 1 2 3 4 5 ML3 ML2 ML 1 PA PA PA . . .para um conjunto de áreas de processo estabelecidas pela organização. Comparando as Representações Continuous . . .para uma única área de processo ou um conjunto de áreas de processo.

10. 5 Foco na melhoria do processo Quantitatively Managed 4 Processo medido e controlado Defined 3 Processo proativo e caracterizado para a organização Managed 2 Processo caracterizado para projetos e frequentemente reativo Performed 1 Processo imprevisível, pouco controlado Dimensões para Medição da Melhoria do Processo Níveis de Maturidade Optimizing

11. Exemplo: Meta Específica e Prática Específica • Meta Específica (da AP Gerenciamento de Requisitos) • Requisitos são mantidos e refletem-se cuidadosamente nos planos de projeto, atividades e produtos. • Prática Específica (da AP Gerenciamento de Requisitos) • Manter rastreabilidade entre requisitos e fontes de requisitos.

12. Exemplo: Meta Genérica e Prática Genérica • Meta Genérica (do Nível 2 de Capacidade ou Maturidade) • Institucionalizar um processo gerenciado. • Prática Genérica (do Nível 2 de Capacidade ou Maturidade) • Estabelecer uma política organizacional.

13. … Área de Processo 1 Área de Processo n Meta Genérica 2 Meta Genérica 3 Meta Genérica 4 Meta Genérica 1 Meta Genérica 5 Meta Específica 1 Meta Específica n … Prática Específica 1 Prática Específica n Práticas Genéricas Nível 1 Práticas Genéricas Nível 2 Práticas Genéricas Nível 3 Práticas Genéricas Nível 4 Práticas Genéricas Nível 5 … Nível 0: Incompleto Nível 1: Executado Nível 2: Gerenciado Nível 3: Definido Estrutura do CMMI -Representação Contínua Nível 4: Gerenciado Quantitativamente Nível 5: Otimizando

14. Nível de Maturidade Área de Processo Área de Processo Área de Processo Metas Genéricas Metas Específicas Características Comuns Compromisso para Executar Habilidade para executar Implementação direta Verificação Práticas Genéricas Práticas Específicas Estrutura do CMMI -Representação por Estágios

15. Equivalência entre as Representações

16. SPICE (ISO 15504)

17. Utilização da 15504

19. Composição da ISO/IEC 15504 • 15504-1: Conceitos e Vocabulário (Concepts and Vocabulary) Normativo - Publicação 2004 • 15504-2: Executando uma Avaliação (Performing an Assessment) Normativo- Publicação 2003 • 15504-3: Guia sobre Executando uma Avaliação (Guidance on performing an assessment) Informativo - Publicação 2004 • 15504-4: Guia sobre Utilização do Resultado de Avaliação (Guidance on using assessment results) Informativo - Publicação 2004 • 15504-5: Um Exemplo de Modelo de Avaliação de Processo (An exemplar process assessment model) Informativo - Publicação 2005

20. nível de capacidade de processos pa pb ... pn processos Modelo de Processo da ISO 15504 • A arquitetura dos modelos é denominada de arquitetura contínua, com duas dimensões: • dimensão de processo • dimensão de capacidade de processo. • A 15504-5 define um exemplo de um modelo compatível com a 15504: • denominado de ISO/IEC 15504-5, e • representa um conjunto de melhores práticas para a engenharia de software.

21. Modelo de Processo da ISO 15504 • A 15504-5 organiza estas em duas grandes categorias: • aquelas relacionadas a “o que fazer”, organizadas em processos específicos; (“dimensão de processos”) • aquelas relacionadas ao “quão bem fazer qualquer coisa que seja feita”, organizadas em níveis de capacidade genéricos. (“dimensão de capacidade”)

22. Fundamentais Organizacionais Apoio 15504-5:Dimensão de Processos • 48 processos que estão organizados em 3 categoria de processo e 10 grupos de processo. • Aquisição • Fornecimento • Engenharia • Operação • Gerência • Melhoria de Processo • Recursos e Infra-estrutura • Reuso • Controle de Configuração • Garantia da Qualidade

23. PROCESSOS ISO/IEC 15504-5:2006

24. 15504 - Níveis de Capacidade

26. Pontuação de Atributo de Processo • Um valor tem que ser atribuído a cada atributo de processo, baseado nos dados validados. • composta pelos seguintes quatro valores: • “N”: o atributo não foi atingido pelo processo (Null) ; • “P”: o atributo foi atingindo apenas parcialmente pelo processo (Parcial); • “L”: o atributo foi atingido largamente pelo processo (Large); e • “F”: o atributo foi atingido completamente (em inglês, fully) pelo processo. Para estar em um nível de capacidade, um processo tem que ter notas “L” ou “F” nos atributos do nível e “F” em todos os atributos dos níveis anteriores.

27. Exemplos de Pontuação de Atributos de Processo

28. Considerações Finais • Não pressupõe modelos de ciclo de vida de software, tecnologias de software ou metodologias de desenvolvimento. • O ISO/IEC 15504 não define um método explícito de avaliação, define os requisitos para o Método de Avaliação de Processos. • Na prática, uma avaliação de processos de software é conduzida utilizando o Modelo de Avaliação de Processos e não o Modelo de Referência de Processos.

29. MPS.BR

30. Qualidade em software via MPS.BR / Gerenciamento de Projetos Qualidade do produto de software É obtida por meio de Qualidade do processo de desenvolvimento de software É alcançada mais facilmente se baseada em Modelo de maturidade (MPS.BR) Tem como base Gerenciamento de projetos

31. MPS.BR • O MPS.BR é um programa para Melhoria de Processo de Software Brasileiro e está dividido em 3 componentes: • Modelo de Referência (MR-MPS) • Método de Avaliação (MA-MPS) • Modelo de Negócio (MN-MPS)

32. 5 4 3 2 A Em Otimização B Gerenciado Quantitativamente C Definido D Largamente Definido E Parcialmente Definido F Gerenciado G Parcialmente Gerenciado Relacionamento com o CMMI MR-MPS

33. MN-MPS: Modelo de Negócio II-MPS.BR & IA-MPS.BR Programa MPS.BR (SOFTEX) Convênio Contrato Contrato MNC MNE Convênio, se pertinente LEGENDA: II-MPS.BR – Instituição Implementadora do Modelo MPS.BR IA-MPS.BR – Instituição Avaliadora do Modelo MPS.BR MNE – Modelo de Negócio Específico para cada empresa (personalizado) MNC – Modelo de Negócio Cooperado em grupo de empresas (pacote)

34. Porque MPS.BR? • Acesso à melhoria de processos a pequenas e médias em empresas em larga escala. • Compatibilidade com os padrões de qualidade aceitos internacionalmente. • Caminho evolutivo mais suave e incremental que outros modelos.

35. Fluxo de Teste

36. OK OK Saque de um valor pré-definido Saque de um valor digitado Procedimento de teste OK OK OK Finalizar saque de valor pré-definido Finalizar saque de um valor digitado Caso e procedimento de teste em um Sistema ATM. O que é um Modelo de Teste? • Um modelo de teste consiste de: • Casos de teste • Procedimentos de teste • Um caso teste pode ser implementado por um ou mais procedimentos. • Um procedimento de teste • implementa (todo ou parte de) um ou mais casos de teste. • Use cases são a primeira entrada para identificar casos de teste. Caso de teste Caso de teste Iniciar saque

37. Projeto de Testes Plano de Testes Avaliação dos Testes Casos de Teste Procedimentos de Teste Componentes de Teste Log’s de Defeitos Artefatos do Fluxo de Testes

38. Programador Projetista de testes Testador de sistema Testador de integração responsável por responsável por responsável por responsável por Projeto de testes (casos e procedimentos) Avaliação dos testes Log de defeitos de sistema Log de defeitos de integração Subsistemas, Componentes, Classes, Pacotes e Scripts de teste Plano de testes Artefatos x Responsáveis no Fluxo Simplificado de Testes

39. Projetista de Testes Elaborar Plano de Testes Projetar Testes Avaliar Testes Executar Testes de Integração Testador de Integração Executar Testes de Sistema Testador de Sistema Implementar Testes Programador Visão Simplificada das atividades

40. Projetista de Testes Elaborar Plano de Testes Projetar Testes Avaliar Testes Executar Testes de Integração Testador de Integração Executar Testes de Sistema Testador de Sistema Implementar Testes Programador Visão das atividades

41. Projetista de Testes Elaborar Plano de Testes Projetar Testes Avaliar Testes Executar Testes de Integração Testador de Integração Executar Testes de Sistema Testador de Sistema Programador Visão das atividades Implementar Testes

42. Projetista de Testes Elaborar Plano de Testes Projetar Testes Avaliar Testes Executar Testes de Integração Testador de Integração Executar Testes de Sistema Testador de Sistema Programador Visão das atividades Implementar Testes

43. Projetista de Testes Elaborar Plano de Testes Projetar Testes Avaliar Testes Executar Testes de Integração Testador de Integração Executar Testes de Sistema Testador de Sistema Implementar Testes Programador Visão das atividades

44. Projetista de Testes Elaborar Plano de Testes Projetar Testes Avaliar Testes Executar Testes de Integração Testador de Integração Executar Testes de Sistema Testador de Sistema Implementar Testes Programador Visão das atividades

45. Avaliar testes: entrada x saída • Entrada: • Plano de testes • Projeto de testes • Saída: • Avaliação dos testes (opcional)

46. Avaliar testes: passos • Avaliar cobertura dos casos de teste • Verificar se os critérios de completude e sucesso dos testes foram atingidos

47. Padronização de Testes • Sistemático • Testes aleatórios não são suficientes • Testes devem cobrir todos os fluxos possíveis do software • Testes devem representar situações de uso reais • Documentado • Que testes foram feitos, resultados, etc. • Repetível • Se encontrou ou não erro em determinada situação, deve-se poder repeti-lo

48. Abordagens de teste • Abordagem funcional (“caixa preta”) • Os testes são gerados a partir de uma análise dos relacionamentos entre os dados de entrada e saída, com base nos requisitos levantados com os usuários • Especificação (pré e pós-condições) • Geralmente é aplicado durante as últimas etapas do processo de teste

49. Abordagens de teste • Abordagem funcional (“caixa preta”) • Objetivo • Erros associados a não satisfação da especificação • Erros na GUI • Erros nas estruturas de dados ou acesso ao banco de dados • Problemas de integração

50. Abordagens de teste • Abordagem estrutural (“caixa branca”) • Os testes são gerados a partir de uma análise dos caminhos lógicos possíveis de serem executados • Conhecimento do funcionamento interno dos componentes do software é usado