A Garantia da Qualidade e o

Ana Liddy Cenni de Castro Magalhães

Treinamento – SPIN-SP – 25/Abril/2006

 Motivação

O que é qualidade?

Como avaliar a qualidade de um produto?

O que garante a qualidade de um produto?

O que é garantia da qualidade?

Qual a diferença entre planejamento, gestão,
controle e garantia da qualidade?

Como estes conceitos estão relacionados?

O que uma organização deve esperar da área da qualidade?

O que a área da qualidade deve realmente verificar?

Quem é responsável pela verificação dos produtos gerados?

Quem é responsável pela verificação dos processos executados?
 Motivação

Porque as pessoas não gostam de auditoria?

Por que estereótipos tão fortes são criados e se perpetuam?

Por mais que o trabalho do SQA auxilie a organização no
desenvolvimento de seus projetos, ele é visto com rejeição...

De quem é a culpa?

Dos auditados, que receiam ter
seus erros expostos
e receber críticas?

Do SQA, que alimenta seu ego
com o medo demonstrado
pelos auditados?
 Objetivos

Apresentar os conceitos que permeiam

a garantia da qualidade

Planejamento, gestão, controle e garantia da qualidade

Apontar motivos que geram este clima de

desconfiança e medo
Relatar a experiência vivenciada
Mostrar como o SQA pode mudar sua
relação com pessoas / organização

Como ajudar ou atrapalhar a
institucionalização de processos

Como enfrentar as dificuldades
surgidas e quebrar este estereótipo
 Agenda

O Contexto da Garantia da Qualidade de Software

 Entendendo o conceito de qualidade
 Planejamento, garantia, controle e gerência da qualidade
 A garantia da qualidade nos principais modelos

O Caminho da Maturidade e o Papel do SQA
 Principais características de cada nível de maturidade
 Evolução das atribuições: o SQA e a equipe de projeto

A Postura do SQA e a Organização
 Conduta pessoal, profissional e na auditoria
 A postura do auditado e os resultados de uma auditoria

Experiência Vivenciada pelos SQAs da FITec
 Visão Geral da FITec
 Mudança da percepção dos SQAs nos projetos

Considerações Finais
 Qualidade: Conceito

Você vive com qualidade?

Você trabalha com qualidade?
O que é qualidade para você?
E para seus clientes?
Como você comprova a
qualidade do seu trabalho?
 Qualidade: Conceito
Atratividade
Valor por dinheiro de mercado

Conformidade com
as especificações

Adequação ao uso
 Qualidade: Conceito

Satisfação do Cliente: busca da cadeia do sucesso

 Qualidade: Conceito
Produto
(bem ou serviço)

A totalidade das características de uma entidade

que lhe confere a capacidade de satisfazer às
necessidades explícitas e implícitas (NBR ISO 8402)
Condições e objetivos Visão
propostos / definidos subjetiva

É o grau em que um sistema, componente ou

processo satisfaz as necessidades ou
expectativas do cliente ou usuário
 Qualidade é ...

Atender a 100% das necessidades (requisitos) do cliente, já

conhecidos e aceitos por nós...
Manter os clientes atuais satisfeitos e buscar novos clientes,
atendendo expectativas quanto a produtos e serviços atuais e futuros

Mas... quem é o cliente?

É todo aquele que recebe o resultado de um conjunto de atividades,
podendo ser:
 Interno: recebe os resultados
do trabalho que você faz
 Externo: recebe os resultados
do trabalho que a organização faz
 Qualidade:
Relação entre Produto e Processo

Estágio de Insumo Estágio de Conversão Estágio de Produto

Matérias-primas
PROCESSOS
Bens

Capital e recursos
Maquinários
Serviços

Recursos humanos
Habilidades humanas

Requisitos Processo Produto

Problemas no processo  Problemas no produto
Qualidade no processo  Qualidade no produto
Qualidade do Produto

Conformidade do produto com os requisitos

Qualidade do Processo

Grau em que o processo garante a qualidade do produto
 Qualidade:
Relação entre Produto e Processo
Diversas atividades do processo afetam a qualidade
final do produto

Se as atividades não forem bem definidas, ao serem executadas,
o produto poderá sofrer as conseqüências

O objetivo do processo é gerar um produto de qualidade

Se o produto gerado não tiver qualidade satisfatória,
o processo deverá ser revisto

Definir o Desenvolver o Avaliar a qualidade

processo produto do produto

Melhorar o N Qualidade S Padronizar o

processo OK? processo
 Qualidade:
Principais Áreas

Planejamento Garantia da
da Qualidade Qualidade
Qualidade

Gestão da Controle da
Qualidade Qualidade
 Gestão da Qualidade

Objetivos

Determinar e implementar
a Política da Qualidade

A Gestão da Qualidade deve:

Fazer planejamento estratégico
- estabelecer metas
- definir responsabilidades

Alocar recursos para as atividades sistemáticas da qualidade
- planejamento, controle, garantia
- melhoria contínua da própria qualidade
 Planejamento da Qualidade

Objetivos

Desenvolver produtos e processos
para atender às necessidades dos clientes

O Planejamento da Qualidade deve:

Entender as necessidades dos clientes

Desenvolver características de produto que
atendam às necessidades

Identificar processos e padrões capazes
de produzi-las

Concretizar os planos
 Controle da Qualidade

Objetivos

Planejar, manter e melhorar a qualidade (Trilogia de Juran)

Monitorar resultados, a fim de determinar se eles estão de
acordo com os padrões relevantes de qualidade

Atuar na eliminação e bloqueio da causa fundamental
de problemas e resultados insatisfatórios

O Controle da Qualidade deve:

Gerenciar processos, de forma a mantê-los
sob controle

Identificar formas de eliminar as causas de um
desempenho insatisfatório

Incluir inspeções, revisões e testes
 Garantia da Qualidade

Objetivos

Aplicar as atividades de Qualidade planejadas
para que sejam utilizados todos os processos
necessários para
atender aos requisitos

A Garantia da Qualidade deve:

Prover visibilidade (por meio de evidências) de que se está
satisfazendo requisitos e padrões relevantes de qualidade
definidos no plano

Assegurar que artefatos e processos estão
em conformidade com o plano

Certificar que todas as atividades da qualidade planejadas
estão sendo executadas
 Qualidade de Software:
Conceito

É o grau de conformidade do sistema,

componente ou processo com:

Requisitos funcionais e de desempenho
explicitamente declarados

Padrões de desenvolvimento claramente documentados

Características implícitas definidas, esperadas
de todo software profissional
(necessidades e expectativas)
 Qualidade de Software:
Dificuldades
Características gerais de um software

Produtos de software são geralmente complexos

Software não tem produção em série

Software não se desgasta e nem se modifica
com o uso

Utiliza representações variadas e imprecisas

A engenharia de software é uma tecnologia
em evolução
 Qualidade de Software:
Dificuldades
Características técnicas

Existência de requisitos implícitos
 Especificação possui características desejadas pelo cliente
 A organização pode ter requisitos não incluídos
• Ex: facilidade de uso e manutenibilidade

Existência de requisitos ambíguos
 Impossível especificar certas características
sem ambigüidade

Dificuldade para escrever uma especificação completa
 Qualidade de Software:
Necessidade
Ciclo de Vida Básico de Software

Perspectiva de um projeto

Idéias / Necessidades (Cliente)

Requisitos

Projeto Projeto
de
Codificação Software

Testes

Produto (Cliente)
 Qualidade de Software:
Necessidade
Cada etapa pode acabar introduzindo erros

É necessário seguir processos que possibilitem garantir a
qualidade dentro das restrições de imperfeição impostas...

Requisitos Requisitos
corretos defeituosos

I Projeto Projeto Erros inseridos Vida Real

D correto defeituoso p/ requisitos
E
A
L Código correto Código Erros inseridos Erros inseridos
defeituoso p/ requisitos p/ projeto

Testes Testes Erros inseridos Erros inseridos Erros inseridos

