A key factor in creating software of good quality is that the requirements for the project being developed are as unambiguous and clear as possible, so the developers will be able to develop the product quickly and effectively. So, there is a need for tools that help requirements engineers create quality requirements. The attributes that define a poorly written requirement are called bad smells. In this thesis we investigate the NALABS tools bad smell detecting capabilities when analyzing industrial requirements. First, we performed a literature study to investigate what types of bad smells exist for requirements and how they were specified. After that we used a case study to examine how many smells and of what categories the NALABS tool detects, when it analyzes industrial requirements. Lastly, we used a small experiment to examine how accurately NALABS detects smells, by designing a simple console application that counted instances of bad smell words in a set of keywords that were from the NALABS tool. The results we gathered gave us an indication that NALABS detects bad smells in all the categories of bad smells that are implemented in it, to a varying degree. Through this thesis we hope to extend the knowledge about bad requirements smells, clarify what attributes of a requirement might be a bad smell, and investigate to what degree the NALABS tool can detect bad smells in industrial requirements.

Deficiencies in software design or architecture can severely impede and slow down the software development and maintenance progress. Bad smells and anti-patterns can be an indicator for poor software design and suggest for refactoring the affected source code fragment. In recent years, multiple techniques and tools have been proposed to assist software engineers in identifying smells and guiding them through corresponding refactoring steps. However, these detection tools only cover a modest amount of smells so far and also tend to produce false positives which represent conscious constructs with symptoms similar or identical to actual bad smells (e.g., design patterns). These and other issues in the detection process demand for a code or design review in order to identify (missed) design smells and/or re-assess detected smell candidates. UML diagrams are the quasi-standard for documenting software design and are often available in software projects. In this position paper, we investigate whether (and to what extent) UML diagrams can be used for identifying and assessing design smells. Based on a description of difficulties in the smell detection process, we discuss the importance of design reviews. We then investigate to what extent design documentation in terms of UML2 diagrams allows for representing and identifying software design smells. In particular, 14 kinds of design smells and their representability in UML class and sequence diagrams are analyzed. In addition, we discuss further challenges for UML-based identification and assessment of bad smells.

Spreadsheets are a widely used end-user programming tool. Field audits have found that 80-90% of spreadsheets created by end users contain textual and formula errors in spreadsheets. Such errors may have severe negative consequences for users in terms of productivity, credibility, or profits. To solve the problem of spreadsheet errors, researchers have presented manual and automatic error detection. Manual error detection is both tedious and time-consuming, while automatic error detection is limited to only finding some formula error categories such as formula reference errors. Both approaches do not provide the optimum result in error detection. We have tested a new error detection approach by detecting bad smells in spreadsheets, which is an indication that an error might be present. Originally developed for object-oriented programming, examples include the large class, and the lazy class. We have adapted the concept of bad smells to spreadsheets. Each bad smell detector might indicate an issue in the spreadsheet, but the indication is not definitive, since the user must examine the spreadsheet and make a final judgment about whether an error is actually present. We evaluated 11 bad smell detectors by analyzing the true positives against the false positives. The result shows that six detectors can highlight some error categories, such as categorical errors and typographical errors. / Graduation date: 2013

