Desenvolvimento Guiado por Testes (TDD) e uma das praticas sugeridas na Programacao Extrema. A mecanica da pratica e simples: o programador escreve o teste antes de escrever o codigo. E, portanto, possivel inferir que a pratica de TDD e uma pratica de testes de software. Entretanto, muitos autores de livros conhecidos pela industria e academia afirmam que os efeitos da pratica vao alem. Segundo eles, TDD ajuda o desenvolvedor durante o processo de criacao do projeto classes, fazendo-os criar classes menos acopladas e mais coesas. Entretanto, grande parte dos trabalhos da literatura sao voltados a descobrir se a pratica faz diferenca na qualidade do codigo gerado, mas poucos sao os autores que discutem como a pratica realmente auxilia. Mesmo os proprios praticantes nao entendem ou conseguem expressar bem como a pratica os guia. Este trabalho tem por objetivo compreender melhor os efeitos de TDD e como sua pratica influencia o desenvolvedor durante o processo de projeto de sistemas orientados a objetos. Para entende-las, neste trabalho optamos por um estudo exploratorio essencialmente qualitativo, no qual participantes foram convidados a resolver exercicios pre-preparados utilizando TDD e, a partir dos dados colhidos nessa primeira parte, nos levantamos detalhes sobre como a pratica influenciou as decisoes de projeto de classes dos participantes por meio de entrevistas. Ao final, observamos que a pratica de TDD pode guiar o desenvolvedor durante o processo de criacao do projeto de classes por meio de constantes feedbacks sobre a qualidade do projeto. Esses feedbacks alertam desenvolvedores sobre possiveis problemas, como alto acoplamento ou baixa coesao. Os desenvolvedores, por sua vez, devem interpretar e melhorar o projeto de classes. Este trabalho catalogou e nomeou os padroes de feedback percebidos pelos participantes. / Test-Driven Development (TDD) is one of the suggested practices in Extreme Programming (XP). The mechanical is simple: the developer writes a test before writing the implementation. Thus, TDD is often seen as a software testing technique. However, many famous book authors suggest that TDD can help developers during the class design creation process, enabling developers to create less coupled highly cohesive classes. Most of the academic studies are interested on finding the difference between a TDDd and a non-TDDd code. Only a few of them discuss how the practice really supports class design. Even practitioners do not understand how the practice guides them. This work aims to understand better the effects of TDD and how the practice influences the practitioner during the class design process in object-oriented systems. To better understand them, we did a essencially qualitative explorative study, in which participants were invited to solve a set of pre-prepared exercises using TDD and, based on the gathered data, we retrieved details of how the practice influenced the developers class design decisions through interviews. At the end, we observed that the practice of TDD can guide developers during the class design creation process through constant feedback about its quality. These feedbacks alert developers about possible problems, such as high coupling or low cohesion. Developers then should interpret and improve the class design accordingly. This study also catalogues the TDD feedback patterns perceived by the participants.

Many web services today give users the opportunity to sign in using an account belonging to a different service. Letting users authenticate themselves using another service eliminates the need of a user having to create a new identity for each service they use. Redpill Linpro uses the open source platform SonarQube for code quality inspection. Since developers in the company are registered users of another open source platform named OpenShift, they would like to authenticate themselves to SonarQube using their OpenShift identity. Our task was to create a plugin that offers users the functionality to authenticate themselves to SonarQube using OpenShift as their identity provider by applying the authentication framework OAuth. Theproject resulted in a plugin of high code quality according to SonarQube’s assessment. RedpillLinpro will use the plugin to easily access SonarQube’s functionality when using theapplication in their developer platform.

