INF2922 Qualidade de Sistemas de Software Contemporâneos ... › ~kalinowski › INF2922 ›...

INF2922 Qualidade de Sistemas de Software Contemporâneos

Apresentação da Disciplina

Prof. Marcos Kalinowski | LES/DI/PUC-Rio

[email protected] | www.inf.puc-rio.br/~kalinowski | @prof_kalinowski

Apresentações

2019 2Marcos Kalinowski © LES/DI/PUC-Rio

• Marcos Kalinowski

– Professor da área de Engenharia de Software

– Principais áreas de atuação:

• Engenharia de Software Experimental

• Qualidade de Software

– Mais informações: http://www.inf.puc-rio.br/~kalinowski

• Quem são vocês?

– Experiência, interesses, ...

Objetivo

• Discutir o estado da prática e da arte a respeito de:

– Modelos e normas de qualidade do processo e do produto de

software

– Métodos, técnicas e ferramentas para o planejamento e

controle da qualidade de produtos de software

• No contexto de sistemas de software contemporâneos

3Marcos Kalinowski © LES/DI/PUC-Rio2019

Ementa

• Conceituação de qualidade de software

• Modelos e normas de qualidade do processo

• Modelos e normas de qualidade do produto

• Planejamento da qualidade do produto

– Objetivos e requisitos de qualidade

– Planejamento da verificação e validação


Ementa (cont.)

• Controle da qualidade do produto

– Fundamentos do controle da qualidade

– Avaliação e medição da qualidade do produto

– Revisões de software

– Análise estática

– Teste de software

– Análise causal e prevenção de defeitos

– Tópicos em robustez e confiabilidade


Ementa (cont.)

• Controle da qualidade de sistemas de software

contemporâneos

– Arquiteturas de microserviços

– Blockchain

– Deep learning

– Sistemas autônomos inteligentes

– Outros


Avaliação

• Grau Final = (Avaliação1 + Avaliação2) / 2

– Avaliação1 = Participação em aula e atividades práticas

– Avaliação2 = Apresentação dos tópicos de interesse

• Para ser aprovado o aluno deverá alcançar um Grau Final

igual ou maior do que 6.


Bibliografia

• Bibliografia básica:

– WAGNER, S.; "Software Product Quality Control". Springer, 1st Edition,

ISBN 978-3642385704. 2013.

• Bibliografia complementar:

– CMMI Institute, "CMMI Development V2.0".

– DELAMARO, M.E.; MALDONADO, J.C.; JINO, M.; "Introdução ao Teste

de Software". Elsevier Editora, 2a Edição, 2016.

– MYERS, G.; BADGETT, T.; THOMAS, T.; SANDLER, C.; "The Art of

Software Testing". Wiley, 3rd Edition, 2012.

– TIAN, J.; “Software Quality Engineering”, Wiley-Interscience, ISBN:

978-0471713456. 2005.

– SOFTEX; "Guias do MPS.BR (Guia Geral e Guias de Implementação do

Modelo MPS-SW)". Disponíveis gratuitamente online.

– Artigos científicos diversos.



Perguntas?


Motivação



Conteúdo enriquecido com material gentilmente cedido pelo Prof.

Aumento da qualidade do produto

Diminuição do retrabalho

Maior produtividade

Redução do tempo para atender o mercado

Maior competitividade

Maior precisão nas estimativas

Qualidade do processo (Expectativa)

Motivação para a Qualidade de Software

112019 Marcos Kalinowski © LES/DI/PUC-Rio

O interesse no processo de software está

baseado em duas premissas:

a qualidade de um produto de software é fortemente

dependente da qualidade do processo pelo qual ele é

construído e mantido

o processo de software pode ser definido, gerenciado, medido

e melhorado

Um processo definido está descrito em

detalhes de forma a poder ser usado de

forma consistente.



A implantação de um Programa de Qualidade

normalmente começa pela definição e

implantação de um processo de software

O processo de software deve estar

documentado, ser compreendido e seguido.



Características

ad hoc - improvisado

fortemente dependente dos profissionais

indisciplinado

Consequências (esperadas)

pouca produtividade

qualidade de difícil previsão

alto custo de manutenção

risco na adoção de novas tecnologias

...

Processo Imaturo


Características

processo conhecido por todos

apoio visível da alta administração

auditagem da fidelidade ao processo

medidas do produto e do processo

adoção disciplinada de tecnologias

Consequências (esperadas)

papéis e responsabilidades claramente definidos

acompanhamento da qualidade do produto e da

satisfação do cliente

expectativas para custos, cronograma,

funcionalidades e qualidade do produto é

usualmente alcançada

...

Processo Maduro


Pesquisa iMPS

• Pesquisa realizada anualmente para acompanhar e

evidenciar resultados de desempenho nas empresas de

software que adotaram o modelo MPS

• Disponível em http://www.softex.br/mpsbr/

16

Travassos, G.H., Kalinowski, M. “iMPS 2013: Evidências

Sobre o Desempenho das Empresas que Adotaram o

Modelo MPS-SW”. Campinas: SOFTEX, 2014 (ISBN: 978-

85-99334-75-1), 102p.


Resultados de Desempenho das Empresas que Adotaram o MPS-SW

• Tendência a obter:

– Maior satisfação dos seus clientes

– Maior produtividade

– Maior capacidade para tratar projetos grandes

– Retorno do investimento (ROI)

– Melhoras no custo e na qualidade


Resultados de Desempenho das Empresas que Adotaram o MPS-SW


– Maior satisfação dos seus clientes

– Maior produtividade


– Retorno do investimento (ROI)

– Melhoras no custo e na qualidade


