In complex information flows where a lot of varied data is transmitted through many companies and divisions, incidents will occur. When Visma Spcs had an incident where invoices sent from Visma to Visma's customers were duplicated and the service meant to receive the transactions did not handle the duplicates properly. They decided that the receiver service was to be upgraded to prevent this incident from happening again, as well as fixing some other issues the service had had. Incidents like this one must be investigated and a solution must be implemented to decrease the likelihood that similar incidents will happen again. In this report, the reader will see examples on how this can be handled and the benefits of tackling technical debt, along with how much more complicated the solutions might get if the service is not allowed to be taken offline.

The unprecedented ubiquity with which technological advancements, such as blockchain, the Internet of things (IoT), big data, machine learning, and artificial intelligence (AI), are impacting the world has forced large organizations to rethink their information technology roadmaps. Their decisions about how they invest in technology have become more important. It is against this backdrop that companies must decide how much to invest in their aging technologies versus these new potentially transformational ones. A decision is only as good as the information available to the decision-makers when they make it. This research project seeks to understand the effects that information asymmetry has on strategic information technology (IT) investment decisions within large complex organizations. The data collected for this study was gathered from six executives. The conceptual model was grounded in Akerlof’s (1978) seminal paper on information asymmetry. This study followed an Action Design Research (ADR) approach to formulate the problem and an elaborated Action Design Research (eADR) process model to create a solution. Results indicate that using the proposed solution will result in organizations making more informed strategic IT investment decisions.

As software systems grow in size they will also grow in complexity. If the increased complexity is not managed the system will be increasingly difficult to maintain. The effect of unmaintainable software is even more distinct when using a agile development process. By increasing the maintainability of the system these problems will be dealt with and the system can be extended with sustained efficiency. This thesis will evaluate the development process of a modern, agile company in order to find changes that will promote increased maintainability. The result is an modified process that will increase the maintainability with the smallest possible overhead for the development organisation. The result is based on earlier studies of development technologies that have proven to increase the maintainability. The implementation of these technologies are adjusted to fit the development team, and some of the technologies that are not suitable for the team are rejected.

The development of Information Technology is, according to the Swedish Government, the most important area of development. The costs of IT in governmental agencies are somewhere in between 20 to 25 billion SEK, paid by taxpayers and one of the largest cost items in the Swedish governments resources. Despite this, every third Swedish governmental agency lacks an IT-strategy and is unable to meet needs for flexibility and control. The study aims to reveal barriers that prevent an active application lifecycle management (ALM) at Swedish governmental agencies and to answer the question: “How do Swedish authorities handle their proprietary applications from a lifecycle perspective; financially and technically?” The case study will be conducted at the Social Insurance Agency (SIA). The SIA distributed, in 2010, about 6 % of the Swedish GDP and is mainly funded by grants and loans from the Swedish National Debt Office. The survey will be studied from a management accounting and ALM perspective. Management accounting is the actions within organizations to achieve financial goals. ALM is the lifecycle of an application that consists of the phases; requirements specification, development, testing, deployment and maintenance. The study will also investigate the technical debt at the governmental agencies. Technical debt refers to the work which has to be completed before an application can be considered finished. The survey is a qualitative study based on interviews with an exploratory purpose. The results are generalised to reflect a greater part of the Swedish authorities and showed that Swedish governmental agencies have inadequate handling of their proprietary applications and that each application is financially linked to one or more projects simultaneously. The models made are to facilitate the understanding of the different stages of ALM in synergy with the management accounting. Theoretically, the Maintenance phase allocates approximately 90 % of the total costs, whereas in governmental agenises it stands for about 20 %. Theoretically 10 % of the total costs are allocated to the Development phase, whereas in governmental agencies the corresponding amount is 80 %. A consequence of this is increased technical debt. The technical debt at Swedish authorities is often funded with loans, which is not allowed according to the Swedish National Debt Office. The SIA exceed budgets without asking for increased funds and according to the Swedish Audit Office, so does also 1/3 of the Swedish governmental agencies, meaning that they must handle the financial complications internally by moving funds amongst different departments and projects, also spending money meant for development on maintenance. Future studies can be made as investigations on how management accounting and ALM can be implemented on a safe and effective manner in a governmental agency.

