Submitted by Marcos Samuel (msamjunior@gmail.com) on 2016-05-31T19:04:11Z No. of bitstreams: 1 PGCOMP_MSC_RodrigoMagnavita_FINAL.pdf: 9354124 bytes, checksum: 42f5519b009b4ce381de2026ab458434 (MD5) / Approved for entry into archive by Alda Lima da Silva (sivalda@ufba.br) on 2016-06-03T23:40:14Z (GMT) No. of bitstreams: 1 PGCOMP_MSC_RodrigoMagnavita_FINAL.pdf: 9354124 bytes, checksum: 42f5519b009b4ce381de2026ab458434 (MD5) / Made available in DSpace on 2016-06-03T23:40:14Z (GMT). No. of bitstreams: 1 PGCOMP_MSC_RodrigoMagnavita_FINAL.pdf: 9354124 bytes, checksum: 42f5519b009b4ce381de2026ab458434 (MD5) / A evolução do software produz uma grande quantidade de dados durante os ciclos de desenvolvimento. Engenheiros de software precisam interpretar esses dados para extrair informações que os auxiliarão na execução de suas atividades diárias. O uso de Visualização de Evolução de Software (VES) tem sido uma abordagem promissora para auxiliar nessa interpretação. Essa abordagem faz uso de recursos visuais que facilitam a interpretação desses dados. Ainda assim, não é trivial representar visualmente todos os dados gerados durante a evolução do software, pois além do software possuir diferentes entidades e atributos, ainda é necessário lidar com a dimensão temporal da evolução. As VES geralmente são construídas com objetivo de auxiliar na execução de atividades relacionadas a um domínio específico da engenharia de software. Muitas dessas visualizações focam apenas em apresentar uma visão geral da evolução do software, sem focar nos detalhes. Entretanto, a maioria das atividades de desenvolvimento de software requer tanto combinar diferentes domínios quanto ter uma visão detalhada das informações. As metáforas visuais (i.e., conceitos, associações e analogias a entidades concretas) utilizadas nessas visualizações, são muito específicas, objetivando auxiliar apenas um determinado domínio. O uso de múltiplas visões do software para construir o modelo mental do sistema vem sendo apontado como uma abordagem efetiva para o completo entendimento do mesmo. Na maioria dos casos, essas visualizações possuem conjuntos de metáforas visuais. Devido a isso, surge uma necessidade do engenheiro de software compreender e se familiarizar com as metáforas visuais de cada uma das visualizações durante a utilização das mesmas. Uma das formas de mitigar esse problema é usar visualizações que possuem uma única metáfora visual para visualizar diversos aspectos e perspectivas do software. Esta dissertação apresenta uma nova metáfora visual, chamada EVOWAVE, capaz de ser utilizada em múltiplos domínios e que permite visualizar os dados de forma global e detalhada. A EVOWAVE é inspirada em ondas concêntricas enquanto observadas de cima. Essa metáfora consegue representar grandes quantidades de dados e seus conceitos são transversais a domínios na área de engenharia de software. O desenvolvimento desta metáfora passou por fases iterativas que refinaram os conceitos associados a ela. Primeiramente foi desenvolvido um protótipo que validou a capacidade da metáfora de representar grandes quantidades de dados. Em seguida, foram realizados estudos para validar a capacidade de representar dados de diferentes domínios. Os resultados indicam que a metáfora proposta pode ser utilizada de forma efetiva em diferentes domínios da área de engenharia de software para auxiliar na execução de atividades de manutenção e evolução.