corretos defeituosos p/ requisitos p/ projeto p/ código
 Qualidade de Software:
Impactos
Impactos no Produto

Requisitos incompletos, faltantes ou não testáveis

Defeitos identificados tardiamente
(dificultando a correção)

Documentação do produto incompleta
ou inconsistente

Rejeição ao produto

Impactos no Custo

Grande retrabalho

Aumento exponencial com a complexidade do projeto

Detecção/correção de defeitos aumenta em relação
ao tempo em que o defeito está presente

% crescente dos custos de manutenção
 Qualidade de Software:
Impactos
Impactos no Tempo

Tempo para testes aproxima (ou supera!) o de desenvolvimento

Projeto excede prazo de entrega, podendo ocasionar:
 Perda de mercado
 Cancelamento do projeto
 Perda do retorno sobre o investimento e do próprio investimento

A qualidade de um produto de software

é altamente influenciada pela
qualidade do processo utilizado em seu
desenvolvimento e manutenção!
 Garantia da Qualidade
de Software

É o conjunto de atividades projetadas para avaliar o

processo pelo qual o software é desenvolvido

Embute mecanismos preventivos que diminuem o número
de defeitos injetados ao longo do projeto

Os processos podem ser apoiados pelo uso de ferramentas
que integrem o uso de padrões de qualidade

Também denominada SQA

(Software Quality Assurance)
 Garantia da Qualidade
de Software
Envolve definir, selecionar e seguir padrões

Padrões de produto
 Se aplicam ao produto gerado na saída dos processos
• Padrões de artefatos (ex: especificação de requisitos)
• Padrões de documentação (ex: cabeçalho/comentários no código)
• Padrões de codificação (como utilizar a linguagem)

Padrões de processo
 Definem atividades a serem realizadas para assegurar que os
padrões de produto estão sendo seguidos
• Ex: definições de atividades de especificação de requisitos,
processos de projeto e validação, descrição dos
documentos a serem gerados
 Garantia da Qualidade
de Software: Importância

Assegura que a qualidade não será comprometida

Fazer direito, para evitar retrabalho, reduzindo custos e prazo

Encontrar erros antes que se transformem em defeitos

Relatar à alta gerência desvios que não podem ser
tratados dentro do escopo de projetos

Acompanhar a resolução de desvios,
garantindo sua execução
Fornece uma visão objetiva e independente

Tanto para atividades de processo quanto de produto,
em relação a desvios e pontos de melhoria

Avalia a aderência dos produtos a padrões, processos,
procedimentos e requisitos estabelecidos e aplicáveis
 Garantia da Qualidade de
Software: Evidência Objetiva
Evidência Objetiva

Informação qualitativa ou quantitativa, registro ou declaração de
fato pertinente às características daquilo que está sendo
analisado

Baseada na observação, medição ou teste

Deve ser verificável
 Algo que você veja
 Algo que é dito por um representante da gerência como
sendo a política ou prática da empresa
 Algo que é dito por um funcionário descrevendo sua
compreensão do que é a prática da empresa

Não é Evidência Objetiva

“Ouvir dizer”

Algo dito por alguém sobre o que outra pessoa faz
 A Garantia da Qualidade de
Software nos Principais Modelos
Normas ISO 9000: Sistema de Gestão da Qualidade

Consenso internacional sobre boas práticas de gerenciamento para garantir
o atendimento aos requisitos do cliente e melhoria contínua

Aplicável em qualquer tipo de organização

Seção 8: Medição, Análise e Melhoria
 8.2.2 a 8.2.4: auditoria interna, avaliação objetiva de processos e produtos
 8.5.2 e 8.5.3: ações corretivas e preventivas
 A Garantia da Qualidade de
Software nos Principais Modelos

Norma ISO/IEC 12207: Processo de Ciclo de Vida

Descreve a arquitetura dos
processos de ciclo de vida

Não especifica detalhes de
como executar as atividades

Não prescreve:
 Modelo de ciclo de vida
 Método de desenvolvimento
 Linguagem de programação

