Made available in DSpace on 2014-06-12T15:55:51Z (GMT). No. of bitstreams: 2 arquivo2329_1.pdf: 8230070 bytes, checksum: 101572b9c6abfdcf32c5faef00f4a617 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2009 / Faculdade de Amparo à Ciência e Tecnologia do Estado de Pernambuco / Linhas de Produto de Software é uma importante estratégia de reuso para minimizar custos e tempo de entrega das aplicações, e maximizar a qualidade e produtividade do desenvolvimento de software. Entretanto, isso envolve o gerenciamento dos pontos comuns e variáveis entre diferentes aplicações, que aumenta sua complexidade quando comparado com desenvolvimento de software tradicional. Assim, desenvolver uma Linha de Produto requer tempo e planejamento para apresentar resultados positivos, ao contrário, o investimento pode ser perdido devido a falhas no projeto. Nesse contexto, um processo de Engenharia de Requisitos é importante para reduzir os riscos envolvidos em uma Linha de Produto, fornecendo gerenciamento e desenvolvimento de requisitos corretos. Por outro lado, existe um desafio chave em Engenharia de Requisitos para Linhas de Produto, que envolve uma solução adequada para gerenciar variabilidades, integrando-as e relacionado decisões em diferentes artefatos para facilitar a derivação de produtos. Assim, o desenvolvimento de Linhas de Produto deve ser apoiado por um processo de Engenharia de Requisitos adequado para o seu contexto. Atualmente, existem muitas abordagens de Engenharia de Requisitos para Linhas de Produto, entretanto, elas apresentam alguns problemas, tais como a ausência de um processo completo e sistemático, com detalhes suficientes para o ciclo de vida da Engenharia de Requisitos. Assim, este trabalho define um processo sistemático de Engenharia de Requisitos, descrevendo atividades, tarefas, entradas, saídas, papéis e guidelines para o contexto de Linhas de Produto, em uma forma usável, efetiva e eficiente. Por fim, um estudo experimental é apresentado para identificar a viabilidade do processo proposto

