El mercado de los estudios de opinión se ha visto impulsado desde dos frentes: (1) fuerzas políticas en pugna por conseguir la victoria en las ánforas o lograr buena imagen institucional, y (2) las marcas comerciales nacionales o extranjeras, que buscan ganar una parte del mercado y posicionar nuevos productos. En este contexto, surge la necesidad por conocer las preferencias del público y es clave contar con información para plantear estrategias que empujen las preferencias en uno u otro sentido. Este tipo de servicio de estudios de opinión lo dan empresas como MIDAMCH S.A.C., la cual sirve como objeto de estudio de la presente tesis. La presente tesis propone el desarrollo de un Sistema de Información, el cual permitirá automatizar actividades claves del proceso de ejecución de estudios en la empresa MIDAMCH S.A.C. con la consiguiente reducción de tiempo de entrega de resultados, logro de eficiencia en procesos y aumento en los beneficios. Para ello, el Sistema de Información contará con una aplicación móvil y web para capturar las encuestas, validar la información capturada y consolidarla en el servidor central para su procesamiento. Para este fin, el capítulo 1 define el proyecto, presenta a la empresa objeto de estudio, la visión y misión, cadena de valor, definición del problema y sus causas, plantea los objetivos generales y específicos del proyecto, y los indicadores de éxito respectivos. Posteriormente, el capítulo 2 incorpora los 7 student outcome que exponen las evidencias que respaldan que los autores de la tesis tienen las competencias requeridas en dichos student outcome. A continuación, el capítulo 3 establece la base conceptual para: planeamiento estratégico, arquitectura empresarial, marco de trabajo de Zachman, TOGAF, arquitectura de software, y dirección de proyectos de TI. Seguidamente, el capítulo 4 detalla el análisis bajo el marco de trabajo de Zachman (Contextual y Conceptual), el modelo AS-IS y modelo TO-BE. Además, define los requerimientos del sistema, los modelos de casos de uso, mockups del SIEV1, definen drivers, conceptos de diseño, patrones de arquitectura, tácticas de diseño y se plantea un diseño mediante el modelo 4C. Finalmente, el capítulo 5 expone cómo se utilizó la guía PMBOK para la gestión del proyecto de inicio a fin, desde el Project chárter, la planificación, la definición del equipo del proyecto, la descripción del producto del proyecto, los criterios de aceptación de cada entregable, la EDT y su diccionario, el cronograma, presupuesto, recursos, plan de respuestas a riesgos, gestión de interesados y control de cambios. / The market for opinion studies has been seen promoted since two fronts: (1) political forces vying for victory in the amphoras or to achieve a good institutional image, and (2) national or foreign trademarks seeking to gain a part of the market and position new products. In this context, the necessity arises for knowing the public preferences and information is the key to raise strategies that push preferences in one way or another. This type of service for opinion studies is given by companies, such as MIDAMCH S.A.C., which serves as an object of study of this thesis. This thesis proposes the development of an Information System, it will allow to automating important activities of the implementation process of studies in the company MIDAMCH S.A.C. with the consequent time reduction in the delivery of the results, achieving process efficiency and earnings growth. For it, the Information System will have a mobile application and website, in order to survey capture, validate that information and consolidate it on the central server for its processing. To this end, chapter 1 defines the project, presents the company targeted in the study, the vision and mission, value chain, problem statement and its causes, sets general and specific objectives, and its respective success indicators. Subsequently, chapter 2 incorporates the 7 student outcome which exposes the evidence to support that the authors of the thesis have the required competence in said student outcomes. Later, chapter 3 establishes the conceptual basis for: strategic planning, corporate architecture, Zachman framework, TOGAF, software architecture and IT project management. Then, chapter 4 details the analysis under Zachman framework (Contextual and Conceptual), AS-IS and TO-BE model. Besides, it defines the system requirements, use-case models, SIEV’s mockups, defines drivers, design concepts, architecture patterns, design tactics and establishes a design using the 4C model. Finally, chapter 5 presents how PMBOK was used throughout the project management, from the Project charter, the planning, definition of the project’s team, project’s product description, acceptance criteria of each deliverable, the WBS and its dictionary, schedule, budget, resources, risk response plan, stakeholder management and change control. / Tesis