Possíveis Ganhos na Evolução nos Níveis de Maturidade do MPS-SW


– Maior número de clientes

– Maior número de projetos

– Maior número de funcionários


– Maior precisão nas estimativas de prazo


Momento de Reflexão

• Investir na melhoria do processo garante a

qualidade do produto?



• Um estudo informal relacionando defeitos em testes de

aceitação com o nível de maturidade de empresas no CMMI-

Dev indicou tendência de melhora na qualidade do produto

(Wagner, 2013)

• Resultados da pesquisa iMPS indicam tendência similar para

o MPS-SW (Travassos e Kalinowski, 2014)

• mas ...


Foco na Qualidade do Produto

• Diversos fatores influenciam a qualidade do produto e ela

precisa ser avaliada e monitorada também diretamente.

(Wagner, 2013)

– Requisitos de qualidade de produtos devem ser definidos e seu

alcance monitorado ao longo da execução do projeto (Tian,

2005)

• definir precisamente o que é esperado

– Especificar!!!

• Qualidade do produto:

– Conjunto de características que devem ser alcançadas em

determinado grau para que o produto atenda às necessidades

de seus usuários (Rocha et al., 2001)


Que características?

• Norma ISO 25010 – Software Product Quality Model

– Sobrepõe a antiga série ISO 9126

– Possui 8 características de qualidade principais para produtos

de software e suas sub-características


Figura retirada de (Mendoza et al., 2019)

A Norma ISO 25010 em Contexto

• Normas SQuaRE (Software product QUality Requirements

and Evaluation)


Requisitos de

Qualidade2503n

Modelo de Qualidade

2501n

Gerenciamento da Qualidade

2500n

Medições2502n

Avaliação

2504n


• Como alcançar os requisitos de qualidade definidos?

– Definir precisamente o que é esperado

• Especificar (de forma testável)

– Desenvolver e manter o sistema de modo que contenha muito poucos

defeitos já desde o início

• Investir na prevenção de defeitos e aproximar-se o quanto for possível de

correto por construção

– ideal zero defeitos, por enquanto uma utopia

– Avaliar continuamente, desde a primeira especificação até a

descontinuação, a satisfação de:

• desejos e expectativas dos interessados (usuários)

• requisitos da interface humano computador

• requisitos funcionais

• requisitos não funcionais

• arquitetura e projeto

• corretude dos procedimentos (algoritmos)


Como Controlar a Qualidade de Software?

• Saber raciocinar sobre artefatos

• Ler e criticar construtivamente os diversos artefatos

– Revisões e inspeções, medição estática

• Testar de forma sistemática

– Formular casos de teste que testem algo relevante

• Automatizar os testes sempre que possível

• Utilizar testes como técnicas de apoio ao desenvolvimento

– Estabelecer uma estratégia de teste

– Ao especificar sempre perguntar: como posso testar isso?

• Utilizar instrumentos como mecanismos de apoio ao

desenvolvimento e de controle continuado da execução

– Técnicas formais leves

• Desenvolver visando manutenibilidade


Porque Utilizar Métodos de V&V?

• A utilização destes métodos na indústria têm mostrado resultados

positivos considerando tanto produtividade quanto qualidade

• Resultados de estudos experimentais evidenciam benefícios da

utilização destes métodos no desenvolvimento de software

• Diversas evidências relacionadas a V&V foram obtidas ao longo dos

anos de pesquisa em engenharia de software


Curiosidades

• O desenvolvimento de programas de boa qualidade sob a ótica da

programação modular, provê um dos alicerces para desenvolver

software correto por construção (von Staa, 2000)

• Prevenção de defeitos é usualmente mais eficaz que a remoção de

defeitos (Mays, 1990) (Kalinowski et al., 2012)

• Qualidade do processo tende a melhorar a produtividade

(Travassos e Kalinowski, 2014)

• Inspeções aumentam significativamente a produtividade,

qualidade e estabilidade dos projetos (Fagan, 1976)

• Inspeções e Testes encontram diferentes tipos de defeitos (Hetzel,

1976 & Meyer, 1978)

• Testes podem revelar a presença, mas não a ausência de defeitos

(Dijkstra, 1970)


Curiosidades

• Um desenvolvedor não é indicado para testar seu próprio software

(Weinberg, 1971)

• Aproximadamente 80% dos defeitos são provenientes de 20% dos

módulos (Pareto, 1897) (Endres, 1975)

• Usabilidade é quantificável (Nielsen, 1994)

• Corrigir um defeito após a entrega do produto é frequentemente

100 vezes mais caro do que corrigi-lo durante as atividades de

requisitos e projeto do sistema (Boehm, Basili, 2001)



Qualidade de Processos




Ciclo: Definição, Uso, Medição, Controle e Melhoria do Processo

33

Executar o

Processo

Definir o

Processo

Medir o

Processo

Melhorar o

Processo

Controlar o

Processo


Definição do Processo

• Razões para a definição de processos de Engenharia de

Software:

– facilitar o entendimento e a comunicação entre pessoas

– apoiar a melhoria dos processos

– apoiar a gerência dos processos

– fornecer apoio automatizado guiando no processo

– fornecer apoio na execução automatizada do processo


35

Executar o

Processo

Definir o

Processo

Medir o

Processo

Melhorar o

Processo

Controlar o

Processo



Medição do Processo (Abordagens)

• Metodologia para medição do processo (GQM & PSM)

• Paradigmas para medição do processo

– Paradigma analítico

baseia-se em evidência quantitativa para determinar onde as melhorias

são necessárias e se as iniciativas de melhoria foram bem sucedidas

• estudos experimentais

• simulação

• classificação de defeitos (falhas causas)

• controle estatístico do processo

