1. GESTÃO DE DEMANDAS DE TESTE E ANÁLISE DE
PADRÕES COM TEXT MINING1
Marcos Lottermann <marcoslott@gmail.com>
Stanley Loh <stanley.loh@ulbra.edu.br> – Orientador
Universidade Luterana do Brasil (Ulbra) – Curso de Ciência da Computação – Campus Canoas
Av. Farroupilha, 8.001 – Bairro São José – CEP 92425-900 – Canoas - RS
21 de junho de 2012
RESUMO
O objetivo deste trabalho é propor uma ferramenta web que permita realizar a gestão de todas as demandas
existentes em cada etapa do teste de software, oferecendo ao gestor uma visão geral do andamento dos projetos e da
produtividade das equipes através de gráficos. Ao longo de cada projeto gerenciado pela ferramenta teremos uma
base de dados com os defeitos reportados pelas equipes de teste, então será aplicada uma técnica de text mining para
que seja possível identificar padrões nestes defeitos, possibilitando que este conhecimento descoberto possa ser
utilizado como aprendizado para futuros projetos.
Palavras-chave: Mineração de textos; Teste de software; Gestão do conhecimento.
ABSTRACT
Title: “MANAGEMENT DEMANDS OF TESTING AND ANALYSIS OF PATTERNS WITH TEXT MINING”
The objective of this study is proposing a web tool that allows performing the management of all demands in
each software testing stage, offering to the manager an overview of the projects status and the productivity of the
teams through graphs. Throughout each managed project using the tool we will have a database of defects reported
by the test teams, and then we will apply a text mining technique to be able to identify patterns in these defects
enabling its discovered knowledge to be used as learning into future projects.
Key-words: Text mining; Software testing; Knowledge management.
1 INTRODUÇÃO
Analisando o cenário global onde o mercado se apresenta cada vez mais acirrado e competitivo, as
organizações devem traçar estratégias para que possam se destacar e obter vantagens sobre os seus
concorrentes. E um diferencial que tem ganhado destaque entre as empresas que atuam na área de
desenvolvimento de software é o investimento no processo de teste de software. Segundo Pressman (2005),
para muitas empresas a etapa de testes chega a representar 50% dos custos e do tempo estimado para o
projeto.
De acordo com Bartié (2002), quanto mais procedimentos fizerem parte do processo de teste de
software, melhor será o nível de avaliação do produto, e por consequência resultará em um produto final com
maior qualidade.
A Empresa X, na qual este trabalho propõe a implantação do GDT, tem um processo maduro de
testes, com as seguintes etapas: escrita dos casos de teste, execução dos casos de teste, checklist e evidências
de teste. O conceito de cada uma destas etapas será apresentado na seção 2.1 deste trabalho. Apesar do
processo bem definido, a empresa utiliza-se de planilhas eletrônicas para o controle das etapas, o que
impossibilita a utilização simultânea desta planilha, gera quantidades desnecessárias de arquivos e não
garante a integridade desses arquivos, dificultando o papel do gestor, que não tem uma visão geral do
andamento das atividades e prazos. Segundo Nogueira (2010), este é o cenário ideal para a implantação da
ferramenta, visto que o processo de testes da empresa é bem definido, maduro, e a implantação da ferramenta
não trará grandes riscos e mudanças a esse processo.
Durante o andamento da etapa de execução do caso de teste, o testador deve reportar bugs e desvios
encontrados no software testado, e estes reportes devem ser feitos na própria ferramenta GDT. Ao reportar o
bug, serão informados a descrição e o resultado esperado para este bug, essas informações serão armazenas
1 Artigo final da disciplina de Trabalho de Conclusão II, submetido ao Curso de Ciência da Computação da Universidade Luterana do Brasil,
Campus Canoas.
1

2. em formato textual. Visto que é inviável a análise manual de cada um destes textos, é de se considerar a
utilização de ferramentas que possam auxiliar na busca de conhecimento na base que será gerada. Isso pode
ser feito utilizando a técnica de text mining (mineração de textos).
Segundo Sveiby et al. (2000), este é um dos principais focos de preocupação das grandes
organizações. Mais do que a tecnologia, o conhecimento é a chave para companhias que pretendem agregar
valor aos seus produtos e serviços. Este é um importante diferencial da ferramenta GDT. Aplicando text
mining, os bugs reportados durante o projeto serão analisados, identificando padrões e tendências que devem
ser utilizados como aprendizado nos futuros projetos, com a finalidade de reduzir custos com retrabalho e
garantir uma entrega com qualidade.
O artigo esta estruturado em cinco seções, da seguinte forma: a seção 2 apresenta a fundamentação
teórica, que serviu como embasamento para este trabalho, destacando a técnica de text mining. Nesta seção
também são apresentados trabalhos relacionados à gestão do conhecimento na engenharia de software; a
seção 3 apresenta detalhes da especificação e da implementação da ferramenta, além de traçar um
comparativo com outras ferramentas existentes; a seção 4 demonstra como foi realizada a validação,
experimentos e testes da ferramenta; e por fim a seção 5 apresenta as conclusões obtidas com este estudo e
sugestões para trabalhos futuros.
2 REFERENCIAL TEÓRICO
Nesta seção, serão apresentados alguns conceitos para a melhor compreensão da ferramenta
desenvolvida e da metodologia utilizada. Foram abordados e contextualizados os seguintes tópicos: as
demandas presentes na etapa de testes, que serão absorvidas e controladas através da ferramenta; ferramentas
de gestão para área de testes existentes; momento ideal para implantação de uma ferramenta no processo de
gestão do teste; técnicas e trabalhos relacionados às áreas de gestão do conhecimento; e text mining.
2.1 Teste de software
Segundo Longo (1996), os consumidores sempre tiveram preocupação com a qualidade, tendo o
cuidado de inspecionar os bens e serviços que adquiriam, porém esta preocupação se voltava para o produto
já finalizado, o que não garantia a qualidade destes. A partir da década de 50, uma nova filosofia começou a
ser aplicada, com base em conceitos, métodos e técnicas, e a qualidade passou a ser um problema da
empresa.
Hoje em dia, é evidente a necessidade das organizações investirem em qualidade, criando um
diferencial frente ao mercado, evitando desgastes com o cliente e reduzindo impactos com retrabalhos e
manutenção do produto. Em virtude desta crescente necessidade na oferta de qualidade, muitas empresas de
desenvolvimento têm adotado o processo de testes de software, muitas vezes até por exigência do cliente.
Myers (1979) define teste de software como o “processo de executar um programa ou sistema com a
intenção de encontrar defeitos (teste negativo)”. Nas subseções seguintes será apresentado o conceito de cada
uma das etapas de teste praticadas na Empresa X, a gestão da execução destas etapas será feita através da
ferramenta proposta.
2.1.1 Escrita dos casos de teste
Esta etapa é executada por um analista de testes e tem como objetivo especificar passo a passo o que
os testadores devem fazer para a execução dos testes, com a finalidade de garantir que os testes realizados
cubram a maior parte ou os principais requisitos do caso de uso. Ela obedece a estrutura de pré-condições,
procedimentos, entrada, resultado esperado e pós-condições.
Nesta etapa, a complexidade de cada um dos casos de uso do sistema é definida pelo analista de
sistemas e pelo analista de testes, servindo como referência para o testador e para o gestor na estimativa de
tempo e esforço necessário para a execução dos testes.
2.1.2 Execução dos casos de teste
Após finalizada a etapa de desenvolvimento de um determinado caso de uso, esse caso é liberado
para testes. Os testadores seguem os passos especificados nos casos de teste planejados na etapa anterior,
reportando os bugs e desvios.
2

