CoordenaÃÃo de AperfeiÃoamento de Pessoal de NÃvel Superior / Uma Linha de Produto de Software SensÃvel ao Contexto (LPSSC) à uma linha de produto para o desenvolvimento de aplicaÃÃes sensÃveis ao contexto, que alteram dinamicamente o comportamento ou que proveem serviÃos com base em informaÃÃes de contexto. Nesse cenÃrio, a atividade de testes precisa lidar ao mesmo tempo com as peculiaridades das aplicaÃÃes finais, que sÃo sensÃveis ao contexto, e com o paradigma de desenvolvimento em linha de produto. Mediante a complexidade envolvida nos testes de uma LPSSC, à fundamental a existÃncia de mÃtodos ou ferramentas de suporte a essa atividade, especialmente com a intenÃÃo de criar testes a partir dos requisitos da linha. O objetivo dessa geraÃÃo precoce dos testes à permitir a identificaÃÃo e correÃÃo dos defeitos nos estÃgios iniciais de desenvolvimento. Dessa forma, esta dissertaÃÃo tem por objetivo propor um ambiente de geraÃÃo de cenÃrios de testes para uma LPSSC que utiliza especificaÃÃes textuais de casos de uso com informaÃÃes de contexto e que possibilita a reutilizaÃÃo dos testes. Este ambiente à constituÃdo pela proposta de um mÃtodo de geraÃÃo de cenÃrios de testes, de um template para especificaÃÃo textual de casos de uso de uma LPSSC e de uma ferramenta de apoio. O mÃtodo utiliza como base especificaÃÃes textuais de casos de uso com informaÃÃes sobre: funcionalidade, variabilidade da linha, e como o contexto afeta os produtos finais. O ambiente tambÃm contÃm o template para caso de uso que fornece suporte ao uso do mÃtodo e a ferramenta de apoio, que permite a modelagem de casos de uso segundo esse template e implementa o mÃtodo proposto. Com a intenÃÃo de verificar os benefÃcios do ambiente, proposto nesta dissertaÃÃo, quanto a geraÃÃo de cenÃrios de testes para uma LPSSC, conduziu-se uma avaliaÃÃo preliminar na forma de experimento controlado. Baseado nos resultados coletados nessa avaliaÃÃo percebeu-se que: o template favorece o entendimento de um caso de uso de uma LPSSC; o mÃtodo favorece a criaÃÃo de um conjunto de testes com uma maior cobertura para uma LPSSC, se comparado a criaÃÃo de testes de forma nÃo sistemÃtica; e a ferramenta representa um suporte necessÃrio. / A Context-Aware Software Product Line (CASPL) is a product line for developing context-aware applications, which dynamically change their behavior or provide services based on context information. With this kind of line, the productivity can be increased and the development costs of the context-aware application can be cut down. In this scenario, the testing activity needs to deal with the peculiarities of both context-aware applications and the product line development paradigm. Through the complexity involved in testing a CASPL is essential to have methods or tools for supporting this activity, especially with the goal of creating tests from requirements. The aim of this early testing generation is to identify and fix the defects in the early stages of development. Therefore, this work aims to propose an environment for generating test scenarios for a CASPL that takes into account the presence of context information and seeks to maximize the testing reuse. This environment consists of a testing scenario generation method, a template for textual use case specification and a support tool. The method uses as input textual use cases especifications with information about: funcionality, variability, and how the context afect the final products. The environment also has a use case template that supports the use of the method and a tool support, which allows the modeling of use cases according to this template and implements the proposed method. In order to verify the benefits of the environment as a way to testing generation for a Context-Aware Software Product Line, an assessment in the form of controlled experiment is conducted. Based on the collected results, it is observed that: the use of the template makes easy the understanding of a Context-Aware Software Product Line use case; the method favors the creation of a set of tests with higher coverage than a non-systematic testing generation; and the tool is the necessary support for the method