– Benchmarking

envolve medir a maturidade de uma organização ou a capacidade de

seus processos

• Normas e modelos para apoiar a avaliação de processos: ISO 9001,

MPS-SW, CMMI, ISO/IEC 33020, ISO/IEC 12207, ISO/IEC 29110

• Métodos para avaliação de processos : Benchmark appraisals,

sustainment appraisals e evaluation appraisals (substituindo as antigas

avaliações SCAMPI A, B e C) para avaliações baseadas no CMMI-Dev,

MA-MPS para avaliações baseadas no MPS-SW


37

Executar o

Processo

Definir o

Processo

Medir o

Processo

Melhorar o

Processo

Controlar o

Processo



Controle do Processo

• Manter o processo dentro dos seus limites normais de desempenho

• O processo deve se comportar de forma consistente

• Controlar o processo envolve:– Medir o processo– Detectar variações no processo decorrentes de causas

atribuíveis– Corrigir variações no processo através da remoção de causas

atribuíveis


39

Executar o

Processo

Definir o

Processo

Medir o

Processo

Melhorar o

Processo

Controlar o

Processo



Melhoria do Processo

• Processos podem e devem ser melhorados continuamente.

• Melhorar o processo envolve:

– Entender as características dos processos existentes e os

fatores que afetam a capacidade do processo

– Planejar e implementar ações que modifiquem o processo

para atender melhor as necessidades de negócio

– Avaliar os impactos e benefícios

40

Análise Causal para

Melhoria ContínuaInovação / Experimentação


Modelos de Qualidade do Processo

• CMMI-Dev (versão atual 2.0, liberada em Março de 2018)

• MPS-SW (versão atual 2016, liberada em Janeiro de 2016)


CMMI-Dev: Conceitos Fundamentais

• Organizado em Áreas de Processo (Prática)

• As áreas de processo possuem:

– Propósito

– Objetivos Específicos

– Práticas

• Além disso existem Objetivos Genéricos que podem ser

aplicados a todas as área de processo


Exemplo: Área de Processo ‘Verificação’


Representações

• Em estágios (staged)

– Perspectiva de maturidade da organização.

– Enfatiza conjuntos de áreas de processo que definem estágios

de maturidade do processo.

• Contínua (continuous)

– Perspectiva de capacidade das áreas de processo.

– Mede resultados em cada área individualmente.


Processo Realizado

Práticas Genéricas

Nível 2

Processo GerenciadoProcesso Gerenciado


Nível 3

Processo DefinidoProcesso Definido


Nível 4

Processo Gerenciado

Quantitativamente

Processo Gerenciado

Quantitativamente


Nível 5

Processo em Otimização

Capacid

ade

45

Áreas de Processo agrupadas em Estágios

• Nível de Maturidade 2

– Gerência de Requisitos

– Planejamento do Projeto

– Monitoração e Controle do Projeto

– Gerência de Acordos com Fornecedores

– Medição e Análise

– Garantia da Qualidade do Processo e do Produto

– Gerência de Configuração



– Desenvolvimento de Requisitos

– Solução Técnica

– Integração do Produto

– Verificação

– Validação

– Foco no Processo Organizacional

– Definição do Processo Organizacional

– Treinamento Organizacional

– Gerência de Projeto Integrada

– Gerência de Riscos

– Integração da Equipe

– Análise de Decisão e Resolução

– Ambiente Organizacional para Integração

47




– Desempenho do Processo Organizacional

– Gerência Quantitativa do Projeto


– Inovação e Implantação Organizacional

– Análise e Resolução de Causas

48



Níveis de Maturidade em Estágios

49

Gerenciado

Definido

Gerenciado

Quantitativamente

Em Otimização

1Processo imprevisível,

pobremente controlado e

reativo

2Processo caracterizado para

projetos e muitas vezes

reativo

3Processo caracterizado para

a organização e proativo

4Processo medido e

controlado

5Foco na melhoria do

processo

Inicial


MPS.BR

Realidade das Empresas Brasileiras

ISO /IEC 12207

ISO /IEC 15504

CMMI

SOFTEX

Governo

Universidades

Base Técnica

Programa MPS.BR


Organização do Programa MPS.BR

51

SOFTEX

Equipe Técnica do

Modelo

(ETM)

Fórum de Credenciamento e Controle(FCC)

Coordenação do Programa MPS.BR(SOFTEX)

Comissão de Ética do

Programa

(CEP)


Equipe Técnica do Modelo (ETM)

• Equipe responsável pela definição e aprimoramento do:

– MR-MPS-SW, MR-MPS-SV e MA-MPS e guias específicos

– Programa anual de treinamento MPS.BR

– Cursos, provas e workshops


Estrutura do Modelo MPS


Adoção e Disseminação do MPS-SW


Descrição dos modelos

• O modelo é descrito nos guias do MPS.BR

• Os guias gerais possuem os requisitos que devem ser

atendidos durante a implantação dos modelos

• Os guias de implementação são orientativos

• Todos os guias estão disponíveis em

http://www.softex.br/mpsbr


Guia Geral MPS de Software

56

Referências

Básicas ISO/IEC 12207:2008 e ISO/IEC 15504

Complementar CMMI-DEV

Objetivo

Descrever de forma detalhada o Modelo MPS e detalha MR-MPS-SW.

Também contém algumas definições comuns aos diversos

documentos do MPS.BR

Público alvo

• Instituições interessadas em aplicar o MR-MPS-SW para melhoria

de seus processos de software

• Instituições implementadoras e avaliadoras segundo o MR-MPS-SW


Guia de Implementação

57

Referências

• Básicas Guia Geral MPS de Software/Serviços

• Complementar diversas

