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.

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.

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

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.

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

REQ 1 Promover ações de conscientização sobre a importância da realização da gerência de

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.

6

REQ 3 Estabelecer políticas para criação, compartilhamento e utilização de ativos de

conhecimento por toda a organização.

REQ 4 Definir papéis e alocar pessoas responsáveis para trabalhar na execução do processo.

de gerência do conhecimento.

REQ 5 Permitir o planejamento das ações relacionadas à gerência do conhecimento, de

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.

REQ 7

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,

estabelecendo padrões e classificações de tipos de conhecimento a fim de facilitar a

recuperação e a disseminação dos ativos.

REQ 8

Permitir a avaliação de conhecimento antes de armazená-lo e disponibilizá-lo para a

organização, com o objetivo de filtrar conhecimento de valor, garantindo que o

mesmo esteja correto e claro o suficiente para ser reutilizado.

REQ 9 Garantir que o conhecimento está disponível para reutilização por outros membros

da organização.

REQ 10 Permitir a busca de conhecimento pelos membros da organização.

REQ 11

Formar uma rede de especialistas na organização, permitindo a busca de pessoas

(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.

REQ 12 Desenvolver soluções para a disseminação do conhecimento aos funcionários da

organização.

REQ 13

Permitir que os usuários avaliem a utilidade do conhecimento, bem como a própria

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.

REQ 14 Permitir a manutenção de conhecimento, de forma que o conhecimento defasado

possa ser atualizado ou desabilitado da organização.

REQ 15 Promover formas de compensar os funcionários pela criação de conhecimento de

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

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

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/

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.

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

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

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(XY) =

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

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.

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.

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.

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.

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

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.

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.