3. 2.1.3 Checklist
O checklist é uma prática antiga utilizada em diversos segmentos. Por exemplo: em 1935, segundo
Porto (2010), a Boeing determinou a seus pilotos a obrigatoriedade da utilização de checklist. Esta etapa
inicia-se ao término da etapa de execução dos casos de teste. Os testadores devem utilizar um checklist pré-
definido para cada tela do sistema, onde está especificada uma lista de verificações que devem ser feitas. Isso
evita o esquecimento de algum teste e possíveis bugs não identificados na execução dos casos de teste.
Geralmente, o checklist é executado por um testador diferente daquele que executou o caso de teste.
2.1.4 Evidências de teste
Esta etapa inicia-se após o término das etapas de execução dos casos de teste e de execução do
checklist, e é realizada por um testador. Consiste em executar cada cenário especificado no caso de teste,
gerando um documento que comprove o correto funcionamento dos requisitos testados. O produto final
entregue ao cliente, geralmente vai acompanhado por um vídeo, mostrando o desenvolvimento do teste, ou
por um print screen das telas da aplicação.
2.2 Ferramentas de gestão para área de testes
Nesta seção serão apresentadas duas ferramentas que se propõem a auxiliar a gestão do teste. A
primeira é o TestLink, que é uma das principais ferramentas do segmento e tem código aberto. A segunda é o
Rational Quality Manager (RQM), ferramenta desenvolvida pela IBM da qual a Empresa X tem licença de
uso. Ambas as ferramentas têm o mesmo propósito, apesar de possuírem algumas particularidades que serão
detalhadas a seguir.
2.2.1 TestLink
O TestLink é uma ferramenta open source (código aberto) desenvolvida na linguagem PHP. O
projeto é mantido pela comunidade aberta de testadores de todo o mundo, e se propõe a auxiliar o
gerenciamento e execução dos casos de teste. Permite aos usuários especificar os casos de teste, executar,
acompanhar os resultados da execução e, por fim, gerar relatórios.
O fato de ser uma ferramenta com código aberto permite que usuários que tenham interesse e
conhecimento customizem a ferramenta e implementem novos recursos conforme a sua necessidade, a
maioria dos métodos presentes no código-fonte não são comentados, o que pode dificultar um pouco esta
tarefa.
Figura 1 – Interface da tela de especificação dos casos da ferramenta TestLink
2.2.2 Rational Quality Manager (RQM)
O RQM é um software proprietário desenvolvido pela IBM, que tem como principal finalidade a
especificação dos requisitos, o gerenciamento e a execução dos casos de teste. A ferramenta também permite
3

4. a integração com outro sistema, desenvolvido pela própria IBM, para reportar os bugs encontrados durante o
teste, o Rational Team Concert (RTC).
A Empresa X – na qual se pretende implantar o GDT – possui licença de uso desta ferramenta, que já
foi utilizada em um projeto-piloto, porém não foi adotada em projetos posteriores. Nesses casos foi mantida
a gestão por planilhas eletrônicas, a especificação pelo software Rose e o reporte dos bugs pela ferramenta
RTC. Esta decisão foi tomada devido a dificuldades encontradas na adaptação ao sistema. A ferramenta foi
avaliada como complexa e pouco intuitiva: o tempo consumido estava sendo superior ao utilizado no formato
antigo de gestão, afetando diretamente o budget do projeto.
Figura 2 – Interface da tela de especificação dos casos da ferramenta Rational Quality Manager
2.3 Por que e quando implantar uma ferramenta de gestão no teste
Segundo Nogueira (2010), antes de buscar a utilização de ferramentas é recomendável que o
processo de testes da empresa esteja bem definido e maduro. E a implantação da ferramenta só deve ocorrer
se não trouxer grandes riscos e mudanças no processo de teste.
Para Aquino (2010), o emprego errado de uma ferramenta, ao invés de trazer benefícios, pode se
tornar um grande risco para os projetos. Ele também afirma que a melhor ferramenta é aquela que atende ao
processo de testes utilizado na organização, e que nem sempre a ferramenta ideal para uma empresa irá se
adequar às necessidades de outra empresa. Para minimizar os riscos é importante fazer um estudo de
viabilidade das ferramentas antes da aquisição e implantação.
Portanto, não é aconselhável a implantação de uma ferramenta que altere radicalmente um processo
maduro de testes, que já é utilizado pela organização, com a ilusão de que automaticamente se terá um ganho
de produtividade. A ferramenta ideal é aquela que irá facilitar e auxiliar a execução das atividades do teste.
Este é um dos motivos pelos quais muitas empresas ainda utilizam planilhas eletrônicas, que são facilmente
customizadas, conforme a necessidade, e de fácil adaptação e utilização.
2.4 Gestão do conhecimento na engenharia de software
Praticamente todas as atividades executadas nas organizações geram dados e informações que podem
se tornar conhecimentos valiosos na tomada de decisões. E a gestão do conhecimento tem justamente este
propósito, de aproveitar o capital intelectual das organizações, que é o principal recurso de empresas que
trabalham com desenvolvimento de software.
Para Turban, McLean e Wetherbe (2004), a gestão do conhecimento é o processo que tem como
objetivo auxiliar as organizações a descobrir, organizar e distribuir a informação e o conhecimento que
fazem parte da memória da empresa, e que normalmente existem dentro delas de forma não estruturada.
4

5. A área de desenvolvimento de software sofre constantes mudanças e conta com interações de muitas
pessoas que atuam em diferentes atividades e fases do projeto. Rus e Lindvall (2002) afirmam que muitos
conhecimentos são gerados em empresas de desenvolvimento, porém existem problemas para localizá-los e
utilizá-los. O uso apurado destes conhecimentos é a motivação para conduzir a gestão do conhecimento nas
empresas de desenvolvimento.
A implementação da gestão do conhecimento na engenharia de software apresenta muitos desafios.
Segundo Rus e Lindvall (2002), há três importantes questões a serem postas em prática.
 Tecnológica – A tecnologia do software deve suportar a gestão do conhecimento, permitindo a
