Submitted by Erika Demachki (erikademachki@gmail.com) on 2015-03-25T18:00:07Z No. of bitstreams: 3 Dissertação - Igor Rodrigues Vieira - 2014.pdf: 3955314 bytes, checksum: 10653cb9217fd4e5673366c0dec73383 (MD5) Dissertação - Igor Rodrigues Vieira - 2014.zip: 294065 bytes, checksum: f01004b14dc2c0cec6bc6eb4898db980 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Rejected by Erika Demachki (erikademachki@gmail.com), reason: on 2015-03-25T18:01:43Z (GMT) / Submitted by Erika Demachki (erikademachki@gmail.com) on 2015-03-25T18:03:23Z No. of bitstreams: 3 Dissertação - Igor Rodrigues Vieira - 2014.pdf: 3955314 bytes, checksum: 10653cb9217fd4e5673366c0dec73383 (MD5) Dissertação - Igor Rodrigues Vieira - 2014.zip: 294065 bytes, checksum: f01004b14dc2c0cec6bc6eb4898db980 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Approved for entry into archive by Erika Demachki (erikademachki@gmail.com) on 2015-03-25T18:04:48Z (GMT) No. of bitstreams: 3 Dissertação - Igor Rodrigues Vieira - 2014.pdf: 3955314 bytes, checksum: 10653cb9217fd4e5673366c0dec73383 (MD5) Dissertação - Igor Rodrigues Vieira - 2014.zip: 294065 bytes, checksum: f01004b14dc2c0cec6bc6eb4898db980 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Made available in DSpace on 2015-03-25T18:04:48Z (GMT). No. of bitstreams: 3 Dissertação - Igor Rodrigues Vieira - 2014.pdf: 3955314 bytes, checksum: 10653cb9217fd4e5673366c0dec73383 (MD5) Dissertação - Igor Rodrigues Vieira - 2014.zip: 294065 bytes, checksum: f01004b14dc2c0cec6bc6eb4898db980 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) Previous issue date: 2014-11-19 / The metaphor of technical debt (TD) is very useful for Software Engineering, it is directly related to the context of evolution and maintenance in the life cycle of a product. It can be understood as a relation between costs and effects, of short and long term, associated with project decisions during the software development process. Currently, large companies and some government sectors still have restrictions in adopting open source products by uncertainties related to its quality and reliability. In this context, this study aims to evaluate the technical debt in open source products in order to demonstrate the feasibility of this approach to evaluate the software quality. For this, were performed experimental studies, contemplating the automated data collection for a significant set of products open source, having as input its source code. These products were evaluated by SonarQube Platform, which enables collect several metrics about the quality of the source code - including the technical debt. The interpretation of the collected data allowed the analysis of the TD evolution for these products, the classification of the projects and the verification of the representativeness of the quality axis that make up the TD. The results suggest that most of the projects evaluated have shown decreased TD along their versions and they showed slightly elevated values of the metric. Another contribution is that the quality axis Coverage, Violations and Complexity is presented as the main contributors to the TD’s increase of from the set of product evaluated. It was also possible to verify the existence of a correlation between the TD implementation and the SQALE methodology, with regard assessing software quality evaluating. / A metáfora da dívida técnica (DT) apresenta-se muito útil para Engenharia de Software, estando diretamente relacionada ao contexto de evolução e manutenção existentes no ciclo de vida de um produto. Ela pode ser entendida como uma relação entre custos e efeitos, de curto e longo prazos, associados a decisões de projeto durante o processo de desenvolvimento de software. Atualmente, grandes empresas e alguns setores do governo ainda possuem restrições quanto à adoção de produtos de código aberto por incertezas relacionadas a sua qualidade e confiabilidade. Nesse contexto, o presente trabalho tem por objetivo avaliar a dívida técnica em produtos de código aberto, no intuito de demonstrar a possibilidade de utilização dessa abordagem para avaliação da qualidade de software. Para tanto, foram realizados estudos experimentais, contemplando a coleta automatizada de dados para um conjunto expressivo de produtos de código aberto, tendo como entrada o respectivo código fonte. Esses produtos foram submetidos à avaliação da Plataforma SonarQube, a qual possibilita coletar diversas métricas sobre a qualidade do código fonte – entre elas a dívida técnica (technical debt). A interpretação dos dados coletados possibilitou a análise da evolução da DT desses produtos, a classificação dos projetos e a verificação da representatividade dos eixos de qualidade que compõem a DT. Os resultados sugerem que a maioria dos projetos avaliados demonstrou diminuição da DT, ao longo de suas versões, e apresentou valores pouco elevados para a métrica. Outra contribuição consiste que os eixos de qualidade “Cobertura”, “Violações” e “Complexidade” foram identificados como aqueles que mais contribuem para o incremento da DT do conjunto de produtos avaliados. Foi possível, também, verificar a existência de uma correlação entre a implementação da DT estudada e a metodologia SQALE, no que diz respeito à avaliação da qualidade de software.

