Junho 2014

[TECNOLOGIAS EM PROJEO]

Ao Corretiva: anlise de causa raiz dos defeitos e proposta

de um plano de ao
Cristiane Corra da Silveira, Marcelo Carboni Gomes

Resumo: O objetivo deste trabalho apresentar os resultados referentes ao estudo do

mtodo de anlise de causa raiz, das tcnicas para sua aplicao e a elaborao de um plano
de ao para os defeitos de um software financeiro. Para o seu desenvolvimento foi utilizada
uma base terica que apoiou o processo e viabilizou a aplicao deste mtodo.
Palavras-chave: Anlise de causa raiz; Defeito; Ao corretiva.
Abstract. The objective of this work is to present the results for the study of the method of
root cause analysis, techniques for application and elaboration of a plan of action for defects
of a financial software. For its development I used a theoretical base that supported the
process and made possible the application of this method.
Keywords: Root cause analysis; Bug; Corrective action.

Introduo
Atualmente, a maioria das empresas de TI (Tecnologia da Informao) possui processos de
negcio complexos e pouco maleveis, que ao serem utilizados no decorrer do processo de
desenvolvimento de softwares permitem o surgimento de anomalias. Segundo PMBOK
(2008), processo um conjunto de aes e atividades inter-relacionadas que so executadas
para alcanar um objetivo.
Com a evoluo tecnolgica das organizaes e a crescente exigncia por qualidade, muitas
pessoas e empresas comeam a se preocupar tambm cada vez mais com a qualidade de
seus produtos e servios, o processo de garantia da qualidade. O CMMI-DEV 1.2 descreve
que o propsito da Garantia da Qualidade de Processo e Produto (PPQA) munir a equipe e
a gerncia com uma viso clara sobre os processos e seus produtos de trabalho associados.
Para Sommerville (2003), a adequao do processo de desenvolvimento um dos principais
fatores para melhorar a qualidade do produto. Uma vez que os processos so aprimorados
para melhorar a qualidade do produto e, em particular, para reduzir o nmero de defeitos
nos softwares fornecidos, a reduo dos custos e do tempo pode se tornar a principal meta
de melhoria.
O termo defeito muitas vezes utilizado de forma genrica. No entanto, importante ter
em mente que sua interpretao depender do contexto em que ele for utilizado. Estas
definies seguem a terminologia padro para Engenharia de Software do IEEE (IEEE 610.12,
1990):

Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

13

Junho 2014

[TECNOLOGIAS EM PROJEO]

Erro: um defeito cometido por um indivduo ao tentar entender uma determinada

informao, resolver um problema ou utilizar um mtodo ou uma ferramenta;
Defeito (ou Falta): uma manifestao concreta de um erro num artefato de
software. Um erro pode resultar em diversos defeitos;
Falha: o comportamento operacional do software diferente do esperado pelo
usurio. Uma falha pode ter sido causada por diversos defeitos e alguns defeitos
podem nunca causar uma falha.
Nesse estudo a nomenclatura utilizada para as anomalias identificadas no software ser
defeito, a divergncia no comportamento esperado de um sistema.
Normalmente, quando os defeitos ocorrem, a equipe busca solues paliativas que
permitem a soluo momentnea deste em curto prazo. No entanto, ao construir novos
projetos, os mesmos problemas voltam a ocorrer devido a ter sido tratado somente o efeito
e no a causa do problema (HERAVIZADEH; MENDLING; ROSEMANN, 2008).
Sempre que um defeito volta a ocorrer, o tempo e o custo para sua resoluo se tornam
maiores (HERAVIZADEH; MENDLING; ROSEMANN, 2008). Isto ocorre, pois a equipe somente
realiza a implementao da soluo, sem desprender tempo com documentao do
processo de resoluo do defeito ou analisar, o motivo, frequncia ou os principais efeitos
da ocorrncia deste defeito. No entanto, este quadro pode ser evitado ao ser analisada a
causa de origem do problema atravs do mtodo de Anlise da causa raiz.
A Anlise de Causa Raiz, tambm conhecida como RCA (Root Cause Analysis) uma maneira
de identificar os motivos que auxiliaram na gerao de um problema, afinal os problemas
so melhores resolvidos ao tentar corrigir ou eliminar as suas causas. Atravs deste mtodo,
possvel a elaborao e aplicao do plano de ao corretiva e passa-se a monitorar as
causas dos defeitos, atuando no processo como um todo antes que estes defeitos voltem a
ocorrer (ROONEY & HEWEL, 2004).
Conforme JUCAN (2005), o esforo para identificar a causa raiz de um problema no um
processo fcil, depende da experincia da equipe. Apesar disto, devido ao avano da
tecnologia, este processo tornasse cada vez mais necessrio, pois existem cobranas
referentes qualidade do produto entregue, tanto pelo cliente quanto da gerncia. Estes
solicitam retornos comprovados das causas originais dos defeitos, bem como quais foram s
aes utilizadas para resoluo e preveno para que estes defeitos no ocorram
novamente.
J ANDERSEN & FAGERHAUG (2006), definem que o processo de anlise de causa raiz
permite uma maior agilidade e eficcia para a identificao dos fatos que auxiliaram na
ocorrncia dos problemas. JUCAN (2005) salienta que o processo de identificao da causa
raiz, dependendo da tcnica utilizada, pode despender semanas ou meses de avaliao
exaustiva. Cada vez mais os projetos de TI so rpidos e precisam de tcnicas geis para
identificao da origem dos seus problemas.
Nas etapas metodolgicas deste estudo, se iniciou uma pesquisa bibliogrfica sobre a
identificao da origem dos seus problemas, o estudo da anlise de causa raiz e suas
Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