Objetivo

Fornecer orientações para implementar nas organizações os níveis de

maturidade descritos nos Modelos de Referência MR-MPS-SW/MR-MPS-SV,

detalhando os processos contemplados nos respectivos níveis de maturidade

e os resultados esperados com a implementação dos processos

Público-Alvo

• Instituições interessadas em aplicar o MR-MPS-SW/MR-MPS-SV para

melhoria de seus processos de software

• Instituições implementadoras e avaliadoras segundo o MR-MPS-SW/MR-

MPS-SV


Estrutura do MPS-SW

58

Níveis de maturidade

Capacidade

Resultado

Processo

Propósito Atributo


Gerenciado Quantitativamente

Parcialmente

Gerenciado

Gerenciado

Parcialmente

Definido

Largamente

Definido

Definido

Em Otimização

Níveis de Maturidade MPS-SW

59

Medição - MED / Gerência de Configuração - GCOAquisição - AQU / Garantia da Qualidade - GQAGerência de Portfólio de Projetos - GPP

Avaliação e Melhoria do Processo Organizacional - AMPDefinição do Processo Organizacional - DFPGerência de Reutilização - GRUGerência de Recursos Humanos - GRHGerência de Projetos - GPR (evolução)

Desenvolvimento de Requisitos - DREProjeto e Construção do Produto - PCPIntegração do Produto - ITPVerificação - VER / Validação - VAL

Gerência de Decisões - GDEDesenvolvimento para Reutilização - DRUGerência de Riscos - GRI

G

F

E

D

C

Gerência de Requisitos - GRE

Gerência de Projetos - GPR

A

BGerência de Projetos - GPR (evolução)

(sem processo específico)


60

CAPACIDADE

PROCESSOS

Nível Processos Capacidades (AP)

A (sem processos adicionais) 1.1, 2.1, 2.2, 3.1,3.2, 4.1*, 4.2*, 5.1*,5.2*

B Gerência de Projetos (evolução) 1.1, 2.1, 2.2, 3.1,3.2, 4.1*, 4.2*

C Gerência de Riscos, Desenvolvimento paraReutilização, Gerência de Decisões

1.1, 2.1, 2.2, 3.1, 3.2

D Desenvolvimento de Requisitos, Integração doProduto, Projeto e Construção do Produto, Validação,Verificação

1.1, 2.1, 2.2, 3.1, 3.2

E Avaliação e Melhoria do Processo Organizacional,Gerência de Projetos (evolução), Gerência deRecursos Humanos, Gerência de Reutilização,Definição do Processo Organizacional

1.1, 2.1, 2.2, 3.1, 3.2

F Aquisição, Garantia da Qualidade, Gerência deConfiguração, Gerência de Portfólio de Projetos,Medição

1.1, 2.1, 2.2

G Gerência de Projetos, Gerência de Requisitos 1.1, 2.1

* Estes APs capacitam apenas um conjunto de processos selecionado pelaorganização de acordo com seus objetivos de melhoria. Os demais APsprecisam capacitar todos os processos do nível pretendido.

Entendendo os Atributos de Processo (Capacidade)

• AP 1.1 O processo é executado

– Este atributo é uma medida do quanto o processo atinge o seu

propósito.

• AP 2.1 O processo é gerenciado

– Este atributo é uma medida do quanto a execução do processo

é gerenciada.

• AP 2.2 Os produtos de trabalho do processo são

gerenciados

– Este atributo é uma medida do quanto os produtos de trabalho

produzidos pelo processo são gerenciados apropriadamente.



• AP 3.1. O processo é definido

– Este atributo é uma medida do quanto um processo padrão é

mantido para apoiar a implementação do processo definido.

• AP 3.2 O processo está implementado

– Este atributo é uma medida do quanto o processo padrão é

efetivamente implementado como um processo definido para

atingir seus resultados.



• AP 4.1 O processo é medido

– Este atributo é uma medida do quanto os resultados de

medição são usados para assegurar que o desempenho do

processo apóia o alcance dos objetivos de desempenho

relevantes como apoio aos objetivos de negócio definidos.

• AP 4.2 O processo é controlado

– Este atributo é uma medida do quanto o processo é controlado

estatisticamente para produzir um processo estável, capaz e

previsível dentro de limites estabelecidos.



• AP 5.1 O processo é objeto de inovações

– Este atributo é uma medida do quanto as mudanças no

processo são identificadas a partir da análise de causas comuns

de variação do desempenho e da investigação de enfoques

inovadores para a definição e implementação do processo.

• AP 5.2 O processo é otimizado continuamente

– Este atributo é uma medida do quanto as mudanças na

definição, gerência e desempenho do processo têm impacto

efetivo para o alcance dos objetivos relevantes de melhoria do

processo.


65

CAPACIDADE

PROCESSOS

Nível Processos Capacidades (AP)

A (sem processos adicionais) 1.1, 2.1, 2.2, 3.1,3.2, 4.1*, 4.2*, 5.1*,5.2*

B Gerência de Projetos (evolução) 1.1, 2.1, 2.2, 3.1,3.2, 4.1*, 4.2*

C Gerência de Riscos, Desenvolvimento paraReutilização, Gerência de Decisões

1.1, 2.1, 2.2, 3.1, 3.2

D Desenvolvimento de Requisitos, Integração doProduto, Projeto e Construção do Produto, Validação,Verificação

1.1, 2.1, 2.2, 3.1, 3.2

E Avaliação e Melhoria do Processo Organizacional,Gerência de Projetos (evolução), Gerência deRecursos Humanos, Gerência de Reutilização,Definição do Processo Organizacional

1.1, 2.1, 2.2, 3.1, 3.2