Technical debt is used to describe the changing or to maintain a system due to expedient shortcuts done during its development. In the context of the software development industry, technical debt is regarded as a critical issue in terms of the negative consequences such as increased software development cost, low product quality, decreased maintainability, and slowed progress to the long-term success of developing software. Code Smells are well informed in the domain of Technical Debt. They indicate to the common bad practices that may impair the future quality of the software system. By identifying those Code Smells, it is possible to give an improved solution or make the developers aware of a possible deficiency. I explore the premise that technical debt within the enterprise should be viewed as a tool. Extensible and Appropriate tools can check the Code Smells automatically and improve the quality assessment accordingly. However, in the field of Enterprise Architecture(EA), common bad habits in EA can be called EA Smells. EA Smells itself can be a component of EA Debt. Enterprise Architecture Debt can be defined as such a metric that depicts the deviation of the currently present state of an enterprise from a hypothetical ideal state.In this thesis, we introduce SmellCull as an extensible tool for capturing, tracking and managing Enterprise Architecture debt in the EA field. SmellCull allows measuring different kinds of Enterprise Architecture debts for EA Model. SmellCull is extensible since different types of Model can be integrated as input into the tool environment and provides developers with a lightweight tool to capture EA debt and make it easier to understand them indicating corresponding parts in the implementation. The tool is used to create propagation paths for the EA debt. This allows for an up-to-date and accurate presentation of EA debt to be upheld, which enables developer conducted implementation-level micromanagement as well as higher-level debt management.Since the tool is sophisticated enough, automated detection supports the design process and ongoing change of EAS(Enterprise Architecture System). This includes the strategic development of EAS with the corresponding roadmaps, as well as design assurance and performance monitoring to assess the quality of data in EA repositories and the compliance with certain standards defined by EA Smells. Due to the limited scope of master thesis, the tool will identify a few number of EA debt. At the end, some future work suggestions in the context of identifying more salable Enterprise Architecture Debts with this tool are given. / Teknisk skuld dvs dålig eller kortsiktig programutveckling som belastning på IT-system måste förr eller senare återbetalas. I industrin betraktas teknisk skuld som en kritisk fråga när det gäller de negativa konsekvenserna som ökad mjukvaruutvecklingskostnad, låg produktkvalitet, minska underhåll och långsammare framsteg till den långsiktiga framgången med att utveckla programvara. Dålig kodkvalitet “code smell” är vanligt förekommande teknisk skuld. Det uppkommer i vanliga dåliga metoder “anti-patterns” som försämrar programvarans framtida kvalitet. För att kunna identifiera bristande kodkvalitet är det möjligt att skapa en förbättrad lösning eller göra utvecklare medvetna om de möjliga bristerna. Jag undersöker förutsättningarna att en sådan teknisk skuld i företag bör undersökas med en programvara. Utbyggbara och ändamålsenliga programvaror kan analysera källkod och hitta var kvaliteten behöver förbättras. Företagens tekniska skuld kan definieras som ett mått som visar avvikelsen från ett hypotetiskt idealtillstånd genom att jämföra det aktuella tillståndet med praktiska rekommendationer “best practice”. I detta examensarbete introducerar jag SmellCull som ett utbyggbart verktyg för att hitta, spåra och hantera bristfällig kodkvalitet inom företagsarkitektur (EA). SmellCull tillåter mätning av olika typer av tekiska skulder för EA modellen. SmellCull är utbyggbart genom att olika typer av datamodeller kan integreras som indata i miljön, och det ger utveck-lare ett lätt verktyg för att hantera teknisk skuld i programmeringsprojekt och hjälpa projektdeltagarna i programmeringsprojekt att förstå vad orsakar brister i kodkvalitet.  Eftersom verktyget är tillräckligt sofistikerat finns det automatiserad spårning, designprocess och kontinuerlig förbättring av EAS (Enterprise Architecture System). Detta inkluderar strategisk utveckling av EAS med motsvarande färdplan, samt konstruktionssäkerhet och prestandäovervakning för att bedöma kvaliteten på data i EA förvar och efterlevnaden av vissa standarder som definieras av EA code smell detection. På grund av den begränsade omfattningen av examensarbetet kommer verktyget att  identifiera några få EA skuld. I slutet, några framtida arbetsförslag i samband med identifiering mer säljbara företagsarkitekturskulder med detta verktyg ges.