Garantia da Qualidade
 Processo de Apoio
 A Garantia da Qualidade de
Software nos Principais Modelos
Norma ISO/IEC 15504 e Projeto SPICE:
Software Process Improvement and Capability dEtermination

Modelo de referência com processos e níveis de capacidade

Guias: avaliação, melhoria, determinação de capacidade, qualificação de auditores

Garantia da Qualidade: processo da categoria Suporte (SUP.3)

Gerência da Qualidade: processo da categoria Gerência (MAN.3)
 A Garantia da Qualidade de
Software nos Principais Modelos
Projeto mps.Br: Melhoria de Processo do Software Brasileiro

Objetivos e práticas distribuídos em 7 níveis de maturidade:
A Em Otimização
B Gerenciado Quantitativamente
C Definido
D Largamente Definido
E Parcialmente Definido
F Gerenciado
G Parcialmente Gerenciado

Garantia da Qualidade:
 Processo de Apoio (GQA), do Nível F
 A Garantia da Qualidade de
Software nos Principais Modelos
CMMI: CMM Integration

Área de Proceso (PA) PPQA: Process and Product Quality Assurance

Versão Por Estágio Contínua

1 2 3 4 5
N5

Capacidade
Nível de
N4

N3

N2 PPQA

0
N1 PA PA PPQA
Avaliação de um conjunto Avaliação por PA ou
predefinido de PAs por nível por grupo de PAs
 O Caminho da Maturidade:
Nível 1- Inicial

Objetivo: conseguir entregar

Processo de desenvolvimento inexistente ou improvisado

O sucesso depende do esforço individual

Grande dependência de pessoas: heroísmo

Faça alguma coisa! Para produzir

Atividade Resultados

Comprometimento com a qualidade

Variável, em função do cronograma (pouca visibilidade)

A responsabilidade pela qualidade é um desafio pessoal
Área da qualidade (quando existente) sem nenhuma autoridade
A iniciativa pela qualidade compete com várias outras
atividades com visibilidade similar
 O Caminho da Maturidade:
Nível 2 - Gerenciado
Objetivo: disciplina e gestão de projetos

Foco: desenvolvimento do projeto de software

Processos básicos de gestão de projetos são estabelecidos
para acompanhar o custo, cronograma e funcionalidade

A disciplina necessária é estabelecida para repetir sucessos
anteriores em projetos semelhantes

Planejamento

Pense antes e Para produzir

Atividade Resultados
depois de agir
Entrada

Tenha certeza Para melhorar

de que foi feita a Avaliação
coisa certa!
Figura adaptada de L. C. Parzianello
 Organização Nível 2:
O Papel do SQA

Principais Objetivos

Garantir a disciplina por meio da garantia dos processos
 Garantir o seguimento da política e a aplicação dos processos definidos
 Atividades de revisão ainda limitadas
 Tratamento de problemas reincidentes
 Ainda não existem metas de qualidade definidas

Prover à gerência visibilidade em relação a processos e produtos
 Durante todo o ciclo de vida: avaliação de atividades e produtos de trabalho
 Em cada processo do nível 2: garantia da conformidade com o CMMI

Orientar o desenvolvimento do produto e atividades, com base no CMMI
 Novos procedimentos e padrões (formato / conteúdo)

Implementação Típica

Gerência de SQA: posição permanente e independente dos projetos
 Existem analistas da qualidade dedicados
 Freqüentemente não técnicos

Relacionamento com a equipe do projeto
 Efetivo, provendo limitada consultoria
 Faz revisões / auditorias e acompanha ações decorrentes
 O Caminho da Maturidade:
Nível 3 - Definido
Objetivo: padronização dos processos (com adaptação)

Foco: processo de desenvolvimento de produtos e seu suporte

Processos padrão para o desenvolvimento e manutenção de
produtos são documentados e usados em toda a organização

Disciplina de processos é estabelecida para garantir a padronização
e a consistência nos resultados dos projetos com aplicações similares

Planejamento Faça uso das lições aprendidas!

Entrada

Atividade
Para produzir Resultados
Padrões

