Qualidade de software aula de revis o
This presentation is the property of its rightful owner.
Sponsored Links
1 / 54

Qualidade de Software Aula de Revisão PowerPoint PPT Presentation


  • 49 Views
  • Uploaded on
  • Presentation posted in: General

Qualidade de Software Aula de Revisão. Prof. Guilherme Alexandre Monteiro Reinaldo Recife. Contatos. Prof. Guilherme Alexandre Monteiro Reinaldo Apelido: Alexandre Cordel E-mail/ gtalk : [email protected] Site: http://www.alexandrecordel.com.br/fbv Celular: (81) 9801-1878. SE

Download Presentation

Qualidade de Software Aula de Revisão

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Qualidade de software aula de revis o

Qualidade de SoftwareAula de Revisão

Prof. Guilherme Alexandre Monteiro Reinaldo

Recife


Contatos

Contatos

  • Prof. Guilherme Alexandre Monteiro Reinaldo

  • Apelido: Alexandre Cordel

  • E-mail/gtalk: [email protected]

  • Site: http://www.alexandrecordel.com.br/fbv

  • Celular: (81) 9801-1878


Motiva o

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


Motiva o1

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.


Modelos cmmi 1 3

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


Objetivos do cmmi

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.


Introdu o

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.


Por que duas representa es

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.


Comparando as representa es

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.


Dimens es para medi o da melhoria do processo

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


Exemplo meta espec fica e pr tica espec fica

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.


Exemplo meta gen rica e pr tica gen rica

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.


Estrutura do cmmi representa o cont nua

Á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


Estrutura do cmmi representa o por est gios

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


Equival ncia entre as representa es

Equivalência entre as Representações


Spice iso 15504

SPICE (ISO 15504)


Utiliza o da 15504

Utilização da 15504


Composi o da iso iec 15504

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


Modelo de processo da iso 15504

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.


Modelo de processo da iso 155041

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


15504 5 dimens o de processos

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


Qualidade de software aula de revis o

PROCESSOS

ISO/IEC 15504-5:2006


15504 n veis de capacidade

15504 - Níveis de Capacidade


Pontua o de atributo de processo

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.


Exemplos de pontua o de atributos de processo

Exemplos de Pontuação de Atributos de Processo


Considera es finais

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.


Mps br

MPS.BR


Qualidade em software via mps br gerenciamento de projetos

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


Mps br1

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)


Qualidade de software aula de revis o

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


Mn mps modelo de neg cio

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)


Porque mps br

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.


Fluxo de teste

Fluxo de Teste


O que um modelo de teste

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


Artefatos do fluxo de testes

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


Qualidade de software aula de revis o

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


Vis o simplificada das atividades

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


Vis o das atividades

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


Vis o das atividades1

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


Vis o das atividades2

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


Vis o das atividades3

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


Vis o das atividades4

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


Avaliar testes entrada x sa da

Avaliar testes: entrada x saída

  • Entrada:

    • Plano de testes

    • Projeto de testes

  • Saída:

    • Avaliação dos testes (opcional)


Avaliar testes passos

Avaliar testes: passos

  • Avaliar cobertura dos casos de teste

  • Verificar se os critérios de completude e sucesso dos testes foram atingidos


Padroniza o de testes

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


Abordagens de teste

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


Abordagens de teste1

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


Abordagens de teste2

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


Abordagens de teste3

Abordagens de teste

  • Abordagem estrutural

    • Objetivo

      • Garantir que todos os caminhos independentes dentro de um módulo tenham sido exercitados pelo menos uma vez

      • Realizar todas as decisões lógicas para valores falsos e verdadeiros

      • Executar laços dentro dos valores limites

      • Executar as estruturas de dados internas


Est gios de teste

Estágios de Teste

  • Teste de Unidade

  • Teste de Aspectos OO

  • Teste de Integração

  • Teste de Sistema

  • Teste de Aceitação


Top down

Top-down

A

C

B

D

E

F

G

H

I

J

K

L


Bottom up

Bottom-up

A

C

B

D

E

F

G

H

I

J

K

L


  • Login