Software architecture (SA) smells are design problems in the internal structure and behavior of an SA. These can be seen as a specific category under the umbrella concept of technical debt (TD). TD is a central concept in software development projects and having the means to detect and measure the smells is essential to understand impairments they may cause. However, TD is only limited to the technical aspects and does not describe smells found on an enterprise level. Enterprise architecture debt (EAD) expands the concepts of TD beyond the technical aspects such that it covers the debts that can be found in all layers of an Enterprise Architecture (EA). EA smells give a measurement for EAD by providing means for identifying and detecting the smell, hence enabling a method to quantify the level of debt. The goal of this thesis is to find EA smells derived from existing SA smells. In total, three new EA smells were presented based on existing SA smells. Each new smell was described by a short description that informally summarizes the smell. This was followed by an indication of the smell’s origin and reasoning about the effects on the quality. Then, an illustrative example of the smell was provided. Finally, a detection algorithm was also provided and implemented in a prototype detection program. This thesis serves as a basis for measurements of the quality of an EA and motivation for future research in this area. It is argued that the finding of EA smells can facilitate quality assessment in an EA. / Mjukvaruarkitektursrötor (MA-rötor) är designproblem i den interna strukturen och beteende i en mjukvaruarkitektur. Dessa kan ses som en specifik kategori under samlingsbegreppet teknisk skuld (TS). TS är ett centralt begrepp inom projekt i mjukvaruutveckling och att ha en metod att upptäcka och mäta dessa rötor är viktigt för att förstå försämringar dessa kan orsaka. TS är dock enbart avgränsat till de tekniska aspekterna och beskriver inte rötorna som kan finnas på en verksamhetsnivå. Verksamhetsarkitektursskulder (VAS) expanderar konceptet av TS utöver de tekniska aspekterna så att de även täcker skulderna som kan finnas på alla nivåer i en verksamhetsarkitektur (VA). VA-rötor ger ett mätvärde för VAS, genom att förse ett sätt att upptäcka rötorna och därmed möjliggöra ett sätt att kvantifiera graden av skuld. Målet i denna avhandling är att hitta VA-rötor som är härledda från befintliga MA-rötor. Totalt har tre nya VA-rötor presenterats baserat på befintliga MA-röter. Varje ny röta har beskrivits med en kort beskrivning som informellt summerar rötan. Detta följt av en indikation av rötans ursprung och resonemang om dess effekt på kvalitén. Ett illustrativt exempel har även presenterats. Slutligen, har en algoritm för att upptäcka rötan också presenterats och implementerats i ett prototypprogram för att upptäcka rötan. Denna avhandling används som en grund för mätvärden av kvalité i en VA och motivation för framtida studier i detta område. Det argumenteras för att identifieringen av VA-rötor kan förenkla kvalitetsbedömningen av en VA.

The rapid pace of digitalization has resulted in increased management of software development, and today a majority of startups are reliant on software. How to manage software development projects is a well-researched area and agile methods are widely adopted by companies in all industries and sizes. However, prior to working with agile methods or any other software development methodology, the founders and management of a startup have to make several technical decisions that could potentially affect the whole software development process and the company's success. Furthermore, studies show that only three programming languages are known by more than 50% of developers, suggesting that the potential effects of technical decisions stretch outside the software development process.  By performing a multiple-case study on startups with a mixed-methodology approach, the researcher has analyzed the literature, interviewed several founders and Chief Technology Officers, and quantitatively analyzed hundreds of thousand lines of code, to find how to organize to make better technical decisions in order to enhance growth and generate less technical debt. The results show that the effects of technical decisions stretch outside the software development process, having an apparent effect on a startup's ability to attract and retain talent. Furthermore, the results show that access to talent is an important but not deciding factor in technical decision-making. Additionally, it is found that in the initial stage of a startup, ease of development and speed are important factors in technical decisions as the main objective is to find product-market fit. When product-market fit has been found and the startup matures, the focus shifts and quality and durability are becoming prominent factors. It is found that scooping features only to implement the absolute core functionality is an effective approach to develop quickly and generate less technical debt while maintaining customer satisfaction. Lastly, it is found that programming language affects the number of issues generated per line of code and the time spent on building features. However, as found in the literature, there is no evidence of this being related to the type of programming language.  The findings have both practical and academic implications. In academics, this thesis lays the foundation for further studies and provides new insights into the field of startups in general, and technical decision-making in particular. For practitioners, this thesis provides a basis for discussion and execution of technical decisions in the early stages of a startup. / Den snabba digitaliseringen har resulterat i en ökad ledning av mjukvaruutveckling och idag är majoriteten av startups beroende av någon form av mjukvara. Hur man leder mjukvaruutvecklingsprojekt är ett välutforskat område och agila metoder är välanvända i företag i alla industrier och storlekar. Innan man arbetar med agila metoder eller någon annan mjukvarutvecklingsmetod så måste grundarna och ledningen ta flera tekniska beslut som potentiellt kan påverka hela mjukvaruutvecklingsprocessen och företagets framgång. Samtidigt finns det studier som visar att endast tre programmeringsspråk hanteras av mer än 50% av utvecklarna, vilket indikerar att de potentiella effekterna av tekniska beslut sträcker sig långt utanför mjukvaruutvecklingsprocessen.  Genom att utföra en flerfallsstudie på startups med både kvalitativa och kvantitativa moment, har forskaren analyserat literaturen, intervjuat flertalet grundare och tekniska chefer, och kvantitativt analyserat hundratusentals rader kod, för att undersöka hur startups kan organisera sig för att ta bättre tekniska beslut som förbättrar tillväxten samt genererar mindre teknisk skuld. Resultaten visar att effekten av tekniska beslut sträcker sig långt utanför mjukvaruutvecklingsprocessen genom att ha en direkt påverkan på startups möjlighet att attrahera och behålla talang. Tillgången till talang visar sig även vara en viktig faktor i teknisk beslutsfattande, däremot är den inte en avgörande faktor. Dessutom visar resultaten att i det initiala stadiet av en startup så är enkelhet och hastighet viktiga faktorer i tekniskt beslutsfattande eftersom fokus ligger på att hitta produkt-marknads-anpassning. När produkt-marknads-anpassning är funnen och startupen mognar, så skiftar dessa faktorerna över till kvalité och hållbarhet. Resultaten visar även att en effektiv metod för att utveckla snabbt och skapa mindre teknisk skuld är att skala ner förfrågningar till dess absolut grundfunktionalitet, samtidigt visade det sig att kundnöjdheten inte minskade. Slutligen visar resultaten att val av programmeringsspråk har en effekt på antalet issues genererade per rad kod och även tiden spenderad för att bygga features. Däremot, precis som i tidigare forskning, finns det inga bevis på att det är relaterat till typen av programmeringsspråk.  Resultaten har både praktiska och akademiska implikationer. I den akademiska världen så lägger detta arbetet en grund för framtida forskning och ger nya insikter i startupfältet generellt, och tekniskt beslutsfattande i startups i synnerhet. För utövare, lägger detta arbetet en bra bas för diskussion och verkställande av tekniska beslut i startups.