integração de todas as ferramentas para que o objetivo traçado com o compartilhamento possa ser
atingido.
 Organizacional – Deve-se ter um bom planejamento para a implantação da gestão do
conhecimento. Um erro comum nas organizações é que elas focam somente a tecnologia e
esquecem a metodologia que deve ser aplicada.
 Resistência – Muitos colaboradores resistem em buscar conhecimento, seja por falta de tempo,
seja por não se sentirem confortáveis em expor seu conhecimento, experiências negativas e lições
aprendidas, temendo que essas informações sejam utilizadas contra eles.
Zaidan (2008) chega à mesma conclusão que Rus e Lindvall (2002). Ele afirma que o fato de grande
parte das empresas não ter obtido êxito ao aplicar técnicas de gestão do conhecimento se deve a não terem
traçado um planejamento estratégico bem definido antes da implantação. As empresas devem aguardar um
determinado período de tempo até que os resultados da gestão do conhecimento comecem a aparecer.
Zaindan (2008) afirma que, em empresas de desenvolvimento, são gerados inúmeros artefatos no
formato eletrônico durante as etapas de desenvolvimento, possibilitando a utilização de ferramentas que
auxiliem na retenção e na disseminação de conhecimento, permitindo consequentemente seu reúso em
projetos futuros.
Segundo Rus e Lindvall (2002), no desenvolvimento de um software diferentes ações são propostas,
visando a redução de custos do projeto, a redução do tempo de desenvolvimento e o aumento da qualidade.
Empregando a gestão do conhecimento na engenharia de software, podem-se obter inúmeros benefícios, tais
como o apoio às memórias do projeto e o apoio ao aprendizado, e principalmente aplicar em novos projetos o
conhecimento que foi adquirido em projetos anteriores, evitando erros e retrabalho.
A motivação para o desenvolvimento e implantação do GDT na Empresa X está diretamente ligada
com o que Rus e Lindvall (2002) afirmam. O conhecimento adquirido através dos bugs reportados na
ferramenta será utilizado em reuniões de retrospectiva para servir como aprendizado em futuros projetos. O
objetivo é a redução de custos do projeto e o aumento da qualidade.
Na seção 2.4.1 será apresentado dois trabalhos que estão ligados à gestão do conhecimento na
engenharia de software, um deles inclusive é direcionado a área de testes.
2.4.1 Trabalhos relacionados
Oliveira et al. (2010) desenvolveu um trabalho em que foi proposta uma ferramenta que tem como
principal objetivo auxiliar no planejamento e na execução de estratégias de gestão do conhecimento. Trata-se
da WebAPSEE Knowledge Manager (WKM). Através dessa ferramenta, é possível fazer a modelagem e a
execução dos processos, acompanhar o prazo das atividades e alocar recursos. A ferramenta promove ainda a
reutilização de boas práticas gerenciais em diferentes projetos e permite controlar as atividades de equipes
que estão geograficamente dispersas.
O autor definiu quinze requisitos. Eles se baseiam em: (i) Bibliografia sobre o que é necessário para
a implantação de Gerência do Conhecimento, na qual se destacam Rus e Lindvall (2002), utilizados como
referência neste trabalho; (ii) Atividades descritas na NBR ISO/IEC 12207 e no Guia de Implementação do
nível E do modelo MPS; (iii) Aspectos socioculturais tratados no P-CMM; e (iv) Estudo qualitativo realizado
com cinco empresas de Belém do Pará. Esses quinze requisitos são apresentados no quadro 1.
Quadro 1 – Descrição dos quinze requisitos que a ferramenta WKM atende
Promover ações de conscientização sobre a importância da realização da gerência de
REQ 1
conhecimento na organização, tanto com a alta direção quanto com os funcionários.
REQ 2 Selecionar uma estratégia adequada às características da organização.
5

6. Estabelecer políticas para criação, compartilhamento e utilização de ativos de
REQ 3
conhecimento por toda a organização.
Definir papéis e alocar pessoas responsáveis para trabalhar na execução do processo.
REQ 4
de gerência do conhecimento.
Permitir o planejamento das ações relacionadas à gerência do conhecimento, de
REQ 5
forma que as atividades detalhadas no plano sejam realizadas pela organização.
REQ 6 Definir os tipos de conhecimento estratégicos para a organização.
Permitir a aquisição de diversos tipos de conhecimento de membros da organização,
tanto relacionados a projetos específicos quanto em nível organizacional,
REQ 7
estabelecendo padrões e classificações de tipos de conhecimento a fim de facilitar a
recuperação e a disseminação dos ativos.
Permitir a avaliação de conhecimento antes de armazená-lo e disponibilizá-lo para a
REQ 8 organização, com o objetivo de filtrar conhecimento de valor, garantindo que o
mesmo esteja correto e claro o suficiente para ser reutilizado.
Garantir que o conhecimento está disponível para reutilização por outros membros
REQ 9
da organização.
REQ 10 Permitir a busca de conhecimento pelos membros da organização.
Formar uma rede de especialistas na organização, permitindo a busca de pessoas
REQ 11 (especialistas) na organização, de forma que se tenham estabelecidas as habilidades
de cada membro da organização e uma quantificação de experiência do indivíduo.
Desenvolver soluções para a disseminação do conhecimento aos funcionários da
REQ 12
organização.
Permitir que os usuários avaliem a utilidade do conhecimento, bem como a própria
REQ 13 estratégia adotada na organização, para que seja possível obter resultados em relação
aos benefícios obtidos com a implantação da mesma.
Permitir a manutenção de conhecimento, de forma que o conhecimento defasado
REQ 14
possa ser atualizado ou desabilitado da organização.
Promover formas de compensar os funcionários pela criação de conhecimento de
REQ 15
valor para a organização.
Martins (2006) desenvolveu uma pesquisa pela qual foi construída uma ferramenta, chamada de
SucReuse, que cria um repositório com os casos de uso em formato XMI. O objetivo dessa ferramenta é
auxiliar os engenheiros de software a reutilizar e elaborar modelos de casos de uso. O autor definiu o
processo de reutilização em dois momentos.
Primeiro, o engenheiro de software, através da técnica de analogia, identifica os casos de uso que
tenham o mesmo contexto. Por exemplo, empréstimos financeiros e aplicações financeiras podem ser
classificados como contexto financeiro. Depois de classificar o contexto, o engenheiro deve identificar, nos
cenários do caso de uso, as partes fixas e as partes variáveis. As partes variáveis devem informar um ou mais
conceitos para o termo destacado como variável. Com este processo é criada a base de conhecimento para
cada modelo de caso de uso que é inserido no repositório da ferramenta. A figura 3 exemplifica esta relação
criada, na qual os termos curso, coordenador e turma foram marcados como variáveis e devem ser definidos
termos semelhantes. Por exemplo, curso: palestra, seminário; coordenador: palestrante, seminarista; turma:
plateia, ouvinte.
Figura 3 – Ligação semântica do cenário de caso de uso
O segundo momento ocorre quando o usuário vai realizar uma busca para encontrar um modelo de
caso de uso que atenda a sua necessidade, e assim reutilizá-lo, fazendo pequenas modificações e obtendo um
6