Context. Technical debt (TD) is a metaphor reflecting technical compromises that sacrifice long-term health of a software product to achieve short term benefit. TD is a strategy for the development team to obtain business value. TD can do both harm and good to a software based on the situation of TD accumulation. Therefore, it is important to manage TD in order to avoid the accumulated TD across the breaking point. In large-scale distributed projects, development teams located in different sites, technical debt management (TDM) becomes more complex and difficult compared with traditional collocated projects. In recent years, TD metaphor has attracted the attention from academics, but there are few studies in real settings and none in large-scale globally distributed projects. Objectives. In this study, we aim to explore the factors that have significant impact on TD and how practitioner manage TD in large-scale distributed projects. Methods. We conducted an exploratory case study to achieve the objectives. The data was collected through archival records and a semi-structured interview. For the archival data, hierarchical multiple regression was used to analyze the relationship between identified factors and TD. For interview data, we used qualitative content analysis method to get a deep understanding of TDM in this studied case. Results. Based on the results of archival data analysis, we identified three factors that show significant positive correlation with TD. These three factors were task complexity, global distance, and maturity, which were evaluated by the architect during the semi-structured interview. The architect also believed that these factors have strong relationships with TD. TDM in this case includes seven management activities: TD prevention, identification, measurement, documentation, communication, prioritization, and repayment. The tool used for TDM is an internally implemented tool called wiki page. We also summarize the roles involved and approaches used with respect to each TDM activity. Two identified TDM challenges in this case were TD measurement and prioritization. Conclusions. We conclude that 1) TDM in this case is not complete. Due to the lack of TD monitoring, the measurement of TD is static and lacks an efficient way to track the change of cost and benefit of unresolved TD over time. Therefore, it is difficult to find a proper time point to repay a TD. 2) The wiki page is not enough to support TDM, and some specific tools should be combined with wiki page to manage TD comprehensively. 3) TD measurement and prioritization should get more attention both from practitioners and academics to find a suitable way to solve such challenges in TDM. 4) Factors that make significant contribution to TD should be carefully considered, which increase the accuracy of TD prediction and improve the efficiency of TDM.

Submitted by Cláudia Bueno (claudiamoura18@gmail.com) on 2015-12-04T17:46:01Z No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Approved for entry into archive by Luciana Ferreira (lucgeral@gmail.com) on 2015-12-07T11:12:37Z (GMT) No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) / Made available in DSpace on 2015-12-07T11:12:37Z (GMT). No. of bitstreams: 2 Dissertação - Andrey Estevão da Silva - 2015.compressed.pdf: 2582210 bytes, checksum: f95bff4058d3be1a4b52850b6023b906 (MD5) license_rdf: 23148 bytes, checksum: 9da0b6dfac957114c6a7714714b86306 (MD5) Previous issue date: 2015-09-11 / The SoftwareTechnicalDebtaimstocalculatecostsfromthefailuretocomplywithqua- lity standardsinthedevelopmentprocess,suchaslackofdocumentation,baddevelop- ment practicesanddisobediencetospecificcodingrulesofaproject.Oneoftheconcerns of organizationsandsoftwareengineersistoensuresuchqualitystandards,however,the humane wayofdoingthiscontrolallowsmistakeswhichconsequentlycausesTechnical Debt, whichintheshorttermarenotaproblem,butinthelongruncandestroyentire softwarestructures.Basedonthisproblem,itwillbeproposedanapproachforcalcu- lating theDesignTechnicalDebtofapplicationsdevelopedinJava.Themethodsused for thispurposeinvolvedataminingofopensourcecoderepositories,defecttracking softwaredatabases,timecorrectionestimativeofdesignrulesviolationandarchitectural compliance check. / A estimativadeDívidaTécnicadeSoftwaretemcomoobjetivocalcularoscustosdonão- cumprimento depadrõesdequalidadenoprocessodedesenvolvimento,taiscomofaltade documentação, máspráticasdedesenvolvimentoedesobediênciaàsregrasdecodificação específicas deumprojeto.Umadaspreocupaçõesdeorganizaçõeseengenheirosde softwareégarantirtaispadrõesdequalidade,noentanto,aformahumanadefazereste controle permiteerrosque,consequentemente,ocasionamDívidaTécnica,queemcurto prazo nãosãoumproblema,masemlongoprazopodedestruirestruturasdesoftware inteiras. Combasenesteproblema,serápropostaumaabordagemparaocálculodaDívida Técnica deDesigndeaplicaçõesdesenvolvidasemJava.Osmétodosutilizadosparaeste fim envolvemamineraçãodedadosderepositóriosdecódigoaberto,bancosdedados de softwarederastreamentodedefeitos,estimativadotempodecorreçãodeviolaçãode regrasdedesigneverificaçãodeconformidadearquitetural.