Entrada
Para melhorar
Entrada Avaliação

Figura adaptada de L. C. Parzianello

 Organização Nível 3:
O Papel do SQA
Principais Objetivos

Garantir a padronização e adaptações com critérios corretos
 Assessorar decisões de adaptação de processos e produtos aos projetos
 Prover consultoria na aplicação de padrões

Aprimorar visibilidade e confiança da gerência em relação aos processos
 Atividades de revisão e auditorias de produto mais efetivas e eficientes
 Tratamento de soluções sistemático

Ajudar na manutenção da base histórica e de conhecimento

Implementação Típica

Grupo de SQA com conhecimento técnico e experiência
 Auxílio efetivo no desenvolvimento de padrões e procedimentos
 Grande canal com o SEPG

Relacionamento com a equipe do projeto
 Ativamente envolvido no desenvolvimento e aplicação
de “guias de adaptação”
 Intimamente ligado a todos os grupos relativos
ao desenvolvimento do produto
 O Caminho da Maturidade: Nível 4
- Quantitativamente Gerenciado
Objetivo: gestão quantitativa dos processos e projetos

Foco: estabelecimento e alcance de metas de qualidade quantitativas
de processos e de produtos

Projetos alcançam controle, estreitando a variação de performance

A gerência tem uma base objetiva para a tomada de decisão
 Baseada em controle estatístico de processos
 Capaz de prever a performance dentro de limites quantitativos
Preveja os resultados que você
necessita e espera e então crie
Planejamento oportunidades para alcançá-los!

Entrada Para prever

Padrões Atividade Para produzir Resultados

Entrada
Entrada
Para melhorar
Avaliação
Figura adaptada de L. C. Parzianello
 Organização Nível 4:
O Papel do SQA
Principais Objetivos

Garantir o uso e a aderência aos processos, com menor variação
 Orientar decisões de adaptação de processos e produtos aos projetos
 Orientar na utilização de padrões de processos e produtos

Aumentar e visibilidade e confiança da gerência nos resultados
 Medição da performance do processo e estabelecimento de metas
• Controle estatístico de processos
 Atividades de revisão e auditorias de produto efetivas e eficientes

Acompanhar baseline da capacidade do processo

Implementação Típica

SQA se torna “SQE” - Engenheiro da Qualidade de Software

Relacionamento com a equipe do projeto
 SQAs / SQEs totalmente integrados à equipe
• Fornecendo suporte na implementação da qualidade
• Definindo objetivos da qualidade
• Ativamente envolvidos em definir e implementar a coleta e análise de dados
 Relatórios provêem subsídios para a identificação e resolução de
causas especiais de variação de performance e ajuste de metas
 O Caminho da Maturidade:
Nível 5 - Em Otimização
Objetivo: melhoria contínua tecnológica e dos processos

Foco: melhoria contínua da organização como um todo,
de forma madura e proativa

Busca contínua de maior efetividade e eficiência de seus processos
Investimento contínuo na melhoria da capacidade dos processos e
da performance destes nos projetos
Crie lições aprendidas e
utilize-as para criar mais
Planejamento lições e assim por diante ...

Entrada Para prever

Para produzir
Padrões Atividade Resultados

Entrada
Entrada
Para melhorar
Para melhorar Avaliação

Figura adaptada de L. C. Parzianello

 Organização Nível 5:
O Papel do SQA
Principais Objetivos:

Ser um canal de comunicação para a melhoria

Cuidar da prevenção de problemas de qualidade nos produtos
 Agente na prevenção de defeitos (DP)

Continuar garantindo o uso e a aderência aos processos, assessorando:
 Decisões de adaptação de processos e produtos aos projetos
 Medição e estabelecimento de metas
 Ajustes na capacidade do processo

Continuar proporcionando visibilidade adequada
 Atividades de revisão e auditorias de produto efetivas e eficientes

Implementação Típica

Estrutura de SQA / SQE / DP consolidada

Relacionamento com a equipe do projeto
 Propostas de melhoria e inovação
 Canal totalmente aberto e mais efetivo
 Garantia da Qualidade
