Orientador: Cecília Mary Fischer Rubira / Dissertação (mestrado) - Universidade Estadual de Campinas, Instituto de Computação / Made available in DSpace on 2018-08-22T06:21:21Z (GMT). No. of bitstreams: 1 Foschiani_FernandaYaradosSantos_M.pdf: 49651686 bytes, checksum: 9c6b109c2f901376bfd10d30c1ea12c3 (MD5) Previous issue date: 2013 / Resumo: Com o aumento da demanda por software no mercado, a fim de reduzir custos e esforço em desenvolvimento e reduzir o tempo de entrega de software, diversas técnicas vêm sendo utilizadas e entre elas estão as Linhas de Produtos de Software (LPS). Por outro lado, os recursos computacionais vêm sendo muito utilizados não são na indústria, mas também em ambientes de pesquisa, facilitando o compartilhamento de dados e serviços computacionais. Este contexto, em que a computação torna-se parte integrante e fundamental para o sucesso na realização de pesquisas científicas, é chamado de e-Science. A diversidade de programas, simuladores e dados computacionais envolvidos em experimentos levam a necessidade de ambientes que forneçam facilidades para o uso e combinação das tecnologias, como por exemplo, ambientes de workflows científicos. A solução proposta nesta dissertação é uma infraestrutura para a execução de workflows científicos, que permite a pesquisadores criarem seus fluxos de trabalho de maneira personalizada, podendo utilizar componentes disponibilizados pela equipe de desenvolvimento, assim como componentes criados por eles mesmos, independentemente da linguagem de programação utilizada. A base para esta infraestrutura é uma linha de produtos baseada em componentes, desenvolvida a partir de sistemas legados. O método proposto para o desenvolvimento da linha de produtos é apoiado pelo arcabouço da Reengenharia Orientada a Características, separado em quatro fases. A primeira fase, Engenharia Reversa do Sistema Legado, extrai informações do código legado a fim de entender o domínio da aplicação e coletar as características que deverão existir na linha de produtos. A segunda fase do método, Análise da LPS, refina o modelo de características obtido na fase anterior e, utilizando técnicas de modelagem do método PLUS, desenvolve artefatos de software baseados em casos de uso. A fase de Projeto da LPS, terceira fase, aplica o método FArM para obter um mapeamento do modelo de características para modelos de arquitetura de linha de produtos baseada em componentes e especifica as interfaces dos componentes, gerando assim a arquitetura final. A quarta e ultima fase trata do desenvolvimento da linha de produtos. Para o desenvolvimento dos componentes foi utilizado o padrão COSMOS* de componentização, e código legado. Foram realizados três estudos de caso: os dois primeiros para avaliar se a solução proxi posta é capaz de substituir o sistema legado e também avaliar o reuso de componentes, e o terceiro estudo para avaliar a capacidade de customização da linha de produtos, a partir da adição de um novo componente desenvolvido em MatLab. Os três estudos apresentaram resultados positivos, indicando que a solução proposta nesta dissertação facilita a modificação da linha de produtos, além de permitir aos pesquisadores a customização de fluxos de trabalho, auxiliando assim o processo de pesquisa científica / Abstract: With the increasing demand for software in order to reduce development costs and effort, and to reduce the time-to-market, several techniques are being used, including the Software Product Line (SPL). Computational resources are commonly used in the research field, in order to facilitate data and computational services sharing. The context in which computing becomes a fundamental for the success of scientific research is called e-Science. The systems diversity, simulators and computational data involved in experiments leads to the necessity of environments that provide facilities for technology use and matching, for example the scientific workflow environment. The proposed solution in this thesis is a scientific workflow environment that allows the researchers to create their own personalized workflows, using components provided by the development team as well as components developed by themselves, regardless of the language being used. The basis for this workflow environment is a component based software product line, developed from legacy systems. The proposed method for the software product line development is supported by the Feature-oriented Reengineering framework, which is divided into four steps. The first one, SPL Reverse Engineering, extracts information about the legacy system in order to understand the application domain and collect the features that need to exist in the product line. The second step, SPL Analysis, refines the feature model obtained in the previous step and, using PLUS modeling techniques, develops software assets based on use cases. The SPL Project step, which is the third approach step, applies the FArM method to obtain a mapping of the feature model to architectural components, and specifies the components' interface, creating the final architecture. The last step is the product line development. For the components development we used the COSMOS* model and legacy code. We performed three case studies: two of them to evaluate if the product line is capable of replacing the legacy system and enhance components reuse, and the third one to evaluate the workflow customization capability, by the addition of a component developed in MatLab. All the case studies had a positive result, showing that the proposed solution of this ix thesis facilitates the product line architectures evolution and allows the researchers to customize their workflows, aiding the research process / Mestrado / Ciência da Computação / Mestra em Ciência da Computação

