No description available.

This thesis deals with the quality assurance of software developed within a small business and also it covers software testing as a means for checking the quality of software. The goal of this thesis is to reveal weaknesses in quality assurance of software developed with particular small business and weaknesses in quality of developed software itself. The real benefit of this thesis is to provide solution to discovered weaknesses by defining appropriate activities and tools of software quality assurance. The main purpose of these suggested activities is to improve the product quality to fulfill the expectations of users and developers. At first, it is necessary to determine the factors influencing the quality of the software and the causes leading to a decline in quality. This issue, together with the theoretical bases of software quality assurance is covered in the first part of thesis. The current state of quality assurance in the company is analyzed in the second part of the thesis. Appropriate measures, activities and tools that will help improve the software quality, are recommended based on the results of this analysis in the final section of this thesis.

This diploma thesis describes the position of software testing according to Lean software development approach and its appliacation in testing team. At first. Lean concept is introduced with its basic principles, then the thesis focuses on the position of testing in the Lean software development itself. At the beginning this thesis deals with agile approach to development and software testing position in Lean software development. This concept defines several principles, which should be followed by testing teams. These principles and its general application in testing teams are subsequently explained. The second part is devoted to Lean software development in a real company. I am working as a tester and I already know the development and testing processes -- that's why one of my goals is to apply this approach to our testing team. Firstly the default situation in our company is introduced. Used technics and types of used testing tools are listed together with procedures and also the disadvantages and troubles, which occurred during the original testing process. Then the following parts are devoted to Lean software development principles application in our testing team followed with description of improvements and advantages delivered by the principles.

The advancement in technology has revolutionized the role of software in recent years. Software usage is practically found in all areas of the industry and has become a prime factor in the overall working of the companies. Simultaneously with an increase in the utilization of software, the software quality assurance parameters have become more crucial and complex. Currently the quality measurement approaches, standards, and models that are applied in the software industry are extremely divergent. Many a time the correct approach will wind up to be a combination of di erent concepts and techniques from di erent software assurance approaches [1]. Thus, having a platform that provides a single workspace for incorporating multiple software quality assurance approaches will ease the overall software quality process. In this thesis we have proposed a theoretical framework for distributed software quality assurance, which will be able to continuously monitor a source code repository; create a snapshot of the system for a given commit (both past and present); the snapshot can be used to create a multi-granular blockchain of the system and its metrics (i.e.,metadata) which we believe will let the tool developers and vendors participate continuously in assuring quality and security of systems and in the process be accessible when required while being rewarded for their services.

Network usage is an important quality metric for mobile apps. Slow networks, low monthly traffic quotas and high roaming fees restrict mobile users’ amount of usable Internet traffic. Companies wanting their apps to stay competitive must be aware of their network usage and changes to it. Short feedback loops for the impact of code changes are key in agile software development. To notify stakeholders of changes when they happen without being prohibitively expensive in terms of manpower the change detection must be fully automated. To further decrease the manpower overhead cost of implementing network usage change detection the system need to have low configuration requirements, and keep the false positive rate low while managing to detect larger changes. This thesis proposes an automated change detection method for network activity to quickly notify stakeholders with relevant information to begin a root cause analysis after a change in the network activity is introduced. With measurements of the Spotify’s iOS app we show that the tool achieves a low rate of false positives while detecting relevant changes in the network activity even for apps with dynamic network usage patterns as Spotify. / Nätverksaktivitet är ett viktigt kvalitetsmått för mobilappar. Mobilanvändare begränsas ofta av långsamma nätverk, låg månatlig trafikkvot och höga roamingavgifter. Företag som vill ha konkurrenskraftiga appar behöver vara medveten om deras nätverksaktivitet och förändringar av den. Snabb återkoppling för effekten av kodändringar är vitalt för agil programutveckling. För att underrätta intressenter om ändringar när de händer utan att vara avskräckande dyrt med avseende på arbetskraft måste ändringsdetekteringen vara fullständigt automatiserad. För att ytterligare minska arbetskostnaderna för ändringsdetektering av nätverksaktivitet måste detekteringssystemet vara snabbt att konfigurera, hålla en låg grad av felaktig detektering samtidigt som den lyckas identifiera stora ändringar. Den här uppsatsen föreslår ett automatiserat förändringsdetekteringsverktyg för nätverksaktivitet för att snabbt meddela stakeholders med relevant information för påbörjan av grundorsaksanalys när en ändring som påverkar nätverksaktiviteten introduceras. Med hjälp av mätningar på Spotifys iOS-app visar vi att verktyget når en låg grad av felaktiga detekteringar medan den identifierar ändringar i nätverksaktiviteten även för appar med så dynamisk nätverksanvändning som Spotify.