Desenvolvimento Guiado por Testes (TDD) e uma das praticas sugeridas na Programacao Extrema. A mecanica da pratica e simples: o programador escreve o teste antes de escrever o codigo. E, portanto, possivel inferir que a pratica de TDD e uma pratica de testes de software. Entretanto, muitos autores de livros conhecidos pela industria e academia afirmam que os efeitos da pratica vao alem. Segundo eles, TDD ajuda o desenvolvedor durante o processo de criacao do projeto classes, fazendo-os criar classes menos acopladas e mais coesas. Entretanto, grande parte dos trabalhos da literatura sao voltados a descobrir se a pratica faz diferenca na qualidade do codigo gerado, mas poucos sao os autores que discutem como a pratica realmente auxilia. Mesmo os proprios praticantes nao entendem ou conseguem expressar bem como a pratica os guia. Este trabalho tem por objetivo compreender melhor os efeitos de TDD e como sua pratica influencia o desenvolvedor durante o processo de projeto de sistemas orientados a objetos. Para entende-las, neste trabalho optamos por um estudo exploratorio essencialmente qualitativo, no qual participantes foram convidados a resolver exercicios pre-preparados utilizando TDD e, a partir dos dados colhidos nessa primeira parte, nos levantamos detalhes sobre como a pratica influenciou as decisoes de projeto de classes dos participantes por meio de entrevistas. Ao final, observamos que a pratica de TDD pode guiar o desenvolvedor durante o processo de criacao do projeto de classes por meio de constantes feedbacks sobre a qualidade do projeto. Esses feedbacks alertam desenvolvedores sobre possiveis problemas, como alto acoplamento ou baixa coesao. Os desenvolvedores, por sua vez, devem interpretar e melhorar o projeto de classes. Este trabalho catalogou e nomeou os padroes de feedback percebidos pelos participantes. / Test-Driven Development (TDD) is one of the suggested practices in Extreme Programming (XP). The mechanical is simple: the developer writes a test before writing the implementation. Thus, TDD is often seen as a software testing technique. However, many famous book authors suggest that TDD can help developers during the class design creation process, enabling developers to create less coupled highly cohesive classes. Most of the academic studies are interested on finding the difference between a TDDd and a non-TDDd code. Only a few of them discuss how the practice really supports class design. Even practitioners do not understand how the practice guides them. This work aims to understand better the effects of TDD and how the practice influences the practitioner during the class design process in object-oriented systems. To better understand them, we did a essencially qualitative explorative study, in which participants were invited to solve a set of pre-prepared exercises using TDD and, based on the gathered data, we retrieved details of how the practice influenced the developers class design decisions through interviews. At the end, we observed that the practice of TDD can guide developers during the class design creation process through constant feedback about its quality. These feedbacks alert developers about possible problems, such as high coupling or low cohesion. Developers then should interpret and improve the class design accordingly. This study also catalogues the TDD feedback patterns perceived by the participants.

The goal of the diploma thesis "Upgrade of agile development support tool" is to study agile methodologies and its use in practice. Thesis is focused on the Scrum framework used by The Corporate Technology department of Siemens, s.r.o. in Brno. Furthermore the thesis analyzes and compares the most used software support tools for agile methodologies which also gives an inspiration for the upgrade of support tool used by the department of Siemens. Thesis identifies possible upgrades based on an analysis with the goal to make agile development even more effective. Results were consulted with the representative of the Siemens company and then modules for Code review and Retrospective were chosen to implement. Implementation consists even of some minor upgrades of the tool. Goals of all implemented upgrades were to save time, optimize administrative work and make development even more effective. Benefits and further upgrades are consulted at the end of the thesis.