Software systems today face many challenges that were not even imagined decades prior. Challenges including the need to evolve at a very high rate, lifecycle phase drift or erosion, inability to prevent the butterfly effect where the slightest change causes unimaginable side effects throughout the system, lack of discipline to define metrics and use measurement to drive operations, and no "silver bullet" or single solution to solve all the problems of every domain, just to name a few. This is not to say that the issues stated above are the only problems. In fact, it would be impossible to list all possible problems--software itself is infinitely flexible bounded only by the human imagination. These are just a portion of the primary challenges today's software engineer faces. There have been attempts throughout the history of software to resolve each one of these challenges. There have been those who tried to tackle them individually, simultaneously, as well as various combinations of them at one time. One such method was to define and encapsulate the various phases within software, which has come to be called a software lifecycle or lifecycle model. Another area of recent research has lead to the hypothesis that many of these challenges can be resolved or at least facilitated through proper traceability methods. Virtually none of today's software components are completely derived from scratch. Rather, code reuse and software evolution become a large portion of the software engineer's duties. As Vance Hilderman at HighRely puts it, "Research has shown that proper traceability is vital. For high quality and safety-critical engineering development efforts however, traceability is a cornerstone not just for achieving success, but to proving it as well." So if software is not derived from scratch, having the traceability to know about its origination is invaluable. Given today's struggles, what is in store for the future software engineer? This paper is an attempt to quantify and answer (or at least project a possibility) that involves a new mindset and a new lifecycle model or structure change that may assist in tackling some of the above referenced issues. / text

A avaliação e melhoria de um processo de software requer um grande esforço por parte de gerentes e desenvolvedores, uma vez que a obtenção de dados para tomada de decisão, acerca da evolução do processo nem sempre é trivial. O desenvolvimento de software, como qualquer disciplina de Engenharia, necessita de mecanismos de mensuração, para que através de uma avaliação de seus resultados o processo possa ser melhorado. Mas a mensuração pode ser uma tarefa bastante trabalhosa sem o auxílio de metodologias ou ferramentas de apoio. Neste sentido, este trabalho apresenta um modelo para mensuração em processos de software, no contexto do projeto APSEE-Prosoft. O objetivo do modelo proposto é prover suporte a realização de mensuração em processos de software, através do desenvolvimento e implantação de programas de mensuração, visando auxiliar aos gerentes na realização de atividades como planejamento, coleta e análise de métricas em um processo de software. Neste trabalho são combinados aspectos relacionados a importantes áreas da Engenharia de Software, como mensuração, processos de software, ambientes de engenharia de software centrados em processos (PSEE), bem como a utilização de métodos formais para a definição e especificação de um modelo de mensuração integrado a um PSEE. / The software process evaluation and improvement requests great effort of managers and developers, especially because obtaining data for decision support (about process evolution) is not a simple task. The software development, as any discipline of Engineering, needs measurement mechanisms, so that through an evaluation of its results, the process can be improved. But measurement can be a difficult task without the aid of methodologies or support tools. In this sense, this paper presents a model for software processes measurement, on the context of APSEE-Prosoft project. The model's objective is to provide support for the measurement in software processes, through the development and implantation of measurement programs, to aid managers in the accomplishment of activities such as planning, collecting and analysis of metrics in a software process. This paper combines aspects related to important areas of Software Engineering, as measurement, software process, process-centered engineering environment (PSEE), besides the use of formal methods for a definition and specification of a measurement model integrated to a PSEE.

