Introdução à Qualidade de Software
Alexandre M. Lins de Vasconcelos
Departamento de Informática - UFPE
[email protected]
081 2718430
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
1
Motivação



O principal objetivo da Engenharia de Software (ES) é
ajudar a produzir software de qualidade;
Empresas que desenvolvem software de qualidade são
mais competitivas;
Empresas que utilizam software de alta qualidade podem,
em geral, oferecer um melhor serviço a um preço mais
competitivo.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
2
Conceitos de Qualidade

Definição genérica:


“Propriedade, atributo ou condição das coisas ou das pessoas
capaz de distingui-las das outras e de lhes determinar a natureza”
(Aurélio).
Outras definições:



Qualidade é estar em conformidade com os requisitos dos
clientes;
Qualidade é antecipar e satisfazer os desejos dos clientes;
Qualidade é escrever tudo o que se deve fazer e fazer tudo o que
foi escrito.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
3
Conceitos de Qualidade

Segundo a atual norma brasileira sobre o assunto (NBR
ISO 8402), qualidade é:

A totalidade das características de uma entidade que lhe confere
a capacidade de satisfazer as necessidades explícitas e
implícitas.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
4
Conceito de Qualidade de Software

“Conformidade a requisitos funcionais e de desempenho
explicitamente declarados, a padrões de desenvolvimento
claramente documentados e a características implícitas
que são esperadas de todo software profissionalmente
desenvolvido” (Pressman).
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
5
Fatores de Qualidade de Software


A noção de qualidade de software pode ser descrita por
um grupo de fatores, requisitos ou atributos, tais como:
confiabilidade, eficiência, facilidade de uso, modularidade,
legibilidade, etc;
Podemos classificar estes fatores em dois tipos principais:
externos e internos;
Fatores Externos
Fatores Internos
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
6
Fatores de Qualidade de Software



Fatores externos são percebidos tanto pelas pessoas que
desenvolvem software quanto pelos usuários. Por
exemplo, confiabilidade, eficiência e facilidade de uso são
fatores externos;
Fatores internos são percebidos apenas pelas pessoas
que desenvolvem software. Por exemplo, modularidade e
legibilidade são fatores internos;
Se os fatores internos forem observados, os fatores
externos serão consequentemente observados. De fato,
os fatores internos são um meio para se alcançar os
fatores externos.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
7
Fatores Externos de Qualidade de Software
facilidade de uso
eficiência
portabilidade
CESAR/DI-UFPE
s
o
f
t
w
a
r
e
correção
robustez
integridade
© 1998, Alexandre Vasconcelos
8
Fatores Externos de Qualidade de Software



Facilidade de uso: a facilidade de aprender como usar o
software;
Eficiência: o bom uso dos recursos computacionais;
Portabilidade: a facilidade de transferir software entre
ambientes operacionais.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
9
Fatores Externos de Qualidade de Software



Correção: habilidade do software executar suas tarefas
exatamente como definida pelos requisitos e
especificação;
Robustez: habilidade de um software funcionar mesmo
em condições anormais;
Integridade: a habilidade do sistema de proteger seus
vários componentes contra acessos ou modificações
indevidos.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
10
Processos de Engenharia






Especificação - define os requisitos e limitações do
sistema
Projeto - Produz um modelo do sistema
Manufatura - construção do sistema
Teste - verifica se o sistema satisfaz a especificação
Instalação - entrega o sistema ao usuário e garante
sua operacionalidade
Manutenção - repara falhas no sistema quando elas
são descobertas
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
11
O Processo de Software

Um conjunto estruturado de atividades necessárias para
o desenvolvimento de um sistema de software
•
•
•
•
•

Especificação
Projeto
Implementação
Validação
Evolução
As atividades variam de acordo com a organização e o
tipo de sistema sendo desenvolvido
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
12
Características do Processo

Facilidade de Entendimento
•

Visibilidade
•

O progresso do processo está externamente visível?
Suportabilidade
•

O processo está definido e bem entendido?
O processo pode ser apoiado por ferramentas CASE?
Aceitabilidade
•
O processo é aceito pelas pessoas envolvidas nele?
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
13
Processos e Qualidade do Produto




Qualidade do processo e qualidade do produto estão
intimamente relacionados;
Um bom processo é normalmente necessário para
produzir um bom produto;
Para produtos manufaturados, o processo é o principal
determinante de qualidade;
Para projetos, outros fatores também são importantes.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
14
Dimensões da Qualidade do Software
Development
technology
Process
quality
Product
quality
People
quality
Cost, time and
schedule
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
15
Análise e Modelagem do Processo



