Background. Machine learning (ML) has rapidly grown in popularity, becoming a vital part of many industries. This swift expansion has brought about new challenges to technical debt, maintainability and the general software quality of ML systems. With ML applications becoming more prevalent, there is an emerging need for extensive research to keep up with the pace of developments. Currently, the research on code smells in ML applications is limited and there is a lack of tools and studies that address these issues in-depth. This gap in the research highlights the necessity for a focused investigation into the validity of ML-specific code smells in ML applications, setting the stage for this research study. Objectives. Addressing the limited research on ML-specific code smells within Python-based ML applications. To achieve this, the study begins with the identification of these ML-specific code smells. Once recognized, the next objective is to choose suitable methods and tools to design and develop a static code analysis tool based on code smell criteria. After development, an empirical evaluation will assess both the tool’s efficacy and performance. Additionally, feedback from industry professionals will be sought to measure the tool’s feasibility and usefulness. Methods. This research employed Design Science Methodology. In the problem identification phase, a literature review was conducted to identify ML-specific code smells. In solution design, a secondary literature review and consultations with experts were performed to select methods and tools for implementing the tool. Additionally, 160 open-source ML applications were sourced from GitHub. The tool was empirically tested against these applications, with a focus on assessing its performance and efficacy. Furthermore, using the static validation method, feedback on the tool’s usefulness was gathered through an expert survey, which involved 15 ML professionals from Ericsson. Results. The study introduced MLpylint, a tool designed to identify 20 ML-specific code smells in Python-based ML applications. MLpylint effectively analyzed 160ML applications within 36 minutes, identifying in total 5380 code smells, although, highlighting the need for further refinements to each code smell checker to accurately identify specific patterns. In the expert survey, 15 ML professionals from Ericsson acknowledged the tool’s usefulness, user-friendliness and efficiency. However, they also indicated room for improvement in fine-tuning the tool to avoid ambiguous smells. Conclusions. Current studies on ML-specific code smells are limited, with few tools addressing them. The development and evaluation of MLpylint is a significant advancement in the ML software quality domain, enhancing reliability and reducing associated technical debt in ML applications. As the industry integrates such tools, it’s vital they evolve to detect code smells from new ML libraries. Aiding developers in upholding superior software quality but also promoting further research in the ML software quality domain.

A mature code-base of 1 300 000 LOC for a period of 20 months has been examined. This paper investigates if churn is a significant factor in finding refactoring candidates. In addition it looks at the variables Lines of Code (LOC), Technical Debt (TD), Duplicated lines and Complexity to find out if any of these indicators can inform a coder as to what to refactor. The result is that churn is the strongest variable out of the studied variables followed by LOC and TD. / En kodbas på 1 300 000 rader kod har undersökts under 20 månader. Denna uppsats undersöker om kodens användningsfrekvens är en signifikant faktor för att finna refaktoreringskandidater. Uppsatsen tittar även antal kodrader, teknisk skuld, antal duplicerade kodrader och komplexitet för att undersöka om dessa indikatorer kan informera en programmerare om vad som ska refaktoreras. Resultatet är att kodens användningsfrekvens är den starkaste variabeln följt av antal kodrader samt teknisk skuld.

This thesis investigates how XML representation of X++ abstract syntax trees (AST) residing in an XML database can be subject to static code analysis. Microsoft Dynamics 365 for Finance & Operations comprises a large and complex corpus of X++ source code and intuitive ways of visualizing and analysing the state of the code base in terms of software metrics and technical debt are non-existent. A solution is to extend an internal web application and semantic search tool called SocrateX, to calculate software metrics and technical debt. This is done by creating a web service to construct XQuery and XPath code to be queried to the XML database. The values are stored in a relational database and imported to Power BI for intuitive visualization. Software metrics have been chosen based on the amount of previous research and compatibility with the X++ AST, whereas technical debt has been estimated using the SQALE method. This thesis concludes that XML representations of X++ abstract syntax trees are viable candidates for measuring quality of source codes with the use of functional query programming languages.

The need for automated methods for identifying refactoring items is prelevent in many software projects today. Symptoms of refactoring needs is the concept of code smells within a software system. Recent studies have used single model machine learning to combat this issue. This study aims to test the possibility of improving machine learning code smell detection using ensemble methods. Therefore identifying the strongest ensemble model in the context of code smells and the relative sensitivity of the strongest perfoming ensemble identified. The ensemble models performance was studied by performing experiments using WekaNose to create datasets of code smells and Weka to train and test the models on the dataset. The datasets created was based on Qualitas Corpus curated java project. Each tested ensemble method was then compared to all the other ensembles, using f-measure, accuracy and AUC ROC scores. The tested ensemble methods were stacking, voting, bagging and boosting. The models to implement the ensemble methods with were models that previous studies had identified as strongest performer for code smell identification. The models where Jrip, J48, Naive Bayes and SMO. The findings showed, that compared to previous studies, bagging J48 improved results by 0.5%. And that the nominally implemented baggin of J48 in Weka follows best practices and the model where impacted negatively. However, due to the complexity of stacking and voting ensembles further work is needed regarding stacking and voting ensemble models in the context of code smell identification.