14

[TECNOLOGIAS EM PROJEO]

Junho 2014

possveis tcnicas de apoio de aplicao. Diante disto, foi identificado que, para um maior
benefcio e eficcia, o processo deve ser implantado atravs de um conjunto de cinco fases:
investigao, anlise, deciso, comunicao e execuo (ROONEY & HEWEL, 2004; JUCAN,
2005).
Com isso, esta pesquisa foi idealizada com o objetivo de realizar um estudo de caso,
aplicando a anlise de causa raiz em um projeto que apresenta um nmero elevado de
defeitos com criticidade alta, comprometendo assim a qualidade do produto a ser entregue
para o cliente. Este estudo prope verificar a eficcia do mtodo proposto para identificao
da causa original, suporte para criao de aes corretivas que visam o crescimento do nvel
de qualidade dos produtos desenvolvidos. Para tal, apresenta-se uma reviso bibliogrfica,
pela qual foi realizado um estudo do processo de anlise de causa raiz, as principais tcnicas
para sua aplicao e trabalhos relacionados. Em seguida, discorrido o processo de anlise
dos defeitos coletadas na ferramenta de BugTrack de um Software Financeiro e
apresentado tambm um plano de ao. Finalmente, avalia-se o plano proposto.
Anlise de Causa Raiz (RCA)
A Anlise de Causa Raiz, tambm conhecida como RCA (Root Cause Analysis), um mtodo
que permite a identificao e correo dos principais fatores que ocasionaram o problema.
Este mtodo visa descobrir os defeitos originais (causa raiz), as quais geraram o problema,
ao invs de buscar solues imediatas para a resoluo de um defeito (JUCAN, 2005 ;
ANDERSEN & FAGERHAUG, 2006).
Segundo Rooney & Hewel (2004), RCA uma ferramenta projetada para auxiliar a identificar
no apenas o que e como um evento ocorreu, mas tambm por que ele ocorreu.
Somente quando identificado o motivo original de um defeito ter ocorrido, ser vivel
gerar aes para que este no volte a ocorrer. A utilizao da ferramenta RCA segundo
Rooney & Hewel (2004), no evita que sempre que ocorrer algum defeito em produo a
equipe tenha que buscar solues imediatas, avaliando somente os sintomas. No entanto,
sugere que o defeito seja tratado, mas no seja fechado at que este seja analisado e
identificado causa original que o fez ocorrer.
A Anlise de Causa Raiz usa uma terminologia especfica (ANDERSEN & FAGERHAUG, 2006),
apresentando os seguintes termos para:
Ocorrncia: um evento ou condio que no esteja dentro funcionalidade do sistema
normal ou comportamento esperado.
Evento: Uma ocorrncia em tempo real. Fato que pode impactar seriamente no
funcionamento do sistema.
Estado: Qualquer estado do sistema, que pode apresentar implicaes negativas para
alguma funcionalidade do sistema normal.
Por que (tambm chamado de Fator causal): Uma condio ou um evento que
resulte ou participa na ocorrncia de um efeito. Elas podem ser classificadas como:
o Causa direta: Uma causa que resultou na ocorrncia.
o Causa contribuinte: A causa que contribuiu para a ocorrncia, mas no a fez
diretamente.
Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

15

Junho 2014

[TECNOLOGIAS EM PROJEO]

o Causa raiz: A causa que, se corrigida, impedir o retorno desta e de