Submitted by Nayara Passos (nayara.passos@ufpe.br) on 2015-03-10T13:51:24Z No. of bitstreams: 2 DISSERTAÇÃO Jean Carlos de Carvalho Melo.pdf: 1961390 bytes, checksum: d66fd564809f98e0c5bd50687923f9e0 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-10T13:51:24Z (GMT). No. of bitstreams: 2 DISSERTAÇÃO Jean Carlos de Carvalho Melo.pdf: 1961390 bytes, checksum: d66fd564809f98e0c5bd50687923f9e0 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2014 / INES, CNPq / Diante do ambiente complexo e dinâmico encontrado nas empresas atualmente, o sistema tradicional de Workflow não está sendo flexível suficiente para modelar Processos de Negócio. Nesse contexto, surgiram os Processos Flexíveis que tem por principal objetivo suprir a necessidade de modelar processos menos estáticos. Processo declarativo é um tipo de processo flexível que permite os participantes decidirem a ordem em que as atividades são executadas através de regras de negócio. As regras de negócio determinam as restrições e obrigações que devem ser satisfeitas durante a execução. Tais regras descrevem o que deve ou não deve ser feito durante a execução do processo, mas não definem como. Os métodos e ferramentas atualmente disponíveis para modelar e executar processos declarativos apresentam várias limitações que prejudicam a sua utilização para este fim. Em particular, a abordagem que emprega lógica temporal linear (LTL) sofre do problema de explosão de estados a medida que o tamanho do modelo do processo cresce. Embora mecanismos eficientes em relação a memória terem surgido, eles não são capazes de adequadamente garantir a conclusão correta do processo, uma vez que permitem o usuário alcançar estados proibidos ou que causem deadlock. Além disso, as implementações atuais de ferramentas para execução de processos declarativos se concentram apenas em atividades manuais. Comunicação automática com aplicações externas para troca de dados e reutilização de funcionalidade não é suportado. Essas oportunidades de automação poderiam ser melhor exploradas por uma engine declarativa que se integra com tecnologias SOC existentes. Este trabalho propõe uma nova engine de regras baseada em grafo, chamado de REFlex. Tal engine não compartilha os problemas apresentados pelas abordagens disponíveis, sendo mais adequada para modelar processos de negócio declarativos. Além disso, REFlex preenche a lacuna entre os processos declarativos e SOC. O orquestrador REFlex é um orquestrador de serviços declarativo, eficiente e dependente de dados. Ele permite que os participantes chamem serviços externos para executar tarefas automatizadas. Diferente dos trabalhos relacionados, o algoritmo de REFlex não depende da geração de todos os estados alcançáveis, o que o torna adequado para modelar processos de negócios grandes e complexos. Além disso, REFlex suporta regras de negócio dependentes de dados, o que proporciona sensibilidade ao contexto. / Declarative business process modeling is a flexible approach to business process management in which participants can decide the order in which activities are performed. Business rules are employed to determine restrictions and obligations that must be satisfied during execution time. Such business rules describe what must or must not be done during the process execution, but do not prescribe how. In this way, complex control-flows are simplified and participants have more flexibility to handle unpredicted situations. The methods and tools currently available to model and execute declarative processes present several limitations that impair their use to this application. In particular, the well-known approach that employs Linear Temporal Logic (LTL) has the drawback of the state space explosion as the size of the process model grows. Although approaches proposing memory efficient methods have been proposed in the literature, they are not able to properly guarantee the correct termination of the process, since they allow the user to reach deadlock states. Moreover, current implementations of declarative business process engines focus only on manual activities. Automatic communication with external applications to exchange data and reuse functionality is barely supported. Such automation opportunities could be better exploited by a declarative engine that integrates with existing SOC technologies. This work proposes a novel graph-based rule engine called REFlex that does not share the problems presented by other engines, being better suited to model declarative business processes than the techniques currently in use. Additionally, such engine fills this gap between declarative processes and SOC. The REFlex orchestrator is an efficient, data-aware declarative web services orchestrator. It enables participants to call external web services to perform automated tasks. Different from related work, the REFlex algorithm does not depend on the generation of all reachable states, which makes it well suited to model large and complex business processes. Moreover, REFlex is capable of modeling data-dependent business rules, which provides unprecedented context awareness and modeling power to the declarative paradigm.

