Your SlideShare is downloading. ×
GESTÃO DE DEMANDAS DE TESTE E ANÁLISE DE             PADRÕES COM TEXT MINING1                                      Marcos ...
em formato textual. Visto que é inviável a análise manual de cada um destes textos, é de se considerar autilização de ferr...
2.1.3    Checklist         O checklist é uma prática antiga utilizada em diversos segmentos. Por exemplo: em 1935, segundo...
a integração com outro sistema, desenvolvido pela própria IBM, para reportar os bugs encontrados durante oteste, o Rationa...
A área de desenvolvimento de software sofre constantes mudanças e conta com interações de muitaspessoas que atuam em difer...
Estabelecer políticas para criação, compartilhamento e utilização de ativos de      REQ 3                 conhecimento por...
ganho de produtividade.2.5     Text mining         Segundo Chen (2001), 80% do conteúdo online está armazenado em formato ...
sistema, ou até mesmo melhorar a produtividade das equipes. Colaço Jr. (2010) cita algumas das atividadesque podem ser aux...
3.1     Descrição dos requisitos        Nesta seção será descrito o funcionamento, os detalhes técnicos e os requisitos fu...
Figura 5 – Tela de controle da etapa de escrita do caso de teste3.1.3   Módulo Ferramentas        O módulo ferramentas é c...
Na figura 10, é possível identificar todos os relacionamentos da tabela BUG para guardar os          comentários inseridos...
pode selecionar o projeto cujos bugs devem ser processados. Esta mesma rotina é executada todos os dias às24h através de u...
Figura 9 – Análises geradas pela tela de text mining3.2   Modelagem do banco de dados         A modelagem do banco de dado...
Figura 10 – Modelagem do banco de dados3.3   Comparativo        Através do quadro 4, foi traçado um comparativo entre as f...
Quadro 4 – Comparativo das funcionalidades da ferramenta GDT            Funcionalidades                        TestLink   ...
4.3   Experimentos         Foram realizados experimentos específicos na funcionalidade de text mining, nos quais foramrepo...
 Padrões – Bugs relacionados ao padrão do cliente. Por exemplo, mensagem de validação em          desacordo com o padrão ...
acesso aos dados, e de acordo com o nível de permissões atribuídas ao seu perfil.        A ferramenta e toda a sua documen...
MYERS, Glenford J. The Art of Software Testing. New York: Wiley, 1979.OLIVEIRA, Jadielly. et al. WKM: Uma Ferramenta para ...
Upcoming SlideShare
Loading in...5
×

GDT - Gestão de Demandas de Teste

916

Published on