A avaliação e melhoria de um processo de software requer um grande esforço por parte de gerentes e desenvolvedores, uma vez que a obtenção de dados para tomada de decisão, acerca da evolução do processo nem sempre é trivial. O desenvolvimento de software, como qualquer disciplina de Engenharia, necessita de mecanismos de mensuração, para que através de uma avaliação de seus resultados o processo possa ser melhorado. Mas a mensuração pode ser uma tarefa bastante trabalhosa sem o auxílio de metodologias ou ferramentas de apoio. Neste sentido, este trabalho apresenta um modelo para mensuração em processos de software, no contexto do projeto APSEE-Prosoft. O objetivo do modelo proposto é prover suporte a realização de mensuração em processos de software, através do desenvolvimento e implantação de programas de mensuração, visando auxiliar aos gerentes na realização de atividades como planejamento, coleta e análise de métricas em um processo de software. Neste trabalho são combinados aspectos relacionados a importantes áreas da Engenharia de Software, como mensuração, processos de software, ambientes de engenharia de software centrados em processos (PSEE), bem como a utilização de métodos formais para a definição e especificação de um modelo de mensuração integrado a um PSEE. / The software process evaluation and improvement requests great effort of managers and developers, especially because obtaining data for decision support (about process evolution) is not a simple task. The software development, as any discipline of Engineering, needs measurement mechanisms, so that through an evaluation of its results, the process can be improved. But measurement can be a difficult task without the aid of methodologies or support tools. In this sense, this paper presents a model for software processes measurement, on the context of APSEE-Prosoft project. The model's objective is to provide support for the measurement in software processes, through the development and implantation of measurement programs, to aid managers in the accomplishment of activities such as planning, collecting and analysis of metrics in a software process. This paper combines aspects related to important areas of Software Engineering, as measurement, software process, process-centered engineering environment (PSEE), besides the use of formal methods for a definition and specification of a measurement model integrated to a PSEE.

A avaliação e melhoria de um processo de software requer um grande esforço por parte de gerentes e desenvolvedores, uma vez que a obtenção de dados para tomada de decisão, acerca da evolução do processo nem sempre é trivial. O desenvolvimento de software, como qualquer disciplina de Engenharia, necessita de mecanismos de mensuração, para que através de uma avaliação de seus resultados o processo possa ser melhorado. Mas a mensuração pode ser uma tarefa bastante trabalhosa sem o auxílio de metodologias ou ferramentas de apoio. Neste sentido, este trabalho apresenta um modelo para mensuração em processos de software, no contexto do projeto APSEE-Prosoft. O objetivo do modelo proposto é prover suporte a realização de mensuração em processos de software, através do desenvolvimento e implantação de programas de mensuração, visando auxiliar aos gerentes na realização de atividades como planejamento, coleta e análise de métricas em um processo de software. Neste trabalho são combinados aspectos relacionados a importantes áreas da Engenharia de Software, como mensuração, processos de software, ambientes de engenharia de software centrados em processos (PSEE), bem como a utilização de métodos formais para a definição e especificação de um modelo de mensuração integrado a um PSEE. / The software process evaluation and improvement requests great effort of managers and developers, especially because obtaining data for decision support (about process evolution) is not a simple task. The software development, as any discipline of Engineering, needs measurement mechanisms, so that through an evaluation of its results, the process can be improved. But measurement can be a difficult task without the aid of methodologies or support tools. In this sense, this paper presents a model for software processes measurement, on the context of APSEE-Prosoft project. The model's objective is to provide support for the measurement in software processes, through the development and implantation of measurement programs, to aid managers in the accomplishment of activities such as planning, collecting and analysis of metrics in a software process. This paper combines aspects related to important areas of Software Engineering, as measurement, software process, process-centered engineering environment (PSEE), besides the use of formal methods for a definition and specification of a measurement model integrated to a PSEE.

