Qualidade de Software Material Didático

Prévia do material em texto

Qualidade de 
software
Fabiano Gonçalves 
dos Santos
Aula 1
Ementa
Objetivo Geral
Objetivo Específico
2
Plano de Ensino
Conteúdo
3
Plano de Ensino
Bibliografia Básica
Bibliografia Complementar
4
Plano de Ensino
Período Características
Anos 50 -Erros conhecidos, APÓS término do programa
Anos 70 -Análise/programação estruturada.
-Falta de consenso: teste ANTES do término
Anos 80 - Primeiras preocupações e PADRÕES com 
QUALIDADE de software
Anos 90 -Primeiros processos de testes. 
-Motivação: Bug do milênio.
Anos 
2000
-Estruturação dos procedimentos de testes dentro do 
processo de desenvolvimento. 
-Surgem excelentes ferramentas de testes. 
-QUALIDADE Total no processo de desenvolvimento 
e produto de software
A preocupação com qualidade de software
Fatos reais - Projetos de Software
+ 30% dos projetos – CANCELADOS
+ 70% dos projetos – FALHAM as funcionalidades
Custos e Prazos EXTRAPOLAM a Previsão
Custos – em mais de 180% 
Prazos – em mais de 200% 
Custos do DESENVOLVIMENTO
80% - identificar e corrigir defeitos de programação
A crise do software
• Software NÃO é tangível. Requer muita ABSTRAÇÃO para 
desenvolvê-lo.
• O processo de desenvolvimento é executado e gerenciado por 
pessoas, sendo portanto SUBJETIVO.
• Discute-se ideias, necessidades e desejos dos usuários (também 
pessoas).
• ABSTRAÇÃO E SUBJETIVIDADE conferem dificuldades ao processo 
de desenvolvimento.
• O software em si é consequência direta da forma (processo) pelo 
qual foi desenvolvido. PROCESSO MANUFATURADO
• Processo de desenvolvimento eficiente  Software eficiente.
Na medida em que os softwares crescem em tamanho e 
complexidade, ABSTRAÇÃO e COMPLEXIDADE conferem cada 
vez mais DIFICULDADES ao processo de desenvolvimento
Aspectos relevantes sobre 
software e processo
• Conjunto de atividades, métodos, 
práticas e tecnologias que as pessoas 
usam para desenvolver e manter 
softwares
• O processo adequado garante que o 
software será desenvolvido de maneira 
organizada, disciplinada e previsível.
• O processo descreve formalmente e de 
forma organizada as atividades que 
devem ser seguidas para a obtenção 
segura de um produto de software.
• A dificuldade está no gerenciamento do 
processo (existem vários modelos), que 
geralmente está dividido em fases.
Processo de desenvolvimento
•Análise: Analista com usuários. 
• Requisitos. Interesses  soluções para 
usuário
• Projeto (design): Projetista usa a tecnologia 
• Requisitos tecnológicos  tecnologia para 
usuário
• Implementação: Programador usa L.P.
• Escrita do código  Lógica de programação
• Testes: Testadores com programas / 
sistema
• Buscar defeitos e falhas nos sistema.
• Homologação ou Aceitação: Com usuários.
• Usuário aprovar o sistema (Participar de 
tudo!)
• Implantação: Instalação e treinamento
• Entrega o sistema. 
• Fim do ciclo de desenvolvimento
ANÁLISE
PROJETO
IMPLEMENTAÇÃO
TESTES
HOMOLOGAÇÃO
IMPLANTAÇÃO
Processo e desenvolvimento de software
• A maior dificuldade esta na fase INICIAL, de 
entendimento do sistema - Requisitos – ALTO grau 
de ABSTRAÇÃO + Comunicação com pessoas
• A segunda maior abrangência 
está na modelagem – ALTO 
Grau de ABSTRAÇÃO + 
domínio das técnicas
• O erros de codificação em si,
representam um % pequeno, 
mostrando que o foco do problema 
não é da Implementação. 
Onde estão os defeitos?
• O QUE É SOFTWARE COM QUALIDADE ?
• Atender aos REQUISITOS dos usuários
• Satisfazer aos DESEJOS dos usuários
• Escrever TUDO o que se deve fazer. FAZER tudo que foi 
escrito
• O QUE É QUALIDADE DE SOFTWARE ?
• PROCESSO SISTEMÁTICO QUE:
• Focaliza todas as ETAPAS e ARTEFATOS (modelos, 
diagramas, programas, módulos de software, classes e etc)
• Com objetivo de Garantir CONFORMIDADE dos processos 
e produtos especificados, PREVININDO E ELIMINANDO 
defeitos
Software com qualidade
• QUALIDADE DE SOFTWARE É CONFORMIDADE COM ?
• REQUISITOS FUNCIONAIS – base para medir a qualidade
• REQUISITOS DE DESEMPENHO – critérios de 
desempenho definidos
• CARACTERÍSTICAS IMPLÍCITAS (esperadas)
• Fácil de usar, fácil de usar (usuário)
• Código Legível, fácil de manter (equipe de 
desenvolvimento)
• A QUALIDADE DO SOFTWARE DEPENDE DA QUALIDADE 
DE SEU PROCESSO DE DESENVOLVIMENTO (sofre forte 
influência).
Software com qualidade
Qualidade do 
Produto
Qualidade do 
Processo
Qualidade de 
Software
A Qualidade do Produto é 
o que buscamos.
A Qualidade 
do Processo é 
o meio para 
conseguirmos.
A Qualidade do produto é 
fortemente influenciada pela 
qualidade dos processos utilizados 
no seu desenvolvimento.
Qualidade no processo x Qualidade 
no produto
• No processo de desenvolvimento de software, a 
qualidade não é uma fase específica, ela atua em 
TODAS as fases
Qualidade é atuar em todas as fases – verificando 
conformidade com os padrões e definições
A qualidade é mais uma fase no processo 
de desenvolvimento de software?
Necessidades?
Desejos?
Interesses? 
Qual a visão do usuário?
A qualidade Sempre considera 
os usuários
©
 L
ig
ht
ke
ep
er
 | 