Submitted by Santos Davilene (davilenes@ufba.br) on 2016-05-25T14:04:00Z No. of bitstreams: 1 FINAL Dissertação Mestrado - Hugo Sica de Andrade.pdf: 4068482 bytes, checksum: f4538e19111b94a4c1caae39a4e6c525 (MD5) / Made available in DSpace on 2016-05-25T14:04:00Z (GMT). No. of bitstreams: 1 FINAL Dissertação Mestrado - Hugo Sica de Andrade.pdf: 4068482 bytes, checksum: f4538e19111b94a4c1caae39a4e6c525 (MD5) / O paradigma de Linhas de Produto de Software (LPS) tem provado ser um meio efetivo para se obter reuso de grande escala em diferentes domínios. A abordagem tira proveito de aspectos comuns entre diferentes produtos, enquanto também considera propriedades específicas dos mesmos. A arquitetura tem um papel importante na engenharia de LPS, provendo meios para melhor entender e manter o ambiente de derivação de produtos. No entanto, é difícil evoluir tal arquitetura, pois nem sempre é claro onde e como refatorar. A arquitetura de uma LPS contém um modelo que irá resultar na arquitetura de produtos, e muitas vezes inclui soluções que indicam um design (arquitetural) inadequado. Uma forma de avaliar tais decisões de design é através da identificação de bad smells de arquitetura, ou seja, propriedades que prejudicam a qualidade do software, mas não são necessariamente errôneas ou representam falhas. Nesse sentido, o objetivo desta dissertação é obter um melhor entendimento de bad smells de arquitetura em LPSs. Primeiramente, o estado-da-arte atual em Arquiteturas de Linhas de Produto de software (ALP) é investigado através de um estudo de mapeamento sistemático. Este apresenta uma visão geral da área através de análise e categorização de evidências. O estudo idenfitica gaps, tendências, e provê direções futuras para pesquisa. Ademais, esta dissertação trata do fenômeno de bad smells de arquitetura no contexto de LPSs através de dois estudos exploratórios em domínios diferentes. O primeiro estudo exploratório conduz uma investigação sobre as implicações de propriedades estruturais em uma LPS no domínio de editores de texto, enquanto o segundo estudo foca em uma LPS no domínio mobile. Antes da busca pelos smells em ambos os estudos, informações relevantes para a arquitetura foram recuperadas do código fonte para que as arquiteturas fossem definidas.

Submitted by Lucienne Costa (lucienneferreira@ufcg.edu.br) on 2018-05-02T20:10:07Z No. of bitstreams: 1 MÁRIO HOZANO LUCAS DE SOUZA – TESE (PPGCC) 2017.pdf: 3990516 bytes, checksum: b6a38a396737d92fd11b9fa9fb3027f5 (MD5) / Made available in DSpace on 2018-05-02T20:10:07Z (GMT). No. of bitstreams: 1 MÁRIO HOZANO LUCAS DE SOUZA – TESE (PPGCC) 2017.pdf: 3990516 bytes, checksum: b6a38a396737d92fd11b9fa9fb3027f5 (MD5) Previous issue date: 2017-06-02 / Anomalias de código conhecidas como bad smells indicam estruturas em código que podem prejudicar a compreensão e manutenção de programas. A ausência de uma definição clara para os bad smells contribui para que diferentes interpretações sejam consideradas, fazendo com que desenvolvedores possuam uma noção particular do que são tais anomalias. Nesse sentido, algoritmos de aprendizagem de máquina têm sido utilizados para customizar a detecção de bad smells a partir de um conjunto de avaliações. Entretanto, tal customização não é guiada a partir das diferentes heurísticas utilizadas pelos desenvolvedores para a detecção de smells. Como consequência tal customização pode não ser eficiente, exigindo um esforço considerável para obter uma alta efetividade. Esse trabalho apresenta um extensivo estudo que investiga o quão similar os desenvolvedores detectam smells em código, e analisa fatores que podem influenciar em tal detecção. As conclusões desse estudo motivaram a criação de uma técnica de customização guiada para melhorar a eficiência na detecção de smells. Essa técnica, definida como Histrategy, guia a customização a partir de um conjunto limitado de estratégias para detectar um mesmo tipo de smell. A partir de um estudo experimental que envolveu 62 desenvolvedores e 8 tipos de bad smell. Os resultados indicaram que a Histrategy apresentou performance superior a 6 algoritmos de aprendizagem de máquina, utilizados em abordagens não guiadas. Por fim, os resultados confirmaram que a customização guiada foi capaz assistir desenvolvedores com estratégias de detecção eficazes e eficientes. / Bad smells indicate poor implementation choices that may hinder program comprehension and maintenance. Their informal definition allows developers to follow different heuristics to detect smells in their projects. In such context, machine learning algorithms have been adapted to customize smell detection according to a set of examples of smell evaluations. However, such customization is not guided (i.e. constrained) to consider alternative heuristics used by developers when detecting smells. As a result, their customization might not be efficient, requiring a considerable effort to reach high effectiveness. This work presents an extensive study concerning how similar the developers detect smells in code, and investigate which factors may influence in such detection. The findings of this study lead to the creation of Histrategy, a guided customization technique to improve the efficiency on smell detection. Histrategy considers a limited set of detection strategies, produced from different detection heuristics, as input of a customization process. The output of the customization process consists of a detection strategy tailored to each developer. The technique was evaluated in an experimental study with 62 developers and eight types of code smells. The results showed that Histrategy is able to outperform six widely adopted machine learning algorithms, used in unguided approaches. Finally, the results confirmed that the guided customization was able to support developers with effective and efficient detection strategies.