F Aquisição, Garantia da Qualidade, Gerência deConfiguração, Gerência de Portfólio de Projetos,Medição

1.1, 2.1, 2.2

G Gerência de Projetos, Gerência de Requisitos 1.1, 2.1

* Estes APs capacitam apenas um conjunto de processos selecionado pelaorganização de acordo com seus objetivos de melhoria. Os demais APsprecisam capacitar todos os processos do nível pretendido.

Processo de Software

• Abordagens de Melhoria de Processos

– O paradigma benchmarking

– Paradigma analítico (analisar resultados do processo)



• Abordagens de Melhoria de Processos

– CMMI Level 5 (Melhoria Contínua)

• Causal Analysis and Resolution (CAR)

– Análise Causal

• Organizational Innovation and Deployment (OID)

– Experimentação



• Melhoria de Processos e Experimentação Contínua

68Marcos Kalinowski © LES/DI/PUC-Rio

Fagerholm, F., Guinea, A. S., Mäenpää, H., & Münch, J. (2017). The RIGHT model for continuous

experimentation. Journal of Systems and Software, 123, 292-305.

Análise Causal

Experimentação

2019

Reflexão


Ênfase em melhoria e inovação no final?

Benchmarking de práticas não necessariamente

relacionadas com os objetivos da organização e os

resultados concretos do processo?

2019


• Visões

– Visão 1: Análise causal deve ser aplicada sempre, desde o início de

esforços de melhora (redução da taxa de defeitos: 50%)

• Força motriz da melhoria continua de processos

– Visão 2: Experimentação contínua deve ser aplicada sempre, desde o

início de esforços de melhoria (adoção de tecnologia com base em

resultados de hipóteses localmente testadas)

• Força motriz da inovação de processos

– Visão 3: Benchmarking deveria enfatizar abordagens enxutas (lean)

construídas com base em análise causal e experimentação!

• Foco na melhoria efetiva dos resultados


Kalinowski, M., Card, D.N. and Travassos, G.H., 2012. Evidence-based guidelines to defect

causal analysis. IEEE software, 29(4), pp.16-18.

2019


• Precisamos de novas abordagens e de novos modelos de

referência

– Inovação 1: Lean causal analysis and experimentation

based software process improvement approach

• Estágio atual: concepção e estudos de caso na indústria

– Inovação 2: Lean causal-analysis and experimentation

based software reference model

• Base para a definição de processos enxutos e ágeis, focados em

resultados


Análise Causal

Experimentação

2019


• Como funciona na prática?

– 1: Uma infraestrutura de básica de medição é elaborada

• Objetivo: prover transparência das informações de desempenho do processo

(e.g., qualidade, cronograma, custo e produtividade)

• Plano de medição, planilha de medição, status report

– 2: Inspeções de requisitos e testes são introduzidos

• Objetivo: melhorar a qualidade do produto e prover dados para análise

causal de defeitos e experimentação

– 3: Análise causal e experimentação são introduzidos

• Objetivo: funcionar como força motriz de melhoria contínua e inovação do

processo

• Processo se mantém enxuto e focado em resultados


Fitzgerald, B., & Stol, K. J. (2017). Continuous software engineering: A roadmap and agenda. Journal of

Systems and Software, 123, 176-189.2019


• Como funciona na prática?


Definition of Ready após inspeções (e aprovação do cliente)

Análise Causal após a identificação de defeitos e falhas:

2019

Status Report


Acompanhamento do Gerente

• Variação das métricas chave ao longo dos sprints

• Avaliação das melhorias de processo

• Teste de hipótese após a introdução de inovações no

processo


“It is not necessary to change. Survival is not

mandatory”

W. Edwards Deming


Referências

77

• CMMI Institute, “CMMI Development V2.0”. Disponível em www.cmmiinstitute.com

• SOFTEX, "Guias do MPS.BR (Guia Geral e Guias de Implementação do Modelo MPS-SW)". Disponíveis

em www.softex.br/mpsbr

• FITZGERALD, B., STOL, K. J., “Continuous software engineering: A roadmap and

agenda”. Journal of Systems and Software, 123, pp. 176-189, 2017.

• KALINOWSKI, M., WEBER, K.C., SANTOS, G., FRANCO, N., DUARTE, V., TRAVASSOS, G., “Software

Process Improvement Results in Brazil Based on the MPS-SW Model”. Software Quality

Professional Journal, v. 14, no. 4, pp. 15-23, 2015.

• KALINOWSKI, M., WEBER, K.C., FRANCO, N., BARROSO, E., DUARTE, V., ZANETTI, D., SANTOS, G.

“Results of 10 Years of Software Process Improvement in Brazil Based on the MPS-SW

Model”. In: International Conference on the Quality of Information and Communications Technology

(QUATIC), 2014, Guimarães, Portugal.

• KALINOWSKI, M., BIFFL, S., SPÍNOLA, R., REINEHR, S. “From project-oriented to service-oriented

software development: an industrial experience guided by a service reference model”. Journal

of Software Engineering Research and Development, v.2, p. 1-21, 2014.

• TRAVASSOS, G.H., KALINOWSKI, M. “iMPS 2013: Evidências Sobre o Desempenho das Empresas

que Adotaram o Modelo MPS-SW”. Campinas: SOFTEX (ISBN: 978-85-99334-75-1), 102p, 2014.

• Kalinowski, M., Card, D.N. and Travassos, G.H., “Evidence-based guidelines to defect causal

analysis”. IEEE software, v. 29, no. 4, pp.16-18, 2012.


Leitura Requerida

• WAGNER, S.; "Software Product Quality Control". Springer,

1st Edition, ISBN 978-3642385704. 2013.