D
re
am
st
im
e.
co
m
Usuários e suas preocupações
Usuários e suas preocupações
As visões da qualidade
• Software de Qualidade
• GARANTE A SEGURANÇA das 
transações, dos negócios e das pessoas 
envolvidas
• MANTÉM A ALTA DISPONIBILIDADE dos 
serviços.
Por que a organização deseja software 
com qualidade?
A documentação do SW torna-se um instrumento fundamental 
para o CONTROLE DA QUALIDDE
• GARANTIA
• Padrões que garantam a qualidade do software
• PLANEJAMENTO
• Seleção de procedimentos e padrões adequados 
para o projeto
• CONTROLE
• Assegurar que o desenvolvimento tenha seguido 
os procedimentos e padrões de qualidade do 
projeto
Gerenciamento da qualidade
• Esforços (recursos) pela qualidade nos mais 
diversos setores organizacionais já provaram 
que:
• a qualidade não tem custo
• se paga em pouco tempo.
O custo com o processo de 
qualidade se paga?
Reflexo Global: MAIOR SATISFAÇÃO DOS CLIENTES, 
REFLETINDO EM MAIOR PARTICIPAÇÃO NO MERCADO
• O Aumento da Qualidade no PROCESSO acarreta
• Garantia de estarmos fazendo o Software CERTO
• Aumento de produtividade
• Redução de Custos: Menos retrabalho e menos perdas
• Menor prazo de entrega
• Aumento da Qualidade do PRODUTO acarreta
• Reaproveitamento de código de programa
• Programas mais eficientes.
• Menor custo e mais facilidade de manutenção
• É mais fácil fazer software CORRETO do que consertá-lo 
(conclusão após longo período de remendo de software)
Conclusões
Qualidade de 
software
Fabiano Gonçalves 
dos Santos
Atividade 1
Perguntas e respostas
• Quais as dificuldade em se prover qualidade 
no processo?
Perguntas e respostas
• Quais as dificuldade em se prover qualidade 
no processo?
Ausência de procedimentos 
claros, até mesmo de um 
processo definido
Ausência de técnicas de 
desenvolvimento (análise, projeto 
e programação)
Ausência de registro das decisões 
e modelos (documentação)
Perguntas e respostas
• Por que qualidade é ter conformidade com 
os requisitos?
Perguntas e respostas
• Por que qualidade é ter conformidade com 
os requisitos?
Por que se não atender ao que 
o usuário precisa (requisitos), o 
SW não terá atingido o seu 
objetivo e sem isso, não há 
qualidade
Qualidade de 
Software
Fabiano Gonçalves 
dos Santos
Aula 2
A qualidade precisa ser medida comparando a padrões e 
critérios pré-determinados
Por que medir a qualidade?
• Para determinar um valor de grandeza.
• Mede e compara o SW com algum dado (padrão) eobtém uma INDICAÇÃO DE QUALIDADE.
• O que devemos medir?
• Processo
• Produto
• Fatores que afetam a qualidade
• Mensuráveis diretamente
• Tempo, Custo, produtividade
• Mensuráveis indiretamente
• Usabilidade, manutenibilidade (subjetivos)
Que medidas são necessárias?
• Tempo e custo do processo
• Desempenho e resultados
• Produtividade da equipe
• Recursos efetivos e usados
O que fazer com medidas?
• Permitir criar padrões
• Estimativas (tempo, custo, recursos)
• Aplicar ações corretivas e preventivas diante 
de riscos
• Afetam a qualidade do software
• Considerar no software
• características operacionais
• capacidade de mudanças
• adaptabilidade a novos contextos
• Categorias
• Revisão do Produto
• Operação do Produto
• Transição do Produto
Fatores de qualidade
Categoria REVISÃO
Fator de Qualidade Característica
Manutenibilidade Capacidade de ajuste e melhorias 
do programa, mantendo-o atual 
Flexibilidade Esforço para se modificar o 
programa
Testabilidade Tempo para teste de um programa, garantindo sua eficácia (executa a 
função a que se destina?)
Fator de 
Qualidade Característica
Corretude Atende as especificações e objetivos do 
cliente?
Confiabilidade Executa sempre da mesma forma? Com a 
precisão exigida
Eficiência Qtde de recursos (hw / sw) para o 
programa executar.
Integridade Controle de acesso (sw e dados) é 
controlado?
Usabilidade Esforço para aprender e operar o 
programa
Categoria Operação 
Fator de Qualidade Característica
Portabilidade Esforço para transferir o programa 
para outro ambiente (hw/sw) de 
execução
Reusabilidade Usar programa ou parte dele em 
outras aplicações
Interoperabilidade Esforço para acoplar um sistema a 
outro. Integração de soluções.
Categoria TRANSIÇÃO
• Roger Pressman
– Dificuldade: desenvolver medidas diretas 
dos fatores de qualidade propostos por 
McCall.
–Por quê? subjetividade na medição.
• McCall, julga relevante.
– Escala padrão (0 a 10), estabelecendo 
métrica para cada fator que afeta a 
qualidade.
Como usar métricas?
• Ausência de:
–modelo corporativo de qualidade;
–procedimentos de testes automatizados;
–profissionais capacitados em qualidade.
• Deficiência no planejamento e aplicação dos 
testes.
• Qualidade é aplicada tardiamente no 
processo.
Influenciam na qualidade
• Ciclo de desenvolvimento de SW confiável.
• Garante ações corretivas no ciclo de 
desenvolvimento.
• Evita a ingerência do projeto de software.
• Amplia chances de sucesso do proj. de SW
• Amplia a produtividade do 
desenvolvimento.
• Evita a propagação de erros.
• Automação de testes reduz custos do 
projeto.
Benefícios da qualidade
ht
tp
://
pt
.w
ik
ip
ed
ia
.o
rg
/
• A garantia da qualidade de software (Software 
Quality Assurance – SQA) deve ser aplicada em 
todo o processo de engenharia de software.
• Define
• Padrões para o projeto
• Procedimentos para o relato
• Acompanhamento de erros e Documentação 
necessária
• Realimenta a equipe com conclusões do projeto.
Software quality assurance - SQA
Atividade Finalidade
Aplicação de Métodos e 
ferramentas técnicas
Aplicar a análise e projeto. Ajudam analistas e 
projetistas a gerarem software com qualidade.
FTR – Revisão Técnica 
Formal
Descobrir problemas de qualidade no projeto. Tão 
importante como os testes de software (produto).
Teste de Software Detectar falhas e erros no software. 
Não é completo por si só.
Auditoria de Padrões e 
Procedimentos Formais
Verificar se o projeto cumpre os padrões definidos. O 
desenvolvimento está usando os padrões?
Atividades de Controle de 
Mudanças
Formaliza e controla pedidos de mudança no software 
(no desenvolvimento e após manutenção)
Medição do software Coleta um conjunto de medidas técnicas e orientadas 
a adm. das especificações do software.
Documentação Manter acessível a documentação histórica dos 
resultados de todas as atividades SQA aplicadas.
Atividades do SQA
• Métodos de validação de qualidade – uso pela 
equipe técnica.
– Processo
– Produto
• Filtram erros e inconsistências no processo de 
desenvolvimento.
• Objetivos
– Apontar melhorias ao produto ou parte dele – 
por um grupo de pessoas.
– Tornar o trabalho técnico mais administrável.
Revisões de software
• Inspeções de projeto ou programa.
• Detectar erros nos requisitos, projeto ou código
• Revisões de progresso.
• Informações p/ gestão do progresso geral do projeto.
• Revisão do processo, produto (custos), 
planejamento e prazos.
• Revisões de qualidade.
• Análise técnica do produto ou documentação.
• Detectar inconsistências entre:
• especificação e projeto;
• código ou documentação;
• assegurar se padrões de qualidade foram seguidos.
Tipos de revisões
• Custos Operacionais de implementação de 
atividades de qualidade no processo (e 
produto)
•Metas:
• Reduzir custo com qualidade
• Comparar com demais custos
• 4 categorias de classificação
Custos de qualidade
Os custos da revisão de qualidade e 
seus impactos
Custos de prevenção
•Prevenção de defeitos: 5 
a 15%
•Atividades decorrentes
– Planejamento da 
qualidade
– Revisões técnicas formais
– Equipamentos de teste
– Treinamento
•São controláveis e 
caracterizam investimento.
Custos de Avaliação
•Remover do processo 
produtos com defeitos: 20 
a 25%
•Atividades decorrentes
– Inspeção intra e 
interprocessos
– Calibração e manutenção 
do equipamento
– Teste
•São incontroláveis e 
caracterizam perdas e 
prejuízos.
Os custos da revisão de qualidade e 
seus impactos
Custos de falha interna
•Defeitos antes da entrega 
ao cliente: 65 a 70%.
•Atividades decorrentes
– Trabalho para refazer
– Esforço para reparar
– Análise do modo como a 
falha ocorreu
•São incontroláveis e 
caracterizam perdas e 
prejuízos.
Custos de falha externa
•Defeito após a entrega ao 
cliente: 65 a 70%.
•Atividades decorrentes
– Solução de queixas
– Devolução e substituição 
do produto
– Manutenção da linha de 
suporte
•São incontroláveis e 
caracterizam perdas e 
prejuízos.
• Custo de identificação e reparo do 
erro/defeito.
–Cresce a medida em que o tempo passa.
– Aumenta a insatisfação (interna e externa).
• Dica: investimento e prevenção.
Revisões de Software - Conclusões
Conhecida como walkthroughs, inspeções, reuniões round – robin
Cada RTF é conduzida como uma reunião.
• Principal atividade de um SQA
• Objetivos
• Verificar se SW atende aos requisitos
• Garantir que o SW está de acordo com padrões 
pré-definidos
• Obter um SW desenvolvido de forma uniforme
• Tornar os projetos mais administráveis
• Descobrir erros de função, lógica ou 
implementação do SW
Revisão Técnica Formal (RTF)
RTF: Reunião de revisão
• Restrições a reunião (duração de até 2h)
• 3 a 5 pessoas, com preparação antecipada.
• Foco: um produto, um componente de 
software.
• Ao final da reunião.
• Aceitam / rejeita / aceitam temporariamente.
• Um revisor = registrador
• Produtor percorre o produto e explica o material
• Revisores levantam questões
• Qualidade no Processo desde o início
• Aferição em cada fase  métricas, fatores de 
qualidade e padrões; Inconsistências.
• SQA – Software Quality Assurance
• Avaliações, Auditorias, Revisões, RTF
• Atividades de controle das mudanças.
• Documentação
• Qualidade no Produto
• Testes
• Fase de Implementação (unitários e 
integrados)
• Fase de Testes (sistema e homologação)
• Automação dos testes / técnicas diversas
Conclusão
Qualidade de 
software
Fabiano Gonçalves 
dos Santos
Atividade 2
23
Dúvida
• Quando falamos de revisões de software, o 
que é importante que o engenheiroconsidere no planejamento?
24
Dúvida
• Quando falamos de revisões de software, o que é 
importante que o engenheiro considere no 
planejamento?
Devem ser consideradas as seguintes questões:
•quem participa?
•qual informação é requerida antes da revisão?
•quais pré-condições que devem ser satisfeitas 
antes que a revisão possa ser conduzida?
•Como Organizar?
• Gerar checklists ou outra indicação do que 
deve ser coberto na revisão.
• Determinar as condições de término ou 
critérios que devem ser satisfeitos para que 
a revisão termine.
• Gerar registros e documentos que devem 
ser produzidos.
4) Quando falamos de revisões de software, o que é importante que 
o engenheiro considere no planejamento?
Devem ser consideradas as seguintes questões:
-quem participa?
- qual informação é requerida antes da revisão?
- quais pré-condições que devem ser satisfeitas antes que a revisão 
possa ser conduzida?
- Como Organizar?
- Gerar checklists ou outra indicação do que deve ser coberto na 
revisão;
- Determinar as condições de término ou critérios que devem ser 
satisfeitos para que a revisão termine;
- Gerar registros e documentos que devem ser produzidos
25
Qualidade de 
Software
Fabiano Gonçalves 
dos Santos
Aula 3
Qualidade do ProdutoQualidade do Processo
Qualidade = Processo + 
Produto
A Qualidade do 
Produto é o que 
buscamos.
A Qualidade 
do Processo é 
o meio para 
conseguirmos.
A Qualidade do produto é 
fortemente influenciada pela 
qualidade dos processos 
utilizados no seu 
desenvolvimento.
2
ht
tp
://
w
w
w
.c
ra
w
fo
rd
th
om
as
.c
om
; h
ttp
://
he
llo
-b
er
lin
.n
et
• A qualidade é responsabilidade de todos os 
participantes do desenvolvimento de software. 
• Qualidade pode ser obtida
• Processo eficiente (analise, projeto, codificação 
e teste)
• RTF nos trabalhos intermediários
• Modificações propostas
• SQA Estatística  Apoio Quantitativo
• Base: frequência da ocorrência de erros e 
inconsistências, ao longo do período de tempo.
• Objetivo: aprimorar os elementos do processo 
que promovem erro.
Garantia estatística da qualidade
3
1. Coletar informações sobre os defeitos e catalogar 
em categorias:
• alguns defeitos – no processo;
• outros defeitos – após entrega.
2. Rastrear o defeito até encontrar sua causa.
3. Considerar: 20% do código tem 80% dos defeitos 
 centrar no que importa.
4. Corrigir os problemas que originaram os defeitos.
Passo a passo para a SQA Estatística
4
I. Especificações incompletas ou mal 
formuladas. 
II. Má interpretação da comunicação com o 
cliente. 
III. Desvio intencional das especificações. 
IV. Violação dos padrões de programação. 
V. Erro na representação dos dados. 
VI. Inconsistência na interface de 
componente. 
Possíveis causas dos defeitos
5
VII. Lógica do projeto inconsistente. 
VIII. Teste incompleto ou errôneo. 
IX. Documentação imprecisa ou incompleta. 
X. Erro na tradução do projeto para a 
linguagem. 
XI. Interface H-M ambígua ou inconsistente.
XII. Diversos (miscelânea) 
Possíveis causas dos defeitos
6
ERROS TOTAL GRAVE MODERADO SIMPLES
 Qtde % Qtde % Qtde % Qtde %