El presente trabajo de investigación tiene como objetivo el estudio de la línea de servicio de Certificación de Software de la empresa consultora TI y requiere resolver la problemática en la evaluación de los productos de desarrollo de software que impactan directamente en el cumplimiento de sus SLA, generando grandes pérdidas económicas. En el análisis cuantitativo, se identificó que existen inadecuadas técnicas para la evaluación con un impacto en el cumplimiento de los umbrales definidos en cada SLA, lo cual ha generado grandes pérdidas económicas en los últimos años por penalización. Ante esta situación caótica, se propone la implementación de un modelo de evaluación de calidad del producto de Software, la cual propone lineamientos de acuerdo con estándares y prácticas internacionales para la evaluación de la calidad, ayudando a incrementar la calidad de sus productos y la satisfacción del cliente, debido que se evidencia pérdidas económicas que se están incrementando anualmente. En este trabajo de investigación se hace una revisión general de los estándares de evaluación de calidad de producto de Software, se realiza una evaluación del cumplimiento de la norma ISO/IEC 25010 en la empresa y se propone un plan de mejora. Como conclusión, se recomienda la ejecución de la propuesta de implementación como apoyo estratégico al cumplimiento de los objetivos estratégicos de la empresa, reduciendo el riesgo de pérdidas económicas e incrementar la capacidad para ejecutar nuevas STD (Solicitudes Técnicas de Desarrollo), que permitirá a la empresa ser más rentable y brindar un servicio de mejor calidad. / The following work of research has as main subject the study of the software certification service line from the consulting TI company and requires solving the problematic in the evaluation of software development products that has a direct impact in the fulfillment of their SLA, generating large economic losses. In the quantitative analysis, it was identified there are inadequate techniques for the evaluation with an impact of the fulfillment of the thresholds defined on each SLA, which has generated large economic losses in the last year due to penalty. Given this chaotic situation, the implementation of a software product quality evaluation model is proposed, which provides guidelines in accordance with international standards and practices for the evaluation of quality, helping to increase the quality of its products and customer satisfaction, because there is evidence of economic losses that are increasing annually. In this research work a general review of the existing software product quality evaluation standards is made, an evaluation of compliance of the ISO/IEC 25010 norm in the company will be carried out and an improvement plan will be proposed. In conclusion, the implementation of the proposal is recommended as strategic support for the fulfillment of the strategic objectives of the company, reducing the risk of economic losses and increasing the capacity to execute new STD (Technical Development Requests), which will allow the company to be more profitable and provide a better quality service. / Trabajo de investigación

In recent years, there has been a surge in research on theimpact of architectural smells on software maintainability.Maintainability in turn encompasses several other qualityattributes as sub-characteristics, such as modularity andtestability. However, the empirical evidence establishing aclear relationship between these quality attributes andarchitectural smells has been lacking. This study aims to fillthis gap by examining the correlation between sevenarchitectural smells and testability/modularity across 378versions of eight open-source projects. A self-developedtool—ASAT—was used to collect data on architecturalsmells and metrics relating to modularity and testability. Thecollected data was analyzed to reveal correlations at both theproject-level and within packages. Contrary to expectations,the findings show that, generally, there is no negativecorrelation between smells and modularity at the projectlevel, except for the Dense Structure smell. Remarkably,project-level testability showed the opposite result.However, a rival explanation proposes that the increasingsize of a project may be a stronger factor in this relationship.Similarly, package-level smells, as a whole, did not exhibit anegative correlation with testability. However, most smellsdemonstrated a stronger negative relationship with thequality attributes they were claimed to impair, incomparison to their counterparts. This empirical evidencesubstantiates the assertion that specific architectural smellsindeed relate to distinct quality attributes, which hadpreviously only been supported by argument.

