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.

Denna studie undersöker hur AI-genererad kod för automatiserad testning av frontend kan kvalitetssäkras genom att utveckla ett ramverk med riktlinjer. Problematiken med kvalitet och trovärdighet i generativ AI-baserade lösningar belyses, där AI ofta producerar kod med varierande kvalitet och anpassning till den specifika kontexten. Genom en kombination av litteraturstudier och en intervju med expert inom området identifieras centrala kvalitetsaspekter såsom kodens läsbarhet, struktur, dokumentation, och underhållbarhet.  Studiens mål är att framställa ett ramverk som praktiskt kan tillämpas för att granska och säkerställa kvaliteten i AI-genererad kod för automatiserad testning av frontend. Ramverket bygger på en kvalitativ analys av både teoretisk och empirisk data och erbjuder vägledning för hur generativ AI kan användas effektivt inom systemutveckling. Det föreslagna ramverket förväntas underlätta testprocessen och minska kravet på manuell kodgranskning, samtidigt som det adresserar de unika utmaningar som generativ AI medför. Framtida forskning rekommenderas för att validera och vidareutveckla ramverket, med särskild tonvikt på praktisk tillämpning och anpassning till olika organisatoriska behov. / This study examines how AI-generated code for automated frontend testing can be quality assured by developing a framework with specific guidelines. The issue of quality and reliability in generative AI-based solutions is highlighted, as AI often produces code with varying quality and contextual accuracy. Through a combination of literature studies and an interview with an expert in the field, central quality aspects such as code readability, structure, documentation, and maintainability are identified.  The aim of the study is to create a framework that can be practically applied to review and ensure the quality of AI-generated code for automated frontend testing. The framework is based on a qualitative analysis of both theoretical and empirical data and provides guidance on how generative AI can be effectively used in system development. The proposed framework is expected to facilitate the testing process and reduce the need for manual code review while addressing the unique challenges posed by generative AI. Future research is recommended to validate and further develop the framework, with particular emphasis on practical application and adaptation to various organizational needs.

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.

<p dir="ltr">The research focuses on integrating automation, specifically security and Infrastructure as Code (IaC), into the Software Development Life Cycle (SDLC). This integration aims to enhance the efficiency, quality, and security of software development processes. The study explores the benefits and challenges associated with implementing DevSecOps practices, which combine development, security, and operations into a unified process.</p><h3>Background and Motivation</h3><p dir="ltr">The rise of new technologies and increasing demand for high-quality software have made software development a crucial aspect of business operations. The SDLC is essential for ensuring that software meets user requirements and maintains high standards of quality and security. Security, in particular, has become a critical focus due to the growing threat of cyber-attacks and data breaches. By integrating security measures early in the development process, companies can better protect their software and data.</p><h3>Objectives</h3><p dir="ltr">The primary objectives of this research are:</p><ol><li><b>Examine the Benefits and Challenges</b>: To investigate the advantages and difficulties of integrating DevSecOps and IaC within the SDLC.</li><li><b>Analyze Impact on Security and Quality</b>: To assess how automation affects the security and quality of software developed through the SDLC.</li><li><b>Develop a Framework</b>: To create a comprehensive framework for integrating DevSecOps and IaC into the SDLC, thereby improving security and reducing time to market.</li></ol><h3>Methodology</h3><p dir="ltr">The research employs a mixed-methods approach, combining qualitative and quantitative methods:</p><ul><li><b>Qualitative</b>: A literature review of existing research on DevSecOps, IaC, and SDLC, providing a theoretical foundation and context.</li><li><b>Quantitative</b>: Building a CI/CD (Continuous Integration/Continuous Deployment) pipeline from scratch to collect empirical data. This pipeline serves as a case study to gather insights into how automation impacts software security and quality.</li></ul><h3>Tools and Technologies</h3><p dir="ltr">The study utilizes various tools, including:</p><ul><li><b>GitHub</b>: For version control and code repository management.</li><li><b>Jenkins</b>: To automate the CI/CD pipeline, including building, testing, and deploying applications.</li><li><b>SonarQube</b>: For static code analysis, detecting code quality issues, and security vulnerabilities.</li><li><b>Amazon Q</b>: An AI-driven tool used for code generation and security scanning.</li><li><b>OWASP Dependency-Check</b>: To identify vulnerabilities in project dependencies.</li><li><b>Prometheus and Grafana</b>: For monitoring and collecting metrics.</li><li><b>Terraform</b>: For defining and deploying infrastructure components as code.</li></ul><h3>Key Findings</h3><ul><li><b>Reduction in Defect Density</b>: Automation significantly reduced defect density, indicating fewer bugs and higher code quality.</li><li><b>Increase in Code Coverage</b>: More comprehensive testing, leading to improved software reliability.</li><li><b>Reduction in MTTR, MTTD, and MTTF</b>: Enhanced system reliability and efficiency, with faster detection and resolution of issues.</li><li><b>Improved System Performance</b>: Better performance metrics, such as reduced response time and increased throughput.</li></ul><h3>Conclusion</h3><p dir="ltr">The study concludes that integrating security and IaC automation into the SDLC is crucial for improving software quality, security, and development efficiency. However, despite the clear benefits, many companies are hesitant to adopt these practices due to perceived challenges, such as the upfront investment, complexity of implementation, and concerns about ROI (Return on Investment). The research underscores the need for continued innovation and adaptation in software development practices to meet the evolving demands of the technological landscape.</p><h3>Areas for Further Research</h3><p dir="ltr">Future studies could explore the broader impact of automation on developer productivity, job satisfaction, and long-term security practices. There is also potential for developing advanced security analysis techniques using machine learning and artificial intelligence, as well as investigating the integration of security and compliance practices within automated SDLC frameworks.</p>