I 205 22 34 27 68 18 103 24
II 156 17 12 9 68 18 76 17
III 48 5 1 1 24 6 23 5
IV 25 3 0 0 15 4 10 2
V 130 14 26 20 68 18 36 8
VI 58 6 9 7 18 5 31 7
VII 45 5 14 11 12 3 19 4
VIII 95 9 12 9 35 9 48 11
IX 36 4 2 2 20 5 14 3
X 60 6 15 12 19 5 26 6
XI 28 3 3 2 17 4 8 2
XII 56 6 0 0 15 4 41 9
TOTAIS 942 100 128 100 379 100 435 100
7
O que nos diz a tabela?
• Os erros I, II e V - poucas causas vitais que 
correspondem 53% dos 
 erros (Some a coluna 
 Total % desses 3 grupos 
 de erros).
• Os erros I, V, VII e X - 
 poucas causas vitais 
 dos erros graves (coluna 
 Qtde de Graves). 
• Após detecção dos erros 
 vitais  ação corretiva  
 novos erros aparecerão.
Garantia estatística da qualidade
ERROS TOTAL GRAVE MODERADO SIMPLES
 Qtde % Qtde % Qtde % Qtde %
I 205 22 34 27 68 18 103 24
II 156 17 12 9 68 18 76 17
III 48 5 1 1 24 6 23 5
IV 25 3 0 0 15 4 10 2
V 130 14 26 20 68 18 36 8
VI 58 6 9 7 18 5 31 7
VII 45 5 14 11 12 3 19 4
VIII 95 9 12 9 35 9 48 11
IX 36 4 2 2 20 5 14 3
X 60 6 15 12 19 5 26 6
XI 28 3 3 2 17 4 8 2
8
REPETIR os passos ATÉ QUE erros sejam 
sanados
1.Criar lista de possíveis Categorias de Causas; 
2.Quantificar, por um tempo determinado, a 
incidência de erros;
3.Focar nas poucas causas vitais;
• 20% do projeto/código contém 80% dos 
erros.
4.Corrigir as causas vitais  corrigir os erros;
5.Surgem novos erros (testes são exaustivos).
A cada Correção de problemas identificados, novos 
podem ser inseridos, por isso várias “rodadas” são 
necessárias.
Procedimento – SQA Estatística
9
Confiabilidade: Difícil quantificar com precisão
Métrica: confiabilidade.
• A probabilidade de um programa operar sem 
falhas, num ambiente específico durante 
determinado tempo específico”.
• Considerar que um número mínimo de falhas 
ocorrerá na execução. 
• Alguns softwares precisam de um % de 
confiabilidade muito próximo a 100%.
• 0,98 de confiabilidade por 8h de processamento = 
se o software for executado 100 vezes por um 
tempo de oito horas é provável que funcione 
corretamente 98 vezes.
• Alta Disponibilidade do software  Hoje.
10
• Problema: sistema de segurança crítico.
• Trata-se de uma Atividade SQA 
• detecta e avalia riscos em potencial, que 
podem provocar falhas e impactar o 
desempenho.
• identifica e avalia causalidades em 
potencial que possam exercer impacto 
negativo e provocar falhas.
Confiabilidade: difícil quantificar com precisão.
Métrica: Segurança.
11
• Passos para implementação da Segurança
1. Identificar a presença de riscos o mais cedo 
possível.
2. Traçar as estratégias no projeto de software 
que eliminem ou controlem esses riscos em 
potencial.
3. Identificar a avaliar casualidades que possam 
impactar, negativamente, o SW causando 
falhas  categorizar as falhas por criticidade e 
risco.
4. Analisar a gravidade e probabilidade de 
ocorrência.
5. Listar os requisitos de segurança para do 
Software.
Segurança: cada vez mais requerida nos Softwares atuais.
Métrica: segurança.
12
Técnicas de Análise da Gravidade e 
Probabilidade de Ocorrência
Análise 
Árvore de 
falhas
Lógica de 
tempo real
13
Órgãos Normativos e Reguladores
ht
tp
://
w
w
w
.ie
c.
ch
; h
ttp
://
pt
.w
ik
ip
ed
ia
.o
rg
14
• Descreve elementos de garantia em termos 
genéricos, que podem ser aplicados aos negócios 
(Produto ou serviço).
• Sistema de qualidade que:
– Define responsabilidades;
– Cria procedimentos e processos;
– Capacita recursos para gestão da qualidade;
– Demanda normas;
– PARA SAFISTAZER OS CLIENTES, 
CONFORME SUAS ESPECIFICAÇÕES.
– Não descreve como Fazer (consultoria).
Princípios da ISO 9000
15
Por que as empresas querem a ISO?
• A adoção das normas ISO lhes confere:
–Gestão
• Prover confiança à própria 
administração de que seus produtos 
atenderão à satisfação dos clientes.
–Garantia
• Prover confiança aos clientes de que os 
produtos atenderão à sua garantia.
16
• As consequências:
• A empresa ganhana produtividade e 
credibilidade, aumentando sua competitividade.
• Com a empresa competitiva:
• diferenciação e; 
• galgar novas oportunidades em um mercado 
global. 
Por que as empresas querem a ISO?
17
Como funciona a certificação?
1. Empresa contrata consultoria específica.
2. Empresa se qualifica para a auditoria de acreditação 
da ISO:
• Avaliação da conformidade do sistema de garantia 
da qualidade -> Não 
certifica-se o produto e sim 
 a capacidade de produção;
• Geralmente certifica-se 
 por área de atividade da 
 empresa 
 (não na 
totalidade).
18
©
 A
rk
ad
i B
oj
ar
ši
no
v 
| D
re
am
st
im
e.
co
m
Como funciona a certificação?
3. Uma vez qualificada 
 (auditoria de validade), a empresa recebe o 
certificado.
4. Começam as auditorias de vigilância – 
semestrais ou anuais.
19
©
 A
rk
ad
i B
oj
ar
ši
no
v 
| D
re
am
st
im
e.
co
m
• ISO: Mundial / Edições: 87,94,2000,2008
• ISO 9001 (mais completa)
–garantia da qualidade em projetos / 
desenvolvimento, produção, instalação e 
assistência técnica  empresas de criação 
de novos produtos.
• ISO 9002
–garantia da qualidade em produção e 
instalação  destina a quem produz item de 
catálogo ou prestam serviços conforme 
especificações existentes.
Modelos da ISO 9000
20
• ISO 9003
–garantia da qualidade em inspeção e testes 
finais. Adequada a empresas cuja produção 
não inclua itens especiais (fácil separa itens 
conformes e não conformes na inspeção).
• ISO 9004
–gestão da qualidade e elementos do sistema 
de qualidade – diretrizes. Funciona como guia 
para desenvolvimento do SGQ. De uso 
voluntário e interno (sem funs. contratuais).
Modelos da ISO 9000
21
• Revisão na norma: adequação à prática.
• Foco no cliente
• Liderança
• Envolvimento das pessoas
• Abordagem do processo (melhoria)
• Abordagem Sistêmica para gestão
• Melhoria contínua na qualidade (1994 – não)
• Abordagem para tomada de decisão
• Benefícios mútuos nas relações com fornecedores
Princípio da ISO 9000:2000
22
Princípio da ISO 9000:2000
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS (ABNT). Coletâneas de normas de sistemas da 
qualidade. Rio de Janeiro: ABNT, 2001.
23
Resumindo
• SQA Estatístico é importante pois temos 
uma noção numérica de falhas, problemas e 
erros por CATEGORIAS.
• Ajuda a aperfeiçoar Processo de Produto
• Confiabilidade é uma métrica importante, 
mas difícil de mensurar  é um quesito 
base: confiar no resultado.
• Segurança é essencial ao SW moderno, 
levando a uma análise de riscos.
24
Resumindo
• A ISO 9000 surge como alternativa para 
melhoria do processo produtivo das 
empresas, gerando produtos e serviços 
mais competitivos no mercado Nacional e 
Internacional.
• A certificação ISO surge como diferencial 
competitivo, sendo estratégico para 
corporação atingir patamares diferenciados 
e oportunidades num mercado Global. 
25
Qualidade de 
Software
Fabiano Gonçalves 
dos Santos
Atividade 3
27
Perguntas
• O que é e, o que faz a ISO?
28
Perguntas
• O que é e, o que faz a ISO?
ISO=International 
Organization 
Standardization.
Orgão, de origem inglesa, 
que produz normas 
internacionais.
150 países participantes e 
cerca de 50 mil especialistas 
(Mundo)
29
Perguntas
• O que é a ABNT?
Órgão brasileiro responsável 
pelas normas de qualidade
Representa, no Brasil a ISO 
e a IEC
Cuida da preparação das 
normas técnicas, mas 
também pode verificar a 
implantação e uso das 
normas em empresas.
Órgão brasileiro responsável 
pelas normas de qualidade
Representa, no Brasil a ISO 
e a IEC
Cuida da preparação das 
normas técnicas, mas 
também pode verificar a 
implantação e uso das 
normas em empresas.
30
Pergunta
• O que representa a adequação a uma 
norma, para uma empresa?
31
Pergunta
• O que representa a adequação a uma 
norma, para uma empresa?
A adequação a uma norma 
consiste em colocar em 
prática, total ou parcialmente, 
a que ela se propõe.
A adequação pode ser obtida 
por consultoria ou de forma 
autônoma.
32
Pergunta
• A certificação, uma vez obtida, vale para 
sempre?
33
Pergunta
• A certificação, uma vez obtida, vale para sempre?
• Não. A certificação vale por 
certo período de tempo, 
durante o qual há 
acompanhamento da 
certificadora: 
• Testes com amostras 
(produtos) ou visitas e 
inspeções (gerenciamento e 
processos).
• A empresa pode até perder 
seu certificado.
Qualidade de 
Software
Fabiano Gonçalves 
dos Santos
Aula 4
Foco Aspectos
Desenvolvedor
• Inicio: Qualidade = Funcionar
• 2º momento: Qualidade = 
Confiabilidade
• 3º momento: Qualidade 
incorpora outros aspectos
Cliente • Percepção da Qualidade• Pacotes de Software
Tecnologia
• Deixou de ser diferencial (todos)
• Passa a atributo de Qualidade, 
como por exemplo :interface
Evolução do conceito de qualidade de 
software
2
Usuário
– Interesse: Qualidade de Uso e desempenho
– Interesse nas medidas externas
• As funções estão disponíveis?
• Software é confiável? 
 É eficiente?