<p>Microservices have emerged as a popular pattern for developing large-scale applications in cloud environments for their flexibility, scalability, and agility benefits. However, microservices make management more complex due to their scale, multiple languages, and distributed nature. Orchestration and automation tools like Kubernetes help deploy microservices running simultaneously, but it can be difficult for an operator to understand their behaviors, interdependencies, and interactions. In such a complex and dynamic environment, performance problems (e.g., slow application responses and high resource usage)  require significant human effort spent on diagnosis and recovery. Moreover, manual diagnosis of cloud microservices tends to be tedious, time-consuming, and impractical. Effective and automated performance analysis and anomaly detection require an observable system, which means an application's internal state can be inferred by observing and tracking metrics, traces, and logs. Traditional APM uses libraries and SDKs to improve application monitoring and tracing but has additional overheads of rewriting, recompiling, and redeploying the applications' code base. Therefore, there is a critical need for a standardized automated microservices observability solution that does not require rewriting or redeploying the application to keep up with the agility of microservices.</p> <p><br></p> <p>This thesis studies observability for microservices and implements an automated Extended Berkeley Packet Filter (eBPF) based observability solution. eBPF is a Linux feature that allows us to write extensions to the Linux kernel for security and observability use cases. eBPF does not require modifying the application layer and instrumenting the individual microservices. Instead, it instruments the kernel-level API calls, which are common across all hosts in the cluster. eBPF programs provide observability information from the lowest-level system calls and can export data without additional performance overhead. The Prometheus time-series database is leveraged to store all the captured metrics and traces for analysis. With the help of our tool, a DevOps engineer can easily identify abnormal behavior of microservices and enforce appropriate countermeasures. Using Chaos Mesh, we inject anomalies at the network and host layer, which we can identify with root cause identification using the proposed solution. The Chameleon cloud testbed is used to deploy our solution and test its capabilities and limitations.</p>

<p>Physical security is one of the most basic human needs. People care about it for various reasons; for the safety and security of personnel, to protect private assets, to prevent crime, and so forth. With the recent proliferation of AI, various smart physical security systems are getting introduced to the world. Many researchers and engineers are working on developing AI-driven physical security systems that have the capability to identify potential security threats by monitoring and analyzing data collected from various sensors. One of the most popular ways to detect unauthorized entrance to restricted space is using face recognition. With a collected stream of images and a proper algorithm, security systems can recognize faces detected from the image and send an alert when unauthorized faces are recognized. In recent years, there has been active research and development on neural networks for face recognition, e.g. FaceNet is one of the advanced algorithms. However, not much work has been done to showcase what kind of end-to-end system architecture is effective for running heavy-weight computational loads such as neural network inferences. Thus, this study explores different hardware options that can be used in security systems powered by a state-of-the-art face recognition algorithm and proposes that an edge computing based approach can significantly reduce the overall system latency and enhance the system reactiveness. To analyze the pros and cons of the proposed system, this study presents two different end-to-end system architectures. The first system is an edge computing-based system that operates most of the computational tasks at the edge node of the system, and the other is a traditional application server-based system that performs core computational tasks at the application server. Both systems adopt domain-specific hardware, Tensor Processing Units, to accelerate neural network inference. This paper walks through the implementation details of each system and explores its effectiveness. It provides a performance analysis of each system with regard to accuracy and latency and outlines the pros and cons of each system.</p> <p><br></p>