7. ganho de produtividade.
2.5 Text mining
Segundo Chen (2001), 80% do conteúdo online está armazenado em formato textual. Este mesmo
percentual, segundo Tan (1999), corresponde às informações disponíveis em uma organização no formato
textual e não estruturado. Devido a este crescente volume de informações armazenadas no formato textual, se
torna inviável a análise manual de cada um destes textos, portanto é de se considerar, a utilização de
ferramentas que possam auxiliar na busca de conhecimento, isso pode ser feito utilizando a técnica de text
mining (mineração de textos).
Segundo Aranha e Passos (2006), a mineração de textos consiste em extrair padrões e tendências de
grandes quantidades de documentos em formato textual e não estruturado, normalmente para um objetivo
especifico.
A mineração de textos possui duas fases principais e sequentes: a extração de informações e
a própria mineração de dados. A primeira destina-se a extrair conceitos, estatísticas e
palavras relevantes de um conjunto textual para estruturá-los minimamente, preparando-os
para a aplicação das técnicas de mineração de dados. Neste segundo momento aplicam-se
as diretrizes e algoritmos de mineração de dados destinados a gerarem regras, classificações
ou agrupamentos. (HOESCHL et al., 2002)
Uber, José (2004) conduziu um estudo no qual foi aplicada a técnica de text mining para automatizar
e auxiliar na análise de chamados telefônicos. Verificou-se o campo que contém a descrição do chamado e,
com base nisto, o sistema categorizou esse chamado. O autor foi motivado a desenvolver essa ferramenta em
razão do elevado número de chamados classificados de forma errônea pelos atendentes. Outro autor, Uber,
Jacqueline (2004), desenvolveu um estudo, com objetivo semelhante, em que a técnica foi aplicada em
ocorrências policiais, classificando automaticamente a natureza da operação do boletim de ocorrência. Ele
chegou à conclusão de que 5,44% dos registros analisados estavam classificados de forma incorreta.
2.5.1 Stopwords
São palavras consideradas irrelevantes no contexto que está sendo analisado, tais como preposições e
artigos. Para Gonçalves (2003), a eliminação destas palavras no processo de indexação salva uma enorme
quantidade de espaços em índices e não prejudica a eficácia da recuperação. Estas palavras negativas devem
ser retiradas na etapa de preparação dos dados.
2.5.2 Técnica associativa
Segundo Loh (2001), a técnica associativa consiste em descobrir relações entre conceitos,
expressando os resultados em forma de regras X  Y, o que significa que “se X está presente em um texto,
então Y estará presente nesse texto com um determinado grau de certeza (confiança)”.
Este grau de confiança pode ser calculado com o mesmo princípio da probabilidade condicional:
utilizando a fórmula presente no quadro 2, se obtém a probabilidade de um evento A ocorrer, dado que um
evento B ocorreu.
Quadro 2 – Fórmula para calcular a probabilidade condicional
P(A|B) =
Para Tan, Steinbach e Kumar (2006), a análise de associação é uma metodologia que oferece grande
suporte na busca de relações com interesse escondidas em grandes conjunto de dados. Segundo o exemplo
que foi apresentando pelos autores, em um case da rede Wall-Mart foi descoberta a relação entre fraldas 
cerveja. Os autores sugerem que utilizando estas regras de associação é possível então identificar novas
oportunidades de venda de produtos, e assim obter vantagem competitiva sobre seus concorrentes.
2.5.3 Text mining na engenharia de software
Durante a etapa de desenvolvimento do software, programadores codificam e corrigem defeitos,
entre outras tarefas. A utilização de ferramentas introduzidas e integradas ao processo de desenvolvimento
permite que sejam armazenados de forma automática dados do processo de desenvolvimento. É possível
minerar estes dados com o objetivo de descobrir padrões e regras que possam melhorar a qualidade do
7

8. sistema, ou até mesmo melhorar a produtividade das equipes. Colaço Jr. (2010) cita algumas das atividades
que podem ser auxiliadas com a aplicação da mineração de dados.
 Programação – Em nível de construção do software, a descoberta de padrões pode ajudar a: (i)
identificar características de uso de uma API (Application Program Interface) ou framework
automaticamente; (ii) manter os padrões de uso atualizados, baseando-se sempre na mais nova
versão da API ou framework; (iii) identificar padrões que abranjam casos de herança em
frameworks.
 Manutenção – A mineração de dados aplicada no histórico de alterações armazenadas por
sistemas de controle de versões pode auxiliar os desenvolvedores com sugestões do tipo “os
desenvolvedores que modificaram o método X também modificaram o método Y”.
 Detecção de defeitos – Todos os sistemas devem seguir algumas regras da linguagem de
programação utilizada para que possam se manter corretos. Grande parte dos erros acontece pela
falta de combinação entre alguns métodos. Por exemplo, chamar o método para desalocar
memória por uma estrutura de dados que não foi instanciada. Utilizando a mineração de textos, é
possível identificar estes padrões e verificar o código, buscando os trechos que não seguem o
padrão e que podem apresentar defeitos.
2.5.4 Ferramentas de text mining aplicadas a engenharia de software
Abaixo serão apresentadas duas ferramentas encontradas que utilizam técnicas de text mining e são
aplicadas no contexto de engenharia de software.
 ChangeMiner2 – É um plug-in gratuito para Visual Studio capaz de minerar o histórico de
versões. No momento da alteração do código, baseado no histórico, o plug-in reporta ao
desenvolvedor os prováveis próximos pontos de manutenção. Essa apresentação é feita de forma
gráfica e textual e tem como objetivo aumentar a eficiência nas manutenções realizadas no
sistema.
 NeuroMiner3– Esta ferramenta combina mineração de textos com técnicas de inteligência