ocorrncias similares.
Cadeia de fatores causais (sequncia de eventos e fatores causais): Uma sequncia
de causa e efeito em que uma ao especfica cria uma condio que contribui ou
resulta em um evento. Isso cria novas condies que, por sua vez, resultam em
outros eventos.
Tcnicas
Para a aplicao do RCA no estudo de caso, foi utilizada a combinao de tcnicas,
permitindo uma maior exatido na identificao da causa raiz, conforme abaixo descritas:
Diagrama de Causa e Efeito, tambm conhecido como diagrama de Ishikawa (espinha
de peixe): permite identificar, explorar e apresentar graficamente todas as possveis
causas relacionadas a um nico problema. Esta tcnica utilizada em equipe e
permite classificar os defeitos em seis tipos diferentes de categorias: mtodo,
matria-prima, mo-de-obra, mquinas, medio e meio ambiente. Sendo, que nem
o nmero e nem os tipos de categorias so pr-estabelecidas, permitindo a equipe
adequar estes conforme sua necessidade. E, atravs desta tcnica, se torna possvel
identificao das causas potenciais de determinada defeito ou oportunidade de
melhoria, bem como seus efeitos sobre a qualidade dos produtos. Alm disto, ela
permite tambm estruturar qualquer sistema que necessite de resposta de forma
grfica e sinttica (isto , com melhor visualizao) (JUCAN, 2005).
Cinco Porqus: baseada na realizao de cinco iteraes de perguntas s quais,
colocado em questo o porqu daquele problema, sempre questionando a causa
anterior. O nmero de cinco perguntas varivel, pois na prtica pode ser
identificada a causa raiz do problema atravs de mais de cinco perguntas ou menos
de cinco perguntas (SERRAT, 2009).
Reunio de Anlise Causal: as causas dos problemas so levantadas em reunies do
tipo Brainstorming. As causas mais provveis so discutidas entre a equipe, e
posteriormente a descoberta das provveis causas, os participantes propem aes
corretivas para estes problemas no futuro (JUCAN, 2005).
Trabalhos relacionados
A anlise de causa raiz utilizada em diversas reas, no sendo um mtodo exclusivo da
rea de tecnologia da informao, esta pode ser aplicada na rea mdica (TEXEIRA, 2007), na
de sistemas eltricos (PIRES, 2010), na industrial (ROONEY & HEWEL, 2004), entre outras,
com o propsito de interpretar o conjunto de eventos observados e apontar a origem que
est causando estes eventos, i.e., onde tudo comeou.
Em Anlise de Causa Raiz em Processos de Negcio (HERAVIZADEH, MENDLING,
TOSEMANN, 2008), foi aplicada a tcnica de anlise de causa raiz baseadas em modelos de
processos de negcio. Este trabalho apresenta a utilizao da anlise de causa raiz como
uma metodologia sistemtica para detectar e documentar a dimenso qualitativa de um
processo de negcio. Neste, foi criado uma base para a anlise de causa raiz em modelagem
de processos de negcio e uma integrao conceitual entre abordagens baseadas em metas
Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

16

[TECNOLOGIAS EM PROJEO]

Junho 2014

e abordagens baseadas em atividades para entender processos. Alm disto, algumas normas
e modelos de maturidade (por exemplo, ISO/IEC 12207, CMMI-DEV e MR-MPS) tambm
recomendam a execuo da anlise de causas, confirmando a importncia deste processo
em uma organizao de alta maturidade, ou seja, que possui seus processos bem definidos e
busca a melhoria contnua.
A norma ISO/IEC 12207 (ISO/IEC, 2008) apresenta indiretamente o termo "anlise de
causas", dentro do processo "Resoluo de Problemas de Software". Este processo tem o
propsito de garantir que todos os problemas sejam identificados, analisados, gerenciados e
controlados at sua resoluo. Na ISO/IEC 15504-5 (ISO/IEC, 2003), a execuo da anlise de
causas apresentada como uma prtica base do resultado Problemas so analisados e
avaliados para identificar solues aceitveis do processo Gerncia de Resoluo de
Problemas. Assim como na norma ISO/IEC 15504, o CMMI-DEV (SEI, 2006), no nvel 4 e
5, e o MRMPS (SOFTEX, 2009), no nvel "A" e "B", tambm recomendam a utilizao do
mtodo de anlise de causa raiz.
Metodologia e aplicao do RCA
Como metodologia para este estudo, foi realizada uma pesquisa aplicada de forma
qualitativa atravs de um estudo de caso para um software financeiro de uma empresa
situada na cidade de Porto Alegre, estado do Rio Grande do Sul, cujo ramo alimentcio e
varejista.
O software financeiro, em questo possui funcionalidades destinadas para o gerenciamento
e controle financeiro das vendas realizadas pela empresa (entrada e sada de operadoras,
controle de caixa, entre outras). Por questes de normas internas de confidencialidade da
empresa em estudo, tanto sua identidade quanto quaisquer informaes tcnicas
estratgicas de seus produtos esto sendo preservados. Foi identificado que para um maior
benefcio e eficcia, o processo foi implantado atravs de um conjunto de cinco fases:
investigao, anlise, deciso, comunicao e execuo (ROONEY & HEWEL, 2004; JUCAN,
2005).
Investigao
Esta fase tem o objetivo de identificar de forma neutra os fatos que apresentam como o
defeito aconteceu. Para isto, devem ser coletados os principais dados referentes
ocorrncia do defeito (Ex.: como o defeito ocorreu, quais as aes realizadas para sua
correo imediata, passos para sua identificao).
A aplicao foi dividida em duas etapas: levantamento total dos defeitos e a seleo
somente de uma amostragem para aplicao nesta proposta. Esta diviso foi necessria,
devido ao software apresentar um elevado nmero de defeitos e tambm pelo tempo
limitado na entrega desta proposta.
Na primeira etapa, foi realizado o levantamento referente ao nmero de ocorrncias do
projeto em questo, atravs da ferramenta de BugTrack utilizado no software financeiro,
apresentando os seguintes nmeros identificados atravs da criticidade (alta, mdia, baixa):
Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

17

[TECNOLOGIAS EM PROJEO]

Junho 2014

Baixa
15

Software Financeiro
Alta
30

Mdia
68

Figura 1 - Etapa 1: Levantamento de defeitos do Software Financeiro

Pelo nmero de defeitos apresentadas no desenvolvimento do software financeiro e

objetivando uma melhor efetividade do trabalho, foi aplicada a segunda etapa da
investigao. Onde foram selecionados somente os defeitos que apresentaram criticidade
alta, agrupando os mesmos por similaridade (aqui ser utilizada a similaridade para os
defeitos com as mesmas caractersticas). Segue, na Tabela 1, um exemplo do detalhamento
de defeitos agrupados por similaridade.
Tabela 1 Etapa 2: Exemplo da Aplicao do Detalhamento dos defeito
Defeitos
Erro ao
validar os
campos
"Banco" e
"Agncia"