– Capítulo 1

– Capítulo 2, até Seção 2.3 (inclusive)



Qualidade do Produto




Motivação

• Investir na melhoria do processo garante a qualidade do

produto?



• Um estudo informal relacionando defeitos em testes de

aceitação com o nível de maturidade de empresas no CMMI-

Dev indicou tendência de melhora na qualidade do produto

(Wagner, 2013)

• Resultados da pesquisa iMPS indicam tendência similar para

o MPS-SW (Travassos e Kalinowski, 2014)

• mas ...



• Diversos fatores influenciam a qualidade do produto e ela

precisa ser avaliada e monitorada também diretamente.

(Wagner, 2013)

– Requisitos de qualidade de produtos devem ser definidos e seu

alcance monitorado ao longo da execução do projeto (Tian,

2005)

• definir precisamente o que é esperado

– Especificar!!!

• Qualidade do produto:

– Conjunto de características que devem ser alcançadas em

determinado grau para que o produto atenda às necessidades

de seus usuários (Rocha et al., 2001)


Que características?

• Norma ISO 25010 – Software Product Quality Model

– Sobrepõe a antiga série ISO 9126

– Possui 8 características de qualidade principais para produtos

de software e suas subcaracterísticas


Figura retirada de (Mendoza et al., 2019)

Características da ISO 25010


ISO/IEC (2011)

Norma ISO 25010


Modelo de qualidade do produto da ISO/IEC 25010 (ISO/IEC, 2011)

Norma ISO 25010


Modelo de qualidade em uso da ISO/IEC 25010 (ISO/IEC, 2011)

A Norma ISO 25010 em Contexto

• Normas SQuaRE (Software product QUality Requirements

and Evaluation)


Requisitos de

Qualidade2503n

Modelo de Qualidade

2501n


2500n

Medições2502n

Avaliação

2504n

QPS (Modelo de Referência para Avaliação de Produtos de Software)

• Considera quatro dimensões: Engenharia de Software,

Serviço, Qualidade do Produto e Organizacional

• Apresenta resultados em três níveis de atendimento da

qualidade: Bronze, Prata e Ouro

• Rocha et al. (2018) descrevem resultados iniciais de sua

implementação e avaliação em organizações Brasileiras


QPS (Modelo de Referência para Avaliação de Produtos de Software)


Modelo QPS para Avaliação de Produtos de Software e sua relação com

Normas Internacionais (Rocha et al., 2018)


QPS – Dimensão Organizacional

(Rocha et al., 2018)


QPS – Dimensão Engenharia de Software



QPS – Dimensão de Serviços



QPS – Dimensão de Qualidade do Produto


Garantia e Controle da Qualidade de Produtos

• Garantia da Qualidade

– Tem como propósito assegurar que os produtos de trabalho e a

execução dos processos estejam em conformidade com os

planos, procedimentos e padrões estabelecidos.

• Controle da Qualidade

– Verificação e Validação.


Verificação e Validação

• Verificação

– Tem como propósito confirmar que cada serviço e/ou

produto de trabalho do processo ou do projeto atende

apropriadamente os requisitos especificados.

• Estamos construindo certo o produto? (Boehm, 1981)

• Validação

– Tem como propósito confirmar que um produto ou

componente do produto atenderá a seu uso pretendido

quando colocado no ambiente para o qual foi

desenvolvido.

• Estamos construindo o produto certo? (Boehm, 1981)


Exercício de Fixação: Associe as Colunas

• Análise Estática

• Testes Unidade

• Testes de Integração

• Testes de Sistema

• Testes de Aceitação

• Revisões de Software


Verificação

Validação



• Testes Unidade






Verificação

Validação


• Boehm, B.W., Software Engineering Economics. Prentice-hall, 1981.

• ISO/IEC, ISO 25000 Software Product Quality - ISO/IEC 25010.

http://iso25000.com/index.php/en/iso-25000-standards/iso-25010, Official site

(2011).

• Mendoza, I., Kalinowski, M., Souza, U., and Felderer, M., Relating Verification and

Validation Methods to Software Product Quality Characteristics: Results of an

Expert Survey. In Software Quality Days, 11th International Conference, SWQD

2019, Vienna, Austria, January 15-18, 2019.

• Rocha, A.R.C., Travassos, G.H., Santos, G., Reinehr, S., QPS - Modelo para

Avaliação da Qualidade de Produtos de Software: Resultados

Iniciais. Simpósio Brasileiro de Qualidade de Software, 2018.

• Rocha, A.R.C., Maldonado, J.C. and Weber, K.C., Qualidade de software: teoria e

prática. São Paulo: Prentice-hall, 2001.

• Travassos, G.H., Kalinowski, M., iMPS 2013: Evidências Sobre o Desempenho das

Empresas que Adotaram o Modelo MPS-SW. Campinas: SOFTEX, 2014 (ISBN:

978-85-99334-75-1), 102p.

• Wagner, S., Software Product Quality Control. Springer, 2013.

Referências

Leitura Requerida

• WAGNER, S.; "Software Product Quality Control". Springer,

1st Edition, ISBN 978-3642385704. 2013.

– Capítulo 3

– Capítulo 4



Gerência da Qualidade de Software




• Gerência da Qualidade (ISO 25001)

– Propósito: Gerência da qualidade de produtos com base em

requisitos de qualidade e avaliação (Wagner, 2013)

– Diretamente alinhada com as definições de Tian (2005) e

Wagner (2013)

• Ênfase na medição das atividades de garantia da qualidade,

verificação e validação



• Qualidade no nível tático e operacional


Gerência da Qualidade

Garantia da Qualidade

Verificação Validação

• Gerenciamento da qualidade envolve (Tian, 2005):