artificial e estatística. O ambiente utiliza princípios da programação neurolinguística para extrair
o canal cognitivo mais usado pelos programadores, por exemplo, de listas de discussões de um
projeto. Isso auxilia na tomada de decisões, pois é possível traçar um perfil psicológico de cada
desenvolvedor ou cliente da empresa, com base em qualquer texto analisado que represente uma
interação.
3 APRESENTAÇÃO DA FERRAMENTA PARA GESTÃO DE DEMANDAS DE TESTE – GDT
A ferramenta desenvolvida foi batizada de GDT. Implementada na linguagem de desenvolvimento
web PHP, com características de orientação a objetos, o sistema foi construído de forma a ser intuitivo e
amigável com os usuários, respeitando os princípios de ergonomia, cuidando do tamanho das telas, das cores
utilizadas e das mensagens objetivas e padronizadas nas interações com o usuário.
A implantação do GDT proporciona a automatização do processo de gestão das demandas de teste e
descoberta de conhecimento nos bugs reportados. Isso é feito através de uma aplicação web em que as
demandas existentes em cada etapa do teste são distribuídas e controladas por esta ferramenta, possibilitando
ao gestor uma visão geral do andamento dos projetos e da produtividade das equipes com os gráficos gerados
através ferramenta.
Com esta ferramenta na gestão do teste, é possível identificar padrões nos bugs reportados,
utilizando técnicas de text mining. Isso possibilita a utilização desses dados para propor melhorias nos
futuros projetos.
Para que a aplicação seja aprovada e possa contribuir de fato com o processo de testes da Empresa X,
foi adotado o processo de desenvolvimento padrão da empresa. Nesse processo, todos os casos de uso foram
especificados, as telas foram prototipadas, o banco foi modelado, foi criado um dicionário de dados e foi
elaborado um plano de testes. Também foram criados os casos de teste e checklists para cada caso de uso.
Todos os documentos gerados estão disponíveis na ferramenta, através do menu documentação.
2
Link para download da ferramenta: https://sites.google.com/site/frchico/changeminer
3
Link para a página oficial da ferramenta: http://qualycred.com/software/neurolinguisticminer/
8

9. 3.1 Descrição dos requisitos
Nesta seção será descrito o funcionamento, os detalhes técnicos e os requisitos funcionais das
principais telas do sistema. Cada subseção representa um módulo do sistema GDT. A especificação
detalhada de cada caso de uso do sistema está disponível através do menu documentação da ferramenta.
3.1.1 Módulo Cadastro
O módulo cadastro é a base do sistema. Para realizar a gestão das etapas de teste de um projeto, é
necessário seguir o fluxo apresentado na figura 4, em que uma equipe, cadastrada, cadastra o cliente, o
projeto e os casos de uso desse projeto.
Figura 4 – Fluxo para liberar as etapas de teste
 Equipe – Através desta tela será criado o usuário que as equipes irão utilizar para logar no
sistema. O campo e-mail deve ser preenchido no formato correto, e a senha deve ter de 6 a 10
caracteres. As equipes cadastradas serão utilizadas para distribuir as demandas existentes nas
etapas de teste, no cadastramento do projeto (em que é designado um testador responsável), no
controle dos bugs, nos gráficos de produtividade gerados através do dashboard e no diário de
testes, no qual é gravado o usuário que incluiu o registro.
 Cliente – Nesta tela serão cadastrados os clientes que terão projetos gerenciados através da
ferramenta.
 Projeto – Nesta tela será feito o cadastro do projeto a ser gerenciado através da ferramenta. Será
informado o cliente, o nome do projeto e uma breve descrição, a data inicial do projeto, o prazo
para escrita dos casos de teste, o prazo final do projeto e o team leader do projeto. As datas
informadas nesta tela serão utilizadas no gráfico de prazos gerado através do menu dashboard.
 Casos de uso – O sistema permite criar até trinta casos de uso por vez através desta tela. Para cada
caso de uso cadastrado será gerado automaticamente uma demanda em cada uma das etapas de
teste (escrita do caso de teste, execução do caso de teste, checklist e evidência de teste). Esta
geração automática é feita pois estes cinco cadastros (etapas de teste + caso de uso) são gravados
na mesma tabela (tabela UC) do banco de dados, conforme pode ser observado na figura 10. Os
campos da tabela UC que apresentam o sufixo _CT se referem à escrita do caso de teste, _ET à
execução do caso de teste, _CL ao checklist, _EV à evidência de teste e os demais ao próprio caso
de uso.
3.1.2 Módulo Etapas de teste
Este módulo é dividido em quatro etapas nas quais o testador informa a data de início da atividade, a
data de conclusão, o tempo consumido, faz algumas observações e informa o status em que se encontra a
atividade, além do nome da equipe responsável por sua execução. Esta estrutura é mantida nas quatro etapas,
com exceção da etapa de escrita do caso de teste, onde é informada a complexidade da análise e a
complexidade do teste, conforme pode ser observado na figura 5.
9

10. Figura 5 – Tela de controle da etapa de escrita do caso de teste
3.1.3 Módulo Ferramentas
O módulo ferramentas é composto pelas funcionalidades que irão fazer o diferencial do GDT em
relação às demais ferramentas utilizadas no mercado, adequando-se à necessidade da Empresa X.
 Controle de bugs – Através desta tela, serão reportados todos os bugs encontrados durante as
etapas de teste. O testador irá informar o cliente, o projeto, o caso de uso ao qual se refere o bug
encontrado, o grau de severidade deste bug, uma breve descrição, a descrição completa e o
resultado esperado para o funcionamento correto da funcionalidade. Então, o bug é atribuído a
uma equipe para correção. É possível inserir comentários e anexar documentos que evidenciem a
existência do bug. A cada troca de status ou anexo adicionado, é inserido um comentário-padrão,
registrando esta ação.
Figura 6 – Tela de reporte de bugs
10

11. Na figura 10, é possível identificar todos os relacionamentos da tabela BUG para guardar os
comentários inseridos, anexos (nome e extensão), nome da equipe que reportou, nome da equipe
que resolveu, status, severidade.
Esta tela é fundamental para o funcionamento da funcionalidade de text mining, pois é através
dela que serão gerados os dados que serão analisados. Na figura 6 estão destacados os dois
campos que serão utilizados em busca de conhecimento.
 Diário de testes – Esta tela tem como objetivo registrar diariamente fatos que ocorreram e podem
impactar nos prazos de entrega acordados com o cliente, como, por exemplo, indisponibilidade do
ambiente ou a existência de elevado número de bugs bloqueando a continuidade dos testes. Estes
dados serão utilizados para negociar prazos com o gerente de projetos e com o cliente, caso seja
necessário. Ao final do projeto, na reunião de retrospectiva, estes dados também são apresentados
para que nos próximos projetos estes problemas não ocorram e estes itens possam ser utilizados
como riscos auxiliando nas estimativas de prazos, se for o caso.
 Dashboard – Através do dashboard, é fornecido ao gestor uma visão geral do andamento das