Orientador: Cecilia Mary Fischer Rubira / Dissertação (mestrado profissional) - Universidade Estadual de Campinas, Instituto de Computação / Made available in DSpace on 2018-08-07T00:50:23Z (GMT). No. of bitstreams: 1 Pinho_HelderdeSousa_M.pdf: 1255692 bytes, checksum: 91ab06629ddbbf4b6885b93010e3511f (MD5) Previous issue date: 2006 / Resumo: O desenvolvimento baseado em componente (DBC) pennite que uma aplicação seja construída pela composição de componentes de software que já foram previamente especificados, construídos e testados, resultando em ganhos de produtividade e qualidade no software produzido. Para haver reuso de componentes, é necessário que usuários consIgam procurar e recuperar componentes previamente especificados ou implementados Um repositório de componentes é essencial para possibilitar tal reuso. Interoperabilidade é um requisito importante para repositórios, mas nem todas as ferramentas a tratam com a devida relevância. O modelo de metadados de um repositório para DBC deve contemplar características de componentes, tais como interface e separação entre especificação e implementação. Este trabalho apresentou o Rigel, um repositório de bens de software reutilizáveis com suporte para desenvolvimento baseado em componentes. O Rigel apresenta características que facilitam atividades executadas durante o desenvolvimento de sistemas baseados em componentes, tais como pesquisa, armazenamento e recuperação de bens e integração com CVS. O padrão RAS foi adotado como o fonnato de metadados e de empacotamento de bens, facilitando a integração do Rigel com outros sistemas. O modelo de metadados do RAS foi estendido para apoiar um modelo conceitual de componentes e arquitetura de software. Esta adaptação resultou na criação de quatro novos profiles RAS, para apoiar bens relacionados à DBC: componente abstrato, componente concreto, interface e configuração arquitetural. Um estudo de caso foi conduzido a fim de mostrar como o Rigel apóia um processo de desenvolvimento baseado em componentes. Conclui-se que as características do repositório Rigel facilitam um desenvolvimento baseado em componentes / Abstract: The component based development (CBD) permits an application to be built by composition of previously specified, build and tested components, resulting in increases in productivity and quality of the produced software. 1n order to make the reuse of components happen, it is necessary that users are able to search and retrieve previously specified or implemented components. A component repository is important to support this reuse. 1nteroperability is an important requirement for repositories, but not alI the tools consider it with the required relevance. The metadata model of a CBD repository must handle components features, such as interface and separation between specification and implementation. This work presents Rigel, a repository of reusable software assets with a support for component based development. Rigel presents features that make activities performed during the development of component based systems easier, such as search, storage and retrieval of assets and CVS integration. RAS standard was adopted as the asset metadata and packaging format, making Rigel integration with other systems easier. The RAS metadata model was extended to support a conceptual model of components and software architecture. This adaptation resulted in the creation of four new RAS profiles to support CBD related assets: abstract component, concrete component, interface and architectural configuration. A case study was conducted in order to show how Rigel supports a CBD processo We also conclude that Rigel repository features make the component based development easier / Mestrado / Engenharia de Computação / Mestre em Computação