Scoping in Software Product Lines (SPL) is the first step to identify products, features, and assets in a market segment. Traditional approaches for SPL scoping are heavyweight and upfront processes in scenarios with unpredictable changes and little resources. An incurred key challenge is handling systematically the iterativeness, adaptability, and feedback in the SPL scoping process. As a final consequence, the software industry can hamper investment in the SPL scoping. In this context, the Scrum framework, as the most popular agile approach to foster the iterativeness, adaptability, and feedbacks, can address that challenge. Previous studies have combined Scrum into some SPL activities with good results. This thesis provides a process, named of RiPLE-SCA, for SPL scoping inspired in the Scrum practices. This process bases on industrial evidence (a case study of a traditional SPL scoping), expert opinion on agile SPL (through a survey), and scientific literature about agile SPL (a systematic mapping). A feasibility study and a cross-case study carried out with two industrial partners indicated that the RiPLE-SCA is practicable and appropriate for an industrial setting as well as fosters iterativeness, adaptability, and feedbacks detecting early obsolete features and changes in domain, requirements, features, and technology. / Submitted by João Arthur Martins (joao.arthur@ufpe.br) on 2015-03-12T18:58:41Z No. of bitstreams: 2 Tese Ivonei Freitas da Silva.pdf: 9233841 bytes, checksum: 6029df71deecd12c97bd99e1787a8361 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-12T18:58:41Z (GMT). No. of bitstreams: 2 Tese Ivonei Freitas da Silva.pdf: 9233841 bytes, checksum: 6029df71deecd12c97bd99e1787a8361 (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2013-10-29 / CNPq / A atividade de escopo em linhas de produto de software é o primeiro passo para identificar produtos, características e ativos de software em um segmento de mercado. As abordagens tradicionais para escopo de linhas de produto de software são processos densos e abrangentes em cenários com mudanças imprevisíveis e com poucos recursos. Um desafio chave nesse cenário é o gerenciamento sistemático da iteratividade, adaptabilidade e do feedback no processo de escopo de linhas de produto de software. Como último efeito, a indústria de software pode restringir investimentos no processo de escopo. Neste contexto, o framework Scrum, abordagem mais popular para incentivar a iteratividade, a adaptabilidade e o feedback, pode lidar com esse desafio. Estudos anteriores têm combinado Scrum com algumas atividades de linhas de produto de software obtendo bons resultados. Esta tese define um processo, denominado de RiPLE-ASC, para o escopo da linha de produtos de software inspirado nas práticas do Scrum. Este processo basea-se nas evidências da indústria (um estudo de caso real de escopo de linhas de produto usando uma abordagem tradicional), na opinião de especialistas em linhas de produto de software ágeis (através de um survey) e na literatura científica sobre linhas de produto de software ágeis (uma mapeamento sistemático). Um estudo de viabilidade e um estudo de caso “cross-case” executados com dois parceiros industriais de nosso grupo de pesquisa indicaram que o RiPLE-ASC tem aplicação prática e adequa-se em um ambiente de produção de software industrial bem como incentiva a iteratividade, adaptabilidade e o feedback detectando cedo características obsoletas e mudanças no domínio, requisitos, características e tecnologia

Submitted by Fabio Sobreira Campos da Costa (fabio.sobreira@ufpe.br) on 2015-05-08T14:47:59Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) risethesis.pdf: 1759813 bytes, checksum: cc03e28dd8851101bba0627d71685084 (MD5) / Made available in DSpace on 2015-05-08T14:47:59Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) risethesis.pdf: 1759813 bytes, checksum: cc03e28dd8851101bba0627d71685084 (MD5) Previous issue date: 2014-02-19 / A produção industrial antes de Taylor era essencialmente manufatureira e focada em produtos únicos. O Taylorismo e seus estudos de tempos e movimentos levaram para a indústria a ideia de padronização dos produtos. Ford, tempos depois, inventou a linha de produtos, onde a partir de então foi possível produzir em massa reduzindo o tempo de entrega do produto e seus custos. No que tange a indústria de software, esta apresenta tanto uma produção manufatureira quanto em massa que gera produtos que são denotados segundo POHL; BöCKLE; LINDEN (2005) como software individual e software standard: uma clara influência do fordismo na concepção do paradigma de Linhas de Produto de Software (SPL). No entanto, este paradigma de desenvolvimento não foi concebido para suportar mudanças nos requisitos de usuários em tempo de execução. Diante deste problema, a academia tem desenvolvido e proposto maneiras de estender o paradigma de SPL de forma a permitir que essas reconfigurações dinâmicas do software sejam suportadas. Surgiram deste esforço as Linhas de Produto de Software Dinâmicas (DSPL) (HALLSTEINSEN et al., 2008). Levando em consideração este cenário, objetiva-se nesta pesquisa contribuir com a área de DSPL apresentando uma nova maneira de pensar quais características de uma DSPL devem ser ligadas em tempo de execução a um produto com base em uma análise que mensura e valida atributos de qualidade em níveis de serviços especificados pelo usuário. Para tanto foi necessária a revisão da literatura existente em busca de meios de analisar atributos de qualidade de serviços em tempo de execução em DSPL e o desenvolvimento exploratório de uma abordagem de reconfiguração da DSPL utilizando-se das características dinâmicas do OSGi como base em tal análise. Com a finalidade de validar a abordagem proposta, a mesma foi testada exploratoriamente em uma DSPL para o domínio de guia de visitas móveis e sensível ao contexto, onde pode-se verificar a assertividade desta. Ao final da validação exploratória pode-se observar a efetividade da abordagem proposta na DSPL na qual foi aplicada. No entanto, faz-se necessário a execução de testes estatísticos para comprovar a hipótese de que esta efetividade demonstrada é válida para outras DSPLs de outros domínios.