• Fácil de usar? 
• Fácil para mudar de 
ambiente?
– Características construtivas 
não interessam
Visões da qualidade
3
©
 L
ig
ht
ke
ep
er
 | 
D
re
am
st
im
e.
co
m
• Desenvolvedor
– Coerente com 
expectativas dos 
usuários (requisitos 
 e aceitação)
– Interesse nas 
 medidas internas 
(técnicas)
– Qualidade de produtos 
intermediários 
(documentos, 
modelos e 
diagramas)
Visões da qualidade
4
©
 W
ar
en
em
y 
| D
re
am
st
im
e.
co
m
; ©
 S
ky
fo
to
st
oc
k 
| D
re
am
st
im
e.
co
m
• Gerente de Desenvolvimento
– Medida global da qualidade
– Qualidade x Prazo x Custos
– Qualidade do processo.
Visões da Qualidade
5
©
 D
m
itr
iy
 S
hi
ro
no
so
v 
| D
re
am
st
im
e.
co
m
NBR ISO/IEC 9126 (Produto)
• Qualidade é: “totalidade de características de uma 
entidade que lhe confere a capacidade de 
satisfazer as necessidades explícitas e 
implícitas“
• As 2 necessidades subsidiam as 
 validações e verificações (como testes)
• Explícitas (externas) = condições em 
 que produto deve ser usado, 
objetivos, funções,desempenho esperado 
 (depende de 
especificações de requisitos).
• Implícitas (internas) = Não estão especificados 
nos requisitos, mas são características obvias e 
fundamentais 
6
• Define Características e sub-características que definem 
um MODELO de qualidade
• Não apresenta métricas para características de qualidade.
– Propõe que cada empresa use as próprias
• Qualidades explícitas (externas) = métricas externas ou 
seja medições baseadas nas necessidades dos usuários 
(produto final)
• Qualidades implícitas (internas) = métricas internas 
(produtos intermediários)
• Qualidades de uso = Visão de qualidade que o usuário tem 
do software
NBR ISO/IEC9126 (Produto)
7
• Modelo de QUALIDADE da norma é composto 
de 2 partes:
–A qualidade do produto deve ser avaliado 
segundo um modelo definido.
–O modelo deve ser usado para estabelecer 
metas de qualidade do SW e produtos 
intermediários
• Público alvo: desenvolvimento SW, Adquirentes, 
Equipe de qualidade e Avaliadores
NBR ISO/IEC 9126 (Produto)
8
O objetivo é que o produto tenha 
o efeito desejado em um 
contexto particular de uso. 
NBR ISO/IEC 9126 (Produto)
A qualidade do 
produto de software 
pode ser avaliada 
pela medição:
dos atributos internos (tipicamente 
medidas estáticas de produtos 
intermediários);
dos atributos externos (tipicamente 
medidas do comportamento do 
código quando executado);
dos atributos de qualidade em uso.
9
Quando executado Durante o desenvolvimento
• Instrumentos necessários para realizar uma 
avaliação 
• Como medir qualitativamente e quantitativamente 
a qualidade - 9126-1
Utilização do softwareUtilização do software
Modelo de Qualidade NBR ISO/IEC 9126
10
Métricas do Modelo de Qualidade NBR 
ISO/IEC 9126
11
Característica Especificidades
Funcionalidade • Ser adequado aos requisitos
Confiabilidade • Manter o nível de desempenho
Usabilidade • Ser de fácil uso. Sem esforço
Manutenibilidade • Esforço para modificações
Portabilidade • Ser transferido de ambiente
Eficiência • Uso otimizado de recusrsos.
O que a norma entende como 
característica?
12
Característica Especificidades
Eficácia • Permitir que usuário atinja sua meta com acuracia e completude
Produtividade
• Permitir que os usuários empreguem a 
quantidade apropriada de recursos em 
relação a eficácia obtida
Segurança • Apresentar níveis aceitáveis de riscos
Satisfação •Satisfazer os usuários.
O que a norma entende como 
Qualidade em uso?
13
Princípios do Modelo de Qualidade NBR 
ISO/IEC 9126
Qualidade do Processo
Contribui para a 
melhoria da qualidade 
do produto
Contribui para a 
melhoria da qualidade 
do uso
14
Métricas do Modelo de Qualidade 
NBR ISO/IEC 9126
15
• Atual NBR ISO/IEC 25051)
• A norma estabelece conjunto de:
• 1. Estabelece os requisitos de qualidade de um 
software tipo pacote.
• 2. Fornece instruções para testá-lo, com base nos 
requisitos.
• Escopo: Pacotes oferecidos ao mercado. 
• Compreendem os processadores de texto, planilhas, 
BDs, softwares gráficos, programas para funções 
administrativas, técnicas ou científicas e programas 
utilitários
NBR ISO/IEC 12119 (Pacote)
16
• Esta Norma não trata de 
processos de produção 
de software (tampouco 
atividades e produtos 
intermediários, por exemplo 
especificações); 
• O sistema de qualidade do 
produtor (tratado, por 
exemplo, na NBR ISO 9001) 
está fora do escopo desta
NBR ISO/IEC 12119 (Pacote)
17
• Pacotes de software 
conjunto completo e 
documentado de 
programas fornecidos a 
diversos usuários para 
uma aplicação ou função 
genérica. (SW de 
prateleira).
NBR ISO/IEC 12119 (Pacote)
18
NBR ISO/IEC 12119 (Pacote)
ISO/IEC 
12119
Requisitos de 
qualidade
Pré-requisitos 
de testes
Descrição 
do produto
Documentaç
ão do usuário
Programas 
e dados
Atividades 
de testes
Registros 
de testes
Relatórios 
de testes
Teste de 
acompanhamento
Instruções 
para testes
19
• Os requisitos de qualidade 
incluem que: 
1. A descrição do produto
2. Documentação do usuário; 
3. Documentação do produto e 
dados necessários ao seu 
funcionamento
• Um pacote de software está 
em conformidade com esta 
Norma se atende a todos aos 
requisitos acima.
NBR ISO/IEC 12119 (Pacote)
20
NBR ISO/IEC 12119 (Pacote)
Pré-requisitos para teste:
Deve ser considerada a 
presença de itens de 
produto; de sistema 
necessário e treinamento 
quando mencionado na 
descrição do produto
Atividades de teste: 
Testar se estão de acordo 
com os requisitos de 
qualidade tais como a 
descrição do produto, a 
documentação do usuário, 
e os programas de dados
Registro de teste:
Deve conter informações suficientes 
para permitir a repetição do teste 
como a elaboração do plano de 
teste, casos de teste, registros de 
resultados com falhas e/ou 
sucessos e por fim, a identificação 
de pessoas envolvidas
Relatório de teste: 
Contém a descrição do produto, o 
hardware e software usado no teste, 
os documentos usados, os resultados 
dos testes (descrições, documentação, 
programas e dados), a lista de não 
conformidades dos requisitos, a lista 
de não conformidades de 
recomendações e as datas dos inícios 
e término do teste
21
Qualidade de 
Software
Fabiano Gonçalves 
dos Santos
Atividade 4
• O que é um pacote de software?
23
• O que é um pacote de software?
24
Trata-se de um produto de 
software que envolve um conjunto 
completo e documentado de 
programas fornecidos a diversos 
usuários para uma aplicação ou 
função genérica.
Um pacote de software envolve 
todos os componentes do produto 
disponíveis aos usuários, tais 
como documentação, manual de 
instruções e guia de instalação.
Qualidade de 
software
Fabiano Gonçalves dos Santos
Aula 5
• “Para os usuários a interface é o programa.” 
• É o que o usuário vê.
• Interface é um Sistema de Comunicação:
– Um lado: usuário
– Outro lado: Computador (hw + sw)
– Objetivo: executar uma tarefa
Qual a importância da interface no 
software moderno?
ação
comunicação
2
• Mais pessoas usam computador (trabalho e laser)  aumento dos 
usuários não especializados  requerem interfaces fáceis de usar.
– As aplicações são cada vez mais complexas.
• Está provado: 
– interfaces eficientes aumentam a 
produtividade.
– Interfaces ruins sacrificam 
a funcionalidade
– A interface influencia como
 usuário visualiza e compreende as funcionalidades.