Orientador: Cecília Mary Fischer Rubira / Tese (doutorado) ¿ Universidade Estadual de Campinas, Instituto de Computação / Made available in DSpace on 2018-08-21T03:56:22Z (GMT). No. of bitstreams: 1 Tizzei_LeonardoPondian_D.pdf: 4801081 bytes, checksum: 4be6c243f0c9f62c50e330561161fcdd (MD5) Previous issue date: 2012 / Resumo: Arquiteturas de linhas de produtos são essenciais para facilitar a evolução das linhas, pois ajudam a lidar com sua complexidade, abstraindo seus detalhes de implementação. A variabilidade arquitetural difere arquiteturas de linhas de produtos de arquiteturas de sistemas únicos. Ela reflete a existência de alternativas de projeto arquitetural e é expressa por meio de um conjunto de pontos de variação e variantes arquiteturais. A variabilidade arquitetural pode dificultar a evolução de arquiteturas de linhas produtos, pois a implementação da variabilidade software pode aumentar a complexidade da arquitetura com a possível adição de elementos e dependências extras. A variabilidade de linhas de produtos é usualmente capturada modelo de características e implementado pela arquitetura de linha de produtos. Entretanto, a implementação de características, pontos de variação e variantes podem estar espalhados por diversos elementos arquiteturais, o que dificulta a sua evolução. Em geral, cenários de evolução de linhas de produto envolvem adição e/ou remoção de características, mudança de uma característica obrigatória para opcional, entre outros. Quando cenários de evolução afetam características cujas implementações estão espalhadas na arquitetura, eles podem causar impacto de mudança em vários elementos arquiteturais. Estudos recentes exploram o uso de aspectos para modularizar a implementação de características em arquiteturas de linhas de produtos. Aspectos são usados para modularizar interesses transversais que, no contexto de linhas de produtos, são interesses que afetam diversas características. Contudo, esses estudos não consideram (i) arquiteturas componentizadas com interfaces explícitas e (ii) o uso integrado de componentes e aspectos para modularizar a implementação da variabilidade arquitetural. Idealmente aspectos devem ser modelados o mais cedo possível, de preferência, junto com o modelo de características para possibilitar a criação de arquiteturas bem estruturadas com aspectos. Todavia, não existem modelos que integrem o modelo de características e aspectos, nem métodos que consideram aspectos para gerar arquiteturas de linhas produtos a partir do modelo de características. A solução proposta nesta tese envolve inicialmente um estudo comparativo para mostrar a facilidade de evolução de arquiteturas de linhas de produtos propiciada pelo uso integrado de componentes e aspectos. Em seguida, é proposta uma visão estendida do modelo de características que permite representar características transversais. Essa visão, chamada de visão de características orientada a aspectos, é usada para criar arquiteturas de linhas de produtos orientadas a aspectos. Além disso, um modelo arquitetural de componentes é estendido para integrar aspectos para modularizar a variabilidade arquitetural. Por fim, o método FArM, que provê o mapeamento de modelo de características para modelos de arquitetura de linha de produtos, é estendido para considerar características transversais. Foram conduzidos dois estudos empíricos: um para avaliar se o uso integrado de componentes e aspectos facilita ou não a evolução de arquiteturas de linhas de produtos. O outro estudo empírico avalia a modelagem de características transversais e a extensão do método FArM propostos para projetar arquiteturas de linhas de produtos que sejam fáceis de evoluir. Os dois estudos apresentaram resultados promissores indicando que a solução proposta nesta tese facilita a evolução de arquiteturas de linhas de produtos / Abstract: Product line architectures are essential to facilitate the evolution of product lines, as they handle their complexity by abstracting implementation details. Architectural variability is what differs product line architectures from single system architectures. It reflects the existence of alternative design options and it is expressed by a set of architectural variation points and variants. Architectural variability can hinder product line architecture evolution because the implementation of software variability can increase architecture complexity by possibly adding extra elements and dependencies. Product line variability is usually captured in the feature model and it is implemented by product line architectures. However, the implementation of features, variation points, and variants may be scattered over architectural elements, which can hinder its evolution. In general, product line evolution scenarios involve feature addition/removal, changing a mandatory feature to an optional feature, and so forth. When evolution scenarios affect features whose implementations are scattered over architecture, they can cause a great change impact on several architectural elements. Recent studies have explored the use of aspects to modularize feature implementation in product line architectures. Aspects can modularize crosscutting concerns, which, in the context of product lines, are concerns that affect several features. Nevertheless, these studies do not consider (i) componentized architectures with explicit interfaces, and (ii) the integration of aspects and components to modularize the implementation of architectural variability. Ideally, aspects should be modeled as soon as possible, preferably, together with the feature model in order to enable the design of well structured product line architectures with aspects. However, there are neither models which integrate features and aspects, nor methods that considers aspects to design product line architectures from the feature model. The solution proposed in this thesis involves a comparative study that presents the support for product line architecture evolution provided by the integration of components and aspects. Then, it is proposed an extended view of the feature model which enables to represent crosscutting features. This view, called aspect-oriented feature view, is used to design product line architectures with aspects. Lastly, the FArM method, which provides guidelines to map from the feature model to the product line architecture model, is extended to consider crosscutting features. Two empirical studies were conducted: one to assess whether the integration of components and aspects facilitates product line architecture evolution. The other empirical study evaluates whether the crosscutting feature modeling and the FArM method extension proposed supports the design of evolvable product line architectures. Both studies presented promising results which indicate that the solution proposed in this thesis facilitates product line architecture evolution / Doutorado / Ciência da Computação / Doutor em Ciência da Computação

Context: There is an overwhelming prevalence of companies developing software in global software development (GSD) contexts. The existing body of knowledge, however, falls short of providing comprehensive empirical evidence on the implication of GSD contexts on software quality for evolving software systems. Therefore there is limited evidence to support practitioners that need to make informed decisions about ongoing or future GSD projects. Objective: This thesis work seeks to explore changes in quality, as well as to gather confounding factors that influence quality, for software systems that evolve in GSD contexts. Method: The research work in this thesis includes empirical work that was performed through exploratory case studies. This involved analysis of quantitative data consisting of defects as an indicator for quality, and measures that capture software evolution, and qualitative data from company documentations, interviews, focus group meetings, and questionnaires. An extensive literature review was also performed to gather information that was used to support the empirical investigations. Results: Offshoring software development work, to a location that has employees with limited or no prior experience with the software product, as observed in software transfers, can have a negative impact on quality. Engaging in long periods of distributed development with an offshore site and eventually handing over all responsibilities to the offshore site can be an alternative to software transfers. This approach can alleviate a negative effect on quality. Finally, the studies highlight the importance of taking into account the GSD context when investigating quality for software that is developed in globally distributed environments. This helps with making valid inferences about the development settings in GSD projects in relation to quality. Conclusion: The empirical work presented in this thesis can be useful input for practitioners that are planning to develop software in globally distributed environments. For example, the insights on confounding factors or mitigation practices that are linked to quality in the empirical studies can be used as input to support decision-making processes when planning similar GSD projects. Consequently, lessons learned from the empirical investigations were used to formulate a method, GSD-QuID, for investigating quality using defects for evolving systems. The method is expected to help researchers avoid making incorrect inferences about the implications of GSD contexts on quality for evolving software systems, when using defects as a quality indicator. This in turn will benefit practitioners that need the information to make informed decisions for software that is developed in similar circumstances.