Made available in DSpace on 2014-06-12T15:55:38Z (GMT). No. of bitstreams: 2 arquivo2275_1.pdf: 5480552 bytes, checksum: be0d8c06ce046cc764aaa9918db223b4 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2009 / Uma Linha de Produtos de Software (LPS) é um grupo de produtos de software com características comuns e variáveis, que também pode ser chamada de família de produtos. As caracterísiticas de uma LPS precisam ser documentadas explicitamente para possibilitar o reuso estratégico dos seus artefatos. Na atividade de Engenharia de Requisitos, isto significa que além de capturar as suas variabilidades, também é preciso relacionar os diferentes tipos de requisitos, tais como organizacionais, não-funcionais e funcionais, além de manter o rastreamento entre eles. Atualmente a captura desta informação é feita usando os modelos de features, mas esses não capturam requisitos não-funcionais explicitamente e nem a influência positiva/ negativa destes requisitos para alcançar configurações alternativas de uma aplicação na LPS. Esta influência pode ajudar na escolha de uma configuração específica para uma aplicação alcançar os objetivos da organização. Um objetivo é um estado do mundo que os stakeholders desejam alcançar enquanto que uma feature é uma característica que o sistema deve apresentar. Partindo destas definições, abordagens orientadas a objetivos podem ser usadas como uma forma efetiva para descobrir requisitos variáveis e comuns de uma LPS, bem como para reduzir os custos associados à configuração de um produto específico na família de produtos. Uma abordagem de requisitos orientada a objetivos que tem sido usada para o desenvolvimento de sistemas complexos é o framework i*. O i* fornece uma maneira natural de identificar e especificar tanto os interesses dos stakeholders como as características do sistema pretendido. Este trabalho propõe uma extensão da linguagem de modelagem do i*, chamada i*-c (i* with cardinality), que adiciona cardinalidade nos elementos de modelos intencionais e assim, permite a identificação e modelagem de features a partir de modelos orientados a objetivos. Para guiar a configuração de uma aplicação específica em uma LPS foi definida a abordagem G2FM (Goal to Feature Model). Ela propõe um processo de identificação e modelagem de features comuns e variáveis de uma LPS em modelos i* com cardinalidade e, a partir destes, produz um modelo de features equivalente

Submitted by Automa??o e Estat?stica (sst@bczm.ufrn.br) on 2015-11-27T13:12:56Z No. of bitstreams: 1 GleydsonDeAzevedoFerreiraLima_TESE.pdf: 3036609 bytes, checksum: d5ebbd6b69974b4e7bda113892450048 (MD5) / Approved for entry into archive by Elisangela Moura (lilaalves@gmail.com) on 2015-11-27T14:51:19Z (GMT) No. of bitstreams: 1 GleydsonDeAzevedoFerreiraLima_TESE.pdf: 3036609 bytes, checksum: d5ebbd6b69974b4e7bda113892450048 (MD5) / Made available in DSpace on 2015-11-27T14:51:19Z (GMT). No. of bitstreams: 1 GleydsonDeAzevedoFerreiraLima_TESE.pdf: 3036609 bytes, checksum: d5ebbd6b69974b4e7bda113892450048 (MD5) Previous issue date: 2014-03-31 / Linhas de produtos de software promovem a reutiliza??o em larga escala atrav?s do desenvolvimento de fam?lias de sistemas que: (i) compartilham um n?cleo comum de caracter?sticas previamente implementadas; e (ii) permitem a sele??o e customiza??o das caracter?sticas vari?veis, as quais determinam os comportamentos distintos de cada membro ou produto da fam?lia de sistema. Por raz?es de time-to-market e flexibilidade, a ind?stria de software tem adotado, com frequ?ncia, a t?cnica de clonagem como mecanismo de cria??o de produtos ou de novas linhas de produtos. Apesar das suas vantagens, a t?cnica de clonagem traz dificuldades para a evolu??o e reconcilia??o de caracter?sticas de linhas de produto de software devido aos poss?veis conflitos de integra??o das mudan?as realizadas no c?digo da linha de produto de software original, denominada Source, e a da linha de produto clonada, denominada Target. Esta tese de doutorado prop?e uma abordagem para evolu??o e reconcilia??o de produtos clonadas baseada na ado??o de t?cnicas de minera??o de reposit?rios de software. A abordagem promove a identifica??o de diferentes tipos de conflitos - l?xicos, estruturais e sem?nticos - que podem ocorrer durante a integra??o de caracter?sticas ou tarefas de desenvolvimento da linha de produto original para a linha de produto clonada. O trabalho apresenta os resultados de um estudo emp?rico de caracteriza??o dos tipos de conflitos de integra??o de c?digo em diferentes evolu??es de duas linhas de produto de software de sistemas de informa??o web. Os resultados do estudo demonstram o potencial da abordagem na resolu??o autom?tica ou semi-autom?tica de v?rios dos conflitos existentes, reduzindo assim os custos de evolu??o e reconcilia??o de linhas de produto de software clonadas. / Software product line engineering promotes large software reuse by developing a system family that shares a set of developed core features, and enables the selection and customization of a set of variabilities that distinguish each software product family from the others. In order to address the time-to-market, the software industry has been using the clone-and-own technique to create and manage new software products or product lines. Despite its advantages, the clone-and-own approach brings several difficulties for the evolution and reconciliation of the software product lines, especially because of the code conflicts generated by the simultaneous evolution of the original software product line, called Source, and its cloned products, called Target. This thesis proposes an approach to evolve and reconcile cloned products based on mining software repositories and code conflict analysis techniques. The approach provides support to the identification of different kinds of code conflicts ? lexical, structural and semantics ? that can occur during development task integration ? bug correction, enhancements and new use cases ? from the original evolved software product line to the cloned product line. We have also conducted an empirical study of characterization of the code conflicts produced during the evolution and merging of two large-scale web information system product lines. The results of our study demonstrate the approach potential to automatically or semi-automatically solve several existing code conflicts thus contributing to reduce the complexity and costs of the reconciliation of cloned software product lines.