Estude um processo existente para entender suas
atividades
Produza um modelo abstrato do processo. Normalmente
representado graficamente. Várias visões diferentes (ex.
atividades, deliverables, etc.) podem ser necessárias
Analise o modelo para descobrir problemas do processo.
Envolve discutir atividades com as partes interessadas
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
16
Técnicas de Análise do Processo

Modelos de processos públicos e processos
padronizados


Questionários e entrevistas


É sempre melhor começar o processo de análise com um modelo
existente. As pessoas então poderão estender e mudá-lo.
Devem ser cuidadosamente projetadas. Participantes podem
contar o que eles acham que você quer ouvir.
Análise Etnográfica

Envolve a assimilação do conhecimento do processo através da
observação
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
17
Elementos do Processo de Software

Atividades


Processos


Conjunto de atividades com alguma coerência e um objetivo bem
definido.
Deliverables (entrega)


Tem um objetivo claramente definido, condições de entrada e
saída. Normalmente executadas por uma única pessoa.
Saída tangível de uma atividade. Usualmente um documento.
Condições

Predicado que deve valer antes ou depois de um processo ou
atividade.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
18
Elementos do Processo de Software

Papéis


Exceções


Uma área limitada de responsabilidade. Exemplos: gerente de
configuração, engenheiro de teste, etc.
Um evento que requer um tratamento especial e que não é
tratado por atividades normais. Usualmente tratadas quando
surgem sem uma estratégia prévia.
Comunicação

Um troca de informação entre pessoas ou pessoas e
computadores
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
19
Classificação do Processo

Informal


Gerenciado


Processos são definidos e guiam o desenvolvimento
Metódico


Não há um modelo detalhado do processo. O time de
desenvolvimento escolhe sua própria forma de trabalhar
Processos são definidos por algum método de desenvolvimento
(OMT, Booch, etc)
Suportado

Processo suportado por alguma ferramenta CASE
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
20
Aplicabilidade do Processo
Informal
process
Prototypes
Short-lifetime products
4GL business systems
Managed
process
Lar ge systems
Long-lifetime products
Methodical
process
Well-understood
application domains
Re-engineered systems
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
21
Escolha do Processo

O processo a ser usado depende do tipo de produto em
desenvolvimento



Para grandes sistemas, o gerenciamento é geralmente o principal
problema. Portanto, você precisará de um processo gerenciado.
Para projetos menores, uma informalidade será possível;
Não existe um processo uniforme que possa ser padronizado em
qualquer organização;
Você poderá ter altos custos se forçar um processo não
apropriado num time de desenvolvimento.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
22
Ferramentas de suporte a processos
Informal
process
Generic
tools
Managed
process
Configuration
management
tools
CESAR/DI-UFPE
Project
management
tools
Methodical
process
Analysis and
design
workbenches
© 1998, Alexandre Vasconcelos
Improving
process
Specialized
tools
23
Melhoria do Processo


Os estudos sobre qualidade estão na sua maioria
voltados para o melhoramento do processo de
desenvolvimento;
Ao melhorar a qualidade do processo está se dando um
grande passo para se garantir também a qualidade do
produto.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
24
Objetivos da Melhoria do Processo



Entender o processo existente
Introduzir mudanças de processo para alcançar objetivos
organizacionais, que são associados à melhoria da
qualidade, redução de custos e aceleração de prazos
A maior parte do trabalho de melhoria de processo até o
momento tem abordado a redução de defeitos. Reflete a
atenção cada vez maior da indústria para a questão da
qualidade
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
25
Estágios da Melhoria do Processo

Análise do Processo


Identificação de Melhorias


Modifique o processo para remover os gargalos identificados
Treinamento na Mudança do Processo


Identifique os gargalos de qualidade, custo e escalonamento
Introdução das Mudanças de Processo


Modele e analise (quantitativamente se possível) os processos
existentes. Métricas são necessárias.
Treine a equipe envolvida com os novos processos propostos
Ajuste da Mudança

Evolua e melhore os processos revisados
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
26
Estágios da Melhoria do Processo
Introduce
process change
Analyse
process
Tune
process changes
Identify
improvements
Train
engineers
Process
model
Process change
plan
CESAR/DI-UFPE
Training
plan
Feedback on
improvements
© 1998, Alexandre Vasconcelos
Revised process
model
27
Medindo o Processo