de Software: Problemas

O papel de SQA não está claramente definido

nas organizações
Normalmente as organizações não possuem um
Grupo de QA ou pessoas especializadas para
realizar as atividades
Falta de apoio e incentivo da alta gerência
Falta de patrocínio para as
atividades de QA

Comportamento Humano
Trabalha aspectos humanos

Ouve, orienta, encoraja

Mantém-se neutro em
conflitos de interesses
Comportamento profissional
e ético

Adequado, conveniente

Discute assuntos pertinentes
Honesto, direto, justo
Respeitoso
Confiante e decidido
Usa seu próprio julgamento
A Postura de um SQA:
Desconsidera aspectos humanos

Sentimentos, receios

Envolve-se em interesses,
jogo de poder
Não segue valores e princípios
morais

Discute assuntos delicados ou
confidenciais
Desonesto, polêmico, irônico
Arrogante
Insolente (atrevido) e inseguro
Age em função dos outros
 A Postura de um SQA:
Comportamento Humano

Bom ouvinte, interessado, Desinteressado, mal ouvinte,

simpático e compreensivo
Perseverante e inquisitivo
Imagem e conduta correta
Não abre mão de suas
convicções
Paciente, amigável e respeitoso
Cultiva a cooperação e a
confiança
Considera-se parte da equipe,
mas age como um convidado
Não dá conselhos
antipático e autoritário
Argumentativo e teimoso
Comportamento imprevisível
Crédulo (inocente), sem
argumentação
Impaciente e indelicado
Faz intrigas e atrapalha as
atividades
Julga-se superior à equipe
do projeto, “não se mistura”
Considera-se “o
dono da verdade”
 A Postura de um SQA:
Atribui culpa ao processo
Utiliza termos mais “suaves”

Verificação de SQA

Oportunidade de melhoria
Postura consultiva, próxima

Consultor dos processos
Entende a resistência como
parte da cultura existente
Trabalha de maneira
independente

Critérios de atuação bem
definidos

Impessoalidade no relato

Canal direto com a alta gerência
Conduta Profissional
Atribui culpa às pessoas
Utiliza termos “pesados”

Auditoria

Não conformidade
Postura distante da equipe

Só “audita” e aponta “erros”
Entende a resistência como
algo pessoal
Não possui autonomia
(possui “rabo preso”)

Sem critérios claros para atuação

Tendencioso no relato

Dependência de
outros canais
 A Postura de um SQA:
Conduta Profissional

Introduz processos de forma Impõe processos, obriga

planejada e “informativa”
Possui atitude preventiva

Evita que problemas ocorram
Orienta como fazer
Cria um clima encorajador
É um instrutor, comunicativo

Educador em melhoria de
processos e CMM
Uma ajuda e um benefício
para os projetos em que
atua
seu uso, sem ponderação
Possui atitude reativa

Resolve problemas ocorridos
Pune pelo não cumprimento
Cria um clima frio, neutro
Pouco comunicativo

Atrapalhado, confuso, de
difícil compreensão
Um complicador e um
obstáculo a mais para os
projetos em que atua
 A Postura de um SQA:
Conduta na Auditoria
Planeja e agenda as auditorias com
antecedência
Direciona as informações

Busca o consenso antes de relatar

Resolve questões com os envolvidos
antes de informar seu superior
Gerencia pendências de auditoria até
o seu fechamento

Controla datas e prazos, examina ações
propostas, atribui responsabilidades
Trabalha objetivamente

Baseia-se em fatos

Possui critérios bem definidos
Ouve e respeita o auditado, sem
interrompê-lo ou menosprezá-lo
Reporta o que é importante,
significativo, fundamental
(evita adjetivos e advérbios)
Surpreende a equipe com
auditorias não planejadas
Reporta tudo a todos

Divulga resultados sem validá-los

Comenta / usa as informações
obtidas de forma arbitrária
Negligencia e não acompanha
pendências de auditoria

Fica perdido sem saber o que
falta e o que deve fazer
Não possui critérios claros