It is arguably an important matter to track and eliminate poor quality. One way of doing this within software development is by applying the technical debt metaphor and using it as a basis when estimating the quality level. There was interest expressed in investigating whether this metaphor could be extended to the development of non-software products and use it as a starting point for developing features in a PLM (product lifecycle management) system able to track and help monitor technical debt throughout the lifecycle of a product. Thus, a case study based on a literature review and interviews analysed qualitatively were conducted. The result consists of the knowledge that similar notions as found in the technical debt research could successfully be applied to other development processes and phenomena as well, a framework consisting of types of technical debt and a “sketch” for how to measure it, and that in a technical debt-tracking feature it could be beneficial with functionality for implementing models for debt quantification, for allowing the organisation to set up rules, and for crawling through the product taxonomy in the PLM system, detecting deviances from aforementioned rules.

I det teknikväxande samhället bidrar mjukvaruutveckling till stora it-relaterade utgifter och investeringar. Industrier utvecklar stödjande programvara för sin produktion och mjukvaruföretag levererar digitala system för kunder som behöver uppfylla ett behov. Utvecklingsteamen jobbar under press för att leverera så bra programvara som möjligt och samtidigt hålla sig inom budgetramar som satts upp enligt avtal. För att nå sina mål kan utvecklare introducera teknisk skuld i systemen, dvs. att bristfälliga lösningar byggs före kvalitetslösningar. Teknisk skuld behöver inte vara ett problem för stunden men på sikt kan konsekvenserna av skulderna bli problematiska och kräva resurser att kunna hanteras. Tidigare forskning visar att drygt en fjärdedel av en utvecklares tid går åt för att hantera teknisk skuld. Vid åtgärdande av teknisk skuld brukar refaktorisering vara ett vanligt verktyg att ta till, vilket innebär att skriva om källkod utan att förändra det visuella beteendet för användaren. Syftet med följande uppsats är att undersöka olika branscher som utvecklar mjukvaraoch deras hantering av teknisk skuld genom att belysa vilka faktorer som avgör om och när refaktorisering skall ske, och hur argumentationerna för refaktorisering skiljer sig åt mellan branscherna. Uppsatsen baseras på kvalitativa intervjuer med aktörer från både industri- och mjukvaruföretag. Empirin från intervjuerna analyseras med hjälp av en ontologisk mappning kring typer av teknisk skuld, som sedan har applicerats i ramverket Technical Debt Quadrant. Resultatet visar att industribranschens avgörande faktorer för refaktorisering var konsekvensen av skuldens påverkan samt hur pass förändringsbenägen den skuldbelagda funktionaliteten var. Branschen ansåg att tidpunkten för att refaktoriseravar bäst lämpad i samband med vidareutveckling av en funktion som innehöll teknisk skuld. I konstrast visade resultatet för mjukvarubranschen att faktorerna för refaktorisering var konsekvensen av skuldens påverkan samt vilka ekonomiska förutsättningar som fanns för projektet. Tidpunkten för när refaktorsering var lämplig avgörs när företagen anser att avkastningen för investeringen att refaktorisera är som högst eller när inget annat val finns. Resultatet visar även att branscherna hade olika fokus för hur de argumenterar för refaktorisering. Industrin argumenterade mer med systemet i fokus, hur det kundeförändras med tiden och att det skulle bli lätthanterligt att underhålla med tiden. Mjukvarubranschen hade mer ekonomiska aspekter som argument, dvs. att de analyserade situationen och beslutade huruvida refaktoriseringen är lönsam eller inte. / In the technology-growing society, software development contributes to large itrelated expenditures and investments. Industrial companies develop supporting software for its production and software companies deliver digital systems for customers to satisfy a need. The development teams work under pressure to deliver as good software as possible and at the same time stay within budget frameworks according to agreements. To achieve their goals technical debt in systems can be introduced, which means that deficient solutions are built before quality solutions. Technical debt does not have to be a problem at first, but in the long run the consequences of the debts can become problematic and require resources to be managed. When fixing technical debt, refactorization is a common tool to resort to, which means to rewrite source code without changing the visual behaviour to the user. Previous research shows that just over a quarter of a developer's time is spent managing technical debt. The purpose of the thesis is to examine different industries that develop software and their management of technical debt by highlighting which factors determine if and when refactoring should take place, and how the arguing for refactorization differentiate between the industries. The thesis is based on qualitative interviews with actors from both industrial and software companies. The empirical data from the interviews are analysed with the help of an ontological mapping around types of technical debt, and later applied in the framework Technical Debt Quadrant. The results show that the industry companies' decisive factors for refactorization were the consequence of the debt's impact and how prone to change the indebtedness functionality was. The industry considered that the time to refactorize was best suited in connection with the further development of a function that contains technical debt. In contrast, for the software companies the results showed that the factors for refactorization were the consequences of the debt's impact and what financial prerequisites there were for the project. Appropriate timing for refactoring wasdetermined when the companies consider that the return on the investment to refactorize is at its highest or when there is no other choice. The results also show that the industries had different focus on how they argue for refactorization. The industry argued more with the system in focus, how it could change over time and that it should be easy to maintain while the software industry had more economic aspects as an argument, ie. that they analyzed the situation and made choices whether the refactorization is profitable or not.