demandas de teste do projeto, contribuindo para maior assertividade na tomada de decisões. O
usuário informa qual o projeto e que tipos de gráficos deseja visualizar. Então, utilizando as
bibliotecas Highcharts e jQuery, são apresentados os gráficos. Na figura 7 temos o exemplo do
gráfico de linhas usado para acompanhar a produtividade das equipes e o gráfico de colunas,
utilizado para acompanhar a execução das demandas do projeto selecionado. No total, são
oferecidas cinco opções de gráficos: (i) Produtividade, que permite enumerar as atividades que
cada equipe alocada no projeto executou; (ii) Acompanhamento das atividades (status), que
oferece uma visão de cada etapa de teste, mostrando em que status se encontram as atividades;
(iii) Acompanhamento das atividades (%), que exibe um gráfico de colunas apresentando o
percentual de conclusão de cada uma das etapas; (iv) Prazos, que exibe um gráfico de linhas com
flags da data inicial do projeto, prazo de escrita dos casos de teste, data atual e prazo final,
facilitando o controle dos prazos; (v) Bugs por dia, que exibe um gráfico de linha pelo qual é
possível verificar a quantidade de bugs abertos por dia, possibilitando ao analista de testes
identificar desvios. Por exemplo: muitos bugs abertos no final da etapa de testes.
Figura 7 – Exemplo de gráficos gerados pelo dashboard
 Text mining – A funcionalidade de text mining é um dos principais diferenciais da ferramenta
GDT. Devido a sua importância, foi criada a seção 3.1.4, para que ela possa ser descrita em
detalhes desde o processamento dos bugs reportados até o conhecimento que é obtido através da
sua utilização.
3.1.4 Módulo Ferramentas: Text mining
Através da figura 8, é possível acompanhar todo o fluxo realizado pelo caso de uso: processar text
mining. Este fluxo pode ser ativado através do botão processar, presente na tela text mining, onde o usuário
11

12. pode selecionar o projeto cujos bugs devem ser processados. Esta mesma rotina é executada todos os dias às
24h através de uma tarefa cron4 agendada no servidor, processando os bugs pendentes de todos os projetos.
Figura 8 – Fluxo de processamento dos bugs
Nos passos 2 e 4 presentes na figura 8, é feita a preparação dos dados. As palavras contidas na tabela
STOPWORD do banco foram alimentadas com análises estatísticas de vários autores5 e calibradas conforme
a necessidade.
Após o processamento dos bugs, é possível consultar os conhecimentos que foram descobertos neste
processo. O sistema dispõe de quatro opções de análise.
 Análise 1 – Descrição do bug: são apresentadas as 70 palavras com o maior suporte, que
aparecem na descrição dos bugs reportados para o projeto selecionado, ordenadas de forma
decrescente. Representada pela primeira tabela exibida na figura 9.
 Análise 2 – Resultado esperado do bug: são apresentadas as 70 palavras com o maior suporte, que
aparecem no resultado esperado dos bugs reportados para o projeto selecionado, ordenadas de
forma decrescente. Representada pela segunda tabela exibida na figura 9.
 Análise 3 – Descrição x resultado esperado: é apresentada uma palavra da descrição (X) e uma
palavra do resultado esperado (Y), com o respectivo suporte e a probabilidade condicional. São
exibidos os 70 primeiros pares, ordenados pelo seu suporte de forma decrescente. Representada
pela terceira tabela exibida na figura 9.
 Análise 4 – Probabilidade condicional: foi utilizada uma técnica de associação para prever a
solução de um bug com determinada descrição. É representada pela lista que é exibida na figura
9. Para realizar o cálculo da confiança, foi utilizada a fórmula da probabilidade condicional, que
foi estudada no quadro 2 e adequada à necessidade conforme o quadro 3.
Quadro 3 – Fórmula para calcular a probabilidade condicional
P(XY) =
Onde:
X= Palavra da descrição do bug.
Y= Palavra do resultado esperado do bug.
4
Tarefas Cron é uma opção do servidor que permite agendar tarefas para serem executadas periodicamente.
5
A base inicial com as stopwords foi extraída através do link http://miningtext.blogspot.com.br/2008/11/listas-de-stopwords-stoplist-portugues.html
12

13. Figura 9 – Análises geradas pela tela de text mining
3.2 Modelagem do banco de dados
A modelagem do banco de dados foi realizada através da ferramenta desenvolvida pela Sun, o
MySQL Workbench. Esta ferramenta é gratuita e permite uma conexão direta com o banco de dados MySQL,
facilitando a criação das tabelas e a geração dos scripts.
Na figura 10, que representa a modelagem do banco de dados, é possível ter uma noção do
funcionamento do sistema e dos relacionamentos entre as tabelas.
13

14. Figura 10 – Modelagem do banco de dados
3.3 Comparativo
Através do quadro 4, foi traçado um comparativo entre as ferramentas estudadas na seção 2.2 deste
trabalho e a ferramenta proposta. Alguns itens foram sinalizados com asterisco devido ao fato de a
ferramenta não ter esta funcionalidade, embora permita a integração com outra ferramenta que a tenha.
Apesar de as duas ferramentas permitirem a gestão das etapas de teste, elas não são de fácil
compreensão. Não foram projetadas com este propósito, embora cumpram o objetivo. O grande diferencial
da ferramenta GDT é que ela foi projetada especialmente para a gestão das etapas do teste e fornece um
módulo que permite a descoberta de conhecimento nos bugs reportados, funcionalidade que nenhuma das
outras duas ferramentas estudadas oferece.
Dois itens que devem ser aprimorados na ferramenta GDT são referentes a permissões dos usuários e
à criação dos casos de teste na própria ferramenta. Em relação a este segundo item, pode ser estudada uma
forma de gerar automaticamente os casos de teste.
14

