Wallacy S.

Scofield
wallacy.ti@gmail.com
O que é Qualidade?
“Qualidade é a adequação ao uso. É a
conformidade às exigências” ROTHERY, Brian. ISO
9000.

“Qualidade tem a haver , primordialmente,

com o processo pelo qual os produtos ou
serviços são materializados.” LOBOS, Júlio

“A qualidade é relativa. O que é qualidade

para uma pessoa pode ser falta de qualidade
para a outra.” G. Weinberg
Um Breve Histórico
Inicio do Século XX – Inspetores atuando em diversos
departamentos de produção para atender as especificações do produto.
Na década de 40 – Antes da 2ª Guerra Mundial, iniciou os
métodos estatísticos de Shewhart para garantir a qualidade.
Após a 2ª Guerra Mundial – Implantação do controle de
qualidade em todo o mundo orientado a processos.
Revolução Japonesa a área da Qualidade – Deming e
Juran implantam os métodos estatísticos na gestão de Qualidade no
Japão.
Ishikawa, “pai” dos CCQs – Figura ilustre nessa revolução da
qualidade que criou Circuito de Controle de Qualidade modelos para
outros controles no restante do mundo.
Uma Crise de mais de 30 anos
Um dos fatores que exerce influência negativa sobre a
qualidade de um projeto é a sua complexidade.

A Crise do Software na década de 60

 Aumento em potencial dos recursos dos hardwares;
 Falta de ferramentas para programação;
 Não havia técnicas nem escolas para programação;
Atualmente o problemas de softwares existem:
 Cronogramas não observados;
 Projetos com tantas dificuldades que são abandonados;
 Programas que simplesmente param de funcionar;
 Programas que não fazem exatamente o que era esperado;

Nós somos capazes de produzir software de qualidade?

Razões da Qualidade
O que nos leva a pensar melhor no que diz respeita a
qualidade:
Qualidade é competitividade.
Qualidade é essencial para a sobrevivência da empresa
no mercado.
Qualidade é essencial para o mercado internacional.
Qualidade é custo/benefício.
Qualidade retém consumidores e aumenta lucros.
Associações com Qualidade de Software
APS

Requisitos Engenharia
de Software

Qualidade de Software
Qualidade e Requisitos
Uma das primeiras questões a responder quando o
assunto é qualidade é como julgá-la.
Estabelecer critérios é o ponto essencial.
Os critérios deverão ser em função da finalidade a
que se destina.
Exemplo: Um ERP – Tem que existir uma boa
especificação como servidores, fontes, hd’s,
memórias, processadores, etc.
Continuação de
Qualidade
 X Requisitos
“ A qualidade é conformidade aos Requisitos.”
Crosby[1992]
Dentro da Conformidade temos que:
Qualidade = f(observado - especificado)
Medidor da Medição ε que não podemos controlar;
Qualidade = f (Observado – especificado + ε)
Papel de diferentes clientes num mesmo projeto;
Diferentes stakeholders têm em mente diferentes
requisitos e podem expressá-los de maneiras distintas.
O engenheiros de requisitos precisam descobrir pontos
comuns e os conflitos.
Papel da Subjetividade

A qualidade de um produto tem um propósito:

Satisfazer o cliente.
Custo é um fator integrante de um modelo de
qualidade.
A necessidade atendida de um cliente pode ser uma
qualidade mesmo que não siga todos os padrões de
qualidade.
Exemplo: Software de Banca.
Qualidade e Bugs
Um programa de computador pode conter erros e
continuar sendo um produto de qualidade.
Caso 1 – Editor de texto que tinha uma falha somente
para 1% de seus usuários;
Caso 2 – Sistema de Tipografia T e X. Tem qualidade
de resultado, mas um ponto fraco em geração de
planilha.
Qualidade de Software não pode ser tratado com
dogmas. Tem que considerar fatores que afetam a
construção e influenciam no resultado para usuários.
Qualidade e Bugs
Exemplos de Fatores a serem considerados:
Tamanho e complexidade do software;
Número de pessoas envolvidas no projeto;
Ferramentas utilizadas;
Custos associados a existência de erros;
Custos associados a detecção e à remoção de erros;
Um Erro é um Defeito,
uma Falha ou um Bug?
Um crash – interrupção da execução
DEFEITO – É um programa que não funciona como
deve.
Ex:
Int teste (void) {
float a, b, c;
c = a/b;
}
Um Erro é um Defeito,
uma Falha ou um Bug?
Falha – É o resultado errado provocado por um
defeito ou condição inesperada.
Defeitos podem existir e nem sempre ser visíveis.
Falhas também podem ocorrer por fatores externos ao
programa, como corrupção de base de dados ou uso da
memória .
Isolar um Defeito
Determinar sob quais condições ele ocorre.
O objetivo é encontrar as causas dentro de um
programa que estão ocasionando falhas e isso
implica em descobrir em qual linha do código ocorre
uma falha como um crash.
Saber onde está o defeito somente pelo janela de erro é
praticamente impossível.
Fazer as operações repetidas sistematicamente
Além de voltar todos os processos desde a entrada de
dados e comando executados pela aplicação.
Muitos programadores desconhecem ferramentas que
permitem facilitar a depuração de código.
Estabilizar um programa
Estabilizar um programa significa corrigi-lo de forma
a diminuir a freqüência de falhas.
Um programa estável apresenta poucas falhas.
A estabilidade está diretamente ligada à maturidade
do programa
Mais tempo de uso representa a possibilidade de
encontrar e corrigir problemas de execuçã.
Qualidade e Bug - Catástrofes
Existem defeito inconvenientes em um software;
Mas não determina se aspecto qualitativo.
Isso porque existem defeitos relativos:
Existem falhas que podemos conviver com elas. Ex:
Falha do office
Existem falhas que representam o completo fracasso
comercial ou até colocam em risco vidas humanas.
ARIANE 501
Uma catástrofe comercial que gerou uma perda de
mais de R$ 300 milhões de dólares.
Um foguete que se autodestruiu com uma explosão por
ter saído de sua trajetória.
THERAC - 25
Uma máquina utilizada em terapia radiológica.
Apresentava ocorrências de falhas dando mensagens
de erros em números que eram entendidas somente
pelos desenvolvedores.
Tinha problema de concorrência de procedimentos.
Morreram 6 pacientes dos erros do Therac
Qualidade e o SWEBOK
SWEBOK – Software Engineering Body Of
Knowledge – 2004
Corpo de Conhecimento de Engenharia de
Software
Dividida em 11 áreas de conhecimento:
Requisitos Gerencia de Engenharia
Projetos Métodos e ferramentas de Eng.
Construção Processos de Engenharia
Testes Qualidade
Manutenção Disciplinas relacionadas
Gerência de Configurações
Qualidade e SWEBOK
Com o desdobramento da computação em uma
extensa lista de subáreas de estudo, a qualidade da
informação aumentou consideravelmente.
Como acontece em todos os estudos, há divisões
de áreas, mas sempre envolvida em outros
domínios.
As classificações são úteis para que possamos
organizar o conhecimento e direcionar esforços.
Em relação a Qualidade, o SWEBOK fez uma
distinção entre técnicas estatísticas e dinâmicas.
Qualidade e o SWEBOK
Qualidade de
Software

Processos de
Fundamentos da Considerações
Gerência de Qualidade
Qualidade de SW Práticas

Cultura e Ética da Garantia da Requisitos da

Eng. De SW Qualidade de SW Qualidade de SW

Valor e Custo da Verificações e Caracterização de

Qualidade Validações Defeitos

Modelos e Tecnicas de Ger.

Revisões e Auditorias
Características da Q. Qualidade de SW

Melhoria da Medição de
Qualidade Qualidade de SW
Fundamentos de Qualidade
Esse tópico abrange a noção de qualidade.
No caso de um software, materializa-se por meio da
definição de requisitos e estes dependem de um modelo.
(Norma SQuaRE, ISO/IEC. 25000.
Os aspectos éticos do trabalho com Software têm se
tornado mais evidentes depois que surgiram uma classe
de problemas com crimes através de computador.
Outro ponto da qualidade é a relação entre valor e custo
que abrange 2 aspectos: ]
 Os prejuízos causados pela falta de qualidade
 Os custos com que é preciso arcar para garantir um determinado

nível de exigência quanto ao funcionamento do software.

Processos de Gerência de Qualidade
Os processos de gerência abrangem todos os aspectos de
construção de um software:
 A Garantia da Qualidade é assegurar que os objetivos planejados no
início do projeto serão cumpridos, garantindo que o programa que
será fabricado fará aquilo que se espera dele.
 As verificações e Validações parece um processo oposto a que
estudamos pois nela se considera a possibilidade de algo errado.
Mas na realidade esse ponto apontará se a garantia da qualidade foi
cumprida e aprovará ou reprovará o produto.
 As auditorias são independentes da construção do software.
Deverão ser feitas por pessoas que não participaram da construção
do software ou por empresas com essa especialidade que respeitam
as normas da ISO 9000.
Considerações Práticas
Requisito de qualidade – “Fatores de influência” – é
necessário atentar-se para o orçamento, usuários envolvidos,
ferramentas e métodos, segurança de funcionamento e
consequências que falhas podem causar.
Caracterização de Defeitos – É verificar a não-conformidade
aos requisitos. Ex: revisões, inspeções, etc.
Técnicas de Gerenciamento de Qualidade – São 4 tipos:
 Orientadas a pessoas – Testes por usuários;
 Estáticas – Que não envolvem execução do produto;
 Dinâmicas – Que são efetuadas na execução do software;
 Analíticas – Que fazem uso de métodos formais.
Medição da Qualidade – Um conjunto de dados obtidos por
medidas é um recurso de extrema ajuda para auxiliar as
tomadas de decisões gerenciais.