Designing with non-visual attributes challenges ways of representation. This research explores methods for designing with invisible materiality within the research practice, as well as ways of representation through textiles when designing spaces. Exploring textiles and smells within a space, the research program investigates spatial interactions. This research focuses on designing embodied experiences using tangible materials as expressions of smells. Through the spatial installations and performances Sight of smell, Touch of smell, and Smell, space, and body movement, haptics were explored as one of the methods of interaction with smells through textiles. Through the sense of touch, this research also investigates ways of revealing, activating, and disseminating smells within a space. Smells were purposely added through the methods of dyeing, coating, and printing to the textile materials that did not inherently embody any smells, As a result, tactile surfaces create non-visual expressions of smell. Further ideas of research in this area would explore another perspective of designing with smells in spaces. As an example, by designing textiles being smell absorbers, dividers, and re ectors, could compliment the spatial concepts and deals with the already existing smells in a living environment. In this licentiate thesis thinking through the olfactive dimension to design textiles is not only novel for the textile design eld; but also, its proposal for application in the spatial design is quite unique, and o ers a new dimension for spatial design. / Horizon 2020 MSCA ITN

With the rising number of servers used in productions, virtualization technology engineers needed a new a tool to help them manage the rising configuration workload. Infrastructure as code(IaC), a term that consists mainly of techniques and tools to define wanted configuration states of servers in machine readable code files, which aims at solving the high workload induced by the configuration of several servers. With new tools, new challenges rise regarding the security of creating the infrastructure as code scripts that will take over the processing load. This study is about finding out how open-source developers perform when creating IaC scripts in regard to how many security smells they insert into their scripts in comparison to previous studies and such how developers can mitigate these risks. Security smells are code patterns that show vulnerability and can lead to exploitation. Using data gathered from GitHub with a web scraper tool created for this study, the author analyzed 400 repositories from Ansible and Puppet with a second tool created, tested and validated from previous study. The Security Linter for Infrastructure as Code uses static code analysis on these repositories and tested these against a certain ruleset for weaknesses in code such as default admin and hard-coded password among others. The present study used both qualitative and quantitative methods to analyze the data. The results show that developers that actively participated in developing these repositories with a creation date of at latest 2019-01-01 produced less security smells than Rahman et al (2019b, 2020c) with a data source ranging to November 2018. While Ansible produced 9,2 compared to 28,8 security smells per thousand lines of code and Puppet 13,6 compared to 31,1. Main limitation of the study come mainly in looking only at the most popular and used tools of the time of writing, being Ansible and Puppet. Further mitigation on results from both studies can be achieved through training and education. As well as the use of tools such as SonarQube for static code analysis against custom rulesets before the scripts are being pushed to public repositories.

Code smells are defined as poor implementation and coding practices, and as a result decrease the overall quality of a source code. A number of code smell detection tools are available to automatically detect poor implementation choices, i.e., code smells. The detection of code smells is essential in order to improve the quality of the source code. This report aims to evaluate the accuracy and quality of seven different open-source code smell detection tools, with the purpose of establishing their level of trustworthiness.To assess the trustworthiness of a tool, we utilize a controlled experiment in which several versions of each tool are scrutinized using the most recent version of the same tool. In particular, we wanted to verify to what extent the code smell detection tools that reveal code smells in other systems, contain smells themselves. We further study the evolution of code smells in the tools in terms of number, types of code smells and code smell density.