Software development can be a difficult and time consuming task. In addition, producing good code is even more difficult. Poor design and implementation choices in software code can result in an end product that is both difficult to understand and difficult to maintain. A collective name for implementation and design choices that is considered to have a negative impact or indicate something negative in software code is Code smells. In this study, we identify 34 unique code smells through a systematic literature study. The results are then ranked and validated with interviews with people who work or have worked with Javascript in a professional environment at some point during the past five years. The end result is a ranked list of 32 code smells that are applicable to Javascript. The result shows that the five highest ranked code smells are Variable name conflict in closures, Depth, Argument Type Mismatch, Duplicated code and Excessive global Variables.

Inadequate software development collaboration processes can allow technical debt to accumulate increasing future maintenance costs and the chance of system failures. The purpose of this qualitative case study was to explore collaboration strategies software development leaders use to reduce the amount of technical debt created by software developers. The study population was software development leaders experienced with collaboration and technical debt at a large health care provider in the state of California. The data collection process included interviews with 8 software development leaders and reviewing 19 organizational documents relating to software development methods. The extended technology acceptance model was used as the conceptual framework to better understand the social and cognitive influences on the perceived usefulness of collaboration in reducing technical debt. An inductive analysis of the data was used for coding, triangulation, and identifying themes related to the use of collaboration strategies to reduce technical debt. Prominent themes included using collaboration at all stages of development, using continuous verification processes, promoting a participatory culture, and using tools to support distributed teams. The study findings showed an environment that promotes collaboration, a culture that encourages participation, and accessibility to collaborative tools that may reduce technical debt in software projects. The results of this study may contribute to positive social change by demonstrating how individuals with diverse backgrounds and different perspectives can work together to improve critical software that people depend on every day.

Företagens tillväxt har resulterat i en ökad mängd data som kräver analys och därmed uppkommer utmaningar för hantering och analys. För att stödja företagens mål har Enterprise Architecture (EA) utvecklats som ett ramverk. Dessutom har begreppet Technical Debt (TD) uppkommit för att bistå i beslutsfattande om hur begränsade resurser ska investeras och identifiera eventuella nackdelar med befintliga designbeslut. För att inkludera både tekniska och affärsrelaterade aspekter har begreppet Enterprise Architecture Debt (EAD) introducerats. Trots att EAD har börjat bli mer välkänt saknas för närvarande fastställda gränsvärden för mätning och hantering av konceptet. Detta gör det svårt för organisationer att erhålla en klar uppfattning om sin skuld och prioritera lämpliga åtgärder. Mot denna bakgrund har syftet med denna uppsats varit att definiera gränsvärden för Enterprise Architecture Debt Measurements (EADM) för att underlätta för organisationer att förstå omfattningen av sin skuld och därigenom kunna prioritera åtgärder på ett bättre sätt. För att uppnå detta har en kvalitativ forskningsansats använts i studien, där data har samlats in genom semistrukturerade intervjuer med EA-experter. Genom att lägga fokus på deltagarnas synpunkter och åsikter syftar studien till att bidra till kunskapen om EAD och dess mätvärden. Resultaten visar på en stark vilja bland EA-experter att anpassa och förbättra mätning och hantering av EA inom organisationer. Förändringsarbete betraktas som nödvändigt för att uppnå effektivitet och relevans inom EA, där kostnadsaspekter spelar en betydande roll vid beslutsfattande. Studien undersöker även möjligheten att fastställa kvaliteten på mätningar inom EA. Respondenterna uttrycker en positiv inställning till standardisering av EAD, samtidigt som de betonar utmaningar med att tillämpa generella mätetal. Studien framhäver vikten av flexibilitet och kontinuerlig anpassning för att utveckla meningsfulla och användbara mätvärden som effektivt kan bedöma kvaliteten inom EAD. Slutsatsen i studien blev att fastställandet av kvaliteten på mätetal är möjligt i de sammanhang där organisationerna visar en vilja att påta sig de kostnader som kan uppstå vid utvecklingen av sådana mätetal och att kvaliteten endast kan fastställas när mätetalen är anpassade efter organisationen. / The growth of companies has resulted in an increased amount of data that requires analysis, posing challenges for its management and analysis. To support the goals of companies, Enterprise Architecture (EA) has been developed as a framework. Furthermore the concept of Technical Debt (TD) has emerged to assist in decision-making regarding the allocation of limited resources and identifying potential drawbacks of existing design decisions. To encompass both technical and business-related aspects, the concept of Enterprise Architecture Debt (EAD) has been introduced. Despite EAD gaining recognition, there are currently no established thresholds for measuring and managing this concept. This poses difficulties for organizations to gain a clear understanding of their debt and prioritize appropriate actions. Against this backdrop, the aim of this thesis has been to define thresholds for Enterprise Architecture Debt Measurements (EADM) to facilitate organizations' understanding of the extent of their debt and enable better prioritization of actions. To achieve this, a qualitative research approach has been employed, with data collected through semi-structured interviews with EA experts. By focusing on participants' perspectives and opinions, the study aims to contribute to the knowledge of EAD and its metrics. The findings indicate a strong willingness among EA experts to adapt and improve the measurement and management of EA within organizations. Change efforts are seen as necessary to achieve efficiency and relevance in EA, with cost considerations playing a significant role in decision-making. The study also explores the possibility of determining the quality of EA measurements. Respondents express a positive attitude towards the standardization of EAD while highlighting challenges in applying generic metrics. The study emphasizes the importance of flexibility and continuous adaptation in developing meaningful and useful metrics that can effectively assess the quality within EAD. The conclusion of the study was that determining the quality of metrics is possible in contexts where organizations show a willingness to bear the costs that may arise in the development of such metrics, and that the quality can only be determined when the metrics are tailored to the organization's needs.

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.

