Les cadriciels et les bibliothèques sont indispensables aux systèmes logiciels d'aujourd'hui. Quand ils évoluent, il est souvent fastidieux et coûteux pour les développeurs de faire la mise à jour de leur code. Par conséquent, des approches ont été proposées pour aider les développeurs à migrer leur code. Généralement, ces approches ne peuvent identifier automatiquement les règles de modification une-remplacée-par-plusieurs méthodes et plusieurs-remplacées-par-une méthode. De plus, elles font souvent un compromis entre rappel et précision dans leur résultats en utilisant un ou plusieurs seuils expérimentaux. Nous présentons AURA (AUtomatic change Rule Assistant), une nouvelle approche hybride qui combine call dependency analysis et text similarity analysis pour surmonter ces limitations. Nous avons implanté AURA en Java et comparé ses résultats sur cinq cadriciels avec trois approches précédentes par Dagenais et Robillard, M. Kim et al., et Schäfer et al. Les résultats de cette comparaison montrent que, en moyenne, le rappel de AURA est 53,07% plus que celui des autre approches avec une précision similaire (0,10% en moins). / Software frameworks and libraries are indispensable to today's software systems. As they evolve, it is often time-consuming for developers to keep their code up-to-date. Approaches have been proposed to facilitate this. Usually, these approaches cannot automatically identify change rules for one-replaced-by-many and many-replaced-by-one methods, and they trade off recall for higher precision using one or more experimentally-evaluated thresholds. We introduce AURA (AUtomatic change Rule Assistant), a novel hybrid approach that combines call dependency and text similarity analyses to overcome these limitations. We implement it in a Java system and compare it on five frameworks with three previous approaches by Dagenais and Robillard, M. Kim et al., and Schäfer et al. The comparison shows that, on average, the recall of AURA is 53.07% higher while its precision is similar (0.10% lower).

Mit Pfeilen lassen sich auf angemessene Weise im Physik- und Mathematikunterricht in verschiedenen Themenbereichen vektorielle Betrachtungen umsetzen. Solche Vektorpfeile stellen ein Symbolsystem dar, mit dem sich Situationen mathematisieren und Probleme modellieren lassen. Ist das Wissen um die Handhabung der Vektorpfeile nicht an spezielle Inhalte und Kontexte gebunden, eröffnen sich für den Agierenden auch in unbekannten, neuen Situationen erweiterte Handlungsoptionen. Vektorpfeile funktionieren dann als sogenannte mentale Werkzeuge. Es war das Ziel der im Mechanikunterricht der Mittelstufe umgesetzten Studie, einen entsprechenden Transfer von Wissen sichtbar zu machen. Die Studie ist als quasiexperimentelle Feldstudie mit drei Treatmentgruppen und einer Baselinegruppe angelegt worden. Die Treatments umfassen mehrstündige Lerneinheiten, in denen das Konzept der Vektorpfeile mit ein, zwei beziehungsweise ohne physikalische Anwendungen der Pfeile gelehrt wurde. Eine erhöhte Anzahl an Anwendungen betont die Inhaltsunabhängigkeit und Flexibilität der Pfeile und vermittelt sie im Sinne eines mentalen Werkzeugs. Hypothesenkonform wird bezüglich einer Skala des Nachtests sichtbar, dass der Unterricht, der mehrere Anwendungen umfasst, zu höheren Leistungen der Probanden bei ihnen unbekannten Anwendungen führt. Außerdem zeigt eine explorative Analyse, dass schwache Probanden besonders vom anwendungsreichen Unterricht profitieren. Es wird jedoch insgesamt deutlich, dass für die Nutzung der Vektorpfeile als mentales Werkzeug weitere Einflussfaktoren eine Rolle spielen. / Arrows can be used in an adequate way to carry out vector calculations in different subject areas of physics and mathematics education. Such vector arrows can be understood as a symbol system with which situations and problems can be modelled mathematically. If the knowledge about the usage of arrows is not attached to specific contents and contexts, additional options arise in new and unknown situations. In this case vector arrows act as so called mental tools. It was the aim of the implemented study to verify such a transfer of knowledge in mechanics education of middle school. The study was designed as a quasi-experimental field study with three treatment groups and one baseline group. The treatments consists of four lessons in which the concept of vector arrows was taught with one, two or without an embodiment of the arrows by physical quantity. An increased number of embodiments emphasizes the independence of contents and the flexibility of the arrows. Thus, arrows become a mental tool. In line with the hypothesis one scale of the post-test shows that the teaching, which involves multiple embodiments of arrows, leads to higher performance related to unknown embodiments.However, it becomes clear, that other factors play a role in the usage of arrows as mental tools.