Qual a importância da interface no 
software moderno?
3
• Esclarece os benefícios de medir 
usabilidade em termos de desempenho e 
satisfação do usuário.
• Emprega o termo usabilidade para 
referenciar mais precisamente aos atributos 
de um produto que o torna mais fácil de usar 
(hardware, software ou serviços), além das 
medidas relevantes de usabilidade
• não cobre os processos de desenvolvimento 
de sistema.
Fácil de usar
4
• Um produto pode ser usado por usuários 
específicos para alcançar objetivos específicos 
com eficácia, eficiência e satisfação em 
contexto específico de uso.
• Eficácia: Completude com as quais usuários 
alcançam objetivos específicos.
• Eficiência: Eficácia c/ mínimo de recursos
• Satisfação: Ausência de desconforto e presença 
de atitudes positivas para uso
Conceituando ...
5
Usabilidade
A justificativa da usabilidade 
de produtos se faz pela 
incorporação de 
características e atributos 
conhecidos como capazes de 
beneficiar os usuários em um 
contexto particular de uso
A partir disso, para determinar 
o nível de usabilidade 
alcançado junto ao usuário é 
necessário medir o 
desempenho e satisfação 
destes trabalhando com um 
produto.
A medição possibilita visualizar a 
complexidade das interações entre o 
usuário, os objetivos, as características 
da tarefa e os outros elementos do 
contexto de uso. A cada circunstância 
ambiental, diferentes níveis de 
usabilidade podem ser definidos.
6
Como medir a avaliar a Usabilidade?
Para especificar ou medir 
usabilidade, algumas 
informações são 
necessárias
Descrição dos 
objetivos 
pretendidos
Descrição dos componentes do 
contexto de uso incluindo usuários, 
tarefas, equipamentos e ambientes 
(contexto existente ou pretendido)
Valores reais ou desejados de eficácia 
e eficiência e satisfação para os 
contextos pretendidos7
• Usuários
• Contexto de Uso: Ambiente físico e social 
no qual um produto é usado. Sistema, 
composto de usuários, equipamento, 
tarefas e o ambiente físico e social, com o 
propósito de alcançar objetivos 
específicos.
• Tarefas, 
• Equipamento (hardware, software e 
materiais)
Usabilidade - Contexto
8
• A escolha e o nível de detalhes de cada medida 
(eficácia, eficiência e satisfação) depende dos 
objetivos das partes envolvidas na medição. 
• Deve-se considerar a importância relativa de cada 
medida para os objetivos. Por exemplo, caso o uso 
não seja freqüente, pode ser dada grande 
importância para as medidas de aprendizado e re-
aprendizado.
• Caso não seja possível obter medidas objetivas de 
eficácia e eficiência, medidas subjetivas baseadas 
na percepção dos usuários podem fornecer uma 
indicação de eficácia e eficiência.
Como medir e avaliar a usabilidade?
9
• Se as medidas de usabilidade são obtidas 
em curtos períodos de tempo, os valores 
podem não levar em consideração os 
eventos pouco freqüentes os quais podem 
ter um impacto significativo sobre a 
usabilidade  Por exemplo, erros 
intermitentes do sistema. 
• Para um produto de uso geral, geralmente 
será necessário especificar ou medir 
usabilidade em alguns contextos 
representativos diferentes, os quais serão 
um subgrupo de possíveis contextos e de 
tarefas que podem ser realizadas
Como medir e avaliar a usabilidade?
10
Problemas de Usabilidade
11
Problemas de usabilidade
12
Problemas de usabilidade
13
Problemas de usabilidade
14
• Qual foi o resultado? Era o que eu queria?
• Para que serve este elemento?
• O que significa esta figura?
• Para onde “leva” este link?
• A página demora a carregar!
• O servidor não responde em tempo.
• Não é exibido corretamente neste browser!
• A linguagem script não funciona neste 
browser ou servidor.
Problemas de usabilidade
15
Parte 1: Introdução Geral
Parte 2: Orientações sobre requisitos da tarefa
Parte 3: Requisitos para apresentação visual
Parte 4: Requisitos para teclado
Parte 5: Requisitos posturais e de layout para posto 
de trabalho
Parte 6: Requisitos para ambiente
Parte 7: Requisitos para monitores quanto à 
reflexão
Parte 8: Requisitos para apresentação de cores
A norma ISO/IEC 9241
16
Parte 9: Requisitos para outros dispositivos de 
entrada que não o teclado
Parte 10: Princípios de diálogo
Parte 11: Orientações sobre usabilidade
Parte 12: Apresentação da informação
Parte 13: Orientações ao usuário
Parte 14: Diálogos por menu
Parte 15: Diálogos por linguagem de comando
Parte 16: Diálogos por manipulação direta
Parte 17: Diálogos por preenchimento de formulário
A norma ISO/IEC 9241
17
• A ISO 9241, partes 12 a 17, fornecem 
recomendações condicionais que são 
aplicadas em contextos de uso específico. 
• Não cobre os processos de 
desenvolvimento de sistema. 
– Os processos de projeto centrados no ser 
humano para sistemas interativos são 
descritos na ISO 13407.
A norma ISO/IEC 9241
18
Qualidade de 
software
Fabiano Gonçalves dos Santos
Atividade 5
Dúvida
• Qual seria uma das vantagens de se usar a 
Norma ISO 9241? 
20
Dúvida
• Qual seria uma das vantagens de se usar a 
Norma ISO 9241? 
21
Esclarecer os benefícios de 
medir usabilidade em termos de 
desempenho e satisfação do 
usuário, lembrando sempre que 
a usabilidade dos computadores 
depende do contexto de uso e 
que o nível de usabilidade 
alcançado dependerá das 
circunstâncias específicas nas 
quais o produto é usado. 
Outra dúvida
• Como a ISO 9241-11 redefine usabilidade? 
22
Outra dúvida
• Como a ISO 9241-11 redefine usabilidade? 
23
Como a capacidade de um 
produto ser usado por 
usuários específicos para 
atingir objetivos 
específicos com eficácia, 
eficiência e satisfação em 
um contexto específico de 
uso. 
Qualidade de 
software
Fabiano Gonçalves dos Santos
Aula 6
NBR ISO/IEC 14598
Avaliação do 
processo de 
desenvolvimento
2
• A norma fornece uma visão geral dos processos 
de avaliação de software.
• Fornece guias para avaliação baseada na 
utilização prática da Norma NBR ISO/IEC 9126
• Define 3 enfoques de processos para:
DESENVOLVEDORES
ADQUIRENTES
AVALIADORES
Visão Geral da Norma NBR ISO/IEC 
14598
3
14598-2
Planejamento 
e gestão
14598-6
Documentação
de módulos
de avaliação
14598-3
 Processo para
desenvolvedores
14598-4
 Processo para