Context The last decade shows many solution proposals of functional decomposition techniques to aid in developing microservice architectures. While some solutions may work, it is uncertain what the effects are on quantitative, measurable metrics; thus, the proposals require validation. Objective The study measures the effects of various functional decomposition techniques on performance, scalability, and maintainability. Furthermore, the study will compare the treatments in order to find whether a statistical significance exists. Method The study uses a controlled experiment containing three functional decomposition techniques—Event Storming, Actor/Action, and Service Cutter—applied on the same use case. The use case follows the CoCoMe framework, which forms the basis of the experiment. Results Each treatment shows similar behavior while presenting different architectural designs. The study found no statistical significance for performance, scalability, and maintainability. Conclusion Evidence suggests that the convenience of an approach might be more important than the resulting architecture since they will likely lead to the same outcome. If performance issues arise, it would likely be due to the microservices architecture and not the functional decomposition technique; therefore, the microservices architecture might not equally benefit any situation or corporation. Furthermore, the study found that service granularity might not be as relevant as some studies claim it to be, and other factors could be more crucial.

The purpose of this research is to define which instruments with their characteristics exist to mitigate the communication issues in modern software development as well as the exact issues that emerge during software architecture design with their characteristics and validity. A Systematic Literature Review (SLR) is used as a major method of the research. Also, this thesis presents the vision of an ideal tool as well as an attempt to approbate the findings from the SLR in a small surrogate project of the ‘Battleship’ game while applying usual non-functional requirements from highly-collaborative industry projects. Additionally, we make the emphasis on simplicity and ease of use of the tools as well as the importance of the popularisation and promotion of both found and future tools to facilitate verification and adoption in the industry. The most popular Agile approaches (Scrum, Kanban, Extreme Programming, DevOps) do not specify, how these aspects of planning and documentation have to be managed and there are no existing additional widely-used and accepted tools for this purpose. In this work, a significant amount of attention is paid to the verification of the found tools in practice with feedback. For the tools which are not verified in practice, this work does a comparison against the vision of an ideal tool to understand. This helps to understand whether the given tool can be quickly adopted in practice, if further research is continued, or whether certain changes are required. Unfortunately, this work cannot present any existing tools which conform to our vision and are popularised, heavily verified in practice or relatively widely used in the industry. The closest solutions found were introduced in two industry papers concentrating on repurposing the existing Agile practices to mitigate the planning and documentation issues. During an SLR, a few tools were found, which we believe can be relatively easily taken to verification in practice or promoted to be used in industry on an everyday basis. However, we admit that further research of the found tools, which do not satisfy our requirements, can be used to reevaluate them in future to check for the desired properties again. Furthermore, we define a roadmap for future research for both the search for a tool and the development of a new instrument.

Code decay is a gradual process that negatively impacts the quality of a software system. Developers need trusted measurement techniques to evaluate whether their systems have decayed. This dissertation aims to assess code decay by discovering software architectural violations. Our methodology uses Lightweight Sanity Check for Implemented Architectures to derive architectural constraints represented by can-use and cannot-use phrases. Our methodology also uses Lattix to discover architectural violations. We also introduce measures that indicate code decay in a software system. We conducted two case studies of proprietary systems (9 versions of System A and 14 versions of System B) to demonstrate our methodology for assessing code decay. Resulting architectural constraints and architectural violations were validated by the expert of each system. Our results show that the net violations of System A increased from one version to other version even though there were architecture changes. However, in System B, the number of net violations decreased after changes in the architecture. The proposed code decay metrics can give managers insight into the process of software development, the history of the software product, and the status of unresolved violations. Our results and qualitative analysis showed that the methodology was effective and required a practical level of effort for moderate sized software systems. Code decay values increase because of an increase in the number of violations over multiple versions. We compared our code decay measures with definitions in the literature, namely coupling metrics. In addition, our empirical results showed that coupling is qualitatively correlated with the size of a system as expected. We note that coupling is an opportunity for architectural violations. We concluded that coupling is not consistently related to violations.

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>

When starting a new software project, selecting what technology stack to use is one of the most important decisions to make. Selecting a technology stack is a large part of the software architecture design, and the choice of the technology stack is crucial to get right since it can make or break a project and is usually hard and expensive to change in the future. This thesis was conducted to develop guidelines for organisations to use during the technology stack selection process by identifying the essential steps of the technology stack selection process at private sector organisations with multiple development teams that perform in-house development. As well as identifying scenarios where it is reasonable to choose similar technology stacks for different development teams, and scenarios where it is reasonable to select different technology stacks for different development teams. The guidelines aim to help organisations evaluate different solutions and help organisations decide whether it is worth it to choose different technology stacks for different development teams. The guidelines provide the essential steps of technology stack selection, control questions that can be used to evaluate whether a given technology stack would work for an organisation, as well as scenarios where it is reasonable to select similar or different technology stacks for multiple development teams. The guidelines are developed using Design Science Research and semi-structured interviews with software developers, software architects and managers at Husqvarna and other organisations that agreed to participate. The interviews were analysed using thematic content analysis to develop a draft of the guidelines, which was then attached to a survey that was sent out to gather feedback which helped further improve the guidelines and validate that they apply to a broad audience. This thesis does not cover technological aspects of technology stack selection, such as performance or efficiency, nor does it cover programs or tools used to aid the development, like integrated development environments (IDE:s), code-sharing software or team communication tools.