Submitted by Caroline Xavier (caroline.xavier@pucrs.br) on 2017-06-30T18:19:05Z No. of bitstreams: 1 DIS_GREICE_DE_CARLI_ROMAN_COMPLETO.pdf: 9835425 bytes, checksum: aa605361de91b916006af4710a54365b (MD5) / Made available in DSpace on 2017-06-30T18:19:05Z (GMT). No. of bitstreams: 1 DIS_GREICE_DE_CARLI_ROMAN_COMPLETO.pdf: 9835425 bytes, checksum: aa605361de91b916006af4710a54365b (MD5) Previous issue date: 2016-12-15 / Em fevereiro de 2001, o Manifesto ?gil foi proposto tendo como princ?pio equipes pequenas e co-localizadas. No entanto, ao longo destes 16 anos, a agilidade tamb?m foi posta em pr?tica em outros contextos, como por exemplo: equipes distribu?das e sistemas complexos, utilizando-se o termo "Desenvolvimento ?gil em Larga Escala". N?o h? uma defini??o clara e compreensiva de como a agilidade est? presente neste contexto. Assim, nosso trabalho preenche essa lacuna com o objetivo de caracterizar a agilidade no Desenvolvimento ?gil em Larga Escala. Neste trabalho, realizou-se um estudo organizado em duas fases. Na Fase 1, denominada Base Te?rica, realizamos um estudo do estado-da-arte da ?rea. Na Fase 2, denominado Estudo Emp?rico, n?s realizamos duas investiga??es: um estudo de campo em uma empresa ?gil em larga escala, para identificar o desenvolvimento durante o processo de transforma??o da empresa para esta nova abordagem e, um grupo focal, para identificar como as equipes ?geis em larga escala que v?m utilizando os m?todos ?geis o quanto se percebem em termos de aspectos de maturidade ?gil. Estes resultados contribuem para os pesquisadores e profissionais entenderem melhor como a agilidade e definida e percebida nestes grandes ambientes. O conhecimento e ?til para aqueles que querem entender como o desenvolvimento ?gil se adapta a tais ambientes e para pesquisadores com o objetivo de se aprofundar sobre o tema. / The Agile Manifesto was proposed in February 2001 having in mind small and collocated teams. However, agile has also been put in practice in other settings (e.g. large teams, distributed teams, complex systems) under the term ?Large-Scale Agile Development' (LSAD). There is no clear definition for and understanding of how agility is present in this setting. Thus, our work fills in this gap aiming to characterize agility in LSAD. We conducted a study organized in two phases. In Phase 1, named Theoretical Base, we conducted the state-of-the-art of the area. In Phase 2, named Empirical Study, we conducted two investigations: a field study in a large-scale agile company to identify how agility was developed during the transformation process of the company to this new approach, and a focus group to identify how large-scale agile teams that have been using agile for a certain while perceive themselves in terms of maturity in agile aspects. Findings contribute to researchers and professionals better understand how agility is defined and perceived in large settings. This knowledge is useful for those who want to enter the agile journey in such similar environments and for researchers aiming to further explore the topic.