Quando for possível, dados quantitativos do processo
devem ser coletados



Contudo, quando as organizações não têm processos
padronizados bem definidos isto pode ser difícil, pois você não
saberá o que medir. Um processo precisa ser definido antes de
qualquer medição ser possível
Medições do processo devem ser usadas para avaliar a melhoria
do processo
Mas isto não implica que as medições devem guiar as melhorias.
Os objetivos organizacionais devem guiar as melhorias.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
28
Objetivos das Métricas

Independentemente da métrica usada, sempre se busca
os mesmos objetivos



Melhorar o entendimento da qualidade do produto;
Atestar a efetividade do processo;
Melhorar a qualidade do trabalho realizado a nível de projeto.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
29
Classes de Medições de Processos

Tempo que se leva para completar as atividades do
processo


Recursos necessários para os processos ou atividades


Ex. Tempo do calendário ou esforço para completar uma atividade
ou processo
Ex. Esforço total em pessoa-dias, custo de viagens, recursos
computacionais
Número de ocorrências de um determinado evento

Ex. Número de defeitos descobertos
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
30
Paragima GQM (Goal-Question-Metric)

Objetivos - Goals


O que a organização quer alcançar? O objetivo da melhoria do
processo é satisfazer estes objetivos
Questões

Questões a respeito das áreas de incerteza relacionadas com os
objetivos.
Como poderemos reduzir o tempo de produção de requisitos?
Como diminuir o número de linhas de código com defeitos?

Métricas

Medições para coletar as respostas às perguntas
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
31
Controle e Garantia de Qualidade






Gerentes querem os melhores projetistas para projetar o produto,
mas em geral não podem tê-los;
Não existe técnica que possibilite o desenvolvimento de software
isento de defeitos;
Controle de Qualidade evita que produtos defeituosos sejam
entregues aos clientes (relaciona-se à validação);
Garantia da Qualidade tenta produzir software com uma baixa taxa
de defeitos (relaciona-se à verificação);
Existe então a necessidade de concentrar esforços em métodos de
SQA (Software Quality Assurance);
O papel de SQA é monitorar os métodos e padrões que os
engenheiros de software usam.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
32
Atividades de SQA

Em SQA temos uma variedade de tarefas, as quais
podemos dividir em dois grandes grupos:


Engenheiros de software: fazem o desenvolvimento dos sistemas
(trabalho técnico);
Grupo de SQA: responsabilidades sobre o plano de qualidade,
inspeção, conservação de registros históricos, análise do produto
desenvolvido e reporting das atividades de SQA ao gerente do
projeto.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
33
Atividades de SQA

O SEI (Software Engineering Institute) recomenda as
seguintes atividades para o grupo de SQA






Preparar uma plano de SQA;
Participar da descrição do projeto de software;
Revisar as atividades dos engenheiros de software;
Documentar e consertar os desvios;
Registrar discordâncias e reportar para o gerente;
Gerenciar mudanças e métricas de software.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
34
Atividades de SQA:
revisões de software






São um filtro no processo de ES;
Não são limitadas à especificação, projeto e código.
Defeito: anomalia do produto (IEEE);
Revisões Técnicas Formais (RTF): destinam-se a
encontrar erros durante o processo antes que eles se
tornem defeitos;
50% a 60% do total de erros são introduzidos durante o
projeto de software;
RTF podem descobrir cerca de 75% desses erros.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
35
Atividades de SQA:
medidas de produtividade de programação

A qualidade do software depende da produtividade de
programação, a qual é afetada por:







qualidade da documentação;
linguagem de programação;
disponibilidade de ferramentas;
experiência do programador;
comunicação no projeto;
grau de dependência entre módulos;
práticas de programação bem definidas.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
36
Atividades de SQA:
medidas de confiabilidade

“Probabilidade de uma operação de programa de
computador ser livre de falha”.
não conformidade com os
requisitos de software


É um elemento importante para a qualidade do software;
Exemplo: um software que opera corretamente em 96 das
suas 100 execuções, tem uma confiabilidade de 0.96.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
37
Confiabilidade x Segurança

Confiabilidade


usa a análise estatística para determinar a probabilidade de que
uma falha venha a ocorrer.
Segurança

examina as maneiras segundo as quais as falhas resultam em
condições que podem levar a uma deformação.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
38
Plano de SQA