Uma adaptação de um processo de software específico para linhas de produtos de software é proposta. Esse processo tem o objetivo de ser ágil, de apoiar as atividades de projetar e desenvolver características com re-trabalho mínimo e de facilitar a engenharia de aplicações. A fase de engenharia de domínio é iterativa e incremental e propõe uma arquitetura baseada em componentes. As aplicações são geradas por um gerador de aplicações configurável a partir de uma linguagem de modelagem de aplicações baseada no modelo de características. Adicionalmente, é apresentado um estudo detalhado de alternativas para projeto de componentes em uma linha de produtos, considerando componentes do tipo caixa-preta e caixa-branca visando a facilitar a composição e o reúso de componentes. Uma linha de produtos para controle de Bilhetes Eletrônicos em Transporte urbano (BET) foi projetada e implementada usando o processo proposto. Alternativas para a implementação baseada em aspectos de requisitos transversais e de variabilidades da linha de produtos BET, bem como sua geração automática, são apresentadas e discutidas / Adaptation of a specific software product line process is described. The adapted process aims to be agile, minimising rework for feature design and development activities and facilitating applications engineering. The domain engineering phase is iterative and incremental, using a component-based architecture. Applications are generated by an application generator configurable using an application modeling language based on the features diagram. Additionally, we present a detailed study of alternatives for design of product line components, considering white-box and black-box components, aiming to facilitate component composition and reuse. A product line for control of Electronic Transport Cards (ETC) was designed and developed using the proposed process. We present and discuss implementation alternatives based on aspect-oriented development to represent crosscutting and variability requirements of the ETC product line, as well as the automated generation of these requirements

Uma adaptação de um processo de software específico para linhas de produtos de software é proposta. Esse processo tem o objetivo de ser ágil, de apoiar as atividades de projetar e desenvolver características com re-trabalho mínimo e de facilitar a engenharia de aplicações. A fase de engenharia de domínio é iterativa e incremental e propõe uma arquitetura baseada em componentes. As aplicações são geradas por um gerador de aplicações configurável a partir de uma linguagem de modelagem de aplicações baseada no modelo de características. Adicionalmente, é apresentado um estudo detalhado de alternativas para projeto de componentes em uma linha de produtos, considerando componentes do tipo caixa-preta e caixa-branca visando a facilitar a composição e o reúso de componentes. Uma linha de produtos para controle de Bilhetes Eletrônicos em Transporte urbano (BET) foi projetada e implementada usando o processo proposto. Alternativas para a implementação baseada em aspectos de requisitos transversais e de variabilidades da linha de produtos BET, bem como sua geração automática, são apresentadas e discutidas / Adaptation of a specific software product line process is described. The adapted process aims to be agile, minimising rework for feature design and development activities and facilitating applications engineering. The domain engineering phase is iterative and incremental, using a component-based architecture. Applications are generated by an application generator configurable using an application modeling language based on the features diagram. Additionally, we present a detailed study of alternatives for design of product line components, considering white-box and black-box components, aiming to facilitate component composition and reuse. A product line for control of Electronic Transport Cards (ETC) was designed and developed using the proposed process. We present and discuss implementation alternatives based on aspect-oriented development to represent crosscutting and variability requirements of the ETC product line, as well as the automated generation of these requirements