Submitted by PPG Ci?ncia da Computa??o (ppgcc@pucrs.br) on 2018-07-16T17:26:53Z No. of bitstreams: 1 ELISA COSTA DIEL_DIS.pdf: 2030569 bytes, checksum: 97dac6ad532e10d4b88caec8f69d282e (MD5) / Approved for entry into archive by Sheila Dias (sheila.dias@pucrs.br) on 2018-07-23T11:12:32Z (GMT) No. of bitstreams: 1 ELISA COSTA DIEL_DIS.pdf: 2030569 bytes, checksum: 97dac6ad532e10d4b88caec8f69d282e (MD5) / Made available in DSpace on 2018-07-23T11:31:48Z (GMT). No. of bitstreams: 1 ELISA COSTA DIEL_DIS.pdf: 2030569 bytes, checksum: 97dac6ad532e10d4b88caec8f69d282e (MD5) Previous issue date: 2017-03-16 / Apesar de o ?gil buscar colabora??o com todos as partes envolvidas, a maioria dos projetos ?geis n?o extende essa colabora??o para o pessoal de opera??es. Problemas de comunica??o s?o um problema recorrente em equipes ?geis que tamb?m ? eminente na rela??o entre desenvolvedores e opera??es. Esta pesquisa visa compreender como a comunica??o acontece em DevOps a partir das percep??es dos praticantes. Para alcan?ar nosso objetivo, realizou-se uma Revis?o de Literatura sobre DevOps e Comunica??o, e conduziu-se um Estudo de Campo com dados qualitativos sendo coletados atrav?s de entrevistas. Os resultados indicam que hoje existem pelo menos tr?s configura??es diferentes de DevOps sendo aplicadas na ind?stria: profissionais Devs e Ops alocados na mesma equipe; uma equipe de DevOps com um conjunto de habilidades compartilhadas; e uma equipe separada de Dev e Ops trabalhando juntos. Apesar dessas configura??es, n?o foram encontradas nenhuma particularidade. Em resumo, os resultados indicam que os membros de equipes co-alocadas e multi-funcionais se comunicam melhor; ? importante trabalhar em conjunto e compartilhar conhecimentos t?cnicos; o poder de decis?o variar? de acordo com a situa??o enfrentada; entre outros. Nossas descobertas ajudam a diminuir a lacuna apontada por Erich, Amrit e Daneva entre Dev e Ops, avan?ando para uma melhor compreens?o de como profissionais DevOps colaboram, ajudando eles a melhorar suas pr?ticas de comunica??o em seu trabalho di?rio. / Even though agile actively seeks collaboration with all kinds of stakeholders, most agile projects do not extend toward the operations people. Issues in communication are a recurring issue in agile teams. Such issues are also eminent in the relationship between developers and operations. This study aims to understand how communication happens in DevOps from the perspective of practitioners. To achieve our goal, a Literature Review on DevOps and Communication was performed, and a Field Study was conducted with qualitative data being collected through interviews. Results revealed that today there are at least three different DevOps configurations being applied in the industry, being: Dev and Ops professionals allocated to the same team; a team of DevOps with a shared skill set; and a separate team of Dev and Ops working together. Despite the configurations, we did not find any particularities. In summary, results show that co-allocated and cross functional team members communicate better; it is important to work together as a single team and share technical knowledge; decision power changes based on the situation that is being faced; among others. Our findings help to narrow the gap pointed out by Erich, Amrit, and Daneva between Dev and Ops, moving towards a better understanding of how DevOps team collaborates by helping practitioners to improve their communication practices in their daily work.