<p>Småföretag har inte samma finansiella och personella resurser som stora företag och kan få svårt att genomföra önskade IT-relaterade förändringar. De företag som väljer att satsa för att uppnå sina visioner måste många gånger hitta andra lösningar för att nå framgång. Avhandlingen bygger på en åtta månader lång fallstudie i ett småföretag och identifierar kompensationer som ett sätt att lösa problemet.</p><p><em>En kompensation </em>är en ersättning för en förändring i ett informationssystem. Ett exempel på kompensation är att göra dubbelarbete istället för att integrera två informationssystem. Andra exempel är att införa regler för hur informationen skall användas och tolkas istället för att sätta restriktioner i informationssystemet, eller att ta fram en rapport ad hoc med en rapportgenerator istället för att låta externa experter utveckla rapporten direkt i verksamhetssystemet.</p><p>Småföretagens korta planeringshorisont med intuitiva och erfarenhetsbaserade beslutsprocesser bildar <em>en gynnsam miljö </em>för att arbeta med kompensationer - det går snabbt att samla hela personalen och säga: ”nu gör vi så här istället”. Men, kompensationen kan också visa sig vara ett tveeggat svärd. I fallstudien visar sig kompensationerna många gånger bidra till <em>negativa bieffekter </em>när de väl används. Exempel på negativa bieffekter är merarbete, stress, ökad osäkerhet och tekniska problem.</p><p>Fyra risker med att arbeta med kompensationer har identifierats. <em>Resursberoendet</em>: om kompensationen leder till att arbetsbördan ökar, är risken stor att personerna får mindre tid att delta i förändringsarbetet <em>Illusionen</em>: om kompensationen ger sken av att lösningen fungerar i praktiken, är risken stor att ledningens fokus flyttas till andra mer akuta projekt trots att viktiga problem kvarstår. <em>Den tekniska skulden</em>: när tekniska problem inte åtgärdas ordentligt, utan hanteras med kompensationer, ackumuleras problemen till en ”teknisk skuld”. Skulden växer i takt med att nya förändringar genomförs och den tekniska infrastrukturen blir mer och mer komplex. På sikt blir det både svårt och dyrbart att åtgärda problemen. <em>Legitimeringen</em>: om arbetet med kompensationer anses ”fungera i praktiken” kan det bli legitimt att inte lösa problem ordentligt. Det bidrar till att företaget inte utvecklar viktiga kompetenser som till exempel användning av formella metoder, beställarkompetens och förmågan att samarbeta med externa experter.</p><p>Kompensationer är en viktig del i småföretagets arbete med IT-relaterade förändringar och kan inte undvikas. Tidigare forskning har dock inte tagit hänsyn till hur kompensationer påverkar förändringsarbetets framgång. Dessa studier har identifierat <em>framgångsfaktorer </em>som användarinvolvering, VD:s stöd, samarbetet med externa experter och användningen av formella metoder. Den här studien visar på att <em>kompensationerna kan påverka framgångsfaktorerna negativt </em>via de fyra riskerna, exempelvis genom att tiden för användarinvolvering minskar, VD:s fokus förskjuts samt att relationerna med externa experter aldrig utvecklas.</p><p>Implikationen är att <em>kompensationerna måste hanteras medvetet </em>därför att de får konsekvenser som kan vara svåra att förutse intuitivt. Dessa konsekvenser kan bidra till att förutsättningarna för framtida förändringar försämras. Det är därför viktigt att överväga vad som lönar sig mest för att uppnå en varaktig framgång: att <em>tillsätta resurser </em>för att göra de nödvändiga förändringarna i informationssystemen, att sänka <em>ambitionsnivån </em>eller att hitta <em>smarta kompensationer</em>. För småföretag som vill förbättra sättet att bedriva förändringsarbete blir konsekvensen att det inte räcker att ta hänsyn till traditionella framgångsfaktorer. De småföretag som verkligen vill få bättre effekter måste också <em>ifrågasätta hur det egna, invanda sättet att arbeta med IT-relaterad förändring påverkar möjligheterna att genomföra både aktuella och framtida förändringarna.</em></p> / Lic.-avh. Stockholm : Handelshögskolan, 2006