Especifica os objetivos, as tarefas de SQA a serem
realizadas, os padrões, os procedimentos a estrutura
organizacional e os mecanismos de auditoria;
Documentos de ES exigidos: Especificação de
Requisitos, Descrição de Projeto, Plano (e Relatório) de
Verificação e Validação, Documentação do Usuário.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
39
Certificação de Qualidade




Não basta que a qualidade exista, ela deve ser
reconhecida pelo cliente;
Deve existir uma certificação oficial emitida com base em
um padrão;
As certificações são dadas por instituições competentes;
Exemplos de certificação:



Selo SIF de qualidade de produtos alimentícios;
Selo ABIC de qualidade do café;
Classificação da rede hoteleira.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
40
Certificação do Produto ou do Processo?


Hoje em dia, a qualidade do processo é mais importante
do que a qualidade final do produto;
Existem normas e padrões tanto para produtos quanto
para processos.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
41
Padrões de Qualidade de Software



Qualidade de produtos de software - ISO 9126 (versão
brasileira - NBR 13596);
Qualidade de pacotes de software - ISO 12119;
Qualidade do processo de software



ISO 9000 / ISO 9001
Capability Maturity Model (CMM)
Outros padrões para qualidade de processo


Personal Software Process (PSP)
SPICE
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
42
Qualidade de produtos de software ISO 9126

Conjunto de características que devem estar presentes
em um software de qualidade:








Funcionalidade - satisfaz as necessidades?
Confiabilidade - é imune a falhas?
Usabilidade - é fácil de usar?
Eficiência - é rápido e “enxuto”?
Manutenibilidade - é fácil de modificar?
Portabilidade - é fácil de usar em outro ambiente?
Muitas destas características são subjetivas;
Outras podem ser definidas por meio de métricas.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
43
Qualidade de pacotes de software ISO 12119


Trata da avaliação de “software de prateleira”;
Descreve detalhes que devem estar presentes no
software, tais como:






Documentação do usuário de fácil compreensão;
Um sumário e um índice remissivo na documentação do usuário;
Presença de um manual de instalação com instruções detalhadas;
Possibilidade de verificar se uma instalação foi bem sucedida;
Especificação de valores limites para os dados de entrada;
etc.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
44
Qualidade do processo de software Capability Maturity Model (CMM)



Descreve princípios e práticas relacionadas à maturidade
do processo de software;
Tem o objetivo de ajudar as organizações a melhorarem
seus processos de software em termos de um caminho
evolutivo que vai de ad hoc (processos caóticos) a
processos maduros e disciplinados;
Para isto define o conceito de nível de maturidade: base
evolucionária bem definida direcionada a obter um
processo de software maduro.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
45
Maturidade
Organizações maduras
Organizações imaturas
Papéis e responsabilidades bem
definidos
Processo improvisado
Existe base histórica
Não existe base histórica
É possível julgar a qualidade do
produto
Não há maneira objetiva de julgar
qualidade do produto
A qualidade dos produtos e
processos é monitorada
Qualidade e funcionalidade do
produto podem ser sacrificadas
O processo pode ser atualizado
Existe comunicação entre o gerente
e seu grupo
CESAR/DI-UFPE
Não há rigor no processo a ser
seguido
Resolução de crises imediatas
© 1998, Alexandre Vasconcelos
46
Componentes do CMM




Níveis de Maturidade
Áreas-chave de processo
Características comuns
Práticas-chave
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
47
Os 5 Níveis de Maturidade
Otimizado
Gerenciado
Definido
Reproduzível
Inicial
CESAR/DI-UFPE
Um processo de melhora contínuo é capacitado
p/retorno quantitativo do processo e das idéias.
Medidas de qualidade são coletadas. O processo
e o produto são entendidos e controlados
quantitativamente.
Processos padronizados, documentados e
integrados.
Processos estabelecidos por experiências
anteriores.
Processo caótico e ad hoc. O gerenciamento é
pensado” durante o desenvolvimento.
© 1998, Alexandre Vasconcelos
48
Níveis no Modelo de Maturidade





Inicial
 Essencialmente não controlado. Resultado imprevisível.
Reproduzível
 Procedimentos definidos e usados para gerenciamento de Produto
Definido
 Procedimentos e estratégias definidas e usadas para
gerenciamento de Processo
Gerenciado
 Estratégias definidas e usadas para Gerenciamento de Qualidade
