Detta examensarbete har varit inriktat på att studera nyttan av att omstrukturera ett mjukvarusystem till ett moderniserat system. Frågan som skulle besvaras av detta projekt var: vad är fördelarna med komponentiseringen av ett legacysystem, med avseende på utvecklingstid som krävs för vidareutveckling av systemet? Denna fråga besvarades med hjälp av en analys av forskningsfronten över ämnet samt att en fallstudie genomfördes. Det som framkom under analysen av forskningsfronten tydde väldigt mycket på att detta var lönsamt att göra. Trots att fallet var för en specifik aktör var det väldigt relevant att genomföra det för detta projekt för att på sätt få ett praktiskt exempel som hjälpte till att besvara forskningsfrågan. Genom att genomföra dessa undersökningar besvarade vi forskningsfrågan. Många slutsatser kunde dras och det blev ett tydligt resultat. Efter våra estimeringar skulle en aktör vinna på en modernisering av sitt legacysystem i de flesta fallen, om kompetensen för att genomföra detta finns. Fallstudien som genomfördes visade på tydliga vinster med att genomföra en moderniseringsprocess för ett legacysystem. / This thesis work has been focused on studying the benefits of restructuring a legacy system to a modernized software system. The question that was to be answered was: What are the benefits of componentization of a legacy system with respect to the software development time required for further system development? This question was answered by doing a state of the art on the subject and also by performing a case study. What was discovered during the state of the art implicated that this kind of work is very profitable to undergo. Even though the case was aimed at a certain system it was relevant to this study because it helped to get a practical example which in turn helped with answering the question for this thesis. By doing these studies the question for this report got answered. Many conclusions could be drawn and the result was clear. By our estimations an actor would benefit greatly by modernizing their legacy system in most cases, if they have the right knowledge for doing this. The case study that was performed showed obvious benefits of the process of modernizing a legacy system.

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.

Denna rapport har sitt ursprung i det kodefaktoriseringsarbete som utfärdats våren 2013 som examensarbete i dataingenjörsprogrammet vid Örebro Universitet. Arbetet utfärdades på Nethouse i Örebro, och hade stort fokus på koddesign och kodkvalitet. I rapporten diskuteras vilka faktorer som påverkar hur underhållbar och läsbar en kod är, men också hur man på ett rimligt sätt kan utvärdera och mäta kodkvalitet. Den teoretiska biten blandas med den praktiska, där läsaren introduceras för ett flertal metoder, och hur dessa sedan implementerades i det faktiska projektet som Nethouse tillhandahöll. / This report has its origins in the code refactoring work issued in spring 2013 as a Degree Project in the Computer Engineering Programme, at Örebro University. The work took place at Nethouse in Örebro, and had a major focus on code design, and code quality. The report discusses the factors that affect how maintainable and readable a code is, but also how to reasonably evaluate and measure code quality. The theory is mixed with the practical, where the reader is introduced to a variety of methods, and how these were then implemented in the actual project that Nethouse provided.

Flera företag använder sig än idag av mjukvarusystem som är uppbyggda med äldre mjukvaruarkitektur som den monolitiska. Ett av dessa företag är Consid vars personalsystem är uppbyggt med det utdaterade ramverket klassisk ASP och där användargränssnitt samt logik kan direkt kommunicera med varandra. Detta medför begränsningar som uppstår till följd av brister i modularitet på grund av valet av mjukvaruarkitektur, vilket försvårar vidareutveckling och ändringar i ett system. Dessa begränsningar påverkar i sin tur parametrar som prestanda, skalbarhet, säkerhet, robusthet samt integrering med modernare tekniker.  I denna rapport presenteras en litteraturstudie samt en semistrukturerad intervjustudie, i syfte att undersöka vilka mjukvaruarkitekturer som är lämpliga att implementera vid en modernisering av en monolitisk mjukvaruarkitektur. Arbetet diskuterade också vilka utmaningar som kan uppstå vid en sådan modernisering och hur de hanteras på ett effektivt sätt. Ett bedömningsschema med önskvärda parametrar, med avseende på skalbarhet, prestanda, säkerhet och robusthet, togs fram för att underlätta avgörandet vid val av mjukvaruarkitektur. Utifrån detta, beslutades det att en prototyp med en REST-baserad arkitektur skulle implementeras och utvärderas.  Resultatet av prototypen, till följd av re-architecting, visade en ökad modularisering av mjukvaruarkitekturen. I jämförelse mot med det tidigare systemet har den nya prototypen ingen större påverkan på prestanda i form av responstid. Däremot bidrog prototypen till förbättrad skalbarhet när det gäller vidareutvecklingen av systemet, eftersom det förenklar införandet av ny funktionalitet. Prototypen hade också högre säkerhet genom att isolera lager ifrån varandra samt dölja underliggande detaljer i implementationen. Dessutom blev prototypen inte bara mer robust till följd av modulariseringen, men även enklare att utföra integrationstester samt destruktiva tester mot. / Several companies still use software systems that are built with older software architecture such as the monolithic one. One of these companies is Consid, whose personnel system is built with the outdated framework Classic ASP and where the user interface and logic can directly communicate with each other. This entails limitations that arise because of shortcomings in modularity due to the choice of software architecture, which complicates further development and changes in a system. These limitations in turn, affect parameters such as performance, scalability, security, robustness, and integration with modern technologies. In this work, a literature study was conducted as well as a semi-structured interview study in order to investigate which software architectures are suitable to implement when a modernization of a monolithic software architecture, is carried out. The work also discussed the challenges that may arise in a modernization of the software architecture and how they are handled efficiently. An assessment scheme with desirable parameters regarding scalability, performance, security, and robustness, was developed to facilitate the decision in the choice of software architecture. Based on this, it was decided that a prototype with a REST-based architecture would be implemented and evaluated. The result of the prototype, following re-architecting, showed an increased modularization of the software architecture. Compared to the previous system, the new prototype has no major impact on performance in terms of response time. However, the prototype contributed to better scalability in the further development of the system as it simplifies the introduction of new functionality. The prototype also had higher security by isolating layers from each other and hiding the underlying details in the implementation. In addition, the prototype not only became more robust because of the modularization, but also easier to perform destructive tests against.