A common challenge in organizations is a perception of that different languages are spoken among IT and other departments. Co-workers come from different background, have different knowledge base and sometimes even different objectives which can make an alignment more challenging. Enterprise Architecture (EA) can align IT investments with business directions and potentially solve issues regarding business-IT misalignments and bring value to organizations. Technical Debt (TD) is a well-established concept in software development and means that a solution that is “quick and dirty” is applied in order to earn time in short term and be able to provide a function in a system more quickly. This primitive implementation will at a later stage need to be corrected and rewritten, and the longer it takes, the more advanced, complex and time-consuming the correction will be. As EA has grown, major scientific and academic contributions have been developed. What is still missing is insight and ability to include a debt concept, which not only address TD but also business aspects. By adapting the TD concept in the EA domain, a new metaphor, providing a holistic perspective, has been proposed; Enterprise Architecture Debt (EAD). Up to the present debts for measuring EAD has been identified, but current research projects has not yet identified when a certain measure is to be considered of high or low quality. There is a need to develop a process for deriving such thresholds and identifying them. To be able to communicate the severity of an EAD to stakeholders, thresholds for EAD measures plays an important role. These thresholds will in the long term play a role in providing a tool for computer scientist working in organizations exploiting EA, and also contribute to current research within the field of IT-management and EA. By adopting a systematic process for defining expert driven thresholds a first version of a process for defining EAD thresholds could be presented and tested with domain experts. Five common opinions were detected, regarding the process, among the experts. The process could potentially facilitate useful communication and it was considered positive that it highlighted the context of the EAD. Also, that clearer process description and real-world EA model examples was needed, and that the moment of selecting membership function was unnecessary came up. Further, drivers for EAD thresholds and areas where it is perceived as important to have thresholds for EADs was a focus during the study. Cost and time, responsibility and engagement and context are perceived to be important drivers for EAD thresholds. While the business-it alignment and master data are seen as important areas. Also, context can play an important role when determine important areas. / En vanlig utmaning inom organisationer är uppfattningen av att olika språka talas på IT-avdelningen och övriga avdelningar. Medarbetare kommer från olika bakgrund, har olika kunskapsbas och ibland till och med olika mål, vilket kan göra fastställandet av riktning mer utmanande. Enterprise Architecture (EA) kan säkerställa att IT investeringar och affärs direktiv går i samma riktning och kan därmed potentiellt lösa problem i anslutning till IT och övrig affärsverksamhet som uppstått på grund av detta och skapa värde till organisationen. Teknisk skuld är ett väletablerat koncept inom mjukvaruutveckling och syftar till att enlösning som är ”quick and dirty” tillämpas för att vinna tid på kort sikt och kunna tillämpa en funktionalitet i ett system snabbare. Denna primitiva implementation kommer vid senare tillfälle behöva korrigeras och skrivas om. Ju längre tid det tar desto mer avancerad, komplex och tidskrävande kommer ändringen att bli. I takt med att EA har vuxit har stora vetenskapliga och akademiska bidrag utvecklats. Vad som fortfarande saknas är insikt och förmåga att inkludera ett skuldkoncept som inte bara adresserar tekniks skuld utan även affärsaspekter. Genom att introducera konceptet teknisk skult i EA domänen har en ny metafor, som tillhandahåller ett helhetsperspektiv, föreslagits; Enterprise Architecture Debt (EA Debt). Fram tills idag har skulder för att mäta EA Debt blivit identifierade, men aktuella forskningsprojekt har ännu inte identifierat när en viss EA Debt är hög eller låg. Det finns ett behov av att utveckla en process för att härleda sådana gränsvärden och identifiera dem. För att kunna kommunicera all varlighetsgraden för en EA Debt till intressenter kan gränsvärden för EA Debt spela en viktig roll. Dessa gränsvärden kommer på lång sikt spela en roll när det kommer till att tillhandahålla verktyg för datavetare som arbetar i organisationer som tillämpar EA, och också bidra till aktuell forskning inom IT-förvaltning och EA. Genom att anta en systematisk process för att definiera expertdrivna gränsvärden har en första version av en process för att definiera EA Debt-gränsvärden kunnat presenteras och testas med domän-experter. Fem vanliga uppfattningar, gällande processen, kunde uppräckas bland experterna. Processens skulle också potentiellt kunna främja användbar kommunikation och det ansågs positivt att den belysta och tog hänsyn till kontext gällande EA Debt. Att tydligare processbeskrivning och verklighetstrogna EA-modeller som exempel behövdes samt att momentet där medlemsfunktion skulle väljas var onödigt kom också upp. Vidare så fokuserade studien på drivkrafter för att ta fram gränsvärden för EA Debt och områden där uppfattningen är att detta är viktigt. Kostnad och tid, ansvar och engagemang och kontext är uppfattade som viktiga drivkrafter när det kommer till gränsvärden för EA skuld, medan inriktningen för IT och övrig affärsverksamhet och basdata ses som viktiga områden. Även kontexten kan ha en viktig roll när det kommer till att avgöra vilka områden som är viktiga.

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.