Ferramenta web para gestão das demandas presentes na etapa de testes e descoberta de conhecimento nos bugs reportados através da técnica de text mining.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
916
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "GDT - Gestão de Demandas de Teste "

  1. 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, asorganizações devem traçar estratégias para que possam se destacar e obter vantagens sobre os seusconcorrentes. E um diferencial que tem ganhado destaque entre as empresas que atuam na área dedesenvolvimento 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 oprojeto. De acordo com Bartié (2002), quanto mais procedimentos fizerem parte do processo de teste desoftware, melhor será o nível de avaliação do produto, e por consequência resultará em um produto final commaior qualidade. A Empresa X, na qual este trabalho propõe a implantação do GDT, tem um processo maduro detestes, com as seguintes etapas: escrita dos casos de teste, execução dos casos de teste, checklist e evidênciasde teste. O conceito de cada uma destas etapas será apresentado na seção 2.1 deste trabalho. Apesar doprocesso bem definido, a empresa utiliza-se de planilhas eletrônicas para o controle das etapas, o queimpossibilita a utilização simultânea desta planilha, gera quantidades desnecessárias de arquivos e nãogarante a integridade desses arquivos, dificultando o papel do gestor, que não tem uma visão geral doandamento das atividades e prazos. Segundo Nogueira (2010), este é o cenário ideal para a implantação daferramenta, visto que o processo de testes da empresa é bem definido, maduro, e a implantação da ferramentanã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 desviosencontrados no software testado, e estes reportes devem ser feitos na própria ferramenta GDT. Ao reportar obug, serão informados a descrição e o resultado esperado para este bug, essas informações serão armazenas1 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. 2. em formato textual. Visto que é inviável a análise manual de cada um destes textos, é de se considerar autilização de ferramentas que possam auxiliar na busca de conhecimento na base que será gerada. Isso podeser 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 grandesorganizações. Mais do que a tecnologia, o conhecimento é a chave para companhias que pretendem agregarvalor aos seus produtos e serviços. Este é um importante diferencial da ferramenta GDT. Aplicando textmining, os bugs reportados durante o projeto serão analisados, identificando padrões e tendências que devemser utilizados como aprendizado nos futuros projetos, com a finalidade de reduzir custos com retrabalho egarantir uma entrega com qualidade. O artigo esta estruturado em cinco seções, da seguinte forma: a seção 2 apresenta a fundamentaçãoteórica, que serviu como embasamento para este trabalho, destacando a técnica de text mining. Nesta seçãotambém são apresentados trabalhos relacionados à gestão do conhecimento na engenharia de software; aseção 3 apresenta detalhes da especificação e da implementação da ferramenta, além de traçar umcomparativo 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 esugestões para trabalhos futuros.2 REFERENCIAL TEÓRICO Nesta seção, serão apresentados alguns conceitos para a melhor compreensão da ferramentadesenvolvida e da metodologia utilizada. Foram abordados e contextualizados os seguintes tópicos: asdemandas presentes na etapa de testes, que serão absorvidas e controladas através da ferramenta; ferramentasde gestão para área de testes existentes; momento ideal para implantação de uma ferramenta no processo degestã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 ocuidado de inspecionar os bens e serviços que adquiriam, porém esta preocupação se voltava para o produtojá finalizado, o que não garantia a qualidade destes. A partir da década de 50, uma nova filosofia começou aser aplicada, com base em conceitos, métodos e técnicas, e a qualidade passou a ser um problema daempresa. Hoje em dia, é evidente a necessidade das organizações investirem em qualidade, criando umdiferencial frente ao mercado, evitando desgastes com o cliente e reduzindo impactos com retrabalhos emanutenção do produto. Em virtude desta crescente necessidade na oferta de qualidade, muitas empresas dedesenvolvimento 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 aintenção de encontrar defeitos (teste negativo)”. Nas subseções seguintes será apresentado o conceito de cadauma das etapas de teste praticadas na Empresa X, a gestão da execução destas etapas será feita através daferramenta 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 queos testadores devem fazer para a execução dos testes, com a finalidade de garantir que os testes realizadoscubram 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 desistemas e pelo analista de testes, servindo como referência para o testador e para o gestor na estimativa detempo 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 é liberadopara testes. Os testadores seguem os passos especificados nos casos de teste planejados na etapa anterior,reportando os bugs e desvios. 2
  3. 3. 2.1.3 Checklist O checklist é uma prática antiga utilizada em diversos segmentos. Por exemplo: em 1935, segundoPorto (2010), a Boeing determinou a seus pilotos a obrigatoriedade da utilização de checklist. Esta etapainicia-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. Issoevita 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 dochecklist, 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 finalentregue ao cliente, geralmente vai acompanhado por um vídeo, mostrando o desenvolvimento do teste, oupor 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. Aprimeira é o TestLink, que é uma das principais ferramentas do segmento e tem código aberto. A segunda é oRational Quality Manager (RQM), ferramenta desenvolvida pela IBM da qual a Empresa X tem licença deuso. Ambas as ferramentas têm o mesmo propósito, apesar de possuírem algumas particularidades que serãodetalhadas a seguir.2.2.1 TestLink O TestLink é uma ferramenta open source (código aberto) desenvolvida na linguagem PHP. Oprojeto é mantido pela comunidade aberta de testadores de todo o mundo, e se propõe a auxiliar ogerenciamento 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 econhecimento customizem a ferramenta e implementem novos recursos conforme a sua necessidade, amaioria dos métodos presentes no código-fonte não são comentados, o que pode dificultar um pouco estatarefa. Figura 1 – Interface da tela de especificação dos casos da ferramenta TestLink2.2.2 Rational Quality Manager (RQM) O RQM é um software proprietário desenvolvido pela IBM, que tem como principal finalidade aespecificação dos requisitos, o gerenciamento e a execução dos casos de teste. A ferramenta também permite 3
  4. 4. a integração com outro sistema, desenvolvido pela própria IBM, para reportar os bugs encontrados durante oteste, 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 mantidaa gestão por planilhas eletrônicas, a especificação pelo software Rose e o reporte dos bugs pela ferramentaRTC. Esta decisão foi tomada devido a dificuldades encontradas na adaptação ao sistema. A ferramenta foiavaliada como complexa e pouco intuitiva: o tempo consumido estava sendo superior ao utilizado no formatoantigo de gestão, afetando diretamente o budget do projeto. Figura 2 – Interface da tela de especificação dos casos da ferramenta Rational Quality Manager2.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 oprocesso de testes da empresa esteja bem definido e maduro. E a implantação da ferramenta só deve ocorrerse 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 setornar um grande risco para os projetos. Ele também afirma que a melhor ferramenta é aquela que atende aoprocesso de testes utilizado na organização, e que nem sempre a ferramenta ideal para uma empresa irá seadequar às necessidades de outra empresa. Para minimizar os riscos é importante fazer um estudo deviabilidade das ferramentas antes da aquisição e implantação. Portanto, não é aconselhável a implantação de uma ferramenta que altere radicalmente um processomaduro de testes, que já é utilizado pela organização, com a ilusão de que automaticamente se terá um ganhode 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 facilmentecustomizadas, 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 podemse tornar conhecimentos valiosos na tomada de decisões. E a gestão do conhecimento tem justamente estepropósito, de aproveitar o capital intelectual das organizações, que é o principal recurso de empresas quetrabalham com desenvolvimento de software. Para Turban, McLean e Wetherbe (2004), a gestão do conhecimento é o processo que tem comoobjetivo auxiliar as organizações a descobrir, organizar e distribuir a informação e o conhecimento quefazem parte da memória da empresa, e que normalmente existem dentro delas de forma não estruturada. 4
  5. 5. A área de desenvolvimento de software sofre constantes mudanças e conta com interações de muitaspessoas que atuam em diferentes atividades e fases do projeto. Rus e Lindvall (2002) afirmam que muitosconhecimentos são gerados em empresas de desenvolvimento, porém existem problemas para localizá-los eutilizá-los. O uso apurado destes conhecimentos é a motivação para conduzir a gestão do conhecimento nasempresas 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 grandeparte das empresas não ter obtido êxito ao aplicar técnicas de gestão do conhecimento se deve a não teremtraçado um planejamento estratégico bem definido antes da implantação. As empresas devem aguardar umdeterminado 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 noformato eletrônico durante as etapas de desenvolvimento, possibilitando a utilização de ferramentas queauxiliem na retenção e na disseminação de conhecimento, permitindo consequentemente seu reúso emprojetos 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, taiscomo o apoio às memórias do projeto e o apoio ao aprendizado, e principalmente aplicar em novos projetos oconhecimento 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 ligadacom o que Rus e Lindvall (2002) afirmam. O conhecimento adquirido através dos bugs reportados naferramenta será utilizado em reuniões de retrospectiva para servir como aprendizado em futuros projetos. Oobjetivo é 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 naengenharia 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 comoprincipal objetivo auxiliar no planejamento e na execução de estratégias de gestão do conhecimento. Trata-seda WebAPSEE Knowledge Manager (WKM). Através dessa ferramenta, é possível fazer a modelagem e aexecução dos processos, acompanhar o prazo das atividades e alocar recursos. A ferramenta promove ainda areutilização de boas práticas gerenciais em diferentes projetos e permite controlar as atividades de equipesque estão geograficamente dispersas. O autor definiu quinze requisitos. Eles se baseiam em: (i) Bibliografia sobre o que é necessário paraa implantação de Gerência do Conhecimento, na qual se destacam Rus e Lindvall (2002), utilizados comoreferência neste trabalho; (ii) Atividades descritas na NBR ISO/IEC 12207 e no Guia de Implementação donível E do modelo MPS; (iii) Aspectos socioculturais tratados no P-CMM; e (iv) Estudo qualitativo realizadocom 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. 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 deSucReuse, 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 oprocesso de reutilização em dois momentos. Primeiro, o engenheiro de software, através da técnica de analogia, identifica os casos de uso quetenham o mesmo contexto. Por exemplo, empréstimos financeiros e aplicações financeiras podem serclassificados como contexto financeiro. Depois de classificar o contexto, o engenheiro deve identificar, noscenários do caso de uso, as partes fixas e as partes variáveis. As partes variáveis devem informar um ou maisconceitos para o termo destacado como variável. Com este processo é criada a base de conhecimento paracada modelo de caso de uso que é inserido no repositório da ferramenta. A figura 3 exemplifica esta relaçãocriada, na qual os termos curso, coordenador e turma foram marcados como variáveis e devem ser definidostermos 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 decaso de uso que atenda a sua necessidade, e assim reutilizá-lo, fazendo pequenas modificações e obtendo um 6
  7. 7. ganho de produtividade.2.5 Text mining Segundo Chen (2001), 80% do conteúdo online está armazenado em formato textual. Este mesmopercentual, segundo Tan (1999), corresponde às informações disponíveis em uma organização no formatotextual e não estruturado. Devido a este crescente volume de informações armazenadas no formato textual, setorna inviável a análise manual de cada um destes textos, portanto é de se considerar, a utilização deferramentas que possam auxiliar na busca de conhecimento, isso pode ser feito utilizando a técnica de textmining (mineração de textos). Segundo Aranha e Passos (2006), a mineração de textos consiste em extrair padrões e tendências degrandes quantidades de documentos em formato textual e não estruturado, normalmente para um objetivoespecifico. 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 automatizare 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 emrazã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 emocorrências policiais, classificando automaticamente a natureza da operação do boletim de ocorrência. Elechegou à 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 eartigos. Para Gonçalves (2003), a eliminação destas palavras no processo de indexação salva uma enormequantidade de espaços em índices e não prejudica a eficácia da recuperação. Estas palavras negativas devemser 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 umevento 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 grandesuporte na busca de relações com interesse escondidas em grandes conjunto de dados. Segundo o exemploque 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 novasoportunidades 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 desenvolvimentopermite que sejam armazenados de forma automática dados do processo de desenvolvimento. É possívelminerar estes dados com o objetivo de descobrir padrões e regras que possam melhorar a qualidade do 7
  8. 8. sistema, ou até mesmo melhorar a produtividade das equipes. Colaço Jr. (2010) cita algumas das atividadesque 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ãoaplicadas 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 desenvolvimentoweb PHP, com características de orientação a objetos, o sistema foi construído de forma a ser intuitivo eamigável com os usuários, respeitando os princípios de ergonomia, cuidando do tamanho das telas, das coresutilizadas 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 edescoberta de conhecimento nos bugs reportados. Isso é feito através de uma aplicação web em que asdemandas existentes em cada etapa do teste são distribuídas e controladas por esta ferramenta, possibilitandoao gestor uma visão geral do andamento dos projetos e da produtividade das equipes com os gráficos geradosatravé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 nosfuturos 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 foramespecificados, as telas foram prototipadas, o banco foi modelado, foi criado um dicionário de dados e foielaborado 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/changeminer3 Link para a página oficial da ferramenta: http://qualycred.com/software/neurolinguisticminer/ 8
  9. 9. 3.1 Descrição dos requisitos Nesta seção será descrito o funcionamento, os detalhes técnicos e os requisitos funcionais dasprincipais telas do sistema. Cada subseção representa um módulo do sistema GDT. A especificaçãodetalhada 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, oprojeto 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, adata de conclusão, o tempo consumido, faz algumas observações e informa o status em que se encontra aatividade, 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 acomplexidade do teste, conforme pode ser observado na figura 5. 9
  10. 10. Figura 5 – Tela de controle da etapa de escrita do caso de teste3.1.3 Módulo Ferramentas O módulo ferramentas é composto pelas funcionalidades que irão fazer o diferencial do GDT emrelaçã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. 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 textmining. Este fluxo pode ser ativado através do botão processar, presente na tela text mining, onde o usuário 11
  12. 12. pode selecionar o projeto cujos bugs devem ser processados. Esta mesma rotina é executada todos os dias às24h 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 tabelaSTOPWORD do banco foram alimentadas com análises estatísticas de vários autores5 e calibradas conformea necessidade. Após o processamento dos bugs, é possível consultar os conhecimentos que foram descobertos nesteprocesso. 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. 13. Figura 9 – Análises geradas pela tela de text mining3.2 Modelagem do banco de dados A modelagem do banco de dados foi realizada através da ferramenta desenvolvida pela Sun, oMySQL 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 dofuncionamento do sistema e dos relacionamentos entre as tabelas. 13
  14. 14. Figura 10 – Modelagem do banco de dados3.3 Comparativo Através do quadro 4, foi traçado um comparativo entre as ferramentas estudadas na seção 2.2 destetrabalho e a ferramenta proposta. Alguns itens foram sinalizados com asterisco devido ao fato de aferramenta 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ácilcompreensão. Não foram projetadas com este propósito, embora cumpram o objetivo. O grande diferencialda ferramenta GDT é que ela foi projetada especialmente para a gestão das etapas do teste e fornece ummódulo que permite a descoberta de conhecimento nos bugs reportados, funcionalidade que nenhuma dasoutras 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 umaforma de gerar automaticamente os casos de teste. 14
  15. 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ários3.4 Cronograma de implantação do sistema Através do cronograma exibido na figura 11, estão especificadas as atividades que foram executadase 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 GDT4 VALIDAÇÃO, EXPERIMENTOS E TESTES A validação do sistema GDT ocorreu com a utilização das próprias etapas de teste estudadas nestetrabalho: escrita dos casos de teste, execução de casos de teste e checklist. Também foi realizado umexperimento com ênfase no teste da funcionalidade do menu text mining. Esses procedimentos serãodetalhados 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 foramtestados os requisitos e comportamentos de cada funcionalidade. Esta etapa foi executada por três testadoresda 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 foramrevisados itens padrões de cada tipo de tela (Pesquisa, Inclusão, Edição, Exclusão etc). Esta etapa foiexecutada por quatro testadores da Empresa X. A demanda foi dividida de forma que o testador executasse ochecklist de uma tela que foi testada por outra equipe. O resultado está disponível no menu documentação daprópria ferramenta. 15
  16. 16. 4.3 Experimentos Foram realizados experimentos específicos na funcionalidade de text mining, nos quais foramreportados bugs reais encontrados durante a etapa de testes de um projeto desenvolvido pela Empresa X. Ocliente que solicitou este projeto será chamado de Cliente ABC. Os projetos do Cliente ABC correspondem acerca 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 nesteprojeto chegou à conclusão de que grande parte dos bugs reportados eram referentes a mensagens devalidação, validações de campos com período de datas (data inicial e data final), padrões do cliente ecomportamento 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. 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 projetosdeste 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 testepoderã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, foidesenvolvido 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 dasregras, 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 menucontrole de bugs, no qual verificou-se que, a cada projeto, é gerada uma base de dados rica em informaçõesreferentes aos defeitos do projeto em questão. E esta base deveria ser explorada para extração deconhecimento, 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 dasatividades 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 quantidadedesnecessá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 detestes a descoberta do conhecimento nos bugs reportados através da ferramenta, o que antes só era possívelquestionando os testadores alocados no projeto. Este conhecimento, obtido no experimento apresentado naseção 4 deste trabalho, já foi utilizado pela Empresa X em tomadas de decisão que trouxeram melhora naqualidade do produto. Em relação a trabalhos futuros, este projeto será continuado pela Empresa X, com odesenvolvimento do módulo de alertas, pelo qual o sistema emitirá avisos ao gestor, conforme o andamentodo 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 umtemplate padrão do caso de teste. Por exemplo, o analista irá fazer o upload do protótipo da tela, e o sistemairá gerar um caso de teste, validando a obrigatoriedade, os campos de data etc. Assim, o analista de testespoderá 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. 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 linkhttp://www.marcos.pro/gdt/php/.AGRADECIMENTOS À DEUS, por ter me dado esta oportunidade, por iluminar o meu caminho e me trazer forças nosmomentos 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 esteperíodo. Aos colegas e amigos de curso, pelos momentos de descontração e pelos momentos de aprendizadocolaborativo que foram muito produtivos. Ao meu orientador, Prof. Dr. Stanley Loh pelo seu comprometimento, disposição e por todas ascontribuiçõ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 destetrabalho, pelos testes realizados na aplicação, as sugestões de melhorias, as reuniões de acompanhamento eapoio sempre que necessário. Aos colegas de trabalho da área de análise e desenvolvimento, pelas dicas, conceitos, sugestão deferramentas, e pelo apoio e prontidão com que me ajudaram sempre que foram encontrados obstáculos.REFERÊNCIASAQUINO, 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 - RevistaEletrô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 deJaneiro: 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 AutomaticDeduction and Artificial Intelligence (IDEIA), in the 8th Iberoamerican Conference on ArtificialIntelligence, 2002, Sevilha. Anais. Florianópolis: UFSC, 2002.LOH, Stanley. Abordagem Baseada em Conceitos para Descoberta de Conhecimento em Textos. PortoAlegre: UFRGS, 2001. Tese (Doutorado em Ciência da Computação), Instituto de Informática, UniversidadeFederal 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. Trabalhode 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. 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 aum ADS Centrado em Processos. In: VI Workshop Anual do MPS, 2010, Campinas. Sessão de Ferramentasdo 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 onKnowledge 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 deocorrência utilizando text mining. Florianópolis: UFSC, 2004. Dissertação (Mestrado em Ciência daComputaçã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ênciasExatas e Naturais, Universidade Regional de Blumenau, 2004.ZAIDAN, Fernando H. Processo de desenvolvimento de sistemas de informação como forma deretenção do conhecimento organizacional para aplicação estratégica: Estudo de múltiplos casos. BeloHorizonte: FUMEC, 2008. Dissertação (Mestrado em Administração), Faculdade de Ciências Empresariais,Universidade Fundação Mineira de Educação e Cultura, 2008. 19

×