Digitaliseringen har inneburit en tilltagande komplexitet i organisationer, vilket föranlett skapandet av begreppet teknisk skuld. Likväl som organisationer försätter sig i ekonomiska skulder försätter sig organisationer i tekniska skulder. Tidigare forskning inom teknisk skuld visar på ett kunskapsgap gällande organisationsteoretiska aspekters eventuella påverkan på teknisk skuld. Baserat på detta så syftar studien till att undersöka antagandet gällande kontrasterande perspektiv på teknisk skuld mellan kommersiellt styrda och tekniskt styrda organisatoriska enheter. För att sedan utforska huruvida balansen av organisatoriska aspekter mellan enheter kan understödja en viss typ perspektiv och därmed inverka på organisationens faktiska ageranden, avvägningar och vägval i relation till teknisk skuld. Undersökningen grundas i en kvalitativ fallstudie där åtta intervjuer i fyra mjukvaruutvecklande organisationer genomförts. Studien visar på att perspektiven mellan enheter i denna undersökning skiljer sig åt en aning men att detta inte påverkar teknisk skuld i någon större utsträckning. Detta tack vare ömsesidig förståelse, god kommunikation, samsyn genom överordnade mål samt balans mellan makt och kultur. Kommersiella krafter tycks besitta något mer makt men undersökta bolag har samtidigt vägt upp detta genom en tydligt teknikfokuserad kultur. Vilket kan få organisationer att, om något, balansera en aning mer åt ett fokus på framtida hållbarhet och därmed gå miste om nutida affärsmöjligheter genom att undgå ett mer flexibelt och tillåtande förhållningssätt till teknisk skuld. / Digitization has meant an increasing complexity in organizations, which has led to the creation of the concept of technical debt. Just as organizations incur financial debts the organizations incur technical debts. Previous research in technical debt sheds light on a knowledge gap regarding organizational aspects, which influence technical debt. Based on this, the study aims to examine the assumption regarding contrasting views on technical debt between commercially controlled and technically controlled organizational units. To then explore whether the balance of organizational aspects between units can support a certain type of perspective and thereby influence the organization's actual actions, trade-offs and decision-making in relation to technical debt. The study was created through a qualitative case study where eight interviews were conducted in four software developing organizations. The study shows that the perspectives between units in this survey differ slightly, but that this does not affect technical debt to any great extent. This thanks to mutual understanding, good communication, consensus through overriding goals and a balance between power and culture. Commercial forces seem to possess somewhat more power, but surveyed companies have at the same time offset this through a clear product- and technology-focused culture. Which may cause organizations to, if anything, balance a little bit more on future sustainability and thus miss out on current business opportunities by avoiding a more flexible and permissive approach to technical debt.

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.