Erro ao incluir
agncia no
cadastrada no
sistema

Descrio (como
ocorreu)

Passos para Reproduo

Aes realizadas

Aps um consulta por 1) Logar usurio em local conectado a

um cheque, foi alterado
empresa padro do Software
o cdigo do banco.
Financeiro.
Posteriormente, foi
2) No menu "Movimento", clicar na
inserido no campo
opo "Controle de Cheques".
"agncia", o nmero de
3) Informar nos campos Banco,
uma agncia que exista
Agncia, Conta CMC7, N do
no software cadastrado
cheque e Local recebimento
para outro banco.
valores correspondentes a um cheque
Sistema apresenta a
cadastrado no sistema e disparar a
mensagem de erro:
ao de [Consultar].
"javax.persistence.NonU 4) Informar um cdigo de banco no
niqueResultException:
cadastrado no sistema no campo
br.com.zaffari.tsr.server.
"Banco"
entity.AgenciaBancaria"
5) No campo "Agncia", informar o
cdigo 25 e voltar o foco para o
campo "Banco".

1) Desenvolvedor simulou o
erro
2) Desenvolvedor
identificou o erro na
implementao referencia a
regra de dependncia entre
os campos banco e agncia

Ao acessar a tela de
Controle de Cheques e
informar uma agncia
no
cadastrada
no
sistema, o mesmo no
esta apresentando a
informao de agncia
no cadastrada

1) Desenvolvedor simulou o
erro
2)
Desenvolvedor
identificou que o erro
ocorria devia ter erro na
validao
do
campo
agncia.

1) Logar com usurio em local

conectado a empresa padro do
Software Financeiro
2) No menu "Movimento", clicar na
opo "Controle de Cheques"
3) Informar uma agncia no
cadastrada no sistema

Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

18

Junho 2014

[TECNOLOGIAS EM PROJEO]

Na Tabela 1, observa-se o agrupamento e a similaridade entre os defeitos. A similaridade na

validao do campo agncia foi identificada em mais de um processo de validao do
software financeiro.
Anlise
Esta fase tem o objetivo de apresentar as razes que demonstram por que ocorreu o
defeito. Para a aplicao desta fase, foi utilizada a combinao das tcnicas Diagrama de
Causa e Efeito, Cinco porqus e reunies de "Brainstorming". Para a realizao desta fase
foram agendadas quatro reunies de "Brainstorming" com integrantes da equipe que
participou do processo de desenvolvimento do Software Financeiro (desenvolvedor, analista
de testes e o gestor).
Na primeira reunio, foi apresentada ao grupo a proposta deste estudo, assim como a tabela
de defeitos gerados na fase de investigao. Posteriormente, foi desenhada, utilizando o
recurso de um quadro, a "espinha de peixe", referente ao diagrama de Ishikawa (JUCAN,
2005). Com o auxlio dos integrantes, foram denominadas as categorias principais
(comunicao, infraestrutura, processo, ambiente/organizao, recursos humanos e gesto),
ver Figura 2.
Aps a denominao das categorias, se iniciou o processo de anlise do primeiro defeito
("efeito"), incluindo o mesmo no diagrama de Ishikawa. Com o auxilio dos integrantes, foi
realizado o processo de anlise dos motivos que ocasionaram o defeito, onde cada
integrante informou as causas potenciais que auxiliaram para ocorrncia deste defeito. Ao
final da identificao das causas, com o auxilio da ferramenta "Cinco porqus (SERRAT,
2009), foi realizado o questionamento do "por que" aquela causa ocorreu e documentado na
espinha de peixe (ver Figura 2), como uma sub-causa. Este processo somente foi finalizado,
quando se obtinha resposta para todos os porqus, e quando todas as causas atingiam
uma causa raiz.

Figura 2 - Exemplo do Diagrama de Ishikawa

Esta tcnica foi aplicada nas demais reunies de "Brainstorming", realizando assim a anlise
de todos os defeitos com criticidade alta.
Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

19

[TECNOLOGIAS EM PROJEO]

Junho 2014

Deciso
Esta fase tem o objetivo de identificar as aes e as lies aprendidas para corrigir ou
eliminar as causas de um defeito, a fim de alcanar em longo prazo, resultados efetivos.
Nesta fase, foi criada uma planilha agrupando por similaridade todas as causas razes
identificadas na fase de Anlise. Alm disto, foi realizada uma reunio de "Brainstorming"
com os integrantes (mesmos utilizados na fase anterior), onde foi apresentada a relao de
causas razes identificadas. Para complementar este estudo, foram solicitadas sugestes de
melhorias associadas a cada item, atravs da aplicao da tcnica de "Reunio de Anlise
Causal" (JUCAN, 2005).
Tabela 2 Exemplo: Aplicao da Tcnica de Reunio de Anlise Causal
Problema: Erro ao validar os campos Banco e Agncia
Causas

Aes de Melhorias Sugeridas

Ferramentas de comunicao so
textuais

Realizar reunies semanais e presencias para retirada de dvidas

1
das EFRs e caso seja identificado a necessidade de alterao da
2
EFRs, representante da fbrica cria uma SEF .