adquirentes
14598-5
Processo para
avaliadores
14598-1
Visão Geral
Relação entre as partes da norma 
ISO/IEC 14598
4
Norma Objetivo
14.598-1
Visão geral da estrutura da série de normas e dos 
processos de avaliação. Relação com a norma ISO/IEC 
9126
14.598-2
Atividades de planejamento e gerenciamento do processo 
de avaliação. Requisitos e orientações para suporte ao 
processo.
14.598-3 Para Desenvolvedores: atividades de avaliação durante o processo de desenvolvimento. Produtos intermediários
14.598-4
Para Adquirentes: atividades de avaliação no processo de 
seleção para aquisição do software (pacote ou sob medida 
ou modificações)
14.598-5 Para Avaliadores: descreve um processo para avaliação de produtos de software (visão do usuário)
14.598-6
Documentação dos módulos de avaliação. Define a 
estrutura e o conteúdo da documentação que será usada na 
descrição dos Módulos de Avaliação. 
As Partes da norma 14.598
5
Avaliar a qualidade de um software 
é:
Verificar, através de técnicas e 
atividades operacionais, o quanto 
os requisitos são atendidos
Tais requisitos expressam as 
necessidades explicitadas e 
objetivam definir as características 
do SW, para que se possa examiná-
lo e compreende-lo
A proposta da Norma ISO/IEC 14.598
6
As razões técnicas 
para deficiências e 
limitações do produto
Produtos, 
mesmo que 
indiretamente
Plano de ações: 
Como o produto 
pode evoluir
Razões para avaliar a qualidade do 
software
Identificar e 
entender
Comparar
Formular
7
Relação entre as normas da série
8
• Pressupõe existência de 
função de suporte a 
Organização para todos os 
seus projetos de avaliação.
• Desenvolvimento de SW
• Aquisição de SW
• Avaliação de SW
NBR ISO/IEC 14.598-2 (Planejamento e 
Gerenciamento)
• Criação de critérios para 
benchmark
• Avaliação da eficácia e qualidade 
de qualquer aquisição
• Obtenção de padrões e de 
informações técnicas
• Desenvolvimento de padrões e 
ferramentas
• Desenvolvimento de software
• Coleta e análise de resultados de 
avaliações
• Distribuição dos resultados de 
avaliação
• Facilitação da transferência de 
tecnologia e suporte a projetos 
de avaliação
9
Estrutura de Um Plano de Avaliação 
Quantitativa
• Introdução
• Objetivos
• Características da qualidade aplicáveis
• Lista de prioridades
• Objetivos da qualidade
• Cronograma
• Definição de responsabilidade
• Categorias de medição
• Uso e análise de dados
• Relatórios
• Demais requisitos de interesse
10
• Define requisitos e orientações para a avaliação 
dos produtos intermediários de software, ou 
seja, avaliar durante a fase de desenvolvimento 
e manutenção: Métricas, revisões, RTF e etc. 
• Objetiva encontrar discrepâncias entre a 
qualidade esperada e a qualidade atual do 
produto de software, pela avaliação.
• Usada por:
• Gerentes de Projeto (monitorar 
desenvolvimento)
• Analistas de Sistemas (levantar requisitos)
• Equipe de Manutenção (demandas da fase)
NBR ISO/IEC 14.598-3 
(Desenvolvimento)
11
1. Inicia o processo de Aquisição. 
2. Nasce a necessidade: Obter, Desenvolver ou Melhorar 
um Produto ou Serviçode SW
1. Elaboração dos documentos de Requisitos de Aquisição
2. Determinar pontos de controle para revisão e auditoria 
do processo
1. Seleção de fornecedores e suas capacidades
2. Contrato negociando: custo e cronograma 
3. Atenção para controle das alterações de contrato
1. Avaliação durante a vigência do contrato, considerando
• Aceitação do produto ou serviço
• Entre do produto ou serviço
1. Aceitação e entrega do produto ou serviço final, 
obedecendo os critérios de qualidade e aceitação 
previamente definidos.
Iniciação
Preparação do pedido 
de proposta
Preparação e 
atualização do controle
Monitoração do 
fornecedor
Aceitação e conclusão
NBR ISO/IEC 14.598-4 (Aquisição)
12
NBR ISO/IEC 14.598-5 
(Avaliação)
Os avaliadores podem ser 
especificamente:
Os laboratórios de testes
As equipes de testes integradas de 
organizações de produção ou de 
distribuição de software
Os compradores ou usuários de 
software de integradoras de 
sistemas
As organizações que realizam 
comparações de softwares
13
Estabelecer requisitos 
de avaliação
Especificar a 
avaliação
Projetar a avaliação
Executar a avaliação
Estabelecer o propósito da avaliação
Identificar tipos de produtos a serem avaliados
Especificar modelo de qualidade
Selecionar métricas
Estabelecer níveis de pontuação para as métricas
Estabelecer critérios para julgamento
Produzir o plano de avaliação
Obter as medidas
Comparar com critérios
Julgar os resultados
NBR ISO/IEC 14.598-5 (Avaliação)
14
Repetidas avaliações, de um mesmo produto, pelo mesmo 
avaliador, com a mesma especificação de avaliação 
devem produzir resultados aceitos como idênticos
Repetidas avaliações, de um mesmo produto, com a mesma 
especificação de avaliação e avaliador diferente devem 
produzir resultados idênticos
A avaliação não deve ser influenciada por nenhum resultado 
parcial
Os resultados não devem ser influenciados por opinião do 
avaliador (subjetividade)
Repetitividade
Reprodutividade
Imparcialidade
Objetividade
ISO/IEC 14.598-5-Características 
esperadas do processo de Avaliação
15
Qualidade de 
software
Fabiano Gonçalves dos Santos
Atividade 6
TÉCNICO DE LABORATÓRIO - INFORMÁTICA - GO - 2009 - 
UFG (Informática, questão 50). De acordo com a ISO/IEC 14598-4, 
no “Processo de Avaliação”, a reprodutividade é caracterizada por: 
(cód. Q40647)
a)uma avaliação que não deve ser influenciada por nenhum 
resultado particular ou por opiniões, mesmo quando realizada por 
um único avaliador.
b)uma avaliação em que os resultados são factuais, ou seja, não 
são influenciados pelos sentimentos ou pelas opiniões de um 
avaliador
c)uma avaliação repetida de um mesmo produto, com mesma 
especificação de avaliação, realizada pelo mesmo avaliador, com 
resultados que podem ser aceitos como idênticos.
d)uma avaliação do mesmo produto, com mesma especificação de 
avaliação, realizada por avaliadores diferentes, produzindo 
resultados que podem ser aceitos como idênticos.
17
TÉCNICO DE LABORATÓRIO - INFORMÁTICA - GO - 2009 - 
UFG (Informática, questão 50). De acordo com a ISO/IEC 
14598-4, no “Processo de Avaliação”, a reprodutividade é 
caracterizada por: 
a)uma avaliação que não deve ser influenciada por nenhum 
resultado particular ou por opiniões, mesmo quando realizada 
por um único avaliador.
b)uma avaliação em que os resultados são factuais, ou seja, 
não são influenciados pelos sentimentos ou pelas opiniões de 
um avaliador
c)uma avaliação repetida de um mesmo produto, com mesma 
especificação de avaliação, realizada pelo mesmo avaliador, 
com resultados que podem ser aceitos como idênticos.
d)uma avaliação do mesmo produto, com mesma especificação 
de avaliação, realizada por avaliadores diferentes, produzindo 
resultados que podem ser aceitos como idênticos.
18
A norma 14598, visa apoiar a avaliação de 
software, oferecendo diretrizes para tal. A nova 
visa a avaliação sob 3 pontos de vistas, que 
são:
a)Programador, Analista e Adquirente
b)Gerente do projeto, projetista de SW e 
avaliador
c)Desenvolvedor, Adquirente e Avaliador
d)Gerente de sistemas, analista de redes e 
analista de sistemas
19
A norma 14598, visa apoiar a avaliação de 
software, oferecendo diretrizes para tal. A nova 
visa a avaliação sob 3 pontos de vistas, que 
são:
a)Programador, Analista e Adquirente
b)Gerente do projeto, projetista de SW e 
avaliador
c)Desenvolvedor, Adquirente e Avaliador
d)Gerente de sistemas, analista de redes e 
analista de sistemas
20
A norma 14598 possui relação com a norma 
9126, que estabelece:
a)Métricas externas, Métricas internas e 
Métricas de qualidade de uso
b)Métricas externas, métricas internas e 
métricas medianas
c)Usabilidade, Eficiência e eficácia.
d)Repetitividade, produtividade e objetividade
21
A norma 14598 possui relação com a norma 
9126, que estabelece:
a)Métricas externas, Métricas internas e 
Métricas de qualidade de uso
b)Métricas externas, métricas internas e 
métricas medianas
c)Usabilidade, Eficiência e eficácia.
d)Repetitividade, produtividade e objetividade
22
Qualidade de 
software
Fabiano Gonçalves dos Santos
Aula 7
• Conceito de processo de software 
–“o que as pessoas fazem, por meio de 
atividades, métodos, práticas e 
transformações para desenvolver, manter 
e melhorar software”
• Capacidade do Processo
–Habilidade do processo em ser executado 
de forma eficiente e eficaz com a presença 
de características relevantes
Conceitos importantes
2
• Execução consistente
• Flexibilidade para adaptação de 
especificidades
• Documentação por meio de fluxos, texto, fig
• Deve ser apropriado para trabalho
• Treinamento e evolução contínua
• Manutenção para garantir evolução
• Controle de mudanças – garantir integridade
• Apoio de equipe, ferramentas e produtos.
Características relevantes
3
• As diretrizes propostas cobrem questões 
como:
– Entendimento dos requisitos funcionais 
entre contratante e contratado;
– Uso de metodologias consistentes para 
o desenvolvimento de software;
– Gerenciamento de projeto desde a 
concepção até a manutenção.
• Ponto central: Documentação
Questões cobertas pela Norma 9000-3
4
• A política de qualidade deve ser definida, 
documentada, comunicada, implementada e 
mantida por uma gerência.
• descreve: atitude da organização quanto a 
qualidade
• Define: Estrutura Organizacional adequada p/ 
gerenciar a qualidade
• Atribui responsabilidades
• Designa representante para controlar sistema 
de qualidade
Responsabilidades da gerência
5
Responsabilidades da Gerência
• Identificar e fornecer recursos adequados 
para execução do sistema de qualidade
• Possibilitar que os gerentes possam usar os 
procedimentos e aprimorar a eficiência do 
sistema de qualidade.
• Revisar periodicamente o sistema de 
qualidade com vistas ao seu aprimoramento
• Manter os registros de todas as revisões.
6
• O sistema de qualidade deve ser documentado – como um 
manual.
• Plano de Qualidade: controle da qualidade
– Detalhar os procedimentos para:
• Controlar a gerência de configuração
• Verificar o produto
• Validar o produto
• Não conformidade
– Mostrar como cumprir os requisitos do sistema de 
qualidade 
– Integrados com atividades do ciclo de vida – qualidade 
em todo o projeto
Requisitos do sistema da qualidade
7
• Tem que ser completos e bem definidos 
–Atender as exigências contratuais.
• Procedimentos para revisão do contrato 
• Revisão junto a clientes.
–Ajuda na aceitação entre as partes
• Garantir a comunicação a empresa, das 
alterações contratuais.
• Contratado e contratante devem concordar 
com as partes do contratoRevisão dos Requisitos Contratuais
8
• Documentar para assegurar cumprimento 
dos requisitos.
–Planejamento
–Método para revisão
–Mudanças e verificações ocorridas
• Planos de Procedimentos
–Executado de forma disciplinada, 
assegurando um desenvolvimento 
sistemático.
Revisão da fase de projetos
9
 Definir o projeto
 Listar os objetivos do projeto
 Apresentar o cronograma
 Definir entradas e saídas (com cliente)
Posterior validação é recomendada
 Identificar projetos relacionados
 Análise de riscos
 Estratégias de controle
As revisões, demonstrações e teste
Revisão da fase de projetos: Plano de 
desenvolvimento
10
 A responsabilidade dos participantes no 
desenvolvimento do software. 
 Os meios de transmissão das informações
Metodologia de desenvolvimento
Os Modelos
 O comprometimento do cliente em aceitar, 
cooperar e dar suporte(ou não)
 A agenda de revisões do projeto para avaliar 
as atividades e os resultados alcançados
Revisão da fase de projetos: Plano de 
desenvolvimento
11
• O Controle da norma orienta para que haja 
procedimento para:
– Avaliação de fornecedores (produtos e serviços)
–qualidade aos produtos e serviços adquiridos
– Seleção
– Avaliação
– Monitoramento
– Controle dos subcontratados 
– Verificação dos produtos comprados
– Registro e acompanhamento de subcontratados
Requisitos de aquisição
12
• Necessidade de procedimentos para a 
identificação do produto por item, série ou lote 
durante todos os estágios da produção, entrega 
e instalação. 
• O produto deve poder ser rastreado através 
dessa identificação.
• A coerência nos procedimentos possibilita que 
todos os passos do caminho do produto 
(manipulação, armazenamento, produção, 
envio, instalação e serviço) sejam devidamente 
controlados. 
Identificação dos Controles dos 
Produtos
13
• O acompanhamento do produto de software 
e seus componentes durante o ciclo de vida. 
Para tanto:
–métodos de gerência de configuração 
(configuration management) - usados para 
identificar e acompanhar o software e 
componentes.
Identificação dos Controles dos 
Produtos
14
• Requer que todas as fases de processamento de um 
produto sejam controladas (por procedimentos, 
normas, etc.) e documentadas. 
• Os procedimentos para planejar, monitorar e 
controlar seu processo de produção, instalação e 
manutenção devem ser devidamente documentados. 
• Um bom sistema pode manter registros que 
monitorem e controlem processos, pessoal e 
equipamentos. Da mesma forma, procedimentos 
desenvolvidos podem controlar os processos de 
reprodução, liberação e instalação do software 
(software replication, release and installation)..
Processo de Controle de Requisitos
15
• Controlar atividades de teste e inspeção.
–Exemplo: documentar Planos de Testes
• Inspecionar as matérias-primas antes do uso
• Elaborar procedimentos para inspecionar, 
testar e verificar: produto atende aos 
requisitos?
• Produtos adquiridos por terceiros ou próprios: 
verificar os requisitos antes de 
disponibilizados para uso
Desenvolvimento ou comércio
Testes e Inspeções dos Produtos
16
• Indicar no produto demonstração por quais 
inspeções ele passou e se foi aprovado.
• Documentar status do software e de seus 
componentes - produção, instalação e 
manutenção.
• Somente produtos que tenham passado por 
todos os teste e inspeções são 
subseqüentemente usados ou vendidos a 
clientes. 
Testes e Inspeções dos Produtos
17
 Procedimentos para:
 Assegurar que produto não conforme aos requisitos 