[pt] Desenvolvedores realizam mudanças de código constantemente durante a vida de um projeto de software. Essas mudanças podem induzir a degradação progressiva do design. A degradação do design pode ser reduzida ou acelerada por fatores que interagem em cada mudança. Esses fatores podem variar desde uma mudança ou ação de reparo específica – e.g., refatorações – até a maneira como os desenvolvedores contribuem e discutem mudanças. Entretanto, estudos anteriores não exploram como esses fatores interagem e influenciam na degradação do design. Eles apenas focam em alguns fatores e tendem a os investigar em isolamento. Estudar os fatores em isolamento pode não explicar adequadamente qual é o conjunto mais relevante de interações entre fatores e qual sua influência na degradação do design. Isso pode indicar que abordagens existentes para evitar ou mitigar a degradação do design são incompletas, já que elas não consideram interações entre fatores que podem ser relevantes. Portanto, essa dissertação relata uma investigação que almeja aumentar a compreensão sobre como uma ampla gama de interações entre fatores pode afetar a degradação do design, para que consequentemente possam ser investigadas práticas efetivas para evitar ou mitigar esse fenômeno. Para tal fim, nós realizamos uma análise aprofundada buscando preencher lacunas no conhecimento existente sobre dois tipos de fatores: fatores relacionados ao processo (i.e. relacionados às mudanças e seus resultados produzidos) e fatores relacionados ao desenvolvedor (i.e. relacionados ao desenvolvedor trabalhando nas mudanças). Nós focamos em analisar os efeitos de possíveis interações entre os fatores previamente mencionados e uma série de sub-fatores, no que diz respeito como essas interações afetam módulos que sofreram diferentes níveis de degradação. Por exemplo, nós observamos que: (1) individualmente, tanto o sub-fator relacionado ao desenvolvedor que representa um desenvolvedor novato (que está contribuindo pela primeira vez), quanto o sub-fator relacionado ao processo que representa tamanho de uma mudança, não se mostraram relacionados a efeitos negativos na qualidade de código das classes alteradas. Porém, analisando interações entre fatores, nós observamos que mudanças em que esses dois fatores interagem tendem a ter um efeito negativo no código, causando degradação. Interessantemente, esse comportamento não se alterou mesmo quando mudança foi introduzida através de uma pull request (o que frequentemente inicia um processo de revisão de código), (2) surpreendentemente, refatorações de extração frequentemente não tem um efeito positivo na qualidade do código, enquanto, em contrapartida, as refatorações de movimentação foram predominantemente positivas. Nós também discutimos como esses achados apresentados na dissertação podem ajudar desenvolvedores e pesquisadores na melhoria de suas diretrizes sobre como evitar e monitorar a degradação do design. / [en] Developers constantly perform code changes throughout the lifetime of a project. These changes may induce the introduction of design decay over time. Design decay may be reduced or accelerated by interacting factors that underlie each change. These factors may come from specific actions of change or repair – e.g., refactorings – to how developers contribute and discuss the changes. However, existing studies do not explain how these factors interact and influence design decay. They solely tend to focus on a few types of factors, and often consider them in isolation. Interactions between factors may cause different outcomes than those previously studied. Studying factors in isolation may not properly explain what are the most relevant set of interacting factors that influence design decay. This may indicate that existing approaches to avoid or mitigate design decay are misleading since they do not consider potentially relevant interactions between various factors. Thus, this dissertation reports an investigation that aims to increase the understanding of how a wide range of interacting factors can influence design decay in order to facilitate the investigation of which practices can be used to avoid or mitigate design decay. To this end, we performed an in-depth analysis to fill knowledge gaps on two types of factors: process-related (i.e., related to changes and their produced outcomes) and developer-related (i.e., related to the developer working on the changes) factors. We focused on analyzing the effects of potential interactions between the aforementioned factors and 12 sub-factors with regards to how they affected modules with different levels of decay. We observed diverging decay patterns in these modules. Our results indicate that both types of factors can be used to distinguish between different decay levels in classes. We have also observed that: (1) individually, the developer-related subfactor that represented first-time contributors, as well as the process-related one that represented size of the changes, did not exert negative effects on the changed classes. However, when analyzing specific factor interactions, we saw that changes where both of these factors interacted tended to have a negative effect and led to decay. Interestingly, this behaviour did not alter even when the change was introduced via pull request (which usually triggers a code review process); (2) surprisingly, extraction-type refactorings often do not have a positive effect on code quality, while, by contrast, move refactorings were mostly positive. We also discuss how these findings in this dissertation can aid developers and researchers in improving their guidelines for the avoidance and monitoring of design decay.