Equipe de testes da fbrica no solicitou No inicio dos projetos, realizar um levantamento dos programas
padronizao de ambiente (Softwares, instalados nas mquinas de homologao e criar ambiente parecido
browsers...)
ao utilizado (sistema operacional, browsers...).
EFR muito complexa
3
4
5
FAs , FEs e RNs com alto nvel de
criticidade
Pouco entendimento da EFR
Falta do conhecimento do produto

Envolver o analista de testes em todas as reunies (retiradas de

dvidas, reunio de apresentao das funcionalidades da EFR...)
6
Incluir no processo a atividade de reviso de CTs por outro
integrante do projeto.
Realizar reunies semanais e presencias para retirada de dvidas
das EFRs e caso seja identificado necessidade de alterao da
EFRs, representante criava uma SEF.

Falta de carga real para os testes.

Para uma validao/verificao das funcionalidades se faz

necessrio dados reais. Diante disto, inserir no processo, a
solicitao de dados reais para a base de testes.

Ineficincia no planejamento

Incluir no plano de projeto/vendas, pr-requisitos com data de

prazos, normas...
Caso no seja atendido o prazo, apresentar os impactos que os
mesmos podem causar e tentar encontrar junto ao gerente aes a
serem tomadas.

Acreditava que ao entregar no prazo iria

ganhar prestigio com cliente j que a
Apresentar relatrios peridicos sobre o status de testes,
outra empresa concorrente iria atrasar mostrando o valor da qualidade de um software na entrega.
a entrega das suas EFRs

EFR Sigla denominada para a nomenclatura Especificao Funcional do Requisito"

SEF Sigla denominada para a nomenclatura Solicitao de Esclarecimento ao Fornecedor
3
FA Sigla denominada para a nomenclatura de Fluxo alternativo (Especificao Funcional)
4
FE Sigla denominada para a nomenclatura de Fluxo de Exceo (Especificao Funcional)
5
RN Sigla denominada para a nomenclatura de Regra de Negcio (Especificao Funcional)
6
CT Sigla denominada para a nomenclatura Caso de Teste
2

Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

20

[TECNOLOGIAS EM PROJEO]

Junho 2014

Comunicao
Esta fase tem o objetivo de comunicar aos integrantes envolvidos no processo de anlise dos
defeitos, os resultados obtidos, assim como as aes corretivas propostas. Nesta fase foi
agendada uma reunio com todos os integrantes da equipe do Software Financeiro. Na
reunio foi apresentado todo o processo RCA executado e o plano de ao criado, utilizando
as aes de melhorias sugeridas na fase de Deciso. Alm disto, foi discutido com a equipe a
eficcia das aes e sua aplicao.
Tabela 3 Plano de Ao (Aes Corretivas)
Aes

Responsveis

1) No inicio dos projetos, criar documento apresentando o processo a Principal: Gerente

ser utilizado, inclusive o de testes, apresentando responsabilidades,
riscos (com associao de prazos). Deixar claro, os riscos associadas Secundrios: Analista de Testes e
ao no cumprimento das responsabilidades e prazos pr- Desenvolvedor
estabelecidos (esta permitira um maior conforto da equipe da fbrica
para realizar o processo de cobrana de pendncias e tambm
justificar atrasos de entrega ou nvel menor da qualidade do produto
entregue).
2) Um requisito/funcionalidade somente poder ser entregue, Principal: Gerente e Analista de Testes
posteriormente a liberao do responsvel da equipe de testes. Caso
o gerente queira liberar este sem esta liberao, POR EXIGNCIA DO Secundrios: Cliente final, Gerente de
CLIENTE, dever ser realizada uma reunio com o cliente final, testes
apresentando os erros conhecidos, percentual de cobertura de testes,
riscos associados a entrega. Nesta reunio, devero ser apresentados
estes dados ao cliente, questionando se ele aceita o produto com o
quadro apresentado. Caso o cliente aceite, dever ser documentado
este aceite e sero de responsabilidade do dele os riscos associados
ao quadro apresentado. Esta documentao pode ser realizada
atravs de um e-mail ou documento formal e deve ser encaminhada
ao gerente do projeto, gerente de testes e cliente final.
3) Um requisito/funcionalidade somente poder ser entregue, Principal: Gerente e Analista de Testes
posteriormente a liberao do responsvel da equipe de testes. Caso
o gerente queira liberar este sem esta liberao, SEM EXIGNCIA DO Secundrios: Gerente de testes
CLIENTE, dever ser documentado que a equipe de testes no
aconselha a liberao ao cliente, apresentando os motivos, erros
conhecidos, percentual de cobertura de testes, riscos associados
entrega. Esta documentao pode ser realizada atravs de um e-mail
ou documento formal e deve ser encaminhada ao gerente do projeto,
gerente de testes e representante superior responsvel pelo cliente
em questo na empresa.
4) Sempre realizar a solicitao de atividades ou aviso de itens Principal: Integrante da equipe que
pendentes com um prazo de no mnimo uma semana de esta realizando a solicitao
antecedncia.
5) Sempre que for identificado que no ser possvel cumprir com os Principal: Gerente
prazos estabelecidos por deficincias de recursos, conhecimento...,
deve ser alinhado aes alternativas, visando minimizar os impactos
no projeto.
6) No inicio do projeto, realizar as seguintes aes:
Principal: Desenvolvedor e Analista de
- Encaminhar as EFRs para um integrante da equipe de Testes

Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