Baseia-se em deduções

Age arbitrariamente
Não sabe ouvir e respeitar o
auditado, discute com ele
Se perde em meio a fatos e
suposições, sem compreender
sua relevância
 A Postura de um SQA:
Conduta na Auditoria

Atua como consultor interno, Atua como fiscal, desconsidera o

passando feedback para o SEPG
sobre adequação dos processos
Pergunta de forma clara
Observa, verifica o que vê e ouve,
de forma independente
Baseia-se em fatos
É pontual e controla o tempo da
auditoria, cuidadosamente

Consegue fazer tudo aquilo a
que se propõe
Possui “jogo de cintura”, é
desembaraçado, claro, franco
Aponta problemas imediatamente
Usa linguagem adequada com o
entrevistado (certifica que entendeu)
SEPG como parte integrante do
processo de melhoria
Induz a resposta, “joga verde”
Satisfaz-se com amostras de
evidências providas por outros
Baseia-se em deduções
Indisciplinado, descontrolado em
relação à auditoria

Faz “o que for possível” fazer,
sem se ater a um plano
Desarticulado (confuso, vago,
indistinto, incompreensível)
Aceita julgamentos e aparências
Procura mostrar seu “grande”
conhecimento, falando “difícil”
 A Postura de um Auditado
Ativo e colaborador – vê o SQA
como um assessor / consultor
Claro e objetivo
Limita-se a responder o que foi
perguntado
Diz o que realmente faz e faz o
que realmente diz
Fornece somente o documento ou
registro solicitado
Mostra-se “transparente”
Postura ética e independente
Lembra-se de fatos relevantes
Consciente de seu papel e
responsabilidade nos processos
Preguiçoso, “manco”, provocativo
– vê o SQA como uma ameaça
Induz o desperdício de tempo
Prolixo, procura sempre por casos
especiais
Diz fazer algo além do que está
sendo solicitado
Entrega pastas contendo outros
documentos/registros
Adota postura comprometedora
Bajulador, faz falsos elogios
Possui “péssima memória”
Esquiva-se de tudo
(“isso é tarefa do fulano”)
 Implicações de uma Auditoria
Obtém um retrato fiel da situação atual
da organização / do projeto
Inclui preparação, entrevistas, check-
lists, registros, relatórios
Baseada em evidências objetivas
Aponta desvios e oportunidades de
melhoria reais, possibilitando melhor
acompanhamento
Maior chance de detectar problemas
antes → ganho em produtividade
Garantia do uso de padrões e processos
→ maior qualidade
Processo decisório pode ser
apoiado em dados confiáveis
Aponta o grau de implementação dos
processos, possibilita melhoria contínua
Falseia a situação real da
organização / do projeto
Realizada de forma ad-hoc, sem
“perda de tempo”
Baseada em suposições
Aponta resultados pouco precisos
e significativos, atrapalhando o
acompanhamento
Maior chance de incidência de
problemas pós-release
Uso de padrões e processos em
função de outros interesses
Pouca visibilidade da situação, sem
colaborar com o processo decisório
Processos e práticas sem
referência para melhoria
 Experiência da FITec:
Visão Geral da Empresa
Recife
Entidade privada sem fins lucrativos

criada em 09/2001
P&D Telecom, TI, Energia e Automação
Campinas

comercial, bancária, industrial, hospitalar
Belo Horizonte
Sites em Campinas, Belo Horizonte e Recife

Principais Tecnologias

FITuav: Veículo Aéreo Não-Tripulado

FITphone: Softphone SIP

FITsurvey: Pesquisa de Opinião em Palm

FITmetering: Sistema de medição de gás, água e energia

FITplc: Família de produtos PLC (Power Line Communications)

FITmanager: Sistema de Gerência de Projetos
 Experiência da FITec:
SW-CMM e CMMI na FITec

Unidade de Recife

Certificada SW-CMM Nível 2 em abril/2005

Trabalhos para o CMMI Nível 3 em andamento

Unidades de Campinas e Belo Horizonte