15. Quadro 4 – Comparativo das funcionalidades da ferramenta GDT
Funcionalidades TestLink RQM GDT
Criação dos casos de teste
Gestão da execução dos casos de teste
Gestão da execução do checklist
Gestão da execução das evidências
Diário de testes
Controle de bugs
Gráficos gerenciais
Descoberta de conhecimento nos bugs
Restrições por usuários
3.4 Cronograma de implantação do sistema
Através do cronograma exibido na figura 11, estão especificadas as atividades que foram executadas
e o próximo importante passo, que será a implantação do sistema em produção, através de um projeto-piloto.
Figura 11 – Cronograma de atividades do projeto GDT
4 VALIDAÇÃO, EXPERIMENTOS E TESTES
A validação do sistema GDT ocorreu com a utilização das próprias etapas de teste estudadas neste
trabalho: escrita dos casos de teste, execução de casos de teste e checklist. Também foi realizado um
experimento com ênfase no teste da funcionalidade do menu text mining. Esses procedimentos serão
detalhados nas subseções deste tópico.
4.1 Execução dos casos de teste
Para cada um dos 38 casos de uso do sistema foi criado um caso de teste específico, em que foram
testados os requisitos e comportamentos de cada funcionalidade. Esta etapa foi executada por três testadores
da Empresa X, e o resultado encontra-se disponível no menu documentação da própria ferramenta.
4.2 Checklist
Para cada um dos 38 casos de uso do sistema foi criado um checklist correspondente, no qual foram
revisados itens padrões de cada tipo de tela (Pesquisa, Inclusão, Edição, Exclusão etc). Esta etapa foi
executada por quatro testadores da Empresa X. A demanda foi dividida de forma que o testador executasse o
checklist de uma tela que foi testada por outra equipe. O resultado está disponível no menu documentação da
própria ferramenta.
15

16. 4.3 Experimentos
Foram realizados experimentos específicos na funcionalidade de text mining, nos quais foram
reportados bugs reais encontrados durante a etapa de testes de um projeto desenvolvido pela Empresa X. O
cliente que solicitou este projeto será chamado de Cliente ABC. Os projetos do Cliente ABC correspondem a
cerca de 35% do faturamento da sede de Porto Alegre da Empresa X e tem seu próprio padrão de telas,
mensagens e comportamentos.
Baseado nas quatro análises geradas e destacadas na figura 9, o analista de testes alocado neste
projeto chegou à conclusão de que grande parte dos bugs reportados eram referentes a mensagens de
validação, validações de campos com período de datas (data inicial e data final), padrões do cliente e
comportamento do sistema (foco nos campos).
Figura 12 – Classificações feitas pelo analista de teste, baseado na Análise 4
Na figura 12 é apresentada a visão que o analista de teste interpretou para chegar a suas conclusões.
Os bugs foram classificados em cinco grupos.
 Mensagens – Bugs relacionados a mensagens de validação do sistema. Neste grupo foram
identificados dois subgrupos: (i) mensagens de campos data (intervalo inicial e final), por
exemplo, bugs com a descrição “data” têm 15,09% de chances de a solução estar ligada à
correção na “mensagem” de validação; (ii) mensagens de validação de acordo com nome da label,
por exemplo, bugs com descrição “mensagem” têm 3,09% de chances de estarem relacionados ao
nome da label.
 Comportamentos – Bugs relacionados ao comportamento do sistema. Por exemplo, quando a
descrição do bug tiver a palavra “incorreto”, há 15,38% de probabilidade de que a solução seja
promover ajustes no “foco” dos campos. Outro exemplo: quando a descrição contiver a palavra
“comportamento” há 6% de chances de que a solução deste bug seja o ajuste no valor “default”
dos campos.
16

17.  Padrões – Bugs relacionados ao padrão do cliente. Por exemplo, mensagem de validação em
desacordo com o padrão estabelecido. Ou nome de labels do mesmo campo escritas de forma
diferente em diferentes telas.
 Permissões – Bugs relacionados à permissão dos usuários. Por exemplo, usuário de consulta com
permissão para edição.
 Obrigatoriedade – Bugs relacionados a validações de obrigatoriedade de campos. A figura 12
indica que os bugs reportados com a palavra “obrigatoriedade” têm 10,34% de chances de a
solução estar em ajustes na mensagem para ficar de acordo com o nome da label.
Pelo conhecimento obtido, foram tomadas as seguintes providências para que os próximos projetos
deste cliente não apresentem os mesmos bugs.
 Foi designado um recurso de teste para, durante a fase de construção, de acordo com os padrões
estabelecidos, validarem: as telas; as mensagens; os menus; e o comportamento do sistema.
 As equipes de análise, desenvolvimento e teste que serão alocadas nos projetos do Cliente ABC
passarão por um treinamento de cinco horas em que serão apresentados todos os padrões
específicos deste cliente e serão realizadas algumas atividades práticas. Esta ação será executada,
a cada projeto, por uma equipe diferente, possibilitando que todos tenham a oportunidade de
estudar e repassar o conhecimento.
Com estas duas ações, é esperada uma redução no número de bugs relacionados a padrões e layout,
tanto de desenvolvimento quanto de análise, evitando retrabalho de todas as áreas. Assim, as equipes de teste
poderão direcionar o esforço dos testes para os requisitos e regras de negócios.
5 CONSIDERAÇÕES FINAIS
Diante das necessidades da Empresa X de automatizar a gestão das demandas da área de teste, foi
desenvolvido o sistema GDT. Para minimizar os riscos deste projeto, foi seguida a metodologia que é
empregada atualmente na empresa (levantamento de requisitos, definição dos casos de uso, especificação das
regras, protótipos, plano de testes etc.).
Durante a fase do levantamento de requisitos surgiu a ideia da criação do módulo ferramentas, que é
o grande diferencial em relação às demais ferramentas do mercado. Neste módulo está contido o menu
controle de bugs, no qual verificou-se que, a cada projeto, é gerada uma base de dados rica em informações
referentes aos defeitos do projeto em questão. E esta base deveria ser explorada para extração de
conhecimento, e para que este conhecimento seja aplicado como aprendizado em projetos futuros. Então,
surgiu o menu text mining, que tem esta proposta.
A solução proposta atendeu aos resultados esperados pela Empresa X, visto que a gestão das
atividades realizada pela aplicação contornou todos os problemas apresentados nas planilhas eletrônicas,
como a falta de segurança e integridade dos arquivos, a indisponibilidade de acesso simultâneo, a quantidade
desnecessária de arquivos e a falta de uma visão geral dos projetos para o gestor.
Além de facilitar a gestão das quatro etapas do teste, a ferramenta proporcionou aos analistas de
testes a descoberta do conhecimento nos bugs reportados através da ferramenta, o que antes só era possível
questionando os testadores alocados no projeto. Este conhecimento, obtido no experimento apresentado na
seção 4 deste trabalho, já foi utilizado pela Empresa X em tomadas de decisão que trouxeram melhora na
qualidade do produto.
Em relação a trabalhos futuros, este projeto será continuado pela Empresa X, com o
desenvolvimento do módulo de alertas, pelo qual o sistema emitirá avisos ao gestor, conforme o andamento
do projeto e a execução das atividades.
Ainda em relação aos trabalhos futuros, será desenvolvido um módulo em que o caso de testes será
escrito através da própria ferramenta. A ideia é utilizar alguma técnica existente para a geração de um
template padrão do caso de teste. Por exemplo, o analista irá fazer o upload do protótipo da tela, e o sistema
irá gerar um caso de teste, validando a obrigatoriedade, os campos de data etc. Assim, o analista de testes
poderá focar seus esforços apenas em escrever cenários que validem as regras de negócio.
Em relação a melhorias da ferramenta, deve-se possibilitar a aplicação de restrição de acessos,
utilizando a sessão que é criada durante o logon, permitindo que apenas usuários alocados no projeto tenham
17