21

[TECNOLOGIAS EM PROJEO]

Junho 2014

desenvolvimento e um integrante da equipe de testes (recursos j

planejados para projeto em questo)
Secundrio: Analista de Sistemas
- Integrantes devem realizar o processo de leitura, entendimento e
validao da EFR, listando dvidas encontradas (aplicar checklist
padro de validao de EFRs para auxiliar no trabalho)
- Realizar reunio de no mximo 1 hora entre os 2 integrantes para
discutir duvidas, regras, FE's, FA's...
- Marcar reunio com o analista de sistemas para solucionar as
duvidas identificadas (2 integrantes participam da reunio)
7) Criar checklist padro de validao de EFRs e CTs

Principal: Analista de testes e

Desenvolvedor

8) Realizar reunio semanal para retirada de dvidas referente EFRs. Principal: Analista de Testes,
Tempo = N EFRs que possuem duvidas * tempo mdio estipulado Desenvolvedor e Analista de Sistemas
(Sugerido = 0,25 / 15 min)
Reunio deve ocorrer no primeiro dia til da semana.
Secundrio: Gerente
Caso no haja dvidas referentes semana que passou, no ocorre
reunio.
Modificaes identificadas devido s dvidas geraram abertura de
SEF.
9) Todas as reunies referente a EFR, sempre dever ir um integrante Principal: Desenvolvedor e Analista de
da equipe de desenvolvimento e um integrante da equipe de testes
Testes
10) Planejar a alocao dos recursos do projeto sempre prevendo um Principal: Gerente
lder tcnico snior (tecnologia e conhecimento do produto) e um
analista de testes snior (conhecimento de testes e produto). Em Secundrios: Analista de testes e
ambas as reas, a pr-condio de nvel snior em conhecimento do Desenvolvedor
produto e do mtodo no precisa estar em uma nica pessoa.
11) No inicio do projeto, validar a possibilidade de ser realizado uma Principal: Gerente
atualizao da base de dados dos ambientes de desenvolvimento e
testes com dados reais (produo) permitindo um nvel maior de
preciso na validao das regras e fluxos
12) Caso ao do item 11 no seja possvel:
Principal: Gerente
- No inicio do projeto, validar com o cliente se carga de dados ser
realiza por ele.
Caso afirmativo, incluir datas de prazo para a entrega das
necessidades referente a dados e, data de prazo para a carga estar
criada.
13) Caso a ao do item 11 no seja possvel, ao do item 12 no Principal: Gerente e Desenvolvedor
possa ser realizada e na ao do item 5, o cliente realize a compra dos
servios de gerao de carga:
Criar carga consistente, levando em considerao todo o processo do
produto (ex.: outras EFRs que utilizam os mesmos dados,
preenchimento de todos os campos, nomenclaturas adequadas...)
simulando dados reais.
14) Na construo dos cenrios de testes, sempre que identificado a Principal: Analista de Testes
necessidade de validao dos dados via banco, construir e incluir as
queries para validao
15) Diariamente, enviar relatrio com andamento dos testes para a Principal: Analista de Testes
equipe do projeto e superiores
No relatrio devero ser apresentadas informaes referentes EFRs
do escopo de testes (N Total de CTs planejados X N Total de CTs

Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

22

Junho 2014

[TECNOLOGIAS EM PROJEO]

testados, N de CTs que passaram, falharam, esto bloqueados,

relao de erros/melhorias encontradas, consideraes...)
16) Antes do inicio da fase de testes, realizar o processo de reviso Principal: Revisor (Analista de testes,
dos CTs das EFRs com criticidade > = Alta.
lder tcnico, analista de sistemas...)
O processo de reviso dos CTs deve ser realizado por outro integrante
da equipe de projeto e que possua perfil de analise.
17) No inicio do projeto, encaminhar solicitao a equipe de Principal: Analista de testes
infraestrutura para gerao de ambiente de testes.
O ambiente de testes dever possuir as mesmas configuraes de Secundrio: Gerente
software do ambiente de homologao (Ex.: Sistema operacional,
browsers (verso e tipos)...)
18) Evitar realizar rotatividade de recursos ou possuir recursos com Principal: Gerente
alocao Part-Time
19) Gerente/ gestor dever realizar um trabalho de acompanhamento Principal: Gerente
da equipe, tentando identificar sintomas referente a desmotivao,
desateno, ...
Secundrio: Recurso Humano
Sempre que for identificado estes sintomas, conversar com o recurso.
Caso identificar que sintoma no mudou ou que voltou a ocorrer,
encaminhar para o Recurso Humano realizar um trabalho
motivacional com o recurso.
20) O cdigo somente dever ser liberado posteriormente a aplicao Principal: Desenvolvedor
do checklist de desenvolvimento e atingir o percentual prestabelecido de teste unitrio sobre linha de cdigo
21) Criar base histrica com tempos de estimativas.
Principal: Desenvolvedor e Analista de
Realizar a manuteno desta base no trmino de cada projeto, Testes
permitindo aumento de assertividade no tempo das estimativas de
desenvolvimento, testes...