Småföretag har inte samma finansiella och personella resurser som stora företag och kan få svårt att genomföra önskade IT-relaterade förändringar. De företag som väljer att satsa för att uppnå sina visioner måste många gånger hitta andra lösningar för att nå framgång. Avhandlingen bygger på en åtta månader lång fallstudie i ett småföretag och identifierar kompensationer som ett sätt att lösa problemet. En kompensation är en ersättning för en förändring i ett informationssystem. Ett exempel på kompensation är att göra dubbelarbete istället för att integrera två informationssystem. Andra exempel är att införa regler för hur informationen skall användas och tolkas istället för att sätta restriktioner i informationssystemet, eller att ta fram en rapport ad hoc med en rapportgenerator istället för att låta externa experter utveckla rapporten direkt i verksamhetssystemet. Småföretagens korta planeringshorisont med intuitiva och erfarenhetsbaserade beslutsprocesser bildar en gynnsam miljö för att arbeta med kompensationer - det går snabbt att samla hela personalen och säga: ”nu gör vi så här istället”. Men, kompensationen kan också visa sig vara ett tveeggat svärd. I fallstudien visar sig kompensationerna många gånger bidra till negativa bieffekter när de väl används. Exempel på negativa bieffekter är merarbete, stress, ökad osäkerhet och tekniska problem. Fyra risker med att arbeta med kompensationer har identifierats. Resursberoendet: om kompensationen leder till att arbetsbördan ökar, är risken stor att personerna får mindre tid att delta i förändringsarbetet Illusionen: om kompensationen ger sken av att lösningen fungerar i praktiken, är risken stor att ledningens fokus flyttas till andra mer akuta projekt trots att viktiga problem kvarstår. Den tekniska skulden: när tekniska problem inte åtgärdas ordentligt, utan hanteras med kompensationer, ackumuleras problemen till en ”teknisk skuld”. Skulden växer i takt med att nya förändringar genomförs och den tekniska infrastrukturen blir mer och mer komplex. På sikt blir det både svårt och dyrbart att åtgärda problemen. Legitimeringen: om arbetet med kompensationer anses ”fungera i praktiken” kan det bli legitimt att inte lösa problem ordentligt. Det bidrar till att företaget inte utvecklar viktiga kompetenser som till exempel användning av formella metoder, beställarkompetens och förmågan att samarbeta med externa experter. Kompensationer är en viktig del i småföretagets arbete med IT-relaterade förändringar och kan inte undvikas. Tidigare forskning har dock inte tagit hänsyn till hur kompensationer påverkar förändringsarbetets framgång. Dessa studier har identifierat framgångsfaktorer som användarinvolvering, VD:s stöd, samarbetet med externa experter och användningen av formella metoder. Den här studien visar på att kompensationerna kan påverka framgångsfaktorerna negativt via de fyra riskerna, exempelvis genom att tiden för användarinvolvering minskar, VD:s fokus förskjuts samt att relationerna med externa experter aldrig utvecklas. Implikationen är att kompensationerna måste hanteras medvetet därför att de får konsekvenser som kan vara svåra att förutse intuitivt. Dessa konsekvenser kan bidra till att förutsättningarna för framtida förändringar försämras. Det är därför viktigt att överväga vad som lönar sig mest för att uppnå en varaktig framgång: att tillsätta resurser för att göra de nödvändiga förändringarna i informationssystemen, att sänka ambitionsnivån eller att hitta smarta kompensationer. För småföretag som vill förbättra sättet att bedriva förändringsarbete blir konsekvensen att det inte räcker att ta hänsyn till traditionella framgångsfaktorer. De småföretag som verkligen vill få bättre effekter måste också ifrågasätta hur det egna, invanda sättet att arbeta med IT-relaterad förändring påverkar möjligheterna att genomföra både aktuella och framtida förändringarna. / Lic.-avh. Stockholm : Handelshögskolan, 2006