Manter os documentos de requisitos atualizados e recuperar os requisitos de um software são desafios enfrentados por desenvolvedores no seu dia a dia durante o desenvolvimento, a manutenção e a evolução de sistemas. Embora existam técnicas para gestão de requisitos, muitas vezes estas técnicas não são aplicadas, os requisitos não são atualizados e a única fonte de informação confiável sobre um software passa a ser seu código-fonte. Esta tese apresenta a TDRRC, uma técnica para a documentação e recuperação dos requisitos no código-fonte usando anotações. A TDRRC possibilita a reengenharia de requisitos sem que haja uma interrupção no desenvolvimento e permite que os requisitos sejam documentados em ambientes de desenvolvimento ágil. A TDRRC contribui para a redução dos problemas relacionados à atualização dos requisitos, pois o desenvolvedor responsável pelo programa passa a ser responsável pela documentação e atualização dos requisitos no código-fonte que ele escreve e mantém. Este trabalho apresenta também formas de aplicar a TDRRC na reengenharia de requisitos, em métodos ágeis e na gestão de requisitos, assim como a sua aplicação em um estudo de caso. / Keeping requirements documents updated and recovering requirements of a software are common challenges faced by developers on their day to day activities. Although there are many requirements management techniques, usually these techniques are not applied, requirements are not updated and the only reliable source of information about a software becomes its source code. This thesis presents TDRRC, a technique that can be used to document and retrieve requirements from the source code using annotations. Applying TDRRC, it is possible to reengineer the requirements of a software without interrupting its development. Also requirements can be documented in a agile environment. TDRRC also contributes to minimize requirements documents update issues as the developer will be clearly responsible for documenting and updating the requirements in the source code he is programming. This thesis also presents how to apply the technique in a requirement reengineering project, in a agile development environment and in a requirements management process. Finally a case study is presented.

Submitted by Kleber Silva (kleberbs@ufba.br) on 2016-05-31T18:36:48Z No. of bitstreams: 1 Dissertação de mestrado - Michelle Larissa.pdf: 7097555 bytes, checksum: 12c156cd6d3326533130fa7d2b9d09e3 (MD5) / Approved for entry into archive by Alda Lima da Silva (sivalda@ufba.br) on 2016-06-03T23:41:05Z (GMT) No. of bitstreams: 1 Dissertação de mestrado - Michelle Larissa.pdf: 7097555 bytes, checksum: 12c156cd6d3326533130fa7d2b9d09e3 (MD5) / Made available in DSpace on 2016-06-03T23:41:06Z (GMT). No. of bitstreams: 1 Dissertação de mestrado - Michelle Larissa.pdf: 7097555 bytes, checksum: 12c156cd6d3326533130fa7d2b9d09e3 (MD5) / A abordagem de Linhas de Produto de Software (LPS) consiste em um paradigma de engenharia de software emergente para promover reuso através do ciclo de vida de software. LPS permitem que as empresas de desenvolvimento supram a grande demanda de sistemas de software usando plataformas e customização em massa. O desenvolvimento de LPS, entretanto, precisa ser adaptado aos novos requisitos, tendo em conta o surgimento de novas tecnologias e serviços. Estas novas tendências de mercado requerem que LPS tornem-se mais evolutivas e adaptáveis. Mais recentemente, a abordagem de Linhas de Produto de Software Dinâmicas (LPSD) surgiu como um meio promissor para desenvolver LPS que incorporam artefatos reusveis e dinamicamente reconfiguráveis. LPSD adaptam seu comportamento quando a variabilidade é alcançada em tempo de execução. A abordagem de reconfiguração dinâmica usa o mapeamento de funcionalidades para os componentes que normalmente são tratadas na implementação. Assim, a seleção de mecanismos que oferecem suporte as decisões de tempo de execução consiste em uma atividade importante. Embora a literatura apresente alguns estudos de implementação nesse contexto, falta a caracterização de mecanismos de acordo com os requisitos de LPSD. De fato, os desenvolvedores precisam contar com um conjunto de mecanismos para lidar com a variabilidade dinâmica. Ademais, as pesquisas existentes começaram recentemente a investigar a necessidade de continuamente evoluir LPSD. No entanto, o foco consiste em discutir modelos de variabilidade. Além disso, no foram realizados estudos empíricos para avaliar quantitativamente o impacto de diferentes paradigmas na implementação de evolução de LPSD. A fim de entender e reduzir as questões mencionadas, nos investigamos as áreas de LPS e LPSD para identificar quais mecanismos de implementação têm sido abordados para gerenciar a variabilidade dinâmica. Neste sentido, um conjunto de critérios foi desenvolvido visando caracterizar esses mecanismos e auxiliar os desenvolvedores na etapa inicial do desenvolvimento de LPSD. Além disso, foi realizado um estudo exploratório no domínio de casas inteligentes com o objetivo de comparar as soluções orientadas a objetos e aspectos para a implementação de evolução de LPSD.