Made available in DSpace on 2014-06-12T15:51:39Z (GMT). No. of bitstreams: 2 arquivo1682_1.pdf: 1782765 bytes, checksum: f72b8949fcd20828665cc0a45ca4034d (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2008 / Dentro da comunidade de desenvolvimento de software, o processo de reutilizar artefatos ao invés de construí-los do zero normalmente conhecido como reuso de software tem se mostrado uma maneira efetiva de evitar os problemas associados ao estouro de orçamentos e cronogramas de projeto. Apesar do imenso potencial, a adoção de reuso em larga escala ainda não prevalece dentro das organizações. Entre os fatores que contribuem para isso, estão os obstáculos econômicos enfrentados pelas empresas, com uma clara preocupação sobre os custos para desenvolver software para e com reuso. Atualmente, as decisões relacionadas com reuso são tratadas sob um ponto de vista econômico, devido ao fato do desenvolvimento de software reutilizável ser considerado pelas organizações como um investimento. Além disso, a adoção de linhas de produto de software dentro desse contexto traz à tona alguns inibidores de reuso, como por exemplo, a aplicação dos modelos de custo para reuso de forma restrita, a falta de uma estratégia para a análise de investimentos, e o fato que poucos modelos de custo possuem uma abordagem baseada na utilização de cenários de reuso. Nesse contexto, esse trabalho apresenta um modelo integrado de custo para engenharia de linhas de produto, com o objetivo de auxiliar as organizações em seus processos de tomada de decisões na avaliação de investimentos em reuso. Os fundamentos para o modelo foram baseados em uma vasta pesquisa sobre modelos de custo para reuso e sua especialização para linhas de produto de software. O modelo apresenta a definição de funções de custo e benefícios, cenários de reuso e uma estratégia de investimento para linhas de produto. Também é apresentado um modelo de simulação baseado na técnica de Monte Carlo. Por último, um estudo de caso discute os resultados de dentro do contexto de um projeto real de desenvolvimento de software, onde o modelo foi aplicado

Made available in DSpace on 2014-06-12T15:51:50Z (GMT). No. of bitstreams: 1 license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2008 / Os mais almejados objetivos da engenharia de software são basicamente alta produtividade, com alta qualidade a um baixo custo e uma possível forma de atingi-los é estabelecer reuso de software o processo de criar sistemas de software a partir de sistemas existentes ao invés de criar do início. Neste contexto, uma abordagem que pode habilitar reuso na prática é Linha de Produto de Software (LPS) um conjunto de sistemas de software que compartilham um conjunto comum e gerenciado de funcionalidades que satisfazem uma necessidade específica de um domínio, e que são desenvolvidas a partir de um conjunto de artefatos reusáveis. Um domínio em particular onde a adoção de tal abordagem pode trazer benefícios é o domínio de jogos móveis principalmente porque os jogos precisam executar em diversos dispositivos e existe uma grande quantidade de jogos do mesmo tipo sendo desenvolvidos com funcionalidades em comum. Entretanto, as características do domínio de jogos móveis geralmente criam barreiras para os processos de LPS na prática, tais como, restrições de memória e de tamanho da aplicação e diferentes implementações de API feitas por diferentes fabricantes. Além disso, os atuais processos de LPS ainda carecem de detalhes em fases relacionadas à implementação de artefatos reusáveis, dificultando a administração apropriada das características mencionadas. Dessa forma, este trabalho objetiva definir uma abordagem prática para implementação de artefatos reusáveis em uma LPS para o domínio de jogos móveis com base nas boas práticas do estado da arte na área. Além disso, com a intenção de avaliar a abordagem, um estudo experimental foi executado com três jogos de plataforma para construir a LPS e um quarto jogo foi derivado dela

Made available in DSpace on 2014-06-12T15:54:05Z (GMT). No. of bitstreams: 2 arquivo6551_1.pdf: 2254714 bytes, checksum: 89a6702d1c801f178299f95585aac5ab (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2007 / Linha de Produtos de Software (LPS) é uma aborgadem promissora para o desenvolvimento de um conjunto de produtos focados em um segmento de mercado e desenvolvidos a partir de um conjunto comum de artefatos. Possíveis benefícios incluem reuso em larga escala e significativa melhoria em produtividade. Um problema-chave associado, no entanto, é o tratamento de estratégias de implantação, em que uma organização decide iniciar uma LPS a partir do zero, fazer bootstrap de produtos existentes em uma LPS, ou evoluir uma LPS. Em particular, no nível de implementação e de modelo de features, métodos de desenvolvimento carecem de apoio adequado para extração e evolução de LPSs. Neste contexto, apresentamos um m´etodo original provendo diretrizes concretas para extração e evolução de LPSs no nível de implementação e de modelo de features, nos quais proporciona reuso e segurança. O método primeiro faz o bootstrap da LPS e então a evolui com uma abordagem reativa. O método se baseia em uma coleção de refatoramentos tanto na implementação (refatoramentos orientados a aspectos) como no modelo de features. O método foi avaliado no domínio altamente variável de jogos móveis

Made available in DSpace on 2014-06-12T15:58:03Z (GMT). No. of bitstreams: 2 arquivo3244_1.pdf: 2061206 bytes, checksum: d9bbab1debda0a2122b877cceb8484ed (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2010 / Conselho Nacional de Desenvolvimento Científico e Tecnológico / O reuso de software é um fator extremamente importante para empresas interessadas em aumentar sua produtividade, diminuir os custos e o tempo durante o desenvolvimento de sistemas e melhorar a qualidade de seus produtos e serviços. Nesse contexto, Linhas de Produto de Software (LPS) e Arquitetura Orientada a Serviços (SOA) são duas estratégias que estão atualmente recebendo uma grande atenção, tanto na área acadêmica quanto na indústria de software. Os conceitos de linhas de produto e arquitetura orientada a serviços compartilham alguns objetivos e características que podem ser usados em conjunto para aumentar as taxas de reuso de software. No entanto, para o resultado dessa junção ser otimizado, é necessário utilizar um processo de desenvolvimento bem definido. Caso contrário, a equipe de desenvolvimento poderá produzir software de maneira não sistemática, aumentando as chances de falha, o tempo e o custo de desenvolvimento. Com essa visão, esse trabalho apresenta uma abordagem para o projeto de arquiteturas para linhas de produto orientada a serviços, constituída de um conjunto de atividades e sub atividades com entradas e saídas especificadas, sendo cada uma delas realizada por um conjunto predefinido de papéis com responsabilidades definidas. Essa abordagem visa ajudar arquitetos de software a projetar arquitetura orientada a serviços para domínios específicos. Para garantir a qualidade da abordagem desenvolvida, uma pesquisa extensiva foi realizada para analisar o atual estado da arte de processos para o desenvolvimento orientado a serviços. Foram então considerados os pontos fracos e fortes dos processos estudados com o intuito de identificar e preencher as lacunas neles existentes. Por fim, essa abordagem foi validada e refinada por meio de um estudo acadêmico experimental preliminar

Made available in DSpace on 2014-06-12T15:58:08Z (GMT). No. of bitstreams: 2 arquivo3259_1.pdf: 5762420 bytes, checksum: 0af73887e3af768529c1569155447ba5 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / FUNDAÇÃO DE APOIO AO DESENVOLVIMENTO DA UFPE / Linhas de Produtos de Software (LPS) são definidas como conjuntos de sistemas de software que atendem a um mercado especifico, que compartilham caracteristicas em comum, porem sendo suficientemente distintos entre si, e que são desenvolvidos a partir de um conjunto de artefatos reusaveis. Entre os beneficios possiveis com a implantação de LPS podemos citar o reuso em larga escala e o aumento de produtividade. Um fator-chave no desenvolvimento de uma LPS e o mecanismo utilizado para a estruturação fonte. Uma das tecnicas mais comumente utilizadas para a estruturação de variações de código e a compilação condicional, tambem chamada de pre-processamento. Apesar de ser amplamente utilizada, o uso de compilação condicional incorre em problemas de legibilidade, modularidade, manutenibilidade e qualidade. Programação Orientada a Aspectos (POA) e uma alternativa a compilação condicional para a estruturação de variações de codigo em LPS, podendo apresentar melhor legibilidade, modularidade, manutenibilidade, qualidade, entre outros fatores, do que a compilação condicional. Entretanto, o uso de AspectJ, implementação mais popular de POA sobre a linguagem Java, como mecanismo de estruturação de variações gera um overhead (aumento) sobre o tamanho final do codigo compilado. No contexto de LPS de sistemas para plataformas em dispositivos moveis, em plataformas como Java ME, que possuem restrições de memoria, esse overhead pode tornar inviavel o uso do produto final. Neste trabalho, analisamos o impacto do uso de AspectJ como mecanismo de estruturação de variações sobre o tamanho do codigo compilado e investigamos os motivos por tras deste aumento. Para tal, utilizamos o BestLap e o Juggling, duas LPS de jogos para dispositivos Java ME que possuem uma versão puramente pre-processada e uma versão hibrida, que utiliza pre-processamento e AspectJ. Utilizamos o BestLap na analise de tamanho para quanticar o overhead com dois compiladores AspectJ, o ajc e o abc. Em seguida, analisamos o codigo compilado de um subconjunto das construções As pectJ, a fim de identificar quais construções geram overhead no tamanho do codigo compilado e os motivos por tras deste overhead. Esse subconjunto consistiu de todas as construções AspectJ utilizadas na versão híbrida do BestLap e do Juggling, o ultimo utilizado apenas para a elicitação das construções analisadas. Com base nessa investigação, desenvolvemos quatro otimizações para o compilador abc que modificam o codigo compilado de certas construções visando a eliminar o overhead. Apresentamos detalhes da implementação e discutimos as pre-condições e a corretude das otimizações desenvolvidas. Em seguida, apresentamos o resultado da aplicação destas otimizações em duas LPS e discutimos como implementações diferentes, porem equivalentes, da mesma variação em AspectJ podem inviabilizar a aplicação das otimizações Por fim, para garantir que as modificações realizadas pelas otimizações não prejudiquem o desempenho, apresentamos o resultado de testes de desempenho realizados em programas AspectJ usados em benchmarks apos a aplicação das nossas otimizações

Made available in DSpace on 2014-06-12T15:58:11Z (GMT). No. of bitstreams: 2 arquivo3303_1.pdf: 1930482 bytes, checksum: 5203b90b2f2248bb0739907c03b9a717 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2010 / Reúso de software é uma forma viável de obter ganhos de produtividade e melhoria no timeto- market tão desejados pelas empresas. O reúso não sistemático (Ad hoc) pode ser prejudicial, uma vez que a reutilização de artefatos de baixa qualidade pode diminuir a qualidade dos produtos finais. O reúso sistemático através da adoção de Linhas de Produto de Software (LPS) é uma boa alternativa para alcançar metas de qualidade e de redução de custos. Essa abordagem se tornou uma solução efetiva para gerar vantagem competitiva para as empresas. Arquiteturas de linhas de produto devem se beneficiar das comunalidades entre os produtos e possibilitar a variabilidade entre eles. Ao mesmo tempo, como uma arquitetura de software, precisa atender requisitos de atributos de qualidade. O desafio de atender atributos de qualidade em sistemas únicos (single systems) torna-se ainda mais complicada no contexto de linhas de produto porque a variabilidade pode ocorrer também nos atributos de qualidade. A variabilidade em atributos de qualidade é uma questão complexa. Entretanto, ela tem sido negligenciada ou ignorada pela maioria dos pesquisadores, uma vez que as atenções têm se mantido no alcance da variabilidade funcional. O foco deste trabalho é definir um processo para o design de arquiteturas de linhas de produto de software que possa lidar de forma eficaz com variabilidade em atributos de qualidade. O processo aprimora o RiPLE-Design com atividades e guias para o design com variabilidade de atributos de qualidade. Por fim, um estudo experimental é apresentado com o intuito de caracterizar e avaliar as melhorias propostas ao processo

Made available in DSpace on 2014-06-12T16:00:54Z (GMT). No. of bitstreams: 2 arquivo7075_1.pdf: 5003439 bytes, checksum: 070d65264679c7bfd03fc912be7cc61f (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / A indústria de software tem sido cada vez mais desafiada a melhorar suas praticas de engenharia com o objetivo de oferecer produtos de forma mais rápida e confiável. Assim, as práticas de desenvolvimento de software sofreram significativas mudanças nos últimos anos, uma vez que novas e acessíveis estratégias tem sido aplicadas de forma a alcançar tal desafio. Neste contexto, Engenharia de Linhas de Produto de Software surgiu como uma estratégia de engenharia de software destinada a fornecer à indústria oportunidades para alcançar os objetivos de negócio acima mencionados. No entanto, para garantir o retorno do investimento com uma abordagem de Linhas de Produto de Software, um processo de derivação de produtos bem definido é muito importante. Sem esse processo, os produtos podem ser instanciados de maneira não sistemática, aumentando o tempo e o custo de produção. Por outro lado, mesmo com esta relevância, quando comparado com a grande quantidade de pesquisas em desenvolvimento sobre linhas de produtos, relativamente poucos trabalhos tem sido dedicados ao processo de Derivação de Produtos. Alêm disso, ainda existem poucos relatórios disponíveis sobre como as organizações de desenvolvimento de software derivam seus produtos a partir de uma linha de produtos, e, em geral, os existentes têm sido realizados como estudos informais, sem rigor científico suficiente, tornando difícil a sua repetição e validação. Assim, esta dissertação tem como objetivo obter uma melhor compreensão sobre como derivação do produto é realizada e quais práticas são utilizadas na indústria. Reunimos descobertas através de dois estudos de caso realizados na indústria. Alem disso, as evidências obtidas a partir dos estudos de caso, foram comparados entre os casos através da análise Cross-case, com o objetivo de identificar padrões entre eles. A definição do estudo e relatório foram estruturados com base nas diretrizes consolidadas para estudos empíricos de acordo com orientações bem definidas, o que permite a replicação dos estudos e extensão

Made available in DSpace on 2014-06-12T16:01:25Z (GMT). No. of bitstreams: 2 arquivo8976_1.pdf: 2350079 bytes, checksum: 1eef40b33c036ecc8b5b613b08bff0a7 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / Engenharia de Linhas de Produto de Software (ELPS) emergiu rapidamente como uma importante abordagem de desenvolvimento de software durantes os últimos anos. ELPS foca-se na identificação e gerenciamento dos pontos em comum (commonalities) e dos pontos de variação (variabilities) de um conjunto de produtos de software, de forma que artefatos (core assets) possam ser desenvolvidos e (re)usados para construir diferentes produtos com custo reduzido. Além disso, melhoria de produtividade, aumento de qualidade e redução do tempo de entrega dos produtos são alguns dos benefícios proporcionados pela abordagem. Neste contexto, o processo de escopo em linhas de produto de software é responsável pela definição da viabilidade a longo prazo da linha de produtos. Seu principal objetivo é identificar e delimitar produtos, funcionalidades, subdomínios e artefatos (componentes, documentos, etc.) existentes da linha de produtos, onde o investimento em reuso trará benefícios econômicos para a empresa. Normalmente, engenheiros de linha de produtos definem o escopo com informações extraídas da documentação de produtos existentes e baseados no conhecimento de especialistas de domínio. Esta é uma tarefa que demanda muito esforço, pois muito tempo é investido na realização de workshops e entrevistas com os especialistas de domínio. Além disso, frequentemente, os especialistas de domínio não tem tempo disponível para compartilhar o conhecimento deles e a documentação dos produtos existentes é inexistente ou está desatualizada. Assim, a fim de reduzir custos e tempo para a realização do processo de escopo, esta dissertação propõe uma abordagem para auxiliar o processo de escopo baseada no código fonte dos produtos já existentes na empresa. Além disso, são apresentados os requisitos, projeto e implementação de uma ferramenta com o objetivo de guiar os analistas de escopo na identificação de similaridades e variações no código fonte dos sistemas legados. Finalmente, esta dissertação também descreve um estudo empírico que foi utilizado para a elicitação de requisitos e um experimento que foi conduzido para avaliar a viabilidade da ferramenta proposta neste trabalho