Submitted by Santos Davilene (davilenes@ufba.br) on 2016-05-25T14:04:00Z No. of bitstreams: 1 FINAL Dissertação Mestrado - Hugo Sica de Andrade.pdf: 4068482 bytes, checksum: f4538e19111b94a4c1caae39a4e6c525 (MD5) / Made available in DSpace on 2016-05-25T14:04:00Z (GMT). No. of bitstreams: 1 FINAL Dissertação Mestrado - Hugo Sica de Andrade.pdf: 4068482 bytes, checksum: f4538e19111b94a4c1caae39a4e6c525 (MD5) / O paradigma de Linhas de Produto de Software (LPS) tem provado ser um meio efetivo para se obter reuso de grande escala em diferentes domínios. A abordagem tira proveito de aspectos comuns entre diferentes produtos, enquanto também considera propriedades específicas dos mesmos. A arquitetura tem um papel importante na engenharia de LPS, provendo meios para melhor entender e manter o ambiente de derivação de produtos. No entanto, é difícil evoluir tal arquitetura, pois nem sempre é claro onde e como refatorar. A arquitetura de uma LPS contém um modelo que irá resultar na arquitetura de produtos, e muitas vezes inclui soluções que indicam um design (arquitetural) inadequado. Uma forma de avaliar tais decisões de design é através da identificação de bad smells de arquitetura, ou seja, propriedades que prejudicam a qualidade do software, mas não são necessariamente errôneas ou representam falhas. Nesse sentido, o objetivo desta dissertação é obter um melhor entendimento de bad smells de arquitetura em LPSs. Primeiramente, o estado-da-arte atual em Arquiteturas de Linhas de Produto de software (ALP) é investigado através de um estudo de mapeamento sistemático. Este apresenta uma visão geral da área através de análise e categorização de evidências. O estudo idenfitica gaps, tendências, e provê direções futuras para pesquisa. Ademais, esta dissertação trata do fenômeno de bad smells de arquitetura no contexto de LPSs através de dois estudos exploratórios em domínios diferentes. O primeiro estudo exploratório conduz uma investigação sobre as implicações de propriedades estruturais em uma LPS no domínio de editores de texto, enquanto o segundo estudo foca em uma LPS no domínio mobile. Antes da busca pelos smells em ambos os estudos, informações relevantes para a arquitetura foram recuperadas do código fonte para que as arquiteturas fossem definidas.

Submitted by Santos Davilene (davilenes@ufba.br) on 2016-05-25T15:42:02Z No. of bitstreams: 1 Dissertação-Larissa_Rocha-UFBA-FINAL-FINAL.pdf: 3201408 bytes, checksum: 5d91e954fc2758c5dbd2b5cc35d0cf87 (MD5) / Made available in DSpace on 2016-05-25T15:42:02Z (GMT). No. of bitstreams: 1 Dissertação-Larissa_Rocha-UFBA-FINAL-FINAL.pdf: 3201408 bytes, checksum: 5d91e954fc2758c5dbd2b5cc35d0cf87 (MD5) / Reuse de software é um aspecto importante para organizações de software interessadas em produtos personalizados e a custos razoáveis. Engenharia de Linhas de Produtos de Software (SPLE) tem como objetivo alcançar estes desafios. O paradigma de SPLE é dividido em dois principais processos: engenharia de domínio e engenharia de aplicação. Derivação de Productos é a prática de criar produtos distintos durante a engenharia de aplicação. Com base na seleção de características (features), engenheiros de SPL e interessados podem derivar programas feitos sob medida e de forma eficiente que satisfazem diferentes necessidades. Neste cenário, propriedades não-funcionais (NFPs) surgem de maneira a prover uma derivação de produtos não apenas em relação às características funcionais, mas também aos atributos de qualidade. Uma definição explícita de NFPs durante a configuração de software tem sido considerada uma tarefa difícil, uma vez que NFPs em grandes sistemas resultam da interação de muitos recursos, tornando-os difíceis de serem configurados. SPL tem sido muito bem sucedida na gestão de features que compõem propriedades funcionais e também um grande número de NFPs. No entanto, existem muitas NFPs que não podem ser expressas e realizadas sob a forma de features, mas requerem diferentes abordagens. Como lidar com elas ainda é um desafio, tanto na teoria como na prática. Atualmente, poucos trabalhos se concentram na análise da NFPs para a engenharia de linha de produto de software. Nesse sentido, realizamos uma revisão sistemática da literatura publicada em busca de abordagens de SPL que reportam NFPs. Além disso, propomos um framework para especificar NFPs para SPL e também uma abordagem de reuso, a qual promove a reutilização dos valores de NFPs durante a configuração de um produto. Uma vez que a engenharia de SPL promove a reutilização de artefatos de SPL, valores de NFPs também poderiam ser reutilizados. Além disso, estudos de caso foram realizados a fim de avaliar a aplicabilidade do framework e da abordagem de reuso.