Otimizado
 Estratégias definidas e usadas para Melhoria do Processo
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
49
Nível 1: Inicial
Foco : pessoas competentes e heróis
O processo de desenvolvimento é desorganizado e até
caótico. Poucos processos são definidos e o sucesso
depende de esforços individuais e heróicos.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
50
Nível 2: Repetível
Foco: Processos de gerenciamento de projetos
Os processos básicos de gerenciamento de projeto
estão estabelecidos e permitem acompanhar custo,
cronograma e funcionalidade. É possível repetir o
sucesso de um processo utilizado anteriormente em
outros projetos similares.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
51
Nível 3: Definido
Foco: Processos de engenharia e apoio
Tanto as atividades de gerenciamento quanto de
engenharia do processo de desenvolvimento de software
estão documentadas, padronizadas e integradas em um
padrão de desenvolvimento da organização. Todos os
projetos utilizam uma versão aprovada e adaptada do
processo padrão de desenvolvimento de software da
organização.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
52
Nível 4: Gerenciado
Foco: Qualidade do Produto e do Processo
São coletadas medidas detalhadas da qualidade do produto
e processo de desenvolvimento de software. Tanto o
produto quanto o processo de desenvolvimento de
software são entendidos e controlados quantitativamente.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
53
Nível 5: Otimizado
Foco: Melhoramento contínuo do Processo
O melhoramento contínuo do processo é conseguido
através de um “feedback” quantitativo dos processos e
pelo uso pioneiro de idéias e técnicas inovadoras.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
54
Áreas-chave de processo (KPA’s)



Indicam as áreas que uma organização deve enfocar para
melhorar seu processo de software;
O CMM define 18 KPA’s distribuídas nos 5 níveis;
Cada KPA é descrita em termos de práticas-chave que
contribuem para satisfazer seus objetivos.

descrevem a infra-estrutura e atividades que contribuem para a
implementação e institucionalização da KPA.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
55
Áreas-chave de processo





KPA 1: não existem KPA’s para este nível;
KPA 2: interesses relacionados ao estabelecimento do
controle básico de administração de projeto;
KPA 3: problemas organizacionais e de projeto;
KPA 4: estabelecem um entendimento quantitativo do
processo de software e do produto;
KPA 5: cobrem os problemas que a organização e os
projetos devem endereçar para implementar uma melhora
contínua e mensurável do processo de software.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
56
Áreas-chave de processo do Nível 2 Repetível
Repetível
(2)
Gerenciamento da Configuração de
Software
Garantia da Qualidade de Software
Gerenciamento de Subcontrato de Software
Acompanhamento de Projeto de Software
Planejamento de Projeto de Software
Gerenciamento de Requisitos
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
57
Áreas-chave de processo do Nível 3 Definido
Definido (3)
Revisões (peer review)
Coordenação Intergrupos
Engenharia de Produto de Software
Gerenciamento de Software Integrado
Programa de Treinamento
Definição do Processo da Organização
Foco no Processo da Organização
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
58
Áreas-chave de processo do Nível 4 Gerenciado
Gerenciado (4)
Gerenciamento da Qualidade de Software
Gerenciamento Quantitativo do Processo
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
59
Áreas-chave de processo do Nível 5 Otimizado
Otimizado (5)
Gerenciamento da Mudança no Processo
Gerenciamento da Mudança Tecnológica
Prevenção de Defeito
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
60
Características Comuns
As características comuns são itens a serem observados para que se
possa verificar a implementação e institucionalização de cada área-chave
de processo.





Compromisso a realizar
Capacidade de realizar
Atividades realizadas
Medições e análise
Verificação da implementação
Cada característica comum possui práticas-chave a serem realizadas.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
61
Críticas ao Modelo CMM




A ênfase é no gerenciamento do projeto e não no
desenvolvimento do produto.
Não incorpora a análise de risco como uma área crítica
do processo.
Não define o seu domínio de aplicabilidade
Dificuldade para implantação em pequenas empresas
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
62
Curiosidades sobre o CMM

Só existem atualmente cinco empresas no mundo no
nível 5:






BOEING;
Loral Systems (IBM);
Unidade da Motorolla (Índia);
Base de Eduards (USAF);
Lock Hit (empresa de aviação).
No Brasil temos:



Nível 2: NEC, ERICSON, CITIBANK;
Nível 3: XEROX;
Equitel/Siemens: implantou nível 2 ou 3, mas não se certificou.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
63
Comparação entre ISO 9001 e CMM

CMM

ISO 9001

Ênfase no contínuo
processo de melhora;


Enfoca estritamente o
software;
Não é uma norma emitida
por uma instituição de
padronização.