18. acesso aos dados, e de acordo com o nível de permissões atribuídas ao seu perfil.
A ferramenta e toda a sua documentação encontram-se disponíveis através do link
http://www.marcos.pro/gdt/php/.
AGRADECIMENTOS
À DEUS, por ter me dado esta oportunidade, por iluminar o meu caminho e me trazer forças nos
momentos difíceis durante esta caminhada de seis anos em que passei nesta instituição.
Aos meus familiares e a amigos verdadeiros, que me incentivaram e me motivaram durante este
período.
Aos colegas e amigos de curso, pelos momentos de descontração e pelos momentos de aprendizado
colaborativo que foram muito produtivos.
Ao meu orientador, Prof. Dr. Stanley Loh pelo seu comprometimento, disposição e por todas as
contribuições que me deu durante o desenvolvimento deste trabalho.
Aos colegas de trabalho da área de teste, por todo o suporte que foi dado para o sucesso deste
trabalho, pelos testes realizados na aplicação, as sugestões de melhorias, as reuniões de acompanhamento e
apoio sempre que necessário.
Aos colegas de trabalho da área de análise e desenvolvimento, pelas dicas, conceitos, sugestão de
ferramentas, e pelo apoio e prontidão com que me ajudaram sempre que foram encontrados obstáculos.
REFERÊNCIAS
AQUINO, Ueslei; NOGUEIRA, Elias. 24ª edição da Mesa Redonda DFTestes. Disponível na Internet.
Mensagem recebida da lista DFTestes administrada pelo servidor DFTestes@yahoogrupos.com.br. 10 mai.
2010.
ARANHA, Christian; PASSOS, Emmanuel. A Tecnologia de Mineração de Textos. RESI - Revista
Eletrônica de Sistemas de Informação, Rio de Janeiro, n.2, 2006. Disponível em:
<http://revistas.facecla.com.br/index.php/reinfo/article/download/171/66>. Acesso em: 16 mar. 2012.
BARTIÉ, Alexandre. Garantia da Qualidade de Software: adquirindo maturidade organizacional. Rio de
Janeiro: Campus, 2002.
CHEN, Hsinchun. Knowledge management systems: a text mining perspective. Tucson, Arizona:
University of Arizona, 2001.
COLAÇO JR, Methanias. Mineração de Repositórios de Software: A Computação ajudando à Computação.
SQL Magazine, 31 jul. 2010.
GONÇALVES, Márcio. Extração de dados para Data Warehouse. Rio de Janeiro: Axcel Books, 2003.
HOESCHL, Hugo Cesar. et al. AlphaThemis - do texto ao conhecimento. In: 1st workshop on Automatic
Deduction and Artificial Intelligence (IDEIA), in the 8th Iberoamerican Conference on Artificial
Intelligence, 2002, Sevilha. Anais. Florianópolis: UFSC, 2002.
LOH, Stanley. Abordagem Baseada em Conceitos para Descoberta de Conhecimento em Textos. Porto
Alegre: UFRGS, 2001. Tese (Doutorado em Ciência da Computação), Instituto de Informática, Universidade
Federal do Rio Grande do Sul, 2001.
LONGO, Rose M. J. Gestão da qualidade: evolução histórica, conceitos básicos e aplicação na educação.
In: Seminário Gestão da qualidade na educação: em busca da excelência, 1995, São Paulo. Anais. Brasília:
Instituto de Pesquisa Econômica Aplicada, 1996. 14 p.
MARTINS, Miriam R. Ferramenta de suporte a reuso de casos de uso. Blumenau: FURB, 2006. Trabalho
de Conclusão de Curso (Graduação em Ciência da Computação), Centro de Ciências Exatas e Naturais,
Universidade Regional de Blumenau, 2006.
18

19. MYERS, Glenford J. The Art of Software Testing. New York: Wiley, 1979.
OLIVEIRA, Jadielly. et al. WKM: Uma Ferramenta para Auxiliar a Gerência de Conhecimento Integrada a
um ADS Centrado em Processos. In: VI Workshop Anual do MPS, 2010, Campinas. Sessão de Ferramentas
do VI Workshop Anual do MPS, 2010.
PORTO, Edson. O poder das listas. Época Negócios. [S.l], 04 fev. 2010. Disponível em:
<http://epocanegocios.globo.com/Revista/Common/0,,EMI120258-16366,00-
O+PODER+DAS+LISTAS.html>. Acesso em: 28 mar. 2012.
PRESSMAN, Roger S. Engenharia de Software, São Paulo: Makron Books, 2005.
RUS, Iona; LINDVALL, Mikael. Knowledge Management in Software Engineering. IEEE Software, [S.l],
vol. 19, n. 3, p. 26-38. mai. 2002.
SVEIBY, Karl. et al. Gestão do Conhecimento: Um novo caminho. HSM Management, [S.l], n. 22, ano 4,
set.-out. 2000.
TAN, Ah-Hwee. Text mining: the state of the art and the challenges. In: Pacific-Asia Workshop on
Knowledge Discovery from Advanced Databases – PAKDD’99, Beijing, 1999.
TAN, Pang-Ning; STEINBACH, Michael; KUMAR, Vipin. Introduction to Data Mining. Boston:
Addison-Wesley, 2006.
TURBAN, Efraim; McLEAN, Efraim; WETHERBE, James. Tecnologia da Informação para Gestão.
Porto Alegre: Bookman, 2004.
UBER, Jacqueline. Validação das ocorrências policiais com base na descrição textual do boletim de
ocorrência utilizando text mining. Florianópolis: UFSC, 2004. Dissertação (Mestrado em Ciência da
Computação), Departamento de Informática e Estatística, Universidade Federal de Santa Catarina, 2004.
UBER, José L. Descoberta de conhecimento com uso de text mining aplicada ao SAC. Blumenau:
FURB, 2004. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação), Centro de Ciências
Exatas e Naturais, Universidade Regional de Blumenau, 2004.
ZAIDAN, Fernando H. Processo de desenvolvimento de sistemas de informação como forma de
retenção do conhecimento organizacional para aplicação estratégica: Estudo de múltiplos casos. Belo
Horizonte: FUMEC, 2008. Dissertação (Mestrado em Administração), Faculdade de Ciências Empresariais,
Universidade Fundação Mineira de Educação e Cultura, 2008.
19