– Definir objetivos específicos de qualidade

– Planejar uma estratégia de qualidade

• Selecionar métodos apropriados de garantia da qualidade,

verificação e validação (V&V)

• Selecionar medidas apropriadas para permitir a avaliação da

qualidade

– Avaliar e controlar a qualidade

• Esta abordagem é consistente com a apresentada por

Wagner (2013), que envolve as seguintes atividades:

– Identificar objetivos; Selecionar e integrar métodos de V&V;

Acompanhar problemas; Monitorar atividades de V&V; Avaliar e

controlar a qualidade



SQuaRE (Software product QUalityRequirements and Evaluation)

• Medidas objetivas referentes à garantia e o controle da qualidade formam

a base para uma gerência da qualidade efetiva (Tian, 2005)


Requisitos de

Qualidade2503n

Modelo de Qualidade

2501n


2500n

Medições2502n

Avaliação

2504n


• Avalia a conformidade do processo e do produto

– Visa assegurar que os processos planejados foram

implementados e que os produtos seguem os padrões pré-

estabelecidos

– Quando não-conformidades são identificadas, elas devem ser

tratadas e resolvidas no projeto

– Caso não sejam resolvidas no projeto, devem ser escalonadas

para o nível adequado de gerência



• É fundamental que as avaliações sejam objetivas

– A objetividade é crítica para o sucesso do projeto

– A objetividade é conseguida com:

• O avaliador sendo independente do projeto (externo ao projeto)

• A utilização de um conjunto de critérios de avaliação



• Recorte de um checklist de garantia da qualidade


Exercício

• Cite três exemplos de medidas que podem ser utilizadas

para monitorar o processo de garantia da qualidade


Gerência da Garantia da Qualidade

• Exemplos de medidas para gerir o processo de garantia da

qualidade (Rocha et al., 2012):

– Taxa de não conformidades (NCs) em avaliações de qualidade

no documento X (por exemplo, documento de requisitos)

– Taxa de NCs em avaliações de aderência ao processo X (por

exemplo, gerência de requisitos)

– Esforço de retrabalho para corrigir NCs identificadas em

avaliações de qualidade

– Taxa de NCs escalonadas

– Taxa de NCs escalonadas sem resolução

– Número de NCs identificadas na auditoria independente de

qualidade


Verificação

• Avalia se o produto definido reflete adequadamente os

requisitos especificados (incluindo requisitos do cliente,

produto e componentes do produto):

– Estamos construindo certo o produto?

• Principais métodos: Revisões e Testes


• Definição: Processo ou atividade para leitura de um

artefato de software visando assegurar que ele cumpre sua

especificação e atende às necessidades de seus usuários

– Validação e verificação estática de artefatos de software

– Proveem um bom meio para o gerente monitorar a qualidade

do projeto

• Tipos de Revisão de Software:

– Revisão aos Pares

– Inspeções de Software

– Walkthroughs

Revisões de Software


Revisões de Software

• Quando e em que tipos de artefato aplicar revisões de

software?

•

Adaptado de Ackerman et al. (1989)

• Um relato simples e compreensível da aplicação de

inspeções de requisitos em desenvolvimento incremental

pode ser encontrado em Kalinowski et al. (2007)


Revisão

Teste de Software


Unidade

IntegraçãoPerspectiva dos Projetistas e Desenvolvedores

Sistema

Aceitação

Perspectiva dos Clientes e Usuários

Teste de Sistema

• Objetivo:

– Executar o sistema sob ponto de vista de seu usuário final,

varrendo as funcionalidades em busca de falhas

• Testes executados em condições similares àquelas que um

usuário utilizará no seu dia-a-dia

• Um sistema divide-se em características:

– Funcionais

– Não-Funcionais


Sistema = Funcional + Não-Funcional

Teste de Sistema

• Exemplos de tipos específicos de Teste de Sistema:

– Recuperação

• Força o software a falhar numa variedade de situações e verifica a

capacidade de recuperação do produto

– Segurança

• Verifica se os mecanismos de proteção construídos para o sistema

irão de fato protegê-lo de alguma utilização ou intrusão imprópria.

– Stress

• Executa o sistema de forma a exigir recursos em quantidade,

frequência ou volume anormais

– Desempenho

• Avalia o desempenho do software quando integrado ao sistema.

Normalmente está associado ao teste de stress


Exercício


para monitorar o processo de verificação


Gerência da Verificação

• Exemplos de medidas para gerir o processo de verificação

(Rocha et al., 2012):

– Densidade de defeitos identificados em revisões por pares

– Esforço para a realização de revisões por pares

– Densidade de defeitos identificados nos testes de software

– Esforço para a realização de testes

– Esforço de retrabalho para a correção de defeitos

– Taxa de defeitos corrigidos

– Taxa de cobertura de funcionalidades dos testes

– Densidade de defeitos identificados após o software entrar em

produção

– Esforço de retrabalho para a correção de defeitos de produção

– Tempo médio entre falhas

– Tempo médio para a correção de um defeito


Validação

• Avalia se o produto atende às necessidades de seus

usuários

– Estamos construindo o produto certo?

• Normalmente envolve o usuário final e demais interessados

• Principais métodos: Revisões e Testes


Validação

• Similaridades e Diferenças com Verificação

– Similaridades:

• Usa abordagens semelhantes (testes, inspeções, demonstrações e

simulações)

– Diferenças:

• Necessidade de avaliar no ambiente de uso (operacional) do

sistema ou em ambiente simulado

• Requer a participação do usuário final e demais interessados

• Na validação, a preocupação é garantir que o produto atende ao

uso esperado, enquanto que na verificação, é garantir que atende