O avanço recente da tecnologia na área de sistemas digitais representa uma grande oportunidade para realizar um importante progresso em diversos aspectos dos sistemas de controle e proteção tradicionais. No entanto, os requisitos provenientes do uso intensivo de software em sistemas críticos de segurança, aumenta a demanda por uma abordagem adequada que possa ser baseada na experiência nesta área. Apesar de vários modelos de capacidade de maturidade estarem em constante desenvolvimento, ainda é um desafio estabelecer uma forma coerente para a melhoria e avaliação do processo de desenvolvimento de software. O objetivo desta pesquisa é propor um método para obtenção de perfis de capacidade baseados na aplicação do modelo de referência brasileiro para melhoria do processo de software MR-MPS, em conjunto com a extensão de segurança do modelo de capacidade e maturidade CMMI-DEV +SAFE, embasado pela percepção de especialistas em segurança por meio da aplicação de um modelo de decisão por múltiplos critérios. / The recent technology advance in the digital systems area represents a great opportunity to make important progress in many aspects of traditional control and protection systems. However, requirements derived from the intensive use of software in safety critical systems raises the demand for a suitable approach that can be based on the expertise in this area. Although a number of capability maturity models have been in constant development, it is still challenging to establish a coherent path for software process improvement and evaluation. The goal of this research work is to propose a method for building capability profiles based on the application of the Brazilian Reference Model for Software Process Improvement MR-MPS, along with the Capability Maturity Model for Development safety extension CMMI-DEV +SAFE, supported by safety engineers insight through the application of a multi criteria decision model.

As formigas são criaturas fascinantes que, além dos avanços na biologia também inspiraram pesquisas sobre teoria da informação. Em particular, o estudo resultou na criação da Teoria da Forragem de Informação, que descreve como os agentes de buscam informações em seu ambiente. Esta teoria também explica fenômenos recentes e bem-sucedidos, como crowd sourcing. Crowdsourcing tem sido aplicado a muitas atividades em engenharia de software, incluindo desenvolvimento, tradução e testes, mas uma atividade parece resistir: depuração. No entanto, os desenvolvedores sabem que a depuração pode exigir dedicação, esforço, longas horas de trabalho, por vezes, para mudar uma linha de código único. Nós introduzimos o conceito de Depuração em Enxame, para trazer crowd sourcing para a atividade de depuração. Através de crowd sourcing, pretendemos ajudar os desenvolvedores, capitalizando a sua dedicação, esforço e longas horas de trabalho para facilitar atividades de depuração. Mostramos que a depuração enxame requer uma abordagem específica para recolher informações relevantes, e descrevemos sua infra-estrutura. Mostramos também que a depuração em enxame pode reduzir o esforço desenvolvedores. Concluímos com as vantagens e limitações atuais de depuração enxame, e sugerir caminhos para superar estas limitações e ainda mais a adoção de crowd sourcing para atividades de depuração. / Ants are fascinating creatures that beyond the advances in biology have also inspired research on information theory. In particular, their study resulted in the creation of the Information Foraging Theory, which describes how agents forages for information in their environment. This theory also explains recent and fruitful phenomena, such as crowdsourcing. Many activities in software engineering have applied crowdsourcing, including development, translation, and testing, but one action seems to resist: debugging. Developers know that debugging can require dedication, effort, long hours of work, sometimes for changing one line of code only. We introduce the concept of Swarm Debugging, to bring crowdsourcing to the activity of debugging. Through crowdsourcing, we aim at helping developers by capitalizing on their dedication, effort, and long hours of work to ease debugging activities of their peers or theirs, on other bugs. We show that swarm debugging requires a particular approach to collect relevant information, and we describe the Swarm Debugging Infrastructure. We also show that swarm debugging minimizes developers effort. We conclude with the advantages and current limitations of swarm debugging and suggest directions to overcome these limitations and further the adoption of crowdsourcing for debugging activities.