Submitted by PPG Ci?ncia da Computa??o (ppgcc@pucrs.br) on 2018-10-09T13:24:12Z No. of bitstreams: 1 LUIS FERNANDES VAZ.DIS.pdf: 17076970 bytes, checksum: 6f8adcfdc62d9c6204d43c0aaaace7e5 (MD5) / Approved for entry into archive by Caroline Xavier (caroline.xavier@pucrs.br) on 2018-10-09T17:12:07Z (GMT) No. of bitstreams: 1 LUIS FERNANDES VAZ.DIS.pdf: 17076970 bytes, checksum: 6f8adcfdc62d9c6204d43c0aaaace7e5 (MD5) / Made available in DSpace on 2018-10-09T17:16:23Z (GMT). No. of bitstreams: 1 LUIS FERNANDES VAZ.DIS.pdf: 17076970 bytes, checksum: 6f8adcfdc62d9c6204d43c0aaaace7e5 (MD5) Previous issue date: 2018-03-27 / This research aimed to investigate task documentation in Software Crowdsourcing, more specifically, in the TopCoder platform. It also aimed to identify the elements that should be considered in the documentation of a task in this kind of software development. This research is of importance when considering that a Task is the component that links the other components of the software crowdsourcing model, which are: the Buyer, the Platform, and the Crowd. It is the task that expresses the Buyer?s need to the crowd members. We followed a qualitative research approach and conducted a Case Study with newcomers in Software Crowdsourcing and a Field Study with industry professionals. Data was analyzed using the Content Analysis technique. We found that, for the Case Study novices, the documentation of the task had a secondary role in the task selection. However, the need of a clear documentation become more relevant during the development of the task given that this is the moment that the instructions within the documentation need to be decoded by the developer and turned into a solution to be later submitted to the platform. For the Field Study participants, the most relevant elements related to the documentation of a task were how clear the description of a task is and their prior knowledge about the task content in order to influence its selection. Inspired on our studies? results, we propose a model for task documentation in TopCoder. We believe this model will likely aid the description of tasks in software crowdsourcing and will, as a consequence, help crowd members in their task development journey. / A presente pesquisa teve como objetivo investigar a documenta??o das tarefas disponibilizadas na plataforma TopCoder e os elementos que devem ser considerados na documenta??o de uma tarefa em Software Crowdsourcing. Esta investiga??o torna-se relevante na medida em que a Tarefa ? o elemento fundamental de liga??o entre os demais elementos do modelo de Software Crowdsourcing (Contratante, Plataforma e Multid?o). ? a Tarefa que expressa a necessidade do Contratante para os membros da multid?o. Assim, para o desenvolvimento desta investiga??o foi adotada a abordagem qualitativa, por meio de um Estudo de Caso com novatos em Software Crowdsourcing e de um Estudo de Campo, com profissionais da ind?stria. Para a an?lise e interpreta??o dos dados foi aplicada a t?cnica de An?lise de Conte?do. Como resultado desta pesquisa, constatou-se que no Estudo de Caso a documenta??o da tarefa teve um papel secund?rio quando os participantes selecionavam as tarefas. Entretanto, o papel da clareza da documenta??o surge com maior for?a durante a execu??o da tarefa, uma vez que ? neste momento que deve ser decodificada a instru??o da documenta??o a fim de realizar efetivamente a tarefa e submet?-la ? plataforma. Para os participantes do Estudo de Campo, os elementos mais relevantes referentes ? documenta??o das tarefas foram a clareza na descri??o da tarefa e o conhecimento sobre o assunto tratado pela tarefa. A partir dos resultados obtidos ? proposto um modelo de documenta??o de tarefa a ser utilizado na plataforma TopCoder. Acredita-se que com o mapeamento dos elementos identificados na pesquisa e a proposta de um modelo de documenta??o para a tarefa ser? poss?vel aprimorar a descri??o das tarefas e consequentemente as entregas realizadas pelos membros da multid?o.

<p>New technology and new innovations have for long been considered as a spring for growth. Conservation farming (CF) is a new production method introduced in rural Zambia and previous research shows that it increases yields and improves soil fertility. Even though the method is proven more efficient than conventional agriculture, only approximately 10 % of Zambia’s farmers have adopted the method. The purpose of this study is to discuss the implications of the introduction of CF on the capabilities of farmers and on economic growth. Furthermore, the study aims to explore why CF, which is proven to be more economically efficient than the conventional method, is not adopted to a larger extent in Zambia.</p><p>A qualitative study of 25 farmers, farming with either CF or conventional methods, was performed in the region of Mumbwa, Zambia. The results were divided depending on whether the farmers were using the new method or not. To analyze the selected material theories were chosen that regard economic growth and technological change, the adoption process of new innovations, incentive creation and the expansion of capabilities.</p><p>The two groups showed differences in age, the size of their land, how many crops they grew and to what extent they were working for others or hiring labor. The conclusion from the small sample of farmers is that the farmers using CF had been able to expand their capabilities in different ways. They had food for all the year, the new method allowed them to plan their time better and it was more environmentally sustainable than the old method. The negative aspect of CF is that it is not compatible with the old method in terms of social norms. CF leads to a more efficient use of capital and labor and therefore it can increase the economic growth. In terms of a new innovation, CF seems to have a relative advantage over the old method but it must be spread to a larger group of farmers to reach a breakthrough. To create a higher adoption rate of the method the farmers’ perception must be taken into account.</p> / Minor Field Study (Sida)