de qualidade seja impedido de ser utilizado
 Alertar o uso inapropriado do produto e notificar a 
todos: produto não se adequar a requisitos
 Identificar, corrigir, testar, discutir e registrar as não 
conformidades-procedimentos adequados
 Caso os problemas não sejam resolvidos, esse deve 
ser guardado em local separado
 Os produtos de software que sofreram modificações 
devem passar por novos testes
 Regressão
Controle de Não conformidade
18
Qualidade de 
software
Fabiano Gonçalves dos Santos
Atividade 7
20
Dúvida
• Quando falamos de revisões de software, o 
que é importante que o engenheiro 
considere no planejamento? 
21
Dúvida
Devem ser consideradas as seguintes questões: 
•quem participa?
•qual informação é requerida antes da revisão?
•quais pré-condições que devem ser satisfeitas 
antes que a revisão possa ser conduzida? 
• Como Organizar?
• Gerar checklists ou outra 
indicação do que deve ser coberto 
na revisão;
• Determinar as condições de 
término ou critérios que devem 
ser satisfeitos para que a revisão 
termine;
• Gerar registros e documentos que 
devem ser produzidos.
Qualidade de 
software
Fabiano Gonçalves dos Santos
Aula 8
 A comunidade de software entende a 
importância de criar normas, modelos e 
métodos para regular e orientar a 
definição de processos de software.
Qualidade de software
2
• Conjunto de tarefas ordenadas: uma série 
de etapas que envolvem atividades, 
restrições e recursos para alcançar a saída 
desejada.
• Para Pfleeger (2004), envolve um conjunto 
de métodos, técnicas, ferramentas e 
pessoas de forma a prescrever todas suas 
atividades
• O processo de criação de um produto pode 
ser concebido como um ciclo de vida
Conceito e significado do processo
3
• Alinha estrategicamente a organização.
• Foca a organização no cliente.
• Obriga a organização a prestar contas pelo 
desempenho dos seus processos.
• Alinha a força de trabalho com os processos.
• Evidencia a necessidade de alocação de 
recursos.
• Melhora a eficiência.
Por que gerenciar POR processos?
4
• Processos fortemente coesos
–Suas partes - fortemente relacionadas e 
afins
• Processos fracamente acoplados
–O mais independentes uns dos outros
• Modular
–Executa 1 função do ciclo de vida
Os processos da ISO/IEC 12207
5
 A NBR ISO/IEC 12207 define
 Processos de Ciclo de Vida de Software 
Estabelecer uma estrutura comum para os 
processos de ciclo de vida de software 
Para ajudar as organizações a 
compreenderem a aquisição e fornecimento 
de software e, assim, conseguirem firmar 
contratos e executarem projetos de forma 
eficaz. 
Base da NBR ISSO/IEC 12207
6
Prototipação
7
Espiral
8
Clássico
9
• A proposta da norma é a sua utilização desde a 
concepção até a descontinuidade do produto 
de software ressaltando:
a importância do envolvimento de todos 
aqueles responsáveis pela produção, 
manutenção e operação do software tais 
como adquirentes, fornecedores, operadores, 
desenvolvedores, mantenedores, gerentes, 
profissionais de qualidade e usuários. 
A ISO / IEC 12207: Proposta
10
• Cabe às empresas a responsabilidade de 
adaptação dos processos, atividades e 
tarefas da norma a fim de atender ao 
modelo de ciclo de vida para o projeto de 
software. 
• De acordo com a natureza dos processos 
esses se agrupam da seguinte forma:
Fundamental / Apoio / Organizacional / 
Adaptação
A ISO / IEC 12207: Especificação
11
• Iniciam o ciclo de vida
• Comandam a execução dos demais.
• Aquisição – inicia o ciclo 
• Fornecimento – responde pela execução 
dos 3 itens abaixo
• [1] Desenvolvimento
• [2] Operação
• [3] Manutenção – modificação para 
alteração ou melhoria.
Processos fundamentais
12
• Define as atividades a serem executadas pela 
organização que adquire ou subcontrata um produto 
ou serviço de software. 
• O propósito do Processo de Aquisição é obter um 
produto e/ou serviço que satisfaça a necessidade 
expressa pelo cliente. 
• O processo inicia com a identificação de uma 
necessidade do cliente e terminacom a aceitação do 
produto e/ou serviço 
• A ISO/IEC 12207 define o propósito e os resultados 
para os sub processos de Preparação para 
Aquisição, Seleção de Fornecedor, Monitoração do 
Fornecedor e Aceitação pelo Cliente.
Processos Fundamentais – Aquisição
13
• O Processo de Fornecimento é a sustentação para 
a execução dos processos de desenvolvimento, 
manutenção e/ou operação do produto ou serviço 
de software. 
• Inicia: preparação de proposta para atendimento ao 
pedido de proposta de aquisição 
• Encerra: entrega do produto ou serviço de software. 
• A ISO/IEC 12207 define o propósito e os resultados 
para os subprocessos de Proposta do Fornecedor, 
Acordo Contratual, Liberação do Produto e Suporte 
à Aceitação do Produto.
Processos fundamentais – Fornecimento
14
• Contém as atividades e tarefas para o 
desenvolvimento do software.
• O propósito é transformar um conjunto de 
requisitos em um software que atenda às 
necessidades do cliente 
• A ISO/IEC 12207 define o propósito e os 
resultados para os sub processos de:
• Elicitação de Requisitos, 
• Análise dos Requisitos do Sistema, 
• Projeto da Arquitetura do Sistema, 
• Análise dos Requisitos do Software, 
Processos fundamentais - Desenvolvimento
15
• Projeto da Arquitetura do Software, 
• Projeto Detalhado do Software, 
• Construção do Software, 
• Integração do Software, 
• Teste do Software, 
• Integração do Sistema, 
• Teste de Sistema e 
• Instalação do Software, 
• Apoio a Aceitação do Software
Processos fundamentais - Desenvolvimento
16
Especificar requisitos
de software
Estabelecer e manter
a rastreabilidade
Verificar os requisitos 
de software
Estabelecer linha base 
e comunicar os requisitos 
de software
O processo se organiza em TAREFAS
Processos Fundamentais – 
Desenvolvimento: TAREFAS
17
• Contém as atividades e tarefas para a 
operação do software e suporte operacional 
aos usuários. 
• O propósito do Processo de Operação é 
operar o produto de software no seu 
ambiente e fornecer suporte aos clientes
• A ISO/IEC 12207 define o propósito e os 
resultados para os sub processos de Uso 
Operacional e Suporte ao Cliente
Processos Fundamentais – Operação
18
• Ativado quando o produto de software é submetido a 
modificações no código e na documentação 
associada devido a um problema ou a uma 
necessidade de melhoria ou adaptação.
• Este processo ainda inclui as possibilidades de 
migração e descontinuidade do produto de software.
• O propósito do Processo de Manutenção é modificar 
um produto de software ou sistema após a sua 
entrega apara corrigir falhas, melhorar o 
desempenho ou outros atributos, ou adaptá-lo a 
mudanças do ambiente 
Processos Fundamentais – Manutenção
19
• Responsabilidade da organização que o 
executa
• Proporciona qualidade aos demais 
processos
• Exemplo: apoiar a documentação do 
software 
Processo - Apoio
20
• Responsabilidade da organização que o executa
• São chamados pelos outros processos e são 
independentes do que esta sendo executado.
Processo Organizacional
Gerência
Infraestrutura
Melhoria
Recursos humanos
Gestão de ativos
Gestão de programa 
de reuso
Engenharia de domínio
21
Atividade Descrição 
Identificação do 
Ambiente do Projeto
Identificação do projeto: modelo e atividades de 
ciclo de vida; requisitos do sistema; políticas, 
procedimentos e estratégias organizacionais; 
tamanho, e tipos de sistema, produto ou serviço 
de software; e quantidade de pessoas
Solicitações de 
Informações
Avaliar os impactos das informações nas 
decisões de adaptação dos usuários, pessoal 
de suporte, gerentes de contrato e potenciais 
proponentes.
Seleção de Processos, 
Atividades e Tarefas
Definição de processos, atividades e tarefas 
que serão executadas com a devida 
documentação desenvolvida e seus respectivos 
responsáveis.
Documentação de 
Decisões e Motivos de 
Adaptação
 