CESAR/DI-UFPE

Ênfase no critério mínimo
para um sistema de
qualidade aceitável;
Tem um escopo mais
abrangente;
Por ser mais conhecido e
embutir um padrão
internacional mínimo de
qualidade, o ISO talvez
traga melhores resultados
para a empresa.
© 1998, Alexandre Vasconcelos
64
Comparação entre ISO 9001 e CMM perguntas




Em que nível do CMM poderia se encaixar uma
organização em conformidade com o ISO 9001? A ISO
9001 atende boa parte das KPA’s do nível 2 e algumas do
nível 3.
Uma organização de nível 2 (ou 3) poderia ser
considerada em conformidade com o ISO 9001?
Provavelmente.
Meus esforços na melhoria do processo e no
gerenciamento de qualidade deveriam ser baseados no
ISO 9001 ou no CMM?
Estas perguntas não têm uma resposta definitiva.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
65
Pontos Principais




O processo de software consiste naquelas atividades
envolvidas no desenvolvimento de software
Modelos de processo incluem a descrição de tarefas,
atividades, papéis, comunicações, deliverables e outros
processos
Processos podem ser classificados com informal,
gerenciado, metódico e de melhoria.
Melhoria de processo envolve análise do processo,
padronização, medições e mudanças
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
66
Pontos Principais




Devemos coletar métricas para responder questões
específicas sobre o processo de software usado
O modelo CMM classifica os processos de software como
inicial, repetíveis, definidos, gerenciáveis e otimizados
Ele identifica processos chaves que devem ser utilizados
em cada nível
O modelo da SEI é apropriado para grandes projetos
desenvolvidos por grande time de engenheiros
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
67
Conclusão






