Exploring the prevalence and common types of technical debt in a CRM software

Abstract

Tässä pro-gradu tutkielmassa tutkittiin teknisen velan yleisyyttä ja sen yleisimpiä muotoja asiakkuuksienhallintaohjelmistossa. Tarkastelun kohteena oleva ohjelmisto on ollut käytössä suurella yrityksellä ja se on rakennettu juuri tämän yrityksen tarpeisiin. Ohjelmisto on ollut käytössä yli kymmenen vuotta, mutta teknisen velan yleisyys ei ole ollut tiedossa. Teknistä velkaa oletetaan kuitenkin olevan olemassa kyseisessä ohjelmistossa. Tutkimuksessa käytettiin tapaustutkimus -menetelmää, hyödyntäen "koodihajuja", joilla voidaan saada tietoa teknisestä velasta yleisesti ja sen yleisimmistä muodoista. Teknistä velkaa tutkittiin kahdella eri työkalulla, jotka olivat IDE:n (integrated development environment) oma koodihajutyökalu ja IDE:n marketplacesta saatava koodihajutyökalu PMD. Jälkimmäiseen työkaluun päädyttiin olemassa olevan tutkimuksen perusteella. Koodihajujen tutkimiseen rakennettiin raamit, jotka sisällyttivät tietyin kriteerein koodihajuja. Näiden raamien avulla pystyttiin selvittämään, että ohjelmistosta löytyy kohtalainen määrä teknistä velkaa sekä yleisimpien teknisen velan tyyppien liittyvän suorituskykyyn.

This master’s thesis researched the prevalence of the technical debt and its common types in a customer relationship management software. The software is used by a large company and it has been built solely for this companys needs. The software has been running for over ten years and the prevalnce of the technical debt has been unknown but it is presumed that it exists. The research was conducted with a case study model, utilixing "code smells", which are useful to gather information about technical debt and its types. The data was gathered using two different tools. First one was the IDE’s (integrated development environment) own code inspection tool and the second one was PMD and it was decided using previous research and downloaded from the IDE’s marketplace. To examine the code smells a frame and inclusion/exclusion critrias were built. With the help of these frames, it was possible to examine that the software has a medium level technical debt and most common types were linked to the performance parts of the software.