Qualidade_Software_Aulas

Prévia do material em texto

Centro Universitário Newton Paiva
Prof. Iremar Nunes de Lima
iremar@portaldba.com.br
http://lattes.cnpq.br/0000426561067083
Qualidade de Software
Material disponível no Google Drive:
goo.gl/9eBAuQ
Você sabia ?
A grande maioria das empresas de 
software no Brasil gasta 70% do 
tempo de desenvolvimento 
corrigindo erros, ao invés de 
inovar e desenvolver novas 
soluções?
Plano de Ensino
Bibliografia
• Artigos disponibilizados no ambiente Newton Virtual e 
pasta da disciplina.
• PFLEEGER, Shari Lawrence. Engenharia de software : teoria 
e prática. 2. ed. São Paulo: Prentice Hall, 2004. 537 p.
• PRESSMAN, Roger S. Engenharia de software. São Paulo: 
Makron Books do Brasil, 2010. 1056 p. 
• SOMMERVILLE, Ian. Engenharia de software. 8. ed. São 
Paulo: A. Wesley publishing company, 2010. xiv, 552 p.
• BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: 
guia do usuário. Rio de Janeiro: Campus, 2000. 472 p. 
Minha Biblioteca: 
http://minhabiblioteca.newtonpaiva.br
Minha Biblioteca: 
http://minhabiblioteca.newtonpaiva.br
Bibliografia Complementar: Leia a capa
Bibliografia Complementar: Artigos atuais DevMedia
Qualidade de Software
• Crosby (1992): 
– “A qualidade é conformidade aos requisitos”
• Propósito da qualidade:
– Satisfazer o Cliente.
• Como?
– Sistema sem bugs (defeitos).
– Fácil de usar, rápido, etc. 
– Ter documentação.
– Ser bem testado.
– Ter métodos, processos e planejamento.
– Gerenciar e cumprir cronogramas. 
– Ter processos para gerenciar pessoas/equipes.
– Controlar, Gerenciar, Medir e Melhorar os processos (BPM).
Uma crise de mais de 30 anos
• Crise de software - os problemas na década de 70:
–Cronogramas não são observados.
–Projetos com tantas dificuldades abandonados.
–Módulos que não operam corretamente.
– Sistemas que não fazem o esperado.
– Sistemas difíceis de usar sendo descartados.
– Sistemas que param de funcionar.
• Ainda vivemos a crise de software?
• Somos capazes de construir software de 
qualidade?
Já temos ...
• Metodologias.
• Técnicas.
• Ferramentas / Tecnologias.
• Organismos normativos:
– ISO – Internation Organization for Standardardization.
– IEC – International Eletrotechnical Commission.
– IEEE – Institute of Eletronical na Electronics Enginerrs.
– ABNT – Associação Brasileira de Normas Técnicas. 
• Normas é o que não falta !
• Como desenvolver softwares aderentes a normas ?
• Será que a conformidade às normas é qualidade ?
Principais Normas para Qualidade de Software
CMMI – Capability Maturity Model Integration
(Modelo de Maturidade em Capacitação – Integração)
• Segundo os idealizadores do CMM, principal 
causa dos problemas é a falta de um processo 
de desenvolvimento de software claramente 
definido e efetivo.
• Conhecer os processos significa conhecer 
como os produtos e serviços são planejados, 
produzidos e entregues.
• Princípio: Empresa evolui aos poucos -
maturidade dos processos. 
Níveis (maturidade) do CMMI
CMMI - versão 1.3 – 2010 – Três modelos
• CMMI for Development (CMMI-DEV), voltado 
ao processo de desenvolvimento de produtos 
e serviços.
• CMMI for Acquisition (CMMI-ACQ), voltado 
aos processos de aquisição e terceirização de 
bens e serviços.
• CMMI for Services (CMMI-SVC), voltado aos 
processos de empresas prestadoras de 
serviços.
Organizações Imaturas:
• Processo improvisado. 
• Não existe base histórica.
• Não há maneira objetiva de julgar a qualidade 
do produto.
• Qualidade e funcionalidade do produto 
sacrificadas.
• Não há rigor no processo a ser seguido.
• Resolução de crises imediatas.
Organizações maduras:
• Processos são definidos e seguidos !
• Papéis e responsabilidades bem definidos. 
• Existe base histórica de dados dos projetos.
• É possível julgar a qualidade do produto. 
• A qualidade dos produtos e processos é 
avaliada.
• O processo pode ser acompanhado, 
atualizado, monitorado e melhorado.
• Existe comunicação entre o gerente e seu 
grupo.
CASE: SPEED SQUADRA – CMMI Nível 3
• Processos SPEED: Ferramentas: SQhoras/ Jira
CASE: SPEED SQUADRA – CMMI Nível 3
• Processos da Metodologia Definida
CASE: SPEED SQUADRA – CMMI Nível 3
• Fotos da fábrica
CASE: SPEED SQUADRA – CMMI Nível 3
• Fotos da fábrica
Métricas de Qualidade de Software
• Métricas de software são medidas associadas 
ao processo ou ao produto de software.
– Linhas de código.
–Ponto de função.
–Total de bugs identificados por projeto.
• Métricas permitem a quantificação de valores 
para a avaliação da qualidade.
• O foco do gerenciamento da qualidade de 
software deve estar baseado no registro de 
dados históricos dos projetos (métricas).
CMMI – NÍVEL 1 - INICIAL
• Processos são caóticos.
• Organização não possui ambiente estável de 
desenvolvimento de sistemas.
• Projetos apresentam problemas de cumprimento de 
prazos, custos e requisitos.
• A organização depende de “talentos” individuais para 
cumprir seus compromissos.
• Atenção: Isto não significa necessariamente que seus 
produtos finais são ruins. 
• Dificilmente é possível repetir sucessos anteriores pois 
dependem fortemente de indivíduos. 
• Documentação e testes dos sistemas são negligenciados.
CMMI – NÍVEL 2 – REPETÍVEL
• Projetos possuem requisitos gerenciados.
• Processos são planejados, medidos e controlados.
• Organização cumpre os cronogramas estabelecidos.
• Tarefas são analisadas e não-conformidades identificadas 
com alguma antecedência possibilitando ações 
corretivas.
• Existem marcos de entregas definidos no cronograma.
• Se for identificado problemas pode-se, por exemplo, 
alocar mais pessoas.
• Datas de entregas são acordadas com os stakeholders e 
revisadas sempre que necessário. 
• Acompanhamento do gerente para cumprir os prazos. 
CMMI – NÍVEL 3 - DEFINIDO
• Existem processos bem caracterizados, documentados e 
entendidos pelos atores.
• Padronização entre TODOS os processos.
• Nos processos são definidos procedimentos, ferramentas 
e métodos. 
• Maior nível de detalhe e rigor na descrição dos 
processos. 
• Acompanhamento mais rigoroso do cronograma.
• Medição com dados estatísticos já estão presentes 
(custos, cronogramas, horas por etapa, etc).
• Atenção: principal diferença entre nível 2 e 3: os 
procedimentos são padronizados para todos os projetos. 
CMMI – NÍVEL 4 - GERENCIADO QUANTITATIVAMENTE
• Processos são selecionados para contribuir com o 
desempenho geral dos demais.
• Uso intensivo de dados estatísticos e outas técnicas 
quantitativas (bugs por projeto, pontos de função por 
interação, status dos projetos, rentabilidade dos projetos)
• Projetos são traduzidos em números (comparar): facilitar 
a análise de desempenho da empresa, projetos, pessoas.
• Dados são armazenados em BD e gerenciados por 
sistemas, permitindo acompanhar dados históricos e 
identificar riscos. 
• Atenção: principal diferença entre nível 3 e 2: aumento 
da previsibilidade do desempenho dos processos de 
forma quantitativa (no nível 3 é qualitativa). 
CMMI – NÍVEL 5 - OTIMIZADO
• Melhoria contínua dos processos com revisão a cada 
projeto.
• Processos são continuamente melhorados com base no 
entendimento quantitativo das causas dos problemas 
identificados em cada projeto.
• Inovações e melhor uso de tecnologias e pessoas.
• Processos são medidos (nível 4) e agora avaliados e 
revisados se necessário. 
• Melhorias de processos é uma tarefa de TODOS.
• Análise e resolução de causas de problemas no 
desenvolvimento dos projetos. 
CMMI – Benefícios
• Uma maior confiabilidade no que refere ao cumprimento de 
prazos e custosque foram acordados (preocupação com a 
base histórica realista e confiável para estes fins).
• O gerenciamento das atividades relativas à produção de 
software aumenta consideravelmente.
• Uma maior qualidade nos softwares, pois processos bem 
definidos e controlados conduzem à produção de produtos 
mais confiáveis.
• A menor dependência da empresa para com seus 
especialistas. Com foco voltado para processos e melhoria 
contínua, além do uso intensivo de informações históricas, a 
organização deixa de depender única e exclusivamente de 
profissionais com um elevado grau de conhecimento técnico.
• A busca por melhorias contínuas nos processos cotidianos.
CMMI – CRÍTICAS
• Complexidade: muitos termos novos e detalhes difíceis 
de serem totalmente implantados.
• Documentação extensa e complexa.
• Em geral é necessário recorrer a consultorias 
especializadas com custo alto.
• Deve-se efetuar reorganizações dentro da empresa 
(resistências a mudanças naturais).
• Atores técnicos (analistas, programadores, etc) são 
obrigados a entender e aplicar os processos.
• O grau de envolvimento da alta administração, gerências, 
falta de comprometimento dos funcionários, falta de 
tempo dos envolvidos, rotatividade do pessoal.
• Vale a pena: custos x benefícios ?
CMMI – BRASIL – 2018 (abril)
https://sas.cmmiinstitute.com/pars/pars.aspx
MPS.BR
• Melhoria de Processos do Software Brasileiro
• Voltado para a realidade do mercado de pequenas e 
médias empresas de desenvolvimento de software no 
Brasil.
• Baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 e 
compatível com o CMMI.
• Desenvolvido pela Softex, interagindo com as 
universidades e com o Governo Federal. 
• Uma das principais vantagens do modelo é seu custo 
reduzido de certificação em relação as normas 
estrangeiras, sendo ideal para micro, pequenas e médias 
empresas que são a grande maioria no Brasil.
MPS.BR
MPS.BR
• G – Parcialmente Gerenciado: neste ponto inicial 
deve-se iniciar o gerenciamento de requisitos e de 
projetos.
• F – Gerenciado: introduz controles de medição, 
gerência de configuração, conceitos sobre aquisição 
e garantia da qualidade.
• E – Parcialmente Definido: considera processos 
como treinamento, adaptação de processos para 
gerência de projetos, além da preocupação com a 
melhoria e o controle do processo organizacional.
• C – Definido: aqui ocorre o gerenciamento de 
riscos.
MPS.BR
• D – Largamente Definido: envolve verificação, 
validação, além da liberação, instalação e 
integração de produtos, dentre outras atividades.
• A – Em Otimização: há a preocupação com 
questões como inovação e análise de causas.
• B – Gerenciado Quantitativamente: avalia-se o 
desempenho dos processos, além da gerência 
quantitativa dos mesmos.
MPS.BR
MPS.BR– BRASIL - 2015
Qualidade de Software:
Indivíduos e Equipes
Fatores Humanos na Qualidade de Software
• Pessoas desenvolvem software !
• Existem:
– Pressão no Desenvolvimento de Software.
– A cultura de horas extras.
– Aplicação de metodologias padronizadas: resistências.
– Conflitos interpessoais.
– Dificuldades da Alta Gerência em prover incentivos.
– Planos realísticos.
– Institucionalização dos processos.
– Investimentos no profissional de T.I.
– Avaliação da equipe de TI.
MELHORIA DE PROCESSOS INDIVIDUAIS E DE EQUIPES
• O problema:
– CMM e CMMI / MPS-BR: apresentam propostas para melhoria 
do desenvolvimento do software com foco nas organizações.
– Posteriormente percebeu-se a necessidade de melhorar os 
processos de trabalho dos indivíduos e das equipes.
• PSP: Personal Software Process
– Ano 2000 por Humphrey (um dos criadores do CMM).
– Foco na melhoria de processos do indivíduo, tornando a sua 
forma de trabalhar mais disciplinado.
• TSP: Team Software Process
– Foco na melhoria de processos de uma equipe de 
desenvolvimento (grupo de pessoas com um objetivo).
• CMMI: foco no “o que deve ser feito…”
• PSP/TSP – acrescentam o “como…”
PSP: Personal Software Process
• Processos em nível pessoal também precisam ser 
conhecidos, melhorados e controlados. 
• Indivíduos:
• Analistas (requisitos, sistemas, arquitetos, ADs, DBAs, etc).
• Desenvolvedores.
• Analistas de Testes.
• Gerentes / Coordenadores.
– Possibilitar ao desenvolvedor:
• Conhecer-se / Medir-se / Analisar-se / Aprender.
– PSP: É um framework para auxiliar o desenvolvedor a 
estimar e planejar suas tarefas, acompanhar sua 
performance em relação ao planejado e melhorar a 
qualidade dos produtos produzidos.
PSP: Personal Software Process
• Um processo pessoal para o desenvolvimento de 
software com definição de :
• Passos definidos
• Formulários
• Padrões
– O objetivo é fazer com que o indivíduo use 
gradativamente técnicas de Engenharia de Software.
• A faculdade não é suficiente !
– Como fazer que os compromissos assumidos pela 
gerência sejam transformados em compromissos 
pessoais?
• As pessoas só assumem compromissos pessoais 
voluntariamente.
• Cronogramas não são vistos como compromissos pessoais.
PSP: Personal Software Process
• Como ?
• Envolvimento dos indivíduos na elaboração do 
cronograma / planejamento.
• Envolvimento dos indivíduos na elaboração dos padrões.
• Cada indivíduo tem um acompanhamento constante 
envolvendo metas e dados estatísticos de produtividade, 
mostrando sua evolução. 
• Benefícios:
– Melhoria da produtividade: melhor controle dos 
mecanismos e tempo de produção do software.
– Melhora a qualidade do software: resultado do 
conhecimento das causas dos erros e seu controle 
estatístico.
PSP: Personal Software Process - Níveis
PSP: Personal Software Process - Estrutura
TSP: Team Software Process
• Objetivo: Melhoria do processo de uma equipe. 
• É uma estrutura para a melhoria quantitativa 
de processo de software que ajuda equipes a 
desenvolver produtos de software de modo 
eficaz.
• O grupo deve ser coeso, cooperando para o 
objetivo.
• Supõe que os membros da equipe tenham sido 
treinados no PSP.
• Cada membro trabalha separadamente com 
suas próprias estatísticas de produtividade.
TSP: Team Software Process
• Princípios:
– Estabelecimento de objetivos e papeis comuns.
– Definição de um processo comum de trabalho.
– Envolvimento de todos na produção do plano.
– Negociação do plano entre o time e a gerência.
– Revisão e aceite final pela gerência.
– Comunicação livre e frequente.
• A equipe é proprietária dos seus processos e pode 
mudá-los sempre que necessário.
• Os processos da equipe são baseados em sua
– Experiência / conhecimento / maturidade.
• SEI sugere: PSP, TSP e em seguida CMMI.
TSP: Team Software Process – 4 Lições
1. A maior parte do desenvolvimento de software é e será feita 
por equipes
2. Equipes com as habilidades apropriadas e em que todos os 
membros trabalham juntos cooperativamente e efetivamente 
podem produzir resultados extraordinários
3. Um trabalho em equipe efetivo requer oito coisas
1.Metas da equipe com que todos concordam
2.Papéis estabelecidos
3.Um ambiente de trabalho adequado
4.Um processo de trabalho comum
5.Um plano para o trabalho
6.O compromisso mútuo com as metas, papéis e o plano
7.Comunicação aberta entre todos os membros do time
8.Respeito mútuo e suporte de todos os membros do grupo
4. Quando times encontram essas condições, produzem um 
trabalho superior, são mais produtivos e apreciam o seu 
trabalho
Qualidade de Software:
Requisitos Funcionais 
e Não Funcionais
INFLUÊNCIA DOS REQUISITOS NA QUALIDADE
REQUISITOS SEM QUALIDADE
• Principal causa de falhas em software.
• Descrições incompletas.
• Esquecimento de regras.
• Mudanças não controladas.
• Necessidadesdos usuários não atendidas.
• Comunicação falha.
• Cronograma falho.
• Teste falho.
• Documentação falha.
REQUISITOS COM QUALIDADE
PROCESSO DE ENGENHARIA DE REQUISITOS
VALIDAÇÃO E VERIFICAÇÃO (IEEE 1012)
• Validação (Homologar):
• estamos construindo o produto certo?
• o software faz o que o usuário requisitou?
• Verificação (Testes):
• estamos construindo o produto 
corretamente?
• o software está de acordo com sua 
especificação?
QUALIDADE DE REQUISITOS: 
NORMA IEEE STD-830-1998 (características)
• Correção: Atende a todo requisito e é coerente.
• Precisão: Tem uma única interpretação por todos os 
interessados.
• Completude: Reflete todas as negociações feitas com 
os usuários, sem pendências.
• Consistência: Não há conflitos entre os requisitos.
• Priorização: Os requisitos são priorizados de acordo 
com sua importância.
• Verificabilidade: O requisito deve ser validado.
• Modificabilidade: é fácil modificar o requisito.
• Rastreabilidade: Quais modificações foram feitas.
O DIÁLOGO ENTRE STAKEHOLDERS
• “ O cliente não sabe o que quer”.
• A responsabilidade é de todos.
• “ Não pedi porque é óbvio”.
• Requisitos não devem ser implícitos: desconheço o negócio.
• “ Basta incluir dois campos a mais no formulário”
• Mudanças não são simples. Deve-se controlar as mudanças.
• “ Funcionava mais rápido na fase de testes”
• Em produção vários fatores podem alterar o comportamento 
do sistema.
– Existe ferramenta que automatiza e gerencia o 
processo de levantamento, análise, verificação e 
documentação dos requisitos?
Qualidade de Software e Métodos 
Ágeis
Revisão Métodos Ágeis 
SCRUM
XP - Extreme Programming
FDD - Feature Driven Development
(Desenvolvimento Guiado por 
Funcionalidades )
TDD - Test Driven Development
(Desenvolvimento Orientado a Testes)
Princípios CMMI
Princípios PSP
Métodos Ágeis e Qualidade De Software
Desenvolver em sala individualmente uma MDS que utilize os 
princípios dos métodos ágeis e de qualidade de software (CMMI, 
TSP e PSP, Normas ISO, outras normas).
Scrum e CMMI são antagônicos?
• CMMI institui uma série de processos a serem seguidos e, 
para alguns, seguir processos significa não ser ágil: nesta 
visão Scrum não tem relação com CMMI.
• Como manter um nível avançado de maturidade sem 
perder agilidade para entregas rápidas, pouca 
documentação, responder solicitações de mudança e ter 
alta produtividade ?
• Fatos: 
• O SCRUM não cobre todas as práticas específicas de 
gerenciamento de projeto, mas podem ser criados 
adaptações para ficar aderente ao CMMI.
• O grande desafio é identificar como práticas alternativas 
podem complementar SCRUM para ficar aderente ao CMMI 
sem perder sua agilidade.
Aderência entre níveis do CMMI com práticas Scrum
Aderência entre níveis do CMMI com práticas Scrum
Aderência entre níveis do CMMI com práticas Scrum
• Leituras recomendadas: 
• http://imprensa.cesar.org.br/scrum/SPINRecife_Mai08_ScrumCMMI_CESAR%5B1%5D.p
df 
• https://www.profissionaisti.com.br/2015/11/scrum-e-cmmi-complementares-ou-
antagonicos/
• http://adsystemsblog.audits.com.br/2008/12/27/agile-x-cmmi-por-jose-papo-ii-scrum-
ou-agile-com-cmmi-e-possivel/ 
É possível fazer o Scrum ou outro processo ágil ficar 
aderente ao CMMI ?
• Pontos de vistas :
• “Ser Agile é seguir regras, procedimentos definidos 
(cerimônias), com cada um executando seu papel no 
ambiente de construção do resultado. Portanto, o 
Agile é sim burocracia! E é muito importante 
entender que qualquer método de trabalho é 
burocrático. É possível adaptar para ser ágil e seguir 
os processos CMMI” (Alércio Bressano).
• “Você pode fazer um processo ágil ficar aderente ao 
CMMI, porém terá um grande overhead (sobrecarga) 
de custo e prazo em cada um de seus projetos para 
conseguir isso” (André Dourado).
Medições / Métricas
de Software
ISO/IEC 2502n
(antiga ISO 15939 – Software 
Measurement Process)
Por que devemos medir?
• Para sabermos quanto cobrar.
• Para conseguirmos dar prazos.
• Para definirmos o tamanho da equipe.
• Para definirmos a complexidade da 
construção do software.
• Para definirmos o tamanho do software.
• Para medirmos os riscos associados ao 
processo de construção do software.
Propósito das medições / métricas
• Obter dados para caracterizar um produto (software) 
ou atributo de software.
• Medidas básicas: número de defeitos (bugs) do projeto, 
total de horas do projeto.
• Medidas derivadas: Índice de defeitos (horas/bugs).
• Medidas permitem avaliar a evolução histórica de um 
indicador ou estimativa (medidas derivadas) .
• Objetivo: Melhoria contínua baseada em indicadores 
ou estimativas.
Modelo de Medição ISO 15939
Que Tipos de Métricas Usar ?
– Linhas de código (retira-se linhas em branco e 
comentários)
– Numero de Pontos de Função.
– Número de Pontos de Casos de Uso.
– Número de Histórias de Usuário.
– Número de Protótipos.
– Número de Tabelas ou Atributos.
– Número de Horas gastas no projeto.
– Número de Horas gastas por Etapa do Ciclo de Vida.
– Número de Horas gastas por cada indivíduo da Equipe.
Que Tipos de Métricas Usar ?
– Valor Total do Custo.
– Valor Total Pago.
– Número de Classes.
– Número de Métodos (operações).
– Número de defeitos / bugs.
– Número de casos de testes realizados.
– Número de defeitos introduzidos por programador / 
hora.
– Número de mensagens de erros.
– Número de mudanças no documento de requisitos.
Métricas ISO/IEC 9126
Métricas ISO/IEC 9126 – Funcionalidade
Métricas ISO/IEC 9126 – Manutenibilidade
Métricas ISO/IEC 9126 - Usabilidade
Métricas ISO/IEC 9126 - Confiabilidade
Métricas ISO/IEC 9126 - Eficiência
Métricas ISO/IEC 9126 – Portabilidade
Métricas: Gráficos / Tabulação
Métricas: Gráficos / Tabulação
Métricas: Gráficos / Tabulação
Exemplos Metodologia – Squadra CMMI 3
Exemplos PSP – TSP – Squadra
(Encontro Anual)
Exemplos PSP – TSP – Squadra
– Participação nos Lucros (Meta atingida – Gatilho)
– Atividade de alongamento (duas vezes por semana).
– Sala Zen: Massoterapia (uma vez por mês ou mais).
– Assessoria esportiva na prática de corrida de rua.
– Aluguel para família em aptos a preços acessíveis: Rio e 
Brasília.
– Certificações (custo zero se aprovado).
– Clube de vantagens (convênios). Desconto em folha.
– Brindes em datas comemorativas (mães, pais, natal ...).
– Festa anual com deslocamento, brindes, ...
– Horário Flexível ... Home Office ...
Exemplos PSP – TSP – Squadra
– Vacina Gripe Subsidiada.
– Sala de café (café 2 vezes + 15 minutos Manhã / Tarde).
– Aniversário: Brindes !
– Horistas / Alimentação / Cabify 
Exemplos PSP/TSP – Squadra – Vacina Gripe 
Princípio Pareto (20/80)
– Vídeo: 
https://www.youtube.com/watch?v=BsgMxLaCPXI.
– 80% das consequências advêm de 20% das causas !
– O que isso tem a ver com Qualidade de Software?
• 20% dos componentes de um software concentra 80% dos 
defeitos (bugs).
• 20% dos defeitos afetam 80% das funcionalidades.
– Quais são os defeitos mais frequentes?
• 80% do esforço de desenvolvimento (em tempo e recursos) 
produz 20% do código.
• 80% do código é produzido com apenas 20% do esforço !!
Princípio Pareto (20/80)
– Corrigindo 20% dos bugs mais reportados elimina-se 80% dos 
erros e problemas !!
– Testes em 20% das telas do sistema são responsáveis por 80% 
dos problemas reportados !!
– Do que adianta gastar uma hora testando uma tela complexa se 
quase ninguém usa? 
– Um resultado com melhor qualidade e produtividade seria 
testar aquela tela que todo mundo usa todo dia !
–20% dos requisitos satisfazem a 80% dos usuários !
QUALIDADE: Governança de TI
• Qualidade na entrega de serviços de TI.
• Assegurar que os serviços e infraestrutura de TI 
podem resistir e recuperar-se de falhas devido a erros, 
ataques deliberados ou desastres.
• Garantir satisfação do usuário (suporte de qualidade)
• Assegurar a conformidade de TI com leis, 
regulamentos e contratos.
• Assegurar o mínimo impacto para os negócios no caso 
de uma parada ou mudança nos serviços de TI.
• Otimizar infraestrutura, recursos e capacidades de TI.
• Documentar e Proteger todos os ativos de TI.
Excelência na Entrega de Serviços de TI
• Normas / Padrões:
• ITIL: Information Technology Infrastructure Library
• Objetivos do ITIL:
• Gestão de serviços de TI: transferir o olhar para 
processos e pessoas, e não apenas na tecnologia.
• Prover serviços de alta qualidade, com foco no 
relacionamento com os clientes 
• Alinhar serviços de TI com os negócios da empresa.
• Assegurar que existem processos de gestão de TI 
centralizados, integrados e documentados. 
• Produtividade, Indicadores e SLA (Service Level
Agreement – Acordo de Nivel de Serviço)
ITIL
Exemplos
• Gerência de Mudanças.
• Gerência de Incidentes.
• Gerência de Problemas.
• Gerência de Capacidade.
• Processos / Procedimentos.
Vide exemplos IBM/FIAT.
ITIL
Governança de TI: Alternativa COBIT
(Control Objectives For Information end Relatet technology)
REVISÃO FINAL
• Qualidade em Software é ...
• Qual o princípio das normas de 
qualidade ?
• Qual o princípio do CMMI e do 
MPS.BR?
• Qual o princípio do ITIL ?
Qualidade Versus ??
• Requisitos x Qualidade: validar e verificar.
• Processos x Qualidade: BPM.
• Modelos (Documentação) x Qualidade: UML, CASES.
• MDS ágeis x Qualidade: Interativo e Incremental.
• Métricas x Qualidade.
• Testes x Qualidade.
• Gerência (planejamento) x Qualidade.
• Pessoas x Qualidade: PSP.
• Equipes x Qualidade: TSP.
CMMI X Fabrica de Software x Qualidade
MPS.BR X Qualidade
Normas Internacionais x Qualidade
ITIL X Qualidade