os requisitos especificados


Exercício


para monitorar o processo de validação


Gerência da Validação

• Exemplos de medidas para gerir o processo de validação

(Rocha et al., 2012):

– Densidade de defeitos identificados em avaliação de requisitos

– Esforço de retrabalho para correção de defeitos nos requisitos

– Densidade de defeitos identificados nos testes de homologação

– Esforço de retrabalho para a correção de defeitos em testes de

homologação








Lembrando: É fundamental alinhar os métodos de V&V e as medidas com os requisitos de qualidade do produto!



Monitorando Introdução & Detecção

0

0,5

1

1,5

2,0

2,5

3,0

Requirements Design Implementation Integration AcceptanceTesting

Fielded

Estimado

Introdução

Detecção

Real

Introdução

Detecção

Def

eito

s p

or

Un

idad

e d

e T

aman

ho

Gerência da Qualidade e Alta Maturidade

• Nos altos níveis de maturidade a gerência passa a ter um

enfoque quantitativo (SOFTEX, 2012)

– No MPS-SW nível B a gerência quantitativa deve compreender

processos críticos para os alcances dos objetivos

organizacionais

– No CMMI-Dev nível 4 a gerência quantitativa deve se basear

em requisitos de qualidade e desempenho

• Faz uso de ferramentas estatísticas, como gráficos de

controle

• Permite a elaboração de modelos de desempenho para

processos estáveis



• Gráficos de Controle

• Modelos de Desempenho


ProblemasAPNormalizado = 0,0502 + 2,55 ProblemasGQNormalizado

Gráfico e modelo de desempenho extraídos de Montoni et al. (2007)

Observation

In

div

idu

al

Va

lue

161412108642

-2

-3

-4

-5

-6

_X=-3,801

UC L=-1,652

LC L=-5,950

Observation

Mo

vin

g R

an

ge

161412108642

3

2

1

0

__MR=0,808

UC L=2,640

LC L=0

I-MR Chart of ln(ProblemasGQNormalizado)


• Gráficos de controle podem ser utilizados como ferramenta

gerencial mesmo que não se tenha ainda processos

estabilizados

• Os gráficos mais indicados para dados de defeitos são os U-

charts (Kalinowski et al., 2012)

– Distribuição de Poisson

• Pontos fora de controle possuem causas atribuíveis e devem

ser alvo de análise causal visando estabilizar o processo

• No MPS-SW nível A e CMMI-Dev nível 5 análise causal de

defeitos deve ser aplicada visando melhoria contínua e não

apenas estabilizar o processo


Gerência da Qualidade: Quem Faz?

• Em empresas menores comumente a gerência da qualidade

é realizada pelo próprio gerente do projeto

• Para empresas maiores é possível que se tenha um gerente

dedicado exclusivamente à qualidade, com uma equipe que

atende a diversos projetos

– Célula de Testes

– Fábrica de Testes


Exercício

• Qual a tendência apresentada neste gráfico de controle do

tipo U-chart? Este comportamento é positivo?


Gráfico extraído de Kalinowski et al. (2014)

Resposta

• Não é possível responder à pergunta somente com a

informação apresentada (falta informação do esforço

investido na detecção de defeitos)


Gráficos extraído de Kalinowski et al. (2014)

Considerações Finais

• Para uma Gerência da Qualidade efetiva:

– Estabeleça requisitos de qualidade para o produto

– Institucionalize garantia da qualidade

– Institucionalize inspeções de software

– Institucionalize testes

– Realize medições sobre as atividades de garantia e controle da

qualidade considerando os requisitos de qualidade do produto

– Utilize resultados de medições para subsidiar decisões

– O uso de gráficos de controle e análise causal de defeitos não

requer alta maturidade


Referências

• Mendoza, I., Kalinowski, M., Souza, U., Felderer, M., Relating Verification and Validation

Methods to Software Product Quality Characteristics: Results of an Expert Survey.

In Software Quality Days, 11th International Conference, SWQD 2019, Vienna, Austria,

January 15-18, 2019.

• Kalinowski, M., Mendes, E., Travassos, G.H., An Industry Ready Defect Causal Analysis

Approach Exploring Bayesian Networks. Software Quality Days, 6th International

Conference, Lecture Notes in Business Information Processing, v. 166, p. 12-33, 2014.

• Kalinowski, M., Card, D.N., Travassos, G.H., Evidence-Based Guidelines to Defect

Causal Analysis. IEEE Software, vol. 29, no. 4, pp. 16-18, 2012.

• Kalinowski, M., Spínola, R. O., Dias-Neto, A. C., Bott, A., Travassos, G. H., Inspeções de

Requisitos de Software em Desenvolvimento Incremental: Uma Experiência

Prática. Simpósio Brasileiro de Qualidade de Software, 2007.

• Montoni, M., Kalinowski, M., Lupo, P., Abrantes, J. F., Ferreira, A.I.F., Rocha, A.R.C., Uma

Metodologia para Desenvolvimento de Modelos de Desempenho de Processos para

Gerência Quantitativa de Projetos de Software. Simpósio Brasileiro de Qualidade de

Software, 2007.

• Rocha, A.R.C., Souza, G.S., Barcellos, M.P., Medição e Controle Estatístico de

Processos. MCTi, 2012.

• Tian, J., Software Quality Engineering, IEEE Computer Society Press, 2005.

• Wagner, S., Software Product Quality Control, Springer, 2013.


INF2922 Qualidade de Sistemas de Software Contemporâneos ... › ~kalinowski › INF2922 ›...

Documents

Transcript of INF2922 Qualidade de Sistemas de Software Contemporâneos ... › ~kalinowski › INF2922 ›...