Submitted by Automa??o e Estat?stica (sst@bczm.ufrn.br) on 2018-03-12T21:07:03Z No. of bitstreams: 1 ErickSharllsRamosDePontes_DISSERT.pdf: 5142026 bytes, checksum: c5d7c498155fa9693ffcb28bbc0c9c56 (MD5) / Approved for entry into archive by Arlan Eloi Leite Silva (eloihistoriador@yahoo.com.br) on 2018-03-19T12:35:22Z (GMT) No. of bitstreams: 1 ErickSharllsRamosDePontes_DISSERT.pdf: 5142026 bytes, checksum: c5d7c498155fa9693ffcb28bbc0c9c56 (MD5) / Made available in DSpace on 2018-03-19T12:35:22Z (GMT). No. of bitstreams: 1 ErickSharllsRamosDePontes_DISSERT.pdf: 5142026 bytes, checksum: c5d7c498155fa9693ffcb28bbc0c9c56 (MD5) Previous issue date: 2017-08-25 / Uma Linha de produto de software (LPS) representa uma fam?lia de sistemas relacionados que compartilham similaridades e variabilidades visando atender ?s necessidades de um segmento de mercado espec?fico. A ado??o de LPS tem sido aplicada em diversas ?reas na ind?stria de software devido aos benef?cios alcan?ados, tais como, redu??o dos custos no desenvolvimento, aumento da qualidade e redu??o do tempo de comercializa??o. No entanto, cen?rios distintos podem ser encontrados para implementa??o de uma linha de produtos, caracterizando 3 abordagens para ado??o de LPS: (1) abordagem proativa: n?o existe softwares em produ??o, e uma LPS ? desenvolvida do zero; (2) abordagem reativa: j? existe uma LPS em produ??o que vai sofrer incremento para atender novos requisitos; (3) abordagem extrativa: a LPS ? desenvolvida a partir dos artefatos de um sistema ou conjunto de sistemas relacionados que j? est?o em produ??o. No contexto de abordagens extrativa e reativa, este trabalho prop?e um m?todo de extra??o e evolu??o de LPSs a partir de sistemas existentes implementados na linguagem Java. O m?todo foi extra?do a partir da condu??o de um estudo emp?rico de desenvolvimento de uma LPS para o dom?nio de sistemas de controle de espa?os f?sicos utilizados em diferentes centros da Universidade Federal do Rio Grande do Norte (UFRN) e define tr?s atividades que apresentam um conjunto de diretrizes para refatora??o e modulariza??o de features em sistemas implementados em Java: (i) Modelar features da LPS, (ii) Projetar e implementar LPS atrav?s da refatora??o de um sistema existente, e (iii) Realizar testes para cada um dos produtos atuais existentes. Em seguida, o m?todo foi avaliado por meio da sua aplica??o durante evolu??es da LPS para atender novos requisitos demandados pelos clientes. Por fim, foi constatado um aumento de linhas de c?digo dos produtos da LPS, no entanto, o n?cleo da LPS possui uma quantidade de linhas de c?digo menor que qualquer produto antes e depois da extra??o da LPS. Com isso, os artefatos da LPS ficaram melhor modularizados em termos de features, o que pode facilitar a evolu??o tanto do c?digo do n?cleo quanto dos artefatos variantes de cada aplica??o. / A software product line (SPL) represents a family of related systems that share commonalities and variabilities to address the needs of a specific market or mission. The adoption of SPL has been applied in several areas in the software industry due to the benefits achieved, such as reduction of development costs, quality improvement and reduction of time to market. However, distinct scenarios can be found when developing a SPL, which lead to 3 approaches for adopting a SPL: (1) proactive approach: there are no previous software implementation and a SPL is developed from scratch; (2) reactive approach: there is a SPL available which is evolved to address new features and products; (3) extractive approach: SPL is developed from the assets of a system or a set of related systems that already exists. In the scenarios of the extractive and reactive approaches, this dissertation proposes a method of extraction and evolution of SPLs from existing systems implemented in the Java language. The method was extracted from an empirical study of an LPS for the domain of systems that manage physical spaces from different Federal University of Rio Grande do Norte (UFRN) departments and defined three activities that present a set of guidelines for refactoring and modularizing features in systems implemented in Java: (i) Model SPL features, (ii) Design and Implement LPS by refactoring an existing system, and (iii) Perform tests for each of the existing products. The method is evaluated through its application during SPL evolutions to address new requirements demanded by the customers. As a result of the study, we found an increase in the number of lines of code of the products of the products, however, the SPL core had lower lines of code than any product before and after the LPS extraction. Thus, the SPL assets have become better modularized in terms of features, which may facilitate the evolution of core and variant implementations of each application.