Requer a documentação das decisões de 
adaptação juntamente com seus motivos.
Processo de adaptação
22
• Não se propõe a determinar métodos, 
ferramentas, treinamentos, métricas ou 
tecnologias empregadas. 
• Por que?
A norma é mundial / acompanhar a 
evolução da engenharia de software nas 
diversas culturas
• Permite que seja utilizada em qualquer 
modelo de ciclo de vida, método ou técnica 
de engenharia de software e linguagem
A ISO / IEC 12207 Especifica
23
Qualidade de 
software
Fabiano Gonçalves dos Santos
Atividade 8
25
Questão de concurso!
FCC - 2010 - TRF - 4ª REGIÃO - Analista Judiciário - 
Tecnologia da Informação
Sobre a norma ISO/IEC 12207, considere:
I. Define objetivos, níveis de 
maturidade organizacional ou de 
capacidade de processo. 
II. Provê uma estrutura para que uma 
organização defina seus processos. 
III. Cobre também a garantia da 
qualidade, que se estende desde 
os produtos adquiridos ou 
fornecidos até a qualidade e 
melhoria dos processos de 
implementação.
Quais as informações estão corretas?
26
I. Define objetivos, níveis de maturidade 
organizacional ou de capacidade de processo. 
II. Provê uma estrutura para que uma organização 
defina seus processos. 
III. Cobre também a garantia da qualidade, que se 
estende desde os produtos adquiridos ou 
fornecidos até a qualidade e melhoria dos 
processos de implementação.
IV. I, apenas.
V. I, II e III.
VI. I e II, apenas.
VII.II e III, apenas.
VIII.III, apenas.
27
I. Define objetivos, níveis de maturidade 
organizacional ou de capacidade de processo. 
II. Provê uma estrutura para que uma organização 
defina seus processos. 
III. Cobre também a garantia da qualidade, que se 
estende desde os produtos adquiridos ou 
fornecidos até a qualidade e melhoria dos 
processos de implementação.
IV. I, apenas.
V. I, II e III.
VI. I e II, apenas.
VII.II e III, apenas.
VIII.III, apenas.
28
Outra?
FCC - 2010 - TRT - 9ª REGIÃO (PR) - Técnico Judiciário - 
Tecnologia da Informação
A norma NBR ISO/IEC 12207 estabelece:
a)os processos fundamentais, organizacionais e de apoio 
do ciclo de vida de software.
b)as atividades de tecnologia da informação agrupadas em 
processos e esses em domínios.
c)os estágios do ciclo de vida dos serviços de tecnologia 
da informação.
d)um modelo de áreas de processos representadas por 
categoria e por estágios.
e)um modelo de processos de software, um método de 
avaliação e um modelo de negócio.
29
Outra?
FCC - 2010 - TRT - 9ª REGIÃO (PR) - Técnico Judiciário - 
Tecnologia da Informação
A norma NBR ISO/IEC 12207 estabelece:
a)os processos fundamentais, organizacionais e de 
apoio do ciclo de vida de software.
b)as atividades de tecnologia da informação agrupadas em 
processos e esses em domínios.
c)os estágios do ciclo de vida dos serviços de tecnologia 
da informação.
d)um modelo de áreas de processos representadas por 
categoria e por estágios.
e)um modelo de processos de software, um método de 
avaliação e um modelo de negócio.
Qualidade de 
software
Fabiano Gonçalves dos Santos
Aula 9
 A ISO/IEC 15504  SPICE (Software 
Process Improvement and Capability 
Determination)
norma para definição de processos de 
desenvolvimento de software. 
Apresenta níveis de capacidade para 
cada processo. 
 Foca na avaliação de processos: 
investigação e análise organizada
ISO / IEC 15504
2
O que é?
• Define requisitos para Avaliação de Processo;
• Na prática, é utilizado com Modelo de Referência 
para Melhoria de Processo.
Avaliação em 2 Contextos:
• Melhoria Contínua (otimização)
– Entender o estado dos processos
– Avaliação identifica oportunidades de melhoria
– Foca na melhoria de processo 
• Determinação da Capacidade
– Determinara adequação dos processos 
– Geralmente realizada por quem tem interesse em 
contratar a organização avaliada como fornecedor 
Visão geral da norma 15504
3
• O modelo de avaliação de processo é 
organizado numa arquitetura de níveis.
• Nível 1: três categorias de processos
• Fundamentais / Organizacionais / Apoio
• Nível 2: composto por dez grupos de 
processo que são alocados em cada uma 
das categorias de processo. 
• Nível 3: 48 grupos de processos
ISO/IEC 15504
4
Níveis de capacidade
• Nível 0 – Processo incompleto
–Não tem atributos
• Nível 1 – Processo executado
–AP1.1: Atributo de execução de processo
• Nível 2 – Processo gerenciado
–AP2.1: Atributo da gerência de execução
–AP2.2: Atributo da gerência de produto de 
trabalho
5
Níveis de capacidade
• Nível 3 – Processo estabelecido
–AP3.1: Atributo de definição de processo
–AP3.2: Atributo de implementação de 
processo
• Nível 4 – Processo previsível
–AP4.1: Atributo de medição de processo
–AP4.2: Atributo de controle de processo
• Nível 5: Processo em otimização
–AP5.1: Atributo de inovação de processo
–AP5.2: Atributo de otimização do processo
6
A avaliação
Os Requisitos para uma avaliação compatível com a 
ISO/IEC 15504 cobrem:
•Plano da Avaliação
•Responsabilidades
•Processo de Avaliação
– Processo documentado com no mínimo:
• Planejamento
• Coleta de dados
• Validação dos dados
• Atribuição de notas
• Registro dos resultados
•Resultado da Avaliação
7
• Descreve um guia para orientações de 
melhorias no processo (ref: modelo de 
processo)
• Não pressupões modelos, tecnologias ou 
metodologias
• Não define um método explícito de avaliação. 
Define os requisitos
Melhoria do processo
Examina 
necessidade da 
organização
Inicia processo 
de melhoria Avalia processo
Planeja 
melhoria
Implementa 
melhoria
Confirma 
melhoria
Mantém 
melhoria
Monitora 
desempenho
8
• 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.
Melhoria do processo
9
• Modelo de referência 
• Fornece orientações para o desenvolvimento de 
processos de software
• Objetivos
– Eliminar inconsistências
– Aumentar clareza e entendimentos
– Estabelecer regras de construções uniformes e 
consistente com ISO/IEC 15504
• Não define como processo será implementado
Objetivos do CMMI
10
• O CMMI pode ser considerado:
• Um modelo de capacidade
• Um modelo de maturidade. 
• O alcance do nível de maturidade de 
processos se faz quando os processos 
alcançam uma determinada capacidade, ou 
seja, tem mecanismos que garantem a 
repetição sucessiva de bons resultados 
principalmente à qualidade, custos e prazos.
CMMI
11
Definir a área de processo
Definir seu nível de Capacitação
CMMI: Representação contínua
Áreas de processo
Objetivos 
específicos
Objetivos 
gerais
Práticas 
específicas
Práticas
gerais
Níveis de 
capacitação
12
• Oferece flexibilidade
• Permite selecionas uma área de processos a ser 
melhorada ou a ordem em que as melhorias vão ser 
feitas.
• Há dependências de processos:
• Para implementar Analise de Requisitos, é preciso 
ter o processo de Gestão de Requisitos
• Uma empresa pode por exemplo terceirizar Testes e 
portanto não se preocupar com essa área e precisa 
forcar em Requisitos e gerenciamento do projeto  
Empresa foca nas áreas de interesse.
CMMI: Representação contínua
13
• Cada Processo: NÍVEL DE CAPACIDADE: 0 a 5. 
• Com isso, trabalha as áreas de interesse, 
conforme estratégia definida.
• Útil: conhece-se bem os problemas da empresa. 
• Sabe-se os processos a serem melhorados
• Sabe-se da dependência entre esses processos.
• Níveis de Capacidade são determinados por Metas 
 Genéricas: 1 para cada nível.
• Capacidade 1: atingir meta genérica 1
• Capacidade 2: atingir metas genéricas 1 e 2
CMMI: Representação contínua
14
Definir Nível de Maturidade
CMMI: Representação por Estágios 
(TODA a empresa)
Áreas de processo
Objetivos 
específicos
Objetivos 
gerais
Práticas 
específicas
Práticas
gerais
Níveis de 
maturidade
15
• A representação em estágios organiza as áreas 
de processos em 5 níveis de maturidade para dar 
suporte e guiar a melhoria dos processos. 
• A representação em estágios agrupa as áreas de 
processos por nível de maturidade, indicando 
quais áreas de processos implementar para 
atingir cada nível de maturidade. 
• Os níveis de maturidade representam um 
caminho de melhoria de processos ilustrando a 
evolução da melhoria para a organização toda 
que busca a melhoria de processos
CMMI: Representação por Estágios 
(TODA a empresa)
16
CMMI – Equivalência entre níveis
Nível de Capacitação Nível de Maturidade
Nível 0 Incompleto
Nível 1 Realizado Inicial
Nível 2 Gerenciado Gerenciado
Nível 3 Definido Definido
Nível 4 Quantitativamente Gerenciado
Quantitativamente 
Gerenciado
Nível 5 Otimização Otimização
17
CMMI – Semântica dos Níveis
• Nível 0
–Não realizado ou realizado parcialmente
–Um ou mais objetivos específicos não 
estão satisfeitos
• Nível 1
–Processo muitas vezes ad hoc ou caóticos
–Satisfaz os objetivos específicos
–Suporta o desenvolvimento de produtos de 
trabalho
18
CMMI – Semântica dos Níveis
• Nível 2
–Possui infraestrutura básica de suporte ao 
processo
–Planejado e executado de acordo com 
políticas
–Suporta profissionais capacitados de 
produzir os produtos de controle necessários
–Monitorado, controlado e revisado
–Assegura manutenção das práticas mesmo 
sob stress
19
CMMI – Semântica dos Níveis
• Nível 3
–Descrito mais rigorosamente
–Práticas dos processos mais homogêneas
–Monitoramento constante, levando em 
consideração mais variáveis
• Nível 4
–Controlado por meio de técnicas 
quantitativas e estatísticas (previsibilidade)
–Desempenho do processo é critério de 
gerenciamento
20
CMMI – Semântica dos Níveis
• Nível 5
–Entendimento das causas comuns de 
variação inerentes ao processo
–Aprimoramento contínuo
21
• Não aborda aspectos de operações de TI
– Gerenciamento de segurança
– Mudança e configuração
– Planejamento de capacidade
– Diagnóstico e funções de help desk
• Estabelece metas, mas não diz como atingir
• Poucas referências e informações de 
organizações que adotaram o modelo CMMI
– Aquisição e treinamento caros
Restrições CMMI
22
Qualidade de 
software
Fabiano Gonçalves dos Santos
Atividade 9
24
CMMI
• O CMMI está dividido em 5 níveis de 
maturidade que atestam o grau de evolução 
em que uma organização. Quais são eles? 
CMMI – 5 Níveis
• Nível 1 - Inicial: os processos normalmente 
estão envoltos num caos decorrente da não 
obediência ou ainda, inexistência de 
padrões; 
• Nível 2 - Gerenciado: os projetos têm seus 
requisitos gerenciados neste ponto. Além 
disso, há o planejamento, a medição e o 
controle dos diferentes processos; 
25
CMMI – 5 Níveis
• Nível 3 - Definido: os processos já estão 
claramente definidos e são compreendidos 
dentro da organização. Os procedimentos se 
encontram padronizados, além de ser 
preciso prever sua aplicação em diferentes 
projetos; 
• Nível 4 - Gerenciado Quantitativamente: 
ocorre o aumento da previsibilidade do 
desempenho de diferentes processos, uma 
vez que os mesmos já são controlados 
quantitativamente;