Functional and reactive programming patterns provide powerful sets of tools for dealing with complexity and scalability. These stand in stark contrast to the imperative programming patterns which permeate the industry. This report seeks to investigate the extent to which a set of common imperative programming languages can be used to implement such functional and reactive patterns, and what the implications of doing so are. This is done by implementing and using a framework based on such patterns in Java, Kotlin, Objective-C, and Swift. The results show that this is possible in all of these languages, but the extent to which this can be considered idiomatic is questionable. Upholding immutability and referential transparency is highlighted as the main source of concern in this regard. / Funktionella och reaktiva programmeringsmönster förser utvecklare med kraftfulla abstraktioner för att hantera komplexitet och skalbarhet. Dagens industri förlitar sig dock till en majoritet på imperativa programspråk, där dessa mönster inte nödvändigtvis kan utnyttjas. Syftet med denna rapport är därför att undersöka hur sådana mönster kan tillämpas i imperativa programspråk. Detta görs genom att studera implementationen och användandet av ett ramverk för funktionell och reaktiv programmering i fyra programspråk: Java, Kotlin, Objective-C och Swift. Rapporten finner att de mönster undersökta i denna rapport går att implementera med existerande språkfunktioner för alla dessa språk, men frågan om detta kan anses idiomatiskt är oklar. Det huvudsakliga problemet är att säkerställa att funktioner skrivs utan sidoeffekter och att datastrukturerna som används inte är muterbara.

With great advancements in cloud computing, the microservice architecture has become a promising architectural style for enterprise software. It has been proposed to cope with problems of the traditional monolithic architecture which includes slow release cycles, limited scalability and low developer productivity. Therefore, this thesis aims to investigate the affordances and challenges of adopting microservices as well as the difference in performance compared to the monolithic approach at one of Sweden’s largest banks, SEB - the Scandinavian Individual Bank. The investigation consisted of a literature study of research papers and official documentation of microservices. Moreover, two applications were developed and deployed using two different system architectures - a monolithic architecture and a microservice architecture. Performance tests were executed on both systems to gather quantitative data for analysis. The two metrics investigated in this study were response time and error rate. The results indicate the microservice architecture has a significantly higher error rate but a slower response time than the monolithic approach, further strengthening the results of Ueda et. al. [47] and Villamizar et. al. [48]. The findings have then been discussed with regards to the challenges and complexity involved in implementing distributed systems. From this study, it becomes clear the complexity shifts from inside the application out towards infrastructure with a microservice architecture. Therefore, microservices should not be seen as a silver bullet. Rather, the type of architecture is highly dependent on the scope of the project and the size of the organization. / Med stora framstegen inom molntjänster har microservice arkitekturen kommit att bli en lämplig kandidat för utveckling av företagsprogramvara. Denna typ av systemarkitektur har föreslagits att lösa de problem som den traditionella monolitiska arkitekturen medför; långsamma lanseringar, begränsad skalbarhet och låg produktivitet. Således fokuserar denna avhandling på att utforska de möjligheter samt utmaningar som följer vid adoptering av microservices samt skillnaden i prestanda jämfört med den monolitiska arkitekturen. Detta undersöktes på en av Sveriges största banker, SEB, den Skandinaviska Enskilda Banken. Utredningen bestod av en litteraturstudie av vetenskapliga artiklar samt officiell dokumentation för microservices. Dessutom utvecklades och lanserades två applikationer byggt med två olika typer av systemarkitektur - en som monolitisk arkitektur och den andra som en microservice arkitektur. Prestandatest utfördes sedan på båda systemen för att samla kvantitativ data för analys. De två nyckelvardena som undersöktes i denna studie var responstid och felfrekvens. Resultaten indikerar att microservice arkitekturen har en signifikant högre felfrekvens men en långsammare responstid än den monolitiska arkitekturen, vilket stärker resultaten av Ueda et. al. [47] och Villamizar et. al. [48]. Forskningsresultaten har diskuterats med hänsyn till den komplexitet och de utmaningar som följer vid implementering av distribuerade system. Från denna studie blir det tydligt att komplexiteten i en microservice arkitektur skiftar från inuti applikationen ut till infrastrukturen. Således borde microservices inte ses som en silverkula. Istället är valet av systemarkitektur strikt beroende på omfattningen av projektet samt storleken på organisationen i fråga.