Nowadays, while software industries are aiming to develop their software continuously, their delivery is hindered by technical debt.  Preventing technical debt would be valuable if it is considered in architectural decisions. On the other side, since microservices architecture is adaptable to build cloud applications and has other advantages, it has become a trend in the software industries. Due to the popularity of microservices and the importance of technical debt in the software industry, this research aims to find the influence of architectural decisions on technical debt in microservices applications. In this research, we explore architectural decisions in microservice applications and their qualities that impact technical debt.   We calculated the repetitiveness of selected microservices architectural decisions and the extra effort that they need to meet qualities to prevent technical debt. Spearman correlation coefficient used to calculate the relation between extra effort on the qualities of architectural decisions in microservice applications that affect technical debt. Furthermore, we calculated the correlation between the repetitiveness of selected architectural decisions and the effort for their qualities to find the effect of repetitiveness on qualities that reduce technical debt.   Our result shows that every architectural decision that we have explored for microservice applications needs some extra effort to increase the quality that can prevent technical debt. Correlation between qualities and repetitiveness of architectural decisions shows that weak correlation, which proves that increasing or decreasing of repetitiveness would not change the demand for extra effort to prevent technical debt.

Software development companies strive to produce high-quality software. In commercial software development environments, due to resource and time constraints, software is often developed hastily which gives rise to technical debt. Technical debt refers to the consequences of taking shortcuts when developing software. These consequences include making the system difficult to maintain and defect prone. Technical debt can have financial consequences and impede feature enhancements. Identifying technical debt and deciding which debt to address is challenging given resource constraints. Project managers must decide which debt has the highest priority and is most critical to the project. This decision-making process is not standardized and sometimes differs from project to project. My research goal is to develop a framework that project managers can use in their decision-making process to prioritize technical debt based on its potential impact. To achieve this goal, we survey software practitioners, conduct literature reviews, and mine software repositories for historical data to build a framework to model the technical debt decision-making process and inform practitioners of the most critical debt items.