<p>Anledningar till att ilska väcks till liv är individuella och kan exempelvis bero på orättvis behandling eller maktlöshet. Ilska känns på liknande sätt inombords hos alla individer vilket innebär att en student som känner ilska över att kamraten fuskat på en tenta, kan uppleva liknande känslor av ilska inombords som patienten som tvingas vänta på sina mediciner. När ilska väl kommit in i kroppen måste den ”komma ut”.  Ilskans väg ut ur kroppen skiljer sig åt från person till person där en del yttrar sin ilska fysiskt medan andra yttrar den verbalt eller via tårar. När ilska försvunnit ut ur kroppen skapas möjlighet för reflektion. En del upplever ilska som en drivkraft för förändring medan andra känner skam och ånger över sitt beteende. Ilska är något vi alla har upplevt och fortsättningsvis kommer att uppleva. Att skapa en förståelse för fenomenet ilska kan skapa förutsättningar för vårdpersonalen att förstå ilska hos patienter. Genom att förstå orsakerna till varför ilska uppstår kan en bra relation mellan vårdpersonal och patient skapas vilket är av stor betydelse för att en god omvårdnad ska kunna utövas.</p> / <p>Reasons why anger evokes is individual and can elicit when a person experience unfairness or feel powerlessness. Anger feels similar on the inside among all individuals which means that a student who feels anger due to a friend who as cheated on an exam can experience the same anger as the patient who is forced to wait for his/her medications. When anger has entered the body it has to “come out”. How anger leaves the body differs from person to person where some express their anger physically while others get their anger out verbally or through tears. When anger has left the body, reflections become possible. Some people experience anger as a driving force for making a change while others feel disgrace and regret due to their behaviour. Anger is something we all have experienced and will continue to do. Understanding the phenomenon anger can create conditions for professionals to understand the patient’s anger. A good relationship between professionals and patients can be founded through understanding why anger evokes which is important for developing a good nursing care</p>

Anledningar till att ilska väcks till liv är individuella och kan exempelvis bero på orättvis behandling eller maktlöshet. Ilska känns på liknande sätt inombords hos alla individer vilket innebär att en student som känner ilska över att kamraten fuskat på en tenta, kan uppleva liknande känslor av ilska inombords som patienten som tvingas vänta på sina mediciner. När ilska väl kommit in i kroppen måste den ”komma ut”.  Ilskans väg ut ur kroppen skiljer sig åt från person till person där en del yttrar sin ilska fysiskt medan andra yttrar den verbalt eller via tårar. När ilska försvunnit ut ur kroppen skapas möjlighet för reflektion. En del upplever ilska som en drivkraft för förändring medan andra känner skam och ånger över sitt beteende. Ilska är något vi alla har upplevt och fortsättningsvis kommer att uppleva. Att skapa en förståelse för fenomenet ilska kan skapa förutsättningar för vårdpersonalen att förstå ilska hos patienter. Genom att förstå orsakerna till varför ilska uppstår kan en bra relation mellan vårdpersonal och patient skapas vilket är av stor betydelse för att en god omvårdnad ska kunna utövas. / Reasons why anger evokes is individual and can elicit when a person experience unfairness or feel powerlessness. Anger feels similar on the inside among all individuals which means that a student who feels anger due to a friend who as cheated on an exam can experience the same anger as the patient who is forced to wait for his/her medications. When anger has entered the body it has to “come out”. How anger leaves the body differs from person to person where some express their anger physically while others get their anger out verbally or through tears. When anger has left the body, reflections become possible. Some people experience anger as a driving force for making a change while others feel disgrace and regret due to their behaviour. Anger is something we all have experienced and will continue to do. Understanding the phenomenon anger can create conditions for professionals to understand the patient’s anger. A good relationship between professionals and patients can be founded through understanding why anger evokes which is important for developing a good nursing care