The rise of Agile project methodologies has increased the success rate of software development projects, but recent studies show that, even though the risk of failing has lessened, only 31% of the completed software development projects are declared as successful while the rest are declared either challenged or failed. A concept called Pair Programming that derives from agile methodologies is widely and basically always used by developers but in present time as we are heading towards a more remote environment and Distributed Pair Programming has become a hot topic. At its core, it is the same as Pair Programming, but the coding session is conducted in a distributed setting, meaning, the two developers are not sitting next to each other. There are little to no studies conducted about DPPs impact on software development projects and if DPP has the potential to mitigate risk factors that may arise while implementing code in an agile software development project.   The purpose of this thesis has been to research and discover what the perceived benefits and drawback of Distributed Pair Programming (DPP) are and which factors that are the most harmful to a software development project and if DPP can facilitate higher success rates. To answer the research questions, a qualitative research method has been used. The empirical data have been gathered by conducting 6 semi structured interviews with developers. Further, a thematic analysis has been carried through with the intent to easily map out the different themes that appears during the interviews.     The findings from the conducted study shows that there are multiple drawbacks and benefits. According to the informants, the benefits outweigh the drawbacks in such a manner that by not conducting DPP, they set themselves up for setbacks. It is very beneficial when onboarding a new team member and when tackling tougher problems. When it comes to implementing DPP in a successful manner there is a need for a digital infrastructure that supports verbal communication, web camera, screensharing and collaboration tools. / Ökningen av agila projektmetoder har ökat framgångsfrekvensen för programvaruutvecklingsprojekt, men nyare studier visar att även om risken för att misslyckas har minskat, förklaras endast 31 % av de avslutade programvaruutvecklingsprojekten som framgångsrika medan resten förklaras antingen utmanade eller misslyckades. Ett koncept som kallas för parprogrammering som härrör från gila metoder används i stor utsträckning och i princip alltid av utvecklare, men för närvarande är vi på väg mot en mer digital miljö och distribuerad parprogrammering(DPP) har blivit ett hett ämne. I grunden är det samma sak som parprogrammering men kodningssessionen genomförs i en distribuerad miljö, vilket innebär att de två utvecklarna inte sitter bredvid varandra. Det finns väldigt få studier utförda om DPPs inverkan på programvaruutvecklingsprojekt och om DPP har potential att mildra riskfaktorer som kan uppstå när kod implementeras i ett agilt programvaruutvecklingsprojekt. Syftet med detta examensarbete har varit att undersöka och upptäcka vad de upplevda fördelarna och nackdelarna med DPP är och vilka faktorer som är mest skadliga för ett programvaruutvecklingsprojekt och om DPP kan främja högre framgångsfrekvens. För att besvara forskningsfrågorna har en kvalitativ forskningsmetod använts. Empirin har samlats in genom att genomföra 6 semistrukturerade intervjuer med utvecklare. Vidare har en tematisk analys genomförts i syfte att enkelt kartlägga de olika teman som framställts under intervjuerna. Resultaten från den genomförda studien visar att det finns flera nackdelar och fördelar. Enligt informanterna uppväger fördelarna nackdelarna på ett sådant sätt att man genom att inte bedriva DPP dukar upp för problem. Det är mycket fördelaktigt när en ny teammedlem ska introduceras och när du tar itu med ett tufft problem. När det gäller att implementera DPP på ett framgångsrikt sätt finns ett behov av bra digital infrastruktur som stödjer verbal kommunikation, webbkamera, skärmdelning och samarbetsverktyg.