Execuo
Esta fase tem o objetivo de implementar as aes identificadas durante a fase de deciso,
acompanhar as atividades e identificar a eficcia das aes corretivas. Para esta fase estava
previsto a aplicao das aes corretivas apresentadas na fase de comunicao em uma
nova etapa do Software Financeiro. No entanto, decorrente de modificaes internas na
estrutura (implantao de um novo repositrios de dados), todos os desenvolvimentos de
novas funcionalidades do software foram colocados em "StandyBy". Diante disto, foi
realizado um replanejamento do mtodo de avaliao, onde foi gerado um documento com
questes a serem aplicadas a um grupo especfico, a fim de avaliar a viabilidade e eficcia
das aes planejadas e do mtodo de anlise de causa raiz.
O andamento desta fase ocorreu atravs das seguintes etapas:
Escolha dos integrantes do grupo de avaliao das aes corretivas: Para a escolha
dos avaliadores foi analisado quais os integrantes possuam maior senso crtico,
familiaridade com o processo de desenvolvimento do software e um nvel maior de impactos
com as aes planejadas. Diante disto, foram escolhidos os integrantes que realizavam aes
Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

23

[TECNOLOGIAS EM PROJEO]

Junho 2014

gerenciais ou de liderana, tais como: um Analista de Sistema, um Analista de Testes, um

Gerente de Testes, um Gerente do Projeto e um Lder Tcnico.
Execuo do processo: Durante a reunio de comunicao (fase anterior) foi
explicada necessidade da avaliao das aes propostas, assim como do processo utilizado,
e informado que seriam enviados via e-mail a alguns integrantes da equipe um questionrio
para avaliao das aes apresentadas. Cada avaliador respondeu a perguntas fechadas,
essas perguntas so de autoria prpria com base em SAMARA(2007).
Avaliao do questionrio: as respostas das perguntas foram agrupadas e analisadas,
avaliando o retorno do estudo. Os resultados referentes a esta anlise sero apresentados a
seguir.
Avaliao do Mtodo RCA e a Ao Corretiva
Visando avaliar o mtodo RCA para o estudo em questo e tambm as aes corretivas
propostas, foram aplicados dois questionrios especficos a grupos com diferentes
integrantes. Os questionrios sero descritos a seguir.
O primeiro questionrio, que se referia a questes relativas ao nvel de satisfao do mtodo
RCA aplicado, foi encaminhado para os integrantes da equipe que participou do processo.
Atravs deste, os integrantes escolheram as alternativas que melhor demonstravam o seu
nvel de satisfao ("Muito Satisfeito", "Satisfeito" ou "Insatisfeito"):
Voc considera que o tempo utilizado na execuo do processo de anlise da causa
raiz foi satisfatrio?
Em sua opinio, a utilizao do processo de anlise de causa raiz auxiliou na
identificao dos motivos originais dos erros?
Em sua opinio, as tcnicas utilizadas (diagrama de Ishikawa, Cinco Porqus e
reunio Brainstorming) facilitaram na visualizao e identificao das causas das
ocorrncias dos problemas?
De acordo com sua opinio, os resultados (aes corretivas) obtidos pela anlise de
causas foram satisfatrios?
Voc recomendaria a utilizao deste mtodo a outras equipes da empresa? (Sendo,
"Muito Satisfeito = Sim" / "Satisfeito = Talvez" / "Insatisfeito = No").
A pesquisa apresentou o seguinte resultado:

Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

24

Junho 2014

[TECNOLOGIAS EM PROJEO]

Figura 3 - Resultado da Pesquisa de Satisfao do Mtodo RCA

O segundo questionrio, que possua questes referentes ao nvel de eficcia das aes
corretivas propostas, foi encaminhado equipe de avaliao (definhada na fase de execuo
do processo RCA). Atravs deste questionrio, os avaliadores determinaram o nvel de
confiabilidade referente efetividade das aes corretivas propostas para a melhoria do
processo de desenvolvimento do Software Financeiro. O questionrio apresentava as
seguintes perguntas:
As aes proposta so eficientes para minimizar ou sanar a recorrncia de defeitos?
As aes propostas tero uma boa aceitao no nvel de equipe?
As aes propostas aumentaram o nvel de qualidade do produto entregue?
As aes propostas auxiliaram a equipe, permitindo um melhor andamento das
atividades de desenvolvimento, testes e gerncia?
As aes propostas so fceis de serem aplicadas?
Teria alguma ao que no foi identificada, mas que voc sugeriria, visando melhoria
do processo de desenvolvimento de sistemas?
Dessa forma:

Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

25

Junho 2014

[TECNOLOGIAS EM PROJEO]

Figura 4 - Resultado da Pesquisa de Eficcia das Aes Corretivas