Submitted by Daniella Sodre (daniella.sodre@ufpe.br) on 2015-03-09T12:50:30Z No. of bitstreams: 2 Dissertacao Antonio Cavalcanti.pdf: 1847589 bytes, checksum: d68a6d0a8cf07180e223791edb011bfb (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-09T12:50:30Z (GMT). No. of bitstreams: 2 Dissertacao Antonio Cavalcanti.pdf: 1847589 bytes, checksum: d68a6d0a8cf07180e223791edb011bfb (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2012-11-01 / É amplamente aceito que o custo de manutenção de um software representa mais de 90% do custo total do produto durante todo seu ciclo de vida. O custo de desenvolvimento do produto tende a se tornar insignificante principalmente em softwares com longos ciclos de vida. Softwares perdem sua importância e tendem a cair em desuso caso não sejam evoluídos. Naturalmente, durante esse processo de evolução diversas forças externas e internas corroboram para o decaimento da qualidade do código fonte do software, como por exemplo, pressões do mercado, diminuição dos orçamentos para manutenção, mudanças no time de desenvolvedores, dentre outros. Apesar de existirem técnicas para acompanhar a qualidade do código fonte de um software utilizando-­‐se métricas, nenhuma leva em consideração o contexto e decisões tomadas que levaram à diminuição da qualidade se tornando então técnicas reativas. Para explicar esse decaimento de qualidade, inserir informações contextuais sobre as decisões tomadas, permitir planejamento preventivo e acompanhar o aumento dos custos de manutenção em softwares com código fonte já comprometido, é utilizada a metáfora de Dívida Técnica. A metáfora de Dívida Técnica é uma analogia ao conceito de empréstimo financeiro. Ao comprometer a qualidade do código fonte do sistema em detrimento a algum benefício imediato, contrai-­‐se uma dívida onde o valor do empréstimo é o esforço economizado na execução da tarefa. Como toda dívida, são aplicados juros sobre o empréstimo contraído e se a dívida não for adequadamente controlado, no futuro a maior parte do esforço de manutenção e evolução será gasto amortizando os custos da dívida. Apesar de intuitiva, muito popular na comunidade de profissionais de software e útil para diminuir a distância entre o vocabulário técnico e o gerencial, a metáfora tem sua definição em evidências anedóticas, por isso se faz necessário estudos que possam descrever o fenômeno com rigor científico. Nesse contexto, o objetivo desse estudo é caracterizar a metáfora de Dívida Técnica sob a ótica de métricas de software, descrevendo relações existentes entre as tomadas de decisões e os impactos causados na qualidade, utilizando-­‐se de suítes clássicas de métricas, fundamentado em 7 anos de dados históricos de projetos reais e companhamento por 8 meses de um projeto vivo.

Made available in DSpace on 2014-06-12T15:58:29Z (GMT). No. of bitstreams: 2 arquivo4584_1.pdf: 1969312 bytes, checksum: ebc699427e4ae5f379c7d0e4b5d9b28f (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2004 / Os dispositivos computacionais estão se tornando ubíquos. Com um celular, atualmente, podemos acessar e manipular informação praticamente em qualquer lugar e a qualquer instante. Neste cenário de computação ubíqua, tem-se exigido que tais sistemas sejam adaptativos, ou seja, tenham a capacidade de se adaptar em decorrência de mudanças no contexto em que estão inseridos. É importante destacar, porém, que a adaptabilidade adiciona certa complexidade ao desenvolvimento de aplicações. Um dos problemas é que a implementação de comportamentos adaptativos em muitos casos se entrelaça com outras preocupações da aplicação, como apresentação, negócio e dados, levando a problemas de legibilidade que podem prejudicar a manutenabilidade do código. A programação orientada a aspectos pode ser usada para facilitar a resolução de problemas relacionados a código entrela¸cado, e dar suporte ao desenvolvimento de programas adaptativos, e ao mesmo tempo adaptáveis (fáceis de modificar) com bons níveis de qualidade e produtividade. Essa dissertação mostra como podemos usar aspectos, em especial em AspectJ, para estruturar aplicações adaptativas, minimizando dessa forma o entrelaçamento de código. AspectJ é uma linguagem orientada a aspectos, de propósito geral, e que estende a linguagem Java. Ela é voltada `a separação de preocupações. Em nosso trabalho ela é utilizada para promover a separação da preocupação adaptabilidade , obtendo-se assim uma implementação modular. Através do uso dessa linguagem, identificamos boas práticas para a estruturação de aplicações adaptativas, as quais foram resumidas em um padrão denominado Adaptability Aspects. Escolhemos a plataforma Java 2 Micro Edition para implementar várias preocupações relativas a adaptabilidade, principalmente pelo fato de ser uma tecnologia destinada a dispositivos ubíquos e com recursos limitados. Al´em de AspectJ, analisamos também uma outra abordagem para a estruturação de aplicações adaptativas: o uso do estilo arquitetural denominado Adaptive Object- Models . Verificamos a partir dessa análise que ele poderia ser combinado com o nosso padrão, e portanto, beneficiar-se com o uso de aspectos. Dessa forma, poderia-se oferecer suporte a um conjunto maior de adaptações e ao mesmo tempo obter-se uma estrutura ção no código mais fácil de compreender. Por fim, avaliamos o impacto de AspectJ, através do uso do padrão Adaptability Aspects, para implementar alguns requisitos de adaptabilidade em aplicações J2ME. Comparamos nossa implementação com uma solução em que a implementação destes requisitos não é tão modular e com uma outra solução utilizando padrões de projeto puramente orientados a objeto na qual se buscava tal modularidade. Alguns dos aspectos comparados foram tempo de execução, memória utilizada, tamanho da aplicação e de seu código. Além de medir tais fatores, descrevemos os ganhos que a programação orientada a aspectos pode trazer para a estruturação de aplicações adaptativas visando obter qualidade em termos de reuso e facilidade de manutenção

Made available in DSpace on 2014-06-12T16:00:37Z (GMT). No. of bitstreams: 2 arquivo6829_1.pdf: 1884179 bytes, checksum: 1e016f27d861e97c8023a4443fecc151 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / A metáfora de Débito Técnico é uma analogia ao conceito de débito financeiro. A metáfora afirma que ao comprometer a qualidade do sistema em detrimento a algum outro benefício, é como se estivesse contraindo uma dívida. A essa dívida são acrescidos juros na forma de custos extras para realizar futuras modificações no sistema. Se o débito não for controlado, a maior parte do tempo de desenvolvimento futuro do sistema pode ser gasto com o pagamento da dívida. A metáfora tem sido usada na comunidade técnica como uma forma de gerenciar e comunicar as consequências em longo prazo que decisões técnicas podem causar. Apesar de intuitiva, essa definição é baseada em evidencias anedótica, por isso um melhor entendimento do fenômeno e uma definição com rigor formal são necessários. Nesse contexto, esta pesquisa tem como objetivo principal caracterizar e conceituar teoricamente um caso de Débito Técnico em um contexto real de desenvolvimento de software para dispositivos móveis. Através de um estudo de caso exploratório foi realizada a caracterização em números concretos do impacto causado pela contração do débito e a identificação de categorias, subcategorias e propriedades que definem o fenômeno de Débito Técnico, utilizando procedimentos da metodologia da Teoria Fundamentada nos Dados. Esse trabalho dá um primeiro passo na construção de uma teoria formal sobre Débito Técnico e possibilita à comunidade cientifica direcionar os esforços futuros para caracterização e gerenciamento de Débito Técnico, de acordo com os conceitos aqui identificados. O trabalho também contribui para o projeto investigado com proposições para o gerenciamento do projeto no futuro

Made available in DSpace on 2014-06-12T16:00:39Z (GMT). No. of bitstreams: 2 arquivo6836_1.pdf: 7134549 bytes, checksum: a413ef5228f95d716999c5ee80611c5f (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2011 / Este trabalho tem como objetivo coletar evidências de decisões em projetos de desenvolvimento de software que podem ou não incorrer em Débito Técnico, a partir de um estudo de caso real. Para isso, foi adotado como estratégia de pesquisa um estudo de caso exploratório em um projeto de desenvolvimento de uma empresa multinacional de dispositivos móveis. O sistema investigado consiste em uma aplicação para dispositivos móveis, usada como cliente para soluções de serviços de email Microsoft ExchangeTM (MS Exchange), onde é possível gerenciar emails, calendários e contatos. Este sistema teve um ciclo de vida de seis anos (2005-2011). Os dados foram coletados de emails, documentos, logs de CVS, análise de código e entrevistas com desenvolvedores e gerentes de projeto. Uma análise investigativa foi realizada durante todo o ciclo de evolução do sistema. Em um primeiro momento, mudanças foram identificadas e após análise histórica das mesmas foi identificado que um conjunto de mudanças semelhantes resultavam de decisões tomadas em relação a um mesmo contexto: pesquisa de subcasos. Alguns importantes subcasos foram analisados e estudados em maior granularidade, onde importantes decisões foram identificadas juntamente com suas causas, motivações e impactos foram investigados. O resultado foi um conjunto de decisões em diferentes contextos e subcasos que em determinado momento incorreram em Débito Técnico e em outros não. Além disso, mostramos os fatores que as influenciaram e impacto dos mesmos no sistema ao longo do tempo. Estas evidências são importantes para validar as categorias que compõe a metáfora do Débito Técnico, visto que existem algumas discussões conceituais sobre a mesma, mas poucos estudos voltados para confirmação da mesma em um caso real. Também, foi criada uma lista de sugestões de procedimentos que podem ser adotados para melhor auxiliar na identificação e monitoramento de Débito Técnico

Made available in DSpace on 2014-06-12T16:01:12Z (GMT). No. of bitstreams: 2 arquivo7175_1.pdf: 951409 bytes, checksum: c76423488bb414047eb8d697e9c1af4d (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2005 / Os avanços tecnológicos nas áreas de micro-eletrônica, informática e telecomunicações vêm abrindo novas possibilidades para o monitoramento remoto de sinais vitais de pacientes, o que pode reduzir custos hospitalares de internação por períodos prolongados, permitir o diagnóstico por especialistas de centros médicos mais avançados, além de proporcionar um incremento na qualidade de vida dos pacientes. Diversos projetos acadêmicos e comerciais buscam desenvolver dispositivos de monitoramento remoto baseados em microcontroladores. Tais dispositivos são programados para executar funções relacionadas à aquisição de sinais, tratamento, armazenamento e transmissão de dados. No entanto, a crescente necessidade por mais funcionalidades, adequação a novos padrões de comunicação, diversidade de plataformas de hardware e aumento da produtividade do desenvolvimento permanecem como desafios no contexto de escassez de recursos computacionais desse tipo de dispositivo. Este trabalho propõe um framework para o desenvolvimento de aplicações de monitoramento de sinais vitais, o TinyMonitor, baseado no sistema operacional TinyOS. Aproveitando as características de programação modularizada do TinyOS, o TinyMonitor define um modelo de componentes que contempla as principais funcionalidades dessa classe de aplicações, permitindo que sejam agregadas novos tipos de captura e processamento de sinais, dispositivos de armazenamento e suporte a diferentes meios de transmissão de dados através da fácil extensão, substituição e reuso de módulos. O modelo de componentes proposto foi implementado como parte de um estudo de caso para o desenvolvimento de uma aplicação de monitoramento de sinais eletrocardiográficos. Posteriormente, essa implementação inicial foi estendida para acrescentar o processamento da freqüência cardíaca. A validação desse estudo de caso se deu por meio de simulações na ferramenta Tossim

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2016-07-01T12:38:10Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertação-JoelsonIsidroDaSilvaAraújo.pdf: 1742206 bytes, checksum: c2b6f413666e50be58b963e8624a1386 (MD5) / Made available in DSpace on 2016-07-01T12:38:10Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertação-JoelsonIsidroDaSilvaAraújo.pdf: 1742206 bytes, checksum: c2b6f413666e50be58b963e8624a1386 (MD5) Previous issue date: 2015-09-04 / CAPEs / Contexto: a mudança faz parte da evolução e durante o ciclo de vida do software a maior parte dos custos está associada a esta tarefa. Poder fazer previsões sobre os potenciais efeitos causados através de uma mudança é uma forma de minimizar esses custos. Neste contexto, surge então a Análise de Impacto (AI) para medir o esforço que será necessário à mudança e para nortear como realizar a mesma da maneira mais adequada, entretanto o resultado gerado pode ser insuficiente, pois é possível existirem erros na identificação dos elementos possivelmente impactados, não contemplando todos os problemas existentes. Objetivo: este trabalho tem como objetivo investigar o que se tem feito para permitir um resultado mais preciso na AI, gerando um catálogo de benefícios e limitações e propondo um guia de boas práticas, respondendo as perguntas de pesquisa – O que se sabe atualmente sobre os benefícios e limitações da AI em mudança de software? O que se tem feito para minimizar os erros gerados na análise? Método: para a condução da pesquisa fez-se necessário a busca de dados na literatura, através de uma pesquisa exploratória, por meio de uma revisão sistemática com o intuito de investigar as técnicas de AI relatadas em pesquisas dos últimos anos. Resultados: de posse dos dados resultantes da extração e análise dos dados, os resultados são: (1) evidências de técnicas existentes que conseguiram minimizar imprecisões nos resultados da análise, (2) geração de catálogo de benefícios e limitações em seu uso e ainda, um guia de propostas de boas práticas a serem adotadas para permitir que a análise apresente melhores resultados. Conclusão: os resultados fornecem uma melhor visão dos fatores que precisam ser melhorados e, além disso, possibilitaram a criação de um guia de boas práticas. Com isto, pretendemos contribuir fornecendo uma melhor compreensão sobre as técnicas existentes, de que forma melhorias vêm sendo propostas e quais práticas permitem a maximização dos resultados gerados através da análise de impacto. / Context: Changing is part of the evolution and during the software lifecycle most cost is associated with this task. Being able to make predictions about the potential effects caused by a change is a way to minimize these costs. In this context, the Impact Analisys (IA) can be used to measure the effort it will take to change and to guide how to do the same in the most appropriate way, however the results generated may be insufficient, it is possible to detect errors on the elements identification possibly impacted, not including all the existing problems. Objective: This study has the objetive to investigate what has been done to allow more accurate result in IA , generating a catalog of benefits and limitations and proposing a guide of good practice by answering the research questions - What is currently known about the benefits and IA limitations on software changes? What has been done to minimize errors generated in the analysis? Methodology: To conduct this research it is necessary to search data in the literature, through an exploratory research using a systematic review that will allow an investigation about the most IA techniques used in the last years. Results: With the data generated through the extration and analisys of data, the results are: evidences of techniques which can be used to minimize inaccuracies in test results, (2) generation of catalog of benefits and limitations in its use and also a good practice guide to be adopted to allow the analysis present better results. Conclusion: the expected results will provide a better view of the factors that need to be improved and, besides, will enable the creation of a good practice guide. With this, we intend to contribute by providing a better understanding of existing techniques, how improvements have been proposed and what practices has been used to improve the results generated by impact analysis.

Submitted by Renata Lopes (renatasil82@gmail.com) on 2015-12-01T13:21:15Z No. of bitstreams: 1 jacimarfernandestavares.pdf: 4117614 bytes, checksum: 6d7763e08f1653c32b20373c9e55ec2b (MD5) / Made available in DSpace on 2015-12-01T13:21:15Z (GMT). No. of bitstreams: 1 jacimarfernandestavares.pdf: 4117614 bytes, checksum: 6d7763e08f1653c32b20373c9e55ec2b (MD5) Previous issue date: 2015-03-16 / CAPES - Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Existem diversas tecnologias desenvolvidas nas areas de manuten c~ao e evolu c~ao colaborativa de software associadas a visualiza c~ao de software, objetivando resolver problemas de empresas e grupos de usu arios. Em muitos casos e necess ario integrar solu c~oes dessas areas visando resolver um dado problema relacionado a evolu c~ao do software. Este problema se torna mais intenso quando se trata de equipes geogra camente distribu das. Neste sentido, foi desenvolvida GiveMe Infra, uma infraestrutura para apoio a realiza c~ao de atividades de manuten c~ao e evolu c~ao de software, realizadas por equipes co-localizadas ou geogra camente distribu das. Tais atividades s~ao apoiadas por diferentes visualiza c~oes de software que permitem ao usu ario obter diferentes perspectivas sobre as informa c~oes disponibilizadas. Um estudo experimental foi realizado objetivando veri car a viabilidade de uso da solu c~ao. Os resultados obtidos s~ao apresentados, bem como os trabalhos futuros em rela c~ao a infraestrutura proposta. / There are several technologies developed to support collaborative software maintenance and evolution, as well as software visualization, in order to solve problems of companies and group of users. In many cases is necessary to integrate solutions already available in these areas to solve a given problem. These problems become intense when geographically dispersed groups are involved in software maintenance and evolution activities. In this sense, an infrastructure, named GiveMe Infra, was developed to support these activities when performed by co-located or geographically distributed teams. These activities are supported by di erent software visualizations that allow the user get di erent perspectives about the provided information. An experimental study were carried out aiming to verify the feasibility of the solution as well as the hypotheses. The obtained results related to the experiments and future works are presented