Two tasks that software engineers constantly perform are writing code that is easy to evolve and maintain, and detecting poorly written pieces of code. For the former, software engineers commonly rely on well-known software architecture styles, such as Model-View-Controller (MVC). To the latter, they rely on code metrics and code smell detection approaches. However, up to now, these code metrics and code smell approaches do not take into account underlying architectureall classes are assessed as if they were the same. In practice, software developers know that classes differ in terms of responsibilities and implementation, and thus, we expect these classes to present different levels of coupling, cohesion, and complexity. As an example, in an MVC system, Controllers are responsible for the flow between the Model and the View, and Models are responsible for representing the systems business concepts. Thus, in this thesis, we evaluate the impact of architectural roles within a system architecture on code metrics and code smells. We performed an empirical analysis in 120 open source systems, and interviewed and surveyed more than 50 software developers. Our findings show that each architectural role has a different code metric values distribution, which is a likely consequence of their specific responsibilities. Thus, we propose SATT, an approach that provides specific thresholds for architectural roles that are significantly different from others in terms of code smells. We also show that classes that play a specific architectural role contain specific code smells, which developers perceive as problems, and can impact class\' change- and defect-proneness. Based on our findings, we suggest that developers understand the responsibilities of each architectural role in their system architecture, so that code metrics and code smells techniques can provide more accurate feedback. / Duas tarefas que desenvolvedores de software constantemente fazem são escrever código fácil de ser mantido e evoluído, e detectar pedaços de código problemáticos. Para a primeira tarefa, desenvolvedores comumente fazem uso de conhecidos padrões arquiteturais, como Model-View-Controller (MVC). Para a segunda tarefa, desenvolvedores fazem uso de métricas de código e estratégias de detecção de maus cheiros de código (code smells). No entanto, até o momento, métricas de código e estratégias de detecção de maus cheiros de código não levam em conta a arquitetura do software em análise. Isso significa que todas classes são avaliadas como se umas fossem iguais às outras. Na prática, sabemos que classes são diferentes em suas responsibilidades e implementação, e portanto, esperamos que elas variem em termos de acoplamento, coesão e complexidade. Por exemplo, em um sistema MVC, Controladores são responsáveis pelo fluxo entre a camada de Modelo e a camada de Visão, e Modelos representam a visão de negócios do sistema. Nesta tese, nós avaliamos o impacto dos papéis arquiteturais em técnicas de medição de métricas de código e de detecção de maus cheiros de código. Nós realizamos um estudo empírico em 120 sistemas de código aberto, e entrevistamos e realizamos questionários com mais de 50 desenvolvedores. Nossos resultados mostram que cada papel arquitetural possui distribuições diferentes de valores de métrica de código, consequência das diferentes responsabilidades de cada papel. Como consequência, propomos SATT, uma abordagem que provê thresholds específicos para papéis arquiteturais que são significantemente diferentes de outros em termos de métricas de código. Mostramos também que classes que cumprem um papel arquitetural específico também contêm maus cheiros de código específicos. Esses maus cheiros são percebidos por desenvolvedores como problemas reais e podem fazer com que essas classes sejam mais modificadas e apresentem mais defeitos do que classes limpas. Sugerimos então que desenvolvedores entendam a arquitetura dos seus sistemas, bem como as responsabilidades de cada papel arquitetural que as classes desempenham, para que tanto métricas de código quanto estratégias de detecção de maus cheiros de código possam prover um melhor retorno.

Two tasks that software engineers constantly perform are writing code that is easy to evolve and maintain, and detecting poorly written pieces of code. For the former, software engineers commonly rely on well-known software architecture styles, such as Model-View-Controller (MVC). To the latter, they rely on code metrics and code smell detection approaches. However, up to now, these code metrics and code smell approaches do not take into account underlying architectureall classes are assessed as if they were the same. In practice, software developers know that classes differ in terms of responsibilities and implementation, and thus, we expect these classes to present different levels of coupling, cohesion, and complexity. As an example, in an MVC system, Controllers are responsible for the flow between the Model and the View, and Models are responsible for representing the systems business concepts. Thus, in this thesis, we evaluate the impact of architectural roles within a system architecture on code metrics and code smells. We performed an empirical analysis in 120 open source systems, and interviewed and surveyed more than 50 software developers. Our findings show that each architectural role has a different code metric values distribution, which is a likely consequence of their specific responsibilities. Thus, we propose SATT, an approach that provides specific thresholds for architectural roles that are significantly different from others in terms of code smells. We also show that classes that play a specific architectural role contain specific code smells, which developers perceive as problems, and can impact class\' change- and defect-proneness. Based on our findings, we suggest that developers understand the responsibilities of each architectural role in their system architecture, so that code metrics and code smells techniques can provide more accurate feedback. / Duas tarefas que desenvolvedores de software constantemente fazem são escrever código fácil de ser mantido e evoluído, e detectar pedaços de código problemáticos. Para a primeira tarefa, desenvolvedores comumente fazem uso de conhecidos padrões arquiteturais, como Model-View-Controller (MVC). Para a segunda tarefa, desenvolvedores fazem uso de métricas de código e estratégias de detecção de maus cheiros de código (code smells). No entanto, até o momento, métricas de código e estratégias de detecção de maus cheiros de código não levam em conta a arquitetura do software em análise. Isso significa que todas classes são avaliadas como se umas fossem iguais às outras. Na prática, sabemos que classes são diferentes em suas responsibilidades e implementação, e portanto, esperamos que elas variem em termos de acoplamento, coesão e complexidade. Por exemplo, em um sistema MVC, Controladores são responsáveis pelo fluxo entre a camada de Modelo e a camada de Visão, e Modelos representam a visão de negócios do sistema. Nesta tese, nós avaliamos o impacto dos papéis arquiteturais em técnicas de medição de métricas de código e de detecção de maus cheiros de código. Nós realizamos um estudo empírico em 120 sistemas de código aberto, e entrevistamos e realizamos questionários com mais de 50 desenvolvedores. Nossos resultados mostram que cada papel arquitetural possui distribuições diferentes de valores de métrica de código, consequência das diferentes responsabilidades de cada papel. Como consequência, propomos SATT, uma abordagem que provê thresholds específicos para papéis arquiteturais que são significantemente diferentes de outros em termos de métricas de código. Mostramos também que classes que cumprem um papel arquitetural específico também contêm maus cheiros de código específicos. Esses maus cheiros são percebidos por desenvolvedores como problemas reais e podem fazer com que essas classes sejam mais modificadas e apresentem mais defeitos do que classes limpas. Sugerimos então que desenvolvedores entendam a arquitetura dos seus sistemas, bem como as responsabilidades de cada papel arquitetural que as classes desempenham, para que tanto métricas de código quanto estratégias de detecção de maus cheiros de código possam prover um melhor retorno.