Qualidade é um conceito complexo, porque significa diferentes coisas para
diferentes pessoas;
Não há uma simples medida para qualidade de software que seja aceitável
para todos os projetos de todas as empresas;
Para estabelecer ou melhorar a qualidade de software, deve-se definir os
aspectos de qualidade nos quais se está interessado e, então, decidir como
fazer para medi-los;
A implantação de um sistema de qualidade permite um aumento de
produtividade, uma melhoria da qualidade do produto final e um aumento da
satisfação dos clientes e da própria empresa;
A falta de consciência de muitas empresas e profissionais que lidam com
sistemas complexos tem sido um dos maiores problemas em adotarem uma
política de qualidade;
Apesar dos custos elevados, é importante introduzir sistemas de
gerenciamento de qualidade de software, como o ISO 9001 ou o CMM.
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
68
Introdução à Qualidade de Software
Situação da Qualidade de
Software no Brasil
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
69
Elaboração de planos estratégicos, plano
de negócios ou planos de metas
Categorias
Atualização sistemática
Revisão sem periodicidade fixa
Em implantação
Não elabora
CESAR/DI-UFPE
1993
%
34,5
38,5
13,1
13,8
1995
%
21,7
34,2
24,7
19,5
© 1998, Alexandre Vasconcelos
1997
Nº
159
183
150
97
%
27,0
31,1
25,5
16,5
70
Inclusão de metas ou diretrizes
para a qualidade
Categorias
Sistemática
Eventual
Pretende incluir
Não inclui
CESAR/DI-UFPE
1993
%
41,2
29,0
15,4
14,3
1995
%
38,9
29,3
28,7
3,1
© 1998, Alexandre Vasconcelos
1997
Nº
199
141
131
21
%
40,4
28,7
26,6
4,3
71
Coleta de indicadores da qualidade
de produtos e serviços
Periodicidade
Sistemática
Quando necessário
Em estudo
Não coleta
CESAR/DI-UFPE
1993
%
26,9
41,8
13,8
17,5
1995
%
25,1
42,1
21,7
11,1
© 1998, Alexandre Vasconcelos
1997
Nº
174
192
141
82
%
29,5
32,6
23,9
13,9
72
Contabilidade de custos da qualidade
e da não-qualidade
65%
381
6%
34
55
118
9%
20%
Não mantém
Em estudo
Em projetos específicos
10
4
6
4
6
Sistemática
9
93 95 97
Sistemática
CESAR/DI-UFPE
Em projetos específicos
© 1998, Alexandre Vasconcelos
73
Programa da qualidade total ou similar
46%
272
18%
104
212
36%
Não tem
Em estudo
Implantado
47
12
11
36
18
Implantado
CESAR/DI-UFPE
38
93 95 97
Em estudo
© 1998, Alexandre Vasconcelos
74
Certificação do sistema da qualidade
Empresas Certificadas
Setor de Informática
Pesquisa da Qualidade
Certificação ISO 9001
Certificação ISO 9002
SW explicitado no certificado
CESAR/DI-UFPE
© 1998, Alexandre Vasconcelos
1995
...
8
8
1
1
1997
124
44
35
11
15
75
Conhecimento do Modelo CMM
5%
71%
27
419
143
24%
Não conhece
Conhece, mas não usa
Conhece e usa
24
5
3
Conhece e usa
CESAR/DI-UFPE
11
95 97
Conhece, mas não usa
© 1998, Alexandre Vasconcelos
76
Métodos para apoiar a participação dos
empregados na solução de problemas
1993
%
Reuniões de trabalho
43,6
Procedimentos informais
34,9
Times, equipes ou círculos
...
Programas de sugestões
...
Outros métodos
14,6
Não adota/em estudo
6,9
CESAR/DI-UFPE
1995
%
61,3
37,4
12,4
18,7
2,5
10,8
© 1998, Alexandre Vasconcelos
1997
Nº
437
214
123
113
28
47
%
74,6
36,5
21,0
19,3
4,8
8,0
77
Avaliação de desempenho dos funcionários
Periodicidade
Sistemática
Eventual
Informal
Em implantação
Não realiza
CESAR/DI-UFPE
1993
%
18,2
13,8
44,7
9,5
13,8
1995
%
16,4
11,3
54,0
7,0
11,3
© 1998, Alexandre Vasconcelos
1997
Nº
103
62
281
63
78
%
17,5
10,6
47,9
10,7
13,3
78
Pesquisa de satisfação dos funcionários
Periodicidade
Sistemática
Eventual
Informal
Em implantação
Não realiza
CESAR/DI-UFPE
1993
%
6,1
9,0
56,7
7,2
20,9
1995
%
6,8
14,1
50,1
4,3
24,7
© 1998, Alexandre Vasconcelos
1997
Nº
%
49
8,3
62
10,6
272
46,3
53
9,0
151
25,7
79
Pesquisas de satisfação dos clientes
Periodicidade
Sistemática
Eventual
Em implantação
Dados de terceiros
Não realiza
CESAR/DI-UFPE
1993
%
21,3
50,5
8,7
1,8
17,7
1995
%
18,7
45,3
14,6
3,6
17,8
© 1998, Alexandre Vasconcelos
1997
Nº
147
248
78
27
88
%
25,0
42,2
13,3
4,6
15,0
80
Estruturas de atendimento e
resolução de reclamações
76%
93
40%
72%
71%
40%
48%
7%
38%
CESAR/DI-UFPE
97
60%
76%
Suporte
95
12%
11%
Visitas
Hot-line
© 1998, Alexandre Vasconcelos
Internet
81
Uso de dados de pesquisa ou de reclamações
44%
259
63
51
211
11%
9%
36%
Sistemática
Não usa
39
41
44
Em estudo
43
35
Eventual
36
93 95 97
Sistemática
CESAR/DI-UFPE
Eventual
© 1998, Alexandre Vasconcelos
82
Engenharia de Software
Principais métodos para prevenção de defeitos
Tipos
Controles de versão
Prototipação
Gerência de projetos
Métodos orientados a objetos
Análise de requisitos
Métodos estruturados
Projeto da interface com o usuário
Análise crítica conjunta
CESAR/DI-UFPE
1993
%
52,5
39,4
...
...
45,0
...
...
...
© 1998, Alexandre Vasconcelos
1995
%
53,7
46,5
...
43,4
47,4
...
...
...
1997
Nº
327
259
235
216
210
210
207
194
%
61,1
48,4
43,9
40,4
39,3
39,3
38,7
36,3
83
Engenharia de Software
Outros métodos para prevenção de defeitos
Tipos
Reuso
Engenharia da informação
Medições da qualidade (Métricas)
JAD
Gestão de configuração
Desenvolvimento em sala limpa
Estimação da confiabilidade
Gestão de mudança
QFD
Outros
CESAR/DI-UFPE
1993
%
...
...
...
...
...
...
...
...
...
...
© 1998, Alexandre Vasconcelos
1995
%
37,3
...
...
9,9
...
...
10,1
...
1,7
...
1997
Nº
110
104
48
46
40
36
32
32
11
19
%
20,6
19,4
9,0
8,6
7,5
6,7
6,0
6,0
2,1
3,6
84
Engenharia de Software
Principais métodos para detecção de defeitos
Tipos
Testes de sistema
Testes de campo
Testes de usabilidade
Testes funcionais
Testes de aceitação
Validação
CESAR/DI-UFPE
1993
%
64,2
55,0
...
58,5
46,8
...
1995
%
62,2
58,2
...
48,8
47,6
...
© 1998, Alexandre Vasconcelos
1997
Nº
392
357
327
329
278
250
%
69,4
63,2
57,9
58,2
49,2
44,2
85
Engenharia de Software
Outros métodos para detecção de defeitos
Tipos
Testes de unidade
Revisões estruturadas
Auditorias
Inspeções formais
Testes estruturais
Verificação independente
Outros
CESAR/DI-UFPE
1993
%
...
...
...
...
...
...
...
1995
%
23,6
2,0
...
10,1
...
...
...
© 1998, Alexandre Vasconcelos
1997
Nº
137
113
102
100
97
81
16
%
24,2
20,0
18,1
17,7
17,2
14,3
2,8
86
Principais Ferramentas Utilizadas
Tipos
Dicionários de dados
Gerador de relatórios
Gerador de telas
Depurador interativo
Gerador de código-fonte
Gerenciador de projetos
CESAR/DI-UFPE
1993
%
34,0
36,2
45,7
34,4
30,1
...
1995
%
38,4
44,5
46,7
33,3
37,3
...
© 1998, Alexandre Vasconcelos
1997
Nº
222
218
207
167
162
143
%
39,2
38,4
36,5
29,5
28,6
25,2
87
Outras ferramentas utilizadas
Tipos
Gerenc. bibliotecas de módulo
Gerador de gráficos
Documentador
Prototipador
Distribuição de software
CASE Lower
CASE Upper
Gerador de entrada de dados
CESAR/DI-UFPE
1993
%
26,6
24,5
19,1
18,4
...
24,5
...
45,7
1995
%
20,4
20,7
18,6
16,6
...
26,5
...
46,7
© 1998, Alexandre Vasconcelos
1997
Nº
116
115
104
90
86
81
79
63
%
20,5
20,3
18,3
15,9
15,2
14,3
13,9
11,1
88
Mais Ferramentas utilizadas
Tipos
1993
%
Gerenciador de configuração
Gerenciador de documento
Driver de teste
Gerador de dados de teste
Analisador de código
Otimizador
Outras
Não utiliza
CESAR/DI-UFPE
...
8,9
10,3
15,2
...
21,3
1995
%
10,3
...
6,5
5,8
9,9
8,8
7,0
10,8
© 1998, Alexandre Vasconcelos
1997
Nº
%
57
10,1
54
9,5
52
9,2
50
8,8
50
8,8
38
6,7
26
4,6
122
21,5
89
Principais documentos adotados
Tipos
Manual do usuário
Help on-line
Contratos e acordos
Guia de instalação
Documentação de programas
Documentação no código
Especificação de sistema
Documentação comercial
Doc. de descrição do produto
CESAR/DI-UFPE
1993
%
64,5
46,1
66,3
46,1
...
49,3
62,4
51,4
...
1995
%
83,3
62,3
67,1
44,5
45,4
47,3
54,1
46,6
...
© 1998, Alexandre Vasconcelos
1997
Nº
436
369
360
317
313
311
293
248
241
%
76,0
64,3
62,7
55,2
54,5
54,2
51,0
43,2
42,0
90
Outros documentos adotados
1993
%
56,7
Projeto de sistema
42,6
Manual de treinamento
...
Documentação de marketing
...
Doc. do processo de software
36,2
Plano de testes
Resultados de revisões / testes 31,6
...
Plano de controle da qualidade
...
Outros
...
Não adota documentação
Tipos
CESAR/DI-UFPE
1995
%
40,2
43,8
...
...
22,4
21,9
...
...
2,5
© 1998, Alexandre Vasconcelos
1997
Nº
223
209
193
141
125
126
39
12
17
%
38,9
36,4
33,6
24,6
21,8
22,0
6,8
2,1
3,0
91
Biblioteca Técnica Especializada
11%
49%
61
284
232
40%
Sem registro bibliográfico
Com registro bibliográfico
93
45,1
45
40,2
Com registro
CESAR/DI-UFPE
43,3
46
95
Não mantém
97
49,2
Sem registro
© 1998, Alexandre Vasconcelos
92