Em fase adiantada de institucionalização do Nível 2
Inicialmente SW-CMM, migrando para CMMI

Principais dificuldades:
Projetos envolvendo software, hardware, firmware
Projetos desenvolvidos em mais de um site
Grande variedade de tipos e tamanhos de projetos
Cultura de desenvolvimento existente (vícios)
Forte influência do principal cliente na forma de trabalho
 Experiência Vivenciada
pelos SQAs da Fitec
Cenário é um pouco diferente nos 3 sites

Problemas enfrentados pelos SQAs variam

Tipo de problema semelhante, mas com timing variado

Possível identificar 3 fases distintas

Fase 1. Durante a escrita dos processos

Ninguém entende ao certo qual é o papel do SQA

Chato: cobra execução e cumprimento do prazo de definição dos
processos, templates, procedimentos, etc.

Preguiçoso: o SQA deveria escrever tudo, para as áreas revisarem
(afinal, esse não é o papel da área de qualidade?)

Busca poder: quer tirar poder dos gerentes de projeto e mudar toda a
forma como a organização trabalha
 Experiência Vivenciada
pelos SQAs da Fitec
Fase 2. Durante o processo de institucionalização

SQA passa a auditar com base nos processos

Equipe começa a entender o papel do SQA, mas com resistência
 Acham que o SQA está apontando seus defeitos, gerando atrito
 Crença de que o SQA teria que resolver os desvios encontrados
 Gostariam que o SQA ficasse com o trabalho de acertar os processos

GP percebe que "perdeu" um pouco do poder que tinha em suas mãos
 Combate à área de qualidade - diversas tentativas:
• Colocar o SQA respondendo ao GP
• Quebrar o canal direto com a gerencia sênior
• Desacreditar o trabalho do SQA: problemas detectados
já conhecidos, de nada ajuda seguir os processos
• Colocar os clientes contra os processos: alega que atrasos
são decorrentes da burocracia gerada pelos processos

Resistência de alguns à aplicação dos processos
 Estão burocratizando, engessando, tirando a liberdade, complicando

SQA atua como “psicólogo” para a aceitação dos processos
 Mostra os benefícios que os processos podem trazer ao projeto,
tais como controle e visibilidade do que está sendo feito
 Experiência Vivenciada
pelos SQAs da Fitec

Fase 3: Projetos rodando processos nível 2 a pleno vapor

Equipe entende melhor o papel do SQA  atividade natural
 Desvios não geram mais conflitos entre SQA e equipe
 Desvios passam a ser vistos como problemas da equipe, e não do SQA
 SQA aponta problemas que passavam desapercebidos
 fornece visibilidade

SQA passa a ser cobrado pela execução das atividades planejadas
 GP/CS sentem falta e já solicitam que seja feita a auditoria

SQA com canal direto e oficial com a gerência sênior
 Não é mais visto como um problema

Percepção dos benefícios de se seguir os processos
 Considerações Finais

Ser um SQA respeitado e de quem as pessoas gostam não é fácil...

Ninguém gosta de ser auditado, de receber críticas e ter defeitos apontados

Somos parte de um sistema, onde todos contribuem para seus resultados
Necessário “medir e regular” a temperatura do ambiente

Identificar e apontar áreas que estão efetivamente funcionando e áreas onde
existe necessidade de ações corretivas ou oportunidade para melhoria

Não ter preconceitos: fatos devem prevalecer sobre as opiniões
Necessário ter habilidades técnicas e interpessoais

Ter perfeito conhecimento dos requisitos requeridos pela norma/modelo e
dos requisitos dos processos organizacionais

Demonstrar consideração e respeito pelos sentimentos e habilidades do outro
Auditar requer confiança, rastreabilidade, cortesia e sensibilidade

Ao entrevistar um auditado, pense em como se sentiria em seu lugar

Perguntas e respostas devem ser construídas em parceria

Confiança não se conquista de imediato, ela se constrói durante o trabalho

Missão do SQA: deixar o ambiente melhor do que encontrou!!

 Dúvidas
Sugestões

Obrigada!
analiddy@gmail.com