In the realm of software engineering, understanding the architecture and measuringthe quality of a source code is essential for maintaining and enhancing softwaresystems. However, many existing tools fall short in evaluating architectural aspects,such as detecting architectural erosion or addressing architecture-related metrics andconstraints tailored to the unique context of their systems or organisations. Thisdeficiency restricts proactive architecture governance and hinders the mitigation ofarchitecture-related risks, creating a critical gap in the analysis of software sourcecode. This thesis presents a novel approach to tackle these challenges. It proposes a graphdatabase as a data structure for analysing the source code and architecture quality andcalculating various architectural metrics of interest. The tool developed in this thesisrepresents the source code structural elements and their relationships in the graphdatabase, enabling an intuitive analysis of the source code architecture. The tool also integrates different code quality metrics parsed from Visual Studiocode metrics results, mapped to their correspondent nodes to assess the source codeoverall quality and identify potential areas of improvement. This empowers softwareengineers and developers to make informed decisions regarding refactoring, codeoptimisation, and architectural enhancements. Furthermore, the tool allows users to define the intended architecture in terms ofmodules to reveal any Architecture erosion (AEr). It also provides the flexibility toestablish custom constraints and metrics through tailored queries, accommodating theunique requirements of their system and company. A case study conducted on a real-world software project validates the effectivenessand usefulness of the proposed approach. The case study demonstrates how the toolanalysis reveals valuable insights into the source code health and identifies patternsthat can impact maintainability and scalability. The results of this research showcasethe potential of our tool as a powerful instrument for analysing the code qualityand architecture of source code, fostering more resilient and sustainable softwaresystems.

The discursive and critical positions of the ‘classic’ nineteenth-century novel, particularly the woman’s novel, in the field of adaptation studies have been dominated by long-standing concerns about textual fidelity and the generic processes of the text-screen transfer. The sociocultural patterns of adaptation criticism have also been largely ensconced in representations of literary women on screen. Taking a decisive twist from tradition, this thesis traces the evolution of representations of masculinity in the malleable characters of Rochester and Heathcliff in film and television adaptations of Charlotte Brontë’s Jane Eyre and Emily Brontë’s Wuthering Heights between 1939 and 2009. Concepts of masculinity have been a neglected area of enquiry in studies of the ‘classic’ novel on screen. Adaptations of the Brontës’ novels, as well as the adapted novels of other ‘classic’ women authors such as Jane Austen, George Eliot and Elizabeth Gaskell, increasingly foreground male character in traditionally female-oriented narratives or narratives whose primary protagonist is female. This thesis brings together industrial histories, textual frames and sociocultural influences that form the wider contexts of the adaptations to demonstrate how male characterisation and different representations of masculinity are reformulated and foregrounded through three different adaptive histories of the narratives of Jane Eyre and Wuthering Heights. Through the contours of the film and television industries, the application of text and context analysis, and wider sociocultural considerations of each period an understanding of how Rochester and Heathcliff have been transmuted and centralised within the adaptive history of the Brontë novel.