Quanto pergunta Teria alguma ao que no foi identificada, mas que voc sugeria,
visando melhoria do processo de desenvolvimento de sistemas?, apresentou as seguintes
aes:
Incluir uma ferramenta para incluso de lies aprendidas, para que os integrantes
da equipe a preencham durante o processo de execuo.
Realizar o processo de reviso da documentao de testes, utilizando como revisor
um integrante da equipe.
Incluir na ferramenta de BugTrack um campo referente a causa raiz. Este campo ser
utilizado para a incluso da razo original da ocorrncia no trmino do processo RCA.
Conforme sugesto, esta informao permitir uma maior facilidade na gerao de
relatrios e uma base histrica para consultas futuras.
Consideraes Finais
Como principal contribuio desta pesquisa, a realizao do estudo utilizando um mtodo
direcionado para a identificao dos motivos causadores pela ocorrncia dos defeitos, um
das principais preocupaes quando se referencia a qualidade do produto. Alm disto, este
estudo permitiu uma maior conscientizao para a equipe participante quanto qualidade
do produto desenvolvido. Isto ocorreu, pois ao realizar a anlise dos defeitos, os integrantes
acabavam sutilmente realizando uma autoavaliao do seu desempenho, permitindo assim
aprendizado e motivao para melhorar suas aes. No entanto, para obter sucesso na
realizao deste imprescindvel que o mesmo seja realizado com a equipe envolvida no
software em desenvolvimento. Isto ocorre, pois cada indivduo possui conhecimentos e
crticas prprias referentes ao processo de resoluo de problemas. Esta diferenciao entre
os indivduos permite que surjam solues e pontos crticos antes no identificados. Alm
disto, importante que a equipe de anlise da causa raiz possua sempre integrantes com
funes diferenciadas (analista de sistemas, analista de testes, desenvolvedores, lder
Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

26

Junho 2014

[TECNOLOGIAS EM PROJEO]

tcnico... ), evitando que as aes sugeridas somente solucionem ou que os problemas

acabem sendo direcionados somente para uma determinada rea.
Saliente-se que a eficcia de resoluo de defeitos atravs das tcnicas de anlise de causa
raiz representa, para a maioria das organizaes, uma mudana significativa na sua cultura.
E, que provavelmente, iro surgir muitos integrantes da equipe que iro inserir barreiras
para no executar estas aes corretivas identificadas. E, evidente que os ganhos
referentes execuo deste mtodo, dependem diretamente do empenho e
comprometimento da equipe para encontrar as causas originais dos problemas, e tambm
da disciplina desta para cumprir as aes corretivas identificadas.
Em relao a perspectivas futuras, entende-se que as aes corretivas identificadas devem
ser aplicadas em uma nova fase de desenvolvimento do Software Financeiro, permitindo
uma avaliao mais efetiva. Outro ponto a se destacar a utilizao de uma ferramenta para
incluso das aes corretivas em um local que esteja disponvel para acesso comum (Ex.:
WIKI, Sharepoint, etc.).
interessante como trabalhos futuros utilizar outros mtodos de anlise dos defeitos e
aplicando em diferentes projetos de desenvolvimento de software, avaliando a efetividade
dos mesmos em relao anlise de causa raiz, assim como para identificao de aes que
permitam solues diferenciadas.
Referncias
ANDERSEN, B., FAGERHAUG, T. (2006), Root Cause Analysis: Simplified Tools and Techniques.
ASQ Quality Press
ECKERT, Chris(2005), Apollo Anlise de Causa de Raiz (RCA). SP
HERAVIZADEH, Mitra; MENDLING, Jan; ROSEMANN, Michael (2008), Anlise de Causa Raiz
em Processos de Negcio. SP
IEEE(1991), IEEE standard glossary of software engineering terminology, IEEE Std 610.121990, New York
ISO/IEC (2003), ISO/IEC 15504: Information Technology Software Process Assessment,
Parts 1-5, The International Organization for the Standardization and the International
Electrotechnical Commission.
ISO/IEC (2008), ISO/IEC 12207: System and Software Engineering Software Life Cycle
Processes, The International Organization for the Standardization and the International
Electrotechnical Commission.
JUCAN, George (2005), Root Cause Analysis for IT Incidents Investigation.Toronto, Ontario.
PIRES, Stfani Pires (2010), Descoberta de Causa-raiz em ocorrncias de Sistemas Eltricos.
Campinas Grande, Paraba
Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

27

Junho 2014

[TECNOLOGIAS EM PROJEO]

PMBOK (2008), 4 Edio, PMI Book Service Center, Pensylvania

PRODANOV, C. (2004), Manual de metodologia cientfica. FEEVALE
ROONEY, J.J. & HEWEL, L.N.V.(2004), Root cause analysis for beginners. Quality Progress.
SAMARA, Beatriz dos Santos. BARROS, Jos Carlos (2007), Pesquisa de Marketing: Conceitos
e Metodologia. So Paulo: Prentice Hall
SEI (2006), CMMI for Development (CMMI-DEV), V1.2, CMU/SEI-2006-TR-008, Software
Engineering Institute. Disponvel em: http://www.sei.cmu.edu/. Acesso em: Julho/2011.
SERRAT, Oliver (2009) The five whys technique. Knowledge Solutions
SOMMERVILLE, Ian (2003) Engenharia de Software. 6. ed. So Paulo: Addison Wesley
SOFTEX (2009a), MPS.BR Melhoria de Processo do Software Brasileiro Guia Geral.
Disponvel em: http:www.softex.br/mpsbr. Acesso em: julho/2011.
TEXEIRA, Thalyta Cardoso Alux (2007), Anlise de causa raiz dos erros de medicao em uma
unidade de internao de um hospital universitrio. Ribeiro Preto. SP

Peridico Cientfico Tecnologias em Projeo | vol. 5 | n 1

28