Les cadriciels et les bibliothèques sont indispensables aux systèmes logiciels d'aujourd'hui. Quand ils évoluent, il est souvent fastidieux et coûteux pour les développeurs de faire la mise à jour de leur code. Par conséquent, des approches ont été proposées pour aider les développeurs à migrer leur code. Généralement, ces approches ne peuvent identifier automatiquement les règles de modification une-remplacée-par-plusieurs méthodes et plusieurs-remplacées-par-une méthode. De plus, elles font souvent un compromis entre rappel et précision dans leur résultats en utilisant un ou plusieurs seuils expérimentaux. Nous présentons AURA (AUtomatic change Rule Assistant), une nouvelle approche hybride qui combine call dependency analysis et text similarity analysis pour surmonter ces limitations. Nous avons implanté AURA en Java et comparé ses résultats sur cinq cadriciels avec trois approches précédentes par Dagenais et Robillard, M. Kim et al., et Schäfer et al. Les résultats de cette comparaison montrent que, en moyenne, le rappel de AURA est 53,07% plus que celui des autre approches avec une précision similaire (0,10% en moins). / Software frameworks and libraries are indispensable to today's software systems. As they evolve, it is often time-consuming for developers to keep their code up-to-date. Approaches have been proposed to facilitate this. Usually, these approaches cannot automatically identify change rules for one-replaced-by-many and many-replaced-by-one methods, and they trade off recall for higher precision using one or more experimentally-evaluated thresholds. We introduce AURA (AUtomatic change Rule Assistant), a novel hybrid approach that combines call dependency and text similarity analyses to overcome these limitations. We implement it in a Java system and compare it on five frameworks with three previous approaches by Dagenais and Robillard, M. Kim et al., and Schäfer et al. The comparison shows that, on average, the recall of AURA is 53.07% higher while its precision is similar (0.10% lower).

Les antipatrons sont de “mauvaises” solutions à des problèmes récurrents de conception logicielle. Leur apparition est soit due à de mauvais choix lors de la phase de conception soit à des altérations et des changements continus durant l’implantation des programmes. Dans la littérature, il est généralement admis que les antipatrons rendent la compréhension des programmes plus difficile. Cependant, peu d’études empiriques ont été menées pour vérifier l’impact des antipatrons sur la compréhension. Dans le cadre de ce travail de maîtrise, nous avons conçu et mené trois expériences, avec 24 sujets chacune, dans le but de recueillir des données sur la performance des sujets lors de tâches de compréhension et d’évaluer l’impact de l’existence de deux antipatrons, Blob et Spaghetti Code, et de leurs combinaisons sur la compréhension des programmes. Nous avons mesuré les performances des sujets en terme : (1) du TLX (NASA task load index) pour l’éffort ; (2) du temps consacré à l’exécution des tâches ; et, (3) de leurs pourcentages de réponses correctes. Les données recueillies montrent que la présence d’un antipatron ne diminue pas sensiblement la performance des sujets alors que la combinaison de deux antipatrons les entrave de façon significative. Nous concluons que les développeurs peuvent faire face à un seul antipatron, alors que la combinaison de plusieurs antipatrons devrait être évitée, éventuellement par le biais de détection et de réusinage. / Antipatterns are “poor” solutions to recurring design problems which are conjectured in the literature to make object-oriented systems harder to maintain. However, little quantitative evidence exists to support this conjecture. We performed an empirical study to investigate whether the occurrence of antipatterns does indeed affect the understandability of systems by developers during comprehension and maintenance tasks. We designed and conducted three experiments, each with 24 subjects, to collect data on the performance of these subjects on basic tasks related to program comprehension and assess the impact of two antipatterns and their combinations: Blob and Spaghetti Code. We measured the subjects’ performance with: (1) TLX (NASA task load index) for their effort; (2) the time that they spent performing their tasks; and, (3) their percentages of correct answers. The collected data shows that the occurrence of one antipattern does not significantly decrease developers’ performance while the combination of two antipatterns impedes developers significantly. We conclude that developers can cope with one antipattern but that combinations thereof should be avoided possibly through detection and refactorings.